INSTITUTIONEN FÖR SYSTEMTEKNIK LULEÅ TEKNISKA UNIVERSITET Introduction to Interactive Systems SMD158 Interactive Systems Spring 2005 Jan-14-05 1997-2005 by David A. Carr 1 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 2 L INSTITUTIONEN FÖR SYSTEMTEKNIK LULEÅ TEKNISKA UNIVERSITET What Is an Interactive System? Jan-14-05 1997-2005 by David A. Carr 3 L
What is an Interactive System? Any system that accepts input from the user and provides information as output to the user. Note,we will concentrate on window-based systems, but the vast majority of interactive systems are not window-based. Examples: - Microwave ovens - Mobil telephones - Pocket calculators - Airliners Jan-14-05 1997-2005 by David A. Carr 4 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-ofview. However, the user point-of-view is still important. Jan-14-05 1997-2005 by David A. Carr 5 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 6 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 7 L INSTITUTIONEN FÖR SYSTEMTEKNIK LULEÅ TEKNISKA UNIVERSITET Software Life Cycle Jan-14-05 1997-2005 by David A. Carr 8 L The Software Engineering Life Cycle Six phases: - Requirements definition - Specification - Implementation - Testing - Installation - Maintenance Always presented as a linear progression, but in reality things are not so. Jan-14-05 1997-2005 by David A. Carr 9 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 conflicting requirements Jan-14-05 1997-2005 by David A. Carr 10 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 11 L Implementation & Testing Overlap Implementation - Development of components - Integration (Very time consuming if the internal design is not done well.) Testing - Module testing - Systems testing - Acceptance testing Jan-14-05 1997-2005 by David A. Carr 12 L
Installation & Maintenance Students always escape these, but maintenance is typically more than half of the effort. Installation usually proceeds acceptance testing. Installation is time consuming and usually requires significant user support. Maintenance is usually the largest part of any system s life. Revision follows the same SE model, although it is maintenance. Jan-14-05 1997-2005 by David A. Carr 13 L The Spiral Model Jan-14-05 1997-2005 by David A. Carr 14 L Software Engineering and the User Interface Iterative design of the user interface tends to blend specification, implementation, and testing. User involvement can result in changes to the requirements 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 15 L
INSTITUTIONEN FÖR SYSTEMTEKNIK LULEÅ TEKNISKA UNIVERSITET Layers of an Interactive System Jan-14-05 1997-2005 by David A. Carr 16 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 17 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 18 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 19 L Interaction Objects A.k.a. widgets, interactors Logical devices which the user manipulates with the input devices Includes: - Presentation (output) - Interaction (input) - Miniature dialog (sequencing) Jan-14-05 1997-2005 by David A. Carr 20 L Window System & Device Drivers Window System - Interface between the interactors and the device drivers. - Provides a logical device that hides machine dependent details. - 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 21 L
This Is Only One Model Note, not everyone agrees that the functional core can be separated 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 22 L INSTITUTIONEN FÖR SYSTEMTEKNIK LULEÅ TEKNISKA UNIVERSITET Interactive Systems Design Jan-14-05 1997-2005 by David A. Carr 23 L The Design Phases Remember the six phases of the software engineering life cycle : - Requirements definition - Specification - Implementation - Testing - Installation - Maintenance Design encompasses the first two. Jan-14-05 1997-2005 by David A. Carr 24 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 user interface Evaluate the design Jan-14-05 1997-2005 by David A. Carr 25 L View Overlap Requirements Define the problem Analysis Model the operator Perform a task analysis Internal Define objects and functions Design Design the user interface Evaluate Functional Design All Jan-14-05 1997-2005 by David A. Carr 26 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 a workstation. 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 27 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 28 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 the system User Satisfaction Jan-14-05 1997-2005 by David A. Carr 29 L Support for: - Logical correctness - Readability - Storage and retrieval - Interface to other software Solutions? Specific Needs Jan-14-05 1997-2005 by David A. Carr 30 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 31 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 32 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 33 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 34 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 35 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 36 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 37 L Define Objects and Functions Make semantic objects in the functional core correspond to task objects - Each widget, state, arc,... Implement syntax in the UI to facilitate task accomplishment - Multiple views - Status indicators Define commands based on task decomposition Jan-14-05 1997-2005 by David A. Carr 38 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 39 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 40 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 41 L Evaluation Simulations Mock-ups Scenarios Test with a representative operator Jan-14-05 1997-2005 by David A. Carr 42 L
Questions? Jan-14-05 1997-2005 by David A. Carr 43 L