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.
