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

[Murray Cumming <murrayc murrayc com>]

On Thu, 2009-03-26 at 22:12 +0000, Matthew Paul Thomas wrote:
> 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. 

Even if we can't make it more precise, the HIG only offers suggestions, so 
we don't need to block on having a lawyerly definition.

> Is PiTiVi "document-based" under this definition? How about Jokosher?  
> Or Brasero?

They could be. Why wouldn't they be?

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

Auto-saving is a whole other set of UI problems that shouldn't block
this. Let's mention it as a caveat, though I don't personally see the
sense in mentioning it until there's one single application that does
this successfully and in a way that can be generalized.

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

So we choose one and suggest it in the HIG (as you say below). I think
the current de-facto behaviour is fairly logicial, because it's similar
to what happens when I do a regular File/Save - I continue working with
what I saved.

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

Yes.

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

That doesn't help with what I think is the more common case: I open a
file from the file manager that I already opened an hour ago. I do want
to just see the same document window again.

This is MacOS behaviour if it helps to know that. It feels natural.

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

Yeah, this implementation detail is something I want to explore if we
can agree on the UI.

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

You'd be surprised. It's what Quit means for all non-tabbed (single
instance) applications that I can find, if you open two documents via
the file manager or Application menu.

However, if you open the second document window via the application's
File menu then both will close when you File/Quit. That's exposes the
fact that they are separate processes if opened via the File Manager or
Application menu. And that is broken voodoo to users.

I suspect that MS Windows has the same problem, but a) I have not looked
and b) MS Windows is a swamp of inconsistency. I think MS Windows
attempts to do this because it copied it from MacOS, and File/Quit
actually makes sense on MacOS because of the global menubar which allows
applications to be open with no open documents.

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

1. See above about how we are currently exposing the idea of processes.
File/Quit is currently just broken.
2. I want to do the right thing in my applications so I want to
establish what the right thing is.

>  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'm not concerned about that.

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

Great. So for now we can just use that. I suggest that you try to
improve it as a separate exercise.

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

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com