I'm going to read -- Bruce tends to philosophize a lot in this, so it's not going to be as useful to put up slides, but I'm going to read to you some of his experiences from the -- here we go. From user testing: "Our testing method is as follows. We set up a room with five to six computer systems. We invite groups of five to six users at a time to try out the systems, often without knowing that it is the software, rather than the system, we are testing. We have two of the designers in the room: any less, and they miss a lot of what's going on; any more, the users feel as though there's always someone breathing down their neck. The initial ground rules are that no questions will be answered, as by the time the formal testing begins, we can supply a draft of the manual. Usually by the second group, some glaring defects in the interface have shown up, and we have to give them help getting past the stumbling blocks. 95 percent of the stumbling blocks found are found by watching the body language of the users. Watch for squinting eyes, hunched shoulders, shaking heads, and deep, heartfelt sighs." [Laughter] "When a user hits a snag, he will assume it is his fault. He will not report it. He will hide it. Make notes of each problem and where it occurred. Question the users at the end of the session to explore why the problem occurred. You will often be surprised what the user thought the program was doing at the time he got lost."
"Herein follows a true anecdote which illustrates how difficult the most simple human interface issue can be, and why thorough testing on real people is so important. As we tune in" -- it's so easy to entertain a crowd just by reading something Bruce wrote [laughter] -- "as we tune in, the authors of the software, both of whom pride themselves on clever interface design, have anguished for hours over difficult passages in their program. It was to turn out, their guesses were quite accurate in said difficult passages. It was the simplest question of all, the cause of the problem. In Apple Presents the Apple II E, the training program for teaching fundamentals using the new Apple II E, find out if the user is working with a color monitor. "User profile: new owner, customer in computer store, or member of a class learning how to use an Apple computer. Test user profile: customers in computer store, non computers [users?] in classsroom environment, friends and relatives. First design: a color graphic is displayed on the screen. Prompt: are you using a color TV on the Apple? Anticipated problem: those who were using a monochrome monitor in a classroom or a computer store situation wouldn't know whether the monitor was black and white, or was color with the color turned off. First attempt: a color graphic's displayed, prompt: is the picture above in color? 25 percent failure rate." [Laughter] "Reason: as anticipated, but incorrectly overcome, those seeing black and white thought their color might be turned down. They didn't answer the question wrong, they turned around and asked one of the authors whether the monitor in question was color or not. A decision was made: the authors could not be supplied with the disk." [Laughter] "Second attempt: a smaller graphic, with large letter words in their own vivid colors, was substituted: green, blue, orange, magenta, which were the only colors the Apple II can display. Prompt: are the words above in color? Failure rate: color TV users, none; black and white monitor users, none; green screen monitor users, 100 percent." [Laughter] "This is why it pays to have a variety of configurations in your test suite. Third attempt: the graphic remained the same, prompt: are the words above in more than one color?" [Laughter] "Failure rate: color TV users, none; black and white monitor users, 16 percent; green screen monitor users, 50 percent. Reason: the black and white monitor users who answered incorrectly admitted they did so on purpose." [Laughter] "50 percent of the green screen folk considered that they were looking at both black and green, two colors, and answered the question accordingly." [Laughter] "Fourth attempt: same display of graphic and color text. Prompt: are the words above in several different colors. Are the words above in SEVERAL different colors? Failure rate: color TV users, none; black and white monitor users, 20 percent; green screen monitor users, 23 percent. By this time the authors were prepared to supply everyone who bought an Apple with a free color monitor just so we would not have to ask this question." [Laughter] "It turns out about 20 percent of the people were not really reading the question, and were responding to 'Are the words above several different colors?' 'Well, yes, of course, green, violet, red, there are several different colors, let's move on!'" [Laughter] "Fifth attempt: same display of graphic and color text. Prompt: do the words above appear in several different colors? Failure rate: none. In case it appears the authors were simply dull fellows, be it known that this was a fully interactive training program, in excess of 100K of code," -- remember, it was a 128K machine, so ... -- "and this was the only interface issue that required more than one correction. It clearly exemplifies how even the most careful designers can totally miss when guessing how users are going to respond." So, reading from Bruce Tognazzini. The Apple II project had started out -- well, the Apple II wasn't really a project, it was a collection of projects. We started out with a number of pieces of software that had our cherished angle bracket or square bracket prompts. By the time we got around to the Apple II E and the Apple III, we'd developed a more or less text windowing interface, called File Card Metaphor, where we used special characters in the character generator ROM to do something like the File Card interface in the Lisa, with -- pick one, two, three, four, five, six menus, and you used the escape key to back out through a hierarchy, and press numbers 1, 2, 3, 4, 5, 6 to advance to the next level. It was a hierarchical-spatial text-driven, keyboard-driven user interface. It didn't use the mouse. It was very successful for what it did. We ensured consistency across many applications, all the applications that Apple implemented as well as third party applications. For example, if anyone was familiar with Quark Catalyst -- Quark, they're the people who make Quark Express now, they made the original Hard Disk Manager for the Apple II and the Apple III, and it used the same interface. It had consistent use; in the keyboard keys, the Open-Apple always meant the same thing in different applications. And so even though it was a text interface, it had many of the underpinnings of the consistency of the graphic user interface of the Macintosh. And it was driven by the exigencies of User Training, which was my mother's group, because the less time we had to spend on user training, the cheaper and faster it was, and if the software were consistent, the training went more easily. It was driven by the exigencies of Publications, which I was running, and one of the problems we faced in Publications was that having not invented desktop publishing yet, we had six weeks minimum from film to printers, which was usually the time that was reserved to write or finish the software. We often had to be finished with the manuals several months before the product shipped, and the software wasn't finished at that point, so in order to have manuals that accurately reflected what the software was going to do, we had to have the programmers tell us what the user interface was going to be, and then in going through that with the programmers, having them do it the same way other applications did it gave us a more full idea for "okay, it's going to do this, it's going to do this, it's going to do that," if they followed some standards or some guidelines. In fact, what Bruce did before writing the Apple II human interface guidelines, and what the origin of this document was, was in fact a Publications Style Guide, which was how we wrote manuals and how we explained portions of the human interface, and explained portions of how you used the computer. And by using consistent explanations, that drove consistent design in some of the applications. So that was in the origins of user testing and of consistency of user interface design in the Apple II group. As I said, it moved into the Lisa group, starting with the separate angle which Larry talked about, coming from Xerox PARC. And the two basically fused in the Macintosh group, where we had the Lisa -- the benefits of the years of Lisa user testing experience and the massive amounts of design that went into the graphic user interface, plus a lot of the democratic, grassroots issues that had come up through the Apple II. Remember, Lisa was only dealing with seven applications. That was all you got on a Lisa. The Macintosh was designed like the Apple II with something where you had many, many applications from third party developers. And so we took the Lisa user interface, grafted it on to the guidelines that had come out of the Apple II Style Guide and Apple II guidelines efforts, and published that for third party software developers to use as style guides for their own applications. -- LisaList is sponsored by <http://lowendmac.com/> and... Shop buy.com and save. <http://lowendmac.com/ad/buy.com.html> Support Low End Mac <http://lowendmac.com/lists/support.html> LisaList info: <http://lowendmac.com/lists/lisa.html> --> AOL users, remove "mailto:"; Send list messages to: <mailto:lisalist@mail.maclaunch.com> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive: <http://www.mail-archive.com/lisalist%40mail.maclaunch.com/> iPod Accessories for Less at 1-800-iPOD.COM Fast Delivery, Low Price, Good Deal www.1800ipod.com
