One can’t deny the irresistible convenience of using a homescreen launcher icon to fire up a web app. Variously referred to as a bookmark icon, shortcut, or homepage icon, why shouldn’t such an icon be able to launch a web page, as well as a native app? And of course it can: this functionality has been available in Android and iOS for years. Indeed, the notion of a desktop shortcut has been around since the first GUI interfaces were developed. So why are we still talking about them in 2015?
The appification of the web
The native vs web debate has been dragging on for years. We’ll sidestep it here for the most part. It’s enough for us to note that some argue that the web shouldn’t seek to imitate native apps: the web is a different beast than native, and so appification isn’t necessarily the right way to go. Others embrace the recent advances in web technologies, without obsessing over matching native performance, attaining a 60fps scroll, for example. The healthy competition of native apps has been good for web technology, lighting a fire underneath it and catalyzing innovation to reduce the experience and feature gaps. Functionality such as geolocation and push notifications, for example, were available natively long before they came to the browser, but come to the browser they eventually did!
It hasn’t all been one sided though. Native has struggled with one of the fundamental building blocks of the web, URLs, and has had to come up with complicated hacks such as Applinks just to replicate linking and indexing.
Regardless of whether or not you support the appification of the web, right now it’s possible to superficially clothe your web app in native garb, with a little help from the host OS and a small file called the web app manifest.
What is a web app manifest?
Simply put, a web app manifest is a file that provides useful meta-data about a web app, such as its name, icons, launch configurations (full-screen or with browser chrome, and orientation) among other things. It’s a JSON file that describes some superficial aspects about how the web app can be launched. In particular it allows a more native- or app-like experience.
These configurations are mostly surface-deep, allowing you to configure how the app should be launched and displayed; if you really want a web app to look and behave like a native app, there’s a whole UI mindset you’ll have to get into when you starting coding.
Web app manifest properties
What exactly can the web app manifest do for you? The following properties are in the current W3C Web app manifest draft:
lang |
app language |
short_name |
name of application. If present this property will be used over the name property if present |
name |
longer application name |
scope |
the navigational scope of the web app, restricting the URLs to which the manifest applies |
splashscreens |
a list of images to be used as splashscreens for devices. Different screen resolutions can be targeted with separate images. Not mandatory for a browser to display the splashscreen |
icons |
a list of icon images to be used as the homescreen launcher icon. Different screen resolutions can be targeted with separate images. |
display |
indicates the display mode for the web app. Common values are |
fullscreen |
dispenses with the browser chrome, leaving more space for the web app screen content |
standalone |
launches like a native app, which may include having a different window, its own icon in the application launcher |
minimal-ui |
similar to fullscreen, but provides some minimal set of navigation UI elements |
browser |
opens with browser, as with a standard link |
orientation |
portrait or landscape |
start_url |
the first URL that should be loaded when the web app is launched. If this property is missing the URL of the current page will be used |
theme_color |
the CSS color of the theme for a particular app context. (Note this feature may be removed from the spec) |
related_applications |
specifies specific platform apps that may be related to this web app, for example an app on the Google Play store. |
prefer_related_applications |
indicates if a specific native app is preferred over this web app |
How to include web app manifest in webpage
This is easy, just include the following in the head of your web page
|
1 |
<link rel="manifest" href="/manifest.json" /> |
You can use any filename for your manifest file.
A sample web manifest
A sample web app manifest is given below:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
{ "lang": "en", "name": "mobiForge - Mobile Web Development", "short_name": "mobiForge", "icons": [{ "src": "icon/lowres", "sizes": "64x64", "type": "image/webp" }, { "src": "icon/hd_small", "sizes": "64x64" }, { "src": "icon/hd_hi", "sizes": "128x128", "density": 2 }], "splash_screens": [{ "src": "splash/lowres", "sizes": "320x240" }, { "src": "splash/hd_small", "sizes": "1334x750" }, { "src": "splash/hd_hi", "sizes": "1920x1080", "density": 3 }], "scope": "/", "start_url": "/index.htm", "display": "fullscreen", "orientation": "landscape", "theme_color": "aliceblue", "background_color": "red" } |
The web manifest above specifies icons of different sizes to target various screen resolutions, in addition to specifying a few of the other properties mentioned above. It should be fairly clear what it’s doing!
Splash screens
Splash screens landed in Chrome 47 (October 2015), described as a way to further improve the user experience and perceived performance of loading a webapp. Before this, the problem with launching web apps in a native-like way was that while waiting for the first render of the app, the screen would simply turn white. This could last for several seconds or more, depending on how well (or not) the site in question was coded. Displaying a splash screen addresses the issue in much the same way that a native app does.
So how do they work? Splash screens are built dynamically from information specified in the manifest file. If you want a splash screen for your webapp, make sure you have the following in the manifest:
- name: This will be displayed at the bottom of the splash screen
- background_color: The splash screen will adopt this as background color. Set this to match the color of your webapp
- icons: An icon will be chosen from the array of icons in the manifest to be displayed at the center of the splash screen. The icon most closely matching 128 device pixels (dp) (1dp = 1px at 160dpi). If you provide icons at 128px, 192px, 256px, 384px, and 512px, you will be well covered for most displays. You can go lower too to ensure lower-display density devices don’t download more than they need—Chrome will pick the best match.
The splash screen will look something like this:
App install banners
Google’s Chrome browser has taken this idea one step further. Paul Kinlan notes that the Add to home screen option was still hidden behind a menu, so to improve this experience, a recent version of Chrome (M42) added App Install Banners: popups that appear after frequent or habitual visits to a particular webpage and prompt the user to install with an add to homescreen button:
Adding to homescreen. Source: Google Developers
While web app manifests are an integral part of this, they are are not the only part. There are several checkboxes to be ticked before Chrome will offer to install a web app in this way:
- The web app must have a manifest
- A service worker must be registered for the website—I suppose the rationale here is that it will have some offline capability, making it a better candidate for installation
- The site must be served over HTTPS—this is a requirement for service workers anyway
- The user must have visited the site twice over two separate days during the course of two weeks
Progressive apps
It’s telling that the requirements for App Install Banners go a little beyond a simple manifest. There is more to appiness than icons and color schemes—it’s not just about the interface. Things like offline capabilities and push notifications feature prominently too. It’s no coincidence that these are exactly the kinds of thing possible with service workers, and I believe that’s why the Chrome team included them as a requirement: if there’s a service worker involved, there’s a good chance that this web page will display some app-like qualities.
Alex Russell describes web apps that satisfy the conditions above, along with a few other properties, as progressive apps. The idea is that as an app is used more and more, it graduates to become more app-like: a prompt to install to home-screen will appear after frequent use, whereupon things defined in the web app manifest now come into play, such as the specified home-screen icon, and whether the web app can go full screen (i.e hide the address bar). The key here is that this is not invasive or obnoxious to the user, in the way that the ubiquitous Download our app and Install as app first-visit popups can be. The app must earn its place on the homescreen. And when it does, there are benefits to be had, such as fullscreen browsing and a top-level spot in the OS task switcher.
With the as-needed permission model of the web, behaviour can be progressively enhanced as trust is gained; it’s not an upfront, all-or-nothing proposition, so that users don’t have to perform a mental audit of an app’s permissions prior to installing. If a particular permission is denied by the user during the course of usage, then the app can still function, just without that extra bit of functionality. Over time, it can may earn your trust, and you may grant it further permissions. For example, if location sharing is not permitted by the user in a map based application, if built well only the location-dependent functionality won’t work; everything else the web app has to offer should still be functional. As Russell puts it:
Sites that want to send you notifications or be on your home screen have to earn that right over time as you use them more and more. They progressively become “apps”.
Closing the app-gap
The web app manifest offers a way to add some configuration information about how a web app should be viewed. But more than this, it offers a hook into the underlying operating system, reducing friction between the OS and the web. One way to look at it is that web apps are becoming more like native apps, and that this helps to reduce the app-gap that is being chipped away by HTML5 and related browser advances. But another way to look at it is that it simply provides tighter and more seamless integration with the OS. It’s not necessarily about web vs native, but about optimising and improving the experience for web. But whatever way you couch it, with the recent implementation of push notifications by browsers, the class of application that can’t be implemented with web technologies just got smaller. Adding web app manifests into the mix blurs the distinction further.
Content images: Jan Persiel, Google Developers
Updated 3rd November 2015 to add section on splash screens.
Leave a Reply