From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; N; WinNT4.0; en-US; m14) BuildID: 2000032409 The sidebar should have a close button (e.g. an 'X') next to the existing 'customize...' button. Clicking on this would have the same affect as the "View|Sidebar" menu option but would be more obvious. Reproducible: Always Steps to Reproduce: none needed

more ideas for german, but who would ever want to close the sidebar? :-)

Not a good idea. When (not if) the user hits the 'x' accidentally, he/she will probably spend at least a minute trying to figure out how to get the toolbar back. I'm sure you guys would do better with the interface here than Microsoft did with Outlook Express (when you kill the oe sidebar, a non-control becomes an "invisible" control to let you re-open it; view menu says nothing), but it will still be confusing. If the user wants to collapse the sidebar, they can. If the user wants to get rid of the sidebar, they probably want to get rid of it permanently, so the menus should work fine (a hint in "customize..." about how to turn it on and off wouldn't hurt, though). If the user actually wants to get rid of the sidebar and then bring it back, why confuse them by giving them an extra control to turn it off that doesn't indicate how to turn it back on?

I disagree that an X will confuse users (well I would wouldn't I?). Most users know what an X does, so the only issue is how to make sure they know how to get the panel back. A one shot message box would take care of that, informing them that they can turn the panel back on from the menu. The point of having an X is that it's more convenient to use and a visual clue that the sidepanel can be gotten rid of.

spam: changing qa contact on sidebar bugs from paulmac to shrir@netscape.com (all 67 of them!)

Duplicate of 32662? Although people seem to be paying more attention to this one. Sure, add an X. Make it look even MORE like Windows :-).

Well, adding an X is one option (which doesnot work so well on Mac), but there are alternative solutions. We have found that opening the sidebar is also not very discoverable. So I'd rather call this bug "Make open and closing the sidebar more discoverable", and tackle the problem from this angle. Also there is a difference between closing (what the grippy does) and completely removing the sidebar (what the view menu currently does). This is somewhat analogous to toolbar behaviour, but certainly hyas potential for confusion.

*** Bug 32662 has been marked as a duplicate of this bug. ***

adding to summary of bug, nominating for beta 2.

Updating to All for Platform/OS as this is a platform independent change to the sidebar. Will have to be looked at on all platforms (possibly individually). But like Paulmac said, "...who would ever want to close the sidebar? :-)"

Even this early on, and in the n.p.m.ui group (which you'd expect to be filled with fairly advanced users), there is still the occasional person wondering how to close the sidebar. A Close button for the sidebar would solve this problem. And I agree with Adam: just pop up a message the first time the user ever closes the sidebar, telling them that they can open it again from the View menu. Resummarizing because an `X' is only appropriate on Windows. Adding 4xp, as IE versions 4 and higher have an `X' button on their sidebars. Adding pp, because while this needs to be implemented for all platforms, it needs a different XUL overlay and graphic for each one (an `X' on the right for Windows, a square on the left for MacOS/Unix/BeOS, etc).

If they can't figure out how to close the sidebar, they're definately not going to be able to figure out how to get it back if they click close accidentally. I'm assuming there will be an alert telling users how to turn it back on, coupled with "Show this message next time" (or "Don't show this message next time"), when they click the close button.

Interesting comparison: my friend accidentally clicked the grippy for the navigation toolbar in netscape 4.7. Naturally it rotated to its "closed" position and hid the toolbar. He came to ask me how to get the toolbar back, and didn't even know what he'd done to make the toolbar disappear. Once I told him to click on the grip he got it back easily. Perhaps if a dialog had popped up showing a little picture of what he had done he would have been able to grasp the concept immediately. As for "View/Sidebar," I've found that users don't know what the "view" menu is for. If users knew, then they would look there, right?

Move to M18 for a later UI polish.

Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.

welp...5/16 has come and gone with no comment and no change on this bug. Removing nsbeta2+ designation for reconsideration or new timeframe (in comparison with the other larger, feature/crasher bugs, is this enhancement really a beta2 necessity?)

[nsbeta2-]

In addition to a close button, we might also want an open button to make this more discoverable. Lake is doing some usability tests to see if we need the make opening and closing more discoverable. nominating nsbeta3

that not bad idea they should add a closing button on the sidebar menu

*** Bug 46171 has been marked as a duplicate of this bug. ***

Alfredo, what do you mean by sidebar menu, there is no menu there as far as I can tell. As far as an open close mechanism, we have talked about a button being next to the bottom part of the right edge of the sidebar frame, sort of like a handle reaching into the status bar. The problem right now seems to be implementation across themes. Also some newer usability data points indicate that opening/closing is not such a big problem as originally feared. Also, making the grippy clearer will help solve this bug (see bug 30595)

for my two cents I think the real concentration should be on making the grippy more obvious. Looking at the classic skin the sidebar grippy really looks 'grippy' and indicates that something useful might happen if you were to click/drag it. We should try something similar for the modern skin. If you go with the close box(X) it won't be long before someone wants the minimize button(—)(the horror!). Plus a box on the left for the mac is gauranteed to look dumb. Also, adding the (X) is akin to saying the sidebar is a window and then I would expect the way to open it would be File-->New-->Sidebar. Which I think would be horrible too. I think the grippy is a great idea and clicking the same widget to open/close is much better IMHO. So can't we just make it better?

See also bug# 31684 (a duplicate, I think.) As I wrote there, the best I've come up with for this problem (pretty much in order of goodness): adding a "Close sidebar" option to the sidebar menu (Tabs right now), making the "Tabs" menubutton not right-margin-bound, or always putting the close button on the left.

sidebar triage team: nsbeta3- We think improvements in the grippy will make this more discoverable.

So..should this bug be closed as wontfix or do we plan to implement this in the future? Thx!

What kind of grippy improvements?

*** Bug 31684 has been marked as a duplicate of this bug. ***

Discussion of the grippy is irrelevant, as the grippy can not be used to close the sidebar -- only to collapse it. Scaremongering about the need for an `Open' button or a `Minimize' button is similarly misguided -- neither of these is necessary, the need here is for a means of *closing* the sidebar which is more obvious than an item in the `View' menu. Windows: +-------------------------+ |My Sidebar [Tabs v] [X]| +-------------------------+ Mac OS: +-------------------------+ |[_] My Sidebar [Tabs v]| +-------------------------+ Other platforms: +-------------------------+ |[X] My Sidebar [Tabs v]| +-------------------------+

Mat: The grippy dicussion is relevant to this bug. people use terms 'close' and 'collapse' interchangeably in this bug as well as users that we had we looked at in the usability lab. The menu action in the 'View' menu is often referred to by users as 'completely hiding' or 'removing' the sidebar. Most users care about the former, wanting to make room for content temporarily. Some grippy issues are currently being addressed: - Modern skin grippy is in process of being updated (already has happened in the latest builds) to make more visible and better indicate motion direction. - Classic grippy worked pretty well in 4.x no changes planned here. Based on what we have seen and how the sidebar is used* we decided that a close button does not make sense in this context as in this design we do not have a counterpart in a similar position that would re-open it. *) The sidebar is used differently than say the left area in IE5. Most sidebar tabs are used in parallel for monitoring information (ie buddy list, stock ticker, CNN news) that updates while most of the IE5 functionality in this area is used for short-term intermittent tasks.

the mechanism used to open the IE "Search,Favorites and history" would be fine for mozilla too. it does not matter whether you want to monitor quotes the whole time or just access a single quote temporarly opening AND closing the sidebar with one click would be fine anyway

From what I have seen in the lab and outside the current design with a clickable grippy seems to be working pretty well for btoh modern and classic. Marking wontfix.

The rest of us don't have access to your usability lab of wonder. Reopening this for further explanation, because I often find myself going to close the sidebar at the click of a button (as in IE), but I can't. Yes, close -- not not collapse. I think this is especially important considering the sidebar opens and shows itself (to show search results) if you're searching at a site and you have the right pref on, since most people would want to completely close it again when they're done navigating the results (that's the state it was in before they searched). Of course, most people don't want it to open in the first place, but there's another bug on that.

http://www.macfixit.com/ultimate/Forum21/HTML/000032-2.html: "Took me awhile to figure out how to hide that annoying side bar....they didn't make that "button" on the edge very obvious...so they obviously want you to keep it open." Reassigning to me. UI discussion about this is fine and welcome, but I don't think this needs to be assigned to someone who isn't going to fix it.

Wow, there's a lot of discussion on a bug that's, to me, really straight-forward and obvious. Adding Matt's implementation along with the one-time message suggested by Adam won't harm the interface at all, and from the sounds of it at least a few people will be less confused. I'm all for it.

Possibly a dialog comes up when the user hits the X? Since you've determined that the view menu is not discoverable, tell them that's where this lives, so they can reopen it. Something like, 'This will completely remove the sidebar from all windows, are you sure you want to do this? To reopen the sidebar, go to view > My sidebar', as well as an option to kill the dialog on following closes.

I've changed my mind about that. A dialog shouldn't come up for something as trivial as a windowing operation (which is basically what this is), unless the user is risking data loss (e.g. `Save changes to foobar.html?'). For a dialog to come up when I close the sidebar would be quite annoying, even if it only happened once.

I'm with kerz. Having the sidebar disappear, and not being able to figure out how to get it back quickly, is more annoying than seeing a dialog the first time you try to get rid of it. Nominating for mozilla0.9. I think I've seen some NS 6.0 reviewers complaining about the sidebar, so having an obvious way to get rid of it would be good.

spam : changing qa to sujay (New Sidebar QA)

I think the attached patch should at least get us started here. It places an X button at the right edge of the sidebar header and clicking on it is equivalent to selecting View|Sidebar. No warning menu for now, because I don't know how to save the state to remember whether it's been shown or not (I'm just learning this stuff, so any comments or pointers will be welcomed). Also, I wasn't sure which one of MANIFEST and makefile.win had to be modified in addition to jar.mn to add the X gif to the right place, so I changed both of them. X gif should go to mozilla/themes/classic/communicator/sidebar/win/sidebar-x.gif You might notice that the button is not square when the mouse goes over it. I couldn't figure out how to do it without hard-coding 'width' in sidebar.css. Could anybody tell me if there is a way?

Davor, thanks for the patch. However, we need platform-specific overlays so that we can position the button as necessary (read earlier comments in the bug).

David, are you up for the task of platform-specific overlays?

We received lots of feedback about this from 6.1PR1. Most users can't figure out how to hide *or* close the sidebar, and are annoyed at the screen real estate it's using. We should do this for .9.2.

"We received lots of feedback about this from 6.1PR1" when, yesterday? We just shipped that bad boy.:-) for my .02 I still think this is a Bad Idea. If there was poor feedback from the 6 release I would imagine it had more to do with the slider not being distinct enough in the modern skin (like german has been saying). If indeed blake is privy to instantaneous feedback then, I've got nothing to counter that - but i still think it's clugey.

Sure, there's lots of feedback already... Actually, though, I think now that most of the comments (about closing the sidebar) were complaints about bug 85026. Still, some people expressed uncertainty at how to hide it at all.

Food for thought in passing... What about adding a Sidebar icon (with an Open/Close state/functionality) as the first item on the left-edge of the taskbar, just before the Nav icon?!

As a state widget? ie depressed when it's showing? we could also borrow microsoft's pushpin image ...

I actually just came across a user who submitted feedback requesting the same thing rbs is: "Dragging the sidebar with the mouse in and out a cumbersome (either for bookmark, search, etc). I would suggest to add additional button to the taskbar on the bottom left, next to "navigator, "mail" applets, which with one mouse click quickly drags (pops) the My sidebar on the screen. Or you might allow a right click on the mouse to pop the mysidebar instead of adding applet "

Sorry for being quiet for so long, school and other work demanded my full attention. I'm still not clear why the close button has to be platform-specific. Do you want to have the close box (not X) for MacOS because this kind of panel already exist in its UI guidelines? I thought this was a non-standard UI element, and it's not actually a window that we have to emulate each platform's window decorations. (IE 5 on MacOS uses a sort of vertical tabbed folders for this, which is totally different from the Windows version, but interestingly enough it doesn't use the close box either.)

usability/polish 0.9.4.

Once closed, one has to go back to the menu to re-open it, right? It seems more appealling to me to have a button on the taskbar to quickly toggle on/off the sidebar. There are buttons (like IM) that have established their own distinctive trademark. An eye-catching representative button for the sidebar could be invented as well.

rbs: F9

rbs: that's the subject of another bug (i don't remember the number)

Looks like this one has fallen on deaf ears. No action in weeks. This is not a stop-ship IMHO. Propose we move it out to a later milestone.

jaime, I understand this is not a stop-ship but let's please now do whatever has to be done to prioritize it for the next subsequent release. This issue has always been high on the annoyance list in every forum for feedback, in every release to date. As we fix everything else this will be the issue that climbs to the top - not devastating but highly visible. Looking at the comparisons to IE and Opera I think we have a superior 'click-on-the-fly' ability that they lack. For people who actually use the sidebar it's very convenient to oneclick it away and back as necessary whilst mousing around. if you don't use it often, then turn it off in the menu and it doesn't matter whether there is a grippy or an xbox or whatever.

It hasn't gotten lost in the shuffle, I've had a patch to add an X for weeks, unfortunately it was created right before leaving Netscape and has gotten lost in the shuffle. It's on an external hard drive of mine, though.

Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work. If anyone disagrees with the new target, please let me know.

Perhaps the most sensible thing to do in the short term is add a "Hide Sidebar" to the popup menu that appears when you click on the "Tabs" button. This would be trival to implement.

->0.9.6

A post in bug 41445 gives the upcoming plan for the context menu. Perhaps, adamlock's proposal can be considered over there.

Well, I did have a patch for this but apparently samir does now as well.

pchen, please r. blake, please sr.

This looks too complex...I didn't need to specify all that css styling and have more than one image. I'll dig up my patch.

Well, I can see this being done with an <image/> (only one .gif needed) but that doesn't really visually indicate the various states the user is in. I would treat the close button the same as any button; the same as the 'Tabs' button on the sidebar header which has various states. You may have got this working with the patch you are describing but I contend that we really need to capture at least three states: normal, hover, hover+active via different images. And this is achieved via the styling I have used. I can see how one could argue against the need for a distinct hover state image; in fact, classic doesn't use a distinct image: it's only modern that does so that it mimics the nav toolbar buttons and looks part of the skin. CC'ing Marlon and Ben for input.

My patch had all the hover states etc...but the toolbarbutton took care of all of it. I simply had to have a rule specifying the image. But I hadn't done Modern yet, and I'm not familiar with modern's structure, so I guess it might be necessary to have separate images for that...

OK, I understand why you were surprised by this patch then. Note that I am still to receive image(s) from gail for classic. As of now I have just tossed in the windows close button images which is a stop-gap measure. I see how you could have captured the states with the different style rules that <toolbarbutton/> specifies but don't think they will look like native buttons in classic. As I understand it, the point of classic is to make the widgets look like native ones, not our own manifestation. And as far as modern goes, it sounds like you are open to images for different states and hence you are open to reviewing my patch. If you'd like I can attach the images marlon has supplied. If there are outstanding objections please let me know and I'll address them. Thanks.

The button I added for Classic had exactly the same styling as the Tabs button that it is next to, and it looked good. I used an X that Asa sent to me. Sure, I'll review this soon.

I like Blake's idea. It seems much easier and more flexible. If, for some reason, we ever change the look of <toolbarbutton>, this button changes automatically.

Plan on landing early in mozilla0.9.7.

*** Bug 109495 has been marked as a duplicate of this bug. ***

The patch looks wrong. The close button should be the first item in the sidebar header, not the last -- so that you can use {float: right} or similar to put it on the right end in Windows Classic, and {float: left} or similar to put it on the left end in Mac Classic.

Can't use {float: right;} now since we are blocked by bug 113658.

Filed bug 113725 regarding the need for mac and windows classic close button icons. Hooked this up to the navigator teams external dependency tracker: bug 112941.

morse, please r. alecf, please sr.

Oh please, no tooltip on the close button!

Comment on attachment 60574 [details] [diff] [review] Patch rev 2: leaner CSS rules and tooltip for close button. r=morse

> Oh please, no tooltip on the close button! Why not? Windows Close buttons have tooltips (since 95, I think) and if it stops people confusing it with some sort of remove tab button then I think it's fine. Though perhaps text more along the lines of 'Close Sidebar' would be better.

Comment on attachment 60574 [details] [diff] [review] Patch rev 2: leaner CSS rules and tooltip for close button. Is there any way we can share the close-sidebar button's CSS with the close-tab button's CSS? that would make it easier for CSS designers to style the close buttons.

Alec, When I first did this work Hyatt mentioned that he had plans to remove the close tabs button. Actually, the images for this modern close button were done for the close tabs button. At this point, I'd like to get my patch in and leave the burden of factoring out the close button to a generic place up to the tabs folks.

Actually I'm not going to remove the close button, and we should share the same one. You should move the images over into global.

* How about oncommand instead of onclick: + <toolbarbutton id="sidebar-close-button" onclick="SidebarShowHide();" * I agree with Hyatt, these close icons are pretty enough that we could use them for tabbrowser. Could you just move the images into themes/modern/global/icons and themes/classic/global respectively? * Could you check in the disabled icon that marlon made? We could use it for the tabs close button.

(*) Moved images and CSS to <theme>/global. (*) Added the disabled close gif for modern. (*) Changed onclick to oncommand. I'd really like to get this in for mozilla0.9.7 so we can start getting usability feedback on this. morse, mind reviewing again? alecf, please sr. Thanks.

Comment on attachment 61165 [details] [diff] [review] Patch rev 3 addressing reviewer comments. r=morse

Comment on attachment 61165 [details] [diff] [review] Patch rev 3 addressing reviewer comments. Ok, this looks alright to me. sr=alecf, but I welcome hewitt or another UI guy to have the final say

*** Bug 114568 has been marked as a duplicate of this bug. ***

Checked in.

Did this cause the creep in startup time from 6.27 -> 6.31 Can you check. Reopening bug to make sure this doesn't get lost.

I think it is ok if the creep is post window open and doesn't delay window open.

Heh, first I was going to say "this is just because that test started reporting the median of the window open times, instead of the average". But then I looked at the raw numbers in the log, and the minimum went up. But then I looked at law's checkin (which I missed earlier) and it now adds a little unnecessary work to interval that we measure [should grab the time just before the window.open() call is made, and don't do anything in between]. So, I don't think window open times truly went up, but it would be a useful tweak to avoid measuring anything that is not actually part of the window opening time.

> Heh, first I was going to say "this is just because that test started > reporting the median of the window open times, instead of the average". Em, "reporting the median ... instead of the _minimum_"

jrgm, I was looking at startup time. Measurement of that is independent of these window open hooks.

danm file dbug 114797 for me to check the effect of my checkin.

The "x"checxkbox to close the sidebar is the worst innovation yet. I tried it on the Dec 13 nightly not knowing what it was for and lost the sidebar. I went to the view menu and restored it, but upon opening an new windoe it was gone. It also caused the ULR bar to disappear. This feature needs more work and rethinking. At a min. there needs to be some text next to the checkbox such as "close sidebar." The omnly way I could restore the sidebar when a new window opened was to launch 0.96 and reset it. Unless this feature is fixed so that it doesn't cause all subsequent new windows to open without the sidebar (no tweaking of prefences can reset new windows with the sidebar) IMHO this feature MUST be removed from the next milestone 0.97. I am using Mac OS 8.6.

Paul, if this widget closes the sidebar, then it is working. I'm not seeing the other defects you mention, but if you still encounter them in recent builds, please file new bug reports.

"X" does indeed close the sidebar using 2/4 build. marking verified. If there are other bugs, please file them separately.

Filed bug 150256 because of the ignoring of comment 10, comment 21, comment 27, and comment 41.