🚀 go-pugleaf

In article <2067@cbosgd.UUCP> db@cbosgd.UUCP D. Bird) writes:
>What is also needed, however, is a way to turn the shortcuts on and off.
>(They should probably default to being off.)  Otherwise, naive users (and
>not-so-naive users) can accidentally type in a command or option key sequence,
>have no idea what they did, and in some cases, are unable to undo whatever
>the sequence did.
There should be no such cases if the programmer is following user interface
guidelines.  All operations which modify data should have an undo.

>The "shortcut switch" could be implemented a number of ways, among them:
>o Yet another parameter in the non-volatile RAM, with control panel access
I would recommend this option.  This would allow for turning off shortcuts
independently of whether the application allows it.  (This assumes the
applications gets command-key shortcuts the 'standard' way, of course.)
New applications could provide built-in tools for manipulating the
'shortcut-behavior' attributes, obviating the need to go to the control
panel.[shortcuts for shortcuts?]

Here's a possible Macish implementation.  (Sorry for the confusion between
Alert and Dialog boxes, I don't recall which one demands attention before
proceeding.)

Assume the 'shortcuts-allowed' attribute can be set three ways.
Silent (what seems to happen currently)
Indicate (via pulling down menu and gray-higlighting the item.)
Silent + Confirm (is this useful?)
Indicate + Conf=rm (Indicate + Alert/Dialog Box)

If shortcut is attemped (command-key something pressed), the mac will do the
following things:
Silent: execute the operation
Indicate: pull down the selected menu and item, and briefly highlight the
	operation before execution
Confirm: indicate, throw up a 'Confirm' dialog box

+--------------------------------+
| <menu_name>:<operation_name>	 |
| Perform this operation         |
| (Yes)	(Describe Operation) (No)|
+--------------------------------+

Putting this feature in the system would also tend to raise consciousness
about the right way to do shortcuts, which would be a good thing.

Conclusions:

There are probably other, more important user interface nits to pick.
After thinking through the implementation, I feel that it more biased
toward protecting the novice user.  It also adds a lot of hair to the
shortcut interface, as well as requiring system-level modifications.
The problem is that it's not in the spirit of the user interface guidelines
to simply ignore keystrokes, even potentially 'dangerous' ones.

Please post other possible solutions for consideration, this is getting
interesting.
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@c.cs.cmu.edu (cmu-cs-c.arpa)	Usenet: ralphw@mit-eddie.uucp
Fido: Ralph Hyre at Net 129, Node 0 (Pitt-Bull) Phone: (412)CMU-BUGS