Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
platform-specific icons
55 views
Skip to first unread message
Marcos Caceres
May 10, 2013, 2:46:25 PM5/10/13
to Matt Basta, dev-webapps
Hi Matt,
On Friday, May 10, 2013 at 6:35 PM, Matt Basta wrote:
> There is at least one bug on file (disclaimer: I filed it) for another issue, which is platform-specific icons.
What's the bug number?
> The icon guidelines for Windows apps, for instance, are difference from the icon guidelines for Android apps. A developer wishing to tailor his icon to look native on each platform can't do that at the moment.
This sounds a lot like UA sniffing (except you would be sniffing the platform). This is quite problematic, IMO - as you would need to target particular version of each OS. iOS 7, for instance, is rumored to have changed it's look and feel to be flat. While Windows Phone 9 might decide to go all blurry and add lens flares. Android has also gone through various fairly radical redesigns, while OEMs have also customized the look and feel ontop. Other platforms might innovate on their look and feel even faster than Android, Windows, and iOS.
Having said that, I see that PhoneGap supports such a thing [1]. For example:
<icon src="icons/android/ldpi.png" gap:platform="android" gap:density="ldpi" />
[1] https://build.phonegap.com/docs/config-xml#icons
--
Marcos Caceres
On Friday, May 10, 2013 at 6:35 PM, Matt Basta wrote:
> There is at least one bug on file (disclaimer: I filed it) for another issue, which is platform-specific icons.
What's the bug number?
> The icon guidelines for Windows apps, for instance, are difference from the icon guidelines for Android apps. A developer wishing to tailor his icon to look native on each platform can't do that at the moment.
This sounds a lot like UA sniffing (except you would be sniffing the platform). This is quite problematic, IMO - as you would need to target particular version of each OS. iOS 7, for instance, is rumored to have changed it's look and feel to be flat. While Windows Phone 9 might decide to go all blurry and add lens flares. Android has also gone through various fairly radical redesigns, while OEMs have also customized the look and feel ontop. Other platforms might innovate on their look and feel even faster than Android, Windows, and iOS.
Having said that, I see that PhoneGap supports such a thing [1]. For example:
<icon src="icons/android/ldpi.png" gap:platform="android" gap:density="ldpi" />
[1] https://build.phonegap.com/docs/config-xml#icons
--
Marcos Caceres
Marcos Caceres
May 14, 2013, 4:30:03 AM5/14/13
to dev-webapps
It was requested we move this back to the mailing list from the bug (801816).
tl;dr: the differences between icon on platforms range from subtle to non-existant (and only in some specific cases do they differ significantly, but not stylistically). See:
https://bug801816.bugzilla.mozilla.org/attachment.cgi?id=749168
https://bugzilla.mozilla.org/attachment.cgi?id=748949
IMHO, introducing a new kind of vendor-platform-version-prefixing (proposed in 801816) would be harmful to the Web platform.
(In reply to Matt Basta [:basta] from comment #9)
> (In reply to Marcos Caceres [:marcosc] from comment #8)
> > you assume that these platforms don't change their look and
> > feel over time.
>
>
> Then I propose adding optional versions to the icon strings as well, similar
> to how Firefox add-ons can platform versions:
>
> "icons": {
> "128": "/path/to/icon.png",
> "128-darwin-10.8": "/path/to/darwin_icon.png",
> "128-darwin": "/path/to/darwin_icon.png",
> "128-windows": "/path/to/windows_icon.png",
> "128-android-5": "/path/to/android_icon.png",
> "128-android-4": "/path/to/android_icon.png",
> "128-android": "/path/to/android_icon.png",
> "128-firefoxos": "/path/to/firefoxos_icon.png"
> }
>
> The platform should choose the most specific icon that accurately describes
> itself.
This looks a lot like CSS vendor prefixing (but with both platform + versions). So, what if developers only do this:
"icons": {
"128-darwin-10.8": "/path/to/darwin_icon.png,
"128-android-5": "/path/to/android_icon.png"
}
Which is the UA to choose?
I would go in the opposite direction and have a declarative means to allow the developer to disable platform styles for their icons.
> > If hosted-apps take off, the UA can adapt the icon to fit the UI guidelines
> > of the platform + version (as IOs does). That way, a designer can just
> > provide the image and the system can adjust it to fit.
>
>
> Size aside, you can't make the icon fit the visual styles of each platform,
> period. It's not possible. And pretending that providing a scalable set of
> icons is going to look great cross platform is only kidding yourself.
Designers are clever (I speak as one). I'm sure they will work out a way to make communicative icons that work across platforms - they did ok with fav-icons across browsers and platforms (and UA's might be able to help them with that). Folks who really do want to target a platform can continue to use UA sniffing - but we certainly should not codify targeting specific platforms (specially in something we want to turn into a W3C recommendation).
> > I understand where you are coming from, but I don't think anyone is saying
> > that. I'm saying that there are better ways of dealing with this problem
> > that scale better in a future and backwards compatible way.
>
>
> Please, then, tell us what these "better ways" are.
I proposed to allow the UA to hook into the platform styles (with the ability for the dev to disable them). The UA is in a much better position to handle this than the developer in most cases.
> Because right now, no
> matter what you do, your app will always stick out like a sore thumb as a
> second class citizen. No other platform has FXOS-style icons, meaning if you
> target FXOS, your icons will look out of place on other platforms.
Now you see my point :) Don't target a platform. There are too many of them and they change all the time. Instead, designers should focus on making great icons (like the FireFox one, which looks great on every platform AFAIK).
> > Targeting the "now" doesn't make sense on the Web because we can't
> > purge apps that don't look right on a given platform.
>
>
> That's not our place or goal.
I'm tasked with writing the W3C specification for this - so, for better or for worst, it's my place and goal to be thinking about these things.
> We're giving a tool and choice to developers
> who want to control their app's look and feel.
Sometimes, less can be more. Organisations/developers that really want to target specific platforms should use other means (e.g., UA sniffing on the server, which unfortunately, a lot of websites continue to do today). We know from years of experience that targeting specific platforms in any capacity is bad for the Web (i.e., made for IE6, best viewed at 800x600).
> > We are defining a new class of application
> > here: there is nothing wrong for a Web application to continue to feel like
> > a Web application when it is "installed".
>
>
> False. Apps are still apps, not new web applications. These aren't a new
> class of application. Users expect that when they turn on their Android
> phone and look at their home screen, it doesn't look like a hodge-podge of
> icons that don't match their platform.
>
> Here's a short list of apps that have different icons on different platforms:
False :) I only found 2.5 that differed significantly (and even then the differences where questionable if they were to do with platform integration). And of those, one of the Android ones used the iOS style!
See:
https://bugzilla.mozilla.org/attachment.cgi?id=748949
For everyone to compare: Android icons on the left, iOS icons on the right. iOS icons are more blurry because I had to resize them to do a side by side comparison. Please also note that iOS icons are square because they haven't been masked.
> - Facebook
https://itunes.apple.com/us/app/facebook/id284882215?mt=8
https://play.google.com/store/apps/details?id=com.facebook.katana&hl=en
These are exactly the same.
> - Foursquare
https://itunes.apple.com/en/app/foursquare/id306934924?mt=8
https://play.google.com/store/apps/details?id=com.joelapenna.foursquared&hl=en
iOS one contains some minor details in the background. Funny, the Android version uses iOS gloss effect.
> - Yelp
https://play.google.com/store/apps/details?id=com.yelp.android&hl=en
https://itunes.apple.com/en/app/yelp/id284910350?mt=8
Yelp differs.
> - Netflix
https://itunes.apple.com/en/app/netflix/id363590051?mt=8
https://play.google.com/store/apps/details?id=com.netflix.mediaclient&hl=en
It's exactly the same.
> - Google Maps
https://itunes.apple.com/en/app/google-maps/id585027354?mt=8
https://play.google.com/store/apps/details?id=com.google.android.apps.maps&hl=en
Differs.
> - Gmail
https://itunes.apple.com/us/app/gmail-email-from-google/id422689480?mt=8
https://play.google.com/store/apps/details?id=com.google.android.gm&hl=en
Differs, but not in style.
> - iMDB
https://itunes.apple.com/us/app/imdb-movies-tv/id342792525?mt=8
https://play.google.com/store/apps/details?id=com.imdb.mobile&hl=en
Exactly the same, except the IOs auto-gloss is applied.
> - Bank of America
https://play.google.com/store/apps/details?id=com.infonow.bofa&hl=en
https://itunes.apple.com/us/app/bank-america-mobile-banking/id284847138?mt=8
Exactly the same. Down to the underside gradient.
> - Pinterest
https://play.google.com/store/apps/details?id=com.pinterest&hl=en
https://itunes.apple.com/us/app/pinterest/id429047995?mt=8
Differs - only in 3D effect and slight coloration difference.
The list above shows that the differences are only subtle, and in most cases non-existent. Certainly nothing in order of "like a hodge-podge of icons that don't match their platform". I also checked some on Windows Phone, found much the same: some different (e.g., facebook), some not (bank of america, imdb).
> All of those apps, from what I could come up with off the top of my head and
> verify, have slightly different icons on different platforms.
Right, some are *slightly* different.
> This is a tool
> that developers want. It's irrefutable.
I respectfully think you showed that it was refutable by showing how subtle, or non-existant, the differences really are. You can see that very clearly here, which removes platform specific bevel and drop shadow (again, slight blur on icons due to resizing):
https://bug801816.bugzilla.mozilla.org/attachment.cgi?id=749168
> This bug is to meet parity with
> other platforms.
IMHO, adding this complexity to the manifest format will only be a replay of vendor prefixing. I don't think this is needed or helpful to the platform in the long term.
Kind regards,
Marcos
--
Marcos Caceres
tl;dr: the differences between icon on platforms range from subtle to non-existant (and only in some specific cases do they differ significantly, but not stylistically). See:
https://bug801816.bugzilla.mozilla.org/attachment.cgi?id=749168
https://bugzilla.mozilla.org/attachment.cgi?id=748949
IMHO, introducing a new kind of vendor-platform-version-prefixing (proposed in 801816) would be harmful to the Web platform.
(In reply to Matt Basta [:basta] from comment #9)
> (In reply to Marcos Caceres [:marcosc] from comment #8)
> > you assume that these platforms don't change their look and
> > feel over time.
>
>
> Then I propose adding optional versions to the icon strings as well, similar
> to how Firefox add-ons can platform versions:
>
> "icons": {
> "128": "/path/to/icon.png",
> "128-darwin-10.8": "/path/to/darwin_icon.png",
> "128-darwin": "/path/to/darwin_icon.png",
> "128-windows": "/path/to/windows_icon.png",
> "128-android-5": "/path/to/android_icon.png",
> "128-android-4": "/path/to/android_icon.png",
> "128-android": "/path/to/android_icon.png",
> "128-firefoxos": "/path/to/firefoxos_icon.png"
> }
>
> The platform should choose the most specific icon that accurately describes
> itself.
This looks a lot like CSS vendor prefixing (but with both platform + versions). So, what if developers only do this:
"icons": {
"128-darwin-10.8": "/path/to/darwin_icon.png,
"128-android-5": "/path/to/android_icon.png"
}
Which is the UA to choose?
I would go in the opposite direction and have a declarative means to allow the developer to disable platform styles for their icons.
> > If hosted-apps take off, the UA can adapt the icon to fit the UI guidelines
> > of the platform + version (as IOs does). That way, a designer can just
> > provide the image and the system can adjust it to fit.
>
>
> Size aside, you can't make the icon fit the visual styles of each platform,
> period. It's not possible. And pretending that providing a scalable set of
> icons is going to look great cross platform is only kidding yourself.
Designers are clever (I speak as one). I'm sure they will work out a way to make communicative icons that work across platforms - they did ok with fav-icons across browsers and platforms (and UA's might be able to help them with that). Folks who really do want to target a platform can continue to use UA sniffing - but we certainly should not codify targeting specific platforms (specially in something we want to turn into a W3C recommendation).
> > I understand where you are coming from, but I don't think anyone is saying
> > that. I'm saying that there are better ways of dealing with this problem
> > that scale better in a future and backwards compatible way.
>
>
> Please, then, tell us what these "better ways" are.
I proposed to allow the UA to hook into the platform styles (with the ability for the dev to disable them). The UA is in a much better position to handle this than the developer in most cases.
> Because right now, no
> matter what you do, your app will always stick out like a sore thumb as a
> second class citizen. No other platform has FXOS-style icons, meaning if you
> target FXOS, your icons will look out of place on other platforms.
Now you see my point :) Don't target a platform. There are too many of them and they change all the time. Instead, designers should focus on making great icons (like the FireFox one, which looks great on every platform AFAIK).
> > Targeting the "now" doesn't make sense on the Web because we can't
> > purge apps that don't look right on a given platform.
>
>
> That's not our place or goal.
I'm tasked with writing the W3C specification for this - so, for better or for worst, it's my place and goal to be thinking about these things.
> We're giving a tool and choice to developers
> who want to control their app's look and feel.
Sometimes, less can be more. Organisations/developers that really want to target specific platforms should use other means (e.g., UA sniffing on the server, which unfortunately, a lot of websites continue to do today). We know from years of experience that targeting specific platforms in any capacity is bad for the Web (i.e., made for IE6, best viewed at 800x600).
> > We are defining a new class of application
> > here: there is nothing wrong for a Web application to continue to feel like
> > a Web application when it is "installed".
>
>
> False. Apps are still apps, not new web applications. These aren't a new
> class of application. Users expect that when they turn on their Android
> phone and look at their home screen, it doesn't look like a hodge-podge of
> icons that don't match their platform.
>
> Here's a short list of apps that have different icons on different platforms:
False :) I only found 2.5 that differed significantly (and even then the differences where questionable if they were to do with platform integration). And of those, one of the Android ones used the iOS style!
See:
https://bugzilla.mozilla.org/attachment.cgi?id=748949
For everyone to compare: Android icons on the left, iOS icons on the right. iOS icons are more blurry because I had to resize them to do a side by side comparison. Please also note that iOS icons are square because they haven't been masked.
https://itunes.apple.com/us/app/facebook/id284882215?mt=8
https://play.google.com/store/apps/details?id=com.facebook.katana&hl=en
These are exactly the same.
> - Foursquare
https://itunes.apple.com/en/app/foursquare/id306934924?mt=8
https://play.google.com/store/apps/details?id=com.joelapenna.foursquared&hl=en
iOS one contains some minor details in the background. Funny, the Android version uses iOS gloss effect.
> - Yelp
https://play.google.com/store/apps/details?id=com.yelp.android&hl=en
https://itunes.apple.com/en/app/yelp/id284910350?mt=8
Yelp differs.
> - Netflix
https://itunes.apple.com/en/app/netflix/id363590051?mt=8
https://play.google.com/store/apps/details?id=com.netflix.mediaclient&hl=en
It's exactly the same.
> - Google Maps
https://itunes.apple.com/en/app/google-maps/id585027354?mt=8
https://play.google.com/store/apps/details?id=com.google.android.apps.maps&hl=en
Differs.
> - Gmail
https://itunes.apple.com/us/app/gmail-email-from-google/id422689480?mt=8
https://play.google.com/store/apps/details?id=com.google.android.gm&hl=en
Differs, but not in style.
> - iMDB
https://itunes.apple.com/us/app/imdb-movies-tv/id342792525?mt=8
https://play.google.com/store/apps/details?id=com.imdb.mobile&hl=en
Exactly the same, except the IOs auto-gloss is applied.
> - Bank of America
https://play.google.com/store/apps/details?id=com.infonow.bofa&hl=en
https://itunes.apple.com/us/app/bank-america-mobile-banking/id284847138?mt=8
Exactly the same. Down to the underside gradient.
https://play.google.com/store/apps/details?id=com.pinterest&hl=en
https://itunes.apple.com/us/app/pinterest/id429047995?mt=8
Differs - only in 3D effect and slight coloration difference.
The list above shows that the differences are only subtle, and in most cases non-existent. Certainly nothing in order of "like a hodge-podge of icons that don't match their platform". I also checked some on Windows Phone, found much the same: some different (e.g., facebook), some not (bank of america, imdb).
> All of those apps, from what I could come up with off the top of my head and
> verify, have slightly different icons on different platforms.
Right, some are *slightly* different.
> This is a tool
> that developers want. It's irrefutable.
I respectfully think you showed that it was refutable by showing how subtle, or non-existant, the differences really are. You can see that very clearly here, which removes platform specific bevel and drop shadow (again, slight blur on icons due to resizing):
https://bug801816.bugzilla.mozilla.org/attachment.cgi?id=749168
> This bug is to meet parity with
> other platforms.
IMHO, adding this complexity to the manifest format will only be a replay of vendor prefixing. I don't think this is needed or helpful to the platform in the long term.
Kind regards,
Marcos
--
Marcos Caceres
Matt Basta
May 14, 2013, 2:15:36 PM5/14/13
to Marcos Caceres, dev-webapps
The differences are no subtle to non-existent.
- The general shape is different: Firefox OS icons are circular. iOS icons are rounded chiclets.
- Android icons are generally flat and don't have a glare. iOS icons have a more plasticy look
Of course companies have the same logo across platforms, it would be silly if they didn't. But if we're saying, "Hey, make your app follow our Firefox OS design guidelines" and then Microsoft says, "You should be following the Windows icon style guidelines" and Apple is saying, "Follow the iOS and OS X icon guidelines" and *all three of those are different*, then we're doing our developers a disservice by not letting them specify those icons.
http://developer.android.com/guide/practices/ui_guidelines/icon_design_launcher.html
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511280.aspx
http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/IconsImages/IconsImages.html
http://www.mozilla.org/en-US/styleguide/products/firefoxos/icons/
https://developer.gnome.org/hig-book/3.8/hig-book.html#icons-style
Please explain how a user is meant to tailor his app to look appropriate on each of the above five platforms by using the official style guidelines using a web app.
_______________________________________________
dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
- The general shape is different: Firefox OS icons are circular. iOS icons are rounded chiclets.
- Android icons are generally flat and don't have a glare. iOS icons have a more plasticy look
Of course companies have the same logo across platforms, it would be silly if they didn't. But if we're saying, "Hey, make your app follow our Firefox OS design guidelines" and then Microsoft says, "You should be following the Windows icon style guidelines" and Apple is saying, "Follow the iOS and OS X icon guidelines" and *all three of those are different*, then we're doing our developers a disservice by not letting them specify those icons.
http://developer.android.com/guide/practices/ui_guidelines/icon_design_launcher.html
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511280.aspx
http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/IconsImages/IconsImages.html
http://www.mozilla.org/en-US/styleguide/products/firefoxos/icons/
https://developer.gnome.org/hig-book/3.8/hig-book.html#icons-style
Please explain how a user is meant to tailor his app to look appropriate on each of the above five platforms by using the official style guidelines using a web app.
dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
Jonas Sicking
May 14, 2013, 2:36:00 PM5/14/13
to Matt Basta, Marcos Caceres, dev-webapps
I could definitely see that this is an issue on some platforms which
has a much more different style, like Windows 8.
/ Jonas
has a much more different style, like Windows 8.
/ Jonas
Marcos Caceres
May 14, 2013, 3:39:46 PM5/14/13
to Matt Basta, dev-webapps
On Tuesday, May 14, 2013 at 7:15 PM, Matt Basta wrote:
> The differences are no subtle to non-existent.
>
> - The general shape is different: Firefox OS icons are circular. iOS icons are rounded chiclets.
For FxOs, only things in the store are circular. With a hosted web app, there is no restriction on the shape. I can publish whatever shape I want - I'm not bound by any app store or guidelines.
> - Android icons are generally flat and don't have a glare. iOS icons have a more plasticy look
This is not so, they have all sorts of shapes - ranging, for instance, from square (Stark), chiclet (Vector Full), circular (FL Studio Mobile), to unbound (Punch Quest). See all the shapes here in the top selling list:
https://play.google.com/store/apps/collection/topselling_new_paid
Seems very few devs actually care on Android about consistency in the icons - yet still works fine.
If we are going to be too restrictive about icons, then that might put developers off (as it means spending more time and money creating a specific icon just for FxOS). Look at the cross platform games on the Play Store page - they have the same icon on iOS and Android (e..g, Fieldrunners, House of the Dead, Cut the Rope: Time Travel, Carmageddon, etc) - the only exception is Punch Quest (on iOS it has a background and a border).
> Of course companies have the same logo across platforms,
It's not just companies. It's apps.
> it would be silly if they didn't. But if we're saying, "Hey, make your app follow our Firefox OS design guidelines" and then Microsoft says, "You should be following the Windows icon style guidelines" and Apple is saying, "Follow the iOS and OS X icon guidelines" and *all three of those are different*, then we're doing our developers a disservice by not letting them specify those icons.
No, you just throw it back at them and say: "here is my icon - make it look awesome" (iOS works like this - details below - so Apple, at least, doesn't say "follow our guidelines" because that would be impossible to enforce on the Web). Or, "I have an awesome icon, just show it" (Android).
And if some small number of people want total control, they can use UA sniffing to target a platform.
> http://developer.android.com/guide/practices/ui_guidelines/icon_design_launcher.html
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa511280.aspx
> http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/IconsImages/IconsImages.html
> http://www.mozilla.org/en-US/styleguide/products/firefoxos/icons/
> https://developer.gnome.org/hig-book/3.8/hig-book.html#icons-style
>
> Please explain how a user is meant to tailor his app to look appropriate on each of the above five platforms by using the official style guidelines using a web app.
>
Again, *you let the user agent do it for you*. You just provide an image - the user agent handles the rest. The same way iOS does it.
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa511280.aspx
> http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/IconsImages/IconsImages.html
> http://www.mozilla.org/en-US/styleguide/products/firefoxos/icons/
> https://developer.gnome.org/hig-book/3.8/hig-book.html#icons-style
>
> Please explain how a user is meant to tailor his app to look appropriate on each of the above five platforms by using the official style guidelines using a web app.
>
Look at: http://iphone.appleinsider.com, it contains:
<link rel="apple-touch-icon" href="http://images.appleinsider.com/apple-touch-icon.png" />
Which is just a normal image (no gloss, no rounded corners):
http://images.appleinsider.com/apple-touch-icon.png
Which ends up looking like this when added to the home screen (give the icon a few secs to load - tinypic is a bit slow):
http://i42.tinypic.com/1q3nk2.png
Perfectly integrated chiclet magic. The user agent/platform could to exactly the same on Android (no gloss, standard rounded corner based on platform version). The developer just needs to provide an image - the UA handles the rest. And we could work out a standard display for FxOS so icons always integrate without the developer having to do anything (i.e., make is a circle if you want, with a standard drop shadow that fits the FxOS platform).
--
Marcos Caceres
Marcos Caceres
May 14, 2013, 3:59:17 PM5/14/13
to Jonas Sicking, dev-webapps, Matt Basta
On Tuesday, May 14, 2013 at 7:36 PM, Jonas Sicking wrote:
> I could definitely see that this is an issue on some platforms which
> has a much more different style, like Windows 8.
>
https://twitter.com/FremyCompany/status/333491310180827136/photo/1
http://mcc.id.au/temp/browsers.png
Also, it's not the case that the Metro look is actually used throughout Windows 8 Phone apps. See how much variation there is in the market:
http://www.windowsphone.com/en-us/store/top-free-apps/entertainment/entertainment
Also, top paid apps (a handful actually use the Metro style - and the more you go back along the long tail, the more of a hodgepodge it becomes):
http://www.windowsphone.com/en-us/store/top-paid-apps
Seems like the only requirement there is that the icon is square (which is great, because they are easy to adapt to other platforms:)).
And again, look at the top games (same icons as iOS in most cases - sans the rounded corners, which supports my argument of letting the platform deal with that):
http://www.windowsphone.com/en-us/store/collections/essential-games/1b72dde0-e923-4b74-8449-af96e9e65670
http://www.windowsphone.com/en-us/store/featured-games
HTH,
--
Marcos Caceres
Matt Basta
May 14, 2013, 6:16:42 PM5/14/13
to Marcos Caceres, dev-webapps
> With a hosted web app, there is no restriction on the shape. I can publish whatever shape I want - I'm not bound by any app store or guidelines.
No, you're not bound. But for developers that *want* to, we should give them that option.
> Seems very few devs actually care on Android about consistency in the icons - yet still works fine.
> If we are going to be too restrictive about icons, then that might put developers off
{
"64": "64.png",
"128": "128.png",
"128-android": "android-128.png",
"128-android-4.2": "android-4_2-128.png"
}
It's purely optional. As we increase our partner base and transition traditionally desktop and native apps to HTML5, more partners are going to look for features like this.
> they can use UA sniffing to target a platform.
> Again, *you let the user agent do it for you*.
Windows (classic and metro), OS X (flat and not flat), and Linux (...) are first-class citizens in the long term goals of the app ecosystem and we should not be ignoring the ability for developers to provide dedicated assets for these platforms.
Marcos Caceres
May 14, 2013, 7:20:19 PM5/14/13
to dev-webapps, Matt Basta
(might be time for others to chime in… Matt and I are sounding like broken records :))
On Tuesday, 14 May 2013 at 23:16, Matt Basta wrote:
> > With a hosted web app, there is no restriction on the shape. I can publish whatever shape I want - I'm not bound by any app store or guidelines.
>
>
> No, you're not bound. But for developers that *want* to, we should give them that option.
Which developers in particular? Do you have a bug with developers asking for this? Is it more devs than are asking for WebP or a solution for responsive images? Also, could we speak to these developers about the alternatives and see if it makes sense? It's our job to listen to what people need and come up with good solutions that not only meet their use cases, but also sustain the health of the Web platform. If we just addressed all immediate needs on the Web, we would have a lot more <font>-like tags.
Again, how many is a few? Why would this get resources over other features?
{
"128-ios": "ios-128.png",
"128-android-4.2": "android-4_2-128.png"
"128-windows-9": "windows9.png"
}
That's when the problems start (FxOS users will get no icons at all). Assuring everyone, not just people on iOS and Android, gets an icon should be the priority.
Then suddenly we have to start supporting another platform's icons (like Opera had to start supporting -webkit- in Presto).
> > they can use UA sniffing to target a platform.
> This is a bad practice
No worst than platform prefixing.
> Beyond rounding the corners or adding a glare, the user agent can't do a whole lot. This is not an alternative.
I don't see how you can say it's not an alternative when the dominant mobile platform already implements it - and has been available since iOS 1.1.3. It's not like some theoretical thing: it's something that people use today on the Web. It's even a standard feature of things like the HTML5 boilerplate.
On Tuesday, 14 May 2013 at 23:16, Matt Basta wrote:
> > With a hosted web app, there is no restriction on the shape. I can publish whatever shape I want - I'm not bound by any app store or guidelines.
>
>
> No, you're not bound. But for developers that *want* to, we should give them that option.
> > Seems very few devs actually care on Android about consistency in the icons - yet still works fine.
>
>
> No, not all do. But some do, and that's what matters.
We need to think carefully as to what we enable on the platform, as all choices have costs and benefits. Pleasing a small handful of developers at the expense of introducing another form of vendor-prefixing could outweigh the benefits.
>
>
> No, not all do. But some do, and that's what matters.
Again, how many is a few? Why would this get resources over other features?
> > If we are going to be too restrictive about icons, then that might put developers off
>
>
> Nothing about my proposal is mandatory, and it's in no way backwards-incompatible. This simply gives the developer to provide platform-specific icons. The following object would be perfectly acceptable:
>
> {
> "64": "64.png",
> "128": "128.png",
> "128-android": "android-128.png",
> "128-android-4.2": "android-4_2-128.png"
> }
>
> It's purely optional. As we increase our partner base and transition traditionally desktop and native apps to HTML5, more partners are going to look for features like this.
Right, but again, what if they only do this?
>
>
> Nothing about my proposal is mandatory, and it's in no way backwards-incompatible. This simply gives the developer to provide platform-specific icons. The following object would be perfectly acceptable:
>
> {
> "64": "64.png",
> "128": "128.png",
> "128-android": "android-128.png",
> "128-android-4.2": "android-4_2-128.png"
> }
>
> It's purely optional. As we increase our partner base and transition traditionally desktop and native apps to HTML5, more partners are going to look for features like this.
{
"128-ios": "ios-128.png",
"128-android-4.2": "android-4_2-128.png"
"128-windows-9": "windows9.png"
}
That's when the problems start (FxOS users will get no icons at all). Assuring everyone, not just people on iOS and Android, gets an icon should be the priority.
Then suddenly we have to start supporting another platform's icons (like Opera had to start supporting -webkit- in Presto).
> > they can use UA sniffing to target a platform.
> This is a bad practice
> and also is impossible for packaged apps.
The problem goes away with the solution I'm proposing.
> > Again, *you let the user agent do it for you*.
>
> Can the user agent adjust the direction of the lighting? Can it adjust the perspective of the image? Can it isolate the shape and turn it white for Metro? Absolutely not.
And for those cases, the developer can disable platform styles. iOS does this with "apple-touch-icon-precomposed".
>
> Can the user agent adjust the direction of the lighting? Can it adjust the perspective of the image? Can it isolate the shape and turn it white for Metro? Absolutely not.
> Beyond rounding the corners or adding a glare, the user agent can't do a whole lot. This is not an alternative.
> Windows (classic and metro), OS X (flat and not flat), and Linux (...) are first-class citizens in the long term goals of the app ecosystem and we should not be ignoring the ability for developers to provide dedicated assets for these platforms.
I agree. We should support all platforms equally.
Matt Basta
May 14, 2013, 7:40:40 PM5/14/13
to Marcos Caceres, dev-webapps
> That's when the problems start (FxOS users will get no icons at all).
The object that you provided would be invalid. Older devices would not find a suitable icon and the Marketplace's validator would consider that an error. It does not meet the spec as it's currently written.
Overridden, platform-specific icons should only be provided if a less specific variant has already been listed.
> Pleasing a small handful of developers at the expense of introducing another form of vendor-prefixing could outweigh the benefits.
> I don't see how you can say it's not an alternative when the dominant mobile platform already implements it
2. Platforms that don't implement their own clipping/reworking (or older devices that don't support it) will see an ugly square icon.
3. Some platform style guidelines physically can't be implemented programmatically.
4. We shouldn't force recomposition across platforms in ways that developers might not expect. Don't have an Unbuntu machine? Too bad, you can't see how your icon is going to look in the dash.
5. This isn't a built-in feature for *any platform that Mozilla currently supports*, meaning it would have to be built from scratch everywhere.
> And for those cases, the developer can disable platform styles. iOS does this with "apple-touch-icon-precomposed".
> It's even a standard feature of things like the HTML5 boilerplate.
----- Original Message -----
From: "Marcos Caceres" <mcac...@mozilla.com>
To: "dev-webapps" <dev-w...@lists.mozilla.org>
Cc: "Matt Basta" <mba...@mozilla.com>
Sent: Tuesday, May 14, 2013 4:20:19 PM
Subject: Re: platform-specific icons
Travis Choma
May 14, 2013, 8:01:07 PM5/14/13
to Matt Basta, dev-webapps, Marcos Caceres
What about making at least one non-platform specific default icon required? This way you don't run into the situation where one platform is using/supporting icons from another and/or missing an icon all together.
Providing optional platform specific icons provides some flexibility, although there is less pressure these days to conform to a specific platform style, i.e. iOS glossy icons are not at all popular anymore even though that is the default recommended style. But this ability to target platforms is worth considering, sometimes getting featured on a particular marketplace depends on having assets that are appropriate for it.
Also let's say open web apps run on iOS down the road, iOS's icon sizes are completely different: 57x57, 72x72, 114x114, and 144x144 so people might start using size differences as a way of targeting specific platforms anyways, without formal support for it.
Best,
-Travis
Which developers in particular? Do you have a bug with developers asking for this? Is it more devs than are asking for WebP or a solution for responsive images? Also, could we speak to these developers about the alternatives and see if it makes sense? It's our job to listen to what people need and come up with good solutions that not only meet their use cases, but also sustain the health of the Web platform. If we just addressed all immediate needs on the Web, we would have a lot more -like tags.
Providing optional platform specific icons provides some flexibility, although there is less pressure these days to conform to a specific platform style, i.e. iOS glossy icons are not at all popular anymore even though that is the default recommended style. But this ability to target platforms is worth considering, sometimes getting featured on a particular marketplace depends on having assets that are appropriate for it.
Also let's say open web apps run on iOS down the road, iOS's icon sizes are completely different: 57x57, 72x72, 114x114, and 144x144 so people might start using size differences as a way of targeting specific platforms anyways, without formal support for it.
Best,
-Travis
Matt Basta
May 14, 2013, 10:53:12 PM5/14/13
to Travis Choma, dev-webapps, Marcos Caceres
My official proposal is as follows:
- Apps icons can specify icons with keys targeting platforms and versions in the format "size[-platform[-version]]"
- The platform will choose to use the most specific icon that's applicable to itself
- The manifest is invalid if an icon targeting a platform does not specify an icon for that size. (i.e.: you can't have "128-android" without "128")
- The manifest is invalid if an icon targeting a platform version does not specify an icon for that platform. (i.e.: you can't have "128-android-4.2" without "128-android")
This prevents developers from unfairly targeting a platform, leaving out platforms unintentionally, or causing havoc with backwards-compatibility. I think that addresses the concern(s) in your first point, yes? I'll leave the other questions you raise to the rest of dev-webapps.
----- Original Message -----
From: "Travis Choma" <tch...@mozilla.com>
To: "Matt Basta" <mba...@mozilla.com>
- Apps icons can specify icons with keys targeting platforms and versions in the format "size[-platform[-version]]"
- The platform will choose to use the most specific icon that's applicable to itself
- The manifest is invalid if an icon targeting a platform does not specify an icon for that size. (i.e.: you can't have "128-android" without "128")
- The manifest is invalid if an icon targeting a platform version does not specify an icon for that platform. (i.e.: you can't have "128-android-4.2" without "128-android")
This prevents developers from unfairly targeting a platform, leaving out platforms unintentionally, or causing havoc with backwards-compatibility. I think that addresses the concern(s) in your first point, yes? I'll leave the other questions you raise to the rest of dev-webapps.
----- Original Message -----
From: "Travis Choma" <tch...@mozilla.com>
To: "Matt Basta" <mba...@mozilla.com>
Jonas Sicking
May 15, 2013, 1:51:21 AM5/15/13
to Matt Basta, dev-webapps, Marcos Caceres, Travis Choma
I think we have a few options here:
* Use some sort of naming scheme for icons, like size-platform or
size-platform-version.
* Create some more general per-platform-override mechanism, similar to
the language-override feature.
* Rely on UA detection and let servers serve different manifests for
different platforms.
* Do nothing and see how much people complain.
The last two are essentially the same, though we could enable
UA-detection in the marketplaces that we can control over, i.e. the
firefox marketplace.
This actually seems like one of those rare cases where UA detection
actually might make sense. Authors are literally wanting to send
different look-and-feel depending on what platform the application is
going to run on.
I can't say that I feel strongly either way. The fact that there's an
escape hatch in the form of UA detection means that there is an out
for people that feel that they absolutely need to do this. And it
means that we will get data on how common of a requirement this is.
On the other hand, I don't see that much harm in adding an
icon-specific feature here. Other look-and-feel issues can always be
implemented using application logic.
Only thing that I definitely don't think we should do at this stage is
the second option in the list above.
/ Jonas
* Use some sort of naming scheme for icons, like size-platform or
size-platform-version.
* Create some more general per-platform-override mechanism, similar to
the language-override feature.
* Rely on UA detection and let servers serve different manifests for
different platforms.
* Do nothing and see how much people complain.
The last two are essentially the same, though we could enable
UA-detection in the marketplaces that we can control over, i.e. the
firefox marketplace.
This actually seems like one of those rare cases where UA detection
actually might make sense. Authors are literally wanting to send
different look-and-feel depending on what platform the application is
going to run on.
I can't say that I feel strongly either way. The fact that there's an
escape hatch in the form of UA detection means that there is an out
for people that feel that they absolutely need to do this. And it
means that we will get data on how common of a requirement this is.
On the other hand, I don't see that much harm in adding an
icon-specific feature here. Other look-and-feel issues can always be
implemented using application logic.
Only thing that I definitely don't think we should do at this stage is
the second option in the list above.
/ Jonas
Mounir Lamouri
May 15, 2013, 7:51:36 AM5/15/13
to dev-w...@lists.mozilla.org
On 15/05/13 06:51, Jonas Sicking wrote:
> * Rely on UA detection and let servers serve different manifests for
> different platforms.
> * Do nothing and see how much people complain.
I would go with "Do nothing and see how much people complain.". I prefer
> * Rely on UA detection and let servers serve different manifests for
> different platforms.
> * Do nothing and see how much people complain.
the idea of having the UA doing the right thing than having platform
specific icons that might end up with developers showing a platform-X
icon on platform-Y because they don't bother having an icon for platform-Y.
FWIW, I think that validating the manifest isn't solving this problem
because developers can easily target multiple platforms (X, Y, Z) and
use one of those icons (say X) for any other platform so if you use
platform A, B or C you will have to enjoy icon X even if it doesn't
match your platform conventions. Making sure there is no specific icons
will force developers to have platform neutral icons (and then UA will
do the right thing) or target only one platform - which is unlikely to
happen.
Also, we can go from this solution to a solution with platform specific
icons if we want but we can't go the other way around so I would prefer
to take baby steps as long as we don't have a urgent need to go faster.
Given the answers to Marcos' questions, I understand that there is not
yet any strong pressure by developers to have this feature.
Cheers,
--
Mounir
Marcos Caceres
May 15, 2013, 9:58:21 AM5/15/13
to Travis Choma, dev-webapps, Matt Basta
On Wednesday, May 15, 2013 at 1:01 AM, Travis Choma wrote:
> What about making at least one non-platform specific default icon required? This way you don't run into the situation where one platform is using/supporting icons from another and/or missing an icon all together.
Imagine we get:
{icons: {"44-ffos:" "icon" }}
FxOS is perfectly capable of showing the icon. Should we punish the user for the developer's mistake? Will others do the same?
So, this is exactly the same issue browsers are now having with the proliferation of "-webkit-". Developers are not providing defaults, so other browsers like Opera were forced to support "-webkit-" (*prior to them switching to Chromium). It would be very unfortunate if we ended up in the same situation with hosted apps.
> Providing optional platform specific icons provides some flexibility, although there is less pressure these days to conform to a specific platform style, i.e. iOS glossy icons are not at all popular anymore even though that is the default recommended style. But this ability to target platforms is worth considering, sometimes getting featured on a particular marketplace depends on having assets that are appropriate for it.
To do that, a developer can provide different app manifests for different markets. The manifest can point to a unique set of icons without the need to target any particular platform:
Awesome Games Market place (myapp.example.com/awsomegames/manifest.json):
{icons: {"awsomegames/hexaicons/..."}}
Firefox OS marketplace (myapp.example.com/fxOS/manifest.json):
{icons: {"fxos/circle-icons/..."}}
My personal site (myapp.example.com/manifest.json):
{icons: {"bevel-icons/..."}}
This is effectively what developers are having to do today. The FireFox OS marketplace is a proprietary application market place - and will likely remain so for a while, so that's ok.
>
> Also let's say open web apps run on iOS down the road, iOS's icon sizes are completely different: 57x57, 72x72, 114x114, and 144x144 so people might start using size differences as a way of targeting specific platforms anyways, without formal support for it.
Exactly. Though it's a bit unfortunate. Anyway, this discussion we should have in the other thread :)
> Also let's say open web apps run on iOS down the road, iOS's icon sizes are completely different: 57x57, 72x72, 114x114, and 144x144 so people might start using size differences as a way of targeting specific platforms anyways, without formal support for it.
Marcos Caceres
May 15, 2013, 10:06:50 AM5/15/13
to Mounir Lamouri, dev-w...@lists.mozilla.org
On Wednesday, May 15, 2013 at 12:51 PM, Mounir Lamouri wrote:
> On 15/05/13 06:51, Jonas Sicking wrote:
> > * Rely on UA detection and let servers serve different manifests for
> > different platforms.
> > * Do nothing and see how much people complain.
>
>
>
> I would go with "Do nothing and see how much people complain.".
> I prefer
> the idea of having the UA doing the right thing than having platform
> specific icons that might end up with developers showing a platform-X
> icon on platform-Y because they don't bother having an icon for platform-Y.
>
> FWIW, I think that validating the manifest isn't solving this problem
> because developers can easily target multiple platforms (X, Y, Z) and
> use one of those icons (say X) for any other platform so if you use
> platform A, B or C you will have to enjoy icon X even if it doesn't
> match your platform conventions. Making sure there is no specific icons
> will force developers to have platform neutral icons (and then UA will
> do the right thing) or target only one platform - which is unlikely to
> happen.
>
> Also, we can go from this solution to a solution with platform specific
> icons if we want but we can't go the other way around so I would prefer
> to take baby steps as long as we don't have a urgent need to go faster.
> Given the answers to Marcos' questions, I understand that there is not
> yet any strong pressure by developers to have this feature.
What Mounir said.
> the idea of having the UA doing the right thing than having platform
> specific icons that might end up with developers showing a platform-X
> icon on platform-Y because they don't bother having an icon for platform-Y.
>
> FWIW, I think that validating the manifest isn't solving this problem
> because developers can easily target multiple platforms (X, Y, Z) and
> use one of those icons (say X) for any other platform so if you use
> platform A, B or C you will have to enjoy icon X even if it doesn't
> match your platform conventions. Making sure there is no specific icons
> will force developers to have platform neutral icons (and then UA will
> do the right thing) or target only one platform - which is unlikely to
> happen.
>
> Also, we can go from this solution to a solution with platform specific
> icons if we want but we can't go the other way around so I would prefer
> to take baby steps as long as we don't have a urgent need to go faster.
> Given the answers to Marcos' questions, I understand that there is not
> yet any strong pressure by developers to have this feature.
--
Marcos Caceres
Travis Choma
May 15, 2013, 11:14:43 AM5/15/13
to Marcos Caceres, dev-webapps, Matt Basta
> From: "Marcos Caceres" <mcac...@mozilla.com>
> To do that, a developer can provide different app manifests for
> different markets. The manifest can point to a unique set of icons
> without the need to target any particular platform:
>
> Awesome Games Market place
> (myapp.example.com/awsomegames/manifest.json):
> {icons: {"awsomegames/hexaicons/..."}}
>
> Firefox OS marketplace (myapp.example.com/fxOS/manifest.json):
> {icons: {"fxos/circle-icons/..."}}
>
>
> My personal site (myapp.example.com/manifest.json):
> {icons: {"bevel-icons/..."}}
>
>
> This is effectively what developers are having to do today. The
> FireFox OS marketplace is a proprietary application market place -
> and will likely remain so for a while, so that's ok.
a clean way to submit the app with custom assets for a given marketplace without a matrix of icon tags. It also goes beyond icons, developers may easily want a custom description on a per marketplace basis that calls out their accolades on a given marketplace.
Also in terms of the manifest on your own site, I suppose as mentioned earlier UA detection would allow you to serve up a different manifest to meet the needs of a given platform. From my experience the need is generally for different icons per platform, less so per version of the platform, although there will probably be some edge cases.
One thing to consider regarding your earlier point and the possibility of multiple manifest files:
> One can try to impose draconian rules on the system, but if a competitor doesn't implement that and content on the Web starts appearing that doesn't
> provide the default, then you just end up punishing users as they are the ones that don't get an icon
This raises the possibility of the reverse, where a competitor starts implementing it's own non-standard fields to the manifest. I suppose there is no avoiding that and something to keep an eye on.
Marcos Caceres
May 15, 2013, 1:09:55 PM5/15/13
to Travis Choma, dev-webapps
On Wednesday, May 15, 2013 at 4:14 PM, Travis Choma wrote:
>
>
> This is interesting to know. If developers are already doing this with multiple manifest files, this provides
> a clean way to submit the app with custom assets for a given marketplace without a matrix of icon tags. It also goes beyond icons, developers may easily want a custom description on a per marketplace basis that calls out their accolades on a given marketplace.
> Also in terms of the manifest on your own site, I suppose as mentioned earlier UA detection would allow you to serve up a different manifest to meet the needs of a given platform. From my experience the need is generally for different icons per platform, less so per version of the platform, although there will probably be some edge cases.
Absolutely.
>
> One thing to consider regarding your earlier point and the possibility of multiple manifest files:
>
> > One can try to impose draconian rules on the system, but if a competitor doesn't implement that and content on the Web starts appearing that doesn't
> > provide the default, then you just end up punishing users as they are the ones that don't get an icon
>
> This raises the possibility of the reverse, where a competitor starts implementing it's own non-standard fields to the manifest. I suppose there is no avoiding that and something to keep an eye on.
Yeah, Mounir and I have been debating for months the appropriate wording in the W3C Specification for this [1]. We've also considered removing exposing the manifest from the API to prevent exactly this (and instead exposing the data developers need in some other way). Unfortunately, JSON's lack of a "distributed extensibility mechanism" makes it highly susceptible to getting extended in potentially incompatible ways :(
> One thing to consider regarding your earlier point and the possibility of multiple manifest files:
>
> > One can try to impose draconian rules on the system, but if a competitor doesn't implement that and content on the Web starts appearing that doesn't
> > provide the default, then you just end up punishing users as they are the ones that don't get an icon
>
> This raises the possibility of the reverse, where a competitor starts implementing it's own non-standard fields to the manifest. I suppose there is no avoiding that and something to keep an eye on.
[1] https://github.com/sysapps/manifest/issues/12
--
Marcos Caceres
Ben Francis
May 16, 2013, 8:45:36 AM5/16/13
to Jonas Sicking, dev-webapps, Marcos Caceres, Matt Basta, Travis Choma
On Wed, May 15, 2013 at 6:51 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> * Rely on UA detection and let servers serve different manifests for
> different platforms.
> * Do nothing and see how much people complain.
>
> * Rely on UA detection and let servers serve different manifests for
> different platforms.
> * Do nothing and see how much people complain.
>
> The last two are essentially the same
+1
--
Ben Francis
http://tola.me.uk
Robert Kaiser
Jun 14, 2013, 5:46:44 PM6/14/13
to
Jonas Sicking schrieb:
different sets per platform and version when there's different themes,
like Windows Classic, or GTK themes.
And then, apart from app icons, I immediately come to think about in-app
icons and styling, and HTML doesn't even have reasonably theming for
"form" controls anyhow (but at least what we do right now is give them a
look that fits with the platform, even though we can't give other
elements than the standard form elements a platform-themed look, as
-moz-appearance isn't standard).
> * Do nothing and see how much people complain.
I think that's the best option without making things very hairy.
At some point we'll need generally better themability for HTML, both in
terms of theming all kinds of elements to platform style (like in
-moz-appearance) and in custom theming of form elements like <button>,
<select> etc. to site style. Maybe some ability to detect platform
theming in CSS needs to be worked into that. How to deal with app icons
there is an interesting question, though.
Robert Kaiser
> I think we have a few options here:
>
> * Use some sort of naming scheme for icons, like size-platform or
> size-platform-version.
That would get hairy very fast, as the next claim will be you need
>
> * Use some sort of naming scheme for icons, like size-platform or
> size-platform-version.
different sets per platform and version when there's different themes,
like Windows Classic, or GTK themes.
And then, apart from app icons, I immediately come to think about in-app
icons and styling, and HTML doesn't even have reasonably theming for
"form" controls anyhow (but at least what we do right now is give them a
look that fits with the platform, even though we can't give other
elements than the standard form elements a platform-themed look, as
-moz-appearance isn't standard).
> * Do nothing and see how much people complain.
At some point we'll need generally better themability for HTML, both in
terms of theming all kinds of elements to platform style (like in
-moz-appearance) and in custom theming of form elements like <button>,
<select> etc. to site style. Maybe some ability to detect platform
theming in CSS needs to be worked into that. How to deal with app icons
there is an interesting question, though.
Robert Kaiser
0 new messages