Improving the User Experience of Web Applications


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


To compare the various existing application development approaches, two broad perspectives can be taken:

End-user perspective:
How will a development approach provide the best possible user experience?
Content and service provider perspective:
How will the development approach affect their costs and benefits?

This document, based on the analysis of how Web apps currently fare from a user experience perspective, discusses some possible actions that could be pursued by W3C members to reduce Web apps weaknesses and increase their existing advantages.

See also the framework to compare mobile apps development approaches from a provider perspective.

Action plan to improve the User Experience of Web Applications

These are very sketchy ideas that need to be further developed and turned into concrete action plans if and when they're deemed appropriate.

Discovery and acquisition

Searching an app

Increase searchability of apps through better metadata

This is SEO issue.

Reaching an app from physical artifacts (ads, paper magazines, TV screen, product labels)

Enable over the air discovery for Just-in-time interactions

This seems far out into the future. The platform has more immidiate problems.

Reaching an app from on-line interactions (social networks, on-line reviews, etc.)

Promote best practices of URI management for client-side apps.

Paying for an app

Enable simple payments on the Web

Need to describe the limitations of existing solutions.

Downloading an app

First point is already covered by HTTP2. Fixing offline is service workers. 3 is an implementation detail.

Authorizing an app for special privileges

Finding on device and launching

Locating the app launcher

Get browsers/OS vendors to simplify integration of Web apps in OS apps list

Get browsers to better support HTML capabilities for "bookmarking" to homescreen.

Starting the app

The first point presuposes a manifest as a solution. that is not the right way to frame this problem: the manifest may be one solution... there may be other solutions!

Regarding own branding, this should be left up to the author. Splash screens are already supported in the platform (index.html can serve as splash screen).

Waiting for the app to be ready to use

First item is an implementation detail.

Intuitiveness and ease of understanding

Adopting familiar user interfaces

CSS should provide some level of system UI integration?

Browsers already do this through markup. CSS is not the correct layer. Also, this is generally considered bad practice: the experience provided by the application should be unique - not a copy of system ui conventions.

Adopting familiar user interaction patterns

This pressuposes various solutions - it should be generalilzed.

Guiding the user

Smoothness and responsiveness

Navigating through views provided by the app

Promoting workarounds does not address problems in the platform.

Interacting within a given view of the app

Smooth scrolling is independent of events. See, for example, position: sticky.

Obtaining content from the network

Need to work with Web Perf WG on this... in particular with regards to the Resource Priorities spec.

Pushing content to the network

Need to describe use case here. This can be handled in various was depending on the use case.

Adaptability to user access requirements

Making the user interface flexible to different user requirements

Automated or semi-automated testing tools?

Need to flesh this out...

Integrating with the accessibility services on the device

[further analysis required]

This should be handled by markup. Better question is: what is missing from the markup to make this happen?

Sensitivity to context

Determining the context in which the user is

Any critical sensor missing (indoor location via WiFi id? BT4?)? Can we build a more generic sensor API that doesn't work against the user privacy?

Notifying the user of a context-relevant information

Personalization and privacy

Gaining access to private data

Web Intents-like solution?

Protecting user privacy

Immersivity and focus

Managing the whole screen space

Fullscreen API to the rescue?

Separating UI from other apps

Make it possible run Web app fullscreen, in separate browser instance?

Ease of returning to once launched

Finding quickly the list of already launched apps

This is a UX issue.

Waiting for the app to be re-activated

Getting the app back in the state it was left

[Investigate further which states are hard to restore]

Ease of obtaining additional features

Paying for an add-on

Enable simple payments on the Web

Is this in-app payments?

Downloading the add-on

Enable large download optimizations

Covered by HTTP2

Authorizing the add-on for special privileges

Presupposes some special security model.

Ease of maintaining

Updating an app

Covered by HTTP2, service workers.

Retrieving locally stored app data

Filesystem API?

Need use case.

Removing an app

Purging an app configuration and stored data

This is UX problem.

Ease of cross devices usage

Locating a compatible version of the app on the various devices

Reduce incompatibilities across devices.

Acquiring (possibly with payment) the app on these devices

Getting the content / configuration of the app synchronized across devices

Making the app work on several devices at the same time