Re: [HIG] Policy questions



On 03Nov2001 05:37AM (+1300), Matthew Thomas wrote:
> Maciej Stachowiak wrote:
>
> > 1) The reasoning does not apply to non-document-oritented applications
> > such as games, utility programs, terminal emulators, chat programs,
> > etc. Clearly "Quit" is appropriate in such cases, certainly when the
> > program has multiple windows.
> 
> Using `Close' instead would still work just as well.

You'd have to use Close to close each individual window. This is
notably less efficient when there are multiple windows.
 
> > 2) The reasoning does not really apply to document-oriented
> > applications where the organization of the documents is more
> > fundamental to the UI than the documents themselves, such as a web
> > browser, a mail client, an addressbook, etc. When I'm reading a mail
> > message, I don't think of it as just any document but part of the way
> > I interact with my mail.
> 
> On the contrary, the reasoning applies *especially* to those sorts of
> applications. In some environments, the bookmarks manager and the Web
> browser may be part of the same program; in others, they may not. Such
> an implementation detail should not need to be reflected in the
> interface. (We have had lots and lots of bugs complaining that `File' >
> `Exit' in the bookmarks manager shuts down the whole of Mozilla.)

I can see how that might be confusing. Possible resolutions include
not putting menu bars on utility windows, or not putting a Quit menu
 
> And more particularly for a Web browser, the fact that my book-buying
> application (fatbrain.com) and my news-reading application
> (slashdot.org) happen to be run by the same program is also an
> implementation detail which should not be reflected in the
> launching/exiting interface.

During my work day, I have need both to close specific browser windows
and to close the whole browser. Reasons for the latter include things
like memory leaks, javascript bugs making the browser unusable, and
not wanting to leave around a program authenticated to a site that
provides access to my finances when I leave the office.
 
> > 3) A key use of Quit, even using when traditional office-style
> > document-oriented apps, is to free up the memory being used by a given
> > program. For purposes of freeing memory, the set of documents hosted
> > by a given app is not arbitrary.
> 
> If users have a compelling need to close all documents which happen to
> be hosted by your application, then your application is too large and
> should be split up. 

Sadly this applies to many existing applications that I use, and it is
beyond my personal abilities to split them all up. Note that closing
an application, in addition to freeing memory used by specific
documents, frees the memory used by code and other resources global to
the application.

> Having a command to close all documents which happen to be hosted by
> a particular application should make no more sense than having a
> command to close all documents which start with the letter P.

Interesting theory.
 
> Even if such a command is necessary currently, it is better provided by
> the window manager or taskbar than by individual applications, as it can
> then be added or removed globally.

But then it can't show up in the application's menu. A distinct
"window manager menu" is an annoying side effect of having 
 
> > 4) Quit is essential when closing all windows is distinct from
> > terminating the program. Consider a chat program that pops up a new
> > window for each message for instance (with, say, a panel applet in
> > lieu of a control window of some kind).
> 
> If it needs a central point to quit it, it should have a control window.
> Closing the control window would prevent new messages from opening, but
> existing message windows would be closed individually.

That seems like a confusing sort of side effect. Why would it be clear
to me that new messages won't pop up if there are still messages on
the screen, and the command wasn't labeled "Stop new windows from
popping up", but simply "Close"? Whereas "Quit" would be quite
unambiguous.
 
> > 5) Even if the future blurs the difference between different
> > applications more, I think today this change would result in a whole
> > lot of "how do I quit" type questions on the mailing list. We should
> > not make usability problems in the present for the sake of consistency
> > witha future that may or may not arrive.
> >...
> 
> I find this attitude annoying (and I've seen it from Seth too): saying
> that we can't move towards a document-centric interface because we don't
> have a document-centric interface yet. We'll never get there at this
> rate. :-)

The problem is that your proposal is step 10 in creating a
document-centric interface, not step 1. Right? You change those things
which create the user's model of the system first, and then attend to
the minor details to make them consistent with that model.

Personally I don't believe in the idea of a fully document-centric
interface because there are many tasks users need to do that are not
related to a document, or are related to the relationship about many
documents and presenting them in a certain way. I have yet to hear a
design for how users would perform such tasks without exposing the
concept of an application in some way.

Regards,

Maciej





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]