Web Apps User Experience Gap Analysis

Status

This is a draft, work-in-progress analysis derived from the “Closing the Gap with Native” Headlight task force.

Introduction

To compare the various existing mobile apps development approaches, two main perspectives can be taken:

from the end-user perspective: how well the said development approach will make it possible to provide the best possible user experience;
from the content and service provider perspective: how well the said development approach will optimize their costs and benefits.

This document applies the model developed separately to analyze a give mobile app development approach from the end-user experience perspective to the kind of user experience Web apps allow currently.

Web Applications User Experiences Strengths and Weaknesses

Distinguish characteristics of browser-based apps from Web-OS apps in the table

Strength/Weakness for the user experience of Web apps on mobile
User experience parameter	Strength	Weakness
Discovery and acquisition
Searching an app	Long history of search on the Web Benefits of links to rank / discover	No clear delineation (yet) of mobile-optimized content difficulty of indexing non text-based app Users don't necessarily associate Web search with apps discovery
Reaching an app from physical artifacts (ads, paper magazines, TV screen, product labels)	URLs make it easy (and can be turned into easier forms)	No good way to discover "over the air"
Reaching an app from on-line interactions (social networks, on-line reviews, etc.)	Links and no-installation make it much easier	Pure client-side JavaScript don't necessarily deal well with URIs
Paying for an app	Users aren't constrained to a single payment processor	No easy way to integrate "one-click" payment
Downloading an app	For simple apps, accessing an app is equivalent to downloading it	For apps with larger needs, it is difficult to defer the download of larger assets to better network conditions While offline is possible, it's mostly broken Users don't necessarily expect or understand they can use a Web apps while disconnected
Authorizing an app for special privileges	Privileges get granted when they're needed Many privileges get granted implicitly through user interactions (e.g. selecting a file)	Apps that require many privileges create a storm of prompts Impossible to know beforehand what an app will be asking Hard to track what privileges an app has obtained
Finding on device and launching
Locating the app launcher	Bookmarks can serve as app launchers	Bookmarks are hard to manage Users don't know how to save a bookmark on their home screen Depending on the OS, the OS app list cannot include Web apps bookmarks
Starting the app		As a Web app runs in the browser, if the browser isn't running, the actual app that gets started is confusingly the browser If the Web app is already running in the browser, hitting the bookmark won't go back to the existing tab (no singleton enforcement)
Waiting for the app to be ready to use		Starting the browser makes starting the app that much longer Optimizing start time for Web apps remain difficult
Intuitiveness and ease of understanding
Adopting familiar user interfaces	If the user is familiar with a Web app on other devices, re-using the same look and feel on mobile is allowed and relatively easy	Providing a UI that integrates well with the OS UI can be challenging, impossible in some cases
Adopting familiar user interaction patterns	Users are broadly familiar with Web interactions patterns (back button, reload, links, etc)	Integrating with the OS interaction patterns can be challenging, impossible in some cases Browsers steals interactions that apps would want to use(zooming, swiping)
Guiding the user
Smoothness and responsiveness
Navigating through views provided by the app		300ms for touch/click events make Web apps feel sluggish
Interacting within a given view of the app		Scrolling with heavy content is very hard to make smooth JS Garbage Collection creates unpredictable spike of CPU JavaScript slower than native code for CPU intensive operations CPU intensive operations run in a separate thread (via Workers) don't have access to all content and APIs from main thread
Obtaining content from the network		Impossible to defer large downloads to better network conditions Impossible to group network requests to optimize latency/battery/network usage Limitations to the type of protocols that can be used
Pushing content to the network		Impossible to defer large upload to better network conditions Impossible to group network requests to optimize latency/battery/network usage Limitations to the type of protocols that can be used
Adaptability to user access requirements
Making the user interface flexible to different user requirements	Web browsers provide more flexibility by default	User interfaces are not often tested in a wide enough set of conditions to cater for that flexibility
Integrating with the accessibility services on the device	Web has a long history of accessibility integration	Mapping with on-device accessibility features is likely to be lesser than what can be obtained from platform-specific code?
Sensitivity to context
Determining the context in which the user is	Users are in control of what the app can determine	Browsers don't have access to all sensors available on a given device, and requires specific permissions to get it in some cases
Notifying the user of a context-relevant information		No access to Push notifications No way to wake up an app while off-line depending on some environment parameters (e.g. location)
Personalization and privacy
Gaining access to private data		For local data, only possible on an ad-hoc basis Require prompting the user one way or another
Protecting user privacy	Users are always in control before data is first shared	Hard to track with whom what data has been shared Third party inclusion muddies this further
Immersivity and focus
Managing the whole screen space		Browser chrome by default prevents fullscreen
Separating UI from other apps		Browser chrome can interfere Other tabs can interfere “External” links either remove the current app, and move it to a hard-to-access background tab
Ease of returning to once launched
Finding quickly the list of already launched apps		Web app not in the list of running Apps Hitting a bookmark starts a new "instance" instead of returning to existing one Finding existing running instance among other tabs is difficult
Waiting for the app to be re-activated		if the browser is not running, overhead of browser start up (without app branding)
Getting the app back in the state it was left		Restoring the state of the app (e.g. scrolling location) not always trivial?
Ease of obtaining additional features
Paying for an add-on	Users aren't constrained to a single payment processor	No easy way to integrate "one-click" payment
Downloading the add-on	If needs little additional content, this is more streamlined than having to go through an app store	for add-ons with larger needs, it is difficult to defer the download of larger assets to better network conditions
Authorizing the add-on for special privileges	Since privileges are granted on usage (rather than up front), this is more streamlined in Web apps	Risks of storm of prompts
Ease of maintaining
Updating an app	App automatically up-to-date when on-line
Retrieving locally stored app data		Web app data is not easily retrieved outside of the browser (is it worse for encrypted storage?)
Removing an app	For apps without offline components, no action needed	Current UIs to manage offline Web apps are hard to get at, hard to use, and not integrated in OS apps management
Purging an app configuration and stored data	Browsers make it possible (not clear this is so for native apps)	Browsers make it hard
Ease of cross devices usage
Locating a compatible version of the app on the various devices	availability of a compatible version much likelier due to cross-device nature of the Web URLs make locating it trivial	Interop issues across devices might make experience of a given Web app very poor on some devices
Acquiring (possibly with payment) the app on these devices	Apps don't have to be paid multiple times (depending on provider's policy) No need to configure / maintain the app on the various devices
Getting the content / configuration of the app synchronized across devices	Federated identity is built for Web browsers	Limited access to discovery-by-proximity systems
Making the app work on several devices at the same time	One URL, one app

What's missing from Scott's analysis?

Where does security fit in this model? In general, how to make Enterprise stuff in this view?

How about identity management? Native apps are also growing in this space

Any lessons from Why mobile web apps are slow?