Closed
Bug 882582
Opened 11 years ago
Closed 11 years ago
Preferences button opens Options on Windows
Categories
(Firefox :: Theme, defect)
Tracking
()
RESOLVED
FIXED
Firefox 28
People
(Reporter: scoobidiver, Assigned: Gijs)
References
(Blocks 1 open bug)
Details
(Whiteboard: [Australis:M9][Australis:P3][strings])
Attachments
(1 file, 1 obsolete file)
5.30 KB,
patch
|
jaws
:
review+
|
Details | Diff | Splinter Review |
It's similar to bug 826840 but for the Custom and Control Firefox menu.
On Windows, the setting button is named Preferences and opens Options (window or tab for in-content). It should be Options or Settings everywhere for any OSes.
I see it's named Settings in http://people.mozilla.com/~shorlander/files/australis-design-specs/australis-design-specs-osx.html and Options in http://people.mozilla.com/~shorlander/files/customization-tab-i01/customizationTab-quickDisplay.html
Assignee | ||
Updated•11 years ago
|
Whiteboard: [Australis:M?]
Updated•11 years ago
|
Whiteboard: [Australis:M?] → [Australis:M?][Australis:P3][strings]
Comment 1•11 years ago
|
||
Considering that about:home is using "Settings", I think that would be a good compromise.
http://hg.mozilla.org/mozilla-central/file/4ffb23062b3b/browser/locales/en-US/chrome/browser/aboutHome.dtd#l29
Updated•11 years ago
|
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Comment 2•11 years ago
|
||
Matej, do you have any thoughts on this?
To summarize: Australis has a button (widget) to open Firefox settings window, currently using "Preferences" as a label, so it doesn't match the corresponding menu command on Windows.
Would it be ok to use "Settings" for this label, as in about:home?
Updated•11 years ago
|
Flags: needinfo?(Mnovak)
Comment 3•11 years ago
|
||
Are we only solving for Windows here? I'm just wondering why "Settings" is preferable since then it doesn't match either Windows or Mac.
Flags: needinfo?(Mnovak)
Comment 4•11 years ago
|
||
My assumption is that the button label should be the same as the old OS-specific menuitem.
about:home is an interesting example, but I wouldn't be surprised if many users simply didn't use that as an entry-point. Perhaps we should fix that one too (not sure if that was an explicit decision or not).
Comment 5•11 years ago
|
||
> I'm just wondering why "Settings" is preferable since then
> it doesn't match either Windows or Mac.
I guess that's the point. Having Preferences would confuse Windows users, having Options would sound wrong for Mac and Linux users, Settings is kind of os-agnostic.
(In reply to Justin Dolske [:Dolske] from comment #4)
> My assumption is that the button label should be the same as the old
> OS-specific menuitem.
So changing based on the OS? Sounds definitely good to me.
I checked bug 711157 but I couldn't find anything about this choice.
Comment 6•11 years ago
|
||
If we can change based on OS, that would get my vote. Otherwise "Settings" sounds good to me. Thanks.
Assignee | ||
Comment 7•11 years ago
|
||
Stealing this, I hope you don't mind... Let me know what you think of this appapproach. :-)
Attachment #807163 -
Flags: review?(jaws)
Assignee | ||
Updated•11 years ago
|
Assignee: jaws → gijskruitbosch+bugs
Comment 8•11 years ago
|
||
Comment on attachment 807163 [details] [diff] [review]
Make 'Preferences' be 'Options' on Windows,
Why does the tooltip end with an ellipsis?
Assignee | ||
Comment 9•11 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #8)
> Comment on attachment 807163 [details] [diff] [review]
> Make 'Preferences' be 'Options' on Windows,
>
> Why does the tooltip end with an ellipsis?
Because the Preferences one does too? I was just going for consistency with what we have.
Comment 10•11 years ago
|
||
I don't think it makes sense, and we shouldn't strive for consistency with something broken. It's particularly bad for strings where changing them again later on requires extra work for all locales.
Assignee | ||
Comment 11•11 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #10)
> I don't think it makes sense, and we shouldn't strive for consistency with
> something broken. It's particularly bad for strings where changing them
> again later on requires extra work for all locales.
Well, can you describe what would make sense? Traditionally, in my understanding, anything that opens a dialog has ellipses. In the designs, none of the menupanel's buttons have ellipses in their labels. So instead there are ellipses in the tooltips. I'm not entirely sure why this is "broken".
Comment 12•11 years ago
|
||
Ellipsis are added when a command will have an extra confirmation or configuration step rather than being executed directly. So for instance, you know that "Print..." won't immediately start the printer and "Clear Recent History..." won't immediately delete data. There's no such intermediate step for Options/Preferences, and therefore this menu item traditionally doesn't get an ellipsis. You can still see it in the menu bar. The same is true for various other menu items that open windows, dialogs or tabs.
I don't think moving ellipses from labels to tooltips makes sense either, as it defeats their purpose of clearly informing the user of the intermediate step.
Assignee | ||
Comment 13•11 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #12)
> There's no such intermediate step
> for Options/Preferences, and therefore this menu item traditionally doesn't
> get an ellipsis.
Actually, Preferences has an ellipsis on OS X. On all apps.
Assignee | ||
Comment 14•11 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #12)
> I don't think moving ellipses from labels to tooltips makes sense either, as
> it defeats their purpose of clearly informing the user of the intermediate
> step.
Can we have this discussion in another landing-blocking (M9) bug, please? Needinfo madhava and/or matej and/or shorlander, as I don't think this is clear-cut. While this hasn't landed on m-c, nobody should be localizing anything just yet, and we don't need to scopecreep this bug into "fix all the ellipses".
Comment 15•11 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #13)
> (In reply to Dão Gottwald [:dao] from comment #12)
> > There's no such intermediate step
> > for Options/Preferences, and therefore this menu item traditionally doesn't
> > get an ellipsis.
>
> Actually, Preferences has an ellipsis on OS X. On all apps.
That must be a special OS X thing then. We follow no rule that says to add ellipses to all items that open dialogs, though, for the reason I stated. Not even on OS X. And is bug is about Windows anyway.
(In reply to :Gijs Kruitbosch from comment #14)
> Can we have this discussion in another landing-blocking (M9) bug, please?
I don't think there's a need for further discussion here.
> Needinfo madhava and/or matej and/or shorlander, as I don't think this is
> clear-cut. While this hasn't landed on m-c, nobody should be localizing
> anything just yet, and we don't need to scopecreep this bug into "fix all
> the ellipses".
I don't say fix all the ellipses in this bug, you just shouldn't have it in the string you're adding here.
Assignee | ||
Comment 16•11 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #15)
> (In reply to :Gijs Kruitbosch from comment #14)
> > Can we have this discussion in another landing-blocking (M9) bug, please?
>
> I don't think there's a need for further discussion here.
>
> > Needinfo madhava and/or matej and/or shorlander, as I don't think this is
> > clear-cut. While this hasn't landed on m-c, nobody should be localizing
> > anything just yet, and we don't need to scopecreep this bug into "fix all
> > the ellipses".
>
> I don't say fix all the ellipses in this bug, you just shouldn't have it in
> the string you're adding here.
I'm confused. I *think* you're saying:
1) you want me to change one of the strings I'm adding
2) you disagree with all (or some) of the existing tooltip ellipses, and the lack of ellipses on labels.
3) you don't want those to get changed here.
4) you don't think we should have a bug to discuss your suggestion, or to update the ellipses/labels per your suggestion (whatever that would entail) before landing on m-c.
Is this summary correct? I'm sure I'm misunderstanding some part of it, but I'm not sure which part.
Comment 17•11 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #16)
> 4) you don't think we should have a bug to discuss your suggestion, or to
> update the ellipses/labels per your suggestion (whatever that would entail)
> before landing on m-c.
>
> Is this summary correct? I'm sure I'm misunderstanding some part of it, but
> I'm not sure which part.
What I wrote was a rehash of our rule for when to add ellipses, since you seemed to have asked for that in comment 11. It wasn't my personal suggestion of a rule we should adopt but rather a description of what we already had adopted. It's in line with our menu bar on Windows, Linux and for the most part on OS X, I believe. So I do think we should have a bug correcting the existing strings. At the same time, we shouldn't land more strings doing it wrong.
Comment 18•11 years ago
|
||
Comment on attachment 807163 [details] [diff] [review]
Make 'Preferences' be 'Options' on Windows,
I agree with comment #17.
Attachment #807163 -
Flags: review?(jaws)
Assignee | ||
Comment 19•11 years ago
|
||
Same patch, sans ellipsis this time.
Attachment #807687 -
Flags: review?(jaws)
Assignee | ||
Updated•11 years ago
|
Attachment #807163 -
Attachment is obsolete: true
Updated•11 years ago
|
Attachment #807687 -
Flags: review?(jaws) → review+
Assignee | ||
Comment 20•11 years ago
|
||
Whiteboard: [Australis:M?][Australis:P3][strings] → [Australis:M9][Australis:P3][fixed-in-ux][strings]
Assignee | ||
Comment 21•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:M9][Australis:P3][fixed-in-ux][strings] → [Australis:M9][Australis:P3][strings]
Target Milestone: --- → Firefox 28
You need to log in
before you can comment on or make changes to this bug.
Description
•