WIDGET OF THE WEEK NO. 1

MAKING A SUBSELECTION FROM A LIST

The conventional way of making a subselection from a list is to present the list and the sublist as two panels. Between them are a number of buttons such as ADD, ADD ALL, and DELETE (one of these is illustrated on a following page). The usual method of operating such a subselection mechanism is to

• select the item on the list on the left
• press the add button

More sophisticated users can do tricks such as "shift-click" additional items on the left and then add the selected items all at once by using the ADD button. Another sophisticated-user alternative is to double-click on items on the left to add them to the list on the right. Some implementations permit the user to select (by dragging a selection box) a range of contiguous items. For occasional and untrained users, these "sophisticated" methods are not familiar, and there is no way of figuring them out from the screen unless detailed instructions are permanently part of the display. Fortunately, a better method is available.

To be concrete, say that a user is choosing a number of items to be requisitioned from a catalog of items.

In the second illustration we see a single list (not all the features shown will be discussed). Alongside of each item are a pair of radio buttons. In this example they are labeled "Not requisitioned" and "Requisitioned." It is important to label the radio buttons explicitly rather than with general "Yes" and "No" column headings or terms such as "Include" and "Exclude". Such general headings force the user to have to take an extra mental step such as "Am I saying 'yes' to putting them in to the requisition or 'yes' to leaving them out?" Having to make such decisions takes time, breaks up the user's train of thought, and is a source of errors when the wrong decision is made.

To see the subselection, another pair of radio buttons should be provided (here done incorrectly with a check box) in this case labeled "Show All Items" and "Show Requisitioned Items Only."

A keystroke analysis shows that we have, for the unsophisticated user or any user looking for isolated items, replaced move-click-move-click with a simple move-click, and the move is usually shorter: it is nearly twice as fast as the conventional design. For the sophisticated user we have replaced move-click-click with move-click, a smaller gain but a gain nonetheless. Note also that double-clicking often fails for users with an inability to do rapid repetitive motions, when using a press-to-click tablet or with a touch-screen. In the latter two cases it is hard to click in the same place twice. For these reasons, and because double-clicking is an "invisible" command (in the sense that nothing on the screen indicates that double-clicking will do anything special), use of double-clicks in interface design should be avoided.

To select contiguous items we can permit click-drag-release where the first click is on the radio button on one end of the range and the user drags through to the last button in the desired range. A "Requisition All" (or whatever the task is) button can serve when the entire list is to be selected. When it is used, all the radio buttons change to the selected state simultaneously. It is best to avoid general terminology such as "Add All." Be specific.

On both cognitive and time-and-motion grounds the radio button method is generally superior.

WIDGET OF THE WEEK NO. 2

SEEKING AN ITEM ON A LIST WITH A TEXT-BASED FIND

The traditional method of doing a FIND is to either have or to make available a text field in a dialog box. After the search string is typed in, the user taps RETURN or clicks on a SEARCH button. This button has many names, but for this particular analysis the particular name--an important human factors consideration--is unimportant.

When the item is found it is displayed, moved into a particular location, selected, or otherwise indicated to the user. If it is not found a message appears, often accompanied by a beep, blurp, squeak, or gurgle to alert you to the failure.

The traditional method is rather punishing to the user, though most computer aficionados have become so accustomed to it that they no longer feel the pain. For example, you can type in a search string, make a typo (unnoticed until too late, of course), hit return by habit, and sit there waiting for a search that you know will fail or find the wrong thing. Most searches are not interruptable, a serious design error.

When creating the search string you often do not know just how much you will have to type in to get a match, and so you type in more of a search string than is really necessary. Searching in text, and in some other cases, a mistake can put you somewhere unexpected, and you then have to navigate back to where you were. Lastly, when you do not get a match you are informed of this by a dialog box (often obscuring whatever is of interest) which you now have to get rid of (by pressing ESC, ALT-4, clicking on a close box, or etc.) before you can get back to work.

The incremental search method is usually better, since it can solve all these problems at once. It's speed relies on the fact that computers are much faster than fingers. This description is both of an incremental searches behavior and some tricks that I've used to implement them; a purely alphabetic search is described, but the methods apply more widely.

When you type the first character of the search string, the computer instantly proceeds to find the first instance of that character in the text, which is highlighted and (if necessary) moved into the display window. If the search is through a list, the first item which begins with that character is brought into the list window. This is usually a fast process since there are a lot of potential matches and one is likely to be close in text. In an alphabetized list, a set of 26 pointers can make the search almost instantaneous. While waiting for the user to type the next character, a search can be started for the first letter followed by each of the next 26 possibilities, working in decreasing frequency-of-use order to maximize the probability of an early hit. The program can save pointers to each as they are found. When the second character is typed the computer will often be ready to display the found target seemingly instantly.

The search proceeds similarly. String searches can also be speeded by methods such as the Boyer-Moore algorithm where search time decreases as search string length increases.

If the user detects an error in his or her typing of the search string, backspace (or delete) is used as in standard typing to erase the last character, at which point the computer returns to the display shown before the incorrect character was typed. Again, keeping a pointer (one for each character in the search string) can make this process blindingly fast.

No delimiter is needed at the end of a search string, as the instance has been found or the user has already learned that there is no instance to be found. A minimum number of letters have to be typed by users as they can see when their objective has been reached. Merely moving the cursor back into the text or the list suffices to indicate that the search is over. When no instance was found, the display should be returned to the state it was in (including cursor position) before the search was started. No error message is necessary, though a beep can still be useful.

This is not a theoretical construct. Borland's IDE uses this interface idea as does Global Village's fax program. The full implementation was used on Canon's CAT workprocessor, and proved very successful there as well.

A side advantage is that searches that include special characters such as RETURN or TAB can be accomplished without special tricks as these characters are not needed as delimiters in the search string.

By far the most elegant way of doing a string search is to use a pseudomode for entering the search string, but this is a different topic.

WIDGET OF THE WEEK NO. 3

LISTEN TO THE AVID (OR LIVID) CUSTOMER

When I was working on a project for a major, multi-national company, I got to see a letter that management had sought to hide. The writer, an experienced user of the company's software, pointed out many obvious interface failures. Or at least they should have been obvious if the personnel at the company had not been so familiar with the product. A beginner would have found far more to complain about than this experienced user did. All of the writer's suggestions would have been improvements and some reveal problems so evident that it boggles the imagination to try to figure out why the programmers did what they did. I helped convince management that the letter would be more a spur to improvement than an embarrassment, and it was distributed along with my commentary.

As usual, the names of specific products and other hints that might reveal the names of the guilty or innocent parties have been changed or omitted.

Here are quotes from the user's letter and my comments.

• "The software was represented to me as a more mature product." Another clear case where schedule was put ahead of quality in the priorities. What had been described to him was the dream of the original project leaders. What was delivered was a schedule-driven "minimal usable subset" built with whatever tools the company found convenient.
• "The user is required to press enter or click the mouse button many more times than is necessary to enter information." There are lots of old interface design habits that are hard to shake. For example, when entering material into a field it is NOT necessary to have the user type RETURN or ENTER or do anything else at all. When she moves to the next field or screen, or uses a menu or a button, the system should just accept the input as it stands. It can be that simple.
• Using TAB instead of arrow keys to move between fields also proved to be a mistake, even though it is a common technique. Two of the fields on one form had free-form text input. In them, a user could TAB to indent paragraphs or make indented lists. Therefore TAB would not get the user to the next field. It was almost painful to watch a user repeatedly strike TAB to try to get to the next field from one of these.
• These examples represent two common interface problems that should be avoided. The first is the use of RETURN to delimit a field, a custom that dates back to and was caused by the limitations of the teletype machine as used in timesharing and minicomputer applications 30 years ago(!). The second is the overloading of RETURN and TAB, using them to mean one thing in free-form text fields and another in shorter fields.
• "When a search option is selected, the cursor should appear in the appropriate text box so the user can start entering information without having to click the box with the mouse or press the TAB button several times." This is a specific case of a general principle: if the user can do only one thing next, do it for her.
• "Useless Dialog Boxes are probably the major cause for wasted user input and frustration." The writer didn't mention how true this is of much of today's software, not just the product he was writing about. The dialog boxes he showed were the kind that inform the user that something has happened and require a mouse click or an ENTER to get rid of them. There is no choice, you must click the box to go on. This is another specific case of the general principle just mentioned: if the user can do only one thing next, do it for him. As the writer said elsewhere in his letter, "It is important that every time a user must interact with a dialog box that there is a productive outcome to the interaction." This can be generalized to: Every time a user must interact with a computer there must be a productive outcome to the interaction.
• He went on to complain that another dialog box merely "tells the user that the item is already listed" when the name or number of an existing item was entered on the screen that allowed you to enter a new item. You had to dismiss the dialog box before you could go on. He suggested instead that three buttons should appear, allowing you to leave the item as is, to delete the listed item, or to bring you to a screen where you could edit it. His design is better than what was provided, but he's still in button-land. Part of this problem is the dreadful idea that entering a new item is different than editing or deleting it, something we abandoned years ago in the design of text editors. Here is a better way: the user summons the form and puts in the item descriptor; if it is new, nothing happens and the user continues as she expected. If it is an item already on the list then that item's data is brought up so that the user can instantly see that it already exists. She can then edit it directly. Deletion, of course, is just one of the ways you can edit.
• The writer pointed out that a screen soon fills up with identical icons differentiated only by the names that appear underneath. He suggests that a greater variety of icons be used because the "environment is a visual one." He's right in that a screen full of identical icons is just a waste of space. He goes on to suggest that four different icons be used. But there will still be lots of identical icons lying around. He doesn't take the next step and realize that the icons are totally unnecessary. In making graphics-based interfaces we must remember that text is also a visual cue, it is a very powerful one that is full of specific content, and one that we all know very well. Text is often the best visual cue possible; we are expert at visually differentiating one word from another (especially if they are not printed in all upper case letters) and can convey quite specific content.
• "If you have a purchase order open and you want to do an item inquiry you receive the following dialog box:" The box says: "This application may not be used when "Create / Update P.O." is running." The correct user reaction is "Why not?" It is clear that the designers were not aware of the real work flow of the user's task.
• The general principle here is that almost any overly-structured work flow approach to system design risks impeding a user whose task or inspiration demands a different approach. In this case the interface moves from aiding the user to being a dictator. A computer should be a servant, not a peer or boss.
• The customer observes, correctly, that "There is a tendency in the computer industry to conform whether or not it has a productive outcome..." This is true in general. "Conforming and having a standard design are very important... since it takes the user less time to get up to speed..., but if by conforming or standardizing you are creating uselessness then you have failed in your design." This is exactly one of the points made a few years back by Grudin's well known article (Grudin, J. "The Case Against User Interface Consistency" Communications of the ACM, 1989 pg. 1164-1173). Obviously, Grudin's analysis has not permeated into the industry. Abandon a standard when it is demonstrably harmful to productivity or user satisfaction.
• He got more specific: "When the software was designed it used the standard Windows menuing style...." his example showed that "All the menus have uselessness built into them. One menu has the Exit command hidden below the File menu." He was trying to point out that Exit was the only item in that menu. "Exit should sit on the main menu line and the choice File should be removed." As he says, "one item does not make a list" and it is wasteful to have to open a menu when there is no further choice.
• The writer often made specific suggestions to improve a detail when there was a deeper design flaw that needed correction. For example in making up a purchase order the user is first given a screen --called "Purchase Order Direct Entry (Add)"--for a particular product. She must then choose a quantity. The default quantity is zero, and the writer points out "The default value should be one. I really doubt that anyone will order a quantity of zero." He's right. But the whole screen is a mistake. The user should be presented with a list of items which he can scroll through or access by a mechanism such as a Find that does matching (approximate matching and a modeless search would be nice, but any Find would be better than a purely manual lookup). Then she would just change the quantity in the list. In this case zero would be an appropriate default. In some applications the list should retain a particular user-chosen quantity--e.g. the last quantity ordered--as the starting point; depending on the demands of the task, it might be useful to have a "Set all quantities to zero" button. Undoable, of course.
• The title of the screen demonstrates another error; there is a " "Purchase Order Direct Entry (Remove)" screen in the system. Clearly, only one is needed. Setting the quantity to zero should remove the item from the P.O. Of course, the list method makes this clear.
• The screens have another wasteful convention. There are two buttons Save and Exit at the bottom. Most users are not sure what they do. Does Save both save and exit, (in which case it should be labeled "Save and Exit") or do you have to hit them both in sequence to get out of the screen with the entry saved? If you exit without saving, do you get a warning? "Do you want to save your changes before exiting?". In any case, both buttons are unnecessary. Once you move the cursor outside the box and start to do anything else, the system should allow you to do it; saving should be automatic and the default to any operation. Undo, a positive action, is how you should take back an operation and restore things to their former state.
• And, as has been indicated, the whole item-by-item method forces the user to work at a snail's pace. In this regard, the usually perceptive writer was already too accustomed to existing systems.
• Perhaps the most important thing to learn from this letter is when a customer takes the time to carefully analyze and make constructive suggestions about your product, PAY ATTENTION! This person is not an enemy attacking you, he or she is showing loyalty to and interest in your product.
• I found out, to my disgust, that nobody at the company had ever replied to the customer's letter; I got permission to write a reply thanking the writer for his helpful observations and congratulating him on his insight. The company did improve the product, and I brought that customer in as part of the usability tests: he was delighted. Unfortunately, the improved product was never released (I could write a whole essay on the politics of how this pessimal result came about) and now, a few years later, the customer uses a competitor's software that is nearly, but not quite, as bad as my client's persistent product.

WIDGET OF THE WEEK NO. 4

THE INTERFACE AS A POINT OF PRODUCT DIFFERENTIATION

Most of my clients are companies that seek to differentiate their products from competitive products in many ways, such as by supplying superior methods and a broad spectrum of applicability in the target enterprises. Another key area of differentiation is in the look and feel of the interface; it is the interface--not the underlying hardware and software--that every user sees and touches every day. In this sense, the interface is the product.

A product cannot have a superior interface unless it differs in at least some regards from current practice. We must walk a fine line between making a product so novel that users experienced with conventional interfaces will feel lost and making it so much like standard GUIs that we are failing to aid users to the best of our ability. On one extreme we must avoid novelty for its own sake, while on the other extreme we must not lose a valuable marketing opportunity by slavishly making our product too much like other products.

Most products follow the Windows interface guidelines at least in broad outline if not in toadying detail. Therefore it might be useful to comment on a few of the places where thoughts on product differentiation might profitably begin (page references below refer specifically to The Windows Interface Guidelines for Software Design, Microsoft Press, 1995).

"Users, because of their widely varying skills and preferences, must be able to personalize aspects of the interface... such as color, fonts, or other options." (pg. 4)

This is a particularly interesting guideline. A user might want larger fonts to make up for a lack of visual acuity or a need to work at a greater distance than usual from a screen. And it may not be possible to provide a physically larger monitor.However, the use of the larger font may prevent the display from appearing as was intended, or even put some parts off-screen. Similarly, changing colors may make a screen less readable.

Allowing personalization often has the effect of delegating the responsibility of completing this interface design. We do not ask the qualifications of the user before setting this job upon them. Furthermore, we have burdened them with a task extraneous to their job function. Say a user wants to do some planning with a spreadsheet; not only do they have to learn the spreadsheet but also how to customize it. Aside from the user's probable lack of competence to do this, we have also--by allowing rampant customization--forced the documentation and software become bloated with system trivia. There is no doubt that time spent in learning and operating the personalization features is time mostly wasted from the task at hand. Most users, if given a reasonable interface, just want to get their jobs done and won't worry about whether the numbers in the spreadsheet default to Times, Garamond, or Bodoni Semi-Bold Extended Italic.

Personalizing an interface in a shared environment is an invitation to disaster as it means that the interface can change without notice. The right action yesterday, say hitting the red button, is hitting the blue button today, because someone thought it looked better in blue. One's training and habits are undermined

Customization sounds nice, democratic, open-ended, full of freedom and joy for the user, but I am unaware of any studies that show that it increases productivity or even objective measures of usability, learnability, or user satisfaction (I did say "objective"). I'm sure it makes a system less learnable. I suspect that if one were to take a user survey, more people than not would be in favor of lots of personalizable features. But then, when graphic user interfaces were first coming in, a majority of users said that they'd never want to use one...

My take-away on this issue is that if we are competent user interface designers so that our interface is already nearly optimal, most personalizations can only make the interface worse. Therefore, we must be sparing and deliberate in offering user customizations. If a user can, by a few judicious choices, really improve the interface, we probably have done a poor job.

If a program is as dismal as, say, Microsoft Word, the situation is reversed. Almost any change the user makes is an improvment. However, Word's interface is not the kind of goal we should be striving toward.

The Microsoft guildines correctly suggest that a system be forgiving. The best way to do this is to eliminate opportunities for mistakes. The second best strategy is to offer unlimited UNDOs; they make only a vague recommendation that you should allow recovery.

Microsoft begins their section on "Forgiveness" by saying, "Users like to explore an interface and often learn by trial and error. An effective interface allows for interactive discovery." (pg. 6) This is definitely bad advice in a production environment and is probably bad advice in general, and I cannot be forgiving in this regard. Users (except for kids and hackers) mostly hate to blunder around until they discover how to make something work-if they ever figure it out. Trial and error wastes your time, leaves you feeling lost and frustrated, and can result in your operating a system inefficiently in the case where you never discover the intended way to do an operation. An effective interface makes it clear how to do what you want to do the first time you try to do it.

One of the oldest canards in the interface business is the one that says "Maximizing functionality and maintaining simplicity work against each other in the interface." (pg. 8). What is true is that adding features ad hoc works against simplicity. But that's just bad design. It is often (though not always) possible to increase functionality and at the same time make a system easier to learn and use, especially if the added functionality unifies what had previously been disparate features.

Microsoft sayeth: "One way to support simplicity is to reduce the presentation of information to the minimum required to communicate adequately." (pg. 8) That's fine (except that I'd replace "adequately" with "well"), but they then say, "For example, avoid wordy descriptions for command names or messages." What is the minimum required to communicate well? Most of today's interfaces err by emphasizing brevity at the expense of clarity. Why should we have to decipher a cryptic item marked "List" in a word processor's pull-down menu when it could say "Make Index or Table of Contents" (remember that a pull-down menu takes up no room from your document since it goes away as soon as you move the cursor away from it or choose an option). Do not confuse a clean, open look to the screen with a simple-to-use interface as Microsoft does.

The best way to differentiate your product's interface is to make it work. As Mark Twain said, "Always do right. This will gratify some people, and astonish the rest."

WIDGET OF THE WEEK NO. 5

WHY CAN'T MY COMPUTER DO ARITHMETIC?

One of the more interesting artifacts in my collection is a four-function calculator given to me (among many others) as an award for a few years of employment at Apple. "Why a calculator," I asked. "To use beside your computer," was the answer.

It's true. I do keep a calculator beside my computer. Why do I need this simple-minded device when I have a computer in front of me? Because you have to go through contortions worthy of a circus sideshow in order to do simple arithmetic with it. There I am, tapping away at my word processor, when I want to do a division: 375 packages of Phumuxx cost $248.93; this I know. But I need the price for one package. On my computer I have to open up a calculator window. To do this I take my hand from the keyboard and move it to the mouse, which I use to do a click-and-drag to open the calculator. Transferring my hands back to the keyboard, I type in the numbers I need or tediously cut-and-paste them from my document. Then I have to press a few more keys and finally copy the results from the calculator window into my document. Sometimes the calculator window opens right on top of the very numbers I need, just to add insult to injury. In that case, I must use the mouse to move the calculator window out of the way before proceeding. It is much faster to grab the calculator.

No calculator function on your computer (or you don't know how to summon it) and no calculator at your side? Do it by the productivity-draining, error-prone pencil-and-paper method. I've done this too many times.

All that is really needed on computers is a "Calculate" button or omnipresent menu command that allows you to take an arithmetic expression, like 248.93 / 375, select it, and do the calculation whether in the word processor, communications package, drawing or presentation application or just at the desktop level. In other words, it is an example of a universal function that can be used anywhere. Here's another facility that should be generally available: anywhere a number can be entered, you should be able to enter an arithmetic expressionthat evaluates to the number. A few programs allow this, all should. What could be more stupid than a person with an amazing multi-megabyte, multi-megahertz, multiprocessing marvel at their fingertips having to reach for a scrap of paper and pencil to divide 69,576 by 12 because the computer is stuck in an input field that only accepts orders in terms of dozens and the user only has the number in units?

I know that this kind of thinking does not lend it self to spiffy graphical gadgets on the display, but we do need more commands, such as

check the spelling of the current selection

treat the current selection as an arithmetic expression and evaluate it

transmit the current selection as an email

transmit the current selection as a fax

that can be used at any time, from any program. In fact, part of the problem is application programs per se, but that's another story.

WIDGET OF THE WEEK NO. 6

FEAR OF THE GRAY SHADOW

We seem to have a real fear of displaying data in our interfaces. We know that people quickly can find one among a few items much faster than they can find one among dozens: there is less to look through. But it does not follow, as some seem to think, that it is therefore better to have fewer items on each screen. In the case where you have hundreds of items and split them up among dozens of screens you lose more in navigation time than you gain in searching for the individual datum-even if the item you seek is swimming in a sea of similar-looking items. Looking for something in long, gray lists is not always a terrible thing in an interface.

If people weren't good at finding tiny things in long lists, the Wall Street Journal would have gone out of business years ago. Would you rather have the stocks listed fifteen to a page, each page decorated like a modern GUI screen, even given some scheme for helping you to find the right page? A table of contents, for example:

STOCKS PAGE

AA - AD 1

AD - AS 2

AT - AZ 3

BA - BK 4 ..... etc. etc.

It would be considered childish, wasteful, and a nuisance. To say nothing of stupid. We sometimes spend more pixels on a typical screen in making neat, gray-shadowed borders than we do in presenting information. When a person is motivated-by interest or salary-to refer to data they find long lists no problem at all.

What a serious, professional user wants is screens packed with useful stuff. Screens should be well-labeled, with navigation schemes and methods to make finding things easier (after all, we do have a computer sitting there and we should be making the best use of it we can) but dense with the information that represents the real value in each screen. Incremental search tools help, of course.

Following the usual philosophy of screen design to its logical conclusion we could argue that there should only be one item of data on any screen, thus the user will always be able to detect it visually with no effort at all.

There is often a trade-off between screen complexity and navigational complexity. But I suspect we are nowhere near the optimum in this regard, and have erred on the side of too little data per screen.

WIDGET OF THE WEEK NO. 7

IF YOUR ONLY TOOL IS A HAMMER...

Interface ideas that are generally agreed upon as good and desirable, and which are well within the capabilities of the computers we use, are nonetheless not being implemented. There is no lack of desire or skill on the part of our programmers, but we cannot implement them because the tools we have provided-tools whose designers never thought of the facilities we need, tools designed to the least common denominator of today's interface culture.

We use these tools because they allow us to quickly mock up interfaces, in the hopes of speeding development. We sometimes claim that we will re-implement the interface correctly at some future date, using a general-purpose programming language, but by that time we have run out the schedule and have already invested a lot of work in perfecting and testing the "mocked-up" design. Going to the "real" interface at this point would require not only recoding, but redesign, retest, and redocumentation. Meanwhile, we have gotten used to our supposedly temporary ideas.

Mocking up makes a mockery of interface quality. We are condemned to live with our second-best ideas. However strenuously our designs struggle, they cannot rise far above the mediocrity of the blunt instruments we have chosen to use.

HABITUATION

The best interface is not theatrical, artistic, convenient, intuitive, or even helpful. The best interface is invisible. It is a property of the human mind-one confirmed by many experiments-that we have but one locus of attention. When we seem to be doing more than one task a time either we are, instead, rapidly switching back and forth between them (which is really doing one thing at a time), or we are doing all but one of them unconsciously, that is, we can do all but one automatically (also called habitually). This is why you can drive to work while listening to the radio, and why you sometimes drive to work (or at least take a turn in that direction) when you intended to go somewhere else on Saturday.

The secret of great interface design is to make the interface of such a nature that its use can become an unconscious act. To do this requires two properties. The first is that you not require the user to be aware of system state in order to know the consequences of their actions. This is because if your single locus of attention is on your task, it is not on system state and you will make errors. For example, typing in all caps because the caps-lock key was down (yes, the useless little green light on the caps-lock key was on, but you didn't see it because it was not at your locus of attention).

The second property is that you not have to make logical decisions about what to do next. Any time you employ logical thinking, those logical processes must be at your locus of attention; apparently, people cannot do logic unconsciously. So plotting a path or method of using the interface necessarily takes your attention from your work. Contrary to most interface design guidelines, this implies that there should be exactly one way to accomplish any task, rather than many. Of course, that one method must be a good one.

There is much more to be said on this subject, which is at one of the foundations of interface design, but it would take a book-length effort to explain it in detail.

WIDGET OF THE WEEK NO. 8

MORE SO IN EVERY WHICH WAY

You have to only read the comics, speak to any human not affiliated with the computer industry, or even (shudder) use a computer yourself to know that our silicon slaves have gotten more so in every which way except easier. More memory, more pixels, more mass storage, more instructions per second, more applications, and ever so much more to learn and remember. One Sunday, I counted and found that computers were the butt of one out of four of the comic strips; everybody from Doonesbury to Dennis the Menace (to say nothing of Dilbert) had something to say. And none was particularly complimentary. Is something wrong with this picture?

Ever notice the prevalence of the crime of covert Macintosh usage? I know it's a crime because people come up to me, look around to make sure we are unobserved, and only then dare whisper "I just got a Mac for my kids" or for his or her spouse, parent, or other loved one. Many will tell me that they use a Mac themselves, in the privacy of their home. Their companies, needless to say, put out IBM-compatible products exclusively. I'm not trying to push Macs, but it's clear that we think of our customers as somehow less human than our family and friends. Besides, "Nobody ever lost their job by recommending IBM-compatibles" to update an old saying. Not that Macs would make our customers happy; users don't care if the computer has Intel inside or a bunch of pigeons tapping at buttons, so long as it gets the job done and bird feed stays cheap.

Come to think of it, Macs aren't all that easy to use these days. The Mac OS is a multi-megabyte monster, not quite in the Windows 95 class as far as swamping the user in an avalanche of irrelevant detail and arcane techniques, but too close for comfort. And it's mostly gotten worse over the years.

A lot of interface design suffers from concentrating on what a physicist might call "second order effects". Second order effects are small enough that you can ignore them and still get the answer right (or at least close enough for any practical purpose). On the other hand, you can spend a lifetime working out second and higher order effects without making any significant contribution to the problem.

An example of the problems of working on higher order effects is spending hours deciding on the optimal font for a useless feature. I picture a knight stopping to inspect his coiffure in the middle of a fight with a fire-breathing dragon. Instant Sir Flambé.

It's easy to get carried away with second order details. They are small, easily handled, simply explained, and readily standardized. In short, bureaucratically tractable. They seldom make a great deal of difference in terms of productivity, although for the most part we haven't a clue to their quantitative contribution. We do know that enough bad details can sink an otherwise good product, though getting all the details right cannot save a bad one. I must admit that we don't have numbers on what attending to first-order details will buy us, either. But the effect (as when the industry went from DOS to GUIs) can be dramatic, leading to great gains in making software approachable and useful.

WIDGET OF THE WEEK NO. 9

GIVE ME A GOOD SHOVEL

While climbing the ever-higher crests of the East Esoterica interface mountains, using two-fisted mice, total immersion virtual reality rooms, eye-ear-and-nose-position detectors with proportional force tactile feedback, and other widgets heretofore unknown, users of everyday systems gets nowhere near these peak performance aids because the earth-bound users are always stubbing their toes on the rubble-strewn ramparts to the lowest base station. Isn't it time for us to turn the bulk of our attention to paving the everyday streets and alleys?

First, a few frustrations by way of illustration of the above paragraph. I ended up (in writing my draft of this Widget) using a different font than the one I used on the last Widget. I was visiting a friend and using his computer, and for some reason it didn't recognize the font (it was the same make of computer and had the font, or at least one of the same name, in its Font menu). There's probably a trick I'm missing, and I'm sure somebody knows exactly what is wrong. I invented this make of computer and I haven't a clue. Don't write with the solution, I don't want to hear about it.

I woke up the other morning with a great idea for this Widget, but by the time I had opened the Widgets file to write it down, I had forgotten the inspiration. And the machine was already booted. I never imagined that the idea would evaporate as I battled with the file system. Not that the file system is hard to use (I've been using it for years) but it requires just enough attention to sometimes distract me from what I should be thinking about.

I don't know what percentage of our time on any computer-based project is spent getting the equipment to work right, but if I had a gardener (I don't) who spent as much of the time fixing her shovel as we spend fixing our computers, I'd buy her a good shovel.

You can buy a good shovel, but you can't buy a good computer system, that is, one that you can just pick up and use. Does that give anybody any thoughts for a profitable business? The idea is radical: usable computers.

INCIDENT AT HIGH NOUN

To change the subject, here's a brief consultant's case study. In this example, what seemed to be a naturally verb-noun situation was changed so as to make it noun-verb and eliminate the errors the verb-noun design caused. It occurred in designing a requisitioning screen. What was needed was a way to let users tell the system for what department of the company they were placing an order. The initial idea was to put a list of locations at the top of the screen: the user would begin the process by doing a point-and-click at one of them. To save time, the department where the computer was located would be the default. If no department was specified, the stuff ordered would be sent to the default location.

Summary: set the department, choose the items. Simple, standard interface design.

This design, I predicted, would lead to errors. Due to habit formation, users would soon fail to click on the department choice at all and would sometimes forget to select a department when ordering from other than their usual computer. You could have no default and force the user to select a department first, every time. Now the only possible error would be to choose the wrong department. This solution is annoying to users because they are usually thinking about the items, not the location when they came to this screen.This design is distracting since you have to set a mode before you can place the order.

The group leader I reported to sheepishly told me that they had gone ahead and already implemented this design (they were sure that they didn't need an interface designer for so simple a screen) and that the problem I thought I was predicting had already evidenced itself.

I suggested that it would be better to simply put the location selector at the bottom of the display. Relabel the list: "To which department do you want the requisitioned items delivered?" You might make the first item "My Department" if the system knows this (from the user's log-on). Do not remove the user's department from the listNow choosing a location is an act of closure, the requisition form has been filled in, the user's attention is no longer on the desired items but on having them delivered. We have achieved "noun-verb" design (what do we want to send and where do we want to send it to). We do not need a default since the user gets psychological satisfaction by indicating that they are done with choosing stuff and want it sent. Sure, users will still form a habit of choosing their usual location from the menu and will sometimes forget that they really wanted the order sent somewhere else. But that is the kind of mistake it's hard to guard against with a computer (Two ways of checking that might be helpful: give a warning if the user almost always orders for a certain department and is now ordering for another; the system could perhaps guess from the items ordered where they were intended to go; sending muffler parts to the bookkeeper is probably wrong).

But the main burden of this Widget is that there was a noun-verb solution, and that it was no harder to implement. I have yet to find a situation where a verb-noun to noun-verb transformation--along with an improvement in usability--was not possible.

WIDGET OF THE WEEK NO. 10

A VOICE IN THE WILDERNESS

I was sent a draft of an article by Stever Robbins on the net. I do not know Robbins except by this essay. It is not unlike my article "Down with GUIs" that appeared in WIRED in 1993 (which is also available on the Internet) but makes its points differently and well. Robbins' statement that "Today's GUIs demand conscious attention to do anything, even for routine tasks you do a thousand times a day" is especially in line with my own work on what's wrong with the design of so many interfaces.

Robbins points out the unnecessary complexity of today's systems with a number of choice examples and explains why tablets and touchscreens are better than mice and trackballs (I have never liked the mouse and don't use one).

Perhaps the most important point is that most of what we do with computers are basically text-based applications. They involve tons of text and tables. The only real need for graphics is in graphs and perhaps product drawings, all the rest of the business with tabs, navigational maps, and colors is window dressing. It wastes user attention, screen space, and makes it harder to print screens on black-and-white printers.

In some cases his ideas can be improved upon and in a very few cases his claims are contradicted by experiment. But he has not spent years studying interfaces, yet sees the flaws that many professional interface designers miss. Of course, the poor man is suffering from Windows, but the Mac is only slightly less obnoxious these days. Here are the words of a very perceptive observer:

------------------------------------------------------------------------

It sounded great: graphical user interfaces (GUIs) would free us from the textual limits of the machine. They would give us whole new metaphors for human/computer interaction, making everything a snap to use.

So why do I like my GUI interface less and less as time goes by? Why is it a continual struggle to get anything done? Some programs are certainly easier to learn, now. But on a daily basis, most of them slow me down, rather than speeding me up.

GUI interfaces are becoming VERY, VERY "cognitively intensive." It takes a lot of brainpower to do anything with them. With text interfaces, you could think about your problem and even hunt-and-peck typists could often put their fingers on automatic to do the actual computer interaction.

Today's GUIs demand conscious attention to do anything, even for routine tasks you do a thousand times a day. Two subtle design decisions drive this: everything is presented as a set of choices, and everything from the selection mechanism (the mouse) to the data-interaction metaphors are relative choices. Combine that with the fact that most GUIs are just text interfaces in disguise, and you have an easy-to-learn, but cumbersome-to-use relationship with your screen. Everything is Choices

More and more, things pop up lists. They display a dozen checkboxes, and let you choose among them. They give you folder tabs inside dialogs, so you can select the one you want. Or they let you choose from several elements in a list box. Most of my time in Windows is spent searching:

Hmm... Is "Show Margins in Color" a customization, a user setup option, or a view preference? I must consult HELP to find out it's listed in "View Preferences."

Which menu is "View Preferences" under? ("User Setup," "Options," and "Customize" are on three other menus.)

I've found the listbox of colors! Now I have to spend five minutes scrolling through the drop-down list to find the color I want. But it only shows three items at a time [despite my having a 1024x1280 monitor], so I have to position the mouse carefully on the scroll arrows, and inch my way through the list. Or I drag it along the items themselves, and they scroll off the top and bottom. But they scroll too fast, so I have to keep backing up to make the choice.

In one program, setting a program option requires selecting a menu item from a submenu. That pops up a "tabbed dialog." You then select the tab you wanted. That tabbed page contains a list box, which you click on. Finally, you are presented with the option you want.

Checkboxes, radio buttons, tabbed dialogs, and list boxes present every possible choice that's available. Then you select from the choices. For learning a program, this is great! At any moment, you know all the possible choices.

But, once you know what you want, this scheme sucks. When using your FAX modem, you just don't care about all the possible printers on your system. You know you want to send a FAX. But the printer list box shows you all possible printers. It forces you to view, consider, and abandon the choices you don't want. Ditto for check boxes or radio buttons, which present you with choices you have to filter out, even if you knew exactly what you wanted to do.

Once or twice, this is fine. But when 90% of a user interface requires me to go through a selection selection to get anything done, it lessens the overall attention I can give to my problem.

Even selecting a menu item requires searching. You must look at the menu and position the mouse correctly. Both your vision and body must be engaged in a feedback loop to make any menu choice, however simple.

A few sort-of solutions are in sight. Some programs now offer context-specific pop-up menus when you click the right mouse button. This is a start, but the whole menu metaphor still requires searching through the menu items (and praying they included what you want in the popup menu).

"But Wait!" you cry, "What about keyboard accelerators? They don't require locating the mouse on the screen." It's true. They help for some common tasks. (I know, for example, that Alt-T, O, Alt-P, Alt-R, [space], [enter] will do a common task in my favorite graphics program.) But they aren't so good for other tasks. Many vendors are sloppy about providing accelerators. Keyboard accelerators may change depending on what is or isn't selected. And if you press Command-Space by mistake, you must stop, look at the screen to figure out what's going on, and press Command to get back to a place where the accelerator is recognized. And as my graphics program amply demonstrates, it often takes a ridiculous set of accelerators to reach the choice you want.

Of course, those problems all assume that you actually know which accelerator you need. Often, you must examine a dialog box/menu item to discover which accelerators are active in a given context. Accelerators are very useful for not having to switch between keyboard and mouse. They fall far short, however, of minimizing the attention we must pay to an interface. Everything's Relative

Einstein was right: everything is becoming more relative. And the mouse is leading the way as the worst offender. Where it goes when you move it depends on where it starts. Using a mouse takes a lot of attention:

Search for the mouse. (Oh, yes, right underneath this month's copy of GUI Magazine. What's this goop on the keys? Is that peanut butter?)

Locate the pointer on the screen. (Jiggle the mouse and watch for the pointer. Yuck. It was peanut butter.)

Now move the pointer. You have to watch while doing it, to make sure you get the positioning correct. Depending on where you started, you may move an inch or several inches, to get to the same place. (Thanks to this peanut butter, the mouse is sticking just a little bit, and I can't quite get it on that little scroll bar button. ... wait, ... nudge ... there is it!)

An absolute pointing device, like a touch screen or tablet, lets you notice what you wanted to choose and just move your finger there. If your screen is always in the same place on your desk, common tasks can become automatic: you just play it like a keyboard. There's no extra attention required. (Alas, I don't own a tablet.)

The "relative vs. absolute" issue touches other interface issues. Many programs present options as being relative to the current state of the thing we're working on. For example, the BOLD button in Microsoft word makes the current text bold. Unless it's already bold, in which case it unbolds it. It makes a great little visual metaphor--you can look to see if the [BOLD] button is up or down. Then click it to change it.

The problem is that you have to look to find out if the button is currently up or down. There is nothing you can do to be sure that text is unbolded, other than bringing your attention to the screen. Toolbar buttons and checkboxes are both relative metaphors, which force your attention back to the interface. Keyboard accelerators don't help, because they still require you to consider what's there now, so you can tell whether or not the accelerator will help.

Most of the time, I know exactly what I want. "I want this text in bold, Times Roman 15." Unfortunately, GUIs as they exist today make me turn a simple desire into a complicated set of choices and decisions. Most GUIs are Really Just Text Interfaces

GUI interfaces give you so much more expressive power. Alas, most developers totally ignore it. They're so into building interfaces with the existing set of widgets (tool bars, drop down boxes, etc.) that they give very little thought to using the visual interaction to enhance how people naturally use the program to get things done.

Menus? They're just command lines, where you choose a word at a time. Dialog boxes? They are not graphical interfaces. They are text interfaces much of the text is already typed for you. Drop down list boxes, checkboxes, option buttons, folder tabs, and menu items are all just text. True graphical interaction is almost nonexistent in most applications. It is limited to elevator dragging on a scroll bar, and maybe drop and drag moving of text.

The lurking possibilities are truly fantastic, however. For example, imagine you're typing into a word processor. When you want to make a word bold-italic, you are almost certainly looking at the word. In today's world, a right click gives you a menu, from which you then search for and select the word "Bold". If you paid close attention to whether the text was already bold or not, you have a good chance of e nding up with the result you want. Then you get to repeat it for "Italic."

But why require all the trouble? What if you could click to select the word. If you then press and hold the mouse button for a second, up pops a gallery of all the possible ways the text can look (bold, italic, underlined, and all combinations thereof), plus some sort of font size slider, etc. You then just click on the look you want. It still requires a choice, but at least you can choose the final look in one easy step.

This scheme eliminates movement to toolbars and menus, and is an absolute selection mechanism. It doesn't matter if the text is already bold. You just look for the appearance you want and select it.

Consider how we use tabs in a document. When you need to change tabs, it's almost always because you want to line a bunch of stuff up. In every word processor out there, the ruler is at the top of the screen, and far away from the line being modified. It also gives no feedback about how the line relates to other lines.

How about: when the cursor is in a line containing a tab, a very faint, transparent set of tab marks appear superimposed over the page right above the line. If you move or add a tab mark, a transparent vertical hairline appears so you can see how it's lining up.

Again, this uses the notion that when a person is thinking about tabs, they're looking at the line containing the tab. They want to see how it lines up. So the tab mechanism should be right there, with alignment guides for immediate feedback.

Example #3: When you click on a pop-up listbox, have the (@*#&$ thing look at your screen size and actually pop up something that uses as much screen real estate as it needs. "But what if it obscures something," you ask? Well, in this world of 256 or 16M colors, it could pop up a transparent listbox, with the text in opaque white [or some color that will show up]. It's better than scrolling.

Conclusion

GUIs give incredible potential for enhancing how we interact with computers. Rather than greatly minimizing interface concerns, however, we have developed interaction standards and thinking which actually increases the amount of mental work it takes to use a graphical user interface. Our first decade of GUIs has been a learning experience. Let's start to design interfaces which let people specify exactly what they want to do, rather than having to make a choice every time. Let's provide interaction mechanisms which don't require reevaluating the current state of the interaction in order ot figure out how to get to the next state. And for goodness' sake, let's design our interfaces around what people are thinking and doing when they sit in front of the screen. Let's punt the nicely beveled, but basically text-base interfaces, and bring in some really creative thinking about how we can use the power of visualization in computers.

Copyright © 1997 by Stever Robbins, used with permission.

WIDGET OF THE WEEK NO. 11

PROGRAMMATIC SELF-HATRED

Humanely-designed software has barely penetrated into the programming arena. This has been brought forcefully to my attention in a number of ways. First, programming has been made more complex over the years. I observed that at home, even with unlimited access to his own and the family's modern computers, My son often chooses to program on our very old Apple II. Why?

With the Apple II he turns it on (boot time is undetectable!), presses Control-B (which gets him into BASIC), and if he then types

PRINT 3+4

and presses RETURN he gets

7

instantly and painlessly. From launching BASIC to result: 5 seconds. As the industry is well aware, ease of use requires copious resources of memory and speed. Therefore we know that the Apple II can operate with such dispatch and ease-of-use because it is a powerhouse of brute hardware: it has a gutsy, 2 MHz 6502 8-bit processo, 48K bytes of RAM (all that you could stuff in!), and a 400K byte disk. My son's regular computer runs a 200 Mhz 32-bit processor and has 80 megabytes of RAM (and there's room for more!), and gigabytes of disk storage. To do the same immediate program, from a standing start on his far bigger and incredibly more potent computer, would take over three minutes. Considering bus width and processor speed, the new machine is about 800 times faster than the old. Considering the time it takes to get started on a task, the new machine is about 70 times slower. (On a fairer comparison, the time it takes to get started on a word processor gives the Apple II only a 15X advantage).

Back to BASICs: The problem is this: with one of today's modern, advanced, powerful, improved, superior computers you turn it on, wait two minutes, and are faced with a desktop. If BASIC is not available from a desktop icon or shortcut, you must open the appropriate folders until you find and double-click on the right icon. Then you wait while the program loads. This gives you a screenful of windows, one for writing code, another for text output, yet another for debugging, and so on. It's all the fashion these days, but is it better?

I asked two professional programmers to add 3 + 4 in Visual BASIC. The first began by complaining that the machine was hobbled by having only 8 Mbytes of memory and was powered by an obsolescent 75MHz 80486 (32 bit) processor. Not counting the nearly two-minute boot time, BASIC was up in 54 seconds. Then an Insert Module had to be opened, a Get Options box was opened and manipulated, a button and a form were created and the programmer had to type the middle line of the following:

Private sub Command1_Click ()

MsgBox 3 + 4

End Sub

(Clear, isn't it?) To use this program, it had to be launched and then a button pressed to make it run. Only two or three errors were made during this process. Time: 3:40.

Another programmer, with a 75 MHz 64-bit Pentium processor and 40 Mbytes of RAM, launched BASIC and did the same task in 28 seconds (nearly 5 times slower than the dinky Apple II). The program, created by a slightly different process, was

Private sub Form-Load ()

MsgBox Str (3 + 4)

End Sub

Maybe I'm old-fashioned, but "PRINT 3+4" seems clearer to me. And I can delude myself into thinking that it is simpler as well. I asked the second programmer why he didn't use

MsgBox 3 + 4

He said he wasn't sure it would work. In other words, he wasn't sure how Visual BASIC (VB) worked in this case. There's nothing odd about this, VB is huge, unmemorable in design, and is peculiar nearly everywhere. We are told that it makes big things easier, but that is no reason to make little things harder. Besides, big things are made out of lots of little ones which leads me to question the overall claim. It is only bad language and system design that explains why one experienced programmer made errors and another was not sure of the proper syntax. I got similar times and results with some Smalltalk programmers on whomI tried this exersize.

On the old Apple II, if you wrote a program that drew a line, you'd see the line right there on the very same display on which you were typing. Nowadays you have to create a special window for it. If you didn't like the mixture of text and graphics you could include a CLEAR command to clear the display for your graphics. If you typed in a command, it executed. Something wonderfully straightforward has been lost.

On another tack: we all know how important it is for programmers to put lots of internal documentation in their programs. A good program looks somewhat like this:

Readable explanation with lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext moretext stillmoretext lotsatext lotsatext lotsatext lotsatext

A line or two of clear, structured code

lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext stillmoretext lotsatext lotsatext

Another line or two of good code

lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext clearwritingabouttheprogram lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext lotsatext...

and so on. What we usually get is

Brief and cryptic comment

code

code

more code

obscure code

code

clever but unexplained trick

undocumented use of really obscure side effect

Briefer comment

code

code

strange system call

code...

and so on. It's not their fault, the programming environments have been designed to make comments hard to add. For example comments in many computer languages are limited to one line at a time; there's no word wrap or other features that even the dumbest word processors have to aid the typing process (there are a few exceptions, UCSD Pascal and Oberon to name two). If you want to edit a paragraph-length comment in VB, you have to word-wrap it by hand! Programmers are not hired for their ability to spell, so you'd think a spell-checker would be part of every programming environment. So would I, but we'd be wrong.

I will avoid getting into questions of how a programming language should be designed to take human factors into account. It is relatively well understood that the results of UI study and cognitive psychology can improve computer interfaces but the blend of state-of-the-art language design and what we know of human factors has yet to be exploited to any major degree; language designers and UI experts too seldom work together. This is true even though one of the earliest books in the UI field examined this very question. (Weinberg's The Psychology of Computer Programming was published in 1971, it was very far ahead of its time: We haven't caught up yet.). In asserting that human factors analysis would be useful in computer language design I am assuming, of course, that programmers are human.

As it is, when I have to write a program, I feel that I am doing it in handcuffs and hobbles. As the shoemaker's children are the last to get new shoes, programmers seem to be among the last to benefit from advances in user interface design. What this omission costs us in wasted time and effort could probably be reckoned in the billions of dollars annually.

WIDGET OF THE WEEK NO. 12

SOMETHING TO MULLET OVER

In this note, I follow in the footsteps of Kevin Mullet, the Product Designer for Macromedia. These are excerpts from his notes for a talk titled, "Space Craft: Perceptual Aids for Cognitive Activity". His work illustrates, once again, that the use of tool kits for creating GUIs-an activity that demands great plasticity since it must interact with that most agile of widgets, the human mind-can be counterproductive. It also hints at some useful techniques for applying spatial organization effectively. In conjunction with spatial / landmark navigational methods (such as Pad++) his methods can be of great value, making us regret that we can't implement them with the tools we currently have. But let us take inspiration nonetheless from those portions we can. Kevin wrote:

"The effective use of space and spatial metaphors is a critical success factor in graphical user interface (GUI) design. Sadly, this is also an area that has been largely neglected by tool kit, framework, and application developers. Effective use of space is prohibitively difficult in modern GUIs because the foundation layers of common software platforms provide little or no support for complex, expressive layouts. Even worse, several familiar UI conventions such as the use of "group boxes" linking labels to controls or non-modular button widths that automatically match the length of their labels present severe problems for spatial parsing but have nevertheless become common by virtue of their availability in popular tool kits.

"A coherent visual organization enhances not only the aesthetics of an interface design, but its usability as well. Because spatial information is available at the earliest stages of perceptual processing, displays with spatial structure that is both obvious and relevant can be used to enhance higher-level cognitive functions. Making the important contextualizing or relational information apparent at a glance helps users orient themselves, locate the information they need, and target or navigate efficiently. Spatial relationships, moreover, can make information displays easier to understand by revealing internal relationships more concretely and explicitly: the visual structure of a carefully crafted display will both reflect and reinforce the semantic structure of the underlying information.

"We will see how spatial articulation can be used to simplify learning, enhance memory, and streamline problem solving. Numerous examples will show how coherent visual structure makes a menu easier to scan, a dialog easier to interpret, or a window easier to operate. We will also see how careful space craft can reduce the need for explicit labeling and make the interface more approachable for beginning users without sacrificing operational efficiency for advanced users. Finally, we will describe one very simple technique "alignment of adjacent elements" that can be applied fairly mechanistically to virtually any problem in GUI design. With just a little practice, this technique can be used to produce noticeable improvements in the visual structure and aesthetic quality of practically any product."

He teaches that one should always put the same button in the same absolute screen location if possible, if not at least put it in the same position relative to the window. The Mac and Windows have done this with some screen elements for years. Another trick is to organize screens so that you don't have to jump around in following the workflow. Consecutive tasks should have adjacent widgets to accomplish them.

Notice that Mullet, like your present scribe, stands in contrast to much of the industry by believing that one can design interfaces that are simultaneously good for beginners (easy to learn) and for experts (efficient and productive).

Widget Of The Week No. 13

DOUBLE DYSCLICKSIA

Double clicking as an interface technique suffers from a number of problems. You cannot always predict what objects on the display will or will not respond to it, and it is not clear what you might expect from double clicking. There is no indication on displayable items that double clicking is supposed to have a response, the functionality is (to use Don Norman's fine term) invisible. At very least, double-clickable items should have a special appearance. The way double clicking is used today, you must not only remember which items are double-clickable but you are burdened with remembering how different classes of widgets or individual items respond to this action.

The first two problems could be at last partially alleviated by new screen conventions, but the act of double-clicking itself is problematical. Double clicking requires operating a mouse button twice at the same (or very narrowly close) location, and in most cases, within a certain period of time (typically 500 msec). If you're a little too slow, it doesn't work. If you jiggle the mouse too much between clicks, it doesn't work. If you are trying to select some text within a word in some word processors, and you do it too fast, the clicks at the ends of the selection are taken as a double-click and you get the whole word. It's happened to me.

A far more common problem is trying to select a graphical item that is positionable graphically, if the mouse shifts during the double click-and it is hard to keep it from moving while you are quickly pressing buttons on it-the item ends up shifted as well as activated. If I want to change the text in a textbox I sometimes have to reposition the accidentally-moved box as well as make the edit. This nuisance can also occur with single clicks.

There are some of us unaffected by dysclicksia: These lucky ones never miss with the mouse; single and double click with insouciance and panache; don't suffer from side effects of clicking; and can shoot a flying bird with a .357 revolver while driving at 150 km / hr along a twisty mountain road. But we can't assume all users share these characteristics. We must design for the dysclicksic user, and remain aware of the problems inherent in using double clicks in an interface. We are indebted to this project's Pam Martin for the term "dysclicksia", a disease for which the only permanent cure is good UI design.

WIDGET OF THE WEEK NO. 14

Like everybody else on most projects, my nose has been to the grindstone recently, with serious damage to the grindstone. So I'll just share some random humor that crept into my computer, some from my own daft hand. I have freely modified those from others to my own warped way of thinking.

WHY SOFTWARE IS THE WAY IT IS

What has been described as "creeping elegance" is probably better described as "feature blight", for like a fungus on a plant it gradually elaborates and blurs the true outline of the product while it drains its sap. The antidote to feature blight is, of course, the "constricting deadline". This results in features being discarded in proportion to the time it would take to implement them. It is often the case that the most useful features take the longest to implement. Thus the combination of the blight and the deadline yeilds software as we know and love it, comprised of bountiful quantities of useless features.

COMPUTER SCIENCE SAVES THE DAY

A number of students were set the problem: Prove that all odd integers > 1 are prime. A math student tried it first. He said, "Hmmm... 3 is prime, 5 is prime, 7 is prime. Hence, by induction, we have that all the odd integers greater than 1 are prime."

The physics student thought for a moment and replied, "I'm not sure of the validity of your proof, but I'll test it by experiment." He continued, "3 is prime, 5 is prime, 7 is prime, 9 is ... uh, 9 is an experimental error, 11 is prime, 13 is prime... Well, it seems true."

Next came an engineering student, "I'm not sure of your answer either. Let's see... 3 is prime, 5 is prime, 7 is prime, 9 is ..., 9 is ..., if you approximate, 9 is prime, 11 is prime, 13 is prime... It'll stand up."

Not to be outdone, the computer science student comes along and says "I've just whipped up a program running under Windows 95 to prove it. Watch this" She ran her program. The screen displayed the result:

3 is prime 3 is prime 3 is prime 3 is prime ...

"Foobar!" said the student, "I should have implemented it in C under Unix." This time the screen read,

3 is prime 5 is prime 7 is prime segmentation fault

"Nope," she said, "Let's use SmallTalk."

But by the time the program started producing results, everybody but the programmer had gone home.

"That's OK," she said to herself, "All these objects are reusable."

PLAY IT AGAIN, SAM

I know that that's not a quote from the movie "Casablanca". But anyway: A programmer, an engineer, and a physicist were coming down a steep hill in an old VW Microbus (didn't jokes used to be about a Priest, a Minister, and a Rabbi?). The brakes suddenly failed and they had a harrowing ride to the bottom, but they made it safely. After the old van rolled to a stop, they got out and began to argue about what they should do. The engineer wanted to immediately rebuild the brakes and get underway again.

"No," said the physicist, "I would like to first analyze the mechanisms and understand the cause of the problem." She then asked the programmer's opinion.

He said, "Let's roll it up the hill and see if it happens again."

The sad fact is that on the computer, the brakes might not fail on the way down the next time. I don't know how many times I've tried something, had it fail, then try it identically (as far as I could tell) and have it run. This fosters a superstitious attitude. People debugging programs often run them more than once in the (sometimes successful) hope that it will run right the second time after failing the first. This should worry us more than it does. On the other hand, it is this non-repeatability of computer phenomena that is one of a computing's few charms.

DRIVE TO HEAVEN

OK, here's one with a priest. A cab driver and a priest are standing in line to get into heaven. St. Peter gives the cabbie a silk gown and a huge gold harp. The cabbie goes in the VIP door. The priest, encouraged by this generous treatement of a cabbie, walks proudly to St. Peter, who gives him a shabby cotton smock and a moth-eaten bagpipe.

"But why," asked the priest, "after I have devoted my life to God."

"Simple," said the bearded gatekeeper, "when people came into your church, they slept. But whenever they got into his cab, they prayed."

I guess I could make up a moral about unintended consequences, but I won't.

WIDGET OF THE WEEK NO. 15

ICONS, AGAIN

I've recently run into a study I'd misplaced which reminded me just how badly icons test out.

In a massive study by Easterby and Graydon in 1981, they took 108 international symbols. 32 of these were widely used at the time. One question they asked was: how many of these symbols are understood by 2/3 or more of the subjects? The surprising answer, given that these symbols were chosen by an international committee of experts and some were encountered on a regular basis by nearly everybody: 3.

In my own test of a dozen icons used on Apple products (done when I worked at Apple) I showed that even the designers who had chosen the icons couldn't remember what they all stood for. Only one was correctly identified by nearly everybody. There was also one that was recognized by nobody! I have repeated this test with many subjects with similar results.

There have been a lot of studies of icons that show their failings but we still cling to them. They are so hopeless that Windows has a faciity that automatically shows you a word or two to explain each icon if your cursor lingers over it. This leads us to the obvious question: Why not provide the words in the first place?

INTERNAL PROGRAM NAMES

It is time, said the owl, to discuss some necessities for long-term maintainability of software. Maybe the owl said something else. I remember well one document that had these three definitions of the terms used in the object model:

TradeUnits = supplyPurchase.tradeUnits

PackageSize = supplyPurchase.item.PackageSize

Units = supplyPurchase.tradeUnits * supplyPurchase.item.PackageSize

It seemed to me that the third line could have been written:

Units = TradeUnits * PackageSize

In this example, the term "PackageSize" seems clear. It is the size of the package. As an example, say that 100 fudgies come in a package. Then one would guess that 100 is the PackageSize. Then PackageSize * TradeUnits must be 100 times a single TradeUnit (a single fudgie) to give the total number of units, namely 100 fudgies.

This guess was as as wrong as it was natural (and shows why we have to be judicious in our choice of names in programs). TradeUnits (in this program) are the number of bags (in particular, the number of bags purchased in a month). Say 85. The term has nothing to do with "units" and the name gives no hint that it is tied to a particular period of time. Once we know this, all is clear. PackageSize is indeed the number of fudgies per bag, so that TradeUnits * PackageSize must be the total number of fudgies, 8500, purchased in a month.

If the names had been something like: PackagesPurchasedPerMonth, PackageSize, and UnitsPurchasedPerMonth, then there would be far less room for confusion.

It may seem picky to spend time discussing or changing tiny details like names used internally in programs, but if such details are attended to it is a win in the long run as learning times for new hires are shorter, the number of errors made due to confusion is diminished, and the programs are far more maintainable.

In this particular case, the term "trade units", unfortunately, has a number of inconsistent meanings in the industry, and so does not have even the justification that it means something to practitioners. There is a formally defined term "trade container" which has the exact same meaning as "PackageSize" as used here, but which the programmers didn't know and so didn't use. Now there are two words where there used to be one, leading to a new opportunity for confusion, as if we didn't have more than enough allready. Sometimes domain knowledge is helpful.

Documentation (along with good design) lies at the heart of successful software. Programming is not a game where you are forced to decipher obscure clues and solve arcane riddles to understand the intent. Come to think of it, many computer games (e.g. Myst) are complex programs which you buy without the instructions. Your job is to muddle on through, learning the rules as you go. Sometimes they even give you a booklet in which you can take notes, i.e. forcing you to document their program.

That may be fun (for some people, though I find it grating), but game playing is not in the cards when a corporation is trying to enhance its bottom line.

MATH CONVENTION IS BACKWARDS

Another thing to avoid in documentation is the old-fashioned math style where undefined variables appears in a formula before you know what they stand for:

A = r2

Where r is the radius of a circle and A is its area.

This can be confusing, forcing you to read ahead and then go back, especially if the equation is a long one with lots of as-yet-unexplained variables. Far better, from a reader's viewpoint, is to follow the obvious dictum to define terms before you use them.

A circle with radius r has an area A given by:

A = r2

WIDGET OF THE WEEK NO. 16

Or, To people who want something to read while waiting for the computer to boot

TRICK REVEALED

In Kawasaki's MacWay online newsletter about the history of the Mac I mentioned that I used a "psychological trick" to make the Canon Cat seem as though it booted instantly. I got a lot of mail asking, "Ok, wise guy, don't hold out on us, what was the trick?" Since it was based on solid psychological research, worked like a charm, and can be applied to a number of interface situations, I thought I'd spill the beans.

As it happens, it took the Cat about seven seconds to read in enough stuff from the disk to give the user a live screen. Recall that the Cat always started off from exactly where you had left it, even the cursor was in the same place when you came back to it. (It is hard to realize, without experiencing it, how pleasant this kind of continuity from session to session can be!)

So we stored an image of the screen on disk so that when you turned on the Cat, that image promptly came up, which took less than a second. I knew from published experimental results that a person typically takes at least eight seconds to re-engage their thinking when coming into a new environment (e.g. moving from talking to a co-worker to using their computer). People stare at the screen for a few seconds, oblivious to time passing, regaining context. By the time they started working, the Cat screen was real (the only visual change was that the cursor started blinking).

In case they started typing before the screen was ready, we captured the keystrokes which all popped into the cursor location at once when the screen went live. In practice (and we did a lot of user observation to find this out) this almost never happened. When it did it did not unduly upset users. In any case, it was a LOT better than having to wait a minute or two as with PCs and Macs.

It would be possible, on today's computers, to quickly load a small routine to capture and display keystrokes so that you could sort-of get started or at least capture an idea while the rest of the system drifted in. Then you could paste what you've done where it belongs. But nobody seems to care. More's the pity.

PHONE SYSTEM MNEMONIC DECIPHERED

Those of you who have enjoyed using an enterprise-wide phone system will appreciate my delight when I learned how to access the splendid array of exotic features available at one of my clients' headquarters. Once you know this code you can then learn the codes that enable you to:

Transfer a call to any other organization with a phone wait longer than yours

Connect automatically to a third party, randomly chosen from the Moscow phone book

Provide perpetual Musak® occasionally interrupted by a gravelly voice that assures you of the importance of your call

Make that ghastly, completely dead absence of sound that makes the caller wonder if an atomic bomb has hit your headquarters city

Tell the caller that this call may be recorded to assure quality control

Provide automatic translation to and from ancient Phoenician

And there are many more such features. But back to my point--the access code is practically intuitive: You have to dial "8877." Why "8877"? It has taken weeks of highly-specialized interface detective work, but now we know why.

Not only do we know why, but I must admit that as a human interface designer I can only marvel at the clever mnemonic that gave rise to this obvious dialing sequence. Did you realize that "8877" spells "TUPS"? If "TUPS" doesn't come readily to mind, just recall that it's "SPUT" backwards. I'm sure that that will help most people. But if it doesn't, we can use the first letters of each wordto make a handy phrase as a mnemonic. (Note: "mnemonic" isn't). To do this, simply note that "8877" also spells "VTQR" on the phone dial! This is easier to remember than "SPUT" backwards. It's easier because there is a simple phrase that immediately comes to mind, a phrase for which VTQR is the acronym: "Viceroys Transmogrify Querulous Rioters". I think that no more need be said on this topic.

WIDGET OF THE WEEK NO. 17

BART IS STRANGER THAN FICTION

The underground conveyance that slips me smoothly into the basement of one of my client's San Francisco headquarters each day is just a little bit off, as if it lived in a parallel universe that is a few milliseconds out of sync with the rest of the world.

Some days, fifteen to twenty minutes out of sync.

The tracks on which it runs, for example, are a little wider than the U.S. railroad standard of 4 feet, 8 inches. I guess this doesn't make much difference in the cost of the cars, which are all custom anyway, but the work-trains and other equipment that rides the rails had to be custom-made at some additional expense. The couplers between cars are non-standard as well. I'm sure there was a good reason for this. Or maybe I'm not so sure. But it doesn't matter, it's just taxpayer money. Other transit systems manage with standard gauge, but what do I know?

The passengers, too, seem odd (except for me and you, of course). Many use the ride as a time for reading, a last-minute nap, or an opportunity to stare vacantly out the windows, open-mouthed at the black nothingness that characterizes the underground view. A few choose to finish their morning preparations on the way. Twice now I've seen the same woman-a woman with an interesting face-apply lipstick, mascara, and this and that until her appearance is indistinguishable from the horde of similarly made-up women on the train. A leather-jacketed young man with a long, wild, mane that seems to have just escaped from a helmet sits down opposite me. He holds a motorcycling magazine. From his pack he takes out a brush and rubber band which tame the hair. The jacket folds away into his pack along with the magazine and out comes a blazer and a new magazine. The shirt is buttoned to the neck, then festooned with a tie. Wire-rimmed glasses are extracted from a pocket and, abracadabra, we have the young intellectual professional, reading Chess Today.

But it is the interface to the ticket machines that really catches my attention (you were wondering when I'd get to this, weren't you?). The new, redesigned, ones at the Colma station are the result of ignoring 25 years of experience with the old ticket-bots. As I stand in line at one of the two machines not presently out of service, I watch person after person baffled by the layout. Though experienced with them myself, I still fumble at the unnatural sequence.

The obvious way to start, and what nearly everybody I've observed tries at first, is to put in money (or an old ticket, which is-cognitively-a money-equivalent). That's how vending machines work: put in money, make choice, get stuff. It is a cultural paradigm.

But these ticket vending machines were designed on some other planet. It is hard, as I sit here, to recall the exact sequence since it is so counter-intuitive. It is vividly impressed on my memory that the different actions take place randomly across the face of the machine. First you do something on top (not a bad place to start, but it's the wrong thing to start with), then on the lower right, then somewhere in the middle and so on. Perhaps the designers put the elements together in a blindfolded game of pin-the-tail-on-the-donkey. The places you put in the ticket (to the left), coins (middle-ish), or bills (lower right) are widely separated instead of being clustered. The LCD display is high up at top center, where short people cannot easily read it (ask my wife); and in any case it is far enough from the rest of the interface that many people don't notice it at all. Maybe it's good you don't see it since it's response time is so slow that people either repeat their actions in hope of forcing a response or stand there wondering whether the machine is broken--in the case that they do notice the display.

Then there's the "correction" button, labeled as though you've made a mistake that has to be corrected. It is not for correcting a mistake: you use it if you want the ticket to be issued for less than the total amount of money you've put in, in other words it tells the machine you want change back. You also have to choose between "BART" and "BART-MUNI" buttons before getting your ticket (a pamphlet, available nowhere in the vicinity, explains the subtle difference). As research has repeatedly shown, having to make a pre-decision takes more mental effort than making one afterwards (it's the old noun-verb vs. verb-noun thing).

Ironically, some of the older machines at least started off on the right foot by having you put in money or the old ticket first. Another proof that the new machines are badly designed are the bright, colorful, large numbers and arrows, 1, 2, 3, 4 to guide you. If the panel were well laid-out, you wouldn't need all these crutches. Of course the numbers don't help a lot, as you've got to remember what step you're on (#2) while you put in your money ($5) knowing that you only want to get a $3 ticket so you have remember to hit the correction button in the next step (#3) keeping in mind that you'll want to count your change ($2) which will come in the form of quarters (8 of them). You can hear the 7:06 train coming! What step did you say you were on?

When you find a computer interface using bright colors and lots of little explanatory legends, trying hard to guide you through a process, you can be sure that the fundamental design has gone astray. (Seen anything that looks like that recently. If not, it's coming soon to a computer near you.)

Here's how the machines could work-though of course there should be user testing to verify that this design is OK:

On the left (since English reads from left to right) should be the slot for the ticket, a place to put in bills, and the coin slot. The display says: "Put in money or your old BART ticket or both." As you put in each, the total value should appear immediately in the LCD display with a message like this:

You now have put in $4.55. Put in more money if you wish, or press

Issue BART Ticket, Issue MUNI-BART Ticket, or Change The Amount Shown

This way the choice is made with the same action that usually confirms (and closes) the transaction. If the "Change The Amount Shown" button is pressed, you are asked to type the amount in which you want the ticket issued and press the large ENTER button ("Enter" is now culturally acceptable). You then get your change and the message shown above, displaying the new amount, of course. For the traveler with the right amount of money in hand this reduces six actions to two: put in the money, press an "issue ticket" button.

There are other shocks for the unwary with the present machines: Say all you have is a $20 bill. The machine accepts it and puts up "$20.00" in the window. You use the Correction feature to show that you only want a $4.00 ticket. Surprise! The system will give no more than $4.95 in change. Yes, there was a little notice posted somewhere saying that, but in all the visual clutter you didn't see it, besides you are trying to catch your train and are not predisposed to taking in the sights. This leaves you with a $15.05 BART ticket that you don't need; you will be buying a sandwich, no drink, no cookie, for lunch-or going to a place that takes plastic. Thanks to BART.

WIDGET OF THE WEEK NO. 18

English is, probably, the hardest language in the world to learn. Readers of Widgets know this can mean only one thing: it has a terrible human interface. Fortunately, we have little verses to help us remember the rules...

I BEFORE E, IF TAKEN WITH CAFFEINE

©1993 by Jef Raskin

"I before E

Except after C,

Unless pronounced A

As in 'neighbor' or 'weigh' "

Education is forfeit for reinforcing these rules!

Sound a feisty reveille while eyeing the schools!

Neither will our heirs be agreeing to deceptions

Once seeing, herein, these ancient exceptions:

We were seized by a feeling

For fleeing on the ceiling

To a leisurely meal

With Keith, Sheila, and Neil

We drank madeira, so foreign, in steins

Along with a surfeit of weird blueish wines

And being too foolish, avoided protein

Therein guaranteeing an ogreish scene

Wherein we're canoeing to a new sovereign state

While deicing a kaleidoscope on a hot jadeite plate

And kneeing obeisance to an overseeing king

Our plebeian lips kissed his counterfeit ring.

Then we unveiled their sleight-of-hand trick-

Deifying a heifer, with effect atheistic

And falling from the heights with a loud seismic crunch

We crushed the nonpareils we had heisted for lunch.

So "I before E

Except after C"

Unless pronounced A?

False decreeing, I say!

WIDGET OF THE WEEK. 19

CHEWING GOMS

There are a number of techniques we use to analyze the quality, reliability, and productivity of an interface. Most are heuristics, those slippery rules that work most of the time, based partly on experience and partly on experimental data. Widgets have discussed these, among others:

avoid modes

use "noun-verb" (or-in IBM-ese-"object-action") rather than "verb-noun" methods

radio buttons work better than check boxes

But there are also well-verified quantitative methods that can predict performance. One of them is the GOMS method (references below). That we have such precise tools seems a too-well kept secret, so this Widget will show how a simple form of GOMS works.

First, we need a well-defined problem that requires an interface:

A lab assistant works at a computer, mostly typing, and is occasionally asked to convert temperature from degrees F or C to degrees C or F. For example, if the assistant is told to convert "30012.25234 degrees Fahrenheit" then the assistant will use the keyboard and / or mouse to enter the number provided to him or her by the researcher.. Voice input or other means are not available. Both C-to-F and F-to-C are equally likely to be required, but they come in no particular order. The numerical result must appear on the display, from which the assistant can read it out to the researcher. The input and output must allow for at least 10 digits to both sides of the decimal point.

The interface is to minimize the time and effort it takes to do a conversion. It is also required that a person with some experience at using computers should be able to figure out how to use the interface the first time within two minutes and without a manual. Screen real estate is not an issue, nor is making the interface attractive a requirement, though it is considered a plus. It is assumed that the window or area in which the conversion is to be done is already active, that is, how you activate the interface is not part of the problem.

A MODERN, GRAPHICS-ORIENTED SOLUTION

The graphic solution illustrated has two pictures of thermometers with a pointer on each that can be raised or lowered with the GID. As the advertising literature for this interface points out, no typing is required. As one pointer is moved, the pointer on the other thermometer moves to the corresponding temperature. A version in color is stunning, the bar indicating temperature in a bright red, and airbrush-like highlights make the thermometers look like glass, etc. Due to the precision required by the problem statement, means of expanding and contracting the scales and changing the range are provided. Keeping the scales representing the appropriate range on one thermometer as you move the arrow on the other is done automatically.. The exact readouts are provided on the movable arrows. The temperature is indicated both numerically and with a bar, so that people with different data-reading preferences are accommodated. The "Auto-Med" feature changes the ranges so that they are centered on 37°Celsius and 98.6°Fahrenheit1 and adjusts the tic-marks so that they represent tenths of a degree, the range and precision needed in most medical situations.

Pressing Expand Scales or Compress Scales increases or decreases the values at tic-marks by a factor of ten respectively. To get quickly to a far-distant temperature, one expands the scale and scrolls up or down until the desired range is in view, puts the arrow near the desired temperature and then compresses the scale (adjusting the arrow if necessary) until the desired precision is attained.

A number of advantages are claimed for this interface: the relationship between the temperatures is clear, you can see how they move together in real time. Any degree of precision can be obtained by expanding the scale, and any temperature range can be accommodated by using the scrolling arrows at the top and bottom of each thermometer scale. In addition, this interface uses familiar icons for temperature (traditional thermometers) and has pleasant graphics that are attractive to users. They will want to play with this interface, and thus learn it without apparent effort.

There are also a number of problems with this interface, which you should think about. Also, it is a good idea to sketch out some improvements or alternative interfaces that would be easier or faster to use (take a few moments to actually do this. Remember, you are a human, you might start by asking what interface would please you most?).

THE KEYSTROKE-LEVEL MODEL

The method to be used in the analyses that follow is based on the "Keystroke-Level Model," a simplified version of GOMS (Card et. al. pp 259 ff).

What this analysis gives is a prediction of

The time an experienced user will take to execute the task (excluding time due to errors except typing errors correctable with the backspace key)

When productivity is important (which, in business, is almost always) it is the goal of an interface designer to minimize this time. Other considerations govern learnability and minimizing error rates and will be discussed along with the "answers." A GOMS analysis is based on the abilities of a more or less "normal" human being and:

A well-defined task (as we have in this case)

The method used in pursuing the task, and

The response time of the system

There are two steps in a simple task (what Card et. al. call a "unit task"). They occur serially so that the total time for the task is the sum of the two times. The first step is cognitive: you must figure out what is to be done and choose a method. The second is where you interact with the computer to execute the task. For our task we've assumed that Pat is already alerted and the time we will study depends only on the nature of the temperature conversion interface. To calculate this time, all the operations a user must do are listed in the order they are done, a set of rules are used to determine where the user spends time in mental preparation, a time is assigned to each operation, and then the times are added to get the total time for using the interface. The times for different kinds of actions, as listed below, have been determined by dozens of experiments with a wide range of users.

SOME TYPICAL TIMES FOR VARIOUS ACTIONS

This list is simplified from the full treatment given in the references, but is still useful for preliminary evaluation of different interfaces and gives the same ordering of speeds as a more careful treatment would find, at least for the interfaces discussed here. The intent is to give a feel for how GOMs works. It is assumed that no drawing is required in using the interface.

Keystrokes (K): .2 seconds

For each keystroke (Shift is a separate keystroke) or mouse click, assuming Pat is an average, skilled typist, we add .2 seconds.

Mouse to Target (M): 1.1 seconds

For each time the mouse must be moved to a new location, 1.1 seconds. In fact this time is larger when the distance to be moved is greater or the target is smaller (and vice versa). However, this time is a useful compromise.

Hands to or from Mouse (H): .4 seconds

To move the hands from keyboard to mouse or vice versa, .4 seconds

System response time (R): measured or estimated

Whenever the user cannot proceed due to system delays, such as response time or time to do a scroll or other such operation during which the user cannot proceed, this time must be added.

Mental Preparation Time (MPT): 1.35 seconds

The time it takes for the human mind (on average) to prepare for a step. There are a set of rules for deciding when a person requires this time (Card et. al. pg. 265). For our purposes they can be summarized:

Rule: Add 1.35 to any keystroke that is not inside text or a number being typed. Also add 1.35 to any Mouse-to-Target operations that select commands (not arguments to commands).

Exception 1: The operation of point-and-click requires no MPT before the click

Exception 2: If a command is invoked by multiple clicks (e.g. you type "EXIT" or "CTRL-L" the only keystroke that gets an MPT is the first.

Exception 3: If there are multiple terminators to a command (e.g. if you press RETURN after typing the last letter of the command itself) there is no MPT before the additional terminators. But there is an MPT between the last keystroke of a variable input and its terminator. So if you are asked to type in a number between 1 and 10 and press RETURN then you would add MPT between the number and the RETURN.

CALCULATING THE TIME FOR THE TWO-THERMOMETER METHOD

We assume that Pat has been using this interface for a while so that no decisions have to be made when alternate means are available: in other words, Pat has already decided how to use this interface. As it turns out, this particular interface is not simple enough to be considered a unit task (the others will be), and our times will be an underestimate since the task-choosing times, which can be considerable, will not be added in.

A voice rings out in the lab, "Pat, convert 1130.5 degrees Fahrenheit into Celsius, please." Starting with the interface as shown, Pat first expands the scale.

Before going on, note that any experienced interface designer would realize that the term "expand" is confusing. To what does "expand" refer: make the total range larger or the increase the distance representing one degree (which makes the total range smaller)? It is similar to the problem with scroll-bar arrows in most Mac / Windows interfaces. Do they move the window frame or the content? The description says that expansion makes the total range larger by a factor of 10. This, too, is unclear. Does the scale expand around its center? Does it leave the bottom fixed and move the top? Let's assume the latter. Upon clicking on "EXPAND SCALES" the thermometer on the left ranges from 80 to 1,100 degrees. Our time so far is MPT + H + M + K. (We need the H because the problem definition said that Pat's hands were normally on the keyboard).

Now Pat has to scroll the thermometer using the arrows above or below the scale of temperatures, and assuming no errors are made, this operation takes MPT + M + K + R (in this case, the scrolling time) + MPT + K (releasing the mouse button). Assume that .5 seconds was taken to do the scroll, and that Pat did not scroll too far or not far enough.

Pat's next task is to get the arrow to read exactly 1130.5. So the arrow is moved to approximately 1130 degrees (MPT + M + K + R + MPT + K), the scale is compressed (MPT + M + K), the arrow is adjusted (MPT + M + K + R + MPT + K), to get the necessary precision the scale is compressed again (MPT + M + K), and the arrow is given a final adjustment (MPT + M + K + R + MPT + K). Pat then reads out the Celsius temperature shown on the other arrow. Our GOMS estimate of the time is 11 * MPT + 7 * M + 11 * K + 4 * R + H, or about 27 seconds.

SUMMARY OF METHOD OF APPLYING GOMS

To get a total time, you lay out the physical steps required to do the task, add in mental preparation times (MPTs) according to the rules, and sum the times. The GOMS models (there are a number of them for different applications and of varying degrees of approximation) have been repeatedly validated experimentally. The work of professor Bonnie John which incorporated PERT models into GOMs achieved real-world accuracies within a few percent of the results discovered when the interfaces were built and tested. In other words, the full GOMS model, applied correctly, is a valid tool. Since GOMS is one of the few quantitative tools in this field, claims of interface design expertise without being able to apply GOMS are questionable. The analysis is eased in complex cases by using computer-based tools that are available.

I must emphasize that the outline given here demonstrates only a small part of how GOMS works, and the references must be studied to learn how to apply GOMS properly. For example, the model presented here does not take into account Fitts's law, which allows refinement of mouse motion time to account for distance and target size.

WIDGET OF THE WEEK. 20

SOME ALTERNATE INTERFACES FOR WIDGET 19's PROBLEM

USING RADIO BUTTONS TO CHOOSE THE CONVERSION

The text in the box explains how to use this interface adequately for anybody familiar with standard user interface techniques. Activating the radio button chooses the conversion. The input is then typed into the white box and, when ENTER is hit, the answer appears in the gray box. Most users would have no trouble operating this interface even without the instructions.

This is a unit task, and the analysis is simple:

Check the desired conversion (half the time this is already done). 1/2 * (MPT + H + M + K) = 1.525 seconds. Then, move the hands to the keyboard, type the temperature and press ENTER. Assuming five digits plus a decimal point this takes MPT + H + MPT + 6 * K + MPT + K = 5.85. The total average time to use this interface is about 7.4 seconds. It is clearly superior to the thermometer method.

USING COMMAND BUTTONS

We can proceed immediately to the GOMS analysis: the problem statement assumes that the converter is active and places the cursor in the white box so that the temperature can be typed in. The time is MPT + 6 * K + MPT + H + MPT + M + K. The total time is about 7 seconds, which is just a little better the previous interface's time.

This shows an important limitation in GOMS analysis (a limitation that its designers were well aware of): This interface is both less error-prone and has better error-recovery than the previous one due to its noun-verb design. There is not room in this Widget to go into this aspect of interface design analysis, but the improvement in usability is larger than the slight time advantage indicates.

A MORE DIRECT METHOD

Here the use of a typed "C" or "F" indicates both that the entry is complete and which conversion is desired. One source of error is that the user might type the wrong letter. There is no problem if Pat is asked "What is the equivalent of 1130.5 degrees Fahrenheit", since it is natural to type "1130.5 F" but if the question is phrased "Convert 1130.5 degrees to Celsius" Pat might type "1130.5 C" and get the wrong conversion. GOMS does not take errors into account (except by looking at typing rates which average in error correction times). Many good designers settle on this method as optimal.

How fast is this method? Using the same temperature as before we have: MPT + 6 * K + MPT + K. By avoiding the mouse altogether we achieve a time of 4.1 seconds. Definitely better, though correcting an C/F error requires doing the whole process over (which takes more than 4 seconds) whereas in the previous interface a correction was just a mouse click away (less than three seconds). We have not stated how the conversion box is re-enabled.

DUAL CONVERSION TECHNIQUE

In this interface the user simply types in the temperature and then reads the desired result; a more compact display can easily be designed if this one seems to take up too much display real estate. Two conversions are done at once; it seems that this is not an obvious approach since few readers (during manuscript testing) thought of it. I suspect that this is due to a common avoidance of having the computer do "extra work." In this case, the unused conversion is "thrown away" and the design might feel "wasteful." If you fall into that camp, think just how many computer cycles are wasted in useless graphical displays!

The only C/F error possible is in reading the result from the wrong box, and only testing would show if the error rate is high enough to nullify the GOMS speed advantage. Correcting an error requires no input at all, of course, the user just has to read from the other box but detecting that an error has been made may not be easy.

The time to operate this interface is MPT + 6 * K + MPT + K as in the previous case, or 4.1 seconds. But in the long run, due to its better error handling and due to the lack of having to choose between typing "C" and "F" (this fact will decrease the second MPT, another effect advanced GOMS analysis accounts for that we will not discuss here) it will be faster, reaching about 3 seconds in practice.

GOMS analysis gives a theoretical minimum time of MPT + 6*K for an expert typing in just the information required (about 2.5 seconds under our assumptions). Is there any reason we cannot achieve this minimum? One last trick gets us there: have the conversion done as numbers are typed in. Now no final delimiter is needed. When you type in "1130.5" you first type in a "1", so the system converts 1 degree both ways, the second digit makes the input "11", and that gets converted as well, and so on. Backspace would return the display to the previous conversion (back to "1" from "11" for example). When you stop typing, the conversion is done.

Starting with an interface that is very graphical and uses spiffy widgets, we have gone to a simple, keyboard-only interface that takes about one tenth the time to use.

References:

Card, Moran, and Newell. The Psychology of Human-Computer Interaction, Erlbaum 1983. The seminal work.

John, Bonnie. GOMS? Interactions, October 1995 pp. 80-85. A good, easy-to-read overview with many recent references.

WIDGET OF THE WEEK NO. 21

INTERFACE EFFICIENCY, PART 1

In engineering, efficiency--the opposite of wastefulness--is often a major concern. It is formally defined as the ratio of the amount of power that does useful work divided by the power that goes into the system. The laws of thermodynamics tell us that, theoretically, efficiency ranges from 0 (all the power is wasted) to at most 1. Any real machine has an efficiency less than 1, which means that a perpetual motion machine is impossible--all it takes is one moving part disturbing the air or running on a bearing to make sure the machine will eventually stop due to friction turning its motion into heat. Efficiency is often given as a percentage, from 0 to 100 percent. Here are a gamut of examples: an ordinary incandescent light bulb has an efficiency of about 3%, a solar cell is typically 15% efficient, a well-designed aircraft propeller can reach 85%.

It is often easy to calculate efficiency. It only requires elementary multiplication and division, so it is easy to get quantitative results. Here is an example: A primitive DC-to-AC (direct current to alternating current) converter uses a 12 V (12 Volt) car battery to spin a DC motor. The motor turns (by a mechanical coupling) an AC generator that puts out typical household electricty: 120 VAC. Say that the current to the DC motor is 10 A (Amperes or amps). Power is measured in Watts (W). Since W = V * A the power input is 120 W. By using the output of the AC generator to try do do various tasks, we find that it can provide at most .72 amps. The power output is therefore 86.4 W or 72% of the input power. We say that the efficiency of the DC-to-AC conversion is 72%. The other 28% of the power is wasted as heat generated in the bearings, wiring, and other parts of the equipment. An aside: an efficiency of 72% is quite good: if the motor and generator were equally efficient they'd each have to have an efficiency of 85%, which is hard to beat for electromechanical devices. Today we would use a solid state (transistorized) converter; the efficiency of the overall process can easily be in excess of 90%.

While we rarely apply quantitative thinking to interface design, an analogy with physical efficiency gives us a way of approaching the issue. This is possible due to the remarkable invention of "The Mathematical Theory of Communication" as Claude Shannon titled hisclassic 1948 paper that introduced information theory to the world. Shannon pointed out that the smallest unit of information is a single on/off or yes/no choice: one bit. To choose among N equally likely options requires the logarithm (to the base 2) of N bits. [See note 1] When I first read Shannon's work in high school I was startled to learn that information theory was a branch (some say root) of thermodynamics. I had not suspected that information could be treated rigorously.

In interface design we can compare the amount of information needed to do the task at hand with the amount of information that a user must supply in order to do that task. Dividing the second figure by the first (just as with mechanical efficiency) gives us the information theoretic efficiency of the interface for that task. The frequency-of-use weighted average of these efficiencies over all tasks might be taken as a useful measure of the information theoretic efficiency of an interface as a whole. Let's work a few examples.

The keyboard of the computer sitting in front of me has 76 keys (there are others, but I never use them). For the sake of initial simplicity we will assume falsely that all are equally likely to be pressed; the form of the argument does not change when we introduce the correct probabilities [see Note 2] and (except for extremes) the numerical values used here are not particulalry important. Given 76 keys, pressing one of them supplies log2 76 = 6.25 (approximately) bits of information. Let's start with a real interface folly: the computer presents a modal dialog box telling you that your email has been sent. You can do nothing until you get rid of the box, usually by pressing ENTER. The information required is zero bits; you have not made a choice. The information supplied is 6.25 bits. The efficiency is zero (as any frustrated computer user already suspects). Say you are given a choice of whether to continue or not; the choice requires only one bit of information, but the way the computer is set up, you must strike either Y or N, supplying 6.25 bits. The efficiency is about 16%.

What good are these quantitative measures? Aside from

the ability to say that a proposed interface detail has a particular numerical efficiency

to bolster the usual heuristic and experience-based arguments, and

the intellectual delights of inquiry,

having an information theoretic minimum gives the interface designer a target. If a user choice requires k bits and your interface has the user supplying exactly k bits you know that you cannot do better (from an information efficiency standpoint). If you require more than k bits, you know that there is room for improvement. Based on these information theoretic considerations and the time it takes for humans and machines to perform interface actions (using the well-known GOMS methodologies), a very practical quantitative approach to interface design and analysis can be constructed.

There are a number of other tools that are part of the analysis, e.g. Fitts' law tells us how long it takes to move a cursor to a target of a given size at a given distance from the current cursor location. Hicks' law shows that the time to choose among n alternatives increases as log2 n. The classic learning curve