The default bug view has changed. See this FAQ.

Need a "visited" livemark item icon

RESOLVED FIXED in Firefox 13

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mak, Assigned: cers)

Tracking

Trunk
Firefox 13
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

5 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
(Assignee)

Comment 1

5 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.
(Reporter)

Comment 2

5 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.
(Assignee)

Comment 3

5 years ago
The glow could be done in CSS, so it doesn't even need to be part of the actual image
(Reporter)

Comment 4

5 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
(Assignee)

Comment 5

5 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...
(Reporter)

Comment 6

5 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
(Assignee)

Comment 7

5 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.
(Reporter)

Comment 8

5 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.
(Assignee)

Comment 9

5 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
(Reporter)

Comment 10

5 years ago
Stephen, could you please elaborate on comment 9?
(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
See Also: → bug 679674
(Reporter)

Comment 12

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

Comment 13

5 years ago
Created attachment 586661 [details]
unified icon for unread livemarks
(Assignee)

Comment 14

5 years ago
Created attachment 586662 [details]
unified icon for read livemarks
(Reporter)

Comment 15

5 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.
Assignee: nobody → cers
(Assignee)

Comment 16

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

Comment 17

5 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)
(Assignee)

Comment 18

5 years ago
is there a preferred name for the icons in the two states?
(Reporter)

Comment 19

5 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]
(Assignee)

Comment 20

5 years ago
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...
Attachment #586661 - Attachment is obsolete: true
Attachment #586662 - Attachment is obsolete: true
(Reporter)

Comment 21

5 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.
(Reporter)

Comment 22

5 years ago
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!
(Reporter)

Comment 23

5 years ago
Still thank you for helping here!

https://hg.mozilla.org/integration/mozilla-inbound/rev/1639e51a4d82
Target Milestone: --- → Firefox 13
(Reporter)

Comment 24

5 years ago
https://hg.mozilla.org/mozilla-central/rev/1639e51a4d82
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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.
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

5 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.
(Reporter)

Comment 28

5 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.
(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.
(Reporter)

Comment 30

5 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.
(Reporter)

Comment 31

5 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.
(Reporter)

Comment 32

5 years ago
Created attachment 600930 [details]
borderless test

well, maybe doesn't look much native but gives a good sense of "not important"
Attachment #600930 - Flags: feedback?(shorlander)
But it is not always that a read livemark is not important.
De-highlighting it might not be the solution
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?
Attachment #600930 - Flags: feedback?(shorlander) → feedback-
(Reporter)

Comment 35

5 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.
(Reporter)

Updated

5 years ago
Blocks: 731459
You need to log in before you can comment on or make changes to this bug.