UI Development Process UI Development process n Like

UI Development Process

UI Development process n 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 2

UI development process n 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 FBut need to understand the vocab 3

Traditional SE process n The “Waterfall” model FNot typically advocated anymore, but terminology and biases remain • Requirements specification • Design • Coding and unit testing • Integration and testing • Operation and maintenance 4

Waterfall model n 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 5

Waterfall model n Implies that you design once (and get it right) – Not really possible for UI software 6

Waterfall model n 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 7

Requirements specification n 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? n Encode into a spec that drives the next phases 8

Requirements specification n 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 n Doesn’t mean you shouldn’t find out about user’s needs n 9

Design n Architectural design – high level decomposition – what are the big pieces, how do they fit together to form the whole n Detailed design – the littler boxes that go in the big boxes 10

Design UI design would be in detailed design + requirements (but iterated) n But, UI design doesn’t fit very well n this is mostly about system structure – UI design is mostly about what the user sees Foften without regard to the system structure that makes it happen – 11

Coding and unit testing n Actually write the code – typically the only part that you get graded on in school – only part you can’t skimp on Fwhere the rubber meets the road – tends to get a lot of attention n Test small scale parts (units) to ensure they function right 12

An aside on unit testing n My experience: the key to good programming is unit testing – All programmers create tons of bugs Fprogramming is just hard Frequires holding more details in your head than is humanly possible 13

Unit testing n Trick is to not avoiding bugs – helps, n But finding and fixing them before they get too hard to find – before n but at some level not possible “anybody finds out” This is what unit testing is for 14

Unit testing n 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 n Unit testing is really “Preemptive Debugging” n 15

Unit testing n 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 Fmore like square of difficulty Fthree cubes it, etc. – difficulty also grows non-linearly in area bug could be in 16

Unit testing n 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 17

Now back to our regularly scheduled lecture. . . 18

Integration and testing – Typically don’t build things in school big enough to hit this n Testing that when you put the pieces together they work – even if “units” work perfectly, whole may not 19

Testing parts n Systems testing – do n you think it works Verification – does n it match the spec Validation and acceptance testing – does it work to the customer – does it meet the contract / spec 20

Testing n Notice that all that testing is about testing of the system – “User n tests” are not really there When you user test you find out the requirements and/or design were wrong 21

Operation and maintenance n What happens after its delivered – the next release – bug fixes – new features 22

Waterfall model doesn’t work for UI software n UI requirements and design are very hard – too hard to get right on the first try – human beings are just too complex Fjust don’t know enough to do it from first principles – hidden mental models n Must iterate the design 23

User centered design § Put the needs of the user first and foremost § Etc… … Will leave this for Intro and other HCI classes 24

User-centered approach has been around for a long time n Catching on, but practices still don’t get followed as much as they should – increasing, n but not there yet Why? 25

Obstacles to user-centered iterative design n Big reason: Impractical – Iteration is expensive – Can barely afford to build it once Feven with high levels of resources – Dealing with this is one of the things this class is about – Good prototyping practice helps a lot 26

Obstacles to user-centered iterative design n 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 27

Obstacles to user-centered iterative design n Value of interactions with users is misestimated user diversity is underestimated F“I understand the users” – user diversity is overestimated F“I’ll never understand them all” F“Can’t get statistically significant info” – belief that users don’t know what they want (true, but…) – 28

Obstacles to user-centered iterative design n Difficult to manage, measure, and set goals – when will the software be done Fvery hard to estimate for software anyway Fopen-ended iteration makes it harder 29

Difficulty of measurement Dealing with users is hard n This is what Intro to HCI is all about n – “Programmers” don’t usually get taught these skills 30

Chicken and egg problem – Can’t afford to build it more than once – Can’t get it right the first time Fmust test and redesign, but can’t do that without building n Do we give up on iterative development? 31

Do we give up on iterative development? No n Build something less than the full system and iterate on that èPrototyping n 32

Prototyping techniques Build mockup & prototypes that allow you to see (some of; high order bits of) effects on real users n But which are cheap to build n Start very cheap (but less realistic) Fso you can afford major change F“get the high order bits” fast – Move to less cheap (more realistic) – 33

Aside: mockup vs. prototype n This is my terminology – not standardized, and not a firm line I use “mockup” for nonfunctional (low fidelity) n “Prototype” for functional / executable (closer to final form) n 34

Three dimensions of prototypes (and mockups) Scope n Fidelity n Maturation n n These are not fully independent 35

Scope n How much of the system is represented? – Often n can test just one aspect How much of the application functionality is behind the interface? 36

Fidelity n How closely does the mockup / prototype mimic the final system – Major issue: is the artifact executable and can it be “run” by the users Fbig increase in both fidelity and cost 37

Another aspect of fidelity: representation n What form is the design represented in? – does it match the physical form? – examples: pencil and paper (static images) vs. storyboard vs. computerized 38

Maturation n 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 39

“Vertical” vs. “Horizontal” prototypes n Scope vs. fidelity tradeoffs – Vertical: go deep in a few critical areas (limited simulation of rest) FHigh fidelity within limited scope – Horizontal: wide coverage but limited fidelity FLow fidelity with larger scope – Often use some of each 40

Some specific prototyping techniques n (Simple) storyboards – sketches (on paper or screen) that indicate how things look across a scenario Fno user interaction at all Fbut still get an idea of what it might be like (and can get users involved) – Low fidelity, low cost (use early) 41

Some specific prototyping techniques n Extended storyboards – Can sketch out multiple interactive paths on paper Ftypically user points at things on paper, you flip to prepared sheets showing how things would change Fcan do part of interface separately – Again, low cost / early 42

Some specific prototyping techniques n Wizard of OZ studies “Pay no attention to the man behind the curtain” – Replace machine actions with “the man behind the curtain” Fhuman listens / watches user, then types, pushes buttons 43

Some specific prototyping techniques n Wizard of OZ studies – Most useful for things that don’t exist yet Ffind out what the big issue with them will be while they can be changed Fdon’t wait till slow item is done to design (& iterate!) interface – Fidelity issues (particularly timing) 44

Some specific prototyping techniques n Limited functionality and/or scope executable prototypes – actual running interface of some sort Fe. g. Visual Basic prototype – more costly, but more fidelity Flater in process 45

Some specific prototyping techniques n Fully functional prototypes that can evolve into the real product – highest level of maturity – can do full user testing – high fidelity, high cost Flast stage of prototyping 46

Warnings about iterative design n Big picture first – Its easy to get bogged down in details and miss the forest for the trees Fe. g. , layout, color, etc. – Get the “high order bits first” Fis the right functionality? Fis this conceptual model going to work for the user? 47

Warnings about iterative design n Beware of delivering (what was supposed to be) the prototype –a lot of pressure to deliver the first thing that looks like it works Fcan get you in big trouble later Fneed to make sure everyone knows this is a prototype – often want to make things look “sketchy” early on to avoid this 48

Warnings about iterative design n Design inertia – First designs have a huge impact Fevolutionary process & like biological evolution can be hard to back out of decisions – Need to be willing to make radical changes when maturity is low Fwhy is needs to be low cost early – Explicitly consider several designs 49

Warnings about iterative design n Need to understand reasons behind usability problems – When “feature X” causes usability problems the simple thing is to eliminate X Fbut if we don’t understand it, we may make same mistake again, and/or make things worse 50

51