Re: Menu guidelines updated

[Adam Elman <aelman users sourceforge net>]

At 5:18 PM +0100 8/24/01, colin z robertson wrote:
> On Fri, Aug 24, 2001 at 12:32:03AM -0700, Adam Elman wrote:
> >  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 :)
>
> Have you read through the settings/options/preferences discussion that
> happened on gnome-gui-list many moons ago? I don't want to hear a word
> on the subject from anyone who has not read that discussion. :)

Yeah, I suspected that was an old argument. :)  I will go dig that up 
before making another comment on the topic.

>  > Why is that ever a good idea?  IMHO the app should _always_ be aware
> >  if it has the same file open in two windows.
>
> While I can see that, for the most part, having limitations on opening
> the same file twice would be helpful, I can think of a few scenarios
> where one might prefer it to be independent. Imagine the user had a
> file open, and wanted to use that file as a template for another file,
> while keeping the original file open. The first thing that would occur
> to me in that situation would be to save the first document, open that
> file again and save it to a new filename, but this wouldn't be allowed
> if the same file couldn't be opened twice. (This situation actually
> happens to me quite often.)
>
> In fact, there are safer ways to do the above, which are compatible
> with the limitations, so I think I've convinced myself that those
> limitations are quite reasonable. But I still think the above method
> is the most obvious.

*shrug* The first way that would occur to _me_ is to save the open 
file as the new file and then re-open the original file, since I'm 
used to apps that wouldn't allow you to open the same file twice. 
The way you describe would never have occurred to me until you 
mentioned it.  And actually, your way is better; I've occasionally 
made changes to an original document that I didn't intend to make 
because I forgot to do a Save As (or vice versa, thought I was making 
changes to the original while I was making changes to the copy).

In any case, I agree that this is likely a very common case -- it 
happens to me all the time too.  I think having an unambiguous "New 
Document as copy of" or "Open a new copy" or some command like that 
would be a far better solution than either.

> There's another issue as well, though it probably isn't too important:
> Two different apps (or the same app running as two different
> processes) will not be able to enforce these restrictions. It is
> possible to have the same file open in both of them simultaneously. It
> strikes me as being somewhat inconsistent.

Well, this is true too.  My first thought is that the correct 
solution is to implement better file-system monitoring, but that only 
works for changes which have been saved to disk.

I think this probably should, in the end, fall under the long-term 
discussion on document-centricity, getting rid of Save, etc. -- I 
have a feeling that the parameters decided in that discussion will 
inform this for the long-term.  In the short term, I think that 
having apps aware when there are multiple views on the same file, or 
only allowing a single view, is better than allowing multiple 
instances of the same document open which, when saved, will conflict 
with one another.


>  > >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.
>
> Yeah, I guess you're right -- it does depend on habits. Maybe it's
> just me, but I'll typically use more than five files _for one project_
> (and this is the same in music, programming, web design, and
> graphics). And I'm usually working on more than one project
> simultaneously. It would be interesting to see what other people's
> habits are, but I suspect that your average power user works like
> this.

Again, *shrug* I generally work on a much smaller set of files, 
unless I'm programming.  I generally have one or two songs that I'm 
working on arranging, one or two word-processing documents that I'm 
writing, and a small number of spreadsheets.  The only cases where I 
work on a large set of files is if I'm programming (and hence working 
on many source files) or doing a web site (where I have to deal with 
a bunch of graphics files).

So it depends very much on the task.  I think that this is not a case 
of "power user" vs. "novice" -- I would bet that a writer might be 
working on 4-5 files at most at one time; a programmer tends to work 
with a much larger number, etc.

'Course, this is all just conjecture; I don't have any practical data 
to support my point.  I _would_ bet that most engineers work more 
with a larger number of files than a smaller number, so if that's 
GNOME's primary audience I think I can concede the point.

> >  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.
>
> At some number, yes, but I assure that number is quite large. The main
> problem being that there is no good file navigation system.

Perhaps.  Although it is true that once you get above 10-15 files you 
really want to be able to organize into a hierarchy, sort by 
date/name/etc., be able to search for files -- i.e., have a decent 
file management/navigation system.

>  > 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.
>
> I'm basing these on the approaches people would have for finding a
> file in a list. For five files or so, you can expect the user to
> remember when they last used the file (and also, five is not a long
> list to search through). Beyond about ten files, memory about when the
> file was last used is far less reliable than memory about the file's
> name.

Yeah, I think you're probably right at these numbers.  Although also, 
that requires the filenames to be useful, which is not always the 
case; in that case you really need a way to search for files by 
content (see above :).

> Another slight advantage of using a submenu occured to me this
> morning. It's the only way to label what happens when you click on one
> of the items. Granted, it's probably not too difficult to work out
> that when you click on the name of a file you used recently it will be
> opened, but that's not stated anywhere if you put it directly in the
> File menu.

That's true too.  It also means you can put "Open Recent" under the 
"Open" command to make it even clearer what its function is, rather 
than have the list down at the bottom of the menu.

All that said, I think a submenu probably does make more sense for 
this function.

Adam
--