ui development process. 2 ui development process n like ui design, this is just once over lightly...
TRANSCRIPT
UI Development Process
2
UI Development process
Like UI design, this is just once over lightly with HCI/UI SW spin– just enough to raise your awareness– not what this course is about, but
important issues
3
UI development process
Software engineering has developed quite a bit of process for software development– The bad news is that a lot of it does
not work well for UI software– Traditional SE approaches are a
flaming disasterBut need to understand the vocab
4
Traditional SE process
The “Waterfall” modelNot typically advocated anymore, but terminology and biases remain
• Requirements specification • Design
• Coding and unit testing • Integration and testing • Operation and
maintenance
5
Waterfall model
Called “waterfall” model because when you finish one phase you are not supposed to go back “up stream”
Requirements specification Design
Coding and unit testing Integration and testing Operation and maintenance
6
Waterfall model
Implies that you design once (and get it right)– Not really possible for UI software
7
Waterfall model
Obsolete, but many of the parts remain in almost any SW process– Biases from this traditional approach
remain– Also beware that terminology like
“testing” doesn’t necessarily match what we typically mean in HCI
8
Requirements specification
What will the system do?– What does it need to do to meet the
customer’s (user’s) needs?– What does the customer (user) want?
Encode into a spec that drives the next phases
9
Requirements specification
Requirements analysis is very hard in practice – user’s can’t tell you what they need
Writing down a requirements spec is not realistic in UI design
Doesn’t mean you shouldn’t find out about user’s needs
10
Design
Architectural design – high level decomposition– what are the big pieces, how do they
fit together to form the whole Detailed design
– the littler boxes that go in the big boxes
11
Design UI design would be in detailed
design + requirements (but iterated) But, UI design doesn’t fit very well
– this is mostly about system structure– UI design is mostly about what the user
sees often without regard to the system
structure that makes it happen
12
Coding and unit testing
Actually write the code– typically the only part that you get
graded on in school– only part you can’t skimp on
where the rubber meets the road– tends to get a lot of attention
Test small scale parts (units) to ensure they function right
13
An aside on unit testing
My experience: the key to good programming is unit testing– All programmers create tons of bugs
programming is just hardrequires holding more details in your head than is humanly possible
14
Unit testing
Trick is to not avoiding bugs – helps, but at some level not possible
But finding and fixing them before they get too hard to find– before “anybody finds out”
This is what unit testing is for
15
Unit testing
In reality you don’t spend your time writing programs– once you get the hang of it its
tedious, but not that hard You spend your time debugging Unit testing is really “Preemptive
Debugging”
16
Unit testing
Has to do with combinatorics– one bug in a small area of code is
typically reasonably easy to find– two (interacting) bugs not just double
more like square of difficultythree cubes it, etc.
– difficulty also grows non-linearly in area bug could be in
17
Unit testing
Key is to test in small enough chunks that you are likely to have at most one bug – may be very small chunks
– if there is one lesson I would give about programming, this is it
18
Now back to our regularly scheduled lecture...
19
Integration and testing
– Typically don’t build things in school big enough to hit this
Testing that when you put the pieces together they work– even if “units” work perfectly, whole
may not
20
Testing parts
Systems testing– do you think it works
Verification– does it match the spec
Validation and acceptance testing– does it work to the customer– does it meet the contract / spec
21
Testing
Notice that all that testing is about testing of the system– “User tests” are not really there
When you user test you find out the requirements and/or design were wrong
22
Operation and maintenance
What happens after its delivered– the next release– bug fixes– new features
23
Waterfall model doesn’t work for UI software UI requirements and design are
very hard– too hard to get right on the first try– human beings are just too complex
just don’t know enough to do it from first principles
– hidden mental models Must iterate the design
24
User centered design
Put the needs of the user first and foremost
Etc… … Will leave this for Intro and other
HCI classes
25
User-centered approach has been around for a long time Catching on, but practices still
don’t get followed as much as they should– increasing, but not there yet
Why?
26
Obstacles to user-centered iterative design Big reason: Impractical
– Iteration is expensive– Can barely afford to build it once
even with high levels of resources– Dealing with this is one of the things
this class is about– Good prototyping practice helps a lot
27
Obstacles to user-centered iterative design Competing approaches
– the power or reason and “getting it right the first time”
– CS typically teaches that you can (and should) get your design right
28
Obstacles to user-centered iterative design Value of interactions with users is
misestimated– user diversity is underestimated
“I understand the users”– user diversity is overestimated
“I’ll never understand them all”“Can’t get statistically significant info”
– belief that users don’t know what they want (true, but…)
29
Obstacles to user-centered iterative design Difficult to manage, measure,
and set goals– when will the software be done
very hard to estimate for software anyway
open-ended iteration makes it harder
30
Difficulty of measurement
Dealing with users is hard This is what Intro to HCI is all
about– “Programmers” don’t usually get
taught these skills
31
Chicken and egg problem
– Can’t afford to build it more than once– Can’t get it right the first time
must test and redesign, but can’t do that without building
Do we give up on iterative development?
32
Do we give up on iterative development? No Build something less than the
full system and iterate on that Prototyping
33
Prototyping techniques
Build mockup & prototypes that allow you to see (some of; high order bits of) effects on real users
But which are cheap to build– Start very cheap (but less realistic)
so you can afford major change“get the high order bits” fast
– Move to less cheap (more realistic)
34
Aside: mockup vs. prototype
This is my terminology – not standardized, and not a firm line
I use “mockup” for non-functional (low fidelity)
“Prototype” for functional / executable (closer to final form)
35
Three dimensions of prototypes (and mockups) Scope Fidelity Maturation
These are not fully independent
36
Scope
How much of the system is represented?– Often can test just one aspect
How much of the application functionality is behind the interface?
37
Fidelity
How closely does the mockup / prototype mimic the final system– Major issue: is the artifact executable
and can it be “run” by the usersbig increase in both fidelity and cost
38
Another aspect of fidelity: representation What form is the design
represented in?– does it match the physical form?– examples: pencil and paper (static
images) vs. storyboard vs. computerized
39
Maturation
How close is this to the final design?– Need to stay flexible (and hence low
cost) early– Typically want to increase both scope
and fidelity as we mature– Concentrate on “big issues” early &
work on details once those are right
40
“Vertical” vs. “Horizontal” prototypes Scope vs. fidelity tradeoffs
– Vertical: go deep in a few critical areas (limited simulation of rest)High fidelity within limited scope
– Horizontal: wide coverage but limited fidelityLow fidelity with larger scope
– Often use some of each
41
Some specific prototyping techniques (Simple) storyboards
– sketches (on paper or screen) that indicate how things look across a scenariono user interaction at allbut still get an idea of what it might be like (and can get users involved)
– Low fidelity, low cost (use early)
42
Some specific prototyping techniques Extended storyboards
– Can sketch out multiple interactive paths on papertypically user points at things on paper, you flip to prepared sheets showing how things would change
can do part of interface separately– Again, low cost / early
43
Some specific prototyping techniques Wizard of OZ studies“Pay no attention to the man behind the curtain”
– Replace machine actions with “the man behind the curtain”human listens / watches user, then types, pushes buttons
44
Some specific prototyping techniques Wizard of OZ studies
– Most useful for things that don’t exist yetfind out what the big issue with them will be while they can be changed
don’t wait till slow item is done to design (& iterate!) interface
– Fidelity issues (particularly timing)
45
Some specific prototyping techniques Limited functionality and/or
scope executable prototypes– actual running interface of some sort
e.g. Visual Basic prototype– more costly, but more fidelity
later in process
46
Some specific prototyping techniques Fully functional prototypes that
can evolve into the real product– highest level of maturity– can do full user testing– high fidelity, high cost
last stage of prototyping
47
Warnings about iterative design
Big picture first– Its easy to get bogged down in details
and miss the forest for the treese.g., layout, color, etc.
– Get the “high order bits first”is this the right functionality?is this conceptual model going to work for the user?
48
Warnings about iterative design
Beware of delivering (what was supposed to be) the prototype– a lot of pressure to deliver the first
thing that looks like it workscan get you in big trouble laterneed to make sure everyone knows this is a prototype
– often want to make things look “sketchy” early on to avoid this
49
Warnings about iterative design Design inertia
– First designs have a huge impactevolutionary process & like biological evolution can be hard to back out of decisions
– Need to be willing to make radical changes when maturity is lowwhy is needs to be low cost early
– Explicitly consider several designs
50
Warnings about iterative design
Need to understand reasons behind usability problems– When “feature X” causes usability
problems the simple thing is to eliminate Xbut if we don’t understand it, we may make same mistake again, and/or make things worse
51