Remove the Close button from the add-on bar

RESOLVED INVALID

Status

()

Firefox
Toolbars and Customization
RESOLVED INVALID
8 years ago
4 years ago

People

(Reporter: heraldo, Unassigned)

Tracking

({uiwanted, ux-consistency, ux-minimalism})

Trunk
uiwanted, ux-consistency, ux-minimalism
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fx4-fixed-bugday])

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b10) Gecko/20100101 Firefox/4.0b10

Contradicts Bug 616014. Arguments for removing the close button are:

1. The close button is of little use and also annoying for people who decide to have the add-ons bar enabled at all times. They don't want to close that toolbar
2. The toolbar can already be closed by rightclicking any toolbar.
3. The close button is inconsistent with all the other regular toolbars
4. Since the add-ons toolbar looks like a Find in page toolbar, and the Close buttons are aligned while the Find in page bar is open, the close button draws attention when wanting to close the Find in page bar

More arguments for removing the Close button are welcome in the comments.

Reproducible: Always
(Reporter)

Updated

8 years ago
Version: unspecified → Trunk

Comment 1

8 years ago
you summed it up pretty accurately, though i’ll add one argument:

1.1. those few who want to enable/disable the addon-bar all the time will already know the shortcut for opening it, which can also be used to close it.

so apart from annoying the majority, it is also unnecessary for the others.

Comment 2

8 years ago
For transient usage of this toolbar the keyboard shortcut route is a much simpler and more consistent idea (bug 616015). As-is, there's a hide button but no show button, which is somewhat inconsistent. I would be in favor of a toggle button of some sort to replace the close button (which I think was in the earlier mockups). A toggle button could auto show/hide on hover in a lower corner or could be placed below the scroll bar on the right.

The primary argument is rather straightforward, however. There are going to be two groups:
A) Those who always have the addon bar shown
B) Those who show and hide the addon bar as needed

Group A does not need or want the close button.
Group B would be better suited by a keyboard shortcut and/or toggle button.
Neither group really benefits all that much from a close button.

I think this close button is over-complained-about, but it nonetheless seems unnecessary and I think it's worth removing after bug 616015 lands.

Leaving unconfirmed with uiwanted until the UX team can weigh in.
Depends on: 616014
Keywords: uiwanted, ux-consistency, ux-minimalism

Updated

8 years ago
OS: Windows Vista → All
Hardware: x86 → All

Comment 3

8 years ago
Could we not have it disappear after first use? or go XX seconds after adding a new button?
(Reporter)

Comment 4

8 years ago
(In reply to comment #2)
> I would be in favor of a toggle button of some sort to replace the close button > (which I think was in the earlier mockups).

This is one of the early mockups that has a toggle button:
http://jboriss.files.wordpress.com/2010/06/fourth_series.png?w=480&h=252

The problem with this approach, I believe, is that the toogle button would not
have anywhere to go in a maximized window.

Comment 5

8 years ago
One additional problem with a regular close button is that to novice users it may impose the expectation that it needs to be closed; it might create a false forced choice. If they have an addon installed that they wish to use continuously that needs the bar to be open this will provide a mixed message to the user.

Updated

8 years ago
Depends on: 616015
(In reply to comment #2)
>I think it's worth removing after bug 616015 lands.

It landed, so what are we doing with this bug ?
I think it should be fixed before shipping Firefox 4

Comment 7

8 years ago
bug 616014 comment 27 gives the reasoning for this
WONT FIX due to bug 616014.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [fx4-fixed-bugday]

Comment 9

8 years ago
(In reply to comment #7)
> bug 616014 comment 27 gives the reasoning for this

No it doesn't. That comment gives the reasoning for why it should be static, i.e. not removable or re-arrangeable by the user. This bug requests removing it entirely.

(In reply to comment #8)
> WONT FIX due to bug 616014.

This bug is a request to undo that bug. You can't WONTFIX based on just that. This bug shouldn't be part of "[fx4-fixed-bugday]". A decision should come from the UX team.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Whiteboard: [fx4-fixed-bugday]

Updated

8 years ago
Status: REOPENED → NEW
> This bug is a request to undo that bug. You can't WONTFIX based on just that.
> This bug shouldn't be part of "[fx4-fixed-bugday]". A decision should come from
> the UX team.

Please don't remove my whiteboard tags.  Thank you very much.
Whiteboard: [fx4-fixed-bugday]
Can we nominate this bug as blocker for greater goods ?
Because this button is completely superfluous...

Comment 12

7 years ago
Any plans for fixing this stupid choice of impeding users by adding this button by programmers ? Users using add-on bar didn't want this, users not using add-on bar didn't care about this. So why keep it this way ? Didn't you see that, this is so obscure change or you are simply so dull and ignorant.
(Reporter)

Comment 13

7 years ago
Rob Tonsan: you may want to check out Bugzilla Etiquette, it helped me: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Rob, if you agree with the premise of a bug and think it is important, there is a VOTE link beside the IMPORTANCE field at the top of the bug.  Clicking this link will signal your want for this bug to be fixed.

Thanks for your feedback and passion for Firefox.
Dave Garrett has done a good job of summarizing the issue here.  The question is whether users use the add-on bar transiently (e.g. find-in-page) or more permanently (e.g. bookmark bar).  Dave described these groups as A and B above.

There's no doubt that both sets of users exist.  For instance, I'm in the transient group, and only bring out the add-on bar when I want to use Firebug.  Others I've seen use alerts and items on the bar constantly, and would never close it.

I filed bug 616014, to add a close button, because I wanted to encourage transient rather than permanent usage of the add-on bar when it was a new feature.  The reason is that one of the UX team's most important goals for Firefox 4 (and beyond) is minimizing Firefox's chrome and maximizing its content space.  This is to give the priority to the web, not to the browser.  As such, I'd certainly prefer that most people have the bottom of the browser taken up with content and not chrome.

However, which group we cater to by default ( by having a close button or not) should be based on actual usage and not our hopes. Usage was not possible to determine at first, because the add-on bar was a new feature.  The close button was added as a first attempt to guide its usage.  Now that the add-on bar has been around a few months, I think we should be looking for data on if most add-on bar users are transient or permanent.

I'm going to CC fligtar to the bug, who may have an idea on how to get some data on this problem.
(In reply to comment #15)
> I'm going to CC fligtar to the bug, who may have an idea on how to get some
> data on this problem.

This would need to be a Test Pilot experiment; I only have data for pings and API calls, which this doesn't use.

fwiw, I strongly support removing the close button.

Comment 17

7 years ago
Does not having it disappear after XX seconds/minutes cater to both groups?

Comment 18

7 years ago
(In reply to comment #17)
> Does not having it disappear after XX seconds/minutes cater to both groups?

While that might solve this problem, I think it would probably confuse people.

The keyboard shortcut (bug 616015) is in and I personally think this is the best route for the transient usage type, instead of the close button. (as stated above, there's no show button) The shortcut key is even listed next to the checkbox in the Firefox menu, where you'd have to go to turn it on in the first place, so it should be easily discoverable for all those who would want it. (it's not listed in the toolbar context menu, though; I think adding it to that too might be wise, especially if the close button is removed)

Comment 19

7 years ago
(In reply to comment #17)
> Does not having it disappear after XX seconds/minutes cater to both groups?

No, that is a really bad idea. I use that information.

As an example, I use the No Squint add-on -- one of the features is displaying the current page zoom level in the add-ons bar (was in the status bar). I regularly look to see what the current zoom level is.

I can't currently move that display with "customize" -- No Squint writes the field and Firefox displays it in the add-ons bar.

Another example: The control to turn on and off the Auto Context add-on is on the Add-Ons bar. Right now I can just click the control. Enabling the Add-One bar first each time will be a real pain.

If/when I can move the display from No Squint and the widget for Auto Contest I'll put them next to the URL bar. But right now I can't do that. Don't take the information away from me before a replacement is available.

Don't get me wrong, I like reducing the Firefox overhead. Long ago I move everything I wanted from the Menu Bar and the Bookmarks Bar onto the Navigation Bat and turned off the other two bars.

Just stop saying "you can't have the information you want because some people don't want to see it so no one can have it". That's what happened to the Find Bar (which is a real annoyance because it vanishes on me all the time when I want to use it) and now you suggest taking away the information from the Add-Ons bar.

Comment 20

7 years ago
(In reply to comment #19)
> (In reply to comment #17)
> > Does not having it disappear after XX seconds/minutes cater to both groups?
> 
> No, that is a really bad idea. I use that information.

I took the word "it" in comment 17 to refer to the close button. I think you're thinking "it" referred to the addon bar. Granted, the sentence was potentially ambiguous in its wording, but based on context I'm pretty sure the "it" must be the close button because having the addon bar auto-hide wouldn't cater to both groups: those who want to hide it and those who don't. Auto-hiding the close button would give both groups pretty much what they want, but I think it would be confusing to users to have an auto-hiding close button. A close button isn't the sort of thing that should be transient. It's probably best we either have it or not.

An auto-hiding/showing addon bar might be a nifty feature, but that's the sort of thing probably better left for an addon. I don't think that would be a good default feature, and I don't think that was being suggested here.

Comment 21

7 years ago
Sorry for my previous rant, I guess I misinterpreted and overreacted.

I agree that a transient close button would not be useful. 1) Users training themselves to use the close button would find it annoying as the button wouldn't always be present. 2) The vanishing would be additional distracting movement.
For all groups simple removable button will be the best idea.
Who don't want it, can drag it do Customizable windows and it will disappear from add-on bar like other icons. It's very simple.

Comment 23

7 years ago
(In reply to comment #22)
> For all groups simple removable button will be the best idea.
> Who don't want it, can drag it do Customizable windows and it will disappear
> from add-on bar like other icons. It's very simple.
nope, sice being able to move it elsewhere doesn’t make sense. for justifying a new option it’s too minor, for making it an opt-out about:config setting it’s too useless.

an opt-in about:config setting would mean that everybody will forget about it and it will be additonal useless chunk, which nobody is using.

my proposal: make it into a moveable toggle-button for the addon bar. if you place this one on the addon bar, it would beharve like the current close button, if placed elsewhere, it will open and close the addon bar, and if removed, it won’t be in the way.

and everybody’s happy.
That's all I have in mind ;)
This will be the best idea.
(In reply to comment #23)
> (In reply to comment #22)
> my proposal: make it into a moveable toggle-button for the addon bar. if you
> place this one on the addon bar, it would beharve like the current close
> button, if placed elsewhere, it will open and close the addon bar, and if
> removed, it won’t be in the way.
> 
> and everybody’s happy.

We could add a toggle button for the add-on bar, but as soon as we did there would be requests for a similar button to toggle the bookmarks bar, large and small toolbar icons, tabs on bottom and top, etc.  While it does simplify this problem, adding toggle-able preferences to main ui is something we'd like to avoid, instead creating a UI that works best in the default or nearly-default mode.

I've been considering this bug and getting people's feedback on the issue for the past couple days.  People's perception of the bar is starkly divided between those who use it permanently and transiently, and as fligtar said, we have no data at this time.

You can make the same argument for not including a close button that we make for the bookmark bar.  For most people, it's permanent.  For those who use it transiently, there's a context menu item and regular menu item.  This is less than the add-on bar has, because it also can be launched and dismissed with a key command.

It's true that we deeply want minimalism in the UI, and thus would be thrilled if add-on users mostly kept the add-on bar minimalized.  But this only is justifiable as long as it supports usage.  If add-on users with to keep the add-on bar visible, then the close button itself reduces the minimalism for these users.

What I'd really like to know is which are the main add-ons that people use the add-on bar for.  Notification add-ons clearly benefit from being constantly visible, while many of the firebug users I've spoken to want transient usage.  It's a shame to have to call this without data, but we may have to give it a try and adjust if our instinct was incorrect.  At the moment I'm leaning towards removing the close button - especially since fligtar, who has a closer relationship to the add-on community than any of us, recommends it.

Comment 26

7 years ago
(In reply to comment #25)
> What I'd really like to know is which are the main add-ons that people use the
> add-on bar for.

The two I currently us are mentioned in comment 19, No Squint and Auto Context. I'd love to move the Add-on widgets off the Add-on bar and onto the Navigation bar.

My experimentation with Firefox 4 has been with a reduced set of extensions. Right now I have no idea which of my other extensions I will bring over to my Firefox 4 profile and which of them will have something useful on the Add-on bar. (I feel your pain about making a decision without the right data, I've been in that situation often enough.)

Comment 27

7 years ago
Created attachment 514893 [details]
This is how i like my addonbar

@Jennifer: as you can see, I really like my applications clean and minimal, too.

But you can’t collect data about how many people would like the addon bar like this (small, in the corner), if you don’t add support for it. The addon barlesque doesn’t tickle my fancy, because it makes the bar huge, and if i restyle the bar, i can as well do everything inside the userstyle (on my windows install, i used “-moz-appearance:tab” in my userstyle: http://userstyles.org/styles/39555)

You may get a number by adding up the installs of barlesque and any addon bar userstyle doing this)

to sum it up: there is another usecase of the addonbar where getting numbers of how many use it is hard. not everyone wants a full-width bar, no matter if toogleable or permanent.

Comment 28

7 years ago
Created attachment 514937 [details]
Enable/Disable "Add-on Bar" in menu...

(In reply to comment #25)

So if you want minimalism just remove it!
We have plenty of option by enable/disable. By keyboard shortcut (CTRL+/) or simply by menu. Why devs always complicate everything.
(In reply to comment #27)
> Created attachment 514893 [details]
> This is how i like my addonbar
> 
> @Jennifer: as you can see, I really like my applications clean and minimal,
> too.
> 
> But you can’t collect data about how many people would like the addon bar like
> this (small, in the corner), if you don’t add support for it. The addon
> barlesque doesn’t tickle my fancy, because it makes the bar huge, and if i
> restyle the bar, i can as well do everything inside the userstyle (on my
> windows install, i used “-moz-appearance:tab” in my userstyle:
> http://userstyles.org/styles/39555)
> 
> You may get a number by adding up the installs of barlesque and any addon bar
> userstyle doing this)
> 
> to sum it up: there is another usecase of the addonbar where getting numbers of
> how many use it is hard. not everyone wants a full-width bar, no matter if
> toogleable or permanent.

We actually considered a design like that early on, but dropped it because it creates a non-rectangular browsing space that blocks any content anchored to the bottom right of the page.  It's a similar problem to the temporary but flickering server messages on the bottom left of Firefox currently (another issue for another day).

Comment 30

7 years ago
ok, i'm glad to drop the addonbar as soon as bug 598929 is fixed. until then, i need it, because some addons use the old statusbar until they are forced to use toolbar buttons.

at least stylish, scriptisch and firebug are (finally) fixed. adblock plus had both kinds of buttons from the start. without all of these i couldn't live :)

Comment 31

7 years ago
Minimalism is all very well, but surely personal tastes should be accounted for. After all the main firefox page says 'Your web, the way you like it:' with easy customization being one of the key advantages of firefox.

Therefore as opinion is divided i don't think forcing either view is the best plan. Sure having a close button on the addon bar by default (so that users are aware of the feature) is fine if those users, such as myself, who dislike it's presence there can remove it.

It doesn't really matter how the removal of the button is effected but i think it should be a 'proper' option that doesn't involve editing css files in the profile folder as it currently does.

That way users from either viewpoint can be happy.
My FF4 is now really minimalistic, but the close button on the addons toolbar is more than annoying. I see two solutions:
1) Remove the close button it or make a setting to toggle it (the button alone). Make a toolbar button (draggable to any other toolbar) and/or keyboard shortcut to toggle it
2) Make a button like in the earlier FF4 betas, where the addon bar could be hidden on the side of the window. We don't need to hide it entirely on the window chrome, as shown by #4, it could be a square button, taking a 15x15px space from the current website, that when clicked would open the addons bar completely or just enough for the addons used.
Duplicate of this bug: 645091

Comment 34

7 years ago
i have an idea:
make the addon bar small into the right corner, but right next to the horizontal scrollbar instead of north or above (covering) it.

there already is a widget to resize the window on some OSs, but we could put the addon bar left of it, collapsible with an arrow (if you use firefox inside a small window and viit a page utilizing a horizontal scrollbar)

what do you people think about that?

PS: on a page without horizontal scrollbar, it would look quite like https://addons.mozilla.org/de/firefox/addon/minimize-addon-bar

Comment 35

7 years ago
This idea is actually quiet good. Might be the reason I already thought of it two month's ago. ^^ (But I don't think I came up with it first either. ^^)

Problems that might arise here:
- When no horizontal bar is visible the bar still leaks into the browser frame.
- As I understood it, the scrollbars are part of the main-browserframe and manipulatint them is tricky. (I tried to do it with a pure css-style and it proved (for me at least) impossible.) A possibble solution might be, too hide the actual scrollbars, create a new set, that is repositionable, place the horizontal one into the browser-bottombox and the shorten the vertical one and link them to the mainframe.

Comment 36

7 years ago
you can do it via xul, i saw someone writing how exactly, but i forgot the term.

it sounded like “making the elements buddies” or sth. like that :)

Comment 37

7 years ago
Thanks for the hint. I'm looking into it. This would be a great project for an extension, but this bug report is still about removing the closebutton from the addonbar. Might be worth to open an own enchantment bug for it.

Comment 38

7 years ago
Looking at comment 29, it seems this will indeed be backed out.

Updated

7 years ago
Duplicate of this bug: 647450

Comment 40

7 years ago
What's the status of fixing this bug ? Any plans ?

Comment 41

6 years ago
could they at least add a "close button" on the close button to remove it somehow and make it optional instead of a permanent useless button?
The close button can be converted to a special button which can be added to multiple toolbars like the spacer and the separator.

Comment 43

6 years ago
This is still open after over a year and a half? Well, I want to add my vote: make it a setting. I want to be able to remove the close button, as I always want my add-on bar available. My NoScript and RequestPolicy combination make using it an almost hourly affair.
We are an open source community and as such accept patches from volunteer contributors. If you are not happy with the progress on this bug, please feel free to contribute a patch. If you don't feel you have the skills or knowledge to do so, consider it a learning opportunity.
The add-on bar was removed in Firefox 29.
Status: NEW → RESOLVED
Last Resolved: 8 years ago4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.