I'm going to implement the good-enough approach for our top sites icons in bug 1388396 but it'd be great to revisit the top sites favicons to improve their appearance even further. More explanation to follow.
No longer depends on: 1398863
Depends on: 1388396
Duplicate of this bug: 1398863
Created attachment 8906871 [details] Desktop algorithm for top sites tiles For context, at one point this was the desktop algorithm for top sites – I think they may have started favoring screenshots over favicons/site images, iirc because users can recognize sites better by their screenshots than they can by their favicons.
Created attachment 8906872 [details] Android top sites mock When implementing this bug, I recommend taking a step back to talk to UX to understand the big picture with regard to our top sites/highlights icons: the current implementation is a compromise. My understanding of bbell's vision for top sites icons is that: - All icons should be scaled up to fill the full tile - He'd rather have a slightly artifacted icon rather than the current implementation of a centered icon with a colored background. - Any icon that, when scaled to fill the tile, is too artifacted should be discarded and replaced with a screenshot (bug 1389259) or, failing that, a generated icon. For example, look at the attached mock. However, in my brief investigation, I saw a few concerns (using the suggested discard size of 90px in bug 1388396 comment 12): - Many icons were too small and thus substituted for generated icons including a default bookmark (addons.mozilla.org) - Some icons have transparency and cannot fully fill the space (e.g. japan.go.jp whose icon is in the shape of a flag): should we add a colored background here? I didn't have enough time to investigate this further so I opted for a good enough approach in bug 1388396. --- Some challenges: - It's hard to know which sites will show up in real user's top sites in practice so when I found to many placeholder icons in my testing, perhaps I had an unrealistic set of sites) - The Icons cache makes it difficult to follow different resizing approaches in different views (e.g. the first request will perform the resize but subsequent requests will just pull from the cache so whoever calls first, wins - The Icons cache & resizing also makes the loaders receive different Bitmaps: the originally-sized bitmap the first invocation and the resized Bitmap from the cache the second time. Some approaches to take: - Can we find alternative site icons that are likely to be larger? (watch the data cap!) - What can we learn from similar implementations (e.g. Chrome)? - How scaled icons look on a device is specific to the screen size and its DPI: could we improve our scaling by taking this into account? - Could we scale different icons at different factors to optimize their appearance? - Could we discard images in an algorithmic way (e.g. I think centered icons that are wider than their margins look fine; there may also be algorithms to identify resize artifacting)?
(In reply to Michael Comella (:mcomella) from comment #3) > Some approaches to take: - I also dislike the colors of our generated favicon – is there a way we can improve the palette? Can we apply that palette to our centered favicons too (if still relevant)?
All open Activity Stream bugs are moving from the whiteboard tag, "[mobileAS]", to the Firefox for Android component, "Activity Stream", so that I can keep better track of these bugs as the new triage owner; I will send out an email shortly with additional details, caveats, etc.
Component: Awesomescreen → Activity Stream
You need to log in before you can comment on or make changes to this bug.