UI Development Process

1
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 disaster
• But need to understand the vocab

4
Traditional SE process

• The Waterfall model
• Not 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

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
  doesnt 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 customers
  (users) 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
• users cant tell you what they need
• Writing down a requirements spec is not realistic
  in UI design
• Doesnt mean you shouldnt find out about users
  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 doesnt 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 cant 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 hard
• requires 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 dont 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 difficulty
• three 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 dont 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 doesnt 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 dont 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 dont 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
• Ill never understand them all
• Cant get statistically significant info
• belief that users dont 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 dont usually get taught these
  skills

31
Chicken and egg problem

• Cant afford to build it more than once
• Cant get it right the first time
• must test and redesign, but cant 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 users
• big 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 fidelity
• Low 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 scenario
• no user interaction at all
• but 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
  paper
• typically 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 dont exist yet
• find out what the big issue with them will be
  while they can be changed
• dont 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 trees
• e.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 works
• can get you in big trouble later
• need 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 impact
• evolutionary process like biological evolution
  can be hard to back out of decisions
• Need to be willing to make radical changes when
  maturity is low
• why 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 X
• but if we dont understand it, we may make same
  mistake again, and/or make things worse

51
(No Transcript)