Re: Close and Exit

Subject: Re: Close and Exit
From: Gregory L Harris (
Date: Fri Aug 24 2001 - 10:52:35 CDT

I've read this thread with a good deal of interest, and have been reluctant
to comment, especially if there's is little chance of affecting the outcome.
But I think this particular design point could be a larger impediment to
adoption than some may realize. (I'd hate to think that answering the odd
question about my "show me the code" t-shirt is in vain.)

It seems to me it might be a good idea to step back for a minute to think of
whether your target audience is broader than enthusiasts. There are reasons
other than history-bound clunkiness why mainstream word processing programs
don't automatically exit when the user closes the only currently open

In business settings, at least in the brick-and-mortar world, it is quite
common to have the need to work on six (or twenty, think of a secretary)
documents and to work on them sequentially. That is, "I've got to write a
letter to client A as soon as I've finished getting this department memo on
travel expenses done." Exiting and re-loading the program is not a
desirable procedure here. What is the sequence of commands you envision for
this user? "Now, before I close this document I just finished, I have to
open or create the next document or I'll have to start the whole thing up

For that audience of users, you might as well ask that they exit and restart
their e-mail client each time they finish reading or writing one message
before moving on to the next. Even if each e-mail message really is an
independent document, that's not what most of us would consider efficient
behavior. For the dominant population of word processor users, that program
is not qualitatively different from their e-mail client.

For that matter, to achieve a real consistency with the paradigm that users
should work with documents and not with applications, the "Open" command
doesn't make any more sense than an "Exit" command. Why would you want to
be in the application to begin editing some other document? Shouldn't you
really go back to the desktop, or the shell, to spawn a new instance with a
different document? (That sarcasm is intended to be only rhetorically mild,
not a flame, so please don't take offense.)

As a lawyer formerly at a big firm, I helped to direct transitions from a
Wang mini system to DOS WordPerfect to MS Word on Windows 3.1, with
voicemail and e-mail along the way. That qualifies me either as experienced
or a blindered dinosaur. I'm not a coder, but I have spent a lot of time on
workflow, usability and implementation.

Abiword is an astonishing accomplishment, however this point is decided.
I'd just like to take an issue away from people looking for a reason why
"it's just not right for us."

Thanks for listening.
Greg Harris

----- Original Message -----
From: "Paul Rohr" <>
To: "NW" <>; <>
Sent: Tuesday, August 21, 2001 5:50 PM
Subject: Re: Close and Exit

> 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'?
> Hi,
> I'm the evil genius responsible for the feature in question, as well as
> 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
> 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
> give. I agree that those are good explanations of how prior word
> 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
> question, because I think there's a useful insight being expressed. Have
> constructed our user interfaces to answer that question in the best
> way?
> 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
> the application hanging around. The mental model you *need* to construct
> 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
> become "natural" ... because they allow you to work in ways that fit the
> model.
> 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
> 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
> simply because we're aware of the other AbiWord documents you're also
> editing.
> But they're just conveniences. The basic story we're telling is that
> just editing documents, and whenever you're done editing AbiWord
> then you're done. Unless the platform requires us to (ie, the Mac),
> 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
> for all of your AbiWord documents. Think of it as a "super-Close" if you
> will.
> 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
> 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?
> bottom line
> -----------
> I understand that the paradigm I'm describing here is *not* consistent
> 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
> better.
> Now it's time for me to shut up again. :-)
> Paul,
> storyteller
> -----------------------------------------------
> To unsubscribe from this list, send a message to
> with the word
> unsubscribe in the message body.

To unsubscribe from this list, send a message to with the word
unsubscribe in the message body.

This archive was generated by hypermail 2b25 : Fri Aug 24 2001 - 10:52:43 CDT