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

[Steve Fosdick <lists pelvoux nildram co uk>]

On Thu, 2009-03-26 at 22:12 +0000, Matthew Paul Thomas wrote:

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

I remember a story from a colleague about a secretary who complained
because whenever she turned the computer off it lost what she had been
typing and it turns out she had not been choosing the save option before
turning off the power.

For many documents hard disks have been fast enough for some time for
saving to take place automatically based on a timer or a number of edits
and again when the user closes the document.  This would likely be a
more natural way to work for a beginner.

On the other hand some experienced users use explicit save as a kind of
"commit" mechanism i.e. saving the document when it is in a consistent
state so if the next round of editing turns out to be disaster the
document could be reverted to that last saved version.

With either unlimited undo or the ability to establish snapshots/save
points or whatever you want to call them within the document (or both)
perhaps explicit save is not required.

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

I did once use an application that saved a new copy and continued
working on the old one.  The menu was definitely labelled "Save As" and
not "Save a Copy" as I have seen in at least one Gnome application.

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

I'm interested in the "Use as Template" option you mention.  Certainly
for me the greatest use of "Save As" is to open a document, similar to
the one I want to write and then "Save As" to create a copy which I then
work on.  As far as I know this is common practise and it is also quite
common to forget to do the "Save As" immediately and accidentally
overwrite the original.

So, if there is a better way it would be good but I can't think at the
moment quite how it would work.

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

It would seem to make more sense to me that if the application has just
been started and has created a blank document ready for editing that
File/New be greyed/inactive until you edit the initial document.

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

I think the difficulty here is that user could chose open for the same
file twice for more than one reason:

1. To create two different documents both based on the first document in
which case both need to be editable but should not be saved to the same
filename.

2. Because of having forgotten the document is already open in which
case making the existing window known would suffice.

The options are to attempt to guess what the user is trying to do, ask
the user what he is trying to do or do one of these things consistently.

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

I agree with Matthew Paul Thomas here.  For me "Quit" has the specific
meaning of terminating the application and by implication closing all
the documents it has open.  I would normally chose it:

1. Because I want a quick way to close all those documents.

2. Because the application has some information in memory which I would
rather was not available to documents in other windows of the same
application (e.g. a web browser and internet banking).

3. Because the application is malfunctioning and would benefit from a
re-start.

The above is certainly advanced behaviour but it would be a pity to
hijack what appears to be a defacto standard when the more beginner
friendly behviour can be implemented with the word "Close" which would
close only the document to which that particular file menu was attached.

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

For me "Quit" should be as I described above - quit the application.  If
a document centred rather than application centred model is working well
and quit is not required then it could indeed be removed.  This would be
much less confusing than renaming it.

I would contend though that there are times when someone will have
opened many documents and will want a way to close them all and start
with a clean workspace.

Perhaps this could be at login/logout when the user can choose whether
the documents get carried over from one session to another or maybe
there could be a global "Close All" which closes all documents in all
applications or, if using workspaces, closes all documents on this
workspace.

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

I quite like the "changes from the last x seconds will be permamently
lost".

I agree that "Close without saving" is a bit long and while I can guess
what cancel would probably do (not close) perhaps it could be explicit
so perhaps the three buttons should be "Discard", "Don't Close", "Save".

The "Save As.." button is presumably specific to the case where the
document has not yet been saved and therefore doesn't have a filename.
I don't think anyone would be surprised if as "Save" button posted the
file dialog for save in this case though there is no hard in making it
explicit.

Regards,
Steve.