tim@efi.com (Tim Maroney) (07/10/90)
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.
sthomas@library.adelaide.edu.au (Steve Thomas) (07/23/90)
In article <1990Jul9.233133.7372@efi.com> tim@efi.com (Tim Maroney) writes: > >Menu items should very rarely vary. HyperCard is one of the worst >offenders, with respect to menu items like "Import Paint". I don't see any way around this for Hypercard: there's just not enough room in a standard menu bar for all the Hypercard menus at once. In any case, I would far rather see only options of relevance at any one time, even at the 'risk' of having menus change. There's no point handing me a box of nails when I'm holding a screwdriver. -- /* Steve Thomas, Barr Smith Library, University of Adelaide */ /* Only a sick society needs disclaimers. Of course, that's only my opinion. */
tim@efi.com (Tim Maroney) (07/24/90)
In article <1990Jul9.233133.7372@efi.com> tim@efi.com (Tim Maroney) writes: >>Menu items should very rarely vary. HyperCard is one of the worst >>offenders, with respect to menu items like "Import Paint". In article <1178@sirius.ucs.adelaide.edu.au> sthomas@library.adelaide.edu.au (Steve Thomas) writes: >I don't see any way around this for Hypercard: there's just not enough room in >a standard menu bar for all the Hypercard menus at once. In any case, I would >far rather see only options of relevance at any one time, even at the 'risk' >of having menus change. I don't have a lot of problems with having *menus* change. That's a clearly visible and natural feedback mechanism. There's nothing deceptive about it. It's when *items* change in the existing menus that I have problems. Note the example -- "Import Paint". It makes sense to me to have the menus change to reflect whole new ranges of options that come into play in a permissible modality, such as selecting a paint tool. You can easily see that this has happened, without doing anything, because the appearance of the screen changes. Not so with menu *item* changes, which are buried and unobvious. >There's no point handing me a box of nails when I'm holding a screwdriver. Then again, saying you have to be holding the screwdriver to paint the walls doesn't make a whole lot of sense either, and this is just what happens when Hypercard demands that you select a graphics tool before letting you "Import Paint".
minich@d.cs.okstate.edu (Robert Minich) (07/24/90)
Two points: 1) If a menu item isn't shown (grayed out, that is) when it's not available, a use may very well be unaware of its existence. If I see it dimmed, I can try to find out how to activate it or look in the online help or RTFM. 2) On a completely different track, how do tear-off menus handle the adding/removing/dimming of items? Most programs I've seen the source for tend to validate the menus after receiving a click in the menubar and so would have stale menus on screen. I'm interested to find out how Apple (Sys 7) and existing implementations (Radius for one) handle this, if at all. Does this mean I should change my menus in real time? Have a nice day. :-) -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| |=(___)= | minich@a.cs.okstate.edu | | U | - Ackphtth |