View
6
Download
0
Category
Preview:
Citation preview
Jan-14-05 © 1997-2005 by David A. Carr 1 L
INSTITUTIONEN FÖRSYSTEMTEKNIK
LULEÅ TEKNISKA UNIVERSITET
Introduction to Interactive Systems
SMD158
Interactive Systems
Spring 2005
Jan-14-05 © 1997-2005 by David A. Carr 2 L
Overview
• What is an interactive system?
• Software lifecycle
• Layers of an interactive system
• Interactive systems design
Jan-14-05 © 1997-2005 by David A. Carr 3 L
INSTITUTIONEN FÖRSYSTEMTEKNIK
LULEÅ TEKNISKA UNIVERSITET
What Is an Interactive System?
Jan-14-05 © 1997-2005 by David A. Carr 4 L
What is an Interactive System?
• Any system that accepts input from the user andprovides information as output to the user.
• Note,we will concentrate on window-based systems,but the vast majority of interactive systems are notwindow-based.
• Examples:- Microwave ovens - Mobil telephones
- Pocket calculators - Airliners
Jan-14-05 © 1997-2005 by David A. Carr 5 L
Two Points-of-View
• Interactive systems can be viewed from:- The user perspective,
- The system perspective
• This course will concentrate on the system point-of-view.
• However, the user point-of-view is still important.
Jan-14-05 © 1997-2005 by David A. Carr 6 L
Two Points-of-View
• To the user the system is:- A tool for accomplishing tasks
- Something that receives input
- And hopefully, displays output
- All too often, a source of frustration
• To the system the user is:- A source of asynchronous input
- An indirect target for output through various devices (display,speaker, lights, ...)
Jan-14-05 © 1997-2005 by David A. Carr 7 L
Ignoring the User
• Ignoring the user, can have serious consequences
• Examples:- The Pollack’s election documents and a poorly designed text
editor
- The Vincennes
Jan-14-05 © 1997-2005 by David A. Carr 8 L
INSTITUTIONEN FÖRSYSTEMTEKNIK
LULEÅ TEKNISKA UNIVERSITET
Software Life Cycle
Jan-14-05 © 1997-2005 by David A. Carr 9 L
The Software Engineering Life Cycle
• Six phases:- Requirements definition
- Specification
- Implementation
- Testing
- Installation
- Maintenance
• Always presented as a linear progression, but in realitythings are not so.
Jan-14-05 © 1997-2005 by David A. Carr 10 L
Requirements Definition
• Semi-formal description of the system• Specifies the properties and services that the system must
perform- Usually prioritized
• Often specifies the execution environment• Usually provided by the customer, but:
- The customer is not always the user- The customer does not always know exactly what is wanted- It usually changes during the development cycle
• The designer must resolve incomplete and/or conflictingrequirements
Jan-14-05 © 1997-2005 by David A. Carr 11 L
Specification
• Two phases, functional and internal
• Functional phase- Describes the functions that the system will have
- Divides them between the operator and the system
• Internal phase- Maps the functions to software
- Relates the functions to specific software components
- Defines: data structures, modules, algorithms, ...
Jan-14-05 © 1997-2005 by David A. Carr 12 L
Implementation & Testing
• Overlap
• Implementation- Development of components
- Integration (Very time consuming if the internal design is notdone well.)
• Testing- Module testing
- Systems testing
- Acceptance testing
Jan-14-05 © 1997-2005 by David A. Carr 13 L
Installation & Maintenance
• Students always escape these, but maintenance istypically more than half of the effort.
• Installation usually proceeds acceptance testing.
• Installation is time consuming and usually requiressignificant user support.
• Maintenance is usually the largest part of any system’slife.
• Revision follows the same SE model, although it ismaintenance.
Jan-14-05 © 1997-2005 by David A. Carr 14 L
The Spiral Model
Jan-14-05 © 1997-2005 by David A. Carr 15 L
Software Engineering and the User Interface
• Iterative design of the user interface tends to blendspecification, implementation, and testing.
• User involvement can result in changes to therequirements after they are “complete”.
• Failure to test early with real users can result in:- System failure
- An immediate demand for a new version
Jan-14-05 © 1997-2005 by David A. Carr 16 L
INSTITUTIONEN FÖRSYSTEMTEKNIK
LULEÅ TEKNISKA UNIVERSITET
Layers of an Interactive System
Jan-14-05 © 1997-2005 by David A. Carr 17 L
An Interactive Systems View of the Software
Functional Core Dialog Control
Interaction Objects Window System
Device Drivers
We concentrate
here
Jan-14-05 © 1997-2005 by David A. Carr 18 L
Functional Core
• A.k.a., the application, the backend
• Implements domain knowledge (e.g. IOGs)
• Logically separated from all user interface objects- Independent of input and output types (pen vs. keyboard, or
display vs. audio)
- But, still aware that there is a user
Jan-14-05 © 1997-2005 by David A. Carr 19 L
Dialog Control
• Controls sequencing
• Function availability at a specific time
• Interaction style (e.g., menu vs. command line)
Jan-14-05 © 1997-2005 by David A. Carr 20 L
Interaction Objects
• A.k.a. widgets, interactors
• Logical devices which the user manipulates with theinput devices
• Includes:- Presentation (output)
- Interaction (input)
- Miniature dialog (sequencing)
Jan-14-05 © 1997-2005 by David A. Carr 21 L
Window System & Device Drivers
• Window System- Interface between the interactors and the device drivers.
- Provides a logical device that hides machine dependentdetails.
- Provides for sharing of physical devices (e.g., mouse &display).
• Device Drivers- Map from an abstract device to a physical.
- Direct interface to the hardware.
Jan-14-05 © 1997-2005 by David A. Carr 22 L
This Is Only One Model
• Note, not everyone agrees that the functional core can beseparated from the interface.- Interaction often needs data that is in the functional core.
+ Runtime generated lists
+ Status of real-time equipment that is being monitored
+ User input while running IOGs in debug mode.
- Separation can lead to time lags between actions and events
+ E.g., mouse events winding up in the wrong window
Jan-14-05 © 1997-2005 by David A. Carr 23 L
INSTITUTIONEN FÖRSYSTEMTEKNIK
LULEÅ TEKNISKA UNIVERSITET
Interactive Systems Design
Jan-14-05 © 1997-2005 by David A. Carr 24 L
The Design Phases
• Remember the six phases of the software engineeringlife cycle :- Requirements definition
- Specification
- Implementation
- Testing
- Installation
- Maintenance
• Design encompasses the first two.
Jan-14-05 © 1997-2005 by David A. Carr 25 L
Another View of the Process
• Define the problem
• Model the operator
• Perform a task analysis
• Define computer objects and functions
• Design the appearance and behavior of the userinterface
• Evaluate the design
Jan-14-05 © 1997-2005 by David A. Carr 26 L
View Overlap
• Define the problem
• Model the operator
• Perform a task analysis
• Define objects and functions
• Design the user interface
• Evaluate
RequirementsAnalysis
FunctionalDesignInternal
Design
All
Jan-14-05 © 1997-2005 by David A. Carr 27 L
Define the Problem
• Begin with a one-sentence problem-statement.- This system will allow a systems developer to design widgets
using Interaction Object Graphs and edit the graphs on aworkstation.
• The statement should include four elements:- Performers of the activity, a.k.a. the users (system
developers)- Supported activity (widget design)- Form of solution (any workstation on the Internet)- Level of support (edit)
• Next, expand the four elements.
Jan-14-05 © 1997-2005 by David A. Carr 28 L
The Performers of the Activity
• Who are they?
• What is their training?
• Why are they going to use the new system?
• How are they doing things now?
• What general needs do they have?
• What specific needs do they have?
Jan-14-05 © 1997-2005 by David A. Carr 29 L
Usability Criteria
• Speed of performance
• Incidence of errors
• Recoverability from errors
• Speed of learning to use the system
• Retention of operation skill
• Flexibility of the system with respect to the users way of working
• Ease with which users can reorganize activities supported by thesystem
• User Satisfaction
Jan-14-05 © 1997-2005 by David A. Carr 30 L
Specific Needs
• Support for:- Logical correctness
- Readability
- Storage and retrieval
- Interface to other software
• Solutions?
Jan-14-05 © 1997-2005 by David A. Carr 31 L
Supported Activity
• What type of widget?- Needs further refinement
- State based?, continuous
• What level of editing?- Diagram itself
- Logical function
- Widget appearance?
• Interfaces to which systems?
Jan-14-05 © 1997-2005 by David A. Carr 32 L
Form of Solution
• Workstation- Java capable (applet or application?)
- Other requirements?
• Target environment?- Workstation itself
- Embedded devices
Jan-14-05 © 1997-2005 by David A. Carr 33 L
Level of Support
• Easy isn’t very descriptive.
• Better parameters- Accuracy
- Time to accomplish a task
- Few errors
- Quick discovery and recovery from errors
- Satisfaction
- Flexibility with different instruments
- Flexibility with different tasks
Jan-14-05 © 1997-2005 by David A. Carr 34 L
Model the Operators
• Remember the questions- Who are they?
- What is their training?
- Why are they going to use the new system?
- How are they doing things now?
- What general needs do they have?
- What specific needs do they have?
• How do we answer them?- Interviews
- Questionnaires
- Observation in the workplace
Jan-14-05 © 1997-2005 by David A. Carr 35 L
Perform a Task Analysis
• State broad tasks and decompose them
• Analyze the decomposition- Semantic inconsistencies
- Parallel tasks
- Identify special tasks
+ Frequent
+ Common
+ Complex
• Partition tasks between users and the system
Jan-14-05 © 1997-2005 by David A. Carr 36 L
Broad Tasks for the IOG Editor
• Operator Goals- Add and define states
- Connect states with arcs, define arcs
- Test IOG execution
- Save work
- Browse IOG
- Test IOG
- Create widget
Jan-14-05 © 1997-2005 by David A. Carr 37 L
Decomposition Add and Define States
• Select state type
• Place on work surface
• Insert state specific data- Name
- States for meta states
- Pictures for display states
- Annotations in standard states
Jan-14-05 © 1997-2005 by David A. Carr 38 L
Define Objects and Functions
• Make semantic objects in the functional corecorrespond to task objects- Each widget, state, arc, ...
• Implement syntax in the UI to facilitate taskaccomplishment- Multiple views
- Status indicators
• Define commands based on task decomposition
Jan-14-05 © 1997-2005 by David A. Carr 39 L
Define Objects and Functions
• Provide general services- Macros
- Undo/redo
- Cut/copy/paste
- On-line help
- Defaults
• Determine who controls the interaction- User or system
- Stress collaboration
Jan-14-05 © 1997-2005 by David A. Carr 40 L
Design the UI Details
• Interaction objects should map syntax to semantics
• Keep appearance and behavior consistent- Choose an appropriate metaphor
- Use a UI toolkit (Swing/Jazz)
• Use forms and menus- Specify actions
- Display units on forms
- Chose good defaults and display them
Jan-14-05 © 1997-2005 by David A. Carr 41 L
Design the UI Details
• Support semantic distance (making things distinct and separate)by using- prefix or postfix syntax
- precise and consistent naming
- consistent spatial layout
• Provide informative feedback- Show the interaction objects useful in a task context
- Indicate forbidden actions
- Display the current system mode (NO HIDDEN MODES!)
- Inform the operator of long response times
- Map movements of pointers on the screen
Jan-14-05 © 1997-2005 by David A. Carr 42 L
Evaluation
• Simulations
• Mock-ups
• Scenarios
• Test with a representative operator
Jan-14-05 © 1997-2005 by David A. Carr 43 L
Questions?
Recommended