Re: [w3c/manifest] Richer splash screen backgrounds (#589)

Hi all, improving splash screen is one of the things I’ve been looking into. The direction we’re pursuing in Chromium is HTML splash screen screenshotted by the browser, which was discussed widely in #9. @mgiuca is on board and willing to make the necessary spec changes.

**Proposed spec change**

Add an optional manifest attribute *splash_screen_url*. UA may show this page while Web App is loading. A static image (screenshot) of splash screen page may be cached by UA for performance.

Advantages:

- A lot of flexibility for design (see [wall of splash screens](https://github.com/w3c/manifest/issues/9#issuecomment-105282660) from #9), all icons, backgrounds and fonts are supported.
- Allows reusing the same graphics for all types of splash screens. Eliminates the problem illustrated by Twitter PWA displaing 2 different splash screens on Chrome - one native, one web-based ([diagram](https://drive.google.com/file/d/0B5jFBoVFZy_pNmlOWnlITnhUSjQ/view?usp=sharing)).
- Pixel-perfect transition between splash screen and web content allows animating the splash screen away in web content (mentioned as potential requirement in [this comment on #9](https://github.com/w3c/manifest/issues/9#issuecomment-206122106)).
- Uses technologies familiar to web developers.
- Simple declaration in manifest.
- UA flexibility of how it’s treated (e.g. always displayed by renderer, screenshotted ahead of time, or cached on first launch).

Disadvantages

- All implementations screenshotting the splash_screen_url to static image cannot show developer-controlled animations, e.g. progress bars and spinners.

Open Questions:

- What should be the mechanism for refreshing cached splash screen image once it’s updated by developer? Could be a JS API, UA checking for updated to manifest file or splash screen file.

**Viable implementation**

In Chromium for Android we found that screenshotting the splash screen page off-screen at A2HS time is difficult for various graphics related reasons. We therefore plan to navigate to it on first launch to grab the image. In the meantime we would fill the screen with background_color. On following launches image of the splash_screen_url would be shown. The splash screen for portrait and landscape would be snapshotted on the first launch in given orientation.

Some problems with such implementation:

- Resizeable windows can cause multiple images to be generated. On desktop environments web rendering engine starts fast enough to make splash screens redundant, so it’s not effectively an issue. On some mobile platforms (e.g. Android) users can divide their screen between apps, we will either fall back to another mechanism or snapshot special versions for split screen.
- If the first Web App launch is offline and the splash screen page has not been put into service worker cache, UA needs to fall back to another mechanism, e.g. background_color or icon-based splash screen

**Demo**

See the [recording](https://drive.google.com/file/d/0B5jFBoVFZy_pUE9OaXRyVU1jdTQ/view) of the UX provided by the early prototype in Chromium. This demo focuses on the smooth transition from the splash screen to web content with the animation rendered by the start_url page. Recorded Web App is based on the [Material Design Launch Screen example](https://material.io/guidelines/patterns/launch-screens.html) and can be found [here](https://piotrswigon.github.io/pwa-demo/dark-splash/).

What is happening on the first launch:

1. UA fills the screen with background_color and navigates to splash_screen_url.
1. Once splash_screen_url has loaded, UA shows it to the user, snapshots it and stores the resulting image.
1. UA navigates to start_url.
1. Page served from start_url [detects standalone mode](https://developers.google.com/web/updates/2015/10/display-mode) and renders splash screen hiding animation on onload.

What is happening on the second launch:

1. UA uses stored image of the splash_screen_url while it starts.
1. Web content is shown on the first paint. Web page is designed to look the same as the stored splash screen image for smooth transition.
1. Once page loads, Web App runs the splash screen hiding animation.

Worth noting that the UX of the first launch is relatively smooth - filling the screen with background_color is not intrusive.

We discussed this between few folks in Chromium and feel that this approach provides good balance of benefits to issues and addresses existing pain points well.

Feedback would be greatly appreciated.

Some folks who discussed this problem in #9:
@kenchris 
@anssiko 
@marcoscaceres 
@jakearchibald 
@mounirlamouri 
@slightlyoff


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/589#issuecomment-323232119