Re: Menu guidelines updated

[Adam Elman <aelman users sourceforge net>]

At 10:08 PM +0100 8/21/01, colin z robertson wrote:
> On Thu, Aug 16, 2001 at 05:04:55PM -0700, Adam Elman wrote:
[...]
>  > 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...

Right, that's kinda what I was thinking.  The "Options" menu tends to 
be a big mess in most GNOME apps that I've seen anyway; I frequently 
have to pick a bunch of different items to find the one that contains 
the setting I was looking for.  Better just to have all the settings 
and preferences in one or two dialogs (I'll let somebody else make 
the case for "Settings" vs. "Preferences" at the moment :)

>  > >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.

[...]

> 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.

Why is that ever a good idea?  IMHO the app should _always_ be aware 
if it has the same file open in two windows.

I guess I can imagine one or two hypothetical circumstances where 
this might be a desirable behavior, but it is VASTLY more likely that 
the user, when opening a file which is already open, would simply 
prefer to see the existing window, or would prefer to have an 
_explicit_ way to open another view on the same file.

The two models I have here are a basic editor, which generally does 
the former -- one window = one document, and you can't have the same 
document open twice, and Emacs, which does the latter -- separating 
internal buffers from the actual visual representation.  It's often 
very useful in development to have the same buffer open in two 
different windows -- however, it is useful because Emacs 
automatically and immediately reflects changes from one window in any 
other windows on that buffer.

Having two windows open on the same file in the same app with the app 
having no apparent knowledge that the two files are the same just 
seems like a recipe for confusion and possibly disaster.

[Recent file opening]
>  > >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.

Well, it depends on how many different files you tend to open.  If 
you tend to work on about four or five files frequently in an app 
over some period of time, then the submenu brings basically no 
advantage.  If you tend to work on 5-10 different files, then having 
a submenu _might_ be a win.  Again, I don't totally disagree with 
you, but I definitely question your assumptions on this.

At some number of files, of course, you hit the point of diminishing 
returns and you're better off just having a good file 
navigation/management system and letting the user go through that way.

> 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.

Yep.  This is also tricky -- you don't want things jumping around the 
menus all the time.  These might be good rules of thumb, though.

Adam
--