On Thu, 31 Mar 2005, Matthew Thomas wrote: > > I would like the possiblity of putting a toolbar (icons only) > > alongside the menubar, a space which is usually wasted. That > > functionality would necessitate including a handle on menubars. > > No, that function would need only a handle on the toolbars. The menu bar > isn't going anywhere, it's just shrinking horizontally.
I assume that was a typo and you are suggestion this case would _not_ need a handle. To nit pick your nit pick if you are going to have the feature at all you cannot assume that people wont want to move the menubar on either side. The latest version of Netscape puts the menubar on the right hand side, which is reasonable if you consider a user that (reads left to right and is) left side dominant and who wants the items they use most - the toolbar buttons - on the left. (I dont use menus all that often once I know the relevant keybindings, and If I know the mnemonics I'll use them in preference to trying to hit the menus with the mouse.) The more salient Point is that this detail doesn't matter if menu bar handles are disabled by default. > As for rearranging toolbars in general, modes are to be avoided whenever > there is a non-modal or quasimodal solution available, so a "Lock the > Toolbars" mode is the wrong solution to this problem. It's a classic > example of Microsoft's usability staff being great at finding problems > (people rearrange their toolbars by mistake) but poor at choosing solutions. I'm not against the idea of turning this Customisability off by defualt (a small discovery penalty I think is worth paying). Applications that want it could include a menu item "View, (Toolbars,) Customise..." ideally backing on to a standard system for various options (like handles, icon/text settings, and even adding/removing buttons). > A better solution would be to get rid of the handles, and make the > entire toolbar draggable when the Alt key was held down. > That would make rearrangement similarly difficult to do accidentally, > but would also make it easier to do when you really did want to do it, > because the target area would be the entire toolbar instead of a tiny > handle. I don't recall exactly which keys are already tied in to the handling of detached menus (but there are some and I know because I needed them in Gnumeric a while back) but it will of course be necessary to have some control keybindings for detached toolbars. I expect this suggestion could be incorporated into any larger plan but I had exactly the same concerns about discoverability as David Christian Berg which is why I could only consider this as one detail among many. Couldn't find a good refence, best I could find was this old comparision chart made for a gtk Acessibility evaluation http://developer.gnome.org/projects/gap/keynav/gtk_menus.html Boilerplate: I'm answering a bunch of different questions and I've resisted the temptation to cram them into one mail, instead I'm adding this boilerplate conclusion to save people reading all my other warblings. At this point I need to file HIG bugs, a bug against gnome-ui-proprerties (and hopefully a patch) and then bring this all to the attention of developers, either through one of the lists or individual bug reports. Thanks to all of you for taking the time and showing an interest in this discussion. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
