CS427: Software Engineering I

1. CS427:Software Engineering I Darko Marinov (slides from Ralph Johnson)

2. Topics • Covered since midterm • Specification • Design • Quality assurance • Next • User interface design • Two more processes (besides XP and RUP) • Summary CS427

3. Homework 4 • Review work of another project • Pair with someone on your project • Swap reviews with a pair from a different project (TAs assigned, see Wiki) • Meet once to review their work • Meet once to review your own work CS427

4. To be reviewed • Select work to be reviewed • Should take two hour meeting to go over it • Give it to other pair to read in advance • One of you moderates the meeting, the other records • Not how it should be done • We do it this way to minimize work • Produce a report of all the issues that were raised CS427

5. To review • Make a check list of things to look for • Read the work, make comments • Evaluate according to check list • Meet and go over items you have found • How should the check list be improved? CS427

6. In real life • Usually there are several meetings until all issues are resolved • Project has a policy that determines what would be reviewed • “Passing review” is a measure of progress • Reviews improve checklists, not just the product under review CS427

7. User interface design • Important • Hard • Isn’t covered well by most software development processes CS427

8. When and who should do? • After data modeling? • Yes, for information systems • No, for video games • By a specialist? • Yes, for mass-market software • No, for in-house IS systems CS427

9. Design alternatives • Novice users • Menus • Make it look like something else • Simple • Expert users • Commands • Specialize to make users efficient • Powerful CS427

10. Design alternatives • Standard IO vs. new IO • Existing metaphors vs. new metaphors • Narrow market vs. broad market CS427

11. Principle • UI design is more like film-making than bridge-building • About communication • Requires understanding audience • Requires specialized skills • Requires iteration CS427

12. Book review • Joel Spolsky on UI Design for Programmers • Three chapters per lecture • Learned Helplessness • A user interface is well-designed when the program behaves … • Program model vs. User Model • User model is simple • Every time you provide an option, you are asking the user to make a decision CS427

13. Principle • UI design is more like film-making than bridge-building • About communication • Requires understanding audience • Requires specialized skills • Requires iteration CS427

14. Golden rules • Place the user in control • Reduce the user’s memory load • Be consistent CS427

15. Place the user in control • No modes (vim?) • Use a new window instead of a new mode • Make modes visible • Undo • Macros • Hide technical details • Direct manipulation CS427

16. Bad wizards CS427

17. Obtrusive assistance CS427

18. Non-obvious choices CS427

19. Reduce memory load • Reduce demand on short-term memory • Establish meaningful defaults • Define intuitive shortcuts • Disclose information progressively • Use real-world metaphors • Speak user’s language • Let user recognize, not remember CS427

20. Common techniques • Menus with keyboard shortcuts • Dialog boxes • Tabs • Toolbar CS427

21. Be consistent • Use visual interface standards • For operating system • For organization • For product or set of products • Show context - keep user from getting lost • System should explain itself CS427

22. Selection using scroll bar CS427

23. The UI design process User, task, and environment analysis Interface validation Implementation Interface design CS427

24. Models • Design model - what the designer thinks about the system • User model - what the user thinks about the system • System image - interface, manuals, training material, web site CS427

25. Reconciling models Pressman says: “The role of interface designer is to reconcile these differences and derive a consistent representation of the interface” CS427

26. Early phases • What are users like? • What do they think the system should be like? • What is a single, consistent, model of the system that can satisfy all the users? CS427

27. Later phases Design • What should system be like? • How can we make the users understand it? • For each aspect of the system, design the system image to match the desired user model Validation • Does user model match our goal? CS427

28. Task analysis and modeling What tasks will a user of the system perform? High level - why people use the system Low level - tasks involved in using the system CS427

29. Tasks and use cases • Use cases are high-level tasks • Decompose high-level ones into low-level ones • Find ones that are missing • Simplify by generalizing • UI design requires more detail than use case analysis usually provides CS427

30. Tasks • For each task: • Is it easy to start the task? • Is all the needed information easily accessible? • Is it easy to see what to do next? CS427

31. Low-level design • Map task into actions that can be directly implemented by standard widgets • Use consistent labels across tasks • Use consistent widgets across tasks CS427

32. User interface design • UI communicates with the user • Like any form of communication, • Needs feedback and iteration • There are standard ways of making a UI • Great UIs are rare and require creativity CS427

33. Next: More UI design • Read chapters 4-6 of the book on UI design for programmers http://www.joelonsoftware.com/uibook/chapters/fog0000000060.html CS427