On Thu, Aug 02, 2001 at 12:51:41AM +0200, Reinout van Schouwen wrote: > * "Applications ... may rename this menu to either "Application" or, in > the case of games, "Game". > > I reiterate my objections against this idea. I am all for not having a > compulasory 'File' menu item, but 'Application' is just as nondescriptive > as 'File' is, and it does not take into account that some programs are no > applications in the traditional sense. E.g. an utility that is used to > view the system clipboard does not obviously operate on files. So should > the leftmost menu item be called 'Application', then? Of course not, it > should be 'Clipboard' (IMO). Please also see my post of July 10th. 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. To be honest I'm not entirely sure where I stand on this issue. If people want to argue about it a bit more that might influence me to a decision. > * [File Access, Open] > > "standard file open dialog" > > What is a standard file open dialog? That of GTK, or a (mini) Nautilus > view of the folder perhaps? The default file selector of GTK is terrible, > which is why the gtkfilesel project exists at sourceforge, but it's not > making any progress AFAICS. [yes if I could program in C..., but I can't > so I'm on the usability list] At some point a document will be written discussing standard dialogs. > "...the user should be notified via a dialog that the file is already open > and the window containing that file should be given the focus and raised." > > What is the purpose of that dialog? The user has indicated he wants to see > some file. Consequently the file is brought to the foreground. That the > file was already open does not matter to the user, does it? hmm. Perhaps not. 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? > I can think of > one situation that something special should be done: the user tries to > open a file that is already open *and changed*. In this case, opening the > file should give a warning like the one given at 'revert' and if the user > agrees, the file should be reverted to the state it had on disk. I'm not sure about that. I don't think Open should function as Revert in that case. If that's what the user wants then Revert is always available. > "... blank untitled document ..." - I propose using a terminology like > 'dirty' and 'non-dirty' (or 'clean'). I see what you're trying to do, and I agree that it's a bit awkward at the moment, but I'm not sure that your terminology is any clearer. > [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. > [File access, Save] > > The example you give about jpg compression level is badly chosen IMHO. I > believe the JPG compression level is not saved with the file itself, so > the most an app could do is default to the last-used value or an > application-default value. Agreed. I'll think of something else. > If there are extra options to be set there should be an 'Advanced options' > button in the save dialog or an extra dialog after clicking Save that > takes care of this. Right. I've got to add in something to cover this. > [Save as] > "new filename" -> "new file" sounds better? > "selected" -> there is nothing to select if it is a new filename, so this > could be changed to 'entered' or something like that. Agreed. "Chosen" is probably the right word. > [Close docname] > > Perhaps we could say something about the effect of a situation where all > documents are closed on the status of menu items. Should they be greyed > out or not? More general guidelines on when to grey out items would be > welcome. There needs to be something about general menu principles. It'll get done at some point. > [Edit] > > "The Edit menu... searching and replacing". > > If you have many, many possible search/replace actions ( like jEdit, for > instance ) you may want to put those in their own separate menu instead of > cluttering the Edit menu with it. I thought about this, and it was the primary reason I was hesitant about putting Find into the Edit menu. I eventually decided that most apps which have comprehensive search and replace functionality could still fit it into the Edit menu. > "Replace dialog" > > A replace dialog should not be something totally different than the Find > dialog. Perhaps they could be the same, but the 'replace' part of the > dialog could be disabled by default if you choose 'find' (but easy to > enable). I think this may be dependent on the app in question. Also, a replace dialog can get rather cluttered, so I think in many cases it makes sense to have a dialog that only does finding just because it will be a far simpler dialog. > [Clipboard Access and Deletion, Paste] > > I suggest adding 'or inserts at caret position'. I use 'caret' because > 'cursor' is ambigious whether the mouse arrow or the text cursor is meant. Agreed. > * Related to Menus are Toolbars, but perhaps those deserve their own > chapter in the HIG. yep. They'll be done at some point. > * Last but not least, popup / context menus are not mentioned at all in > this document, but I think that really belongs in there. > > * Something I mentioned earlier: when to use cascading submenus and when > not to? I believe there's a lot of information available on this subject > aready. Again, these will go into the general menu principles section. colin _____________________________ ____ rtnl http://rational.cjb.net c z robertson ndirect co uk icq 13294163
Attachment:
pgpnOvdFZQ2GL.pgp
Description: PGP signature