Manifest: 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 [email protected]:

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

[phone]
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 [email protected]:

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

[phone]
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.

[kenchris]

You have an event to call when you want the splash screen to be hidden. It is your responsibility to call it. A timeout could be used, but it kind of defeats the purpose

[raucao]

That would work I think.

From our daily experience I should also add that the automatically generated ones can be a bit ugly, but we'd also not like to use the theme color for this in our apps usually, because it's too bright as background for the splash screen.

[kenchris]

I guess that the user agent could decide what to use for background color, like you could use the theme_color and make it 20% darker, like Android does something like that for the status bar background color. We can make suggestions but leave it open for UAs to decide

[marcoscaceres]

...resuming work on this...

[mounirlamouri]

/cc @PaulKinlan @jakearchibald

I wrote a proof of concept for this using what would be a theme_color with an icon from the Manifest. I'm fairly happy about using the icon. However, I am a bit concerned about the theme_color. It might be very close but not quite exactly the icon's background colour. Also, the theme_color might not be the best solution for a smooth transition. For exmaple, GMail would have a red theme colour with a mostly white content after. They might prefer to have a white-ish loading screen.

Which makes me realise that we could generalise that to help prevent the usual white screen, outside of a splash screen context. For example, if loading an offline-first application would take a couple of hundred milliseconds, a user might still be annoyed by a flash of white. However, if the colour is closed to the page's background, it might be less annoying.

What would you think of introducing something like a background_color property?

[kenchris]

If you did use a 9 piece image (which is just one image btw) then you could define any background color in that. Also it is natively supported on Android.

[jakearchibald]

I thought 9-slice images were the answer, but they don't solve a whole lot of cases. Eg

• Icon against a diagonally stripped background
• Anything with text is going to look platform-alien
• Anything that tries to match something like first real render is going to have sizing issues

[kenchris]

• 9 piece images can be transparent as well
• If a non-9 piece image is used, we can just center the image
• iOS as an example, strongly discourages the use of text on any splash screen

[jakearchibald]

I agree with @mounirlamouri, it's a quick win.

Is still like a way to generate splashscreen bitmaps on the client, but I realise that's way more complicated. Take https://jakearchibald.github.io/svgomg/, I'd like to be able to create a splash screen that was identical to first render, or maybe without the text.

[mounirlamouri]

I'm not a big fan on how that was solved. I don't think I would implement the specification as-is unfortunately.

The background-color fields in image is interesting but I'm not sure that's what we want here. Maybe we should have background-color on splashscreen? The idea was really about knowing the background colour of the content that would be printed after the generated splash screen.

[slightlyoff]

I'd like to keep this from being too specific to one timing or another. A
generalized background color is good. A more specific one for each use-case
might also be good, but I'd like to not get hung up on it.

On Sun, May 24, 2015 at 7:19 AM, Mounir Lamouri [email protected]
wrote:

I'm not a big fan on how that was solved. I don't think I would implement
the specification as-is unfortunately.

The background-color fields in image is interesting but I'm not sure
that's what we want here. Maybe we should have background-color on
splashscreen? The idea was really about knowing the background colour of
the content that would be printed after the generated splash screen.

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

[marcoscaceres]

Maybe we should have background-color on splashscreen?

That's what is currently specified?

The idea was really about knowing the background colour of the content that would be printed after the generated splash screen.

Maybe you can list some apps I can look at to see what you mean. This is not what I'm seeing in the sample of apps I've been testing on iOS.

[marcoscaceres]

Here is a wall of splash screens. The images on the left are the splash screen, the ones on the right are the application screens shown after the splash screen goes away.

[marcoscaceres]

From the above, we can discuss different use cases and requirements.

[marcoscaceres]

The background-color fields in image is interesting but I'm not sure that's what we want here. Maybe we should have background-color on splashscreen? The idea was really about knowing the background colour of the content that would be printed after the generated splash screen.

I need the background color for both the splash screen and for the icons. However, I think I made a mistake having background_color be on the image object. It makes processing non-trivial for me in the gecko implementation. For tiles, this is what I'm doing to determine what image to use:

1. Create an HTML image element in Gecko's parent process.
2. convert the list images from icons to string of "srcset"s .
3. set image.srcset = converted list of icons.

In the above, I lose the background color :( That is, I know which img.currentSrc is used, but I can't then go back reliably to find which background color was associated with an image object (there could be two sources that use the same background-color).

Would anyone object to removing background color from image object and moving it to it's own members:

"icons_background_color": "papayawhip",
"splashcreen_background_color": "blue" 

PS: I hate JSON. It's an inflexible pile of crap.

[mounirlamouri]

I would prefer to have background_color on the icon object instead of outside. It gives information that can be interesting to the UA. For example, which icon is fit for a dark background and which for a lighter one.

This said, none of the presented solutions (splashcreen_background_color or icons.background_color) currently match what I had in mind. I don't think it's fair to take iOS examples and say that a splashscreen implement should follow what is being done their. iOS has its own UI rules which doesn't match other platform. For example, Android does not recommend having splashscreens so you will obviously find very little apps with splashscreen.

I will ping some folks about that and come back to you.

[marcoscaceres]

I would prefer to have background_color on the icon object instead of outside. It gives information that can be interesting to the UA. For example, which icon is fit for a dark background and which for a lighter one.

That's kinda interesting, but I'd like to see where something like that is done in practice? Is that something that Android supports?

I don't think it's fair to take iOS examples and say that a splashscreen implement should follow what is being done their.

I think it's the same on Android, but I will check tomorrow.

iOS has its own UI rules which doesn't match other platform. For example, Android does not recommend having splashscreens so you will obviously find very little apps with splashscreen.

Yes, @pornel pointed this out in https://github.com/w3c/manifest/issues/361. We need to start thinking about how to address that. We've already started doing platform specific stuff with the related_apps thing, so feels like the time is right to start giving that some more serious thought.

Didn't know that Android didn't recommend them. I'll still be interested to see if devs. are respecting that on mainstream apps.

[marcoscaceres]

(fwiw, I think having per icon background color might be a "nice to have" thing - it seems kinda niche, but need to find evidence).

[kenchris]

Well, at least at Google I/O it was announced that the Material Design Guidelines how includes a section on guidelines for splash and launch screens:

https://www.google.com/design/spec/patterns/launch-screens.html

"Because launching your app while displaying a blank canvas increases its perceived loading time, consider using a placeholder UI or a branded launch screen."

That sounds pretty much like a recommendation in some cases :-)

[marcoscaceres]

How about having background_color on icon and icon_background_color. That would allow authors to override icons_background_color.

{
"icons": [
   {"src": "icon.png",
    "background_color": "orange" },
   {"src": "icon.png"}
],
"icons_background_color": "red"
}

I also seriously want to introduce platform and theme on image objects too - to address @pornel's use cases from #361.

[marcoscaceres]

(fixed JSON above)

[marcoscaceres]

The same as above for splashscreen.

[kornelski]

In Safari 8 9 Apple has introduced a new kind of icon for pinned tabs which they hacked with a non-standard mask attribute.
The icon must be a vector icon, which is only black+transparent, and the browser changes the icon's color based on <meta theme-color> (which is wrong, because theme is a background color and they use it for foreground color). _edit:_ it's all fixed now <meta rel=icon-mask color>.

So maybe {src:"icon.svg", sizes:"all", "foreground_color":red} is needed for that?

[marcoscaceres]

Article re: YouTube update states:

Many people have also been taking notice of Google's recent about-face regarding splash screens. While the practice used to be frowned upon, a recent change to the Material Design spec declared that Launch screens are acceptable for apps that take too long to display content at startup. Drive was the first app to receive this treatment, followed shortly thereafter by Maps. Now that YouTube has joined the ranks, a number of people have already mentioned that it feels much snappier.

[marcoscaceres]

Marking "at risk" while waiting on feedback from potential implementers.

[kornelski]

Why is it at risk when it ships in Chrome? (…with ugly hack that repurposes other fields, because this one was missing…)

[marcoscaceres]

Chrome uses icons + background_color to create splashscreens (instead of splashscreens member). Their feedback is that the bg+icons combo is sufficient, but having this in the spec is causing confusion.

On 25 Mar 2016, at 9:32 AM, Kornel [email protected] wrote:

Why is it at risk when it ships in Chrome?

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

[kornelski]

That's unfortunate, because I find Chrome's implementation hacky, fragile and insufficient to build a quality experience.

AFAIK Chrome's recommendation is to design a 192px icon for the splash screen, and then hope that maybe other sizes will be used elsewhere. I understand they've done it for an MVP, but that's not good enough to keep.

Design of our app calls for a different style of logo on the splash screen than it uses for the homescreen icon (splash logo should be larger, with name in our brand font, and without a shadow).

Additionally, on the first run, our app needs to download initial data before it can lay out the homepage (homepage layout is dynamic and server-driven), so we do have our own HTML/CSS splash screen. AFAIK there's no way to guarantee when Chrome decides it has the first useful render of the page, so we risk that Chrome's splash screen and our in-app splash screen will be slightly different and cause glitchy/jarring jump of the logo on two distinct splashcreens.

We'd like to create a seamless experience where splash screen looks the same from the first render by Chrome, until our app has downloaded data (optionally with a progressbar rendered on our HTML splash screen if download takes long, so just keeping Chrome's bare splash for longer is an unattractive option).

Implementation of splash screens on iOS is a little bit buggy, but allows us to implement our design, and it's _so much better_ than what Chrome ships.

[PaulKinlan]

Just to be clear our guidance is to use a larger icon. 192 is minimum.

On Fri, 25 Mar 2016, 17:43 Kornel, [email protected] wrote:

That's unfortunate, because I find Chrome's implementation hacky, fragile
and insufficient to build a quality experience.

AFAIK Chrome's recommendation is to design a 192px icon for splash screen,
and then hope that maybe other sizes will be used elsewhere. That's not
good enough.

Design of our app calls for a different style of logo on the splash screen
than it uses for the homescreen icon (icon should be larger, with name in
our brand font, and without a shadow).

Additionally, on the first run, our app needs to download initial data
before it can lay out the homepage (homepage layout is dynamic and
server-driven), so we do have our own HTML/CSS splash screen. AFAIK there's
no way to guarantee when Chrome decides it has the first useful render of
the page, so we risk that Chrome's splash screen and our in-app splash
screen will be slightly different and cause jarring jump of the logo.

We'd like to create a seamless experience where splash screen looks the
same from the first render by Chrome, until our app has downloaded data
(optionally with a progressbar rendered on our HTML splash screen if
download takes long).

Implementation of splash screens on iOS is a little bit buggy, but it's _so
much better_ than what Chrome ships.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/w3c/manifest/issues/9#issuecomment-201382645

[kornelski]

Could you at least extend definition of icons to have a field like "role": "splash", so that the pixel size is not the deciding factor?

And please don't put app name underneath it on the splash screen. Roboto is not our font.

[marcoscaceres]

On 26 Mar 2016, at 4:55 AM, Kornel [email protected] wrote:

Could you at least extend definition of icons to have a field like "role": "splash", so that the pixel size is not the deciding factor?

That's just shifting the problem up one level.

The point here is to bootstrap the progressive apps ecosystem by covering the 80% case. Once we get more than Chromium-based browsers supporting this standard, we can come back and add more things (even things we know we need, like this!).

We need another year or so for that to happen so we are trying to reduce the feature set to "good enough" for now. That may help us convince Microsoft and Apple to implement, and Mozilla to use my implementation in a product like Fennec.

To be clear: there is no point in having splashscreens in the spec if Chromium is not going to implement it, so we should take splashscreens out till they are convinced otherwise.

We need more sites like FT saying "we need this" in order to change their minds.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

[laukstein]

@pornel, sizes: "all" proposed in https://github.com/w3c/manifest/pull/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 https://github.com/w3c/manifest/blob/51ebee66f37d1d7652dc26411ca0b8492d1287d6/index.html#L153-L156

"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 [email protected] wrote:

@marcoscaceres, you forgot to remove https://github.com/w3c/manifest/blob/51ebee66f37d1d7652dc26411ca0b8492d1287d6/index.html#L153-L156

"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 [email protected] 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 https://github.com/w3c/manifest/issues/9#issuecomment-105282660, 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