| ||||||||||||||||||||
| ||||||||||||||||||||
Originally published in the AppleDirect, August, 1989
Republished as Chapter 6, in Tog on Interface
Dear Tog: I’d like to pose a few questions for you to examine. My main concern is pretty basic but fairly important. I’m worried that the command-key is breaking down as a valid method to communicate instructions. There is very little consistency between programs these days and I really have too many functions to address with a small set of commands. So here goes:
I would like the current list of suggested command keys to be expanded. Command K is used as a delete function in some programs, yet it initiates something in others (AppleLink).
A separate but related issue would be a tutorial on ordering items on the menu bar and within menus. I used to order functions in workable groups, but found the programs easier to use if the functions were grouped with the most used towards the top. How do you feel about this?
—Aaron Rosenbaum
Tog Responds: Frankly Aaron, I mainly feel saddened that you, a pillar of the software community, would have the audacity to accuse me, a Cupertino-renowned evangelist, of pontificating. But I will lay all that aside (particularly since I am sadly lacking in a defense), and answer your question.
We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.
People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.
It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.
While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.
Hence, users achieve a significant productivity increase with the mouse in spite of their subjective experience.
Not that any of the above True Facts will stop the religious wars. And, in fact, I find myself on the opposite side in at least one instance, namely editing. By using Command X, C, and V, the user can select with one hand and act with the other. Two-handed input. Two-handed input can result in solid productivity gains (Buxton 1986).
Command-Key Illusion. Since users do experience the illusion that keyboarding is faster, there is market pressure to supply them with "shortcuts."—even when using "shortcuts" will actually slow them down. What I generally recommend is supplying as many "shortcuts" as demanded by the market—the real market, not the programmer in the cubicle next to you. But only if these "shortcuts" are not to the detriment of the user of the Macintosh visual interface. This leads to two important guidelines:
Guideline: The keyboard interface must not dictate the design of the visual interface.
Guideline: The work to design and build the keyboard interface should not sap resources that are needed for the creation of the visual interface.
In other words, don’t rape the primary interface for the benefit of so-called "power-users," who may well end up achieving lower productivity by using the keyboard interface anyway. This is a major problem right now.
(Thank heavens I gave up pontificating!)
And now on to your specific questions:
1) P stands for....
At the time this column was written, at Apple, P stood for Plain, the command that would make bold, italic, or otherwise styled text into unstyled text. Unfortunately, everywhere else in the civilized world—like in all our developer’s software—P stood for Print. I wrote in this column, in no uncertain terms, that P still stood for Plain. I also began a dialog inside Apple the led to changing it. I was helped in that effort by letters from the readers demanding a change. The result? P now stands for Print.
2) Multiple-key commands (e.g., option-command-shift-9) started out only applied to system functions, but they have certainly proliferated beyond that. At this point, there are no rules for how many keys can be used beyond common sense: the more keys required, the slower the action and the fewer the people who will have the dexterity to use them. Again, because the so-called power user is rocking away at high speed on the keyboard is no evidence that he or she is being more productive; it only means he or she is having to work really hard to accomplish the task.
3) User-specified command keys are the best solution to the current problems, leading to the following guideline:
Guideline: All command-keys should be user-specifiable. The developer can and should supply an initial set, but the user should be able to overrule those choices.
In the early (pre-release) days of Lisa, we had command keys instead of pull-down menus. One of the primary reasons we abandoned command keys was the difficulty of coming up with fixed definitions that could be easily transported from application to application. Users were constantly confused.
I remember one mainframe company in the sixties that came up with the following command-key guidelines:
A real power-user paradise!
Users are better able to remember disconnected data when they are the source for that data: they can remember shortcut keys far better if they assigned them. This fact was the basis for our decision to enable users, not applications, to control the programming of F1 through F15 on the USS Saratoga—I mean, extended—keyboard. (USS Saratoga was our code name during development of the extended keyboard because of its eerie resemblance to the popular aircraft carrier. Not so much the shape as the size.)
Specifiable command keys also enable the handicapped who cannot use the mouse access to applications without burdening the rest of us with cluttered menus and the siren song of improved productivity where none exists.
4) "With one level of undo, command z undid, command z again re-did. With multiple levels of undo could you propose a key for re-do?"
How about Command-Shift-Option-Control-Help-Triple click? Oh, its been used?
On September 19th, MacWeek will be hosting InterfaceDesign‘89, a conference in San Francisco on the Macintosh interface. This will be a working conference where you developers can tell us what you want. We expect to incorporate many of your suggestions into the Guidelines. Let us know what key you think should be used for re-do.
I would also hope that we might be able to hammer out some more standard Command key equivalents, although for the life of me, I cannot imagine why Command K would mean delete. Could it stand for kill?
I would also like somebody—anybody—to show up with one properly-conducted test report that shows that command keys are equivalent or superior to pull-down menus somewhere, somehow.
Menu ordering is another topic that should be raised at ID‘89. Aaron is correct in assuming that items toward the top are accessed faster. In face, our research showed that the fastest item of all is—drum roll—item two. Then there’s the standardization of where items will occur on the menu bar: I am pleased to see that the new version of AppleLink, 5.0, will actually open documents in the File menu. How revolutionary! Now if we can only get HyperCard to even have a menu bar....
But that’s next month’s column.
| The ID'89 conference was quite a success, and, following it, we adopted a much more complete set of command keys, published in my 1989 edition of the Guidelines.
This column set off a flurry of email like no other. Here are just three of the responses received... |
In The Thick Of It
Tog,
As a developer and experienced user, I strongly disagree with your discussion on command keys....
First, I disagree with the statement that keyboarding is slower than mousing. Bet you could see that one coming. I have absolutely no doubt that for most of the users, the non-power users (for lack of a better term that has been extremely over used), mousing is faster. To me, this is a basic part of the Macintosh user interface. Users should ALWAYS learn via the mouse and ONLY in the most used statements convert from mouse to keyboard. For example, I and many of my users and clients type at 75-125 words per minute. In their environment, they and I have set up key equivalents such as Control-B for bold. In typing their documents, it is far faster for the experienced user to type Control-B then the word then Control-B for a single bold word than it is to do the equivalent with the mouse. For the non-power users, it is far faster to select the mouse command. This is not because the mouse is inherently faster or slower than the keyboard, but because of the switching time between the two devices for the power user who types at extreme rates. I don't know how fast you type, but I know that some of my clients and myself no longer think of words as a series of letters. We actually think in a pattern of keystrokes. I don't think of 'the' as 't-h-e', I think of it as 'the'. Bottom line -- key equivalents are, as you said, slower for anyone who doesn't type at an extreme rate. But, they are far faster for those of us who do.
Second, I'm glad that Apple think that Command-P stands for Plain, but lets not fight what is CLEARLY the standard -- and that is Print. Most of my clients, users and definitely myself Print far more times than selecting Plain. Now, you’re probably sitting there saying "this guy is out of it," but think of this. Most of the time when you are word processing, you are typing in the Plain style. Occasionally, you may bold or underline something. If the formatting takes place while typing, most people will choose BOLD type some and then choose BOLD again. The other type of formatting takes place after the typing. In this case, the user rarely needs the plain command because he/she has selected only the relevant text. Now, the obvious exception to this is the user who frequently uses styles with multiple styles, but in my experience, this is much less common in everyday use.
Finally, what's the difference if Command-K does stand for kill, as long as the user remembers it?
-Neil Ticktin Truin Software
Hi, Nick,
I don’t think most folks can touch-type 75-100 command-keys per minute, particularly with the weird layout of the keyboard we’ve adopted, which often requires the user to curl the thumb underneath the other keys. Regardless, you have presented the standard argument that makes it seem logical that command keys would be faster. Unfortunately, experimental evidence does not support the argument.
You also argue that there is no need for a short-cut key for Plain, as there is for Bold, etc. You have presented an argument based on most people writing in a very specific style, and with no errors. I not only make errors when I type, but I play with the text, over and over, until it scans the way I want it to. As a result, I probably use the plain key equivalent in my word processor—Command-Shift-Space—at least 30 times per day. I print perhaps 5 times per day.
There are two things wrong with Command-K for kill. First, the menu doesn’t say, "Kill," it says Delete. Second, it violates an unwritten, but long-standing guideline:
Guideline: words like "kill," "abort," and "default" have powerful emotional charges connected with them and have no place in the interface. Instead, use words like "stop," "cancel," and "standard."
Your argument that P for Print is clearly the standard is well-taken: I hope we will change it soon.
-Tog
Its All In Their Minds
Hi, Tog,
... The August Apple Direct issue just arrived with your "Command Keys vs. the Mouse" article. I totally agree with you about keyboarders versus mousers. Keyboarders only think they are faster—I think its because of the sound of the keys, and the boss thinks work is flying when he hears those keys pecking away. If the mouse had a motor in it so it made a sound like a motorcycle or a whoosh or a zip, maybe folk would think the mouse was faster.
As a result of my observations of users, there are NO command key equivalents in my product, Smart Labels, except for Undo, Cut, Copy and Paste. The Clear and Escape keys will clear the label text edit box. Users may demand key equivalents, but I will resist them. One of my current interesting projects is software that will work with the keyboard disconnected, and, in-fact, will not respond to any keystrokes. How's that for an interface challenge!
—Kim Hunter
Or Is It?
Tog:
I have been doing some study and testing on the issues raised by your last article and would like to share some of my thoughts. (If they prove useful maybe you could cut me in on some of that $50 million you paid the guy to time the 2 second "amnesia time slice"!)
Let me begin by saying I agree that the mouse should be the primary interface to any application and that any support of the keyboard should in no way reduce the efficiency of the mouse or the aesthetic appeal of the graphical interface.
I disagree, however, with the premise that mousing is faster than keyboarding (notice that I did not say that I believe keyboarding is faster than mousing). I believe that making such assumptions will stand in the way of providing the user the ability to determine just how he will interact with the computer for any given function at any given time.
In your article you state "The keyboard users in this case feel as though they have gained two seconds over the mouse users, but the opposite is really the case." To the keyboard user, it may not matter that he was actually slower, because he has perceived a speed increase over using the mouse. It is the subjective nature of perception and the disparity between perception and reality that gives rise to the "religious" nature of these discussions.
I came across an interesting example of perception vs. reality while designing a small text editor: When scrolling the text horizontally in a window we would refresh the text by redisplaying each line starting at the top. This resulted in a wave of text rippling down the screen, and many complaints that the screen refresh was too slow. The remedy was to scroll the bits already on screen and then redisplay each line from the top. The second implementation was actually slower than the first because we incurred the overhead of scrolling the bits before we even started to display the new text on the screen. However, the perception was that there was an immense increase in speed. We stuck with the second implementation because it increased the overall satisfaction of the user even though it actually decreased the throughput of the product.
In my mind, perception is stronger than reality. A user’s perception of a product is what causes him to purchase it and influences his satisfaction with the product...
I'm not trying to propose that Apple abandon the mouse interface. On the contrary, as I stated earlier, I believe that the mouse/graphical interface should remain primary. But I strongly believe that more needs to be done to allow for the experienced user who is willing to make an investment in learning to be allowed more keyboard access to the entire interface, not just menus. I think Donald Norman [Norman, 1988] put it best when he said "…the design should not impede action, especially for those well-practiced, experienced users who have internalized the knowledge. It should be easy to go back and forth, to combine the knowledge in the head with that in the world. Let whichever is more readily available at the moment be used without interfering with the other, and allow for mutual support."
-Nolan Larsen, WordPerfect Corp.
|
Don't miss the next action-packed column! Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com. |
 |
| Contact Us: Bruce Tognazzini Copyright Bruce Tognazzini. All Rights Reserved |
