Subject: Re: Close and Exit
From: Paul Rohr (email@example.com)
Date: Tue Aug 21 2001 - 16:50:46 CDT
At 10:41 AM 8/21/01 +0100, NW wrote:
>I have followed the letters on this with interest. Until recently I
>earned some of my money by giving lessons in computing, often for
>beginners and especially in word processing. One of the topics that was
>guaranteed to come up was 'why do we have both Close and Exit'?
I'm the evil genius responsible for the feature in question, as well as the
lengthy ensuing flamefest over on the developer list. Over there, we've
(more or less) agreed that we disagree and have mostly moved on to other
issues, and I'm trying to stick to that principle over here as well.
Thanks for bringing up this example, though.
It highlights the fact that beginners *do* have this question, because they
don't have any prior expectations that there should even *be* two separate
commands like this. Any intuitions the rest of us have about what those
commands "should mean" have been created by explanations such as the one you
give. I agree that those are good explanations of how prior word processors
have behaved. This doesn't mean that those behaviors are "right", though.
When I put my UI designer hat on, I'm listening *very* hard to that "naive"
question, because I think there's a useful insight being expressed. Have we
constructed our user interfaces to answer that question in the best possible
a story about applications
Some user interfaces are inherently application-centric. They dedicate a
portion of the GUI to the application per se, a portion that's visually
separate from all the documents:
- the menu bar at the top of the Mac UI
- the top-level window and associated menu in old-style Windows MDIs
It thus makes "visual sense" to get rid of all the documents and still have
the application hanging around. The mental model you *need* to construct to
make sense of which boxes are on-screen when is a story about applications
being separate from, and superior to, documents. The story is that you
"live inside" an application, and never leave it.
Once you accept and adopt that entire model, all kinds of detailed behaviors
become "natural" ... because they allow you to work in ways that fit the
One testimony to the persistence of that mental model is that some very
vocal people on these two lists are trying to find ways to *create* an
app-centric story for AbiWord, even though there currently is *nothing* in
the GUI which visually corresponds to the application itself.
a story about documents
Our user interface tells those beginners a different, simpler story. The
story I want AbiWord to tell is that we're a really friendly tool they can
use to work with one document, or with many documents. Their focus should
be on their documents and their desktop, because that's what's important.
So, from their nice friendly desktop, they can either create a new AbiWord
document, or edit an existing one. If they want to work on more such
documents, they can open or create them from the desktop just like they did
for the first one. (Desktops are usually easier places to find documents
than dialogs.) Or, as a convenience, we have AbiWord menus and dialogs to
help them do so from there, too. From any AbiWord document, we have a
variety of these convenience features (such as the Window menu) we can offer
simply because we're aware of the other AbiWord documents you're also
But they're just conveniences. The basic story we're telling is that you're
just editing documents, and whenever you're done editing AbiWord documents,
then you're done. Unless the platform requires us to (ie, the Mac), there's
no plaintive empty application sitting around asking you to work on more
AbiWord documents. You don't have to do anything different to get rid of
that application, too.
Thus, there still is a difference between Exit and Close, but it becomes a
simpler story. Forget about applications entirely. You're just working
with documents. Close gets rid of this document. Exit does the same thing
for all of your AbiWord documents. Think of it as a "super-Close" if you
what's the right precedent?
I might feel more tentative about advocating this style of interface if I
didn't have a *huge* precedent backing me up -- namely, web browsers. The
switch from application-centric UIs to document-centric UIs has already made
great inroads with users.
If you compare the following product categories:
- word processors (a la Word 97)
- web browsers (a la Netscape or Internet Explorer)
is there any question which category is more widely used? Does anyone
really argue that the web-browser style of user interface is *harder* for
novices to learn than classic word processor UIs?
I understand that the paradigm I'm describing here is *not* consistent with
more complex paradigms people are used to. Really, I do understand.
What I'm still not sure many of my critics understand is that the current
user experience *is* consistent. It's just different, and simpler, and IMHO
Now it's time for me to shut up again. :-)
To unsubscribe from this list, send a message to
firstname.lastname@example.org with the word
unsubscribe in the message body.
This archive was generated by hypermail 2b25 : Tue Aug 21 2001 - 16:43:03 CDT