Rapid Prototyping

1. Rapid Prototyping Marti Hearst (UCB SIMS) SIMS 213, UI Design & Development February 25, 1999

2. Last Time:Lo-Fi Prototyping lo-fi prototype!

3. Last Time • Hi-fi prototypes warp perceptions • Low-fi prototypes are • easy to create • easy to change • appropriate in the early stages of UI design • Electronic tools in the research community are bridging the gap between low & hi-fi Adapted from slide by James Landay

4. Today • Problems with lo-fi interfaces • Why build prototypes? • Tools for prototyping • Widgets • What prototyping tools lack Adapted from slide by James Landay

5. Paper Sketches • Advantages • support brainstorming • do not require specification of details • designers feel comfortable sketching • Drawbacks • do not evolve easily • lack support for “design memory” • force manual translation to electronic format • do not allow end-user interaction Adapted from slide by James Landay

6. Problems with Low-fi Prototypes • Doesn’t map well to what will actual fit on the screen (realism) • Couldn’t hold in your hand -- different ergonomics from intended device • Timing in real-time hard to do (slooooow computer) • Difficult to simulate some things (e.g., highlighting) Adapted from slide by James Landay

7. Problems with Low-fi Prototypes • Writing on paper not the same as writing on the intended device (realism) • Appearance unrealistic • Dynamic widgets hard to simulate (pop-ups) • Some items had to be static! • Dragging hard to simulate Adapted from slide by James Landay

8. Why Build Prototypes? • Must test & observe ideas with users • Paper mock-ups don’t go far enough • how would you show a drag operation? • not realistic of how interface will be used • Building final app. now is a mistake (?) • changes in the UI can cause huge code changes • takes too much time • Drag & drop prototyping tool appropriate Adapted from slide by James Landay

9. Why use Prototyping Tools(rather than write real code)? • Faster • Easier to incorporate testing changes • Multiple UIs for same application • Consistent user interfaces • Easier to involve variety of specialists • Separation of UI code from app. code • easier to change and maintain • More reliable Adapted from slide by James Landay

10. Prototyping Tools vs. UI Builders • Prototyping tool: • Lay out the design of the system • examples: • hypercard, director, powerpoint, html wysiwyg interfaces (e.g., dreamweaver) • UI builder/toolkit • Create the code that underlies the UI in a real application • examples: visual basic, tcl/TK, Java GUI builders (visual café), parts of cold fusion • The difference is a bit fuzzy

11. Prototyping Tools • Director • most commonly used by designers • intended for multimedia -> lacks widgets • good for non-widget UIs or the “insides” of app • HyperCard • metaphor: card transitions on button clicks • comes with widget set • drawing & animation more limited • Both have “scripting” languages Adapted from slide by James Landay

12. HyperCard • Tool palettes Adapted from slide by James Landay

13. Prototyping Tools • Powerpoint • pros • can be used as a kind of storyboard • decent drawing package • animation features are easy to use and fairly flexible • the notes page feature can comment on storyboard • cons • no interaction facilities e.g. if users clicks on button A, bring up window Wa, otherwise bring up window Wb. • no scripting language

14. Macromedia Dreamweaver

15. UI Builders • Visual Basic • lots of widgets (AKA controls) • simple language • slower than other UI builders • NeXT UIB, SpecTCL, Various Java tools... • widgets sets • easily connect to code via “callbacks” • “commercial” strength languages • there are many such tools • see link on web page to www.cs.cmu.edu/~bam/toolnames.html Adapted from slide by James Landay

16. Other Differences • Programming ability • prototyping tools usually don’t require much • UI builders usually do • Performance • prototyping tools produce slow programs • UI builders depend on underlying language • Widgets • prototyping tools may not have complete set • UI builders have widget set common to platform • Part of a final product? Adapted from slide by James Landay

17. Widgets • Buttons (several types) • Scroll bars and sliders • Pulldown menus Adapted from slide by James Landay

18. Widgets (cont.) • Palettes • Dialog boxes • Windows and many more... Adapted from slide by James Landay

19. What is Missing from a Prototyping Tool? • Support for the “insides” of applications Adapted from slide by James Landay

20. Drawbacks of Current Tools • Require specification of lots of detail • must give specific instance of a general idea • e.g., exact widgets, fonts, alignments, colors • designers led to focus on unimportant details • evaluators focus on wrong issues • Take too much time to use • poor support for iterative design • sketched interface took 5 times longer with traditional tool (no icons) Adapted from slide by James Landay

21. What is SILK???? Sketching Interfaces Like Krazy Adapted from slide by James Landay

22. Designing Interfaces with SILK 1)Designer sketches ideas rapidly with electronic pad and pen • SILK recognizes widgets • easy editing with gestures 2)Designer or end-user tests interface • widgets behave • specify additional behavior visually 3) Automatically transforms to a “finished” UI Adapted from slide by James Landay

23. Some Research Systems • Forms VBT • two-view approach • Lapidary • precursor to many of today’s UI builders • Visual Obliq • for building distributed applications Adapted from slide by James Landay

24. Summary • UI tools good for testing more developed UI ideas • Two styles of tools • “Prototyping” vs. UI builders • Most ignore the “insides” of application Adapted from slide by James Landay

25. Next Time • Discount Usability Engineering