On Thu, Aug 16, 2001 at 05:04:55PM -0700, Adam Elman wrote: > >hmm. There are two schools of thought here. One is that the name of > >the first menu should be standard, the other is that it should adapt > >to its context even at the expense of consistency. > > Well, remember that the whole point of consistency in UI is to allow > the user to create a mental model of how to interact with the system > which appears self-consistent and follows a set of rules. As long as > the rules are consistent and make sense, I think the user is better > served by having names that adapt to the context. Sounds reasonable. > OTOH, the problem there is that the "File" menu generally contains at > least one important command which has nothing to do with a file per > se -- "Quit". I don't think it makes sense to have a "File" menu for > an app that doesn't deal with files/documents, or doesn't deal with > them as a primary operation. But if you always have the Quit command > under the File menu, you don't want it to go away either. It's a > catch-22. > > I can think of two ways to fix this in the long-term (I'm sure there > are many others): > 1) Go the MacOS X route and add a window which is named with the name > of the current application; this menu would always contain the > "About..." dialog, the "Preferences..." option, and "Quit"; possibly > other standard application functions as well (although I'm not sure > what). Apple also puts the "Hide" options that used to be under the > app menu here, but I don't like that (and I'm not sure it'd work > without significant WM modification anyway). I like this option, as > it also solves the "Edit -> Preferences..." vs. "Tools -> Options..." > problem. Yeah, this is quite nice. One problem though: MacOS has a much larger menu bar than is available to most apps in X, since in MacOS it goes across the whole screen, while in X it is generally confined to the window. OTOH, if it got rid of the Options menu... > 2) Get rid of the "Quit" option altogether; this involves moving much > more towards a document-centric paradigm rather than the current > app-centric one. This is a little more radical. :) hmm. I have yet to be convinced about this whole document-centricity thing. Thankfully it's not relevant at this stage. > >I'm actually a bit unsure about this whole thing. Should we deny the > >user the user the ability to have the same file open in two seperate > >windows? > > Yes, I think we should, at least through this means. There are, > IMHO, better ways to provide that functionality -- have a "Clone > Window" command of some kind (although not with that name), allow the > user to split a window into different panes that show different > views...allowing that functionality by simply bringing up a new > window with the same document even if it's already open is far, far > more likely to be confusing than useful. Well, I'm not thinking about views here. I'm thinking about having the document open in two entirely independant windows, as if the app had no knowledge that they were the same file. > > > [File access, open recent] > > > "...recently opened documents .. available via a submenu". > > > > > > It is common practice to maintain a list of the last n open files in the > > > File menu itself, where n is hardcoded or a user selectable value. Let's > > > not discourage this practical feature in the HIG. > > > >I'm not discouraging it. I'm encouraging a better way of doing it. You > >can fit more items into a submenu. > > Yes, although submenus are much more annoying/difficult to navigate > than single menus. Which is not to say that I disagree with you, but > I don't think that "you can fit more items" is a sufficient reason to > use a submenu in and of itself. Granted, it's harder to navigate a submenu than a top-level menu... but it's a lot easier than navigating a file dialog. The Open Recent menu is there for the purpose of reducing the amount of work that the user has to do, so I figure it's mostly a question of what results in the minimum amount of work. I think an extra ten items in the Open Recent menu at the cost of some slightly fancier mouse-work and a bit more scanning is probably a big win. I've just realised that this raises the question of what order the items should be in. For a short history (five items or so) you'd probably want the items to be ordered from most recently used to least recently used, but for a long history (ten or more items) you'd want them to be in alphabetical order. colin _____________________________ ____ rtnl http://rational.cjb.net c z robertson ndirect co uk icq 13294163
Attachment:
pgptTMVxL3ANR.pgp
Description: PGP signature