IMS2805 - Systems Design and Implementation

IMS2805 - Systems Design and Implementation Lecture 4 Interface Design – Part 2

References • HOFFER, J.A., GEORGE, J.F. and VALACICH (2002) 3rd ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chapter 14 • HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chap 12 • WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 14, 15

References • Don Norman’s The Design of Everyday Things (Doubleday Currency 1986) • Very useful and general discussions of the problems of designing interfaces applied to doors, windows, watertaps and computer systems. • Alan Cooper’s About Face: The Essentials of User Interface Design (Programmer’s Press, 1995) • Practical advice combined with criticism of a number of standard aspects of interface design.

Human–Computer Interface Design The interface is the link between the users and the computer INTERFACE Database Programs end user direct user To many users the interface is the system

What makes a ‘good’ interface? • Leverage Metaphor: • a good interface gives the desired output with least effort • Economic argument: • the effort applied (by users) will be proportional to the (perceived) benefit of the outcome (to those users)

Human–Computer Interface Design "The way a user interacts with a computer is as important as the computation itself; in other words, the human interface, as it has come to be called, is as fundamental to computing as any processor configuration, operating system, or programming environment. (John Anderson, 1989)

vocabulary nouns can be seen as the data structure (entity and attribute labels) in the data tables. grammar the gizmos used to present the data restrict the way the vocabulary is used. sentences a structure making a single statement with a minor closure point at the end. paragraphs one or more “sentences” with a coherent thought and a more significant closure point at the end. dialogue conversations require two-way communication. The flow of conversation needs to carry a logical thread, it may also be navigated in a number of different directions. roles conversation reflects the roles of the parties involved Human conversation as a metaphor for the human-computer interface

Human-Computer Communication 1. data - “vocabulary” for GUI communication 2. metaphors and mental models 3. application posture 4. “grammar” - gizmos 5. closure and flow in GUI communication 6. navigation 7. task structure/dialogue

1. Vocabulary - the data • The human-machine interface will: • add new instances to the database • modify existing instances in the database • delete instances in the database • The underlying structure of the data influences the human-machine conversation BUT • the screen layouts • the screen navigation process do NOT have to reflect the data table structures • Internal data structures reflect the best way to store data • External data structures reflect the best way to obtain and use the data in a conversation. • The human-machine interface must ensure that, as far as possible, the data meets the rules for the data domain, is correct and complete.

COURSE course code, course title SUBJECT subject code, subject description STUDENT student no., name, address, phone RESULTS student no., subject code, yr, sem, result External and Internal data views Student results sheet Student no: 12345678 Name: Fred Nurk Course: 0961 B. Comp. Year: 1998 Semester: 1 Subject Result Grade SYS2001 65 C SFT2001 88 HD COT2001 75 D PHY2120 68 C

Cooper’s Manifest Model manifest models are chosen by the developer.The best ones reflect the user’s mental modelnot the implementation model mental models reflects user’s vision implementation models reflect technology

2. Mental Models humans simplify(the music doesn’t come straight from the tape) humans anthropomorphise (inanimate objects gain personality)

“Understanding how software actually works will always help someone to use it, but this understanding usually comes at significant cost. The manifest model allows software creators to solve the problem by simplifying the apparent way the software works. The cost is entirely internal, and the user never has to know.” User interfaces that abandon implementation models to follow mental models are better.” (Cooper 1995, p31) The Value of the Manifest Model

main screen person record person find item record loan loan add modify delete add modify delete item add modify delete Interface Follows the Implementation Model

main screen person everyone loans staff admin loan find items check loans new items remove items item make loans accept returns Interface Follows the User’s Mental Model

Compare These ... three examples of colour change dialogs from PhotoShop. which dialog best suits the mental model of a graphic artist (the target user)?

originally a “trash can” on Macintosh. Note the difference in the metaphor! implies the ability to take work home The window metaphor implies both viewing and restrictions on the view. a common storage & classification device folder Metaphors metaphors are used to draw an analogy between the way the dialog works and some object the user is familiar with. Some common metaphors:

May 1997 Sun Mon Tues Wed Thurs Fri Sat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Some Metaphors Don’t Work Transferring mechanical models to computers can restrict an application where these restrictions are not necessary. Paper calendars are limited in the size of paper available and show one month at a time. Computerised calendars are often presented one month at a time. Is this restriction necessary? What opportunities are lost?

Choose Your Metaphors Carefully • A metaphor should • make it easier for the user to understand the function and purpose of the software • NOT limit the range of useful features offered • enable the user to predict ALL the functions available • NOT behave differently on computer from real life

3. Application Posture • The posture of an application is the way it presents itself to the user • Sovereign • Transient • Daemonic • Parasitic

Application Posture • Sovereign (royal) posture • only application on screen • monopolises user’s attention for long periods • usually running continuously • usually large with lots of related features, functions • e.g. word processor, spreadsheet

Application Posture • Transient posture • single function application • called when needed - appears, performs job and leaves, • temporary • e.g. scanner software

Application Posture • Daemonic posture • works quietly and invisibly in the background • possibly doing vital tasks • often no need for human intervention • talks with the user when they must be manually adjusted for changing circumstances e.g. printer driver

Application Posture • Parasitic posture • continually present like a sovereign • performs a supporting role • small and superimposed on another application • often report progress e.g. Windows clock, eyeballs to track mouse cursor, paper clip

Design for Sovereign Posture • Sovereign users are experienced users. • while each user spends some time as a novice, this is only a short time relative to the total amount of time spent using the software. • design for optimum use by experienced users! • sovereign users are in flow - don’t interrupt! • OK to take up video real estate (multiple toolbars etc) • Use muted colours and textures (users will be looking at this for a long time!)

Design for Sovereign Posture • Buttons etc can be smaller, more tightly packed because users will be familiar with them • Window should be maximised, avoid resizing to move from one document to another • Use the full screen and all its possibilties • Tune the application to avoid delays

Design for Transient Posture • Avoid taking more space than necessary - support rather than replace the sovereign application • Use bright colours to differentiate this application from background sovereign • ‘Gizmos’ can be larger and bolder than in a sovereign application • Build instructions into the interface - user doesn’t use this often enough to remember • All information and facilities should be available on the surface - single window

Design for Transient Posture • Avoid alternative views and dialog boxes • Use simple controls - push buttons • Avoid controls on window edges • Provide a simple keyboard as well as mouse interface • Window should be less than full size, must be moveable, may be reshapable

Design for Daemonic Posture • Avoid taking more space than necessary - avoid full-screen control panels • Mostly should be invisible • this includes status reports since user often not aware of the existence of this application • Must be able to be reached • use a Windows control panel or • create a transient program that runs a launchable application to configure the daemon • See design tips for transient applications

Design for Parasitic Posture • Should be simple and often bold in reporting information • Avoid taking more space than necessary - get out of the way of the sovereign application when necessary • Are not the focus of the user’s attention • Use small features because on screen for long periods and user will learn where it is • Design to support sovereign but not interfere

4. Grammar - Gizmos Gizmo Data Entry Mode Validation free text no auto checks select one item from a list limited choice select an item or enter text selects nearest match choose one option only limited choice choose one or more options limited choice toggle choice on or off limited choice perform a preset function limited choice

Properties Control Source Item_name Back Color (= background) Border Style clear Tab Stop No Locked Yes Text Boxes for Display • A text box is used to display data. The form and text box are BOUND to a column in the data table. • Normally you set the box so that it is obvious this is OUTPUT. You can do this by making the box the same colour as the background and removing the box outline. • This field will be skipped in the Tab order. If the user selects the field they can copy the data but not change it (locked).

Text Boxes for Input • A text box can be used to input many types of data. The text box will be UNBOUND for input only, or BOUND to a column if you want to display and alter values. • Normally you set the box so that it is obvious this is INPUT. You can do this by making the box a different colour from the background and having a clear box outline (these are the default settings). • N.B it is ILLEGAL to use tax file numbers for other purposes! Properties Control Source (unbound) OR tax_file_no Format fixed Decimal places 0 Input Mask 000\000\000;;_ Status Bar Text tax file number This field has formatting prompts as well as automatic checks for numeric data.

Properties Control Source (unbound) OR account_no Format fixed Decimal places 0 Input Mask 000\000\000;;_ Status Bar Text account number Text boxes for Input A text box can be used to input many types of data. The text box will be UNBOUND for input only, or BOUND to a column if you want to display and alter values. Normally you set the box so that it is obvious this is INPUT. You can do this by making the box a different colour from the background and having a clear box outline (these are the default settings). This field has formatting prompts as well as automatic checks for numeric data.

Properties Control Source Name Row Source Type Table/Query Row Source Select [Name] From [gizmos]; List Boxes for Input • A list box can be used to restrict input of data to values currently saved. The list box is BOUND to the relevant column in the data table in which the values are stored. • You can arrange the size of the box to display as many values at once as you like. If more values are available a scroll bar will appear. • List boxes like these prevent the user entering invalid data but do require the use of a mouse.

Properties Control Source Name Row Source Type Table/Query Row Source gizmos (table) Properties Control Source (unbound) Row Source Type Value List Row Source gizmos; widgets; doodads Combo Boxes for Input • A combo box displays the list of current values but also allows the user input new values or to select current values from the keyboard • The combo box may be BOUND to a column in the data table from which the values will be displayed OR the possible values may be specified in the property sheet

Other Choices for Input • Option buttons, check boxes and toggle buttons can be used to provide a choice from a range of alternatives. • Usually option buttons are used to select only one choice while check boxes are used to select as many as apply. • Toggle buttons may be labelled with icons. • Typically these controls will be placed in a group so that the range of choices will be clear.

Command Buttons • Command buttons are used to carry out program steps such as saving a record, accessing another file, etc. As a result, there is often scope for using icons in place of, or in addition to, text. • Note the CD player metaphor in this example. Is it a good one? On click [Event Procedure] Properties

5. Sentences and Paragraphs - Closure Points • In human speech, closurepoints enable the speaker to take a breath and the listener to respond. In writing, closure points are given by ends of paragraphs and chapters. • In human-computer dialog, closure points allow the user to take a short mental break. Where delays in processing occur, these cause least interruption at closure points.

Sentences and Paragraphs - Closure Points • In human-computer dialog the following situations are examples of possible closure points • end of entering data into a gizmo • end of a composite data item, such as customer address • end of a sub-transaction, such as one item being ordered • end of all transactions for this customer • end of the day (or conversation period)

Closure Points and Data Validation • Closure points are obvious stages at which to check for errors in the data presented so far. • So ... • use closure points as logical places to allow the user to check and correct the data entered so far • adjust the level of data validation to the level of closure point • remember - error messages interrupt the flow of the dialog - attempt to minimise this interruption

Error Messages • Error messages may place the user in a different mode. • In this example, the user is required to change from one mode (the mode of the main process) to respond to the error (error handling mode). • Modeless feedback is preferable.

Approaches to Errors • There are several ways of handling errors: • Restrict the user’s opportunities for making errors: • get users to select values rather than type them in (can use typing to select values though) • don’t accept invalid formats (go back to start of field and insist on correct format) - take care with this!

Approaches to Errors • Tell the user what is acceptable and validate the input • give patterns for data entry fields • show rules, examples next to the field • Accept everything the user enters and deal with it somehow (Cooper’s preference) • save whatever the user enters • offer alternatives

Flow • Flow - a state of concentration; • Techniques for inducing and maintaining flow • follow mental models • direct, don’t discuss • keep tools close at hand • give modeless feedback • don’t interrupt

6. Navigation Techniques menus drop-down menus are a common feature of GUI interfaces. Note the conventions for menu structures. switchboards are easy to produce but simple switchboards force a hierarchical structure on the system. command buttons allow jumps to other functions without returning to a “top level”. button bars a collection of command buttons producing a version of the switchboard. Common on Web sites. Include content as well as navigation on the one page. toolbars used for a range of purposes, they can include navigation command buttons as well. tabbed folders pop up like a transient application.

Menus • menus are used by novice and intermediate users, and by expert users for infrequently used functions; • every function must be available on a menu; • users don’t understand hierarchical menus - avoid them - keep to single level menus; • don’t put bang (immediate action) menu items on a top-level menu

Menus • menus as a training aid: • put icons on menus so that users learn what they mean by familiarity; • disable menu items that are not available;

Switchboards • switchboards are used by novice and intermediate users, and when the hardware / software restricts navigation techniques (e.g. the Web) • switchboards are the GUI equivalent to menu structures on text systems • usually requires many levels of switchboard to cover all functions; • users will not remember the structure of the set of menus; TEXT-BASED SYSTEM MENU OF CHOICES ---------------------------- 1 BOOKINGS 2 CUSTOMERS 3 TOURS 4 MAINTENANCE 5 LOGOUT

Switchboards • GUI design allows icons and explanation for each selection on a switchboard - use them! • switchboards can be useful as an overview of the full system; • however, switchboards often don’t allow other navigation so not very useful as a training aid.

IMS2805 - Systems Design and Implementation