1. 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 12 Designing for Usability II

2. 2 CS 501 Spring 2002 Administration Requirements document An example will be discussed in class See also the web site associated with the text book Assignment 2 Questionnaire Everybody should reply Email to wya@cs.cornell.edu

3. 3 CS 501 Spring 2002 Planning for the Presentation 1.Who is the audience? What do they want to learn? The client(s): Do you understand their requirements? Is this the system that they want? 2.How much time do you have? How much detail can you cover? 45 minutes for set-up, presentation and discussion. Prepare 30 minutes presentation. Do nor be superficial but there is not time to go into all details.

4. 4 CS 501 Spring 2002 Planning for the Presentation 3.What facilities are in the room? Computer projector, Ethernet, conference telephone, screen, overhead projector, whiteboards. 4.What materials should you prepare? Report -- either hand out paper copies or distribute by email. Slides for computer projection (PowerPoint, web, or similar) or overhead foils. Bring a laptop if you have one. Otherwise, let your TA know if you will need a computer or other equipment.

5. 5 CS 501 Spring 2002 The Presentation 5.Speakers Either have one person act as moderator or hand off sequentially, one speaker at a time. 6.Questions The speaker should decide who answers questions. Do not interrupt the speaker. If you think that you can answer a question, raise your hand and wait for the speaker to ask you. Have a full rehearsal of your presentation

6. 6 CS 501 Spring 2002 Usability: 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.

7. 7 CS 501 Spring 2002 User Interfaces: Iterative Design Requirements Design Implementation (prototype) Evaluation

8. 8 CS 501 Spring 2002 Methods for Specifying Requirements and Evaluation of Usability Observing users (user protocols) Focus groups Measurements effectiveness in carrying out tasks speed Expert review Client's opinions Competitive analysis

9. 9 CS 501 Spring 2002 Example: the NSDL The National Science Digital Library (NSDL) A major program of the National Science Foundation (NSF). Comprehensive digital library of all materials relevant to science education, broadly defined. $25 million per year for 6 years. 64 grants to universities and other not-for-profit universities. Technical leadership from Cornell.

10. 10 CS 501 Spring 2002 NSDL: the Start First thoughts Users of the NSDL will be very diverse: K-12, university, adults; students and teachers. Very high variations in computers and networks available to users. Volume of material prohibits designing every screen individually. Interface creation will be a major part of the project.

11. 11 CS 501 Spring 2002 NSDL: Getting Started Strategy Hire a senior interface designer During the first year (2000-2001), build a throw- away demonstration system http://www.siteforscience.org/ Then move to a systematic software development process

12. 12 CS 501 Spring 2002

13. 13 CS 501 Spring 2002 NSDL: The Demonstration System What we learned: User requirements Because of the diversity of users, more than one portal is needed "One library, many portals" Technical requirements Portals must be data driven: experiments with RSS channels Interface components and graphical elements will be used in many different places

14. 14 CS 501 Spring 2002 NSDL: The Requirements Process During winter 2002... Informal meetings to discuss design concepts, e.g., review methods other systems use to display search results Prepared a series of documents on (a) system requirements, e.g., hardware/software, users with disabilities (b) functional requirements Technical review and small pilots of portal toolkit software Mock-ups of graphical design http://portals.comm.nsdlib.org/cgi-bin/wiki.pl?User_Interface_and_Portals

15. 15 CS 501 Spring 2002 NSDL: Design mock-ups Show Carol Terrizzi's design mock-ups. [End of NSDL example]

16. 16 CS 501 Spring 2002 Information Presentation Information to be displayed Presentation software Display

17. 17 CS 501 Spring 2002 Information Presentation Text precise, unambiguous fast to compute and transmit Graphics simple to comprehend uses of color shows variations

18. 18 CS 501 Spring 2002 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

19. 19 CS 501 Spring 2002 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

20. 20 CS 501 Spring 2002 Design for Direct Manipulation Conceptual models, metaphors, icons => there may not be an intuitive model Navigation around large space Conventions are growing over the years => scroll bars, buttons, help systems, sliders => good for users, good for designers

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

22. 22 CS 501 Spring 2002 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!

23. 23 CS 501 Spring 2002 System Considerations of User Interfaces Personal computer cycles are there to be used Any network transfer involves delay Shared systems have unpredictable performance Data validation often requires access to shared data Mobile code poses security risks

24. 24 CS 501 Spring 2002 Extensibility in Web Browsers Data types: helper applications, plug-ins Protocols HTTP, WAIS, Gopher, FTP, etc. proxies Executable code CGI scripts at server JavaScript at client Java applets Style sheets

25. 25 CS 501 Spring 2002 Web Interface: Basic Web servers Web browser Static pages from server All interaction requires communication with server

26. 26 CS 501 Spring 2002 Web User Interface: CGI Script User interface tables CGI Scripts Web servers Web browser Scripts can configure pages Scripts can validate information All interaction requires communication with server

27. 27 CS 501 Spring 2002 Web User Interface: JavaScript User interface tables CGI Scripts Web servers Web browser JavaScripts can validate information as typed Some interactions are local Server interaction constrained by web protocols Java Script html

28. 28 CS 501 Spring 2002 Web User Interface: Applet Any server Web servers Web browser Any executable code can run on client Client can connect to any server Applets

29. 29 CS 501 Spring 2002 Device-Aware User Interfaces Examples of devices: desk-top computer, fast network connection laptop computer, intermittent connectivity PalmPilot, intermittent use of cradle Smart telephone Digital camera, camcorder Device-aware user interfaces are aware of: => Performance of device => Connectivity

30. 30 CS 501 Spring 2002 The Importance of Design Good support for users is more than a cosmetic flourish Elegant design, appropriate functionality, & responsive system: => a measurable difference to their effectiveness A system that is hard to use: => users may fail to find important results, or mis-interpret what they do find => user may give up in disgust A computer system is only as good as the interface it provides to its users