Closed
Bug 112534
Opened 23 years ago
Closed 17 years ago
Remove collapse toolbar grippies
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: djm, Assigned: janv)
References
Details
(Keywords: polish, Whiteboard: Please don't comment with arguments, just vote. See comment 8 to turn them off.)
Attachments
(6 files, 4 obsolete files)
549.94 KB,
image/png
|
Details | |
26.14 KB,
image/png
|
Details | |
23.40 KB,
patch
|
caillon
:
review+
hewitt
:
superreview+
|
Details | Diff | Splinter Review |
1.39 KB,
patch
|
caillon
:
review+
|
Details | Diff | Splinter Review |
2.89 KB,
patch
|
caillon
:
review+
|
Details | Diff | Splinter Review |
26.21 KB,
image/gif
|
Details |
It would be good if there were some way to disable the toolbar collapse grippies. I find them annoying (never having found a use for them) and some less computer literate people I know have found them very confusing ("where's my back button gone?"). Some pref (or skin hack) to disable them entirely would be greatly appreciated.
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
(I played around with PhotoShop (see attachment) and think that Mozilla would look even cooler without the grippies :) I recently installed IE 6.0 to see how they're doing and really liked the new, grippieless look. I've always found the Netscape-style click-to-collapse grippies confusing, and there should definitely be a pref to disable them. Please.
I made a really simple patch that disables toolbar collapsing. You are still allowed to uncollapse collapsed toolbars, though. It removes two lines from chrome\content\global\bindings\toolbar.xml (line 262, in toolkit.jar).
Reporter: does the patch make you happy? Probably not. In other words, is this bug about making clicking the grippies not collapse the toolbars, or about hiding the grippies altogether? Probably later, but I think it could be read either way (the title should probably be reworded). I think there should be a bug for both cases. Which one this is? The grippies are not "collapse grippies", think of them as "handles" that can be used to drag the toolbars into a new place. This is rarely needed, unless you're a "power user". Also, inexperienced users often accidentally click or drag the grippies and do stuff they can't undo without assistance, which is the reason Microsoft (finally) added the feature to lock the toolbars (hide the grippies) in IE 6. And they turned it on by default. The grippies also have a weird side-effect (pretty much in Netscape and Mozilla only, if I'm not wrong) that when they're clicked, they collapse the toolbar. This, of course, is very confusing to users that aren't used to this behaviour. Bug 15322, toolbar movement, targeted for Mozilla 1.2, is still not fixed (and won't be for a while, I'm sure), which means that the grippies are more or less useless since the toolbars cannot be moved. I'm proposing the "useless-ui" keyword, since the mozilla 1.0 manifesto (http://www.mozilla.org/roadmap/mozilla-1.0.html) says that every ui element must do something useful.
beware: do NOT apply this patch if one or more of your toolbars are collapsed (they become hidden and can't be uncollapsed). This is a really ugly hack but it mozilla plenty pretty makes. This patch basically removes a section (<binding id="toolbargrippy" etc.) from the toolbar.xml file. I don't know how to do the fix properly but this works. Kind of.
Comment 7•22 years ago
|
||
In <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65067>, I specify that the bars should no longer have grippies, at all. They cause a host of UI problems, including lack of distinction between multiple collapsed bars, ugliness of collapsed state, ugliness of expanded state (which is what this bug is complaining about), and difficulty of cancelling a toolbar drag (since a non-drag click collapses the bar instead of doing nothing). However, the grippies should not be removed until the bars have a shortcut menu to make them easy to turn on and off, as shown in the `Chrome area shortcut menus' section of the spec.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
OS: Linux → All
QA Contact: zach → sairuh
Hardware: PC → All
Summary: Way to disable collapse grippies → Remove collapse grippies
Attachment #68808 -
Attachment is obsolete: true
Attachment #68818 -
Attachment is obsolete: true
I marked my ugly and silly patches obsolete. Please don't use them :) While waiting for a real fix for this, you can use this nice workaround: Add these lines to userChrome.css in your profile's chrome directory toolbargrippy { display: none !important; } This will disable the grippies (taken from http://www.geocities.com/pratiksolanki/userChrome.html)
Updated•22 years ago
|
Target Milestone: --- → mozilla1.1beta
Comment 9•22 years ago
|
||
Yes, we should definitely remove the grippies. A mechanism needs to be in place to automatically uncollapse any toolbars that the user had collapsed. Patches, anyone?
Keywords: helpwanted
Comment 10•22 years ago
|
||
Nominating for buffy, this fits the polish/usability improvements criteria well. Our usability studies showed that users thought this was for a variety of functions other than collapsing, such as showing icons only (no text) in the toolbars. This collapsing functionality is not useful, anyway.
Keywords: nsbeta1
Comment 11•22 years ago
|
||
It is my understanding that while usability studies can help identify problems in the interface they do not count as a representative sample of our target audience. Nav triage team: CC'ing Lori regarding usability study findings Blake mentions.
Whiteboard: [need info]
Comment 12•22 years ago
|
||
I don't know if it's representative of everyone or not. I haven't heard a case for why the ability to collapse toolbars is in any way useful.
Reporter | ||
Comment 13•22 years ago
|
||
In the absence of an IE-like way to stack or edit the toolbars, they are IMO completely useless. The ability to hide a toolbar is already (and more usably) provided in the menus. Can anyone make a case _for_ the grippies?
Comment 14•22 years ago
|
||
<http://portal.acm.org/citation.cfm?id=274657> presumably makes a case for them. I don't know what the paper says, since I'm not an ACM member, but I doubt it would change my mind. :-) Fixing this bug would resolve bug 47873, bug 48332, bug 50785, bug 57022, bug 89199, and bug 103515.
Keywords: polish
Comment 15•22 years ago
|
||
I've read the paper, and it goes through a number of alternatives (quite scary, to be honest, including vertically and horizontally-*tabbed* toolbars) and reaching this design at the end. It seems from the tone of it they were rushed because of a short development cycle and did not do any formal user testing until reaching the final design, which is the collapsable-grippy model. They say two important things about it: that the collapsed grippy's size was essential to the user discovering what toolbar it corresponded to, and that they needed to change colour and mouse shape on mousing over to suggest it was clickable (Mozilla breaks the first suggestion by providing the same size of grippy for any toolbar, and the second by not changing mouse icon, and IMO those are not good solutions to their problems, to begin with!) I am quite sure that anyone reading this document will entertain a notion of dislike for the features and the process they were designed through. I'd advocate removing this unusable feature from Mozilla, and implementing a proper solution (instead of a half-designed one) for toolbar size reduction. For now, the view menu will more than suffice for what is being asked for.
Comment 16•22 years ago
|
||
I omitted an important remark: that the design was produced for Netscape 3.0, and that the designers describe their target audience as business users using laptops or 14" CRTs at 640x480 pixels.
Comment 17•22 years ago
|
||
Updated•22 years ago
|
Attachment #93112 -
Flags: review+
Comment 18•22 years ago
|
||
Comment on attachment 93112 [details] [diff] [review] patch Well, for the lot of bloody good it does you, r=FrodoB. :)
Comment 19•22 years ago
|
||
Comment on attachment 93112 [details] [diff] [review] patch >+++ classic/global/win/toolbar.css 28 Jul 2002 23:07:37 -0000 >@@ -54,53 +54,6 @@ > > /* ::::: toolbargrippy ::::: */ > >-toolbargrippy { you missed a spot ;-b
Updated•22 years ago
|
Whiteboard: [need info] → [need info][geekweb-p1]
Comment 20•22 years ago
|
||
my vote: just delete them entirely (for now and the foreseeable future). If at some point, toolbars are customisable and draggable, then turn them back on, BUT, only as dragging, and only when users select the "allow me to play with my toolbars" preference. Collapsing is **************** useless and really annoying! I keep hitting them when I'm aiming for the menu or button. Thanks...
Assignee | ||
Comment 21•22 years ago
|
||
Attachment #93112 -
Attachment is obsolete: true
Comment 22•22 years ago
|
||
Comment on attachment 101522 [details] [diff] [review] up to date patch This patch only appears to address 37 of the 55 occurrances of toolbargrippy in lxr seamonkey tree.
Assignee | ||
Comment 23•22 years ago
|
||
thanks Neil, I'll attach a new patch
Assignee | ||
Comment 24•22 years ago
|
||
I hope, this covers whole tree
Attachment #101522 -
Attachment is obsolete: true
Assignee | ||
Comment 25•22 years ago
|
||
We can also remove files from directories: classic/global/toolbar modern/global/toolbar modern/communicator/toolbar except files still referenced from elsewhere: classic/global/tbgrip-texture.gif http://lxr.mozilla.org/seamonkey/source/themes/classic/communicator/sidebar/sidebar.css#144 modern/global/toolbar/tb-mid.gif http://lxr.mozilla.org/seamonkey/source/themes/modern/editor/editorFormatToolbar.css#43 http://lxr.mozilla.org/seamonkey/source/themes/modern/messenger/messengercompose/messengercompose.css#148 http://lxr.mozilla.org/seamonkey/source/themes/modern/navigator/navigator.css#472 modern/communicator/toolbar/prtb-bg-noline.gif http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/skin/modern/help.css#52 http://lxr.mozilla.org/seamonkey/source/themes/modern/communicator/brand.css#68 http://lxr.mozilla.org/seamonkey/source/themes/modern/communicator/toolbar.css#61 http://lxr.mozilla.org/seamonkey/source/themes/modern/navigator/navigator.css#347 modern/communicator/toolbar/toolbarBindings.xml http://lxr.mozilla.org/seamonkey/source/themes/modern/communicator/toolbar.css#47 http://lxr.mozilla.org/seamonkey/source/themes/modern/communicator/toolbar.css#79
Updated•22 years ago
|
Attachment #101540 -
Flags: superreview+
Comment 26•22 years ago
|
||
Comment on attachment 101540 [details] [diff] [review] better one yay. sr=me
Comment 27•22 years ago
|
||
So, talk to the mail/news and editor people and see if they're okay with removing the toolbar collapse grippies. You have my blessing, but we'll need to figure out a way to work around the profiles for which the toolbars are currently collapsed.
Comment 28•22 years ago
|
||
Bugs possibly affected by this : bug 12267 bug 48332 bug 50114 bug 50785 bug 60864 bug 128963 ? bug 130184 bug 135342 and bug 150162 (?) bug 167406 Apply it ! Apply it ! :)
Assignee | ||
Comment 29•22 years ago
|
||
Assignee | ||
Comment 30•22 years ago
|
||
we can also remove grippytooltiptext later
Comment 31•22 years ago
|
||
I sortof liked them, but I can understand how they would confuse many novices. It's certainly ok with me (for Composer) if the the conclusion is to simplify and remove them.
Comment 32•22 years ago
|
||
> we'll need to figure out a way to work around the profiles for which the
> toolbars are currently collapsed.
Change goToggleToolbar?
Assignee | ||
Comment 33•22 years ago
|
||
neil, goToggleToolbar uses hidden attribute grippies use moz-collapsed
Comment 34•22 years ago
|
||
"we'll need to figure out a way to work around the profiles for which the toolbars are currently collapsed." has that been figured out yet?
Assignee | ||
Comment 35•22 years ago
|
||
Jag suggested for example to remove moz-collapsed from toolbar element in its binding ctor. We can also add a cleanup funtion to xpinstall to remove moz-collapsed occurences from localstore.rdf (but how to deal with multiple profiles ?) And I just found out that we can remove moz-collapsed from xul.css entirely so even if there is such element with this attribute set, it won't get collapsed. It just needs to fix fullscreen.js, since it uses moz-collapsed attribute too.
Assignee | ||
Comment 36•22 years ago
|
||
mailnews team is ok with this fix too
Comment 37•22 years ago
|
||
jglick and mailnews module owners are on board.
Assignee | ||
Comment 38•22 years ago
|
||
Comment 39•22 years ago
|
||
Jan: one last thing: grippyhidden and grippytooltiptext attributes and entities?
Assignee | ||
Comment 40•22 years ago
|
||
my plan is to land core changes first and then remove these attributes and entities
Comment 41•22 years ago
|
||
Comment on attachment 101717 [details] [diff] [review] patch to remove moz-collapsed r=caillon
Attachment #101717 -
Flags: review+
Comment 42•22 years ago
|
||
Comment on attachment 101540 [details] [diff] [review] better one Man, I actually grippy collapse quite often (quicker than View > Show/Hide > ...) I wonder how many times I'll click over there with nothing happening... Oh well. r=caillon.
Attachment #101540 -
Flags: review+
Comment 43•22 years ago
|
||
Comment on attachment 101665 [details] [diff] [review] additional patch for mailnews r=caillon.
Attachment #101665 -
Flags: review+
Assignee | ||
Comment 44•22 years ago
|
||
patches have been checked in perf wins: Txul: 2-3% Ts: 1-2%
Comment 45•22 years ago
|
||
If it's not too late, please consider leaving a non-displayed box with image in the grippies replacement (giving it some meaningful ID.) The Sky Pilot theme (perhaps others?) used the grippy background (in conjunction with #throbber-box) as toolbar end-caps to give the toolbar a unique look.
Comment 46•22 years ago
|
||
On further thought, only a box with an ID is needed since I could accomplish this same effect with a background-image statement; rather than a list-style-image statement.
Comment 47•22 years ago
|
||
Please ignore my last comment #45 and Comment #46, I've figured a way around the problem.
Comment 48•22 years ago
|
||
Patrick: You said you already found a way - nevertheless I want to remark that it's easily done with a bit of XBL magic as I used it LCARStrek theme (for end caps at the right, I think now I also must add them at the left) ;-)
Comment 49•22 years ago
|
||
Hi Robert, I was able to use #throbber-box for the right-hand end-caps. For the left, I ended up moving the toolbar background from ".toolbar-primary-holder" to ".toolbar-button-box", throw in some margin adjusts for the mast icon and .toolbar-primary-holder (depending on if the icon was displayed) and finally using .toolbar-primary-holder for the left end-caps. I say end-caps since they are different depending on [toolbarmode="small"] (navigator full screen) and [buttonstyle="text"/"pictures"] (new primary toolbar button modes.) Caveat: I also had to dork around with some of the other component .toolbar-primary-holder settings (specifically, navigator.css and help.css) but I think it would too detailed to list here. I can send you the changes if you want to take a look-see? Lastly, thanks for looking out for my backside. I have made binding changes before (tab toolbar and sidebar) but tend to seek other ways, if possible, so as to reduce down-stream maintenance problems.
Comment 50•22 years ago
|
||
Joonas: The IE Grippies DO APPEAR by default on all news installations of Win98, 2000, ME and XP. So your argument is based on a wrong assumption. When you installed IE 6.0, you probably already had the pref set in your registry that's why it installed with the grippies invisible. Try formatting your computer first before installing windows and you will see that the grippies do appear. Personally I am not in favor of this bug. Instead of removing them, we should work to make them work as expected: to be able to drag toolbars around.
Comment 51•22 years ago
|
||
Sorry, didn't mean to spread disinformation. However, I'm sure that the module owners et al. didn't make the decision to remove the grippies because I claimed that IE hides them by default, but because they thought the grippies were confusing to users.
Comment 53•22 years ago
|
||
Moz looks much better with them removed. I don't see much point in worrying about a pref until they actually do something useful, like rearrange the toolbars. And then it should be in the context menu.
Comment 54•22 years ago
|
||
I started up my nightly automated install of Mozilla today, and noticed something "not right" with the toolbars, but I couldn't put my finger on it until I delved into bonsai... While I think the UI looks nicer without them, and I admit that I (and most others) used them rarely, there is one slight problem There is now no way to hide the menu bar (err, collapse it). The menu bar is the only toolbar without an entry in View > Show/Hide, and it should still be collapsable. (I set up a kiosk with a non-fullscreen mozilla with the menu bar collapsed at my work. It was, at the time, very useful.... not secure in the least, but it kept everything hidden while still leaving space for other programs on the same screen.) I guess I can just go in and add some lines to my user.css to do the same thing, but I thought I'd mention it.
Comment 55•22 years ago
|
||
if this stays fixed, we should purge the tree of any toolbar grippy tooltips from the various .dtd files, too.
Comment 56•22 years ago
|
||
about full screen, yes, now with out the toolbar grippies we can't hide / show them toolbars whe in full screen. but I was able to go out of full screen, hide / show what I wanted, and then go back into full screen. that seems acceptable to me. I hope the grippy removal stays. what are the points against?
Comment 57•22 years ago
|
||
here are the bugs i see in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021008 [classic skin] 1. you can't show/hide the toolbars in venkman/inspector 2. when maximized, the file (ie first) menu appears displaced (perhaps by about one grippy width?) 3. the menubar is too tall [1-3px] (since it behaves like notepad its height should match), it should bleed into top of the window instead of having a bevel. some other things are probably just generic ancient bugs (or relate to me putting my sidebar on the right side): A. the quick search in address book bleeds into the left window border B. the quick search in mailnews bleeds into the (think) right window border C. the tabs area in navigator bleeds into the right window border Actually A-C might change (basically reverse which border i'm complaining about) if we fix: 4. there shouldn't be a left/right borders for the menubar i.o.w. it *should* bleed into the window border, as notepad does perhaps a better example is wordpad since it has toolbars and a menubar and no grippies. the toolbars should all bleed right into the border. 5. alt-space, right still doesn't work (dean has a patch, why doesn't someone sr it?)
Comment 58•22 years ago
|
||
Is there any chance this bug could be modified? Some sort of hidden pref for those of us who liked the grippies? I personally, due to a very small computer room setup, don't have a large monitor and use the grippies all the time to get a little more real estate. Buying a larger monitor to run at a higher resolution is a bit of a pipe dream right now. I understand they are somewhat non-standard, but once you learn what they do, they are *very* nice and honestly one of the reasons I have liked Mozilla for so long. I admit a general unfamiliarity with how things work around here (I've filed/commented on a few bugs, nothing much) so I obviously can't raise much of a stink. But I really do like the grippies, I use them a lot. Perhaps a tool tip could be added if the mouse hovered over the grippies? ("This will collapse the toolbar to free up browser space."?) Please reconsider! If I had a 19" monitor I wouldn't care... but I don't, so I do.
Comment 59•22 years ago
|
||
jmscott42: a) You can turn off all but the menubar using the View menu, so it isn't too harsh a regression. b) The grippies *did* have tooltips; however, tooltips are a bad solution to the inherent discoverability problem the grippies have. I myself was very annoyed every time I collapsed them and had to restore a specific one. c) The vast majority of users doesn't appreciate the tooltips, and think something is broken when they click by mistake on them (notice how close to the back button the middle one was) I sympathize with you as I used the grippies many times to do presentations using Mozilla. But this is too much a usability problem to be kept in. Somebody can code an XPI that adds them instead.
Comment 60•22 years ago
|
||
Anyone mind if I add my $.02? If you want to remove it, fine, just please add a preference somewhere (and make it obvious for all us dumb people) where we can get them back. I don't particularly like the full-screen mode, I think that the grippies were a damn good idea (I run with only one bar up normally - personal shortcuts, and if I need something I'll unhide the grippy - everything else stays hidden...), and I'm probably going to revert to an older version so I can get them back. I like a nice lean browser, real-estate wise, and I just don't like the full screen mode (if I want to use the taskbar at all, I have to hit the Windows key to bring it up, and then click a couple of times to get rid of it- a little too much effort just to find out the frickin time). Personally, it is a rather harsh regression, so I'd like to see it stay. Leave it off as standard, but give us a preference window somewhere for it. Just because it's not liked universally, doesn't mean it has to be expunged from Mozilla. Set it up as a pref somewhere.
Comment 61•22 years ago
|
||
Re: Comment #60 From michael_bourgon@yahoo.com 2002-10-12 09:56 > If you want to remove it, fine, just please add a > preference somewhere (and make it obvious for all us dumb people) where we can > get them back. While we're at it, why don't we add a pref to behave like IE? Yeah? No? Why not? *yawns* We have *way* too many prefs right now. A pref to add the toolbar grippies back is a * stupid* thing. An XPI to add the functionality back in is fine though. > I don't particularly like the full-screen mode, What does that have to do with this? > I think that the grippies were a > damn good idea (I run with only one bar up normally - personal shortcuts, and if > I need something I'll unhide the grippy - everything else stays hidden...), and > I'm probably going to revert to an older version so I can get them back. Just go to the View menu, "Show/Hide", and show or hide what bar you want shown or... er... hidden. > I like a nice lean browser, real-estate wise, Mozilla is not a lean browser. Try Phoenix. Or K-Meleon. > and I just don't like the full > screen mode I heard that. > (if I want to use the taskbar at all, I have to hit the Windows key > to bring it up, and then click a couple of times to get rid of it- a little too > much effort just to find out the frickin time). Um. That's not quite a Mozilla issue. > Personally, it is a rather > harsh regression, It was a regression that grippies were ever thought of. > so I'd like to see it stay. Leave it off as standard, but > give us a preference window somewhere for it. This is a feature a tiny minority needs - or thinks it needs it. Therefore, it shouldn't be anything more than an XPI-based add-on.
Comment 62•22 years ago
|
||
> just please add a preference somewhere
A feature used by 0.01% or less of our userbase isn't worth the XUL bloat to
keep it in as a pref. Eaither write an XPI you can install on your own builds, or...
Perhaps some more of the entries in the show/hide menu need hotkeys? That would
be of more general use, less confusing for other users, and satify your need to
often toggle of bars on and off. F4 & F5 for navigation and PT bar maybe?
Comment 63•22 years ago
|
||
Re: Comment #62 From Jeremy M. Dolan 2002-10-12 12:43 > F5 for PT bar F5 is common for "refresh" on Win32.
Comment 64•22 years ago
|
||
grippies were added due to usability testing data collected in the 4.0 timeframe. They were needed then and they are still needed and used now by many people, not a small minority. We still see usage in usability and have other usage data. This is a serious usability regression and will hurt a large part of the Netscape user base , which constitutes a large majority of the Mozilla user base. I'm not sure what usability data Blake is referring to. If it was the data from studies this summer, they did not show confusion about toolbar buttons. People use grippies to temporarily collapse toolbars when they need to maximize screen real estate and when they don't want to be bothered with features but want quick access to them. In terms of the confusion of collapsed state of stickies, that was tested too and tooltips fixed any issues that existed. Full screen mode and menu access are not sufficient replacements for this feature. Grippies need to come back and not as a pref. We _do_ have too many prefs.
Reporter | ||
Comment 65•22 years ago
|
||
I cannot imagine what usability data you must be collecting, but my experience with toolbar grippies has been universally negative. The two novice users who I introduced to Mozilla (from IE) both required my assistance to unhide their toolbars after miss-clicking buttons on it. When I showed them what went wrong, their reaction was (in each case) confusion - they had found the show/hide toolbar menu and played with it to no avail. The problems with the toolbar grippies are: 1. They are too easy to hit 2. Their function is not clear 3. They look like toolbar grab-boxes for detachable toolbars (which Moz doesn't yet support) 4. They duplicate a function (show/hide toolbars) provided elsewhere in the UI I agree that show/hide toolbars should be easy to use (e.g. should have keyboard accelerators assigned). Fixing show/hide (in a separate bug) would be much more usable than retaining these UI horrors.
Comment 66•22 years ago
|
||
> grippies were added due to usability testing data collected in the 4.0 > timeframe. This is incorrect. Grippies were added due to usability testing collected in the *3.0 timeframe*, and I seriously question the usability process they used to choose this functionality. This has been stated before in the bug (back in comment 15). (I have a PDF version of the original document by Irene Au and Shuang li published in the CHI 98 proceedings that I can't publically post due to ACM copyright restrictions, but I offer to send it to interested researchers if they contact me through email.) > They were needed then and they are still needed and used now by many > people, not a small minority. We still see usage in usability and have other Usage in usability? > usage data. This is a serious usability regression and will hurt a large > part of No, it was bad design, and its removal has already started helping our user base, since end-users (including my parents, which were two Netscape customers, and today run Mozilla) commonly have problems using the grippies. The problems with them have been hashed out before here and in other places. > the Netscape user base , which constitutes a large majority of the Mozilla > user base. I honestly suggest serious usability testing be done on the Netscape Communicator product if you believe grippies are still a good idea in a end-user, commercial, browser. And, at any rate, Netscape can add grippies in their Communicator XUL if they choose to intentionally harm their users. Let's not make improving Mozilla's UI impossible; it already is hard enough. Re-resolving FIXED. Please, let's take the discussion to the newsgroups, no sense in spamming innocents here.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
QA Contact: sairuh → claudius
Summary: Remove collapse grippies → Remove collapse toolbar grippies
Comment 67•22 years ago
|
||
discussion should indeed be in the newsgroups. just for reference - a couple of bugs have been filed about the missing grippies already - i've duped one to the other, and marked that WONTFIX following the discussion here. it's bug 175091.
Comment 68•22 years ago
|
||
I went back from 1.2beta to Mozilla 1.0.1 because of the grpippies. Don't take away the grippies! (At least, how do I get them back? Is there a line in the Preferences .JS files or anything to enable them on 1.2beta?) I think, a lot of users like the grippies as a distinct feature of Mozilla/Netscape. It doesn't have to be every bit like MS IE! BTW, if you like "copying", copy from Alias/Wavefront Maya! This high-end 3D design application, originally created for SGI Irix workstations, has grippies just like Mozilla.
Comment 69•22 years ago
|
||
Re: Comment #68 From Eugene Scherba 2002-10-22 13:45 > I went back from 1.2beta to Mozilla 1.0.1 because of the grpippies. > Don't take away the grippies! That's not really an argument on why you want or need them back. Most likely not because they look nice? > (At least, how do I get them back? Is there a line in the > Preferences .JS files or anything to enable them on 1.2beta?) This is the wrong place to ask. > I think, a lot of users like the grippies as a distinct feature of > Mozilla/Netscape. They were there because Netscape 4 had them. Netscape 4 had them because they were a - for that time - interesting way of moving around toolbars, and collapsing them. We're now in 2002, and collapsing toolbars no longer makes sense. We have "show/hide" in the View menu for that already. Moving around toolbars does not work in the first place. Until this is changed, there's no point in grippies for Mozilla. > It doesn't have to be every bit like MS IE! This is Sooooo not about MS IE. MS IE, btw, *does* have grippies. Only that you can turn them off since version 6/Win32. > BTW, if you like "copying", copy from Alias/Wavefront Maya! Yeah, cuz' a very-high-end 3d application is quite similar to a web browser when it comes to the interface / front-end. Uh-huh. > originally created for SGI Irix workstations, has grippies just like Mozilla. There are other programs who also do. Like MS Office. But that's totally besides the point. Unless you tell us what exactly you're missing, grippies aren't going to return.
Whiteboard: [need info][geekweb-p1] → [need info] BEFORE COMMENTING, READ COMMENT 69!
Comment 70•22 years ago
|
||
> Unless you tell us what exactly you're missing, grippies aren't going to return.
I guess, I have to tell you that in clear terms. I am missing an interesting and
DISTINCT way of moving around toolbars. Do you get my point?
Comment 71•22 years ago
|
||
Re: Comment #70 From Eugene Scherba 2002-10-23 10:56 > I am missing an interesting and > DISTINCT way of moving around toolbars. Do you get my point? Yes, I do now. But as I already pointed out, there was never a way to move around toolbars in the first place, in Mozilla. That feature is still being worked on, and until it's done, there is no reason for grippies to return.
Comment 72•22 years ago
|
||
I see. I will rephrase my plea: I am missing an interesting and DISTINCT way of COLLAPSING toolbars. Who needs moving tollbars?
Comment 73•22 years ago
|
||
OK! I now know that insanity and mob rule govern the mozilla application framework. Why would you want to break apps that third party devolpers are making or have made. toolbar grippies are usefull. Why would you want to remove this from the toolkit, toolbars.xml, just because the apps that mozill.org build using them suffer from usability issues - fix those apps don't change the toolkit. You can disable grippies, by not referencing then in xul and by styling them, without removing the functionality and breaking third party apps by removing this functionality from the toolkit. Is the point to drive developers away from building apps based on mozilla? Is the stabilty of the toolkit less important than than the few apps currently built by mozilla.org and their usability issues? Are current and future apps to be hamstrung by a constanly changing feature set in the toolkit? Is the idea to have developers constantly reinventing the wheel? The arument 'if you don't like it make your own' and 'we can't afford the xul bloat' smells - you are talking about a few lines of code. My reading today of the toolbars.xml shows grippies are gone. I PLEAD FOR SANITY. I PLEAD FOR STABILITY IN THE TOOLKIT.
Comment 74•22 years ago
|
||
This is not a bug. The grippies were removed by request of a few?! Please restore them in future versions of Mozilla. They are very useful because they enable the user to instantly toggle hide/view instead of having to go to the view menu to hide/view - a much longer procedure. Is IE the browser everyone dreams of? At the very least, I suggest that a pref.js option be created so that power users can restore the grippies while the less fortunate common users learn to live without.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 75•22 years ago
|
||
.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 76•22 years ago
|
||
This was very much a bug. Fixing this one fixed at least 10 other ones, see comment #28. Grippies are gone, and not ever coming back, at least not until we have moveable toolbars. If you want a faster way to toggle view/hide, go open a bug requesting a keyboard shortcut for it.
Status: RESOLVED → VERIFIED
Comment 77•22 years ago
|
||
That is already filed: bug 45532
Comment 78•22 years ago
|
||
Please: If you want Moz to be as "convenient as IE" then go vote for bug 45532 which is about adding a context menu for toolbars - exactly what IE does. IE has never had something like the collapsing grippies, as far as I know.
Comment 79•22 years ago
|
||
you might want to put this in the release notes.
Comment 80•22 years ago
|
||
"The ability to hide a toolbar is already (and more usably) provided in the menus." I cannot disagree more! If this were true, then why have toolbars in the first place? You could say this about EVERY function provided by the toolbar. Resorting to a menu is less efficient, which I relate to usability. The grippie is definately the most efficient way to hide/view toolbars. Even a context toolbar menu is less efficient than the grippie. "target audience as business users using laptops or 14" CRTs at 640x480 pixels." IMO the toolbars still eat a lot of real estate on a 12" notebook running 800x600 or a 13" notebook running 1024x768 with larger fonts. AND, if I enter a java app from a web page, I want to quickly minimize the toolbars. When I leave the java app, I want 'em back quickly. There are lots of reasons to minimize the toolbars. "You can disable grippies, by not referencing then in xul and by styling them, without removing the functionality and breaking third party apps by removing this functionality from the toolkit." I agree 100% with that. Removing them from the toolkit sounds like solving the "issue" with extreme prejudice.
Comment 81•22 years ago
|
||
I vote WONTFIX for this "bug". Saying it will fix several others is a cop out. I doesn't fix them, its just giving up. grippies for collapsing the bars are useful. "The ability to hide a toolbar is already (and more usably) provided in the menus." I also disagree with this, wholeheartedly. As essentially stated in comment #80, you might as well remove the bars altogether if you believe this bizarre argument. If fixing the problems with grippy behavior is beyond your abilities, ask for help, or just hide them by default & leave us who use them the option of bringing them back. Are you planning on eliminating every feature that has bugs? Might as well scrap the whole project.
Comment 82•22 years ago
|
||
"I cannot disagree more! If this were true, then why have toolbars in the first place? You could say this about EVERY function provided by the toolbar." Toolbars are designed to give rapid access to *frequently used functions*. Not everything has to go in a toolbar. The assumption going on here is that hiding/showing toolbars is not a frequently used function, therefore it doesn't need rapid access (grippies). I guess some people disagree and for them, the grippies are useful. However: - grippies DON'T hide the toolbar. They still use up a significant chunk of real estate, especially for a single collapsed bar. - once collapsed, it is not obvious what they are or which one is which. - many people accidentally click them and then cannot figure out what they have done It would be possible to hide the grippies by default (I guess), but that then requires another preference, and Mozilla already suffers from bloat in the preferences, so developers are being very careful about adding more. Some power users don't see this as a problem, but Mozilla is not just a browser for power users! The more preferences, the more confusing options for casual users. The concluding argument here, is that the grippies would be a lot *more* useful if they could also be used to move the toolbar, and if that were done then having a preference might be worth the trade off (like IE and the "lock toolbars" menu item). That functionality, however, is a fair way off and in the meantime it's not worth the tradeoff. Please try and see it from all sides and not just your personal point of view. Thanks
Comment 83•22 years ago
|
||
I never used grippies to hide toolbars because things like the personal toolbar take up almost as much space collapsed as they do normally. If I really need more room temporarily, I just hit f11. Easy. Even in 4.x which didn't offer fullscreen on UNIX, I removed them in the menus. I think Aaron did a great job summing up why they need to go. One more thing to keep in mind though. Instead of bloating Mozilla by still supporting them with a pref, you can always add the XUL/CSS back, or even the C++ code in necessary. Moz is open source, and most of the UI is run-time compiled/applied. This is great for those features (grippies) that one-in-a-million users (you) want.
Comment 84•22 years ago
|
||
A question: Will this "fix" be applied only on the 1.2x and later branches, or will it be imposed on 1.0x and 1.1x? Given the use of the feature in 3rd party apps as mentioned in comment #73, I would encourage you to not apply it to the earlier branches.
Assignee | ||
Comment 85•22 years ago
|
||
definetely not for 1.0
Comment 86•22 years ago
|
||
Just a note to the uninformed. Grippies were provided by the toolbox method of the toolbar.xml. Grippies offered an area for a tooltip that was set aside from the other tooltips that appear in toolbars to clearify the interface, a graphic to set the bar apart from the rest of the interface and when wrapped in the toolbox method they had the ability to be collapsed into the toolbox tray holder. In any skin the collapable feature, bug, was not required to be used nor was the tooltip or graphic area. Developers had a choice to use grippies or not. The usage, implementation, of the grippy feature, bug, in the modern and classic skin, was not so good and it is fine with me if grippies are not in those skins. Instead of fixing those skins, by wrapping the toolbar and menubar in a vbox in the navigator.xul and editing the toolbar.css in the modern and classic packages, it was somehow decided to remove this functionality from the toolkit completely. By fixing this 'bug' in the manner decided tooltips for menubars and toolbars are pretty much useless. Now any, all, apps that used this feature are broken - this includes skins and other xul apps that may have used this feature, bug, in their interface. Now all the xul documentation is broken, including the two published books. Instead of the mozilla.org developers needing to fix a few, 5 I believe, files they had to 'fix' many, many files - see comment #25 for a partial list. Now all third party developers must either remove this functionality from their interfaces or reimplement the toolbar.xml If any third party developers that would like to include grippies in their project they can contact me as I have a toolbar.xml that fixes some of the odd behavior of the toolbar.xml. Watch kiosk.mozdev.org for a gtoolbar.xml soon. If the mozilla.org developers would like to see a test case of no grippies in mozilla-1.0.0 or the updated toolbar.xml or how to correctly use it you may also contact me. I would like to see this functionality returned to the toolkit and to the developer community - the real people hurt by this 'fix'. If you want to flame me do it here please. I am sorry for this long comment but I feel no real discussion, understanding, of the usage of grippies has occurred and many missinformed assumptions have been made here.
Comment 87•22 years ago
|
||
I would like to make the following comments/statements: 1) I still use NC 4.79 for mail/news due to its maturity and functionality. The term "grippy" or "grippies" is never used to refer to the "vertical tabs" found on toolbars and window panes within this suite. 2) The "vertical tabs" have one purpose: to collapse/hide a toolbar or window pane with one click, and have it available again for a similar one click without resorting to keyboard or menu access. Toolbars in NC 4.79 are moved up/down by left-click-hold on any portion of the toolbar in question. Vertical tabs were never intended for this purpose; this isn't their function. I don't know how it came to be thought that vertical tabs were designed as a "grip site" for dragging. 3) A mouse motion of one click = toolbar or window pane collapsed, or uncollapsed, does not equate with the string of mouse motions going up to the Menu Toolbar, clicking on View, sliding over to Show/Hide, and clicking on the toolbar one wishes to show or hide. There is definitely a time and mouse motion difference between the two options, and the vertical tab method provides a faster, more accessible functionality. 4) As a pleased user of Mozilla 1.1 browser, I am extremely disappointed by this decision. I feel it was made arbitrarily, without accurate, real-world feedback on how the vertical tabs were used. It was also made on faulty information as to the primary function of vertical tabs, not to mention a gross misnomer of the feature itself. 5) This "bug" only received 4 votes: how did it come to garner so much attention that put it among the front runners to be fixed for 1.2 final? Especially when there are larger issues with still-unaddressed memory leaks. This whole situation is rather baffling... I would like to petition the developers to reconsider this decision based on a poll taken through an appropriate newsgroup, regarding real-world usage of the vertical tabs in Mozilla 1.1 and 1.2b. Given the sweeping change the removal of vertical tabs has required in the toolkit and toolbar.xml, I don't believe this is too great a request. Vertical tabs are functional and do serve a purpose. I don't believe they should be discarded in such a cavalier fashion. Please reconsider this decision.
Comment 88•22 years ago
|
||
Hey, quite some people don't have 17" screens. I use the 'grippie' function to free more space for the browser window. With right-click some functions can be done also which are ob toll bars. So please leave the function. Bernard
Reporter | ||
Comment 89•22 years ago
|
||
Please stop spamming this bug and go and vote-for/work-on bug #45532 instead - It will allow you to do everything the grippies did without causing confusion for new users.
Comment 90•22 years ago
|
||
Sorry to be so late to the comment period, but this is a seriously bad idea. I've returned to Moz 1.1 simply to get grippies back. Switching between English and Japanese websites, it is often necessary to switch between 1280 x 1048 (English) and 640 x 480 (Japanese) for viewing grapic information such as floorplans and charts. I use the one-click switch option in Matrox QuickDesk to do so. However, once in the larger page mode, thre are two toolbars that are not immediately necessary taking up 1.5-2cm of the top of the screen. I have no objections to having the grippies off as a default if there is an "on" option for people who need them in a drop down menu, as M$ has done. Don't render a good product useless. CL
Comment 91•22 years ago
|
||
With reference to <a href="#c89">comment #89</a>: Damien, my intent is not to "spam," but to comment directly to the "bug" in question. And in response to your exhortation that I instead vote for <a href="show_bug.cgi?id=45532" title="ASSIGNED - Context menu for toolbars">bug #45532</a>, I respectfully refuse. Why? Because the proposal for toolbar context menus is not the same function provided by vertical tabs. The mouse motions required for using right-click context menus are, once again, not equivalent to the one left-click motion used by vertical tabs. In addition, with any piece of software there is a learning curve and a period of break-in. To remove a functional aspect of Mozilla on the grounds that it was "too confusing," even when this function had been successfully utilized in the Netscape Communicator package for years, is a weak justification at best, and a poor excuse at worst. Once again, I fail to see how a "bug" that garnered only 4 (now 5) votes received so much attention. If time had been taken to collect actual user data on the use of vertical tabs, I firmly believe the Mozilla developers would have received a different picture. I personally am dismayed at the degree of insufficient feedback on which this decision was based. I implore the development group to seriously reconsider this decision.
Assignee | ||
Comment 92•22 years ago
|
||
>I implore the development group to seriously reconsider this decision.
This decision was already reconsidered. The toolbar grippies will be added back.
Comment 93•22 years ago
|
||
I found it ironic that twice in the last few days I've seen CNN showing some web page, and both times they were using Netscape 6.x with the toolbars collapsed. Yes, the grippies are confusing, and can really screw users over. On the other hand, I bet we have another set of users and use them for presentations and aren't even aware of view->show/hide.
Comment 94•22 years ago
|
||
Jan Varga: do you mean the widget, or their usage in Mozilla ? Where is the bug for this ? Alternatively please point me to a discussion of the rationale. The existence of Phoenix^WWhatever makes any usability arguments for Mozilla itself pretty much beside the point (i.e. it is hopeless), but still ...
Comment 95•22 years ago
|
||
you've already seen the discussion and rationale that brought them back - it's in comment 64. i adapted bug 175091 into a bug for putting the grippies back in, if the netscape folks feel the need to have a bugzilla bug before changing mozilla code, that could be used for the purpose...
Comment 96•22 years ago
|
||
Well, if the grippies must come back can we have a "Lock Toolbars" in View - Show/Hide as well please (and not at some indefinite point in the future). This doesn't need to make the grippies dissappear, necessarily, just that it stops them doing anything. Should be trivial, right?
Comment 97•22 years ago
|
||
I don't want to start a discussion about it again, but me (and some other people) are really missing the grippies. They were nice to look at, and it is also a little bit complicated to go to the "View / Show/Hide" menu all the time you want to hide a toolbar. My proposal: until we have a nice solution, what about removing the grippies in the default theme, but allow other themes to add them again?
Comment 98•22 years ago
|
||
Oops... there is a separate bug about restoring the grippies: Bug 178185 .
Comment 99•22 years ago
|
||
This was backed out by bug 175091. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 100•22 years ago
|
||
Instead of removing the grippies totally once again, it would be useful if there where a possibility to hide them. I suggest a menu entry under View -> Show/Hide.
Updated•22 years ago
|
Keywords: helpwanted,
nsbeta1
Whiteboard: [need info] BEFORE COMMENTING, READ COMMENT 69! → Please don't comment with arguments, just vote. See comment 8 to turn them off.
Target Milestone: mozilla1.1beta → ---
Comment 101•22 years ago
|
||
I am in the camp of those who desparately miss grippies. I have three different computers and have to use small screen resolutions on all of them, making it very important to be able to temporarily maximize the content area of the browser. It takes a lot of mousework to hide the toolbars through the menus due to the fact that the you have to go into submenus. And how many people are clear on which thing is the "component toolbar", which is the "personal toolbar", and which is the "navigation toolbar"? This makes the menu method confusing, as well. How many people who have spoken out against grippies are using in 800x600 mode? Not many, i suppose. Those who have opposed the return of grippies on this bug have not addressed an important issue raised here--why the grippies were removed from the toolkit rather than from the themes. This is important because comments have indicated that people have built applications and themes which depend on grippies. Now we have talk again of taking out the grippies to fix the performance regression. If this is going to be done, can't we remove the grippies from the themes instead of the toolkit? This seems like a correct way to satisfy everyone. Those who like grippies can choose a grippy theme, those who don't can choose a different theme, and third party developers don't have to redesign their product due to a toolkit regression. If grippies are retained the toolkit (as i hope they are), then perhaps those that want them in the themes should file bugs, one on Classic and another on Modern, to move the grippies to the right-hand side, where they're much less likely to be clicked on accidentally. This might increase their chances of retaining grippies in the two default themes.
Comment 102•22 years ago
|
||
Please excuse my clutziness!!! I meant for the previous comment to go into bug 175091, not here. Sorry sorry sorry. (I know that the two bugs are intertwined, but i was referring to discussion on the other bug, and i haven't read the discussion on this bug to know whether all of the same issues were brought up here.)
Reporter | ||
Comment 103•22 years ago
|
||
This is stupid - why was this reverted without any investigation into alternatives? Even M$ gets this right in their browser where toolbars are locked by default. Why is Mozilla going backwards in usability?
Comment 104•22 years ago
|
||
> why was this reverted Because the decision to remove the grippies *entirely* was a tremendous mistake in the first place with so many people using and liking them. Heavily used features can be disabled by default, but you mustn't remove them like this. > Why is Mozilla going backwards in usability? Mozilla isn't going backwards in usability, just because "some" believe it is. Usability is very subjective in nature. I do really think that we should keep the grippies in the toolbox, so that they can be enabled/disabled via themes. This moving in/out of grippy code doesn't help anyone.
Comment 105•22 years ago
|
||
> Because the decision to remove the grippies *entirely* was a
> tremendous mistake in the first place with so many people using
> and liking them.
That's a matter of opinion. Backing out a bug, once it's been decided upon and
implemented, should not be done unless there is a valid technical reason for it
(such as peformance regression). As I understand it, the re-addition of the
grippies actually introduces performance degradation - does it not? Backing it
out should only have been performed after careful consideration and workarounds.
What was the *procedural* reasoning behind the decision here? It just seems to
me as if this is in violation of regular Bugzilla practices. If not, somebody
please explain to me why it was acceptable. (I'm not arguing for or against the
grippies, I just want to understand how this resolution was worked out. Just a
change of opinion on Jan's part?)
Also, if grippies *ARE* back (as decided by the module owner ?) - should not
*THIS* bug be now marked as WONTFIX? Surely, we can't always have one bug or
the other open at any given time, if they are in opposition to each other.
Or is Jan planning some kind of compromise?
Updated•22 years ago
|
Flags: blocking1.3b?
Comment 106•22 years ago
|
||
Does the workaround in comment 8 still apply? I suspended downloading new builds when the bug 175091 fix went in.
Comment 107•22 years ago
|
||
> Does the workaround in comment 8 still apply?
Yes. [Mozilla 1.3b; Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b)
Gecko/20030123]
If there're no *severe* performance or functionality penalties, the grippy
*code* should stay. Loved by many, hated by many - let's discuss the default
setting and keep the possibility to change it for those who want to. Anyone
should be able to live with some lines in his userChrome.css.
Comment 108•22 years ago
|
||
Personally, I think it should be reversed (if the code is to remain). No grippies by default (new users to Mozilla will never miss their absence) and people can add CSS to put turn them on.
Updated•22 years ago
|
Flags: blocking1.3b?
Comment 109•22 years ago
|
||
> No grippies by default (new users to Mozilla > will never miss their absence) and > people can add CSS to put turn them on. But I think they should be turned on by default so new user can know that they exist. Bug 175091 shows that many people love they, so it is also a inducement for using Mozilla. If someone think the grippies are bad they can turn it off, but this should not be done by css but by a preference in the UI. New user don't want to make additions to files to change a pref. And I don't undestand why some people think that many prefs in the UI-Dialog should be deleted, one point that I (and I think very much other) like in mozilla are the count of preferences.
Comment 110•22 years ago
|
||
With build 2003012508 (win95) I cannot hide the grippes with the workaround given in comment 8 :-( Can anyone else confirm this?
Comment 111•22 years ago
|
||
Workaround still functioning with Mozilla 1.3b [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030125]
Comment 112•22 years ago
|
||
The workaround, thankfully, still works for me too.
Comment 113•21 years ago
|
||
*** Bug 209154 has been marked as a duplicate of this bug. ***
Comment 114•21 years ago
|
||
Make it a Preferences option, enabled by default (in the Appearance section)?
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 115•19 years ago
|
||
*** Bug 229480 has been marked as a duplicate of this bug. ***
Comment 116•19 years ago
|
||
*** Bug 292436 has been marked as a duplicate of this bug. ***
Comment 117•17 years ago
|
||
We went into extra effort to get grippies back into toolkit-based SeaMonkey, this bug is WONTFIX for SeaMonkey (suite), while it's FIXED for any other toolkit-based app.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 17 years ago
Resolution: --- → WONTFIX
Comment 118•17 years ago
|
||
I read almost the whole list of comments and the huge majority of comments (basically except those of developers) are asking for the grippies to be removed, so we can safely assume that, based on the number of comments, most Seamonkey users dislike those grippies.
You need to log in
before you can comment on or make changes to this bug.
Description
•