Word's take on MSDI (was Re: FAQ -- why the MSDI interface? (aka, no pagers please))

Subject: Word's take on MSDI (was Re: FAQ -- why the MSDI interface? (aka, no pagers please))
From: Paul Rohr (paul@abisource.com)
Date: Mon Aug 20 2001 - 00:23:07 CDT

At 04:15 PM 8/19/01 -0400, JAL wrote:
>Screenshots, as requested. (I ran in and grabbed somebody's Windows box,
>so the colors are non-standard.)

Thanks for the screenshots. They're *very* helpful.

>As you can see, MSDI Word 2000 still has a close box for what was the
>child window in previous versions, even though it normally opens docs in
>separate parent windows (look at the far right of the menubar. When the
>last doc is closed, Word reverts to the plain background. The program
>stays open, and a new doc can be opened or dragged in from Explorer.

Oh dear. That's even worse than I feared. It's arguably better than MDI,
but the taint of their MDI legacy still lingers in the form of those two
close boxes per frame. After promoting MDI for so long, I suppose they felt
that a more gradual transition for their existing users would be a good
idea, but ...

... gack, what a hack!

Knowing how thorough they are, not only did they put that stupid
document-level close box on the menu bar, but it probably moves to the
toolbar if the menu is disabled (or do they no longer allow that?) So long
as that widget is visible, it would allow you to close the document in that
window (leaving it empty) without closing the application-level window.

Now I see how their UI probably works, though. One of the widgets maps to
File / Close, and the other maps to either:

  - Window / Close (which implies File / Close) or
  - File / Exit (which implies close *everything*)

... depending on how many documents and windows are currently open. Right?
It's overly complex, but at least it's consistent.

Or is it? I've also heard people say that if there's more than one document
open, then File / Close maps to Window / Close (ie, the outermost close box
widget rather than the "inner" one). If so, then there's no one-to-one
mapping between menus and widgets at all, because the "final" File / Close
*does* only close the document and not the window.

Ick. What a choice. Either all File / Close operations leave empty,
reusable windows cluttering the screen (equivalent to clicking the "inner"
close box), or else you have inconsistent behavior -- sometimes the window
goes away ("outer" close) and sometimes it doesn't ("inner" close).

I'd hate to explain this all to my Grandmother, either.

Having seen this, and unless I've missed some crucial detail here, then my
preference for our *much* simpler model is, if anything, even greater. For

  - we only have a single "outer" close box,
  - File / Close is always equivalent to Window / Close, and
  - when you close the last document, you're done.

It may not be what everyone expects at first, but it's easy to understand,
*very* easy to explain, and (I hope) reasonably easy to get used to.
Indeed, I share Nils' belief that most people will recognize the Netscape
similarities without even thinking about it.

>We had a user who was frustrated when she dragged a doc from Explorer
>into Word and, instead of opening, it was embedded in the doc that was
>already open. She had to be taught to click the close box for her doc
>before doing this.

Yep. That's probably another reason Word's UI designer liked the MDI-style
second close box -- it creates an obscure way to allow the drop target to
mean "open the document" instead of "embed the document".

I suppose that's a real design constraint, but it seems like a pretty
contorted solution. I understand why you'd want the default drop action for
any other file type to be "embed" rather than "open", but as your user
demonstrated, who wants to embed one Word document inside another? If you
drop a Word document on Word, don't you want to open it?

I'd think a far more plausible solution would be to just special-case that
one file format with "open" semantics for drops instead. But I don't work
in Redmond, so maybe they had other design constraints to deal with.

pixel pusher

This archive was generated by hypermail 2b25 : Mon Aug 20 2001 - 00:15:18 CDT