1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 11 Usability 1

2 CS 501 Spring 2005 Course Adminstration Quiz 2 on Thursday Same format as the first quiz

3 CS 501 Spring 2005 Presentations Project Presentations First presentation is next week, Wednesday through Thursday (note change of date). Meeting room is at 301 College Avenue. For instructions, read the Assignments page. Schedule your presentation now!!!! Available time slots are on the Home page. Your client must attend the presentation unless you have special permission.

4 CS 501 Spring 2005 Planning for the Presentation How will you use the time? This is a presentation to the client, with the Instructor as a secondary audience. Possible topics: Overview of project and progress against plan Presentation of assumptions, decisions Summary of requirements in moderate detail What has been learned since feasibility study. Changes in plans Allow 15 minutes for questions. Expect interruptions. "This is our understanding of your requirements."

5 CS 501 Spring 2005 Planning for the Presentation Logistics Have a rehearsal, check visual aids and demonstrations. Then change nothing. Check out the equipment in the meeting room. What network will you use (if any). How will you connect a computer (if you do)? What about firewalls? Will one person act as chair and call on other members of the team? Never interrupt your colleagues. Not everybody is a great presenter, but everybody can be well-prepared.

6 CS 501 Spring 2005 Design Requirements Operation and Maintenance Implementation Design Feasibility and Planning Your understand the requirements, now to design the system.

7 CS 501 Spring 2005 What is Design? Design is conscious Design keeps human concerns in the center Design is a dialog with materials Design is creative Design is communication Design has social consequences Design is a social activity Terry Winograd Bringing Design to Software, 1996

8 CS 501 Spring 2005 Software Design The design phase is the most creative part of software development. The design must: Meet the requirements Satisfy the users Provide flexibility for changing requirements Be suitable for implementation with available resources Be testable and maintainable Fit within the style of the organization(s)

9 CS 501 Spring 2005 Reading Reading: Mitchell Kapor, A Software Design Manifesto. Dr. Dobbs Journal, kapor.html "Software design is not the same as user interface design." "Architects, not construction engineers, are the professionals who have overall responsibility for creating buildings.... in the actual process of designing and implementing the building, the engineers take direction from the architects."

10 CS 501 Spring 2005 Lectures on Design LecturesTopic 11-12Usability 13-14System Architecture 15-16Object Oriented Design 17-18Tools and Techniques

11 CS 501 Spring 2005 Design for Usability Usability of a computer system is a combination of factors: User interface design Functionality Performance Help systems and documentation Freedom from errors Anything else?

12 CS 501 Spring 2005 User Interface Design The user interface design is the appearance on the screen and the actual manipulation by the user (look and feel) Fonts, colors, logos, key board controls, menus, buttons Mouse control or keyboard control? Conventions (e.g., "back", "help")

13 CS 501 Spring 2005 Same Functions, Different Interface The user interface design is different from the functionality provided. Example 1: Microsoft Word on Windows and Macintosh: Different user interfaces for the same functionality. Example 2: The desk top metaphor Mouse -- 1 button (Macintosh), 2 button (Windows) or 3 button (Unix) Close button -- left of window (Macintosh) right of window (Windows)

14 CS 501 Spring 2005 User Interface Design Examples of change: 1990 to 2004

15 CS 501 Spring

16 CS 501 Spring

17 CS 501 Spring

18 CS 501 Spring

19 CS 501 Spring

20 CS 501 Spring

21 CS 501 Spring

22 CS 501 Spring

23 CS 501 Spring

24 CS 501 Spring 2005 User Interface Design: Requirements and Refinement It is very difficult to specify and comprehend an interactive interface in a textual documents. Requirement documents benefit from sketches, comparison with existing systems, etc. Design documents should definitely include graphical elements and often benefit from a mock-up or other form of prototype. Implementation plans should include evaluation of user factors and time to make changes. USER INTERFACES MUST BE TESTED WITH USERS

25 CS 501 Spring 2005 The Design/Evaluate Loop Evaluate ? Design Build Analyze requirements

26 CS 501 Spring 2005 Mock-up Example

27 CS 501 Spring 2005 Methods for Specifying Usability Requirements and Evaluation of Usability Initial Mock-upPrototypeProduction Client's opinions    Competitive analysis  Expert opinion   Focus groups   Observing users    Measurements  

28 CS 501 Spring 2005 Focus Group A focus group is a group interview Interviewer Potential users Typically 5 to 12 Similar characteristics (e.g., same viewpoint) Structured set of questions May show mock-ups Group discussions Repeated with contrasting user groups

29 CS 501 Spring 2005 Usability Laboratory Monitor users while they use system (or a prototype) Evaluators User one-way mirror

30 CS 501 Spring 2005 Usability Laboratory

31 CS 501 Spring 2005 Usability Laboratory Observing techniques Human observer Video camera Tape recording Study techniques Human protocol (user talks aloud while using system) User carries out specified list of tasks Software designer presents story board (mock-up) to user

32 CS 501 Spring 2005 Eye Tracking

33 CS 501 Spring 2005 Eye Tracking

34 CS 501 Spring 2005 Measurement Basic concept: log events in the users' interactions with a system Examples from a Web system Clicks (when, where on screen, etc.) Navigation (from page to page) Keystrokes (e.g., input typed on keyboard) Use of help system Errors May be used for statistical analysis or for detailed tracking of individual user.

35 CS 501 Spring 2005 Principles of Interface Design Interface design is partly an art; there are general principles: Consistency -- in appearance, controls, and function. Feedback -- what is the computer system is doing? why does the user see certain results? Users should be able to interrupt or reverse actions Error handling should be simple and easy to comprehend Skilled users offered shortcuts; beginners have simple, well-defined options The user should feel in control

36 CS 501 Spring 2005 Style of User Interfaces: Command Line Interfaces User interacts with computer by typing commands Allows complex instructions to be given to computer Facilitates formal methods of specification & implementation Skilled users can input commands quickly Requires learning or training Can be adapted for people with disabilities Can be multi-lingual Suitable for scripting / non-human clients

37 CS 501 Spring 2005 Style of User Interfaces: Direct Interaction User interacts with computer by manipulating objects on screen Can be intuitive and easy to learn Users get immediate feedback Not suitable for some complex interactions Does not require typing skills Straightforward for casual users, slow for skilled users Icons can be language-independent Difficult to build scripts Only suitable for human users

38 CS 501 Spring 2005 Design for Direct Manipulation metaphors and mental models: Conceptual models, metaphors, icons, but there may not be an intuitive model navigation rules: How to move among data functions, activities and roles in a large space conventions: Familiar aspects that do not need extra training. => scroll bars, buttons, help systems, sliders => good for users, good for designers look: characteristics of the appearance that convey information feel: interaction techniques that provide an appealing experience

39 CS 501 Spring 2005 Design for Direct Manipulation: Menus Easy for users to learn and use Certain categories of error are avoided Enables context-sensitive help Major difficulty is structure of large choices Scrolling menus (e.g., states of USA) Hierarchical Associated control panels Menus plus command line Users prefer broad and shallow to deep menu systems

40 CS 501 Spring

41 CS 501 Spring

42 CS 501 Spring 2005 Help System Design Help system design is difficult! Must prototype with mixed users Categories of help: => Overview and general information => Specific or context information => Tutorials (general) => Cook books and wizards => Emergency ("I am in trouble...") Must have many routes to same information Never blame the user! *