1 cs 501 spring 2002 cs 501: software engineering lecture 12 designing for usability ii

1 CS 501 Spring 2002

CS 501: Software Engineering

Lecture 12

Designing for Usability II


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 [email protected]


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.


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.


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


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.


User Interfaces: Iterative Design

Requirements

DesignImplementation

(prototype)

Evaluation


Methods for Specifying Requirements and Evaluation of Usability

• Observing users (user protocols)

• Focus groups

• Measurements effectiveness in carrying out tasksspeed

• Expert review

• Client's opinions

• Competitive analysis


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

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

NSDL: Design mock-ups

Show Carol Terrizzi's design mock-ups.

[End of NSDL example]

16 CS 501 Spring 2002

Information Presentation

Information to be displayed

Presentation software

Display

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

Extensibility in Web Browsers

• Data types: helper applications, plug-ins

• ProtocolsHTTP, WAIS, Gopher, FTP, etc.proxies

• Executable codeCGI scripts at serverJavaScript at clientJava applets

• Style sheets

25 CS 501 Spring 2002

Web Interface: Basic

Web serversWeb browser

• Static pages from server

• All interaction requires communication with server

26 CS 501 Spring 2002

Web User Interface: CGI Script

User interfacetables

CGIScripts


• Scripts can configure pages

• Scripts can validate information

• All interaction requires communication with server

27 CS 501 Spring 2002

Web User Interface: JavaScript

User interfacetables

CGIScripts


• JavaScripts can validate information as typed

• Some interactions are local

• Server interaction constrained by web protocols

JavaScript

html

28 CS 501 Spring 2002

Web User Interface: Applet

Any server


• Any executable code can run on client

• Client can connect to any server

Applets

29 CS 501 Spring 2002

Device-Aware User Interfaces

• Examples of devices:

desk-top computer, fast network connectionlaptop computer, intermittent connectivityPalmPilot, intermittent use of cradleSmart telephoneDigital camera, camcorder

• Device-aware user interfaces are aware of:

=> Performance of device=> Connectivity

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

1 cs 501 spring 2002 cs 501: software engineering lecture 12 designing for usability ii

Documents