Scott Jenson, a well-known UX designer and creative director
with a specialty around mobile phone and consumer electronics, was
involved in the
W3C Closing the Gap task force, and shares here some of his
thoughts on what mobile needs from the Web for new user
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
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
- 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
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
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
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
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
Exploring a topology of devices and services to encourage
- 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
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.