Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dialog Edit menu, display of shortcuts (was: Movable-Modal WDEF)
Message-ID: <10672@hoptoad.uucp>
Date: 8 Mar 90 01:18:01 GMT
References: <39127@apple.Apple.COM> <1831@esquire.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 113

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.
This is one of the most common bugs on the Mac, unfortunately, and it
even crops up in Apple programs like HyperCard.  (Try pasting the name
field of a card, background, button, or field sometime in HyperCard
1.2.2.  It's amazing to me that this hadn't been fixed in a version
that came out some two years after the initial release of HyperCard!)

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

Maybe if all other menus were disabled when a modal dialog came up,
that would be eye-catching enough to some neophytes to suggest pulling
down the menu.  But I still doubt that many people would either notice
it or figure it out.

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

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

The right-column/left-column arrangement of a menu is inherently more
capable of supporting this kind of thing than oval buttons are.  As
graphic elements, ovals demand bilateral symmetry, while rectangles can
cope with a division into unequal columns.  This approach to shortcuts
would perhaps look better with rectangular buttons, but they'd have to
be very close together vertically, and the shortcuts would have to be in
a clear and distinct column.

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.

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

I don't know.  What you've said sounds like programmer-think rather
than user-think or artist-think.  There's a vast gap between these
kinds of thinking, and learning to think like a non-programmer is the
most basic skill of friendly user interface design.

(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.)
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Skip, witches!  Hop, toads!  Take your pleasure!"
    -- Aleister Crowley, THE BOOK OF LIES