Provide a checkbox in the customization palette to toggle Keyhole appearance

RESOLVED WONTFIX

Status

()

Firefox
Theme
RESOLVED WONTFIX
11 years ago
7 years ago

People

(Reporter: faaborg, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
The purpose of this bug is to decide if we should have a checkbox in the toolbar customization palette near "use small icons" that says "combine back and forward."   While the keyhole design has the advantages
of making firefox look new, building product identity, and making the back
button easier to hit, and while it seems to be getting in general a positive
reaction so far, some people still really hate it.  The solution of "let's make
a pref" is often inferior to choosing the correct default, but in this case I
think the change is polarizing enough that we should use a pref to help
mitigate risk.

A related issue, is deciding if we want to produce the keyhole design in the tango style.  We believe that integrating with the OS theme is more important on Linux that cross platform identity, so we would definitely leave this checkbox off by default.  However, the option to use keyhole would be available for anyone who likes the design on other platforms.

Dao points out that we would need to still have a single element, and the only way to pull this off would be to do just a visual change of the back/forward buttons.  This means that you couldn't have other buttons between back and forward anymore, but that doesn't strike me as too much of a problem.  The fact that the two buttons are the same element would otherwise be transparent to the user.

This change would also introduce a compatibility issue with every existing theme.  Themes would need some way of indicating that they support the pref.
I think a the set of people who will want to do this will want to remove the forward button entirely, which is one of the most common modifications I've seen and one of the primary reasons for wanting to split the buttons.

Would that still be possible?

Comment 2

11 years ago
Alex proposes a switch for separating the icons visually. Technically, they'd still be part of the same single toolbar item. So, no, this wouldn't enable you to remove just the forward button.
(Reporter)

Comment 3

11 years ago
It's my understanding from talking with Dão that having separate back and forward buttons in the customization palette along with the keyhole is technically impossible (although I think this would be the ideal solution).

Comment 4

11 years ago
I don't think we discussed this, but it would actually be possible to have three items in the toolbar palette: Back, Forward, and the current combined blob. However, there are a few reasons why I would be against that:

* We've been rather conservative when it comes to adding toolbar items to the
  palette that some users might find useful. (I don't have a bug number
  off-hand, but I think there are some wontfixed bugs.) This would be a bad
  precedent, as separate Back and Forward buttons would be quite redundant.

* It's confusing, especially if the theme styles the combined button just like
  the separate buttons. (Applies to: Gnomestripe, text and small icon modes of
  Winstripe and Pinstripe, custom themes.)

* It's not a decision that most users will be willing to make. Our goal should
  be to design and implement what's right for 95% of our users, and leave the
  rest to custom themes and extensions.

* We would have to use different ids for the separated back and forward buttons
  and the ones that exist within the combined element. We have right now is
  backwards compatible, because we're reusing the ids of the previously
  separate buttons.

* It could turn out to be a startup performance regression, although I think it
  shouldn't be one.
I think this is an edgecase, and implementing preffable behaviour here is wrong, IMO.  This is just an appearance situation, and that's why we have themes.  Implementing separate back/forward/unified buttons feels like a giant pain in the ass for minor benefit.  I'm sure it can be done via extension, like alternative UI for pretty much everything else we do.

The other problem, namely forcing this onto all themes, just feels like we're trying too hard to give users choice in the core, and its just not worth it, IMO.  Heck, it doesn't even make sense on Linux since we're not doing the keyhole there.

Comment 6

11 years ago
Why not provide a voting site where users could choose between keyhole and non-keyhole (separated back/forward buttons, that could be placed in the toolbar independently)?

I've read a LOT of people who don't want this in.
(Reporter)

Comment 7

11 years ago
>I think this is an edgecase, and implementing preffable behaviour here is
>wrong

I agree that implementing prefs for every behavior is wrong, but I am also concerned that this is not an edge case.  I believe a subset of users (particularly on OS X) could quickly abandon Firefox 3 based on this single visual change, as opposed to learning that themes exist, finding a theme they like, installing it, restarting, etc.  That's a 5 minute process and we are going to have users making quick first impression decisions.  Also I can see the recommendation between two users in this subset "go get Firefox 3 and turn off keyhole" to be more compelling than "go get Firefox 3 and locate and install a third party theme."

In person beltzner said to me "if we don't believe in the design we shouldn't ship it."  I want to reiterate that I still believe this is the right thing to do for the majority of users.  This allows us to visually differentiate from other browsers, be easily recognizable, create a visual identity, and make it easier for users to hit the back button.  However, if we force this change on everyone, there are going to be a subset of really angry uers.  One user writes in:

>I absolutely cannot believe you left that fucking hideous, huge back button in >there.  I love Firefox, but I will never, ever use FF3

I know we can't over rotate on flames, and beltzner has already told me to grow a pair, but the seething hatred towards keyhole from some of our users is really palpable.  I'm usually pretty good at ignoring dissent that I think is purely fear of change (like calls to revert the awesome bar back to the way it was in Firefox 2).  However, I think changes that produce this level of anger might be worthy of a preference.

>it doesn't even make sense on Linux since we're not doing the
>keyhole there.

Actually I was hoping this pref would allow us to get keyhole on Linux.  Another user writes in:

>Why is Linux second class 'citizen'? A few weeks ago you posted an article >about the importance of recognizable graphic elements in some products (like >the Coca Cola branding graphics, etc). It doesn't make sense that Linux >Firefox versions do not use the keyhole concept which i think is very cool. Do >I want Firefox to look like Epiphany/Galeon/Konqueror? No. It really doesn't >make sense in terms of branding image.

I've also had some people at Mozilla ask for keyhole on Linux.

If providing a pref is technically too difficult, here is an alternate idea that still helps the user achieve their goal and doesn't go as far as hoping the user finds a third party theme they like:  we produce alternate themes for all of the platforms that remove keyhole (or in the case of linux add it) and we add a "Get Themes" link to the customization palette, which takes the user to a Web page with links to these themes, and a link to browse all themes.

Comment 8

11 years ago
I really dont like the keyhole style a la windows media player, at least the current implementation.

Just see how its on WMP11, there is much more "air" around the buttons.
There are no arrows at the play, fast forward and rewind buttons, there are only triangles. Which looks very nice there, but notice even on windows media player there is no keyhole for the back and forward buttons at the upper left side. The play button is so big because this is player and the play button is probably the most used button. But in one browser Im not sure that the back button deserve so big attention.

If you really want to release the final version with this, the keyhole should be reduced a little, now is just too big. For small icons mode you can see how its on WMP mini mode when windows media player toolbar is activated on the taskbar, and the player is minimized.

And for the end what you think about that, if a user adds space between the back button and forward button to separate the keyhole as two different buttons, to make it look like in previous versions.
For example there is a hack for combining the stop and reload buttons, only with CSS and little user action.

#back-button + #forward-button to form the keyhole, and when there is something between these two buttons (like space) the selector wont work and will display the two buttons as it was before, separated.

That way anyone who want to activate the keyhole on linux can do it easy and anyone who dont want it can remove it from windows or mac.
(In reply to comment #7)
> concerned that this is not an edge case.  I believe a subset of users
> (particularly on OS X) could quickly abandon Firefox 3 based on this single

FWIW, we've faced this risk (and yes, with just as many and just as vitriolic comments) every time we've shipped a new theme. Some users refuse to use us *until* we change our theme to look more like something, other users refuse to use us *after* we change our theme.

Our product is skinnable as a way of helping users make their browser look they way they want it to, but every visual change is going to carry a risk. We need to get used to that, and make sure that what we're shipping is the theme we believe is the best in terms of aesthetics as well as in terms of user experience.

I don't mean to be dismissive, but the risk you're referring to isn't new nor is it unusual or special in this case.

> visual change, as opposed to learning that themes exist, finding a theme they
> like, installing it, restarting, etc.  That's a 5 minute process and we are
> going to have users making quick first impression decisions.  Also I can see
> the recommendation between two users in this subset "go get Firefox 3 and turn
> off keyhole" to be more compelling than "go get Firefox 3 and locate and
> install a third party theme."

I don't really know why you think the former is any better than the latter, to be honest. In both cases the upset user will have saught out advice on how to work around the visual appearance that they didn't like (just as I and many others did when OS X 10.5 came out) - they've made the choice that they want to use Firefox, if they could just switch this one thing.

> a pair, but the seething hatred towards keyhole from some of our users is
> really palpable.  I'm usually pretty good at ignoring dissent that I think is
> purely fear of change (like calls to revert the awesome bar back to the way it
> was in Firefox 2).  However, I think changes that produce this level of anger
> might be worthy of a preference.

I can show you some of the comments we got about Firefox 2, if you'd like. They aren't much different.

> I've also had some people at Mozilla ask for keyhole on Linux.

I find it really hard to respond to this using polite terms; we consulted deeply with the GTK community, and it was made absolutely clear to us that keyhole was a non-starter in terms of making Linux look and feel native, and we agreed at that time that we'd heed that advice. If people believe that's wrong, they should take it up with those people (ventnor, monreal, etc.)

> If providing a pref is technically too difficult, here is an alternate idea
> that still helps the user achieve their goal and doesn't go as far as hoping
> the user finds a third party theme they like:  we produce alternate themes for
> all of the platforms that remove keyhole (or in the case of linux add it) and
> we add a "Get Themes" link to the customization palette, which takes the user
> to a Web page with links to these themes, and a link to browse all themes.

I'm fine to have themes as recommended add-ons, and adding a "Get Themes" (we still have the string!) link here seems sensible.

One question: the small icon files for Windows, AIUI, won't have the keyhole approach, correct? Could we not ship small icon files for Mac which are the same as the existing icons (in terms of size) but not use the keyhole approach?

Or, could we ship separate back and forward buttons to appear on the customize toolbar palette which use the old back and forward bindings? That way it's not a pref, it's just a matter of people customizing their toolbars.

Comment 10

11 years ago
Please, please, don't make this keyhole thing mandatory. Keep the old back/forward buttons in the toolbar customization window. There's no reason to remove them. You'll make a lot of people happier when they upgrade to FF3.

This isn't just about the appearance. It's about basic functionality - and in this case you're actually removing something a lot of people take for granted (having the buttons in different places).
(Reporter)

Comment 11

11 years ago
>I find it really hard to respond to this using polite terms; we consulted
>deeply with the GTK community, and it was made absolutely clear to us that
>keyhole was a non-starter in terms of making Linux look and feel native

Just to be clear I didn't mean to imply that I wanted us to switch the approach, as I said in comment 0: "We believe that integrating with the OS theme is more important on Linux that cross platform identity, so we would definitely leave this checkbox off by default."

>I'm fine to have themes as recommended add-ons, and adding a "Get Themes"

Ok, changing the summary of the bug.

>One question: the small icon files for Windows, AIUI, won't have the keyhole
>approach, correct? Could we not ship small icon files for Mac which are the
>same as the existing icons (in terms of size) but not use the keyhole approach?

Kevin suggested this as well, I'll check with him to make sure it is still a possibility for proto.
Summary: Provide a checkbox in the customization palette to toggle Keyhole appearance → Provide a "Get Themes" link in the toolbar customization palette
(Reporter)

Updated

10 years ago
Summary: Provide a "Get Themes" link in the toolbar customization palette → Provide a checkbox in the customization palette to toggle Keyhole appearance
(Reporter)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 12

10 years ago
Filed spin off bug 426748 for adding a "Get Themes" link to the toolbar customization palette.

Updated

10 years ago
Duplicate of this bug: 443218

Comment 14

10 years ago
>>Alex Faaborg
>>The purpose of this bug is to decide if we should have a checkbox in the
>>toolbar customization palette near "use small icons" that says "combine back
>>and forward."   While the keyhole design has the advantages
>>of making firefox look new, building product identity, and making the back
>>button easier to hit, and while it seems to be getting in general a positive
>>reaction so far, some people still really hate it.  The solution of "let's make
>>a pref" is often inferior to choosing the correct default, but in this case I
>>think the change is polarizing enough that we should use a pref to help
>>mitigate risk.

Response: I think this reasoning is perfect. There should be an option to have separate back and forward buttons (not just visually but as separate elements). I also think that a checkbox is too accessible and may indeed be confusing to new users. An about:config option would be better, IMHO.

>>Dão Gottwald
>>I don't think we discussed this, but it would actually be possible to have
>>three items in the toolbar palette: Back, Forward, and the current combined
>>blob. However, there are a few reasons why I would be against that:
>>
>>* We've been rather conservative when it comes to adding toolbar items to the
>>  palette that some users might find useful. (I don't have a bug number
>>  off-hand, but I think there are some wontfixed bugs.) This would be a bad
>>  precedent, as separate Back and Forward buttons would be quite redundant.

Response: If there is an about:config option then it would be an either/or situation. Nothing redundant about it.


>>* It's confusing, especially if the theme styles the combined button just like
>>  the separate buttons. (Applies to: Gnomestripe, text and small icon modes of
>>  Winstripe and Pinstripe, custom themes.)

Response: If the user is advanced enough to change an about:config setting, presumably they would not be confused by the change.


>>* It's not a decision that most users will be willing to make. Our goal should
>>  be to design and implement what's right for 95% of our users, and leave the
>>  rest to custom themes and extensions.

Response: Ah, this is crucial. Why not have this as an extension? Especially since the NoUn buttons extension already exists. We merely need to look at NoUn buttons extension to see the reason. It only works with the default theme. Basically, this is an issue where a lot extensions all need to conform to give reliable user experience and it now looks like we will need an extension for every theme. Not “the right thing to do”.

>>* We would have to use different ids for the separated back and forward buttons
>>  and the ones that exist within the combined element. We have right now is
>>  backwards compatible, because we're reusing the ids of the previously
>>  separate buttons.

Response: if combined and separated elements were mutually exclusive (with the toggle between them being the about:config setting) then this is a non-issue.

>>Mike Connor
>>I think this is an edgecase, and implementing preffable behaviour here is
>>wrong, IMO.  This is just an appearance situation, and that's why we have
>>themes.  Implementing separate back/forward/unified buttons feels like a giant
>>pain in the ass for minor benefit.  I'm sure it can be done via extension, like
>>alternative UI for pretty much everything else we do.

Response: See above. BTW, you guys could just “bless” one specific extension and stipulate that all themes must work with that extension. Just so long as there is an “officially sanctioned” way of getting back and forward buttons as separate elements.


>>Alex Faaborg 
>>I agree that implementing prefs for every behavior is wrong, but I am also
>>concerned that this is not an edge case […]if we force this change on
>>everyone, there are going to be a subset of really angry uers.

Response: Nail on the head. Although I will not switch from Firefox either way, I hope you guys can recognize “the right thing to do”.

>>Petr Mrázek
>>This isn't just about the appearance. It's about basic functionality - and in
>>this case you're actually removing something a lot of people take for granted
>>(having the buttons in different places).

Response: Seconded. Let me elaborate though. To me there is a clear visual metaphor of arranging the past to the left, present in the middle, and future to the right. Meaning… back button to the left, merged reload/stop button in the middle, and forward button to the right. FF3 breaks this. Also, I used to have a bad mouse and used to position back button on the left side of the toolbar and forward button to the right side so they’d be as far apart as possible. Again, now this is broken. I posted a complaint to the newsgroups and it was pointed out that this is also a usability issue for people with poor motor control.

Conclusion: This concludes my appeal to you guys to reopen this bug. The solutions can range from providing official separate back and forward buttons in the “customize” palette, to making an about:config option to either use current design or a separate buttons one, or simply blessing and extension as an official thing for themes to conform to. The key is to have something all themes HAVE to conform to.

Comment 15

10 years ago
I fully concur with the previous poster. I have been using Firefox since 0.9x, and while I have enjoyed most of the changes made, the one and only change that rendered me furious was the unified back/forwards button. I abhor the unified back/forward buttons in IE7, as well as in the Firefox 3, for several reasons.

1.) Usability. I have seen several subreasons to this, some being:
    a.) Poor motor control
    b.) Mouse problems
    c.) Decreased distinction between forward and back (If I'm trying to go back, I sure as heck don't want a single mis-click to send me five pages forwards.)
2.) Aesthetic reasons. This includes the inability to separate the buttons leading to power-users feeling that they are having freedoms taken away. This puts them in a position where they have to choose between their right to alter their browser as they please, and a platform that is both powerful and familiar. Even if the latter is strong enough that they are not driven away outright, there will be enough animosity there to sour what has in the past been the most vocal group of Firefox supporters: the power users who wan't the flexibility to change things that Firefox provides, via its extensions, themes, and customizability. On the whole, these are people who are not in the least intimidated by about:config or extensions, so that would be plenty for them.

(Sorry for the spiel, that's just my position, though it seems many share it)



While many above have suggested that an extension would be an answer, I will note that there is not a single portable, theme-agnostic, cross-platform extension which separates the forward and back buttons. Not one. Here, I'll show you the searches:

https://addons.mozilla.org/en-US/firefox/search?q=keyhole&cat=all
https://addons.mozilla.org/en-US/firefox/search?q=separate&cat=all
https://addons.mozilla.org/en-US/firefox/search?q=unified&cat=all

The only one on any of those searches which separates the buttons is NoUn Buttons, and it's Windows only (or at least non-linux). It's at:
https://addons.mozilla.org/en-US/firefox/addon/7056
and when I go there, I get the _delightful_ message:

NoUn Buttons is not available for Linux.


I'm sorry, but this is the one case I can think of where Mozilla has really dropped the ball. You were alerted very early on to a great deal of ill will over the unified buttons, AND early on in the betas it was possible to separate them and have them automatically revert:
http://forums.mozillazine.org/viewtopic.php?f=18&t=624115
Nonetheless, this non-intrusive, strongly requested feature was removed.

There is not even a single about:config tag containing 'back', 'forward' that has anything to do with it, nor any _at all_ under  'unified', 'button', 'keyhole', or 'separate'. I have to say that I am really disappointed.

Comment 16

10 years ago
(Just a note: I apologize if there's anger in the previous post, I just spent the last 4 hours trawling Google, addons.mozilla.org, Bugzilla, the browser.css file in the default chrome, and anything I could lay my hands on, with _zero_ result.)

Updated

10 years ago
Duplicate of this bug: 420889
I concur with Alex original post in that although this behavior is by design, it unneccessarily breaks visual methaphors, makes navigation harder (through shortening the lists) and more complex by breaking work flow.

I propose this could be easily fixed with an extension that doesn't try to replace the unified back/fwd control but just simply truncates the right hand side (hiding the unified dropdown) and adding old style back & forward history dropdown buttons to either side. The advantage of this technique is that it could be programmed theme-aware or very easily modified for a new style (just one setting: negative x-offset)
Duplicate of this bug: 666025
You need to log in before you can comment on or make changes to this bug.