1 Unit E-Guidelines (c) elsaddik SEG 3210 User Interface Design & Implementation Prof. Dr.-Ing. Abdulmotaleb El Saddik University of Ottawa (SITE 5-037) (613) x 6277 site.uottawa.ca mcrlab.uottawa.ca

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

3 Unit E-Guidelines (c) elsaddik 4. Response Time 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

4 Unit E-Guidelines (c) elsaddik 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 (> 3s) 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

5 Unit E-Guidelines (c) elsaddik A typical users’ tolerance of delays Zero (no visible or articulatory delay) Cursor movement and appearance Display of simple menus Echoing of input Moving, resizing and iconizing windows Short (up to 2/3 second) 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

6 Unit E-Guidelines (c) elsaddik 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

7 Unit E-Guidelines (c) elsaddik 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)

8 Unit E-Guidelines (c) elsaddik 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%

9 Unit E-Guidelines (c) elsaddik 5. Feedback and Error Handling 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.

Unit E-Guidelines (c) elsaddik 5. Feedback and Error Handling Provide a clear and easy way out of each state Back to the previous state To other important states Mouse over feedback

Unit E-Guidelines (c) elsaddik 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 actions should be organized with clear chronology as needed sequences of actions should provide clear feedback upon completion

Unit E-Guidelines (c) elsaddik 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

Unit E-Guidelines (c) elsaddik 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 3D Style: The flush 3D effect simulates the appearance of bevelled buttons or shapes inset at the same level as the background Consistent Use of Colour Across Design Elements

Unit E-Guidelines (c) elsaddik 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 23K 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). ‘Not enough space on drive B; an extra 23K needed’ ??

Unit E-Guidelines (c) elsaddik Error Messages (Cont’d) If there are 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

Unit E-Guidelines (c) elsaddik 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

Unit E-Guidelines (c) elsaddik 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

Unit E-Guidelines (c) elsaddik 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

Unit E-Guidelines (c) elsaddik Example (1)

Unit E-Guidelines (c) elsaddik Example (2)