WICG / WICG/install-element

App Downloads tied to Installation

Open
#27 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
21
Forks
4
Avg merge
3d 18h
Merged PRs (30d)
4

Description

Currently the story around PWA installation and offline access is a bit weird, and I would assume confusing for many users. On most platforms installing a PWA is just adding a shortcut and is not related to working offline or otherwise downloading or caching app assets. Web developers can choose to download app files when the page first loads, when the PWA is "installed" (in Chromium), when the user interacts with custom download/cache UI, etc. This is somewhat akin to the traditional way of installing apps on Windows, where each application has its own different installation/download process. That method has rightfully been considered inferior in terms of user experience to the model of application stores and their 1 (or few) click install and download. In the typical app store model, installation and download of core app code and assets are a single unified operation, creating consistency and thus perceived reliability.

The install API and install element represent an opportunity to bring this improved user experience to PWAs. Of course, some PWAs are online only and may not want to download or cache anything as part of installation, so such a hypothetical alteration should be optional but encouraged for web devs.

The core requirements are to provide a standardized way for the PWA being installed to start download of assets and to report download progress to the install API or element. Installation would then be delayed until the download has finished. This could perhaps be done similar to how service workers handle fetch and sw install with an event which waits until work is finished. Providing a way to report download size ahead of time would also be important, but I'm not sure if that would be better placed with install API or a manifest value.

A change this would bring to the install element is instead of 2 states, Install -> Launch, it could be 3 states, Install/Download -> Downloading (cancel) -> Launch. The download progress could be displayed inside the install element. This is the basic pattern seen across almost all native app stores.

This paradigm could be deferred to a possible future v2 of the API. While true, I believe that would be missing out on the improvement to the user experience provided by a standardized coupling of installation and downloading of PWAs. Regardless I think the future possibility should be considered in the design of the current version.

(Updated from #MicrosoftEdge/MSEdgeExplainers/issues/1092)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the install API and install element proposal, then compare its current two-state flow with the service-worker fetch and install patterns mentioned in the issue. Define whether installation should support asset-download initiation, progress reporting, cancellation, and a manifest-provided size before proposing a design for the three-state flow.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.