Software Engineering: Analysis and Design - CSE3308 Conceptual Issues in Human-Computer Interaction
Download ReportTranscript Software Engineering: Analysis and Design - CSE3308 Conceptual Issues in Human-Computer Interaction
CSE3308/DMS/2002/17 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 Conceptual Issues in Human-Computer Interaction CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.1 Lecture Outline CLINTs What is Human-Computer Interaction? Models An and WIMPs and HCI example of the role of models The need for design Principles POET for design - a design method CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.2 CLINTs and WIMPs CLINT - Command Line INTerfacer WIMPs - Windows, Icons, Mice, Pointing Over the last 4 decades, have migrated from CLINTs to WIMPs The vast majority of computer users will run screaming from a command line interface The GUI is now king of our screens, but is unlikely to stay enthroned forever Voice-based systems Virtual Reality-based systems CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.3 What is Human-Computer Interaction? The ways and means by which humans use computers The interaction between humans and their computers occurs through what is known as the user interface The User Interface is the “System” If the User Interface is poor, then the system is poor The User Interface is a necessary but not sufficient part of building a good system CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.4 Models People build mental models of how the world works People form these models through experience, training and instruction These mental models are often wrong in principle, but correct in effect In software development, we have three mental models which we are concerned with The Implementation Model The System Model The User Model CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.5 The interaction between the three models Implementation Model User Model Designer User System System Model CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.6 Which model should the System Model match? Better Worse System Models Implementation Model reflects technology CSE3308 - Software Engineering: Analysis and Design, 2002 User Model reflects user’s vision Lecture 8A.7 Models and User Interfaces Mental models are generally simpler than reality Mental models don’t have to be true or accurate, so long as they are effective Example - many users see the screen as the centre of the computer where the work is done Software which has a system model similar to the user’s mental model reduces the complexity of an interface Most software conforms to the implementation model CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.8 The Baffling Case of the File System The current file systems used in all systems are based on the implementation model, not the user model The current file system is an endless source of user problems and frustration Very few people even question whether it can be done a different way! Users view files in the same way as they view documents in the real world, but this is not correct CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.9 The real world analogy to using a file Compare with using a book from a shelf 1. Make a photocopy of the book on the shelf 2. Scribble any changes you want to make on the photocopy 3. Burn the original book on the shelf 4. Place the scribbled-on photocopy where the original was CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.10 The current filing system Differentiates between the copy on the hard disk and the copy in RAM Use of Hard Disks is purely a technical issue driven by cost, has nothing to do with the usage of the filing system The ability to lose all your changes and revert to the old version prior to saving is a sideeffect and a dangerous side-effect The existence of two versions of the same document simultaneously is greatly confusing CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.11 A solution in tune with the user’s mental model What are the goals of a file system for the user? Saving changes to the document Create a copy of the existing document Naming and renaming the document Placing and repositioning the document Specifying the stored format of the document Creating a milestone copy of the document Reversing some changes Abandoning all changes CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.12 Addressing the requirements Saving changes to the document With modern technology, we can save often automatically Save when the user stops rather than when actually typing Manual save facility for the paranoid Creating Add a command Make Snapshot Copy Give copy standard name like Copy of Alpha and put it in the same directory Should just happen, no dialog box Naming a copy of the document and renaming the document Name in the title bar should be editable CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.13 Addressing the requirements (2) Placing and repositioning the document All documents placed in file system in default location Explicit command on the menu to move to a different location, if necessary Specifying the stored format of the document Currently tied in with the file system Not actually part of the file system, but is actually a property of the document Very rare occurrence, shouldn’t be tied to saving the document CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.14 Addressing the requirements (3) Making a Milestone copy of the document creates a version of the document to be stored separately in the file system similar technology is already used in revision control systems Simple to revert back to a milestone when we need to Abandoning a facility on the menu to abandon all changes since the document was opened with appropriate warnings facility should also be undoable for a week or two Reversing all changes some changes use a multi-level undo CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.15 The New Menu Menu now reflects the user’s mental model instead of the implementation model there is one document and the user owns it and can control its behaviour easily and in detail No need for the user to worry about copies in RAM and disk CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.16 The New Menu’s Appearance Document New Open... Close Rename/Reposition… Make Snapshot Copy Make Milestone Revert to Milestone... Document Properties... Abandon Changes Close CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.17 The Need for Design As can be seen by the File Menu example, there is still room for considerable improvement in user interfaces By applying good design principles to the tasks that users perform we can produce far better user interfaces The result is more work for developers, but more productive and better-selling software for users CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.18 Five fallacies The design is satisfactory for me - therefore it will be satisfactory for everybody This design is satisfactory for the average person - it will therefore be satisfactory for everybody else The variability of human beings is so great than it cannot be catered for in any design - but since people are wonderfully adaptable it doesn’t matter anyway Good interfaces are expensive and since products are usually purchased on appearance and styling, we can ignore interface design Good interfaces are an excellent idea, I always design things with this in mind, but I do it intuitively and rely on my common sense, so I don’t need to test it CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.19 Design Principles Affordances Being aware of the mental models in the system Making things visible The principle of mapping The principle of feedback CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.20 Affordances The perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used Examples The handle on a door A 3-D pushbutton on a toolbar Affordances are far more compelling than written instructions CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.21 Making things visible The functions in a system should be visible Example - the Telephone standard telephone has 15 function buttons most functions use the * and # button the button has no relationship to the function How many people can set up a three-way call or remember how to turn off call waiting? Counter example - the Car Many more buttons, but each button generally has one purpose and is labelled people have far less problems in a strange car as opposed to their own telephone Visibility acts as a reminder of what can be done and how it is done CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.22 The principle of mapping Mapping is the relationship between two things for example, the steering wheel of a car, when it is turned right, the car turns right, when turned left, the car turns left By using natural mappings, the designer can make actions easily learned and always remembered e.g. spatial analogies: to move an object up, move the control up e.g. other physical analogies: a louder sound means more, a quieter sound means less CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.23 The principle of feedback Sending information back to the user on what action has actually been performed and what result has been accomplished Feedback needs to be timely Example - Keyboards can easily be made to be silent, but a good keyboard will have a nice satisfying click! CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.24 How people do things An approximate model - Seven Stages of Action Three basic areas Goals - what does the user want, i.e. their expectations of and intentions for the device? Execution - how does the user achieve the goals with the device Evaluation - how does the user know whether their goals have been met? Gulf the distance between the intentions of the user and the allowable actions Gulf of Execution of Evaluation the amount of effort the user must exert to interpret the physical state of the device and how well it satisfied the user’s intentions and expectations CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.25 The Seven Stages of Action Goals Evaluation of interpretations Intention to act Sequence of actions EXECUTION Execution of the action sequence Interpreting the perception EVALUATION Perceiving the state of the world The World CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.26 Using the seven stages to assess a design How easily can one: Determine the function of the device? Tell what actions are possible? Tell if the system is in the desired state? Determine mapping from intention to physical movement? Determine mapping from system state to interpretation? Perform the Action? Tell what state the system is in? CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.27 POET - a design method The Psychology of Everyday Things - Donald Norman - Apple Fellow (new edition of book retitled “The Design of Everyday Things”) Address the goals of the user Use both knowledge in the head and knowledge in the world Simplify the structure of tasks Make things visible, bridge the gulfs of Execution and Evaluation Get the mappings right Exploit the power of constraints, both natural and artificial Design for error When all else fails, standardise CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.28 POET - A design method (2) Address the goals of the user Don’t allow the implementation model to rule the way things are done Use knowledge in the head and knowledge in the world People learn better and feel more comfortable when the knowledge needed to do the job is available externally But knowledge in the world must have a natural, easily interpreted relationship between that knowledge and the information it is intended to convey about possible actions and outcomes Knowledge in the head improves performance, so the design should not impede experienced users with that knowledge Knowledge in the head is only available within a context CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.29 POET - a design method (3) Simplify the structure of the tasks; 4 ways: Keep the task much the same but provide mental aids » e.g. providing a drop-down list box of postcodes Use technology to make things visible and reduce memory load » the automatic spelling check function in Word 97 Remove some parts of the task with automation » e.g. filling in the suburb field based on the postcode Change the nature of the task » e.g have a web page and let the user fill in the details Simplify, but don’t take control away from the user CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.30 POET - a design method (4) Make things visible Bridge the Gulf of Execution by letting people know what is possible letting people know how actions are performed Bridge the Gulf of Evaluation by showing people the effects of their actions Actions should match intentions and expectations The system state should be readily perceivable and interpretable The system state should match the user’s intentions and expectations CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.31 POET - a design method (5) Get the mappings right between intentions and possible actions between actions and their possible effects on the system between actual system state and what the user can perceive between the perceived system state and the needs, intentions and expectations of the system Exploit the power of constraints use constraints so that the user feels there is only one choice: » the right one reduce the possible number of actions at any stage CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.32 POET - a design method (6) Design Assume any error can be made and plan for it Support, don’t fight the user’s response Allow recovery from errors Don’t straitjacket the user: » what you think is an error may be normal behaviour in the system When for error all else fails, standardise If there must be arbitrary mappings, standardise the layout Standards are hard to agree upon Users must be trained in standards CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.33 The Backwards Clock 12 1 11 2 10 3 9 4 8 5 7 6 CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.34 References Norman, Donald A, The Design of Everyday Things, Currency/DoubleDay, 1990 (previously published as The Psychology of Everyday Things, Basic Books, 1998) CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8A.35