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.
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
- Enable large download optimizations
- Fix offline
- Integrate off-line Web apps in list of available OS apps
First point is already covered by HTTP2. Fixing offline is service workers. 3 is an implementation detail.
Authorizing an app for special privileges
- Allow Web apps to manage group of permissions?
- Enforce consent-through-interaction pattern?
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
- Use manifest as a way to promote Singleton enforcement?
- Saved Web apps should be started under their own branding (fullscreen, optional splash screen)
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
- Provide better hooks for optimizing start time (e.g. for scripts loading, assets loading)
- Promote best practices
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
- More DOM Events to match specific patterns
- Indie UI should help
This pressuposes various solutions - it should be generalilzed.
Guiding the user
Smoothness and responsiveness
Navigating through views provided by the app
- Get browsers to disable it under the right conditions (à la Chrome)
- Promote work-arounds (e.g. FastClick)
Promoting workarounds does not address problems in the platform.
Interacting within a given view of the app
- Provide better hooks for managing scrolling (e.g. Scrolling events)
- Promote best practices and libraries
- Provide more control on memory management?
Smooth scrolling is independent of events. See, for example,
Obtaining content from the network
- Background network operations.
- Priority handling in network ops.
Need to work with Web Perf WG on this... in particular with regards to the Resource Priorities spec.
Pushing content to the network
- Background network operations
- Priority handling in network ops
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
- Progress on Push API
- Look into registering wake-up for Web apps (on top of notifications?)?
Personalization and privacy
Gaining access to private data
Web Intents-like solution?
Protecting user privacy
- Common strategy toward iframe handling?
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
- Allow singleton-enforcement for Web apps
- Include Web apps in tasks list
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
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
- Standardized identity management
- Easy synchronization for Web dbs?
- Discovery of other nearby devices
Making the app work on several devices at the same time
- UX guidance on cross-device apps