Manifest format should support some way of including a splash screen

[marcoscaceres]

This feature is at risk. Unless we hear otherwise, this feature will be removed from the specification in the next few months.

Why is this at risk?

In the past, various vendors had expressed an interest in having a splash screen for when an app boots up. However, at least one implementer claims that it's possible to achieve this effect by using background_color + icon members. Additionally, browsers engines are able to boot up in sub 200ms, making it possible for authors to create their own splash screen experiences without needing to rely on this.

Use case

Because of the limited processing capabilities of some devices and the amount of time it takes to initialize a Web runtime, there can be a small - yet noticeably perceivable - delay between when the end-user starts an application and the application actually becoming available and interactive to the end-user.

Depending on the complexity of the application and the processing power of the device, this delay can range from a few milliseconds to a couple of seconds. When applications take more than a few seconds to load, it can be disorienting to end-users as nothing is displayed on the screen; leading to a poor user experience. Native applications overcome this issue by allowing developers to use a media file that is displayed the instant the application is launched. Such a file is commonly referred to as a "splash screen" or "launch image".

[mounirlamouri]

CC people involved in the previous issue: @nhoizey @julienw

[mounirlamouri]

I've been trying to think about that last week and I feel that there are a lot of use cases here. Most people will ask to be able to tweak there splash screen as much as possible but there is a sure thing: we don't want to put HTML and CSS in the manifest. Using a HTML page (linked) wouldn't be efficient.

Also, we have to define what the splash screen is for: it is for the moment between the user tried to start the application and the application is actually started. It can be a second or less when the application is cached. It can be a few seconds if the application has to be loaded from the network.
In both cases, as soon as the application is loaded we should show the index of the application and the splash screen should be hidden. The feature isn't there to replace the splash screens show by games when they load data for example.
The problem with having different magnitude of time between some types of application startups and some others is that some elaborated splash screens might be shown only for a few milliseconds giving a terrible user experience. When we expect the application to get loaded very quickly no splash screen or a plain colour is probably the best thing to do.

As soon as we agree that we can't customize the splash screen in detail, I think we can narrow down the splash screens in two categories:

• an icon shown in the middle of the screen with a background;
• a huge background image.

For the former, we could easily take the best sized icon from the manifest and show it on top of a predefined background colour. It could be based on the icon colours or on the system theme. We could also ask the application developer to define it.
For the later, we should just ask for a background image knowing that it is very hard to get it right because of the different size of screens. The UA will then have to play with resizes and maybe cropping.

I think this is a feature we should keep as UA specific behaviour for the moment. UA could simply do the first proposition: show an app icon on some kind of background if they believe this is a good idea. I believe that this is a good enough solution for the moment and that we might learn more later. The main concern I have is that with performance improving and offline hopefuly getting fixed on the web, we might end up no needing splash screen soon enough and if we need them, we might have a better understanding of what are the use cases.

[nhoizey]

I've had time to think about it since our discussion on sysapps/sysapps#41 and I agree with @mounirlamouri that we need something simple enough to fit most needs.

I'm not comfortable with "the UA [having] to play with resizes and maybe cropping". So, isn't "an icon show in the middle of the screen with a background" just "a huge background image" that is not huge enough to fill the screen? ;-)

As I said in our previous discussion, I'm not comfortable either with the UA chosing a solid background color alone, "based on the icon colours or on the system theme".

As a webapp developer, I would then like to have this:

• If I set nothing, the "best sized icon from the manifest" on a background set by the system theme (may be a gradient instead of a solid color)
• I can set my own list of splash icons, from which the "best sized" is chosen by the UA
• I can set a solid color for the background

My understanding is that "best sized" means something like "the biggest that fits into 90% or the width and height of the viewport", to give it some padding…

[marcoscaceres]

@nhoizey, what concerns do you have about the UA proportionally resizing the splash screen?

I agree that the user should get to specify the BG color for the start up.

(adding this here as we can probably reuse some of the text: https://dvcs.w3.org/hg/nativeapps/raw-file/tip/splashscreen/Overview.src.html)

[nhoizey]

@marcoscaceres I have more concerns with "cropping" than with "resize", actually… ;-)

[marcoscaceres]

I agree. Cropping would be bad.

The RICG looked quite a bit into resizing by browsers and found the
algorithms to be good from a design/aesthetic POV. Unfortunately, I don't
have a reference; but the were many blog posts about it.

[marcoscaceres]

We've (@mounirlamouri and I) done a whole bunch of investigation into this over the last month or so, and from Mozilla's point of view, we don't need splash screens. There is too much variance in what developers need and using HTML is perfectly well suited to this task: you can adapt it to layout, you can animate it, it's accessible, etc.

The challenge for both developers and browser vendors is to have the runtime pop up quickly enough to be able to render a HTML page (in around 100ms - FireFox OS is able to do this, FWIW).

[marcoscaceres]

Closing this bug. If anyone disagrees, please reopen for further discussion.

[laurentperez]

Hi

I'd like to reopen the discussion on this. We are an UA vendor : our HTTP proxy translates custom data-* attributes into web UI components.

Currently there are at least 3 different implementations of a splash screen :

• phonegap documents the plugin element of a widget together with navigator.splashscreen : http://docs.phonegap.com/en/2.2.0/cordova_splashscreen_splashscreen.md.html. However, support is coming for the standard element : https://issues.apache.org/jira/browse/CB-3571
• apple uses link rel="apple-touch-startup-image" href="Default-Landscape.jpg" media="screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:landscape)"
• rim uses a rim:spash element : https://developer.blackberry.com/html5/documentation/rim_splash_element.html

It is unclear for us if we go the widget splash way (see https://dvcs.w3.org/hg/nativeapps/raw-file/tip/splashscreen/Overview.html) or manifest way.

I understand the spash is doable in pure web without UA assistance. Apple is using their own standard, but we like true standards. Not every developer has the JS skills to wait for the readiness of their content and hide a custom splash element, quickly shown before everything else.

What do you think ?

[marcoscaceres]

(I'm reopening so this doesn't get lost - but I'm away on vacation till next month)

[mounirlamouri]

A library/framework could work very well. Not speaking about the fact that a splash screen is actually pretty easy to implement.

[laurentperez]

On Firefox Beta 24, on Android, if you have in your manifest : "icons": {"128": "icon.png"}

Then when you first run the app, you'll get a zooming animation of the icon on an orange/yellow background, with a spinning loader at the bottom. So there's some sort of splash mechanism, but you won't get this on the latest Firefox OS simulator.

If I want to override the zoom, change the background or use a progress bar instead of a spinner, I can't. Phonegap exposes navigator.splashscreen.show() and hide() (see http://simonmacdonald.blogspot.fr/2012/04/phonegap-android-splashscreen-just-got.html).

If I could use {splashscreen: "splash.html" } in the manifest and dismiss it like Phonegap does, it would be nice. I agree HTML is well suited for this, I could use media queries in the splash.html page to display a retina friendly image, use another one in landscape, etc.

On a side note, Tizen uses the widget spec (https://developer.tizen.org/downloads/sample-web-applications/load-web-app-tizen-sdk/sample-config.xml-file), but unlike Blackberry with a rim:splash extension, does not support splashscreens yet : https://developer.tizen.org/forums/web-application-development/splash-screen

[marcoscaceres]

Will try to investigate what we would need as part of w3c-webmob/installable-webapps#36 in 2014. However, I'm inclined to defer splash screens to future versions of the spec.

Would anyone object to that?

[anssiko]

@marcoscaceres We are experimenting with a proposal with @kenchris, should be able to share it with the group soon. Perhaps we can keep the proposal in its own branch as an experimental feature, and after we have implementation experience consider merging it to future versions of the spec?

[kenchris]

@anssiko I think that is a good idea. Let's finish up our proposal.

[marcoscaceres]

ok, closing this and we can reopen for v2

[anssiko]

We've shipped an experimental implementation of the "launch screen" feature in Crosswalk:

https://crosswalk-project.org/#documentation/manifest/launch_screen

We'll now gather feedback from web developers, and evaluate how the feature is used in real-life to help us refine the proposal. And if there's developer pull and interest among other implementers, we can then think about the standards track.

[marcoscaceres]

Thanks @anssiko! Looking forward to getting your feedback.

[laukstein]

@pornel, sizes: "all" proposed in #407.

[jakearchibald]

@pornel

We'd like to create a seamless experience where splash screen looks the same from the first render by Chrome

I agree with this goal, but I don't think a list of image urls is the way to achieve it, especially given the variety of resolutions.

The best answer I have is an html page that the browser runs, and on onload rasterises it at all the resolutions it needs it (presumably one for each orientation).

[marcoscaceres]

The best answer I have is an html page that the browser runs, and on onload rasterises it at all the resolutions it needs it (presumably one for each orientation).

Agree. The presupposition being extremely fast browser boot times (i.e., sub 100 or 200ms). It seems Chrome is getting there, and we were there with FirefoxOS before it got killed.

[marcoscaceres]

Ok, splashscreens are 410.

[jakearchibald]

The presupposition being extremely fast browser boot times

Wait, are we talking about the same thing? I'm talking about the browser caching and caching bitmaps at add-to-homescreen time, then displaying them at next launch while the browser boots up.

[marcoscaceres]

Wait, are we talking about the same thing? I'm talking about the browser caching and caching bitmaps at add-to-homescreen time, then displaying them at next launch while the browser boots up.

Yes, but that still presupposes that the browser engine will boot up quickly. The point of the splash screen was to mitigate the wait time between the browser booting up and first paint - which for some engines was more than 1.5 seconds. On engines that do take ages, is currently handled through the combination of icons + background_color.

If an engine can cold start and first paint fast enough, it doesn't need to show anything the icon + background color - and can hence show its own HTML splashscreen.

[jakearchibald]

Pretty sure we're talking about different things.

As far as i can tell, you're talking about an HTML splash screen when the app launches, which doesn't need anything from the manifest, as it's just the app.

I'm talking about a special HTML resource, specified in the manifest, which the browser uses to generate bitmap splashscreens at the point of "install". One of these bitmaps is then displayed as the splashscreen at launch time, while the browser loads.

[jakearchibald]

My idea isn't needed if the browser can get to first render, from cold, in 100ms

[marcoscaceres]

Pretty sure we're talking about different things.

No, no... ok, yeah :)

As far as i can tell, you're talking about an HTML splash screen when the app launches, which doesn't need anything from the manifest, as it's just the app.
I'm talking about a special HTML resource, specified in the manifest, which the browser uses to generate bitmap splashscreens at the point of "install". One of these bitmaps is then displayed as the splashscreen at launch time, while the browser loads.

Ok, yeah... Not talking about that. I would be against such a thing... it's would be super complicated to get right and know when to take the screenshot... like a selfie, but for web apps :)

My idea isn't needed if the browser can get to first render, from cold, in 100ms.

I'd rather we (browsers) get to the above.

[jakearchibald]

The timing would be window.onload - but I agree we shouldn't explore it as an option unless quick browser load time become unattainable.

[laukstein]

@marcoscaceres, you forgot to remove

manifest/index.html

Lines 153 to 156 in 51ebee6

	"splash_screens": [{
	"src": "splash/lowres",
	"sizes": "320x240"
	}, {

"splash_screens": [{
    "src": "splash/lowres",
    "sizes": "320x240"
  }

[marcoscaceres]

D'oh. PR?

Sent from my iPhone

On 5 Apr 2016, at 7:55 PM, Binyamin Laukstein notifications@github.com wrote:

@marcoscaceres, you forgot to remove

manifest/index.html

Lines 153 to 156 in 51ebee6

	"splash_screens": [{
	"src": "splash/lowres",
	"sizes": "320x240"
	}, {

"splash_screens": [{
"src": "splash/lowres",
"sizes": "320x240"
}
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[laukstein]

D'oh. PR?

@marcoscaceres, you removed all documentation related to splash_screens except the mentioned in example https://w3c.github.io/manifest/#example-manifest

[anssiko]

@marcoscaceres PR #445.

Sorry about the monkey patch, my editor (TextMate FTW!) still does not like it.

[marcoscaceres]

I'm going to buy you a copy of Sublime.

On 5 Apr 2016, at 9:43 PM, Anssi Kostiainen notifications@github.com wrote:

@marcoscaceres PR #445.

Sorry about the monkey patch, my editor (TextMate FTW!) still does not like it.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[julienw]

The timing would be window.onload - but I agree we shouldn't explore it as an option unless quick browser load time become unattainable.

The experience in Firefox OS showed that this is not really good. For some apps we'd have the final state, some other apps would have some waiting state, some other apps would be in a "loading but not finished loading but no splashscreen" state. The solution is a new "event" (or you can call that an API) that the app could send (or call).

[kornelski]

I like the idea of browser screenshotting a splashscreen in HTML format — it'd be possible to create responsive splash screens with correct font rendering. I hope the browser could prepare such splash screens immediately (in background) when the app is added to the homescreen, so there's no other splash-placeholder screen before the splash screen.

I think it should be a screenshot from a separate dedicated resource (/splash.html), and not a screenshot from start_url, because optimizing app for both fast, fully asynchronous startup and showing of screenshotable splash at a time of specific event (like the load event) is complicated.

[laukstein]

the idea of browser screenshotting a splashscreen in HTML format

How do you imagine it behavior animated splashscreen? The icon itself may be animated image.

[jakearchibald]

I hope the browser could prepare such splash screens immediately (in background) when the app is added to the homescreen

That was what I was thinking. It'd create screenshots of both orientations too.

I think it should be a screenshot from a separate dedicated resource (/splash.html)

Agreed, although they may point at the same resource, which would work for some things like https://jakearchibald.github.io/svgomg/

[jakearchibald]

How do you imagine it behavior animated splashscreen?

I don't think that should be supported.

[marcoscaceres]

I don't think that should be supported.

And this is the problem. If you look at the examples from #9 (comment), most of those do have some animated aspect to them... e.g., twitter's "bounce zoom in", or LinkedIn's "exciting" slide down to reveal, and other fancy fades and transitions... it's all part of the UX the web would be denying users and developers by using a screenshot solution.

[jakearchibald]

Right, but the screen shot could be the first frame of the animation