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 https://github.com/w3c-webmob/installable-webapps/issues/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.

[marcoscaceres]

Moved to V3

[marcoscaceres]

@anssiko do you have any feedback on the splashscreen usage since you guys shipped?

[anssiko]

@marcoscaceres I'm not aware of any significant feedback that would motivate us raising the priority. I suggest we keep this in the V3 / future work bucket.

Optimally, SW improves the startup experience enough (beyond the first start when the cache is primed), so that this would not be needed at all.

[marcoscaceres]

I'm inclined to close this. We can revive again in the future once we see how the manifest gets used in the wild.

[anssiko]

WFM. Thanks for triaging the issues.

[marcoscaceres]

There is some renewed interest in this coming from potential implementers.

[anssiko]

I'll check whether there has been more recent feedback on the launch screen feature in Crosswalk.

[anssiko]

Quick poll result: most of our users seem to be using the Cordova splash screen plugin: https://github.com/apache/cordova-plugin-splashscreen/blob/master/doc/index.md

[kenchris]

Which is due to most of our users using Crosswalk with Cordova integration and in that scenario that is the only thing they can use :-)

[marcoscaceres]

On March 6, 2015 at 8:28:59 PM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

Which is due to most of our users using Crosswalk with Cordova integration and in that
scenario that is the only thing they can use :-)

We can probably learn a lot from Cordova, like adding the minimum duration before removing the splash screen.  

[mounirlamouri]

How are Crosswalk applications handling the different screen sizes?

[anssiko]

@mounirlamouri For the background image, we're using the 9-patch image method. Android uses something similar for stretchable bitmaps, see http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch

[marcoscaceres]

Ok, there are two solutions here I can think of... 

1. we support patch images, as per Android: from playing around, it appears that patch images are just PNGs with a 1px transparent border around the image. In that border, black pixel lines indicate what the stretchable areas are (you can have patterns like: _   __ __). Android uses a .9.png file extension as the way to tell the OS that this is a 9-patch. 

So, in the manifest, we would also provide a member to say that it's a nine-patch image: 

{
   splash: [{"src": "foo.png", "BikeShedMyName": "patch"}]
}

When patch markers are missing, we just use, say, 30 by 30px (or some sensible default).

BikeShedMyName could be "align" or "display" or something. 

1. we support CSS border-image syntax. This seems overly complicated tho, because values relate to the rest of a stylesheet, so it's probably not even possible to support 2.  

So, my vote is just do 1: it's simple and straight forward :)

On March 9, 2015 at 7:05:11 AM, Anssi Kostiainen (notifications@github.com) wrote:

@mounirlamouri For the background image, we're using the 9-patch image method. Android
uses something similar for stretchable bitmaps, see http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch

---

Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/9#issuecomment-77834657

[kenchris]

You don't really need to hardcode the patching in the image files, it could very well be specified in markup

[kenchris]

How does 1 allow you to define how to scale the patch areas? like stretch, repeat etc? It probably also won't work with any lossy format like jpeg

[marcoscaceres]

Markup? you mean like option 2? But then we would be recreating what CSS does :(  

On March 9, 2015 at 8:40:50 AM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

You don't really need to hardcode the patching in the image files, it could very well be
specified in markup

---

Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/9#issuecomment-77845920

[marcoscaceres]

On March 9, 2015 at 8:43:27 AM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

How does 1 allow you to define how to scale the patch areas? like stretch, repeat etc? It
probably also won't work with any lossy format like jpeg

Yes, this is true. It's a pretty cheap solution restricted to .png (and maybe .webp), probably doesn't work with vectors either. 

[kenchris]

Would it be too bad? like

"image.png 30px stretch 30px stretch 20px repeat 20px repeat"

I guess the image would work, but it would then only work with non-lossy formats like PNG (WEBP?)

[anssiko]

I would prefer not to reinvent CSS for launch screen, nor put CSS in JSON. Vote for option 1 to address the most common use case first, make it dead simple, while ensure it is extensible to allow experimentation and future extensions.

We could just recommend people to use a lossless format. That should be obvious for most web developers anyway.

I could see how we might get bonus points if developers would be able to use their existing 9-patch image assets. If there's a de facto format for it, then we should embrace it assuming no obvious issues or concerns with it.

[marcoscaceres]

On March 9, 2015 at 8:48:12 AM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

Would it be too bad? like

"image.png 30px stretch 30px stretch 20px repeat 20px repeat"

Personally, I think it's better just to encode this information directly in the image file. 

However, the above would be simple to parse so long as we don't combine URL and stretching information together.

I guess the image would work, but it would then only work with non-lossy formats like PNG
(WEBP?)

Yeah, that's the tradeoff. However, we would get all those 9-patch images already being used on Android for free. 

Maybe there is a third option of adding "auto" to the patch parser above.  

[kenchris]

@anssiko you need to be able to rely on the drawn lines :-) lossy formats will not make that possible

[anssiko]

I guess we'd be fine mandating the use of PNG since it AFAIK addresses all the known requirements, has a spec blessed by ISO/IEC and W3C, and is the format used by the native platforms for the same purpose.

[nuxodin]

What about putting a html-document as the splash-screen url?

splash: "splash.html"

And maybe, the implementor will cache this document as a static image? But, hm, this will make animated gifs impossible...

2015-03-09 14:09 GMT+01:00 Anssi Kostiainen notifications@github.com:

I guess we'd be fine mandating the use of PNG since it AFAIK addresses all the known requirements, has a spec blessed by ISO/IEC and W3C, and is the format used by the native platforms for the same purpose.

— Reply to this email directly or view it on GitHub https://github.com/w3c/manifest/issues/9#issuecomment-77849745.

Freundliche Grüsse Tobias Buschor

shwups GmbH Talstrasse 1 9000 St. Gallen

+41 76 321 23 21 shwups.ch

[anssiko]

@nuxodin You mean, create the 9-patch image from a snapshot of the HTML page? Or just create a fixed sized splash screen in landscape and portrait? That would not work e.g. on desktop where the window can be resized while the launch screen is being displayed. Also, you may have multiple monitors of different resolutions or aspect ratios.

There are some implementability concerns with using an HTML document. For example, what if some of the resources needed to render splash.html do not load or load too slowly, or you get 404? Should we check the splash.html for updates, if so, how often?

Someone might also abuse this, for example, display an ad once in a while instead of your usual splash screen.

What is the use case, what extra flexibility do you need that is not provided by the static 9-piece image?

[marcoscaceres]

There are some implementability concerns with using an HTML document. For example, what if some of the resources needed to render splash.html do not load or load too slowly, or you get 404? Should we check the splash.html for updates, if so, how often?

@nuxodin : Yes, this is basically the whole point: on some OSs, booting up the webview is just too slow. Otherwise, you would not need the splashscreen at all. The index.html would serve just fine (e.g., on FxOS, we don't need splash screens because we can get a webview up in 200ms). This is why we originally rejected adding splash screens to this spec. Maybe Moore's law will allows us to overcome this limitation in the future.

[nuxodin]

Or just create a fixed sized splash screen in landscape and portrait?

Yes, snapshot of it.

That would not work e.g. on desktop where the window can be resized while the launch screen is being displayed. Also, you may have multiple monitors of different resolutions or aspect ratios.

On desktop, it should be ok loading the cached splash-screen-html without making a snapshot. But i see the problem...

Should we check the splash.html for updates, if so, how often?

On installing the web-app and on changing the last-modified of the manifest (or the version?)

What is the use case, what extra flexibility do you need that is not provided by the static 9-piece image?

HTML / CSS is well known by all webdevelopers, the 9-piece image is new mechanism developers have to learn.

2015-03-09 16:31 GMT+01:00 Marcos Caceres notifications@github.com:

There are some implementability concerns with using an HTML document. For example, what if some of the resources needed to render splash.html do not load or load too slowly, or you get 404? Should we check the splash.html for updates, if so, how often?

@nuxodin https://github.com/nuxodin : Yes, this is basically the whole point: on some OSs, booting up the webview is just too slow. Otherwise, you would not need the splashscreen at all. The index.html would serve just fine (e.g., on FxOS, we don't need splash screens because we can get a webview up in 200ms). This is why we originally rejected adding splash screens to this spec. Maybe Moore's law will allows us to overcome this limitation in the future.

— Reply to this email directly or view it on GitHub https://github.com/w3c/manifest/issues/9#issuecomment-77876134.

Freundliche Grüsse Tobias Buschor

shwups GmbH Talstrasse 1 9000 St. Gallen

+41 76 321 23 21 shwups.ch

[slightlyoff]

Starting up a renderer process in all chromium-derived runtimes can require multiple process starts. We need to paint faster than that. We must allow an image. If a URL, it should be a URL that could be run once on the device, snapshotted, and re-rastered at next start without renderer startup.

[marcoscaceres]

HTML / CSS is well known by all webdevelopers, the 9-piece image is new mechanism developers have to learn.

That's not true. CSS border-image has been around for many years, tho it never found much use. Also, it's not like it's a huge burden to learn, plus there are a lot of tools that easily allow you to make 9-patch images (both on the web and offline - including any off the shelf graphics program). The benefit is also that we don't need to introduce any new image format.

[mounirlamouri]

A feel that we are going in circles with this discussion.

• We can't use a plain image because it would require cropping or image magics that we can't really rely on browsers to do;
• Opening an HTML page would fire up new processes which will make the splash screen slowing down the application startup;
• Making a snapshot of an HTML page will require static page but developers want to do progress bars and stuff - also, it come with the problem of the snapshot happening at the "wrong time";
• Other solutions a freaking complex (9 images?!).

Can we instead expect UA to build a splash screen from the information already in the Manifest? The icons, theme_color, name or even short_name sound like good information to build a splash screen.

We could add in the Manifest a hint to ask the browser to show a splashscreen (though, I'm not entirely convinced) but then, I wonder, when do the splashscreen hides? The load event is late and unreliable. Other events like DOMContentLoaded might be too early. What does Cordova or Firefox OS do?

[raucao]

What does Cordova or Firefox OS do?

Firefox OWAs on Android use the supplied icon and extract the main color from it to use as background color I believe.

With Cordova you have to provide a defined set of image sizes: http://cordova.apache.org/docs/en/4.0.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens

[benfrancis]

Firefox OWAs on Android use the supplied icon and extract the main color from it to use as background color I believe.

Firefox OS does the same, centre aligns the app icon. We could use theme-color for the background colour instead now that exists.

[kenchris]

I actually think it is quite simple.

Provide an image. By default center it and use theme_color or similar for background color. If the image is a 9 piece image (like used by PhoneGap and natively supported by Android) we scale it according to the splits and fill the screen. There is not talk about 9 separate images here :-) just one single one with 4 cuts... two horizontally and two vertically.