Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to define platform-specific icon/splash style #361

Closed
kornelski opened this issue Apr 11, 2015 · 26 comments
Closed

Ability to define platform-specific icon/splash style #361

kornelski opened this issue Apr 11, 2015 · 26 comments

Comments

@kornelski
Copy link

Different platforms have different guidelines regarding their icon style, and an app may need to follow them to look "native".

Wrong style, even if slightly wrong, can create "uncanny valley", e.g. multiple OSes use square icons with rounded corners, but with a different radius. Icon with a wrong corner radius looks like an amateurish knock-off.

The spec currently only matches icons on size and density, but not style/theme, so sites would need to resort to user-agent sniffing if they wanted to serve system-specific icons.

A theoretical solution available in HTML, with help of Moz's nonstandard media queries, is:

<link rel=icon href="generic.png">
<link rel=icon media="all and -moz-windows-theme:luna-blue" href="xp.png">
<link rel=icon media="all and -moz-windows-theme:aero" href="vista.png">
@raucao
Copy link
Contributor

raucao commented Apr 11, 2015

We need this, too.

@alxlu
Copy link

alxlu commented Apr 17, 2015

This would be useful for us as well as we have some unique icon sizes.

@kenchris
Copy link
Collaborator

Different sizes are already handled. Anything missing there @alxlu ?

@raucao
Copy link
Contributor

raucao commented Apr 20, 2015

The point is that different platforms have different requirements as well as interface guidelines for app icons, especially in regards to shape, whitespace, and transparency. Size doesn't matter for that.

@alxlu
Copy link

alxlu commented Apr 20, 2015

Looking back at this, I think what I had in mind may be somewhat out of scope for this topic. The reason I brought icon size into this is because we have an unconventional size (basically a wide rectangle) for one of our icons that I anticipate many developers will not bother creating an icon for.

As a result, we will probably end up taking a square icon and putting it on top of a solid color rectangle. It would be great to have some type of field for icon background color added to our vendor specific field—as some icons may look strange on top of certain colors. I figure this is something developers are more likely to do than create a custom icon for us.

@marcoscaceres
Copy link
Member

@alxlu I'm also thinking of adding background color to the "image object" definition... we need the same thing for #9.

@pornel although you are more or less correct, it seems bad to target specific platforms (though you could use UA sniffing to send the right icon if really needed).

I did look into this problem about a year ago - but found they only differ a little bit in most cases:

https://groups.google.com/forum/#!topic/mozilla.dev.webapps/Dqie9L41XKg

For example:
screenshot 2015-04-24 14 04 46

@marcoscaceres
Copy link
Member

@skddc, could you post images of your icons for reference?

@marcoscaceres
Copy link
Member

@alxlu added feature request for background color: #366

@kornelski
Copy link
Author

@marcoscaceres I disagree about the "a little bit". Even examples you've shown differ enough that a wrong icon would give impression of app creator not having a good taste or not caring about the platform.

This is very important for the "native" feel, rather than giving a second-rate almost-but-not-quite feel. Here's a screenshot from Android. Can you guess which FT icon belongs to the native app?

And FT's icon is already as simple as it gets.

Now imagine a complex icon that's a colorful 3D model (KitKat or OS X 10.9 style) used among flat white silhouettes on Windows "Metro". Yuck!

So I'm quite serious with media-query-like mechanism that can target exact styles. That's the reality. We have designers who will follow style set by iOS, Material design, Metro, and whetever comes next.

It would be silly to be vague about it, because then both browsers and authors would have to figure out how to map spec-euphemisms to the specific OS they target.

Specced media query is always better than browser sniffing (e.g. not many authors will design for Tizen or Ubuntu, but niche vendors will be able to pick which one of the more popular styles is closer to their preferred one, without twisting User-Agent even more).

@marcoscaceres
Copy link
Member

Ok, a problem remains that you then even need to go down to the OS version (think of how drastically different iOS 6 was vs 7)... so the whole media query above would need to be rethought even for that.

@kornelski
Copy link
Author

It's not OS, it's style. Single OS can have many styles, e.g. Windows has Classic, Luna, Aero, Metro (and most versions could switch between couple of these at any time, so even exact OS version is not enough).

In case of iOS the styles would probably end up being named "iphoneos" or "ios" and then the new one would be "ios7" or "vibrant" (like they did in OS X).

So it may be good to be able to specify an arbitrary list of tokens (styles) an icon fits, and let browsers pick whichever one they want. This way browser/OS vendors will be defining the tokens as they see fit, and will be free to invent new ones when fashion changes.

@marcoscaceres
Copy link
Member

Ok, yeah - theme could work so long as the theme doesn't change from one version to another.

@marcoscaceres
Copy link
Member

I wonder if the same applies to splash screens...

@kornelski
Copy link
Author

Yes, it might apply to splash screens as well, e.g. if the splash screen mimics initial application layout it'll have different location and sizes of toolbars on different platforms (and screen sizes)

@marcoscaceres
Copy link
Member

So yeah, it feels like we are probably going to need a generic means of targeting platforms and themes. If anyone has a proposal for how to make this work sanely in JSON, I'm all ears. I'll try to come up with something in the next week or so (gotta finish up the Gecko implementation of the base members + CSP).

@marcoscaceres
Copy link
Member

Safari's "favorites" also shows this issue... iOS icons mixed with, um, "web" icons...

screenshot 2015-07-04 00 14 57

@marcoscaceres marcoscaceres added P2 and removed P3 labels Jul 3, 2015
@marcoscaceres marcoscaceres changed the title Ability to define platform-specific icon style Ability to define platform-specific icon/theme style Jul 6, 2015
@marcoscaceres marcoscaceres changed the title Ability to define platform-specific icon/theme style Ability to define platform-specific icon/splash style Jul 6, 2015
@tigt
Copy link

tigt commented Oct 14, 2015

Should there be an option for icon processing? Many OSes perform icon processing to massage them into the system's look and feel:

  • iOS 1-6 had the -precomposed flag to opt-out of icons getting rounded and glossed
  • All iOS versions will fill in transparency with black
  • Android still rounds off very sharp corners. Some versions, especially older ones, will also shrink the icon and apply a drop shadow.
  • Firefox OS always applies a drop shadow

Some sort of precomposed parameter to opt out of this processing would be good for designers who want to do these sorts of operations themselves for maximum visual control.

@marcoscaceres
Copy link
Member

@tigt, yeah, probably... I've been kinda hoping implementers would stop doing that (as happened with iOS).

@marcoscaceres
Copy link
Member

Upping the priority on this one... let's see if we can put something together by this friday.

@kenchris
Copy link
Collaborator

I don't think the point here is supporting any theme or OS, but there are very big iconography differences between ie Windows and other platforms. I think it would work if we added some hints instead which (the icon) will be ignored by platforms not understanding the hint.

@kenchris
Copy link
Collaborator

Also every time I request icons from our graphics team, they ALWAYS send me different icons for iOS and Android, even without me requesting it

@marcoscaceres
Copy link
Member

We need to add some spec text about how to do this server-side... similar to i18n.

@kornelski
Copy link
Author

Server-side? Ewww :(

Server-side solution is favouring incumbents and it's hostile to new platforms, because any new platform won't be recognised by all existing sites.

OTOH if the solution was declarative, then the UA could make a decision which of available styles is the closest fallback, so if somebody makes "ShinyRounded OS" tomorrow, it'll be able to fall back to iOS icons without having to fake an iOS User-Agent.

icons: [{
        "src": "a.png",
        "theme": "material"
      },{
        "src": "b.png",
        "theme": "ios-precomposed"
      },{
        "src": "c.png",
        "theme": "samsung-rounded-ish"
      }]

and have UA pick the theme it wants. Because the UA picks the theme, you don't even have to define which values are valid (just define which icon is picked as the default in case none of the themes are recognized by the UA).

HTML already solves this with vendor-specific link rel= values, so going back to UA sniffing would be regression even from current de-facto standards.

@marcoscaceres marcoscaceres removed the P1 label Mar 31, 2016
@marcoscaceres
Copy link
Member

Personally, I agree 100% with @pornel. It's a matter of getting implementations behind this (though technically, I would prefer to reuse the platform member). It think we are going to have to sit on this for a bit.

@marcoscaceres
Copy link
Member

I'm going to make platform available on image objects and "let god sort it out". The platform member is open ended enough that it can take the values of "theme"... let's see if some defacto standard emerges.

Will send a PR.

@patrickkettner
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants