On Tue, Jun 26, 2001 at 06:47:28PM +0100, Calum Benson wrote: > colin z robertson wrote: > > > As always, tell me if I've done anything wrong or if there's anything > > that you can't understand. I apologise for the fact that this is even > > less interesting to read through than the dialogs stuff. > > Looks fairly non-controversial so far :) Here are my comments... > > > File menu > --------- > > Mac standard or not, I've seen "Close" and "Quit" in the same menu cause > considerable confusion before. People sometimes hit "Close" expecting > it to close the application rather than the document, and sometimes they > hit "Quit" expecting it to close just that window rather than all the > application's windows (e.g. in the Netscape/Mozilla model). The > confusion isn't helped by the fact they're right beside each other on > the menu. Agreed. There's also the more philosophical problem of whether Quit should affect windows which otherwise appear to be separate, and whether there should be multiple independent instances of the same application running simultaneously, since it's then not clear which windows will be affected by Quit. > Since "Close" only makes sense in a document-based app, perhaps it would > help to always include the relevant document and application name in > those menu items? E.g.: > > Close myhomepage.html Ctrl-W > Quit Mozilla Ctrl+Q Yes, I quite like that. > Or if that idea doesn't appeal, perhaps the recent files list could be > used to separate the two items instead, to minimise the risk of error, > since presumably any app that has "Close" should also have a recent > files list? That is: > > Close Ctrl-W > --- > <Recent File list> > --- > Quit Ctrl-Q > > (This admittedly brings the recent file list back out of the sub-menu > you've suggested for it, but personally I prefer that as it's supposed > to be quick to access. But maybe I'm just too used to the Windows Way, > I guess the sub-menu is still quicker than the File>Open dialog.) I'm more in favour of having the recent files in a submenu simply because I like to have an enormous list (NEdit gives me 30, but I want more) rather than the four or so that you typicially get with Windows apps. You could still put Close up with the file access commands even if you didn't have recent files in the main menu. > "If the window being closed is the last open window of that application > then the application should exit." Hmm, I'm not sure about this one at > all, people often want to close all their open documents before they > start a new one, so they'd be rather annoyed if the application closed > before they got the chance. True. How should this work then? Should the last close put an empty/blank document in the current window while other closes remove the window? > On a similar note, I'd quite like to see a "File > Close All" menu item > on all applications that support multiple open documents (which would > prompt you to save any unsaved changes, of course). It's a really > convenient feature in those apps that have it today. Ok. I may have to start worrying about bloat at some stage. I don't know whether items like Open Selected already fall into that category. > Edit Menu > --------- > > Separate Undo/Redo menu items tends to suggest multi-level Undo... if > the app only supports one level, should we suggest a single menu option > whose label changes between Undo and Redo instead? Or would one of > "Undo" and "Redo" just always be greyed-out? (Can't say I really care > much either way, but traditionally it's been done the first way, so the > guidelines should probably at least say something about it). Right. I'm more in favour of greying them out myself, though I can see that having just one item might make a useful indicator that it was a single-level undo. It's worth remembering that there will always be limits on the depth of the undo history. With audio editing, for example, you very quickly run out of disk space so the history necessarily has an arbitrary limit. It's a bit strange to treat a limit of one differently from a limit of, say, five. > What about the concept of "Repeat" (which is basically "keep redo-ing, > but to my new selection", as supported by M$ Word etc.), is this > useful/widespread enough to be worth providing a guideline for? I've seen this in Word (indeed, it made the time spent using Word slightly less painful), but I don't think I've seen it anywhere else. I'm not sure there are many situations where it applies, so I'd be inclined to leave it out of the guidelines. I could probably be persuaded otherwise though, if someone felt strongly about it. > Options Menu > ------------ > > Ah, okay, you've solved the "Preferences/Settings" debate by using the > most neutral term for the configuration menu title :) I'm actually a firm believer that it's better than either "preferences" or "settings". There was a thread on g-g-l a while back where I was arguing that (and on the same thread was thoroughly out-voted in my belief that "directory" was a better term than "folder"). > If I was being particularly perverse, I'd mention that in the past, when > working on financial applications, I've had to go against guidelines > that recommend an "options" menu, because "options" means something very > different to stock traders and the like. Entirely coincidentally, those > apps were being designed to run under CDE on Solaris, which rather less > coincidentally will soon be replaced by GNOME on Solaris, so when they > port they'll have to break the guidelines again :) > > But admittedly that's a very specific and isolated situation where the > guideline would have to be broken, it just happened to come to mind. I'm sure that you could find that sort of problem for 75%+ of the terms used in a modern GUI. I don't think it merits a change in the guidelines. > Help Menu > --------- > > Personally, I'd also like to see a "Search Help" menu item by default, > possibly even above "Help Contents"-- searching is probably about the > most common thing people do with a Help system, and support for an > (initially primitive) Search capability is being added to > Scrollkeeper/Nautilus Help sidebar as we speak. (This assumes that > everyone would be using Nautilus or some other search-enabled viewer, > though, which may not be a valid assumption?) Yes, Search would be good. I have no idea how the help system works in GNOME, and I hear that there are some significant changes planned for 2.0. I really need some input from someone with that sort of knowledge on this issue. > "About appname..." -- don't think this should have the trailing > ellipsis? Well, not if we're sticking to the traditional definition of > what the ellipses mean, anyway. Yep. I think you're right there. Strange that it's such a common misuse of the ellipsis. colin _____________________________ ____ rtnl http://rational.cjb.net c z robertson ndirect co uk icq 13294163
Attachment:
pgpMJFMP7zgHa.pgp
Description: PGP signature