Software Engineering Requirements

1
Software Engineering Requirements User
Interface Design

• Saint Michaels College
• Department of Computer Science
• Colchester, Vermont 05439
• http//personalweb.smcvt.edu/mbattig/

2
Part 1 UID Fundamentals

• USER, n. The word computer professionals use
  when they mean idiot. We need to avoid this
  mentality.
• I never design a building before Ive seen the
  site and met the people who will be using it.
  Frank Lloyd Wright

3
Introduction

• There are several areas of research that deal
  directly with User Interface Design. They are
• HCI/Human Factors and
• Usability Engineering.
• The HCI camp is more driven by research in
  psychology and therefore employs a heuristics
  approach. The UE camp is more driven by
  laboratory observation and has more of a
  validate verify each system approach. Lets
  discuss the tradeoffs with each approach

4
Usability Engineering

• Consider Jakob Nielsens book on Usability
  Engineering (google the title and read the first
  3 pages).
• Typical Usability Engineering Lab
  http//idealab.dis.unimelb.edu.au/
• The following material is adapted from
  http//www.useit.com/papers/guerrilla_hci.html

5
Discount Usability Engineering

• The "discount usability engineering" Nielsen
  1989b, 1990a, 1993 method is based on the use of
  the following three techniques
• Scenarios
• Simplified thinking aloud
• Heuristic evaluation
• Additionally, the basic principle of early focus
  on users should of course be followed. It can be
  achieved in various ways, including simple visits
  to customer locations

6
1 - Scenarios

• Scenarios are a special kind of prototyping as
  shown. The entire idea behind prototyping is to
  cut down on the complexity of implementation by
  eliminating parts of the full system. Horizontal
  prototypes reduce the level of functionality and
  result in a user interface surface layer, while
  vertical prototypes reduce the number of features
  and implement the full functionality of those
  chosen (i.e. we get a part of the system to play
  with).

7
2 Simplified Thinking Aloud

• Traditionally, thinking aloud studies are
  conducted with psychologists or user interface
  experts as experimenters who videotape the
  subjects and perform detailed protocol analysis.
  This kind of method certainly may seem
  intimidating for ordinary developers. However, it
  is possible to run user tests without
  sophisticated labs, simply by bringing in some
  real users, giving them some typical test tasks,
  and asking them to think out loud while they
  perform the tasks. Those developers who have used
  the thinking aloud method are happy about it
  Jørgensen 1989, Monk et al. 1993, and my
  studies Nielsen 1992b show that computer
  scientists are indeed able to apply the thinking
  aloud method effectively to evaluate user
  interfaces with a minimum of training, and that
  even fairly methodologically primitive
  experiments will succeed in finding many
  usability problems.

8
3 Heuristic Evaluation

• These are ten general principles for user
  interface design. They are called "heuristics"
  because they are more in the nature of rules of
  thumb than specific usability guidelines.
• Visibility of system status
• The system should always keep users informed
  about what is going on, through appropriate
  feedback within reasonable time.
• Match between system and the real world
• The system should speak the users' language, with
  words, phrases and concepts familiar to the user,
  rather than system-oriented terms. Follow
  real-world conventions, making information appear
  in a natural and logical order.
• User control and freedom
• Users often choose system functions by mistake
  and will need a clearly marked "emergency exit"
  to leave the unwanted state without having to go
  through an extended dialogue. Support undo and
  redo.
• Consistency and standards
• Users should not have to wonder whether different
  words, situations, or actions mean the same
  thing. Follow platform conventions.
• Error prevention
• Even better than good error messages is a careful
  design which prevents a problem from occurring in
  the first place. Either eliminate error-prone
  conditions or check for them and present users
  with a confirmation option before they commit to
  the action.
• Recognition rather than recall
• Minimize the user's memory load by making
  objects, actions, and options visible. The user
  should not have to remember information from one
  part of the dialogue to another. Instructions for
  use of the system should be visible or easily
  retrievable whenever appropriate.
• Flexibility and efficiency of use
• Accelerators -- unseen by the novice user -- may
  often speed up the interaction for the expert
  user such that the system can cater to both
  inexperienced and experienced users. Allow users
  to tailor frequent actions.
• Aesthetic and minimalist design
• Dialogues should not contain information which is
  irrelevant or rarely needed. Every extra unit of
  information in a dialogue competes with the
  relevant units of information and diminishes
  their relative visibility.
• Help users recognize, diagnose, and recover from
  errors
• Error messages should be expressed in plain
  language (no codes), precisely indicate the
  problem, and constructively suggest a solution.

9
HCI SIGCHI

• There is a SIG (Special Interest Group) of the
  ACM for HCI called SIGCHI.
• Definitions intro from SIGCHI
  http//sigchi.org/cdg/cdg2.html2_1

10
Three classes of Heuristics (1 of 3)

• Place User in Control
• Define interaction in such a way that the user is
  not forced into performing unnecessary or
  undesired actions
• Provide for flexible interaction (users have
  varying preferences)
• Allow user interaction to be interruptible and
  reversible
• Streamline interaction as skill level increases
  and allow customization of interaction
• Hide technical internals from the casual user
• Design for direct interaction with objects that
  appear on the screen

11
Three classes of Heuristics (2 of 3)

• Reduce User Memory Load
• Reduce demands on user's short-term memory
• Establish meaningful defaults
• Define intuitive short-cuts
• Visual layout of user interface should be based
  on a familiar real world metaphor
• Disclose information in a progressive fashion

12
Three classes of Heuristics (3 of 3)

• Make Interface Consistent
• Allow user to put the current task into a
  meaningful context
• Maintain consistency across a family of
  applications
• If past interaction models have created user
  expectations, do not make changes unless there is
  a good reason to do so

13
Know Thy User!

• Perhaps the most fundamental issue is to know the
  users experience, task, and environment. We can
  place the users experience on a continuum as
  follows
• Novice ? Intermittent User ? Expert
• This continuum can be used in at least two ways
  Computer experience and knowledge of the task
  domain.

14
User Interface Design Process (Spiral Model)

• User, task, and environment analysis and modeling
  
• Interface design
• Interface construction
• Interface validation

15
User Interface Design Process (Spiral Model)

• The above (macro) process, is broken down into
  the following interface design activities
  (micro)
• Establish the goals and intentions of each task
• Map each goal/intention to a sequence of specific
  actions (objects and methods for manipulating
  objects)
• Specify the action sequence of tasks and subtasks
  (user scenario)
• Indicate the state of the system at the time the
  user scenario is performed
• Define control mechanisms
• Show how control mechanisms affect the state of
  the system
• Indicate how the user interprets the state of the
  system from information provided through the
  interface

16
Additional Interface Design Issues

• System response time (time between the point at
  which user initiates some control action and the
  time when the system responds)
• User help facilities (integrated, context
  sensitive help versus add-on help)
• Error information handling (messages should be
  non-judgmental, describe problem precisely, and
  suggest valid solutions)
• Command labeling (based on user vocabulary,
  simple grammar, and have consistent rules for
  abbreviation)

17
Iterative Evaluation

• Once the User Interface is complete, we begin the
  Evaluation Cycle
• Preliminary design
• Build first interface prototype
• User evaluates interface
• Evaluation studied by designer
• Design modifications made
• Build next prototype
• If interface is not complete then go to step 3

18
Additional Resources

• Various Handouts
• Additional Readings
• Jakob Nielsen Usability Engineering (google
  usability engineering and read a few pages)
• Ben Shneiderman Designing the User Interface

19
Part 2 - Utilizing the PDA as a Vehicle for User
Interface Design Pedagogy
Note Please see the notes on slides 25 30 for
details about downloading the Simulator from
PalmOS and running the dynamic versions of the
.prc files (executables). For simplicity, you
may prefer to talk about the static versions of
the PDA interfaces, especially if you dont want
to go through the hassle of getting the Simulator
working.
20
Overview

• Goals for the Software Requirements
• Goals for User Interface Design
• Benefits of the PalmOS platform
• Sample Applications Development
  Products/Environments
• Assignment

21
Software Engineering Goals

• Learn the struggle of maintenance
• Learn new tools/platforms while
• Differentiating essential from accidental
• Learn importance of non-technical skills
• Work in a team environment
• Work with realistic project constraints

22
User Interface Design Goals

• Gain experience with prototyping
• Experience benefits of parallel design
• Consider the novice-expert continuum
• Incorporate heuristics for UID
• E.g., Reduce user memory load, direct
  manipulation where applicable, minimize user
  inputs, etc.
• Benefits of usability testing

23
A Sample Project

• Palm IIIc Basketball Stats Collection
• Collect team stats
• Collect player stats
• Usability tests during an actual NCAA Division II
  basketball game

24
Benefits of PalmOS

• Novel platform (a little gee-whiz factor)
• Unfamiliar development environment
• Inexpensive development environment
• Limited interface real estate (160 x 160)
• Stylus input forces efficiency
• Emulator provides cross-platform experience

25
Commercial App
palmsim61_dbg\PalmSim.exe NFL Football Scouting
Application Click this icon
26
Metrowerks CodeWarrior IDE

• Very reasonable academic pricing
• Intuitive interface debugger
• Palm platform requires C (the hardware/OS
  resources are too limited for a full Java
  run-time implementation)
• Palm OS Programming, 2nd Ed. from OReilly is
  very useful, with samples

27
Metrowerks CodeWarrior IDE

• Most of the applications contain linear code that
  is not terribly object-oriented (I.e., very
  little reuse)
• Constructor facility is helpful for GUI design
• Simulator Emulator software for windows
  available as free downloads from www.palmos.com

28
Sample Student Work 1

• Heavy memory load! Why?
• Efficiency is lacking for real basketball games.
  How do I determine home vs. visiting team? What
  do the abbreviations mean?

29
Sample Student Work 2

• Improved version
• Handles both teams on one screen
• Jersey number is button label
• Some run-time defects

30
Sample Student Work 3

• Improved usability
• View/change stats
• More robust
• Still room for improvementbut as good as many
  commercial apps!

Click the icon
31
Assignment

• Using the CS-SE Palm Requirements Specification
  assignment sheet (with accompanying Outline),
  develop a requirements specification with an
  appropriate User Interface Prototype.