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
problem with.
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
click File->Exit).
Hope this helps,
Tim
---------- Original Message ----------------------------------
From: Paul Rohr <[EMAIL PROTECTED]>
Date: Thu, 16 Aug 2001 13:05:07 -0700
>Hi,
>
>There's been a lot of noise and confusion recently about how and
why our
>window-management UI works, so as the author and designer of
those features,
>I'd like to clarify a few things.
>
>First, there are a ton of possible GUI precedents for how to
manage windows
>for documents and applications. Worse, these precedents vary
greatly
>depending on which platform you grew up with.
>
>The design choices I made consciously favor the following UI
precedents:
>
> - 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
application, and
>the overwhelming majority of desktop users (95+%) are already
familiar with
>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
the single
>most ubiquitous cross-platform application in the world -- web
browsers.
>It's no accident that most web browsers in widespread use have
very very
>similar UIs, and I deliberately chose to try to take advantage of
that
>commonality. Two complicating factors worth mentioning, though:
>
> 1. For most people, browsers are read-only tools. The fact
that
> we're an editor means that we're creating new documents,
which
> 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
diverged,
> I usually tended to follow Netscape's lead.
>
>Thus, if you want to understand how the AbiWord window-management
UI works,
>run Netscape on either of those platforms. Our behaviors should
be very
>very close to what that product's already taught people to
expect.
>
>For earlier discussions of these topics, see:
>
> http://www.abisource.com/mailinglists/abiword-
dev/99/May/0061.html
> http://www.abisource.com/mailinglists/abiword-
dev/99/May/0074.html
> http://www.abisource.com/mailinglists/abiword-
dev/99/May/0073.html
>
>terminology
>-----------
>We're using what's called a "Multiple SDI" (MSDI) interface. In
the grand
>scheme of things, this falls between:
>
> - true SDI ... only one document per app, period
> - true MDI ... all documents share same application
menu/container
>
>Like SDI, each document gets its own full top-level window. The
application
>is only "up and running" while you're editing a document. The
application
>"goes away" when you're done with the document(s). Unlike SDI,
MSDI allows
>us to use the same instance of the application to edit more than
one
>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
or the
>Ctrl-Tab keybinding) to cycle between documents. Unlike MDI,
there's no
>top-level container which aggregates all of those documents, so
it's not
>possible to leave the app open with no documents.
>
>Note that in the Mac UI, the few differences between MDI and MSDI
are much,
>much subtler. In fact, if I did my job right a few years ago,
then our
>existing XP MSDI policies for window management will map *very*
cleanly into
>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
platform-specific
>MDI implementations outside the Windows world, for example
GTK/GNOME. In
>particular, from a usability standpoint, tabbed interfaces are
*not*
>functionally equivalent to MDI.
>
>2. The strength of MDI apps is that they "confine" or aggregate
all their
>document windows in an overall container. This is valuable when
you're
>simultaneously editing *huge* numbers of documents (for example,
in an email
>client or code editor) and don't want those windows to clutter up
the rest
>of your workspace. [ Note that a traditional Unix/X way to
cluster windows
>like this is to park them on a virtual desktop instead. ]
>
>3. The corresponding weakness of MDI apps is that they "cramp"
your display
>in an app-centric way by forcing all your documents to coexist
within the
>MDI container, instead of being "free" to be managed in a
document-centric
>way on the desktop.
>
>For all 3 reasons, I tend to believe that MSDI is a solution that
integrates
>quite well with most people's expectations of how to interact
with documents
>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
*lot* of
>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
the document
>I want, it'd take a *long* time. I know which application I'm
currently
>using, so it's nice to be able to cycle more quickly through,
say, my
>AbiWord documents using just ctrl-tab or the Window menu.
>
>why Exit?
>---------
>Again, it's a useful convenience, just like the Window menu. We
*are*
>running an application which manages multiple documents of the
exact same
>kind, so IMNSHO we should take advantage of that and give people
the option
>of closing them all at once.
>
>To the person who was surprised when exiting Netscape's IRC
client also
>killed their browser, I agree. I make no apologies for
Netscape's decision
>to use MSDI to bundle a bunch of *different* applications with
dissimilar
>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
desktops.
>Everyone else would find it surprising, and that kind of surprise
is usually
>not a good thing.
>
>While it is a thinkable way to solve the "I'm done with my
documents, but
>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
the above
>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
designer,
>you sometimes have to make choices. The UI policy decision
that's currently
>coded was to optimize instead for the following doc-centric (and
not
>app-centric) scenario:
>
> - 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
>
>bottom line
>-----------
>I encourage people to tread very, very lightly when considering
changes to
>the MSDI portions of the window-management UI -- namely, the File
and Window
>menus. What we have now is a carefully-balanced whole, and off
the cuff,
>each of the proposed changes (so far) seems to have bigger costs
than
>benefits.
>
>Like Dom said, it'd be really cool to go into a usability lab and
test out
>some of the creative proposals being floated here. Failing that,
though,
>I'm very reluctant to make any significant changes here without
that kind of
>data.
>
>Paul
>
>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
AbiWord. (Or
>get my version of AbiWord to not crash on his document -- I
haven't debugged
>the problem yet.) Sorry for the delay.
>
>
