SY DE 542 Interface Design

1. SY DE 542Interface Design Course Overview Introduction to Work Domain Analysis Jan. 10, 2005 R. Chow Email: chow@mie.utoronto.ca

2. Course Materials • Text: Burns & Hajdukiewicz (2004). Ecological Interface Design. Taylor and Francis, UK. • Website: www.eng.uwaterloo.ca/~sd542 - lecture schedule and full description of deliverables - lecture slides (available after each lecture) - email address for all electronic submissions

3. What to expect • Design of computer displays • Focus on cognitive human factors • From analysis to design • Hands-on approach

4. What not to expect • An Introduction to Human Factors / Ergonomics • A course in Human-Computer Interaction • Design, not Critique / Testing • System Analysis, not Rules-of-Thumb • A course in Web Design • Complex, dynamic, safety-critical systems • A course in Theory • Examples + Exercises & Project, No Exam • A course in Programming • Prototype as a demonstration & testing tool • A course in “conventional” Graphics Design • Usefulness, Not Aesthetics

5. Deliverables • No midterm, No final exam • ONE design project! • 5 project checkpoints (1-page each) – 5 x 5 % • Report 1: Design Prototype & Description • Due on March 7, worth 40% • Report 2: User Testing & Design Recommendations • Due on March 28, worth 20% • Presentation: as scheduled, worth 15% • Electronic submission ONLY for all reports • All deliverables due by 1:30 pm, late penalties

6. Project Checkpoints • Jan.17: Project Proposal • What is target system? • Jan.24: Work Domain Analysis • What information is needed to use (i.e., monitor and control) the system? • Jan.31: Information Availability Analysis • What information is available? What information needs to be derived? How? • Feb. 7: Phase 2 Design Sketch • How are main variables and context shown? • Feb. 14: Phase 3 Design Sketch • How are variables integrated?

7. Lecture Schedule (approx.) • Jan.10: Intro to Work Domain Analysis (WDA) (Ch.1, Ch.2 – 1st half) • Jan 17: More advanced WDA, Info Requirements (Ch.2 – 2nd half, Ch. 4) • Jan.24: Analog/Digital Representations, Design Phase 1: Basic Design of Info Req’ts (Ch.3 – 1st half, Ch.4) • Jan.31 Context and Salience, Design Phase 2: Single Variable Constraints (Ch. 3, 4) Visit website for full lecture schedule …

8. Why Interface Design? • Game of 15 • Rules: • Two players take turns choosing numbers • Choose from the numbers 1 to 9 • Cannot choose number already chosen by opponent • First to collect 3 numbers that add up to 15 wins • A draw is possible: All numbers chosen, but neither player has a set of 3 numbers that add up to 15)

9. Game of 15 • Why does Player A usually win? • Which number is the “best option”? • Which numbers are “second best”? • Tic-tac-toe board highlights: • Opportunities (ways to win) • Constraints (ways to block, dead paths) • Overall purpose (a line in any direction) • Tic-tac-toe board minimizes need for real-time computation (cognitively challenging / taxing) • Tic-tac-toe board supports learning

10. Interface Design • Interface design can shape performance • By making the same problem easier or harder • Interface design can impact productivity • Achieve purpose • Achieve purpose quickly and easily • Interface design can impact safety • Prevent errors • Appreciate potential impact of errors • A good interface is a transparent interface • Maintain focus on target system (purpose, opportunities, constraints), rather than on the interface (recording, computing)

11. Interface Design Challenges • Deciding what information is needed. • Making the display of that information as easy as possible.

12. User Centred Design • Start with the user (Interviews, Observations) • Who are the users? • What are user’s needs? limitations? preferences? • What are user’s tasks? Which are important? frequent? difficult? • Focus on these key tasks • What are the users’ mental models? • Reflect these mental models • Good candidates for UCD: • Websites: e.g., Expedia, U of Waterloo, … • Office applications: e.g., Word, Excel, Powerpoint

13. Asking the User – Why not? Consider a nuclear power plant … • Users may have incomplete / inaccurate understanding (esp. with large, complex systems) • Users may give inconsistent answers (esp. different training, experience, roles) • System dynamics do not necessarily conform to what users believe or prefer! Therefore: Start by understanding SYSTEM; Then, ask users.

14. Task Analysis • What are the sub-tasks? steps? • What info is needed to perform each step? • What feedback is needed after each step? Often used for websites / office systems Also used for nuclear power plants …

15. Pizza Delivery Example • How should manager show new delivery person where to make first delivery?

16. Option 1: Set of directions • Easy to write • Based on own / other’s experience (ask the user) • Easy to follow • Start immediately, no training required • Step-by-step, no thinking required

17. Option 2: Map • Harder to draw • Based on thorough understanding of the geographic area (i.e., the “system”) • roads, landmarks • relationships (intersecting, parallel, beside, across) • “you-are-here” and “destination” markers • Harder to follow • Need familiarization • Need to develop and follow own route

18. Directions vs. Map • What if there is a road closure? • What if there is a second order elsewhere? • What if there are many orders tomorrow? • What if you hire another delivery person? How many sets of directions are needed? How many maps?

19. Task vs. Work Domain Analysis • Maps • Can be used in Unanticipated Events (e.g., road closures, traffic jams) • Can support Fault Compensation (e.g., find an alternate route) • Can support Learning (e.g. alternate routes, preferred routes, new routes) • Can support Full Variety of Activities (e.g., new orders, new assignments) • Directions <-> Task Analysis • Maps <-> Work Domain Analysis

20. Work Domain Analysis:Target Systems • Dynamic • Complex (large number of components and connections; different means to end) • Real-time Operation • Safety-Critical • High Social and/or Economic Value • Problem-Solving • Expertise: Needed and Expected

21. Best Case Scenario • Maps + Directions (Work Domain + Task Analyses) • Given limited time for analysis, choose higher-value approach based on system • For complex systems, use WDA (subject of this course) • Consider supplementing with TA (tentative subject of guest lecture)

22. Intro to Work Domain Analysis • Work Domain = System controlled by User • Systems are designed for a purpose • Parts and components are designed to achieve the purpose • Key questions in a WDA: • WHY was the system designed? (Purpose) • HOW does the system achieve its purpose

23. Abstraction Hierarchy (AH) • A functional decomposition of the system into multiple levels • DOWN: • HOW does the system achieve its purpose? • HOW does the sub-system / a component achieve its purpose? • UP: • WHY was system designed? • WHY was the sub-system / component designed?

24. How How Why Why Abstraction Hierarchy: Examples Warmth Fireplace Heater Dinner Home-Cooking Frozen Entree Takeout

25. Why Abstraction Hierarchy? During Anomaly Response: • Detection & Diagnosis • Purpose is not achieved. What may be broken? (going down the AH) • Compensation • Purpose is not achieved. What are other options? (going down and across AH)

26. Abstraction Hierarchy (cont’d) Restaurant School Walk Drive Bus Also, during Anomaly Response: • Replanning • Component is broken. What purpose(s) could be threatened? (going up and down AH)

27. Other Hierarchies Dinner Soup Salad Pasta Pastry Mammal President Dog Cat VP Finance VP Operations (classification) (authority) Is-part-of Has-a

28. Abstraction Hierarchyfor a Complex System • 5 levels • Levels are defined by WHY and HOW • Highest levels oriented towards designed purpose • Lowest levels oriented towards physical components • Each level is a complete, but unique description of the system

29. Levels in the AH • Functional Purpose: designed for purpose • Abstract Function: first principles • Generalized Function: processes • Physical Function: components and behaviour • Physical Form: condition, location and appearance of components.

30. DURESS Example • DUal REservoir System Simulation (Vicente, 1991; Vicente 1999)

31. Functional Purpose • Ask “why was the system designed?” • “What is it intended to do” • “When is it working correctly”

32. Abstract Function • First principles description • Basic laws - conservation laws • Look for things that must be conserved, things that move or flow • Mass, Energy, Resources, Information, Money

33. Generalized Function • Process Description • Look for “physics”, “process variables” • Describes “how it works” • More defined description of the system • Egs. Water flow, electrical heating, combustion, signal propagation

34. Physical Function • Look at the components in the system • Describe their capabilities • Capabilities: how much? how many? how fast? how far? how long? • Search for limits on performance.

35. Physical Form • Look at components • Describe appearance, location, condition, type of material, size, shape.

36. Exercise • Develop a preliminary AH for DURESS

37. Project Proposal: Choosing your system • Characteristics listed on Slide 20 • Data-intensive • Need for monitoring • Need for decision-making, problem-solving • Need for some expertise • Do you have expertise? • Do you have access to expertise? Reminder: Proposal (200 words) due NEXT Monday