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.
See also:
- Proposals to reduce the UX gaps of Web applications
- Framework to compare mobile apps development approaches from a provider perspective
Web Applications User Experiences Strengths and Weaknesses
Distinguish characteristics of browser-based apps from
Web-OS apps in the table
User experience parameter | Strength | Weakness |
---|---|---|
Discovery and acquisition | ||
Searching an app |
|
|
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 |
|
Authorizing an app for special privileges |
|
|
Finding on device and launching | ||
Locating the app launcher | Bookmarks can serve as app launchers |
|
Starting the app |
|
|
Waiting for the app to be ready to use |
|
|
Intuitiveness and ease of understanding | ||
Adopting familiar user interfaces |
|
|
Adopting familiar user interaction patterns | Users are broadly familiar with Web interactions patterns (back button, reload, links, etc) |
|
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 |
|
|
Obtaining content from the network |
|
|
Pushing content to the network |
|
|
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 |
|
|
Personalization and privacy | ||
Gaining access to private data |
|
|
Protecting user privacy | Users are always in control before data is first shared |
|
Immersivity and focus | ||
Managing the whole screen space | Browser chrome by default prevents fullscreen | |
Separating UI from other apps |
|
|
Ease of returning to once launched | ||
Finding quickly the list of already launched apps |
|
|
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 |
|
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 |
|
|
Getting the content / configuration of the app synchronized across devices |
|
Limited access to discovery-by-proximity systems |
Making the app work on several devices at the same time |
|
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?