d88-jwa@nada.kth.se (Jon W{tte) (09/17/89)
I have read about changing/not changing the Standard Alert for quite a while now, and I agree that you shall not change the well-known layout: Save Discard Cancel But since so much happens when you use your modifier keys (i.e. rebuild desktop, launch DAs, inhibit MacsBug, MF or INITs, not to mention MS WORD or PageMaker...) why not let the user chose "save as" by holding any / a special modifier key while clicking "save as" ? You could even change the text of the button as soon as the user depresses the modifier key, and change it back when (s)he releases it. I think I'll do this in my next program... Anyone got any strong arguments why I shouldn't ? h+@nada.kth.se -- Death is life's way of telling you you've been fired.
dave@PRC.Unisys.COM (David Lee Matuszek) (09/18/89)
In article <1684@draken.nada.kth.se> h+@nada.kth.se (Jon W{tte) writes: > >I have read about changing/not changing the Standard Alert for quite >a while now, and I agree that you shall not change the well-known >layout: > > Save > > Discard Cancel > >But since so much happens when you use your modifier keys (i.e. >rebuild desktop, launch DAs, inhibit MacsBug, MF or INITs, not >to mention MS WORD or PageMaker...) why not let the user chose >"save as" by holding any / a special modifier key while clicking >"save as" ? You could even change the text of the button as soon ^^^^^^^^^ I assume you meant "save"? >as the user depresses the modifier key, and change it back when >(s)he releases it. I've never learned to do any of those things. Whenever I need to rebuild the desktop, I have to look up the command sequence. I use MS Word for complex documents, and hate it; no one else in my family will use it at all. >I think I'll do this in my next program... Anyone got any strong >arguments why I shouldn't ? Sure, go ahead, if that's what you want. Three suggestions, though: 1. Be sure to keep "Save As..." around on the standard menus, so that users can click "Cancel," then use "Save As...". 2. Require two modifier keys, e.g. shift-option, to minimize the chances that someone will hit it by accident. 3. Don't document it, or document it in an obscure place. (This last is necessary for uniformity with other Mac programs. :-) I think there is a large contingent of people such as myself who have a very low opinion of command-key sequences and other hidden features on the Macintosh. If you really want them, fine, but please remember to (1) provide all needed functionality to users who do not want to memorize your command sequences, and (2) make them sufficiently hard to hit by accident so they don't screw us up. -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. * 20th anniversary? Yeah, but it's 17 years since the LAST man on the moon! *
chaffee@reed.UUCP (Alex Chaffee) (09/20/89)
In article <11491@burdvax.PRC.Unisys.COM> dave@PRC.Unisys.COM (David Lee Matuszek) writes: >I've never learned to do any of those things. Whenever I need to >rebuild the desktop, I have to look up the command sequence. > [and other bad stuff about the combinatorial explosion of modifier keys] I've always thought that whoever invented the "option" key actually thought he ws doing a good thing. "This way," (he thought), "programmers can make buttons do different things without overly complicating the look & feel [his terminology was ahead of his time] of the interface. If a button (or whatever) has two functions, the second will become active when the OPTION key is down, 'cause it's an OPTION." (Choice -- option -- option key -- get it?) Unfortunately, he never wrote this down in the Interface Guidelines. Programmers saw other programmers using this technique and (since they lacked guidance) turned it into yet another Pandora's box from the likes of which the UI Guidelines were supposed to liberate us. "WHY," I often ask, "did the programmer choose COMMAND-SHIFT (not to mention C-S-CLEAR-&c-&c) rather than OPTION?" If everything funky was done by ONE key, then I would know how to get _any_ funky thing to happen -- and it would be STANDARD. Instead, we learn once again that UNIX repeats itself. Now, I know I'm just crying in the wilderness, that this malady will never be cured -- but is there anyone out there who at least sees my point? Oh, and just to remove some potential flames, of course I see cases where just the option key wouldn't be enough, and we'd have to use Command or Shift or Control... but _always_ as a second choice; the first option should always be taken by the option key. > ... >2. Require two modifier keys, e.g. shift-option, to minimize > the chances that someone will hit it by accident. I am opposed to two or more modifier keys even more than I am opposed to using keys other than option to modify the function of a button which could be modified just as well by one key... Just to eliminate the confusion of "will it do the option thing AND the shift thing, or..." (Actually, I wouldn't _really_ mind multiple presses if they were standardized.) Conversely, when you have your hand on the mouse, how often do you accidentally press any key on the keyboard, let alone option? (Especially if you know option has a reputation for making things 'funky'...) > [ these combinations are never documented ] Yeah; at least in UNIX you can always type "man"... "Nor is it a consequence of my bed's being covered with leaves that I am not hallucinating that it is." - Barry Stroud ____________________ -- Alex Chaffee chaffee@reed.UUCP ____________________
kent@sunfs3.camex.uucp (Kent Borg) (09/26/89)
In article <13330@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes:
...about the lack of Interface Guidelines on the meaning of the Option
and Shift keys as modifiers to clicks (and drags).
I don't remember reading in the Human Interface Guidelines about how
modifiers should be used, but I have observed de facto standards which
well designed programs seem to use.
The shift key constrains the normal action, the Option key loosens the
normal constraints.
Look at common examples: Draw programs use the shift key to force
rectangles to be squares, ovals to be circles, slanted lines to be at
a `regular' angle. Clearly constraining stuff. The shift key also is
used for extending selections. That qualifies as a constraint in that
the current selection is not replaced, only adjusted. Note that by
this description, an action should never be made more dangerious by
the addition of the shift key. Expermenting is safe.
The examples for the Option key are things like the Finder allowing
the trashing of locked files, or FontDA Mover (and other programs)
allowing the opening of any type of file when the Option key is held
down. What about Bartholomew Cubbins (you know, the Dr. Suess
character with all the hats) behavour in draw programs: option
dragging something gives you a copy, leaving the original alone?
Well, cloning something *is* removing a constraint about a single
thing being in two places at the same time, it pretty much fits the
idea. Note that these behaviors are not all safe, experimenting with
the Option key could cause trouble.
What should the Command key do as a modifier? I suggest nothing. It
is already used for standalone commands, further overloading seems too
confusing.
What should the Control key do as a modifier? I doubly suggest
nothing. The control key is a grudging offering to the history of
computing, and some keyboards don't even have it. I say leave it at
that. Besides, if it is left open, I can use it for my QuicKeys.
How about combinations? Only if they fall out naturally, like shift
for constraining a drag, option for copying the dragged object, so
shift-option constrains the dragging of the copy. Any modifiers past
that seems too much.
How's that for some dogma from Kent?
--
Kent Borg "This and being born are the 2 damndest
kent@lloyd.uucp things that ever happened to me."
or -Resident of McClellenville, SC,
...!husc6!lloyd!kent referring to Hurricane Hugo (from NPR)