1Fall 2003 6.893 UI Design and Implementation 1Lecture 6: Prototyping2Fall 2003 6.893 UI Design and Implementation 2UI Hall of Fame or Shame?Today’s candidate for the Halls of Fame and Shame is the Windows calculator. It looks and works just like a familiar desk calculator, a stable interface that many people are familiar with. It’s a familiar metaphor, and trivial for calculator users to pick up and use.Unfortunately it deviates from the metaphor in some small ways, largely because the buttons are limited to text labels. The square root button is labeled “sqrt” rather than the root symbol. The multiplication operator is * instead of X.This interface adheres to its metaphor so carefully that it passes up some tremendous opportunities to improveon the desk calculator interface. Why only one line of display? A history, analogous to the paper tape printed by some desk calculators, would cost almost nothing. Why only one memory slot? Why display “M” instead of the actual number stored in memory? All these issues violate the visibility of system state heuristic. A more serious violation of the same heuristic: the interface actually has invisible modes. When I’m entering a number, pressing a digit appends it to the number. But after I press an operator button, the next digit I press starts a new number. There’s no visible feedback about what low-level mode I’m in. Nor can I tell, once it’s time to push the = button, what computation will actually be made.Most of the buttons are cryptically worded (recognition, not recall). MC, MR, MS, and M+? What’s the difference between CE and C? My first guess was that CE meant “Clear Error” (for divide-by-zero errors and the like); some people in class suggested that it means “Clear Everything”. In fact, it means “Clear Entry”, which just deletes the last number you entered without erasing the previous part of the computation. “C”actually clears everything.It turns out that this interface also lets you type numbers on the keyboard, but the interface doesn’t give a hint (affordance) about that possibility. In fact, in a study of experienced GUI users who were given an onscreen calculator like this one to use, 13 of 24 never realized that they could use the keyboard instead of the mouse (Nielsen, Usability Engineering, p. 61-62). One possible solution to this problem would be to make thedisplay look more like a text field, with a blinking cursor in it, implying “type here”. Text field appearance would also help the Edit menu, which offers Copy and Paste commands without any obvious selection (external consistency). Finally, we might also question the use of small blue text to label the buttons, which is hard to read, and the use of both red and blue labels in the same interface, since chromatic aberration forces red and blue to be focused differently. Both decisions tend to cause eyestrain over periods of long use.3Fall 2003 6.893 UI Design and Implementation 3Today’s Topics• Paper prototypes• Wizard of Oz prototypesToday we’re going to talk about protototyping: producing cheaper, less accurate renditions of your target interface. Prototyping is essential in the early iterations of a spiral design process, and it’s useful in later iterations too.4Fall 2003 6.893 UI Design and Implementation 4Why Prototype?• Get feedback earlier, cheaper• Experiment with alternatives• Easier to change or throw awayWe build prototypes for several reasons, all of which largely boil down to cost.First, prototypes are much faster to build than finished implementations, so we can evaluate them sooner and get early feedback about the good and bad points of a design.Second, if we have a design decision that is hard to resolve, we can build multiple prototypes embodying the different alternatives of the decision.Third, if we discover problems in the design, a prototype can be changed more easily, for the same reasons it could be built faster. Prototypes are more malleable. Most important, if the design flaws are serious, a prototype can be thrown away. It’s important not to commit strongly to design ideas in the early stages of design. Unfortunately, writing and debugging a lot of code creates a psychological sense of commitment which is hard to break. You don’t want to throw away something you’ve worked hard on, so you’re tempted to keep some of the code around, even if it really should be scrapped.The prototyping techniques we’ll see in this lecture actually force you to throw the prototype away. For example, a paper mockup won’t form any part of a finished software implementation. This is a good mindset to have in early iterations, since it maximizes your creative freedom.5Fall 2003 6.893 UI Design and Implementation 5Prototype Fidelity• Low fidelity: omits details• High fidelity: more like finished productAn essential property of a prototyping technique is its fidelity, which is simply how similar it is to the finished interface. Low-fidelity prototypes omit details, use cheaper materials, or use different interaction techniques. High-fidelity prototypes are very similar to the finished product.6Fall 2003 6.893 UI Design and Implementation 6Fidelity is Multidimensional• Breadth: % of features covered– Only enough features for certain tasks• Depth: degree of functionality– Limited choices, canned responses, no error handlinghorizontalprototypeverticalprototypescenariofront enddifferent featuresback endFidelity is not just one-dimensional, however. Prototypes can be low- or high-fidelity in various different ways (Carolyn Snyder, Paper Prototyping, 2003).Breadth refers to the fraction of the feature set represented by the prototype. A prototype that is low-fidelity in breadth might be missing many features, having only enough to accomplish certain specific tasks. A word processor prototype might omit printing and spell-checking, for example.Depth refers to how deeply each feature is actually implemented. Is there a backend behind the prototype that’s actually implementing the feature? Low-fidelity in depth may mean limited choices (e.g., you can’t print double-sided), canned responses (always prints the same text, not what you actually typed), or lack of robustness and error handling (crashes if the printer is offline).A diagrammatic way to visualize breadth and depth is shown (following Nielsen, Usability Engineering, p. 94). A horizontal prototype
View Full Document
Unlocking...