www site uottawa caelsaddik www elsaddik com SEG

www. site. uottawa. ca/~elsaddik www. el-saddik. com SEG 3210 User Interface Design & Implementation Prof. Dr. -Ing. Abdulmotaleb El Saddik University of Ottawa (SITE 5 -037) (613) 562 -5800 x 6277 elsaddik @ site. uottawa. ca abed @ mcrlab. uottawa. ca http: //www. site. uottawa. ca/~elsaddik/ 1 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Unit E: Design Guidelines 2 Unit E-Guidelines (c) elsaddik 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. A General Meta-Guideline Interaction Styles vs. Interaction Elements Coding Techniques and Visual Design Response Time Feedback and Error Handling Command-Based Interfaces Menu Driven Systems Keyboard Shortcuts Forms-Based Interfaces Organizing a Windowing Interface Question and Answer Interfaces Information Query Interfaces Voice I/O Natural Language Interfaces Other Types of I/O Localization and Internationalization On-Line Help Guidelines and Standards Documents

www. site. uottawa. ca/~elsaddik www. el-saddik. com 4. Response Time • The time it takes from the moments users initiate an activity until the computer presents the results. • User Think Time • The time it takes the user to think before entering the next action • Response is good or bad only in terms of the user’s perception • Over time users become more demanding of computers • Users seek systems with fast response • Users want to feel in control • Slow response time puts the computer in control 3 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com General response time guidelines • Display whatever you can, as soon as you can, when delays are longer than 2 -4 seconds • e. g. when starting an application, open a window with a title immediately • When total elapsed time is very short, it is best to display everything at once • Announce long delays (> 3 s) • Before user selects action if possible • i. e. warn of consequences with a distinctive cursor • During execution when a delay is expected • Calculate the expected length of the delay and provide dynamic feedback • Use a bar or numeric feedback • Keep the variability of response time low • Users become more frustrated if the system sometimes works slowly • Clearly explain response time variability 4 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com A typical users’ tolerance of delays • Zero (no visible or articulatory delay) • • • Short (up to 2/3 second) • • 5 Unit E-Guidelines (c) elsaddik Cursor movement and appearance Display of simple menus Echoing of input Moving, resizing and iconizing windows Scrolling, page flipping Display of complex menus Detection of an error in a command Execution of simple commands like status or help Display a window with more than 5 -6 fields Loading a simple local document whose name is known Saving a document First feedback from any operation

www. site. uottawa. ca/~elsaddik www. el-saddik. com A typical users’ tolerance of delays • Long (up to 15 seconds) • • • Loading a complex document Loading a document from a distant site Starting up a complex application Performing a complex query Sending a moderate document to a printer • Very long (over 20 seconds) • Retrieving from a tape archive & Printing a sophisticated document 6 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Technical guidelines to assist with response time • If there is sufficient memory, work with ‘backing store’ Save window contents when they are covered • Draw into the backing store when windows are hidden. • This enables instant display when windows are exposed (rather than redrawing) • If possible, use double buffering when total delays are less than 2 -4 seconds • Draw the whole image to an internal bitmap and display all at once • Users are distracted by bits of windows slowly drawing (Backing store is typically part of a hard disk that is used by a paging or swapping system to store information not currently in main memory) 7 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Technical guidelines to assist with response time • Ensure the time to create the display is shorter than the computational time • Users only tolerate delays in computation, not display of results • Options to turn off fancy graphics may be needed • Perform user tests using slow equipment • Profile code to find those procedures that take most time • Optimize them • Profile usage to find those procedures that are used most • Multiply the percentage each action is performed by its average response time • Optimize actions in top 20% 8 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 5. Feedback and Error Handling 9 Unit E-Guidelines (c) elsaddik General guidelines about feedback • Uniquely identify each state: • Make each change of state immediately clear • Use the most accurate form: cursor appearance, status bars, changes in icons or colours, ‘graying out’ etc.

www. site. uottawa. ca/~elsaddik www. el-saddik. com 5. Feedback and Error Handling 10 Unit E-Guidelines (c) elsaddik • Provide a clear and easy way out of each state • Back to the previous state • To other important states • Mouse over feedback

www. site. uottawa. ca/~elsaddik www. el-saddik. com 5. Feedback and Error Handling • Offer informative feedback: • frequent & minor actions get modest feedback • infrequent or major actions get substantial feedback • direct manipulation should result in explicit display of changes • Avoid distracting the user • e. g. some versions of MS-Word moves all windows when the user opens or closes a toolbar • Some applications flash fancy graphics on the screen • Don’t personify the computer or patronize the user • I wish you would. . . • I don’t understand. . . • . . . is too difficult • Design dialogues to yield closure 11 Unit E-Guidelines (c) elsaddik • actions should be organized with clear chronology as needed • sequences of actions should provide clear feedback upon completion

www. site. uottawa. ca/~elsaddik www. el-saddik. com Error Messages • When displaying an error message, have the cursor point to the errant item • Provide as much detail as you can about errors • Have the system spend some time translating a symptom into its possible causes • The extra time is well worth it • The time is only spent occasionally when errors occur • If there is more than one cause, consider displaying them all if it would help speed user’s work. • Be specific about the names of things causing errors 12 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Preventing Errors • Strive for consistency: • sequences of actions, terminology, colour, layout, capitalization, fonts, etc… all should be consistent. • exceptions should be comprehensible and limited: • not echoing passwords to the screen when typed Examples: • Consistent Use of the Flush 3 D Style: • The flush 3 D effect simulates the appearance of bevelled buttons or shapes inset at the same level as the background • Consistent Use of Colour Across Design Elements 13 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Error Messages (Cont’d) Example 1. • User: rename apple. txt pear. txt • Bad computer: • Parameter count exceeded • The system could detect the problem and make a suggestion • Good computer: • Rename not done. Extra argument follows new file name. The space preceding ‘. txt’ appears incorrect. Example 2 • Instead of ‘Could not save file’ • ‘File not saved: Not enough space on drive B; an extra 23 K needed’ • ‘File not saved: A write-protected file with this name (apple. txt) already exists’. • ‘File not saved: You (John) do not have permission to write to this directory (mydata). 14 Unit E-Guidelines (c) elsaddik • ‘Not enough space on drive B; an extra 23 K needed’ ? ?

www. site. uottawa. ca/~elsaddik www. el-saddik. com Error Messages (Cont’d) • If there a small number of possible solutions, prompt the user to pick one • Avoid displaying error codes (even if accompanied by explanatory text), e. g. ‘ERROR 234’ • Their original functions were: • To help programmers • To save space • To provide an index into documentation • They are rarely justifiable today. • Index into documentation using the first few words of a carefully phrased message. • Use codes internally only • Formative evaluation 15 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Error Messages (Cont’d) When to display error messages consider: • Display them as soon as possible, even before the user finishes entering data on a form • For beginners • For infrequently used screens • Whenever continuing to enter data might mean the user is liable to further errors • e. g. if the user makes the same error in several fields • e. g. if subsequent values are constrained by earlier values OR • Display them when all data on a form is entered • For forms frequently used by experts • experts will find this faster 16 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Important Error Handling Techniques • Design as many operations as possible to be reversible: • encourages exploration of unfamiliar options • Consider multiple "levels" of reversibility (undo capability): • single action, data-entry task, complete sequence of actions • Infinite undo is best even though not possible • Require confirmation for commands which cannot be undone • E. g. file deletes • Provide a ‘cancel’ mechanism for operations in progress • If partial results make sense, display them • e. g. partial file retrieved from the network • Consider allowing users to override error messages and enter invalid data into a database • The user would come back later to fix errors • This prevents wasted work if the source information is erroneous • Provide a mechanism to subsequently remind the user of the invalidly entered data 17 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Important Error Handling Techniques • Consider helping the user to correct errors automatically • E. g. repetitive spelling mistakes • Consider a ‘teach me’ interface (simple error handling) • If the user does something ‘wrong’: • Have the system ask what the user means • Then ask if this should always be acceptable in the future • e. g. adding ‘exit’ as a synonym for ‘quit’: • constrain user actions to prevent error; • if an error is made, application should be able to detect error and allow for recovery • erroneous actions should leave application state unchanged 18 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Example (1) 19 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Example (2) 20 Unit E-Guidelines (c) elsaddik