SEG 3210 User Interface Design & Implementation

1. SEG 3210User 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/

2. Unit E: Design Guidelines • 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 • Localization and Internationalization • On-Line Help • Guidelines and Standards Documents

3. 15. Localization and Internationalization • This section is important if software may ever possibly have users with different: • Countries • Languages • Cultures • Locale • Set of features that can be varied depending on the language and culture of the user or the data • Internationalization • The process of designing software so that it can be easily adapted to different locales • Localization • The process of adapting software so it can be run in different locales

4. Design of internationalized software • Special care must be taken when integrating 3rd party software • May not follow the same internationalization standards as you want • Do not make the functionality dependent on the format of data, or vice-versa. • Create a resource file for each locale and language • All strings to be displayed (except data) are taken from this file • English is just one possible language • The system will read the appropriate configuration file when it is installed or run • Design screen layouts so they can automatically adapt to different text ... • Amounts (some languages are more wordy than others) • Orientations (some run right-left or bottom-top) • Think carefully when designing keyboard shortcuts • English mnemonics won’t work in other languages • Keyboard layouts can be totally different

5. Design of internationalized software • Understand and apply all local and international standards • (official and de-facto) • Employ professional translators who understand the technology and are willing to test the application • Avoid text that is difficult to translate • Limit use of acronyms • Do not string more than two nouns together • Keep text simple and short but avoid telegraphic style • Except for single ‘fill-in-the-blank’ proper nouns, avoid constructing text piece-by-piece within your code. • Ensure all language versions are thoroughly tested • Have all language versions ready for release at the same time • Being a release behind causes significant frustrations • Beware of numerous cultural differences: • Trash can or mail boxes are not universal • ‘Black cat’ means bad luck in North America, good luck in the UK. • The colour red has numerous conflicting connotations • Keep away from metaphors involving culture-specific games or activities

6. Design of internationalized software • Allow for the display of different ... • Sets of diacriticals (accents) • Each language has its own set • E.g. In Arabic, characters look different depending on their position relative to others • E.g. in Thai, diacritics can be stacked on top of each other several levels • Also in Thai, spaces separate syllables, not words • ‘ABCD’ ‘AB CD’ ‘A BCD’ mean different things, causing problems at line breaks • Some languages run top-bottom • Date and time formats • Allow for various orders of components, and different words (e.g. for months) • Allow for 12 and 24 hour clocks • Allow for time zones, but avoid hard-coded abbreviations such as ‘GMT’ which may not be unique around the world.

7. Design of internationalized software • Character sets • e.g. Latin, Japanese, Arabic • ‘!’, ‘?’ and ‘#’ are not consistently used among languages • In Spanish: ¿ … ? • In French, a space precedes a ? • Numeric formats • Different symbols separate thousands: • comma, period, space, nothing • Different symbols designate the decimal point. • Currency formats • Allow for different symbols and locations • Different ways of expressing US$1000 • $1000 (In the US, or in Canada and the UK if the application doesn’t mix currencies) • US$1000 (In English Canada, if the application mixes currencies) • 1000 $ (Inmost French locales) • 1000 USD when mixing large numbers of currencies • Telephone number and postal code formats • Don’t constrain what characters can be entered

8. Design of internationalized software • Prepare to handle different collating sequences when sorting

9. 16/17. Help & Documentation • Why do systems have Help & Documentation? • Users require different types of support at different times • User Support may be provided by help and/or documentation • Help: problem-oriented and specific • Documentation: System-oriented and general • User Support can be in two forms • Hardcopy user Manuals • Brief getting started notes • Introductory Tutorial • Thorough Tutorial • Quick Reference Manual • Detailed Reference Manual • Online Material • User manual & help facility • Tutorials • Demonstration

10. Requirements of Help and Documentation • Availability • Continuous access concurrent to main application • Accuracy and Completeness • Help matches actual system behavior and covers all aspects of system behavior • Consistency • Different parts of the help system and any paper documentation are consistent in content, terminology and presentation • Flexibility • Allows users to interact in a way appropriate to experience and task • Unobtrusiveness • Does not prevent the user continuing with work nor interfere with application

11. Approaches to user Support • Command Assistance and Command Prompts • User requests help on particular command. • E.g. DOS help, UNIX man • Good for quick reference • Provide information about correct usage when an error occurs • Good simple syntactic errors • Assumes user knows what to look for • knowledge of command • On-line Tutorials • User works through basics of application in a test environment • Useful but are often inflexible • On-line Help/Documentation • Paper documentation is made available on computer • Hypertext used to support browsing • Continually available in common medium, but can be difficult to browse

12. 16 . On-Line Help • Some interesting findings about a particular help system • 5-20% of user interactions typically involved help • 10-20% of messages were never accessed • 10% of messages accounted for 90% of requests • Most users were unhappy with the help system • Questions users ask when they go to help: • Task achievement (70%): • How do I do this, or should I do this? • State identification (20%): • Where am I, or What is this? • Exploration: • What can I do with this program? • Diagnostic: • What is wrong?

13. Guidelines for help • Make help easy to access • Advertise the help system • Provide several ways to gain access • Make it fast • Couple help with the system • Integrate help and error handling • Make help active so it gives suggestions • Organize help around tasks and goals • Provide a variety of navigational aids • Hyperlinks • Full text keyword searches • Outlines • Organize help using increasing levels of detail • Make help consistent in style • Use a professional writer • Make help complete and accurate

14. 17. Guidelines and Standards Documents • Characteristic of Guideline: High in generality • Principle: Requires interpretation to apply • Rule: Simple to apply • Characteristic of Standard: High in authority • Standards and guidelines: • Are dependent on context • Have exceptions • Often conflict • Are generally based on sound research • But the research may be misapplied • e.g. Often guidelines say ‘Display 7 +/-2 menus due to short term memory’ • The real reason is to prevent confusion

15. Some benefits of standards • Improved usability • Standards have been carefully developed • Common terminology • Means of comparison among applications • Easier deign and maintenance • You know what things should look like • A common identity among applications • Reduction in training • Things are the same within and across applications • Customer satisfaction • Safety • Errors less likely to be made due to familiarity • Typical standards documents • ISO 9241 • IBM Common User Access Guide • Inside Macintosh (Apple) • The Windows Interface: An Application Design Guide (Microsoft) • SUN: Java Look and Feel Design Guidelines

16. Before you go: Can you guess the woman’s age? Keep looking