- From: Matt Giuca <notifications@github.com>
- Date: Wed, 11 Jul 2018 02:02:05 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/555/404097653@github.com>
I did a review pass on #657. But @dominickng and I also had a long chat about the high-level strategy here and the details of the dimensions. Note that the original proposal on this bug was to simply introduce a platform-specific icon purpose, which lets you say "this is my Android icon", "this is my Windows icon", etc. That's contrasted to the approach @kenchris takes in #657 which is to define a contract between the developer and user agent which we can attempt to fulfill on all platforms. This latter approach is a lot more "webby" but it has some issues which I'll get to. First, to the dimensions. I took @clagom's diagrams and extended them. In @kenchris's PR, he's proposing that we specify the safe zone as 4/5 (the diameter of the safe-zone circle as a percentage of the width of the source square). Remember that I previously stated that the Android safe zone is 22/36. I'll get into why that's important. Let's consider two options and how they render on Android: **OPTION A**: We specify the safe zone as 22/36 (61%) diameter (roughly). This exactly fits [Android's model](https://medium.com/google-design/designing-adaptive-icons-515af294c783) of the safe zone. (To avoid this arbitrary seeming number, we could drop down to 3/5 or 60%. The key is that the safe zone is *smaller or equal to* Android's.) Under this option, the website gives us this image, with the important contents exactly fitting inside a circle of radius 61%:  (As @clagom shows above, they would probably want to make the icon a little smaller so it has some padding, but I'm just going to keep everything tight for demonstration purposes.) So under this policy, the user agent is allowed to crop exactly down to the safe zone, like this:  I'm not sure exactly what Android does, but the [diagram](https://medium.com/google-design/designing-adaptive-icons-515af294c783) suggests that it would cut down to a 72dp-diameter circle, leaving a bit more of a margin:  So this turns out OK on Android, but it kind of doesn't make sense unless you chop off a large area from the outside. If another platform just takes the icon and rounds off the corners, it's going to look much too small. So if we go with Option A, you pretty much *have* to cut off around 1/6 of the space on all sides. **OPTION B**: We specify the safe zone as 4/5 (80%), as in #657. This is a pretty reasonable safe zone which will still look fine if you don't cut anything off. Under this option, the website gives us this image, with the important contents exactly fitting inside a circle of radius 80%:  However, the web-specified safe zone is much bigger than what Android allows, which means if we just pass this image to Android, it *MAY* crop down to 61% of the image:  Oops. Though as above, Android is likely to only cut to 72dp, not 66dp, resulting in a bit more of the image:  Though still not great. So Option B doesn't work on Android if we just pass the image through to the OS. However, what the user agent can do is automatically add a border of 15% on all sides:  (Shown here in black, though it could set it to the app's theme colour or the most common colour in the image, etc.) Now if we give this to Android, it will correctly chop down to 61% or 66%, giving the correct tight icon shown above. However, the extended border may be visible to the user in certain extreme cases. I've never seen Android show any part of the *background* outside of the 72dp zone due to parallax, but who knows what a future version of Android might do. I think it's fairly safe to assume the user will never see these "black" pixels. Basically, we get the same result either way, but Option A aligns the Web to Android, while Option B makes the user agent do work to align Android to the web. I daresay Option B is more palatable, because the Web shouldn't be designed around the quirks of one specific platform. It should be designed in the most generic way possible, and then user agents should do their best to map onto the underlying platform. On Windows 10, the "full bleed" option (Halo logo in [this example](https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/app-assets)) roughly fits without having to manipulate the Option B image at all. (You're supposed to leave 16% margin on each side; Option B leaves 10%, but since it's in a circle, it's more like 22% on each side if you're fitting a square icon into the circle.) Anyway, this roughly fits the expectation. However, we then considered trying to fit this into a square, which is particularly important on iOS. On iOS, there's an expectation that icons will be cut into a rounded-square, not a circle, which means you don't have to avoid the corners that a circle would cut off. For square-shaped icons, this means you make the important part much bigger. Thus, an image designed to fit in Android's (or, the Web's) circle safe zone will look too small on iOS, or another device with a square mask:  This wastes cos<sup>2</sup>(45°) or 50% of the space. For a real world example, we looked at the Facebook logo. Here's what the Facebook logo looks like inside the Option B icon metrics:  And here's what it looks like cropped with the 72dp outer ring, in both circle and rounded-square masks:   The top one is basically what this will look like on circle-masked Android devices, while the bottom is what it will look like on iOS. In the circle, the "f" comes a bit too close to the edge, and in the square, the "f" is a bit too small. You'd probably want to extend the bottom of the "f" all the way to the bottom so it doesn't cut off like that. And you'd probably want to shrink the "f" a bit more so it has more margin in the circle, which will make it even smaller in the square version. Basically, @dominickng's point is that we should be giving developers a way to specify a different icon on each platform, designed with that platform in mind. That's **OPTION C**. However, a few counter-points: - Android adaptive icons are also supposed to work as a square. Facebook already has the above issue on square-masked Android platforms. So while this isn't ideal on iOS, it's a minor imperfection which is the cost of using the generalized Web platform. - Tailoring things for each platform isn't something we generally build into the Web platform. I prefer if we can describe a generic solution and then have user agents worry about platform-specific details. Since we have a pretty good general solution here, I'd not be a fan of us giving up on this and telling developers to specify "one normal icon, then if you want, an Android adaptive icon, a Windows 10 tile icon and an iOS home screen icon." - Developers who really want to supply an iOS-specific icon can user-agent detect in the Manifest and provide a special icon set on that platform. - The downsides of Option C are the same as always on the web: the most popular platforms will enjoy tailored icons, while less popular platforms will have no developers looking at them. What if, for example, Chrome OS switches to adaptive icons at some point (and I have no insider information on this, just hypothetical) — would we just use the "android" icons there? Or would we introduce a new platform which developers have to tailor their icons for? My preferred option is still **Option B**, which is #657, with those proposed dimensions (4/5). But there's a lot to consider. I hope this has been helpful. In summary, I spent most of today literally trying to fit a square peg in a round hole. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/555#issuecomment-404097653
Received on Wednesday, 11 July 2018 09:02:29 UTC