Closed
Bug 1398970
Opened 7 years ago
Closed 3 years ago
Follow-up: optimize appearance top sites favicons
Categories
(Firefox for Android Graveyard :: Activity Stream, enhancement, P5)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: mcomella, Unassigned)
References
Details
(Whiteboard: [mobileAS])
Attachments
(2 files)
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.
Reporter | ||
Comment 2•7 years ago
|
||
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.
Reporter | ||
Comment 3•7 years ago
|
||
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)?
Reporter | ||
Comment 4•7 years ago
|
||
(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)?
Reporter | ||
Comment 5•7 years ago
|
||
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
Comment 7•6 years ago
|
||
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: P3 → P5
Comment 8•3 years ago
|
||
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•