Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!esquire!baumgart
From: baumgart@esquire.dpw.com (Steve Baumgarten)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Movable-Modal WDEF 1.01 (LONG)
Message-ID: <1831@esquire.UUCP>
Date: 6 Mar 90 19:02:35 GMT
References: <39127@apple.Apple.COM>
Sender: news@esquire.UUCP
Reply-To: baumgart@esquire.dpw.com (Steve Baumgarten)
Organization: Davis Polk & Wardwell
Lines: 66
In-reply-to: mjohnson@Apple.COM (Mark B. Johnson)

In article <39127@apple.Apple.COM>, mjohnson@Apple (Mark B. Johnson) writes:
>Handling a movable-modal dialog is just like any other window.  There
>are really only two differences.  If the front window is the
>movable-modal, then you ignore any click outside the window.  Also
>ignore menu command keys.  The latter is currently a subject of
>discussion with the Human Interface group.  I've found that it's very
>difficult to handle the menu if the window is modal.  The biggest
>problem is what items would be enabled?  Should a desk accessory be
>allowed to be opened?  Maybe the solution is to disable ALL of the
>menu items.  That's up to the Human Interface group to come up with
>some guidelines.

I always thought that this was one of the great failings of the Mac
user interface.  While DTS has preached to us about designing our
programs so that the user is in control, so that he's never surprised
or locked into a mode, etc., the Mac OS itself violates many of these
rules.

Specifically, people tend to want to cut and paste in dialog boxes and
are continually surprised and annoyed when they can't.  Even if it's
the kludgy Hypercard script editor solution of supporting the keys and
not the Edit menu, anything would be better than forcing people to
type things when they shouldn't have to.

Nisus solves this problem very, well, nicely.  It *always* keeps the
Edit menu enabled, so that you can cut and paste anywhere, even in
modal and StdFile boxes.  I find myself reaching selecting parts of
names in other programs' StdFile boxes and trying to use CMD-X and
CMD-V, and I'm always frustrated when I can't perform this most basic
of Macintosh functions.  Best of all, since Nisus allows you to choose
cut and paste from the Edit menu, this feature is available to novices
as well as experts.

So if there's any way to add support for Edit menu items in modal (and
non-modal) dialog boxes, I urge the Human Interface group to consider
it.  It's easy to forget that new users don't know what we veterans
have known for a while -- that some things "aren't allowed", but for
no justifiable reason (apart from programming, which is never a valid
reason when you're trying to explain to your mother why the skills she
just used in her MacWrite document suddenly cause the computer to
beep).

By the way, Nisus also handles the issue of command-key equivalents in
dialog boxes with equal aplomb.  Instead of forcing you to wade
through a manual as Word does, Nisus displays the "cloverleaf-letter"
combinations right next to the buttons as soon as you press the
command key.  So a novice can use the dialog boxes in the traditional
point-and-click way, a more experienced user is given reinforcement to
aid his memory, or is just allowed to consider the possibility of
using command keys without having to haul out the manual, and an
expert is not slowed down in the least.

All in all, Paragon software has done some serious thinking about
their program's user interface and about the low-level Macintosh
interface, and I think they've made the right decisions.  If the Human
Interface group isn't familiar with Nisus, they should definitely
check it out.

It's also a great word processor, but I'll save that discussion for
another group.

--
   Steve Baumgarten             | "New York... when civilization falls apart,
   Davis Polk & Wardwell        |  remember, we were way ahead of you."
   baumgart@esquire.dpw.com     | 
   cmcl2!esquire!baumgart       |                           - David Letterman