Last Comment Bug 706850 - Need a "visited" livemark item icon
: Need a "visited" livemark item icon
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 13
Assigned To: Christian Sonne [:cers]
:
Mentors:
Depends on:
Blocks: livemarksIO 731459
  Show dependency treegraph
 
Reported: 2011-12-01 09:07 PST by Marco Bonardo [::mak] (Away 6-20 Aug)
Modified: 2012-02-28 16:47 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
unified icon for unread livemarks (828 bytes, image/png)
2012-01-07 05:32 PST, Christian Sonne [:cers]
no flags Details
unified icon for read livemarks (631 bytes, image/png)
2012-01-07 05:33 PST, Christian Sonne [:cers]
no flags Details
livemark item icon sprite (3.77 KB, image/png)
2012-01-16 14:29 PST, Christian Sonne [:cers]
no flags Details
patch v1.0 (15.51 KB, patch)
2012-02-11 01:49 PST, Marco Bonardo [::mak] (Away 6-20 Aug)
no flags Details | Diff | Splinter Review
borderless test (19.20 KB, image/png)
2012-02-27 09:09 PST, Marco Bonardo [::mak] (Away 6-20 Aug)
shorlander: feedback-
Details

Description Marco Bonardo [::mak] (Away 6-20 Aug) 2011-12-01 09:07:07 PST
Livemark items are currently decorated with livemark-item.png icon (livemark-item-aero.png for Windows Aero), we need a modified icon, called livemark-item-checked.png, that differentiates visited (that for these items also means read) items from unvisited ones.

Right now I'm using some ugly placeholder, linking just to give an idea of what I mean http://i41.tinypic.com/v4uy50.jpg

The starting icons are:

http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/livemark-item-aero.png
http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/livemark-item.png
http://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/livemark-item.png
http://mxr.mozilla.org/mozilla-central/source/browser/themes/gnomestripe/places/livemark-item.png
Comment 1 Christian Sonne [:cers] 2011-12-02 08:59:28 PST
Is there a strict need to keep the old icons as the unread ones? I drew up this quick sketch that would "mimic" the glow from app tabs when something is new, and desaturated the icon for when it is read: http://geeksbynature.dk/bugs/706850/706850_pinstripe.png

The same could be done for the other system icons - the glow color I used is just the color from the feed icon.
Comment 2 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-12-02 09:04:27 PST
No, there is no strict need, just someone from UX team should take a quick look at the approach and evaluate if it's functional.
The only strict need is the size of the image, that should stay 16x16, so the glow may become problematic.
Comment 3 Christian Sonne [:cers] 2011-12-02 09:06:08 PST
The glow could be done in CSS, so it doesn't even need to be part of the actual image
Comment 4 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-12-02 09:11:02 PST
yes but this has to be used in treeviews, and treeviews have native painting, so they don't support a bunch of CSS styling... I don't think we can make that glow in treeviews at all.
But I like the idea of desaturated icons
Comment 5 Christian Sonne [:cers] 2011-12-03 09:20:07 PST
I did an experiment with both desaturated versions and a glow applied inside the icon so as to fit in 16x16: http://geeksbynature.dk/bugs/706850/icons_desaturated_innerGlow.png

I suspect that if inner glow is chosen, we will probably have to tweak it somewhat, but this is just a POC...
Comment 6 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-12-05 05:30:43 PST
The colored border idea is a win, but the glow should be far more subtle imo, to the level of being mostly reduced to 1px of inner border
Comment 7 Christian Sonne [:cers] 2011-12-05 07:48:50 PST
Here's one where I included a much narrower glow: http://geeksbynature.dk/bugs/706850/icons_desaturated_innerGlowNarrow.png

It also preserves opacity better, as I colorized the border rather than masking over it.
Comment 8 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-12-05 08:26:16 PST
So, we'd use the second and the fourth line if I get that correctly? Good work, I like it! Still maybe, as shorlander suggested on irc, we should change all platforms to use orange, the blue variation is still too subtle, imo.
Comment 9 Christian Sonne [:cers] 2011-12-05 09:40:20 PST
Here are all the icons colorized first to the gnomestripe orange, then to the pinstripe orange - I think I'd prefer the latter, so it would make it 2 and 6, bit it is of course up to you guys (and/or UX): http://geeksbynature.dk/bugs/706850/icons_desaturated_innerGlowNarrowOranged.png
Comment 10 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-12-09 17:20:14 PST
Stephen, could you please elaborate on comment 9?
Comment 11 Stephen Horlander [:shorlander] 2011-12-22 21:57:26 PST
(In reply to Marco Bonardo [:mak] from comment #10)
> Stephen, could you please elaborate on comment 9?

I really like the idea of just a colored border and maybe 1px outer glow. The inset glow makes the icons looked recessed and maybe a little heavy.

Since we are replacing the icons anyway this is a good opportunity to simplify things a bit by using roughly the same icon on all platforms with only slight color and style tweaks on the desaturated icon. So a 14x14 icon and 1px outer glow for all platforms. 

I think a mashup of Comment 2 and Comment 9 + some shape tweaks to bring it inline with the rounded square of the default favicon: http://people.mozilla.com/~shorlander/files/live-mark-icons.png
Comment 12 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-01-04 03:11:59 PST
Christian, do you have any time to convert Stephen mockups to real icons? Should be even simpler since all platforms are unified.
Comment 13 Christian Sonne [:cers] 2012-01-07 05:32:55 PST
Created attachment 586661 [details]
unified icon for unread livemarks
Comment 14 Christian Sonne [:cers] 2012-01-07 05:33:36 PST
Created attachment 586662 [details]
unified icon for read livemarks
Comment 15 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-01-09 01:19:47 PST
nice, thank you! we just have to optimize them and put in patch form. I'll try to finish the other patches along the week too, so we can proceed.
Comment 16 Christian Sonne [:cers] 2012-01-09 09:54:39 PST
(In reply to Marco Bonardo [:mak] from comment #15)
> nice, thank you! we just have to optimize them and put in patch form.

I already ran optipng -o7 on them, if that's the type of optimization you're talking about.

Regarding patch form, I didn't think there was presently a visited state I could attach to, but if it's just a matter of adding some :visited rules to a style-sheet(?), I'll happily do that part too :-)
Comment 17 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-01-09 12:17:30 PST
hm, well that's the minor problem, the css handling will be done in the blocked bug, this may just remove the old icons and add the new ones to the tree (and jar.mn)
Comment 18 Christian Sonne [:cers] 2012-01-13 15:00:18 PST
is there a preferred name for the icons in the two states?
Comment 19 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-01-14 03:12:54 PST
hm, well, I suppose we may put both aside in livemark-item.png and use -moz-image-region to select the wanted image. The order may be [hightlighted|grey]
Comment 20 Christian Sonne [:cers] 2012-01-16 14:29:22 PST
Created attachment 589016 [details]
livemark item icon sprite

(In reply to Marco Bonardo [:mak] from comment #19)
> hm, well, I suppose we may put both aside in livemark-item.png and use
> -moz-image-region to select the wanted image. The order may be
> [hightlighted|grey]

Now they're in one image - as far as I understand mercurial, I can't really create a binary patch, so someone with push rights will have to do that part I suspect.

Now that all themes use the same image, would it be advisable to leave in the root of themes, and then make the jar.mn pack it into the right location in each theme? If not, the same file will have to appear in at least 3 locations, and that seems a bit wasteful...
Comment 21 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-07 08:17:55 PST
(In reply to Christian Sonne [:cers] from comment #20)
> Now that all themes use the same image, would it be advisable to leave in
> the root of themes, and then make the jar.mn pack it into the right location
> in each theme? If not, the same file will have to appear in at least 3
> locations, and that seems a bit wasteful...

Thanks!
Doesn't matter that much since doesn't hit the product, only the sources tree. And in future they may differ again, who knows.
Btw, sorry for late, I'm now merging this icon into my patches queue.
Comment 22 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-11 01:49:26 PST
Created attachment 596289 [details] [diff] [review]
patch v1.0

just a plain icon addition patch for the due blame (and glory!), all the code for the replacement is in bug 613588
It looks great!
Comment 23 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-24 05:44:50 PST
Still thank you for helping here!

https://hg.mozilla.org/integration/mozilla-inbound/rev/1639e51a4d82
Comment 24 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-25 02:15:42 PST
https://hg.mozilla.org/mozilla-central/rev/1639e51a4d82
Comment 25 [not reading bugmail] 2012-02-25 17:38:30 PST
I like the color difference, but I was so confused by this, it feels like the unread and read icons are backwards.  I kept thinking I read all the bright colored orange ones already.  I actually had to think hard about what I read and figure it out that was not intuitive to look at in one pass.
Comment 26 Girish Sharma [:Optimizer] 2012-02-25 22:46:54 PST
Why not change the icon of the read one's with the actual favicon of the page. Like it was done earlier. And keep the unread icon highlighted.

I really don't like the blank favicons even after visiting their respective pages.
Comment 27 dindog 2012-02-26 08:11:04 PST
(In reply to Girish Sharma from comment #26)
> Why not change the icon of the read one's with the actual favicon of the
> page. Like it was done earlier. And keep the unread icon highlighted.
> 
> I really don't like the blank favicons even after visiting their respective
> pages.

+1

The issue never exist to me in fact... with website icon, been read, rss icon, not yet.
Comment 28 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-27 05:19:35 PST
(In reply to Dennis "Dale" Y. [:cuz84d] from comment #25)
> I like the color difference, but I was so confused by this, it feels like
> the unread and read icons are backwards.  I kept thinking I read all the
> bright colored orange ones already.  I actually had to think hard about what
> I read and figure it out that was not intuitive to look at in one pass.

yes this is matter of getting used to the colors, though probably we may improve the current situation, I was thinking to add some opacity so the read ones to make them appear less bright. Could you file a follow-up so we can evaluate?

(In reply to Girish Sharma from comment #26)
> Why not change the icon of the read one's with the actual favicon of the
> page. Like it was done earlier. And keep the unread icon highlighted.

very good reasons:
1. performances.
2. the old system was pretty buggy on many livemarks doing redirects, the new system is not.

So I don't think we will go back to the page icon, though we can evaluate improvements to make easier to distinguish the different status.
Comment 29 Girish Sharma [:Optimizer] 2012-02-27 05:23:05 PST
(In reply to Marco Bonardo [:mak] from comment #28)
> very good reasons:
> 1. performances.
> 2. the old system was pretty buggy on many livemarks doing redirects, the
> new system is not.
> 
> So I don't think we will go back to the page icon, though we can evaluate
> improvements to make easier to distinguish the different status.

Can't we use the favicons api ? that is used by places view, namely history and bookmarks page to get the favicon ?, or use the same heuristics for getting the favicon, as used by the new thumbnail service for getting the screenshot of redirecting sites.

While you are replying, is ther a way to automatically load livemarks now?, instead of opening each individual one. I have a huge number and clicking on each one and then waiting for it to load is pretty tiresome.
Comment 30 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-27 05:25:52 PST
(In reply to Girish Sharma from comment #29)
> Can't we use the favicons api ? that is used by places view, namely history
> and bookmarks page to get the favicon ?, or use the same heuristics for
> getting the favicon, as used by the new thumbnail service for getting the
> screenshot of redirecting sites.

my 2 points stick even using the favicons api. Using icons to indicate visited status is just bringing in issues, since it's not what it is supposed to do.

> While you are replying, is ther a way to automatically load livemarks now?,
> instead of opening each individual one. I have a huge number and clicking on
> each one and then waiting for it to load is pretty tiresome.

Likely not in the product itself since upgrading livemarks contents is expensive and we don't want to do that unless the user is going to use a livemark. Though I'm evaluating making a simple add-on for users willing to pay the cost. Though this is the wrong bug to discuss this.
Comment 31 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-27 09:04:58 PST
I was thinking we should try with a borderless icon for visited status, just the livemark glyph, or a really subtle border and transparent background.
Comment 32 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-27 09:09:21 PST
Created attachment 600930 [details]
borderless test

well, maybe doesn't look much native but gives a good sense of "not important"
Comment 33 Girish Sharma [:Optimizer] 2012-02-27 10:13:35 PST
But it is not always that a read livemark is not important.
De-highlighting it might not be the solution
Comment 34 Stephen Horlander [:shorlander] 2012-02-27 10:25:15 PST
Comment on attachment 600930 [details]
borderless test

It definitely makes it more obvious which item is de-emphasized. It might be too extreme though since the shape is now completely different. Maybe keep the background but lower the contrast/opacity?

Would you please take another screenshot with more unread items?
Comment 35 Marco Bonardo [::mak] (Away 6-20 Aug) 2012-02-27 13:19:40 PST
From my constant usage, what attract my attention are the white background and the border, so my example was the limit of that. The white background especially seems to play an important role in making appear it prominent. I was almost thinking to use the empty favicon border (or similar), just to keep the shape.

Note You need to log in before you can comment on or make changes to this bug.