Stemmed from bug 39447: The Add button in the sidebar is non-intuitive and misleading, because you can also remove panels from the menu that appears when you click it. I realize the checkmarks are indicative of this, but I still think it's confusing that in order to remove a panel, you click the add button. Anyone have any suggestions for better text?

`Customize ...', `Edit ...', or even just `...' would be better.

I would go with "edit" -- I don't think we have room for more than four letters!

Personally, I like a "Panels" button to produce the menu to turn panels on or off, and then a separate customize button for the customize sidebar dialog...but as vera said, we're very limited with space (unfortunately)

I agree with Vera: "Edit" is appropriate and sufficiently short. No ellipsis is necessary since the Edit label applies only to the menu and does not itself lead to a dialog. Reassigning to Sidebar for update post-beta2.

Edit doesn't make much sense to me and conflicts with the Edit menu. I also don't see how one would know to click an Edit button to turn panels on and off. Why not a Panels button with a Customize... option? (since really, you can customize the panels from the dialog)

Cc'ing John Gable. I think we're creating a real usability problem by using the word "tab" in some places and "panel" in others. Changing to "panel" here would just extend the problem to another part of the interface.

We have tested the name "panels" and we got strong dislike from every single person in each focus group for that name. We have data on this. Since real data beats opinions, we should *not* use the term "panels". As for "edit" or something else ("customize"), here is some additional data to consider. "My" personalized sites like My Yahoo and My Netscape are using (or going to use in Metscape's case) the term "edit". It is a short word that is becoming the defacto standard, which is an argument for "edit". I'm leaning toward "edit", but am happy with either "edit" or "customize" as long as it makes sense to the user and with what the user reads in the pop-up they get after clicking this button.

I suggested "Panels" because that is what we use everywhere else in the product. If research data has shown that "Panels" is very much disliked, then I'm not sure why the heck we've decided upon it -- but that's a different bug entirely and not within the scope of this one. Vera: let me know if you see where "tab" is used somewhere, because it needs to be changed to "panel". I still don't think Edit is a good choice here (it denotes clipboard options, but you're not doing anything clipboard-related. It also indicates that you can edit the sidebar or some aspect of it, but you're not really doing that either), but if that's the consensus.. Also, John, I think it was decided that Customize is too long (if it wasn't, we might as well just use Add/Remove)

Tabs was a really easy to understand term for the users I have seen in usability testing and customers during the beta 1 launch. Thats why settled on this term.

The tab issue is bug 45707; please comment ther.

<smiles> "Tab" is the term that was officially chosen for these thingies that we're discussing. Here's the style: "My Sidebar," never "Sidebar" by itself "Tab" and "tab," with initial cap in most places An informal effort has developed to change over to the term "panel." As the person responsible for explaining this to end users, I am pleading for a single term. Since "Tab" was what we settled on after usability research, and is what marketing is using, and (really important) is what users will see at web sites (as in, "add this Tab to My Sidebar"), I would like to use the word "Tab" everywhere, consistently. So, please don't change any occurrences of "tab" to "panel." The change should go the other way, as per John Gable and German Bauer. BTW, the other side to this is that these thingies have the physical appearence of tabs only in the Modern skin. This argument goes that calling them "tabs" will confuse users who choose the Classic skin (or other skins where these don't look like tabs). However, I believe that it would be far more confusing to call them "tabs" in some places, and "panels" in others.

Vera: I agree we need to be consistent, but I'm not sure that bypassing the argument that they might not resemble tabs in other skins (which I think is very valid) just to use "tab" is a good idea. I don't like "panel" either. But bug 45707 is the tab issue. Let's keep it there...

To break my own rule, one last comment: >However, I believe that it would be far more confusing to call >them "tabs" in some places, and "panels" in others. Well, of course. We would be consistent everywhere with whatever term we finally agree on.

To get back to the menu title ... JohnG is correct that My Yahoo and My Netscape use `Edit', but they use it for *buttons*, not for menus. (That's why I suggested `Edit ...' with an ellipsis; I was assuming this was a button, not a menu.) Having two `Edit' menus in the same window at the same time is just asking for trouble. Pick and choose one or more of the following solutions: * combine the menu functions into a dialog (especially since I'll often want to do some adding and some removing at the same time), and make the `Edit' menu an `Edit ...' button; * use a graphic for the menu, instead of a word (cf. the menu for showing columns in the tree widget); * get rid of the menu, and make `Customize ...' a context menu item for the tab part of the panel. (See? that's another reason you need to distinguish between tabs and panels.) Also provide `Customize Sidebar ...' somewhere in the main menus, for the same purpose.

I think it's kind of nice to have a quick, easy-access menu to add or remove panels, rather than having to deal with another dialog. However, I'm not sure I like the idea of using a graphic instead of text. I can imagine the graphic being very hard to identify, and users might think it's just a silly graphic.

over to german to flush this bug out and make a decision for beta3.

Ok lets sort a few things out here: 1. I think this bug should be split into the wording of the initial button, which I think "Add" is not ideally suited for it. However 'adding' is likely the activity users will do initially, so it *may* help discoverability. After seeing small number oif users I prefer something like Edit or Customize though. 2. the dialog and the flyout menu serve two *different* purposes: while the dialog lets you add a nd remove panels from a common pool of panels shared across sidebars of all compnents on mozilla, users wnated to have a way to turn off certain panels in some apps while showing them in others. So the flyout menu serves as a quick access point to turning on and off inidividual panels. I believe this behavor is specs on the sidebar spec of http://mozilla.org/projects/ ui/netscape/sidebar/ a bit below the middle. After we agree on 1) we should this bug and file a new one for 2)

I changed "Add" to "Tabs", not as a final decision, but just to get some feedback. I feel it's a little better, but it might suggest to the user that the tabs in the resulting menu are the ONLY available tabs. Also, German, I agree that we need to do something about point 2. So, what do you think about Add -> Tabs?

sidebar triage team: We all like the fact that it (the old "Add" button) now says "Tabs" and are happy to keep it that way. So marking this as works for me, where the correct way for it to work is for it to say "Tabs" > Changing summary to indicated "Tabs" is what we want. Thanks Blake for your work on this - we liked your solution.

No problem. Glad you like my solution...