The W3C is working on multiple documents on moving the core web application platform forward, the primary one being Core Mobile Web Platform. There are also the Closing the Gap task force, the Web and Mobile Interest group, and numerous technical interest groups on dozens of specific topics, from DOM performance, to device hardware APIs and many many more.
These efforts are excellent and clearly important. What’s missing from this discussion is a framing document, something that attempts to motivate at least part of a broader picture. Is performance the only issue? Why do we need these varied technical proposals? Are they adding up to a coherent whole? This short document is treading into opinionated waters, not to create a definitive list of projects but to attempt some guiding principles to help motivate these and future projects.
In the court of public opinion, the war between native apps and web apps appears to be over. Even though the web world is valiantly and consistently improving the web platform, the world seems to have moved on, embracing and rewarding native apps.
But this is only an apparent victory. The world which native won is itself changing. When there was a single dominant device, the downsides of native were minimal. But as that single device grew to multiple platforms, each with multiple devices and screen sizes, the burden of writing a native app has steadily increased.
In addition, what an app is attempting to accomplish is also changing. We’re no longer just flinging birds or vignetting square photos. We’re entering a world where nearly every device, from movie posters to microwaves, can become ‘smart’ and wish to interact with you. Even further, the number of ‘screens’ in our life is growing as well, encouraging new interaction patterns across more than a single fixed screen. We are on the cusp of significant experimentation and new interaction models.
A single definition of a web app is tricky: any attempt to articulate where a web document ends and a web app starts is such a nuanced continuum that it is ultimately not a useful exercise. In fact, the very concept of a web app is changing so rapidly that it’s hard to understand how all of the various pieces under consideration in the W3C fit together as a cohesive whole. We seem to be so focused on how to build web apps that we seem to be ignoring how they will be experienced. However, what should be categorically and emphatically stated is that web apps are NOT and should never be just a ‘web ports’ of iPhone apps, that is aiming far too low in aspiration.
This document is an attempt to break out of this iPhone myopia and discuss how interactive web pages (for lack of a better term) should be experienced. The W3C is exploring numerous technical capabilities but hopefully by calling out some of these new directions, it hopes to coordinate existing activities and encourage new ones. The following list is certainly partial and will change over time but hopefully it encourages further discussion:
Web UX Style 1: Native App replacement
The first interactive style is one which wants to emulate a native app. Even though I just disparaged this just 2 paragraphs above, it is the dominant model today and one which the market currently understands and accepts. This style encapsulates a web page into a package that looks and behaves just like any normal native app. In the user’s eyes, packaged web apps should look and feel nearly identical to native. The web in this case is an implementation technology and the technical plumbing shouldn’t show. As the user concept of a native app is well explored, a web equivalent has several clear requirements. If a web app is appropriately provisioned and vetted, it should be allowed to:
- integrate in the list of apps directly available to the user
- This means that it should show up on that OS’s home screen and be launched just like any other native app.
- install itself from any web page
- As apps can now be installed from the browser, it would make sense to allow web apps to do this same. This implies that the user experience to install a web app should not be just saving a bookmark. Apps should be able to have an ‘install link’ on any web page that starts the safe process of downloading the app package to the device.
- integrate into the the OS task-switcher
- If the user switches from a web app to a native app, such as the contacts manager, they shouldn’t have to switch to the web browser and then switch to the web app. That’s too complicated and confusing. A user should switch between running web apps just as they do with native apps.
- have a full screen experience
- Web apps should be able to start in full screen, just as native apps do.
- open links to external pages in a separate browser
- A web app will most likely be interested on a core user experience and will switch internally between its own pages. However, it should be able to offer links that when selected ‘escape’ to the browser.
- enforce the “singleton” rule
- If the user chooses the web app on the home screen a second time, it should just open up to the currently running instance, not launch a new one.
- operate in the background
- This is likely dependent on the native OS but if at all possible, a web app should be allowed to run in the background. This becomes more important as apps want to process activities such as location, in the background.
- generate system level notifications
- This is just integration with the OS like many other potential services. This is especially important for apps that can run in the background and need to inform the user that something important has changed
There is likely much more to add to this list but the goal is fairly simple: if we are content to mimic native apps, web apps should behave much like native apps on the host device. The user shouldn’t have to navigate to a ‘sub OS’ on their device to launch a separate class of applications, with their own rules.
Web UX Style 2: On demand interaction
Native apps are a snapshot in time. They exist as frozen functionality that is searched for, downloaded, installed, organized, updated and eventually deleted, all by user initiated actions. As the number of smart devices grows, from smart movie posters, to smart museum displays, to smart doorknobs, to even smart toasters, all sorts of devices will be sprouting the potential to interact with the user. The sheer user effort involved in managing native apps will become overwhelming, even if a single OS dominates. If you believe in Moore’s law in any way, it’s clear that the number of devices that require interactivity will grow astronomically. Having a ‘user cached native app’ for each smart device, over time, is a mathematical absurdity. No one is seriously arguing that EVERY web page in the world should be a native app so why would we expect this of smart devices?
This is where the web’s ability to offer interactivity with the click of a link turns into an amazing super power, one that saves us from this complexity. It offers interactivity for nearly zero effort on the users part. This is something native apps can’t hope to achieve and is a clear differentiator in the struggle between native and web apps.
Today the web link and the URL bar are the only ways to summon a web page. However, we’re starting to see how mobile handsets and their ever expanding set of hardware sensors are expanding this capability. QRCodes, as clunky as they are, were the first to offer this ‘outside of the browser’ approach to launching web pages. NFC is very similar, trading proximity for a much quicker experience. This will likely continue through new technologies such as Bluetooth 4 and Wifi Direct.
This ability to ‘summon’ a web page without typing anything at all needs to be explored in future W3C standards and not be left solely to handset makers. A system where smart devices could broadcast a URL so nearby mobile devices could offer it would unlock an interactive ecosystem, effectively carrying the web server model from cyberspace into the real world. Any device could contain a link to a web page offering the ability to control that device. This linking of the real world to the web could be a very transformative and unique capability of web apps. In order for this to take place, the W3C should encourage a wireless discovery service.
There should be a multi protocol standard for smart devices to broadcast a URL. Wifi, WifiDirect, and Bluetooth Low energy are all likely initial candidates. QRcodes roughly accomplishes this but requires a custom app and significant user activity to get the target in focus. NFC is easier and works well but requires the user to physically tap the device. By listening for a wide and expanding list of wireless protocols, the browser can become an agent looking for potential URLs on the users behalf.
The results should be optionally passed through a web service. There are many reasons the immediate results of this discovery service would need to be augmented. For example, it might be useful to add additional results from nearby geo located objects. In addition, as the number of devices found grows, the value of ranking the results increases significantly. The objects found in the discovery service above should be stored in a common format (e.g. json) so any web service could then read and alter that list in an interoperable way.
Web UX Style 3: Multi Screen interaction
Lots of experimentation is going on connecting phones and tablets to interactive television. However, just as WebRTC is enabling so much more than just face to face video, the ability for one screen to interact with another has many deep possibilities beyond just streaming movies. This is a rich new type of interaction that is just starting to uncover its potential.
While the W3C can’t realistically create standards when we are in such an early exploratory phase, it can specify a very simple and basic rendezvous mechanism for web devices to find each other. This doesn’t preclude any experimentation but does significantly encourage the category to be explored further. Possible steps would include:
- Extending the discovery service to web apps
- While the discovery service listed previously is a user service meant to find everything, it should be possible for a web application to offer this choice as well. This would allow the list to be filtered so only targeted/cooperating devices would be matched.
- Exploring a topology of devices and services to encourage common categories
- This likely will be a moving target but starting off with some basic media transport styles such as printer or video display would encourage devices to share their functionality across multiple applications and companies. This clearly needs much deeper thinking but point here is to broach the topic and discuss what topology would be useful.
The goal of this document is to rise above the current alphabet soup of technical standards and create some conjecture and possibly even motivation around how these standards can work together. The web can be so much more that what native apps can do. It can offer interactivity like water, pouring out of any device with nothing but a click. This is the super power of the web and isn’t appropriately appreciated as the key differentiator from native apps.
In a world where companies roll out beautiful fait accomplis, we start to believe that all web products need to be fully formed and mature when we release them. We forget that the delta between Netscape and Gmail was 10 years! It takes time for meaningful systems to evolve. We don’t just need new focused standards but also new experimental standards that encourage exploration.
The web has been on it’s back footing for too long, aspiring to catch up to the legacy of the iPhone native app model. While there is clearly a significant amount of work just to make basic web apps more viable, there are also several things the mobile web can do to encourage a new type of interaction such as offering a model that allows the web to pervade the physical world, allowing anything to have a ‘web page’. In addition, the ability for web based devices to find and interact with each other, both at the user and programmatic level needs to be encouraged. While still experimental, the W3C can at least open the gates and encourage new interaction styles in an open and collaborative manner.
This was previously published on the W3C blog on 28 Aug 2013