Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scott.cis.upenn.edu!grobbins
From: grobbins@scott.cis.upenn.edu (Grobbins)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dialog Edit menu, display of shortcuts (was: Movable-Modal WDEF)
Summary: choices and compromises in Nisus
Keywords: user interface Nisus dialogs menus
Message-ID: <21518@netnews.upenn.edu>
Date: 8 Mar 90 21:13:46 GMT
References: <39127@apple.Apple.COM> <1831@esquire.UUCP> <10672@hoptoad.uucp> <1838@esquire.UUCP>
Sender: news@netnews.upenn.edu
Reply-To: grobbins@eniac.seas.upenn.edu
Organization: U. of Pennsylvania
Lines: 66

In response to discussion of Nisus' user interface:

In some respects, Nisus makes wonderful additions to the Mac user interface.
In other respects, it's an ugly hack.  But everything that's there is there
for a reason.

Nisus makes many extensions to the Mac interface which carry on Apple's
recommendations to the nth degree.  Virtually every editing action is
undoable, in multiple stages.  Rear windows are all active when the
command key is down -- just as in the finder you can drag rear windows
by holding down command, in Nisus you can drag, resize, scroll, click
buttons, and select text in rear windows, without activating them, by
holding down command.  An option key modifier means "do to all" here
and there in other applications; in Nisus, option-zoom zooms all
windows (effectively tiling them), option-close closes all windows, and
so on.

While these are good extensions (IMHO) even these simple enhancements
inevitably bring up problems: should cmd-Z twice be Undo Undo or Undo Redo?
(Nisus does the latter, using shift-cmd-Z for the second and further Undos.)
Should cmd-click in a rear window act like a click or a command-click
(in cases where, in the front window, they would do different things)?
As programmers realize, there is no such thing as a _simple_ enhancement.

Other issues are clouded by history: should shift-arrow key extend the
selection?  Hardware snafus made that difficult, even though (as memory
serves) Inside Mac recommended it from day one.  Because Nisus supports
simulated arrows (for pre-Mac Plus keyboards; cmd-space is right arrow,
shift-cmd-space is select to the right) arrow key selections were not 
supported.

Labeling buttons in dialogs was an easy win; once a programmer thought 
of the method (showing equivalents only when cmd was held down) it seemed
obvious.

Is being able to choose menus from modals a step forward or backwards?
I think the latter, because modals should be obviously and completely
separate, not "fuzzy" in modality.  The programmer used menu selections
from dialogs as a way of avoiding scrolling lists in QUED, and due to
time and money pressures, the method stayed on in Nisus.

While using scrolling lists would be a better method in most cases,
there are some where it's not.  For example, defining a user text style
already takes up a long, complex dialog.  Adding lists of font names,
sizes, and so on to the dialog only makes it more intimidating.  Letting 
the user select the items from the menus is an easy out, in that
situation.  While menus during modals started out as a hack, and stayed
in because of outside pressures, in the end other arguments keep it
alive -- orthogonality (consistency) and overall simplicity.

Why are meaningless icons omnipresent in Nisus?  Two reasons: no one has
suggested more meaningful icons, and users don't want to do without the
convenience of having certain controls (like page preview activation)
handy.  As mentioned before, nearly all icon controls are duplicated 
in the menus.  (Not just because it's the proper Mac way to do things,
but also because it made implementing macros easier.)

Again IMHO, Nisus has serious user interface problems remaining.
(FullWrite is much better thought out.)  But it also has some great ideas, 
worth standardizing.  And anyone who can pick up MacWrite without reading the 
manual would be able to use 85% of Nisus without training.

Grobbins       grobbins@eniac.seas.upenn.edu

(occasional design consultant on Nisus, years ago; no current
affiliation with Paragon Concepts, except as a nagging user.)