584006 - Add-ons manager utilities button style needs to be correct on all platforms

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Paul [pwd]]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3pre) Gecko/20100802 Minefield/4.0b3pre
Build Identifier: 

Currently the new Update (dropdown) button seems out of place. It looks closer to being native to OSX than it does to looking like it belongs on Windows 7 or even Firefox, as such,the button should be the style of the new Firefox toolbar buttons.

Reproducible: Always

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That's what I have seen yesterday too. Its style doesn't match the one from the mockups:

https://bug562622.bugzilla.mozilla.org/attachment.cgi?id=442478

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Note that the style is just temporary, until the visual redesign - and I didn't spend a lot of time styling it because of that.

Though the gear icon is very OSX-like. I think Boriss is still thinking through what icon should be used on other OSes.

Comment 3

[Paul [pwd]]

The gear is fine. It's the shape of the button that is alien to the Windows environment.

Comment 4

[Michael Monreal [:micmon]]

(In reply to comment #2)
> Though the gear icon is very OSX-like.

The gear is used for about everything on linux desktops...

- "gtk-execute" icon
- "System tools" category icon
- KDE logo
- ...

The gear metaphor seems to suggest motion, doing any kind of "work", but it is not very specific. Does it have a strict meaning on OSX?

I wonder if a simple text label would be a better choice her.

(Btw, is there a bug for the redesign?)

Comment 5

[Dave Townsend [:mossop]]

Marking this as needed for string freeze in case it needs string changes

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

See also attachment 462750 [details] for the broken button on Linux.

Comment 8

[Tony Chung [:tchung]]

perhaps a tooltip needed instead, to keep the gear icon?

Comment 10

[Jennifer Morrow [:Boriss] (UX)]

What was t(In reply to comment #1)
> That's what I have seen yesterday too. Its style doesn't match the one from the
> mockups:
> 
> https://bug562622.bugzilla.mozilla.org/attachment.cgi?id=442478

An important assumption I had when I made that mockup is, unfortunately, no longer true: that by default, all add-ons would automatically update.  It's been confirmed that we can't automatically update plugins.  This is important because it means that normal users, who have never touched the add-ons manager, by default will need to manually update their add-ons.  This sucks, but it also means that updating is no longer Advanced UI - it's primary and important to surface from anywhere within the add-ons manager.  If normal users at any point could have out of date plugins, then normal users should be able to go to the add-on manager and quickly & easily be able to perform such an update.

Comment 11

[Dave Townsend [:mossop]]

(In reply to comment #10)
> What was t(In reply to comment #1)
> > That's what I have seen yesterday too. Its style doesn't match the one from the
> > mockups:
> > 
> > https://bug562622.bugzilla.mozilla.org/attachment.cgi?id=442478
> 
> An important assumption I had when I made that mockup is, unfortunately, no
> longer true: that by default, all add-ons would automatically update.  It's
> been confirmed that we can't automatically update plugins.  This is important
> because it means that normal users, who have never touched the add-ons manager,
> by default will need to manually update their add-ons.  This sucks, but it also
> means that updating is no longer Advanced UI - it's primary and important to
> surface from anywhere within the add-ons manager.  If normal users at any point
> could have out of date plugins, then normal users should be able to go to the
> add-on manager and quickly & easily be able to perform such an update.

This bug has nothing to do with performing updates etc. It is purely about the visual look of the button.

Comment 12

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #8)
> perhaps a tooltip needed instead, to keep the gear icon?

Filed bug 589344 for this.

And this bug can remain just for the style changes.

Comment 14

[Andreas Nilsson (:andreasn)]

Attachment: new icon and button appearance for linux

Carried over from bug 590175

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 470466 [details] [diff] [review]
new icon and button appearance for linux

>+  -moz-appearance: button;

This isn't needed - buttons have this set already.

>   min-width: 4.5em;

Similarly, this doesn't seem to be needed either (for Linux, at least).

>   list-style-image: url("chrome://mozapps/skin/extensions/utilities.png");

I played around with this - if you apply list-style-image only to the .button-icon class (ie, #header-utils-btn .button-icon), it doesn't show the double icon. For some reason, the dropmarker is inheriting that style (but only on Linux - haven't looked into why).

Comment 17

[Andreas Nilsson (:andreasn)]

Attachment: Updated patch for Linux (checked in)

>>+  -moz-appearance: button;
>This isn't needed - buttons have this set already.
Removed.

>>   min-width: 4.5em;
>Similarly, this doesn't seem to be needed either (for Linux, at least).
Actually, it appears it does. Without this, the button grows really wide. Also tried with min-width: 16px;, but that was too small.

>>list-style-image: url("chrome://mozapps/skin/extensions/utilities.png");
>if you apply list-style-image only to the .button-icon class (ie, #header-utils-btn .button-icon), it doesn't show the double icon.
Added.

Comment 18

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 471090 [details] [diff] [review]
Updated patch for Linux (checked in)

I'm assuming you're keeping the existing icon on purpose, as opposed to the icon in the first patch.

The existing icon will eventually be updated on Windows and OSX (its another gear, but prettier). So the Linux icon can be updated to that too, when its done.

Comment 19

[Andreas Nilsson (:andreasn)]

Oh, crap, didn't I include that in the patch?

Comment 20

[Andreas Nilsson (:andreasn)]

Hm, I think it did get included, maybe it doesn't show in the diff unless you go to View in the patch detail?

I can update the icon later on if needed.

Comment 21

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Oh, duh. My mistake. 

The one time I don't look at the raw patch...

Still, r+ remains.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So this is ready now for check-in?

Comment 23

[Dão Gottwald [:dao]]

This bug was reported on Windows, the summary says "on all platforms", but the patch is Linux-only. Can someone please clarify?

Comment 24

[Michael Monreal [:micmon]]

Judging from the date I would say windows is already fixed? At least it seems to look fine on recent screenshots. Linux still has the pre-new-listview button. Cannot speak for Mac, but this could be Linux-only right now.

Comment 25

[Dão Gottwald [:dao]]

Windows has the same Mac button style as Linux right now.

Comment 26

[Michael Monreal [:micmon]]

Sorry, I thought the images posted in Boriss' latest blog¹ were actual screenshots.

[1] http://jboriss.wordpress.com/

Comment 27

[Dave Garrett]

comment 22 redux: The current patch is review+ and even if it's Linux only it looks like it should be committed for now at least to make progress. If other OSes need patching too, then someone can write new patches for them too.

Comment 28

[Dão Gottwald [:dao]]

Comment on attachment 471090 [details] [diff] [review]
Updated patch for Linux (checked in)

http://hg.mozilla.org/mozilla-central/rev/b07b23448a2d

Comment 29

[Dão Gottwald [:dao]]

Andreas, are going to take care of Windows as well?

Comment 30

[Dão Gottwald [:dao]]

Attachment: the rest

Comment 31

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 473470 [details] [diff] [review]
the rest

According to Boriss's mockups, we don't want native styling on that button on Windows/OSX.
See https://bug585950.bugzilla.mozilla.org/attachment.cgi?id=464424

I'll attach the guide Boriss made, that elaborates on a lot of these details.

Comment 32

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Visual design guide

Comment 33

[Paul [pwd]]

(In reply to comment #31)
> Comment on attachment 473470 [details] [diff] [review]
> the rest
> 
> According to Boriss's mockups, we don't want native styling on that button on
> Windows/OSX.
> See https://bug585950.bugzilla.mozilla.org/attachment.cgi?id=464424
> 
> I'll attach the guide Boriss made, that elaborates on a lot of these details.

Even if that is the case, as shown in attachment 473975 [details], the button styling is clearly wrong.

Comment 34

[Michael Monreal [:micmon]]

What is the guideline for linux? "Wait for an updated guide" or "do what you want"?

Comment 35

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #34)
> What is the guideline for linux?

It should use native styling/icons/colors wherever applicable. Which means a mockup isn't going to be a lot of help - but the Windows/OSX mockups should be able to act as a guideline (there's little visual difference between them, and no layout differences).

(In reply to comment #33)
> Even if that is the case, as shown in attachment 473975 [details], the button styling is
> clearly wrong.

Yes, it is - this bug still needs fixed for Windows/OSX, but just not with native styling.

Comment 37

[Dave Townsend [:mossop]]

Fixed by bug 601022, file any remaining issues separately

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Marking as verified fixed with builds on all platforms like Mozilla/5.0 (X11;
Linux i686; rv:2.0b8pre) Gecko/20101125 Firefox/4.0b8pre ID:20101125030318