Brugergrænseflader til apparater BRGA

1. Brugergrænseflader til apparater BRGA Presentation 6: The Usability Engineering Lifecycle

2. Outline • When to apply? • Choosing the Software Engineering Process • User Involvement • Iterative design and prototyping • Design rationale • Meta-methods

3. When to Apply Usability Engineering

4. When to Apply Usability Engineering • Not a ”one shot affair” • Throughout entire product lifecycle • Tied to software engineering /development process • ROPES, RUP, SPU or Agile Methods, XP • Software engineering • = discipline concerning software design process / life cycle

5. The Importance of the “right” Software Engineering Process

6. Software Engineering Process • Why care about development methods? • Most engineering companies use development methods to construct their products • All usability work must therefore be situated in these • Badly employed method endangers product usability • Beck and Wells: existing methods do not work • Certainly there seems to be problems: • Products and projects developed for years –> • Only to arrive at the marked with unwanted features and bad user interfaces

7. Requirementsspecification Architecturaldesign Detaileddesign Coding andunit testing Integrationand testing Operation andmaintenance “The Waterfall Model” Origins: civil engineering Bridge building Need to secure delivery Specify everything! Does not always work well - In a software development perspective - Especially so in a usability perspective - Promotes building the product right – not the right product

8. Requirementsspecification Architecturaldesign Detaileddesign Coding andunit testing Integrationand testing Operation andmaintenance Design Fallbacks - Design fallbacks are one solution - Problems with interactive systems - Very expensive with long fallbacks - Users do not understand Use Cases or Class Diagrams and similar lots of feedback!

9. Iterative Rapid Development Proces Spiral model End target Start ROPES Iterations helps significantly on usability problems (Bohm 1988) But if not verified – then useless

10. XP – an Alternative • “XP is successful because it emphasizes customer involvement and promotes team work.” - Don Wells • XP: eXtreme Programming is primarily a software engineering method, but Agile Methods may be used everywhere • XP is too big of a topic for one lecture • Main points presented, focus on promoting usability • Its up to you if you wish to use this method

11. The Rules and Practices of Extreme Programming Coding • The customer is always available • Code must be written to agreed standards • Code the unit test first • All production code is pair programmed • Only one pair integrates code at a time • Integrate often • Use collective code ownership • Leave optimization till last • No overtime. Testing • All code must have unit tests • All code must pass all unit tests before it can be released • When a bug is found tests are created • Acceptance tests are run often Planning • User stories are written • Release planning creates the schedule • Make frequent small releases • The Project Velocity is measured • The project is divided into iterations.Iteration planning starts each iteration • Move people around • A stand-up meeting starts each day. • Fix XP when it breaks Designing • Simplicity • Choose a system metaphor • Use CRC cards for design sessions. • Create spike solutions to reduce risk. • No functionality is added early • Refactor whenever and wherever possible. Usability related issues have been highlighted

12. XP Project model

13. XP in Relation to Usability Methods Prototyping / mock-ups Keystroke Level Analysis Design Guidelines & Heuristics User tests Heuristic Evaluation Field studies Cognitive Walkthrough Future workshops Video prototyping

14. XP vs. Traditional Methods SPU/OOA-OOD • There is a reason for making requirement specifications • There is a reason for making legal contracts • Lack of trust between engineering company & customer only one • Need to control ”loose cannon” developers • Silverbullet & gold plating • Conflict between what the customer thinks he needs – and what he really needs (next time!) • HCI concludes user involvement is good – but expensive • Use XP and more trust instead of traditional methods

15. Iterative Design and Prototyping

16. Iterative Design and Prototyping • Iterative design overcomes inherent problems of incomplete requirements -> but only when used right • Prototypes is one way • most users have difficulties relating textual requirements to end products • get feedback on design faster • experiment with alternative designs / Nielsen: Parallel Design • fix problems before code is written • constructs the XP System Metaphor, developers & users • usage: simulate or animate some features of intended system • Management issues • time • planning • non-functional features • contracts

17. Techniques for prototyping Storyboards / Mock-ups prototypes with low fidelity (= precision) need not be computer-based – paper mock-ups Limited func simulations = scenarios One part of functionality provided by designers RAD tools may be used for these (Visual Studio) Most often mock-ups are ok Wizard of Oz technique Horisontal / Vertical advanced prototypes Depending on what needs to be tested RAD tools are common for these Throw-away, incremental, evolutionary

18. Low-fidelity prototyping

19. Fidelity in Prototyping • Fidelity refers to the level of detail • High fidelity • prototypes look like the final product • Low fidelity • artists renditions with many details missing

20. Why Use Low-fi Prototypes? • Traditional methods take too long • sketches -> prototype -> evaluate -> iterate • Can simulate the prototype • sketches -> evaluate -> iterate • sketches act as prototypes • designer “plays computer” • other design team members observe & record • Kindergarten implementation skills • allows non-programmers to participate

21. Nokia Uses Paper Prototyping Extensively

22. Advantages of Low-fi Prototyping • Take only a few hours • No expensive equipment needed • May use users (later) – may use Heuristic Evaluation / Cognitive Walkthrough with designers • Can test multiple alternatives • fast iterations • number of iterations are tied to final quality • Almost all interaction can be faked

23. Wizard of Oz Technique • Faking the interaction • from the film “The Wizard of OZ” • “the man behind the curtain” • Long tradition in computer industry • prototypes made of other equipment • Much more important for hard to implement features • Speech & handwriting recognition

24. High-fidelity Prototypes & RAD Tools

25. Problems with Low-fi Prototypes? • Doesn’t map well to what will actual fit on the screen • Realism low - cognitive load high (hard to draw) • Couldn’t hold in your hand - different ergonomics from intended device (PDA, speech) • Timing in real-time hard to do • Some things can not be simulated (dragging/highlight) • Lack of interactive feedback (affordances) • Solution: Build more advanced prototypes

26. RAD Development • Use RAD tools for Rapid Application Development Prototyping • PowerPoint, Word, HyperCard, Director, HTML-tools • JBuilder, Visual Studio (widgets) (for evolutionary) • Produces: • Horizontal / Vertical High-fidelity prototypes • Incremental & Evolutionary • Danger of ”it’s good enough” effect • User may sit next to the developer • Dangerous

27. Director Cast Flash / Shockwave • Basic objects used in interface • Mainly multimedia in nature • images, audio, video, etc. • synchronize with cue points • Can take screenshots and provide both simpel and advanced navigational transitions (”change something” when button is clicked)

28. Visual Studio – Pocket PC

29. Director or Visual Studio? • Prototyping tools • Director, Hypercard, PowerPoint, Frontpage • prototyping tools produce slow programs • May evolve to a certain degree – then throw away • IDE tools with UI Builders • Visual Studio, Delphi • Uses the standard Widgets available • May eventually evolve to full product (warning!) • May take a longer time to get started with • Better for developers – not good for designers

30. Widgets May not be available with embedded platform IDE’s

31. Design Rationale

32. Design Rationale Design rationale: information explaining why a user interface is the way it is. AKA – Styleguide or Designguide Benefits of design rationale • communication throughout lifecycle • reuse of design knowledge across products • enforces design discipline • presents arguments for design trade-offs • organizes potentially large design space • capturing contextual information • “one can always read the design rationale and understand why a certain path was chosen”

33. Meta-methods

34. Meta-methods • Decide on which methods to employ for your project • Make an illustrated plan of the usage (with some text) • Write down how you would like to use the methods. How many users, which user, how often • Get it reviewed

35. Læringsmåls alignment • Når kurset er færdigt forventes den studerende at kunne: • Definere og beskrive forskellige typer af brugergrænseflader til apparater og computere • Definere og beskrive gængse teorier, metoder og retningslinier indenfor menneske-maskin-interaktion og anvende disse til at lave en brugervenlig brugergrænseflade til et givet apparat • Designe og konstruere brugergrænsefladesoftware til udvalgte typer af brugergrænseflader Vi har fået en Forståelse af Hvordan Usability passer ind I hele processen. Vi har fået Prototyping Værktøjer