Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!rutgers!pyrnj!esquire!baumgart
From: baumgart@esquire.dpw.com (Steve Baumgarten)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dialog Edit menu, display of shortcuts (was: Movable-Modal WDEF)
Message-ID: <1838@esquire.UUCP>
Date: 8 Mar 90 15:15:34 GMT
References: <39127@apple.Apple.COM> <1831@esquire.UUCP> <10672@hoptoad.uucp>
Sender: news@esquire.UUCP
Reply-To: baumgart@esquire.dpw.com (Steve Baumgarten)
Organization: Davis Polk & Wardwell
Lines: 202
In-reply-to: tim@hoptoad.uucp (Tim Maroney)

In article <10672@hoptoad.uucp>, tim@hoptoad (Tim Maroney) writes:
>In article <1831@esquire.UUCP> baumgart@esquire.dpw.com (Steve Baumgarten)
>writes:
>>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.
>
>I regard this as a bug.  If people are going to use ModalDialog with
>editable text items, they *must* use a filterProc that allows the
>standard edit menu commands; if they don't, their software is broken.

Sure, but I think programmers just regard this as one of Apple's
friendly tips, like never having commands that can only be accessed
from the keyboard.  Certainly Microsoft has never taken many of
Apple's human interface suggestions, and I can only think of two or
three other applications that I own that properly support cut and
paste in modal dialogs.

Just out of curiosity, does MacApp provide support for this?

>>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.
>
>I don't really think so.  I've never observed a novice even *try* to
>pull down a menu when a modal dialog is up.  It seems obvious to them
>that it wouldn't work.  

Of course, since the Edit item is always dimmed.  But in Nisus the
Edit item is enabled, so you're encouraged to take a peek and see
what's there.

You could say something similar about many communication programs --
most don't allow you to use desk accessories under Finder while
downloading.  In most cases you're presented with a (possibly)
movable, but modal dialog and all menu items are dimmed.  But
Versaterm keeps the Apple item enabled, so even if you didn't know you
*could* use desk accessories, you're given a strong reason to think
that the computer won't beep at you if you try.

>			 So, the only people who would benefit from the
>feature are people who are at least semi-experts, people who read that
>part of the manual.  But these are people who probably always use the
>edit menu shortcuts anyway.

Again, something similar could be said about the trick that
Multifinder pulls when you double-click on a file the application for
which is already running.  My roommate (a computer novice) knows all
about the File menu and the "Open" choice to work on a different file,
but he never considered using it after he found that he could
double-click on a file in the Finder layer.  I neither showed him that
nor suggested it could be done.

The funny thing was, he wasn't surprised when it worked.  To him it
seemed a perfectly natural extension of his standard Finder skills.
But I remember the first time I did this using THINK C -- I was
surprised that it worked!  I'm so used to using "Open" that my brain
lagged behind my fingers.

So I think cutting and pasting in dialogs is much the same thing.
People who don't know better try it (at least once), and if they're
not beeped at will continue trying it.  But since most Mac
applications don't support Edit items in dialogs, novices are
immediately discouraged from further experimentation in other
programs. 

>>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).
>
>Technically, it's not at all hard to intercept and handle clicks in
>the menu bar from a modal dialog filter proc.  The question is whether
>the effort involved is worth it.

Since it doesn't reduce the program's functionality, nor interfere
with its use by experts, I'd say it is worth it.  It wouldn't be a
question, though, if each application didn't have to support cut and
paste itself, in its own idiosyncratic way.

>>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.
>
>Ooh, I hate those.  Talk about some ugly buttons.  Yeah, the reminder
>is nice from a psychological perspective, but the appearance of the
>shortcuts themselves is nasty from an aesthetic perspective, at least
>to me.  If pressed to justify this judgment, I'd say that the graphic
>simplicity and symmetry of a text label is being spoiled by the
>addition of an extraneous and assymetrical element.  Suitcase does the
>same kind of reminder, and I wince every time I look at it.

I think you misunderstand.  I agree with you about the way Suitcase
does things, but this is different than Nisus' implementation.  In
Nisus, the dialog box looks like any other dialog box on the Mac --
just buttons, one of which is highlighted, but nothing more.  However,
when you press the command key -- and only when you press the command
key -- the shortcuts are displayed next to the buttons, outside of
their outlines (i.e., the buttons themselves do not change in any way;
instead, some text appears to the left of the buttons that have
shortcuts). 

So from an aesthetic point of view the look of the dialog box is never
spoiled or cluttered.  But when the person decides that he wants to
try out a shortcut (let's say he knows that most buttons have
shortcuts but can't remember what they are), he can tentatively press
the command key.  The shortcuts are displayed for as long as he holds
the key down; if he then releases the command key without choosing a
shortcut, the dialog box returns to its original state: buttons only,
without shortcut labels.

This really seems to be the best of all possible worlds, since as with
cut and paste in dialogs it provides a great deal of help to novices
but doesn't slow down experts.

>Shortcuts are for power users, and power users are likely to look in
>the on-line documentation for a shortcuts section, while
>non-power-users are likely to ignore even the most obvious shortcuts.

>This being the case, it's all right to have a single clear hidden rule
>for all shortcuts rather than a constant reminder of a diverse set of
>variously-chosen shortcuts.  My favorite way to do button shortcuts is
>still what I did in TOPS Terminal.  Outlined buttons take return or
>enter.  Cancel buttons take Cmd-Period or Escape.  All other buttons
>are unique in their first letter and take Cmd-Shift-first-letter.
>People did in fact use these shortcuts and find them convenient, and
>it's very little effort for the programmer to make sure that the
>buttons have unique first letters.

Sometimes that's not possible though, and I don't think it's so great
to have some shortcuts use command while others use command-shift.
However, it is good that you went to some extra effort to provide
command keys at all; many applications don't.

But it would be so much better if Apple support this kind of thing at
a lower level.  They do for menus, so I don't think it's out of line
to ask for additional support for dialog boxes, especially if it can
be done as unobtrusively and intuitively as it is in Nisus.

>(Though I haven't examined Nisus, I have also heard that the interface
>has one of the main problems with all Mac word processors I've used
>[MacWrite, Word, FullWrite] -- meaningless graphics littering the
>screen, each of which has some secret meaning which, once you've read
>the manual, you can figure out and perhaps remember a few hours later,
>but which is not at all suggested by the graphic itself.  Better just
>to use text than to use an arbitrary graphic.)

[ As an aside, I remember people saying just this about the Finder
when the Mac was first introduced.  But I digress... ]

Sure, this is one of its failings.  To its credit, however, all those
commands are accessible from the menubar, so even if you can't
remember what an icon means you can still make use of the function.
In a sense it would have been better to make that a setting that by
default would be disabled; once people get used to the program, they
can then take advantage of the speed using icons provides.  But when
they're first learning it they won't be overwhelmed with inscrutable
or ambiguous pictures.

Nisus is far from perfect, but compared to many Mac applications it
goes a lot further to make things easier for novices.  Here's an
anecdote that helps describe what the competition is like:

    In the most recent Macworld (or possibly MacUser), there's a
    question in the help section about how to get Word to display
    all the installed fonts.  Incredible how confused people get
    by this.  The answer discussed using the bizarro option-+ (or
    whatever) combination to repeated click on a font to add it
    to the menu, but then went on to say something like "But you
    can add all the fonts in one step -- *if* you know about the
    'list all fonts' command."  It was the "if you know" part that
    really got me, because the command is only accessible from the
    dialog box that lets you fool with your menus.  And that
    dialog is as confusing as any I've ever seen.

Anyway, I don't want this to turn into a "mine is better than yours"
flame fest; I just wanted to clarify why I think Apple should consider
changing the standard Mac dialog interface, in addition to clearing up
a misconception or two about Nisus.

--
   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