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:

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.

See also:

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?