Manifest: Add splashscreen as a `purpose`

[mounirlamouri]

If we give regarding the icon purpose/type/kind, maybe we should add splashscreen in there to help UA pick an image if it's meant to be used for the splashscreen?

[kenchris]

I think that is a great idea. @marcoscaceres

[marcoscaceres]

I would prefer a separate member for splash screen. The "purpose" is supposed to be a hint.

[marcoscaceres]

(I'm worried that some UAs will ignore the purpose and use the splash screen as the icon)

[mounirlamouri]

Some UA build an icon to build the splash screen. This is what Chrome does. Having websites tell us which icon should be preferred could be useful.

[RobDolinMS]

I was discussing this with @boyofgreen a few weeks ago and having a single array of images of various sizes (up to as big as a splash screen) may be preferable to having multiple arrays of images.

[marcoscaceres]

@mounirlamouri, would still like "splashscreens" to be a separate member. You can then fallback to icons if it's missing. Otherwise, icons gets super messy.

[mounirlamouri]

@marcoscaceres was that a question? I've never been keen to have a splashscreen member. I'm not aware of plans for Chrome to use this. The benefit of using purpose on icons is that if a website would like one specific icon to show up in the UA-built splashscreen, they can express this.

[marcoscaceres]

@mounirlamouri, I understand the intent, but I'm still worried that it's super easy to screw up and that we are going to end up with a confusing long list of icons that mix badges, splashscreens, normal icons, and other things we add in the future.

I can understand why badges would be grouped with normal icons, but, as I've demonstrated elsewhere, splashscreen differ a lot from application icons (e.g., in games). The fact that Chrome used the app's icon as a splash screen was a design choice by the Chrome team (and I agree that it makes for a great fallback), but I don't know if everyone would want to follow that showing an icon as a splashscreen is always a great idea.

That's why I propose separating splashscreen into its own member... or, as a compromise, we could have splashscreen as "purpose", but would like to see a splashscreen member also added.

WDYT?

[dominickng]

@mounirlamouri we have been getting feedback from devs that they would like more control over the splashscreen; having an explicit splashscreen member might be one way of accomplishing this. The actual functionality is something the Chrome installability team has been discussing without much advancement towards a consensus as of yet.

[RobDolinMS]

@dominickng Instead of having two arrays of images (icons[ ] and splash_screen[ ] ) what if there was one array of images and images could be labeled with something like a "purpose" of favicon, badge, splash screen, etc.? Would that satisfy your scenario? /cc @marcoscaceres @mounirlamouri

[marcoscaceres]

@RobDolinMS, if I understand correctly, that's what @mounirlamouri is also proposing. I'm supportive of doing that, but would also like the separate splashscreens member for the reasons I outlined above.

[ericelliott]

Right now we have an already gigantic array of icons. Splash screens obviously don't fall into that category in my mind.

If we can avoid any breaking change to the existing icons member, that would be great. The benefits of PWAs are hard to resist. Companies are already realizing HUGE improvements in app install & activation rates, along with dramatic reductions in cost per user acquisition. Some crazy forward-looking devs like me are already using it for production apps. I know, that's nuts, right? But I know of several large enterprise companies who are doing the same.

In addition to the crazy people are already using this spec in prod argument, let's go with internal consistency. Since icons already sets precedent for a member dedicated to a particular type of asset, I would really prefer that we follow that precedent and add a separate member for splashscreens, as well.

I know engineers like to detect patterns and lump everything that feels the same from an engineering perspective into one pile, but shorter lists are ergonomically better, too, and easier to scan.

Check out how crazy the icons list gets when you try to include just a couple vendor's recommended icon sizes for various devices. Now imagine adding all the different splashscreen sizes and formats.

Giving us separate members gives us a more scannable manifest.

[boyofgreen]

I am leaning towards a separate group as well. I really like "purpose" with icons, but I would never want to see a splash screen used as an icon or tile by accident.

[marcoscaceres]

Ok, I've put together a proposal at:
https://github.com/w3c/manifest/pull/530

As I argued already, I'm not a huge fan of "splashscreen" as a "purpose", but this would satisfy everyone's needs.

[kenchris]

I would like to understand what users needs really are?

• Different imagery than icons (then splashscreens would be more appropriate)
• More control than icons and background color?
• Control over text? like whether to show text or not (UA decides default?)
• Special considerations for splash screens on desktop (Would like MS input here)

[marcoscaceres]

On 19 Nov. 2016, at 12:48 am, Kenneth Rohde Christiansen [email protected] wrote:

I would like to understand what users needs really are?

Different imagery than icons (then splashscreens would be more appropriate)

Yes. Easy to see examples of this if you open a few native apps on your phone.

More control than icons and background color?

Yes. As above.

Control over text? like whether to show text or not (UA decides default?)

Not sure what text you are referring to here? But I think no.

Special considerations for splash screens on desktop (Would like MS input here)

Dunno. But yes, MS's input would be great.

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

[kenchris]

PWAs on Android have the name of the app, like "The New York Times" on the splash screen.

Google apps on the other hand often have a Google logo (secondary image)

[marcoscaceres]

PWAs on Android have the name of the app, like "The New York Times" on the splash screen.

Again, this is UA decision on the part of Google (which is wonderful, but still... Chrome specific... other vendors may choose a different display).

Google apps on the other hand often have a Google logo (secondary image)

Yeah, there will be variance... a long with the million other apps out there and the way they do this.

[marcoscaceres]

s/display/composition (text, image, image position, image size, time to show the image, etc.)

[delapuente]

My 2 cents. Provide a splashscreen member not limited to icons to provide full control over the splashscreen experience and also allow the value splashscreen in purpose as a hint for those browsers building the splashscreen from the icons array.

[JacobDB]

What's the status on this? Just ran in to an issue where I need to set unique icons for the home screen and splash screen and found that I was unable to with the current spec.

[dominickng]

If you set a sufficiently large (>384px) icon, Chrome should use that for the splash screen, with a different layout better optimized for the larger icon..

We haven't really had much consensus here for how to proceed on splash screens unfortunately.

[JacobDB]

@dominickng yea, that's what I thought too, but that doesn't seem to be working. Will do some more testing next week.

[JacobDB]

@dominickng I finally figured out what's happening with this and logged an issue on the Chromium issue tracker. Essentially, if a service worker is registered, the 192x192 icon is getting used, and if no service worker is registered, the 512x512 icon is getting used. There's a test case ZIP attached to the issue.

https://bugs.chromium.org/p/chromium/issues/detail?id=899879

[aarongustafson]

Where are we at with this? @marcoscaceres’ PR was abandonded. Should we shelve splash screens for now?

[kenchris]

Actually at TPAC the TAG promised to help the mini app effort getting support for their requirements in various W3C specs. From what I heard they had interest in splash screen, but I guess we can reopen later.

[marcoscaceres]

It's unclear what will happen with the mini app stuff... they can come talk to us when they are ready.

[marcoscaceres]

Where are we at with this? @marcoscaceres’ PR was abandonded. Should we shelve splash screens for now?

I'm in favor of shelving this. @mgiuca, @dominickng, @aarongustafson?

[dominickng]

I'm also in favour of shelving this - we don't really have a consensus on a way forward at this point, and I think it will need a dedicated effort to examine the needs across each platform to really figure out something workable.

[marcoscaceres]

I'm going to go ahead an close... folks tagged here are free to reopen if need be.