Xref: utzoo comp.sys.mac.programmer:15867 comp.sys.mac.misc:1173
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!efi!tim
From: tim@efi.com (Tim Maroney)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.misc
Subject: Re: Menu items that change
Message-ID: <1990Jul9.233133.7372@efi.com>
Date: 9 Jul 90 23:31:33 GMT
References: <40218215MES@MSU> <42382@apple.Apple.COM> <42383@apple.Apple.COM> <1990Jun27.180718.3155@portia.Stanford.EDU> <1990Jul3.143206.940@acc.stolaf.edu> <886@mdavcr.UUCP> <23043@dartvax.Dartmouth.EDU> <8997@goofy.Apple.COM> <23058@dartvax.Dartmouth.EDU>
Organization: Electronics For Imaging, Inc.
Lines: 47

In article <23058@dartvax.Dartmouth.EDU> kurash@carr (Mark Valence) writes:
>As my original posting states, I also disagree, but for different reasons.
>First of all, I do see an 'essential difference'.  In the case of 'Clean Up'
>the changing item does not just 'clarify'.  It can actually be changed
>by clicking i nthe appropriate place.  I'm sure every Finder-retentive
>Mac user (like me) has been frustrated by this item - you go to clean
>your window up and - damn, forgot to unselect.

Very true.  This is a good example of modal behavior that should be
avoided at all costs.  As Inside Mac says (I-28), "Being in a mode
makes future actions contingent upon past ones, restricts the behavior
of familiar objects and commands, and may make habitual actions cause
unexpected results."  The variable Clean Up item has all these
problems, and variable menu items in general always risk them.  Undo is
inherently a command that is based on past actions, so it's all right
to have its menu item be modal.  Other familiar examples, however, are
not so clearly permissible.

Clean Up is right out of there; it doesn't have any saving graces that
would make it a permissible modalism.  Check the list of excuses for
modality in IM I-28-29, and you won't find anything that's even in the
ballpark.  A more applicable statement is:  "If you yield to the
[modal] temptation too frequently, however, users will consider
spending time with your application a chore rather than a satisfying
experience."  (IM I-28)  This is a perfect description of the constant
annoyance of having to deselect before Cleaning Up.

Show/Hide Clipboard is also problematic -- which one will come up if
the clipboard is visible, but not frontmost?  What if the clipboard is
neither frontmost nor visible, but is still "potentially visible"
because it is hidden by other windows in front?  I think it is better
to make the item invariant.  It should always be Show Clipboard, and it
should always make the clipboard window the frontmost visible window.
If the clipboard window is already visible and frontmost, the menu item
should be either disabled, or a no-operation.  There are already a menu
operation (File:Close), a different mouse operation (close box), and a
keyboard shortcut (Command-W for Close) to get rid of a frontmost
clipboard window.  Adding menu modality is a "neat trick" that is
gratifying to the programmer but doesn't help the user, and it will
cause frustration if the user's assumptions about the menu item don't
match the programmer's.

Menu items should very rarely vary.  HyperCard is one of the worst
offenders, with respect to menu items like "Import Paint".  Finder is a
runner-up in the contest for most gratuitously modal menus, with Clean
Up Selection.  Unfortunately, these things acquire momentum and it is
probably too late to do anything about them now.