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. :) > > > > >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. 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. 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. > [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. 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. > 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. > >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. 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. 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. colin _____________________________ ____ rtnl http://rational.cjb.net c z robertson ndirect co uk icq 13294163
Attachment:
pgpXtaBYSbpn8.pgp
Description: PGP signature