Download - Rapid Prototyping Marti Hearst (UCB SIMS) SIMS 213, UI Design & Development February 25, 1999
Adapted from slide by James Landay
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
Today
Problems with lo-fi interfaces Why build prototypes? Tools for prototyping Widgets What prototyping tools lack
Adapted from slide by James Landay
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
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
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
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
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
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
Adapted from slide by James Landay
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
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
Adapted from slide by James Landay
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
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
Widgets
Buttons (several types)
Scroll bars and sliders
Pulldown menus
Adapted from slide by James Landay
What is Missing from a Prototyping Tool?
Support for the “insides” of applications
Adapted from slide by James Landay
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
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
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
Summary
UI tools good for testing more developed UI ideas
Two styles of tools– “Prototyping” vs. UI builders
Most ignore the “insides” of application