Re: [HIG] Policy questions

[Matthew Thomas <mpt mailandnews com>]

Maciej Stachowiak wrote:
> 
> 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.

When typing a chapter of the HIG, you have to press a different key for
each character. This is notably less efficient when there are multiple
characters in a word ... I'm not sure what you're getting at here. If
for some reason you want to close a large number of windows, typing
Control+W for each of them is quicker than typing Control+W for some and
Control+Q (or having to go into the menus themselves due to a lack of
shortcut) for others.

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

Not really an option, if you want any sort of comprehensive
keyboard-accessible bookmarks management.

>                                           or not putting a Quit menu

... item on any `File' menu. Exactly.

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

Those are just bugs, not design considerations. The only UI which they
should affect is the UI of the task manager (the tool you use when
things go wrong).

>                                                                 and
> not wanting to leave around a program authenticated to a site that
> provides access to my finances when I leave the office.

The inability to log out of authentication without closing a browser
window is also a bug. It was filed quite some time ago, but no-one's
fixed it yet.

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

That's why we write human interface design guides -- so *other* people
can do that work. :-)

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

Which, again, should be negligible.

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

I don't see why not. Is there a standard GTK+ structure identifying
the menu bar in a given window? If not, why not?

>                                                      A distinct
> "window manager menu" is an annoying side effect of having

Of having what?

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

On further thought, message windows shouldn't pop up by themselves in
the first place -- that would be bad UI. Even if they did, following an
option `Open messages automatically when they appear in my Inbox', it
would be obvious that closing the Inbox window would stop new message
windows from appearing.

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

No.

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

No. First you make it appear that document-creating applications don't
exist (only the documents do). Then you can fix the back end so that
document-creating applications really *don't* exist, and thanks to the
prior changes you can do this without disrupting the user experience at all.

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

Give some examples of such tasks then, and we'll see. :-)

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>