Subject: Re: FAQ -- why the MSDI interface? (aka, no pagers please)
From: Tim LaDuca (firstname.lastname@example.org)
Date: Thu Aug 16 2001 - 16:22:20 CDT
I think there is only one very specific problem with the current
MSDI interface, and that is the ambiguity of File->close. If I
start AbiWord, it opens with a new blank document. I did not ask
for this blank document, so I would expect that File->Open opens
the document in the same window(say by-bye to the blank new
document. Currently this is exactly how abiword behaves. If I now
go to File-Close, I would expect abiword to return to it's state
before I did File-> open. That is, return to a blank new document.
Currently however, that is not what happens, instead AbiWord
closes. I beleive this is what a majority of the people
complaining about the MSDI interface (including myself) have a
When a document is already open, we have consistent behavior. File-
>Open opens a new window. File-Close returns abiword to the state
it was in before I chose File->Open, that is, it closes the window.
Further, I think when most people go to File->Close they
think "close the document", not "Close the window". If the window
closes as a side-effect, that's fine, as long as it is
appropriate. On the other hand, when most people think "I want to
close the window" (at least on windows 9x) they click the little X
in the upper right hand corner, and that's what they will do if
they really want AbiWord to go bye-bye completely,(or they'll
Hope this helps,
---------- Original Message ----------------------------------
From: Paul Rohr <email@example.com>
Date: Thu, 16 Aug 2001 13:05:07 -0700
>There's been a lot of noise and confusion recently about how and
>window-management UI works, so as the author and designer of
>I'd like to clarify a few things.
>First, there are a ton of possible GUI precedents for how to
>for documents and applications. Worse, these precedents vary
>depending on which platform you grew up with.
>The design choices I made consciously favor the following UI
> - Macintosh (app-centric, all documents share same menus)
> - Windows (Mac-like, especially since Win95 added the taskbar)
>We are building what is essentially a mass-market desktop
>the overwhelming majority of desktop users (95+%) are already
>one or both of those interfaces, so whatever we do *must* Just
Work in their
>eyes, and not confuse them.
>More specifically, the UI precedent I followed most closely was
>most ubiquitous cross-platform application in the world -- web
>It's no accident that most web browsers in widespread use have
>similar UIs, and I deliberately chose to try to take advantage of
>commonality. Two complicating factors worth mentioning, though:
> 1. For most people, browsers are read-only tools. The fact
> we're an editor means that we're creating new documents,
> the browser UIs weren't necessarily optimized for.
> 2. Insofar as IE's window-management interface is a bit more
> Windows-centric, it does occasionally diverge from the
> pre-Mozilla Netscape UIs, and thus whenever the two
> I usually tended to follow Netscape's lead.
>Thus, if you want to understand how the AbiWord window-management
>run Netscape on either of those platforms. Our behaviors should
>very close to what that product's already taught people to
>For earlier discussions of these topics, see:
>We're using what's called a "Multiple SDI" (MSDI) interface. In
>scheme of things, this falls between:
> - true SDI ... only one document per app, period
> - true MDI ... all documents share same application
>Like SDI, each document gets its own full top-level window. The
>is only "up and running" while you're editing a document. The
>"goes away" when you're done with the document(s). Unlike SDI,
>us to use the same instance of the application to edit more than
>document at a time.
>Like MDI, the application can manage multiple documents at a
time, and it's
>easy to use application-level functionality (via the Window menu
>Ctrl-Tab keybinding) to cycle between documents. Unlike MDI,
>top-level container which aggregates all of those documents, so
>possible to leave the app open with no documents.
>Note that in the Mac UI, the few differences between MDI and MSDI
>much subtler. In fact, if I did my job right a few years ago,
>existing XP MSDI policies for window management will map *very*
>a native Mac look and feel. Hub may need a platform-specific
#ifdef in one
>spot, but otherwise I think I got very close. We'll see. ;-)
>why not MDI?
>A few reasons.
>1. The practical one is that there still aren't many good
>MDI implementations outside the Windows world, for example
>particular, from a usability standpoint, tabbed interfaces are
>functionally equivalent to MDI.
>2. The strength of MDI apps is that they "confine" or aggregate
>document windows in an overall container. This is valuable when
>simultaneously editing *huge* numbers of documents (for example,
in an email
>client or code editor) and don't want those windows to clutter up
>of your workspace. [ Note that a traditional Unix/X way to
>like this is to park them on a virtual desktop instead. ]
>3. The corresponding weakness of MDI apps is that they "cramp"
>in an app-centric way by forcing all your documents to coexist
>MDI container, instead of being "free" to be managed in a
>way on the desktop.
>For all 3 reasons, I tend to believe that MSDI is a solution that
>quite well with most people's expectations of how to interact
>on a modern desktop.
>why a Window menu?
>It's a useful convenience.
>Yes, many desktops are adding functionality to manipulate
documents, and you
>can certainly use those if you like. However, I tend to have a
>documents open at once on my desktop, including:
> - a bunch of .cpp files (in my MDI editor)
> - a bunch of email messages (in my MDI mailer)
> - several browser windows
> - several AbiWord documents
>If I had to cycle through *all* of them using alt-tab to get to
>I want, it'd take a *long* time. I know which application I'm
>using, so it's nice to be able to cycle more quickly through,
>AbiWord documents using just ctrl-tab or the Window menu.
>Again, it's a useful convenience, just like the Window menu. We
>running an application which manages multiple documents of the
>kind, so IMNSHO we should take advantage of that and give people
>of closing them all at once.
>To the person who was surprised when exiting Netscape's IRC
>killed their browser, I agree. I make no apologies for
>to use MSDI to bundle a bunch of *different* applications with
>UIs, where an "Exit" *would* lead to surprises.
>why not a pager?
>To be honest, I've never given this idea much weight. It would
only be a
>familiar UI paradigm to folks with experience on traditional X
>Everyone else would find it surprising, and that kind of surprise
>not a good thing.
>While it is a thinkable way to solve the "I'm done with my
>not with the application" problem, I'm still unconvinced that
this is a
>must-fix problem. (See below.)
>why does the last Close exit?
>I do take for granted that people know how to use their desktops
to do all
>of the following tasks:
> - start an application (double-click it)
> - open an existing document (double-click it)
> - create a new document (varies, but usually a context menu)
>Note that once the application's already up and running all of
>should continue to work. (If not, file a bug.) From inside the
>application, you should also be able to:
> - create a new document (File / New, or Ctrl-N)
> - open another document (File / Open, or Ctrl-O)
> - close the document (File / Close, or Ctrl-W)
> - close the application (File / Exit, or Ctrl-Q)
>If so, then the only screw case that a pager would be needed for
would be to
>avoid relaunching the application in the following scenario.
> - you're done with all of your current documents,
> - you want to create a new one, AND
> - you want to do so in that order.
>Granted. You can't do that with the current MSDI. So? As a UI
>you sometimes have to make choices. The UI policy decision
>coded was to optimize instead for the following doc-centric (and
> - you're done with all of your current documents
> - of course, you don't want that silly app hanging around
> - if and when you do, you'll relaunch it
>I encourage people to tread very, very lightly when considering
>the MSDI portions of the window-management UI -- namely, the File
>menus. What we have now is a carefully-balanced whole, and off
>each of the proposed changes (so far) seems to have bigger costs
>Like Dom said, it'd be really cool to go into a usability lab and
>some of the creative proposals being floated here. Failing that,
>I'm very reluctant to make any significant changes here without
that kind of
>PS: I do still plan to review Jared's interface review as soon
as I can get
>a version of his document which doesn't crash my version of
>get my version of AbiWord to not crash on his document -- I
>the problem yet.) Sorry for the delay.
This archive was generated by hypermail 2b25 : Thu Aug 16 2001 - 16:21:39 CDT