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. 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

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 3 Unit E-Guidelines (c) elsaddik • The process of adapting software so it can be run in different locales

www. site. uottawa. ca/~elsaddik www. el-saddik. com Design of internationalized software • Special care must be taken when integrating 3 rd 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 4 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com Design of internationalized software • Understand 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: • • 5 Unit E-Guidelines (c) elsaddik 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

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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. 6 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 7 Unit E-Guidelines (c) elsaddik • Telephone number and postal code formats • Don’t constrain what characters can be entered

www. site. uottawa. ca/~elsaddik www. el-saddik. com Design of internationalized software 8 Unit E-Guidelines (c) elsaddik • Prepare to handle different collating sequences when sorting

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 9 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 10 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 11 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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? 12 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 13 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 14 Unit E-Guidelines (c) elsaddik

www. site. uottawa. ca/~elsaddik www. el-saddik. com 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 • • 15 Unit E-Guidelines (c) elsaddik 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

www. site. uottawa. ca/~elsaddik www. el-saddik. com Before you go: 16 Unit E-Guidelines (c) elsaddik Can you guess the woman’s age? Keep looking