Re: [Usability] HIG: File New/Open/Quit, etc.

[Matthew Paul Thomas <mpt myrealbox com>]

On Mar 24, 2009, at 8:23 AM, usability-bounces gnome org wrote:
> ...
> Are there objections to the HIG saying this, in the appropriate
> sections?:
>
> 0. An application is "document-based" if it loads and saves documents.

Agreed as far as it goes, but I'm not sure this is a useful definition.  
Is PiTiVi "document-based" under this definition? How about Jokosher?  
Or Brasero?

> 1. Document-based applications should have File/New, File/Open,
> File/Save, and File/Save As menu items.

Agreed except for the last two.

For "Save", it shouldn't be a requirement of HIG compliance that an  
application requires users to understand the distinction between RAM  
and disk (an increasingly irrelevant distinction as disks get faster).  
The guidelines shouldn't discourage application developers from making  
saving completely automatic.

For "Save As...", while this is already standard in Gnome as well as  
Windows and Mac OS, it's a bit of a hellhole. When you use "Save As..."  
to save an existing document in a different folder, what happens? You  
probably know by now that (1) the old copy remains on disk and (2) you  
continue working on the new copy, but both of those behaviors are quite  
arbitrary: either of them (though not both at once) would make just as  
much sense with the opposite behavior!

Because that behavior is so cross-platform, though, an application  
designer probably shouldn't get rid of "Save As..." (replacing it with  
more useful items like "Move/Rename..." and "Use as a Template...")  
unless they make a clean break and get rid of "Save" at the same time.  
So for both of those, I suggest a guideline of the form "If your  
application requires explicit saving of documents, then...". (It would  
be nice to also have guidelines on what a save-less application's  
"File" menu should look like -- and Alan Cooper makes an interesting  
attempt at this in /About Face/ -- but realistically that needs more  
experimentation and testing first.)

> 1.1 File/New and File/Open should open new application windows (if not
> using tabs), if the current document is empty and unmodified.

Agreed, but "File" > "New" should do that regardless of whether the  
current document is empty and unmodified, right?

> 1.2 File/Open should check if the chosen document is already open in  
> the application. If so, it should bring the window to the front. The
> application may ask the user if he wishes to open a second window for
> the document. Show suggested UI for that.

Disagree. If we're having to ask the user whether an action meant one  
thing or another, the design was poor.

A clearer alternative would be to always open a new copy read-only, and  
have "Save" in that new copy prompt for a file name and location just  
like a new document would.

> 1.3 The same check and UI should happen when opening a file in any  
> other way, such as from the file manager.

Agreed. (For this purpose, it would be cool if there was an API for an  
application to tell whether a document was open in *any* Gnome  
application, not just in the same one!)

> 2. Document-based applications should have a File/Quit menu item. This
> should close only the current document window. It should not close all
> document windows open by the application.

Disagree. That would be quite confusing, because it's not what "Quit"  
means either in previous versions of Gnome, or on other platforms.

> 2.1 Should it be called File/Close instead? Do we want both the Close
> and Quit keyboard shortcuts to activate this menu item, to avoid
> annoying people with the change.

What's your motivation here? If you're trying to prevent the harm of  
closing a dozen carefully-opened documents with a single mis-click or  
accidental key combo, I think a better way of doing it would be to  
remove "Quit" entirely (as Epiphany does, for example). That way the  
effort of closing documents would be proportionate to the effort of  
opening them, and it would reduce the need for people to care about  
what the "application" is.

> 2.2. If there are unsaved changes in the document, the application
> should ask the user if they wish to save the changes. Show a suggested
> UI for that, because these are currently very inconsistent.

There already is a suggested presentation for that.
<http://library.gnome.org/devel/hig-book/stable/windows- 
alert.html.en#save-confirmation-alerts> I think the problem is that the  
suggested presentation is obviously wrong, which leads application  
developers to do something else, and then they all do different things.  
(In particular, the primary text in the screenshot uses part headline  
grammar and part normal grammar, instead of choosing one or the other;  
"Close without Saving" is too wordy, is weirdly capitalized, and has a  
non-obvious access key; and "Save As" should end with an ellipsis but  
is shown as not having one. And to top it off, the screenshot shows off  
the hated bug 101968.)

> 3. The application should _not_ list its open document windows in a
> Documents or Windows menu.
> ...

Agreed.

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/