Marco Bonardo [:mak] Reporter
	Description • 13 years ago

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

	Christian Sonne [:cers] Assignee
	Comment 1 • 13 years ago

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.

	Marco Bonardo [:mak] Reporter
	Comment 2 • 13 years ago

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.

	Christian Sonne [:cers] Assignee
	Comment 3 • 13 years ago

The glow could be done in CSS, so it doesn't even need to be part of the actual image

	Marco Bonardo [:mak] Reporter
	Comment 4 • 13 years ago

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

	Christian Sonne [:cers] Assignee
	Comment 5 • 13 years ago

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...

	Marco Bonardo [:mak] Reporter
	Comment 6 • 13 years ago

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

	Christian Sonne [:cers] Assignee
	Comment 7 • 13 years ago

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.

	Marco Bonardo [:mak] Reporter
	Comment 8 • 13 years ago

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.

	Christian Sonne [:cers] Assignee
	Comment 9 • 13 years ago

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

	Marco Bonardo [:mak] Reporter
	Comment 10 • 13 years ago

Stephen, could you please elaborate on comment 9?

	Stephen Horlander [:shorlander]
	Comment 11 • 13 years ago

(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

	Marco Bonardo [:mak] Reporter
	Comment 12 • 13 years ago

Christian, do you have any time to convert Stephen mockups to real icons? Should be even simpler since all platforms are unified.

	Marco Bonardo [:mak] Reporter
	Comment 15 • 13 years ago

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.

	Christian Sonne [:cers] Assignee
	Comment 16 • 13 years ago

(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 :-)

	Marco Bonardo [:mak] Reporter
	Comment 17 • 13 years ago

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)

	Christian Sonne [:cers] Assignee
	Comment 18 • 13 years ago

is there a preferred name for the icons in the two states?

	Marco Bonardo [:mak] Reporter
	Comment 19 • 13 years ago

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]

	Christian Sonne [:cers] Assignee
	Comment 20 • 13 years ago

(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...

	Marco Bonardo [:mak] Reporter
	Comment 21 • 13 years ago

(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.

	Marco Bonardo [:mak] Reporter
	Comment 22 • 13 years ago

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!

	Marco Bonardo [:mak] Reporter
	Comment 23 • 13 years ago

Still thank you for helping here!

https://hg.mozilla.org/integration/mozilla-inbound/rev/1639e51a4d82

	Marco Bonardo [:mak] Reporter
	Comment 24 • 13 years ago

https://hg.mozilla.org/mozilla-central/rev/1639e51a4d82

	[not reading bugmail]
	Comment 25 • 13 years ago

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.

	Girish Sharma [:Optimizer]
	Comment 26 • 13 years ago

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.

	dindog
	Comment 27 • 13 years ago

(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.

	Marco Bonardo [:mak] Reporter
	Comment 28 • 13 years ago

(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.

	Girish Sharma [:Optimizer]
	Comment 29 • 13 years ago

(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.

	Marco Bonardo [:mak] Reporter
	Comment 30 • 13 years ago

(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.

	Marco Bonardo [:mak] Reporter
	Comment 31 • 13 years ago

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.

	Marco Bonardo [:mak] Reporter
	Comment 32 • 13 years ago

well, maybe doesn't look much native but gives a good sense of "not important"

	Girish Sharma [:Optimizer]
	Comment 33 • 13 years ago

But it is not always that a read livemark is not important.
De-highlighting it might not be the solution

	Stephen Horlander [:shorlander]
	Comment 34 • 13 years ago

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?

	Marco Bonardo [:mak] Reporter
	Comment 35 • 13 years ago

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.