1 / 34

CPIS 354 - Principle of Human Computer Interaction

CPIS 354 - Principle of Human Computer Interaction. Department of Information Systems Faculty of Computing and Information Technology King Abdul Aziz University Khalid Al-Omar. 1. 1. design rules. Lecture 12. 2. 2. design rules.

deniser
Download Presentation

CPIS 354 - Principle of Human Computer Interaction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CPIS 354 - Principle of Human Computer Interaction Department of Information Systems Faculty of Computing and Information Technology King Abdul Aziz University Khalid Al-Omar 1 1

  2. design rules Lecture 12 2 2

  3. design rules • Designing for maximum usability – the goal of interaction design • Designer need designing rules to follow in order to increase the usability • Design rules • suggest how to increase usability • differ in generality and authority

  4. Rules classification • Design rules classified by two dimensions: 1. Generality: mean whether the rule can be applied to many design situation or whether it is focussed on a more limited application situation. 2. Authority: mean an indication of whether or not the rule must be followed in design or whether it is only suggested.

  5. Types of design rules • Standards • Specific rules or guidelines, that measurable • e.g. ISO 9241 defines usability as effectiveness, efficiency and satisfaction with which users accomplish tasks • Principles • general understanding • e.g. “an interface should be easy to navigate” • Guidelines • direction for design • advice on how to achieve principle • e.g. “use colour to highlight links”

  6. increasing generality increasing authority types of design rules • standards • specific design rules • high authority • limited application • principles • abstract design rules • low authority • high generality • guidelines • lower authority • more general application

  7. Golden rules and heuristics • Useful check list for good design • There are many rules but the most well used are: • Nielsen’s 10 Heuristics (used in Heuristic Evaluation) • Shneiderman’s 8 Golden Rules • Norman’s 7 Principles • Better design using these than using nothing!

  8. Nielsen’s 10 Heuristics • Visibility of system status • Match between system and the real world • User control and freedom • Consistency and standards • Error prevention • Recognition rather than recall • Flexibility and efficiency of use • Aesthetic and minimalist design • Help users recognize, diagnose, and recover from errors • Help and documentation

  9. 1. Visibility of system status • The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. • Examples: Figure 1.1: Password strength is shown as the password is entered (e.g. Windows Live Account)

  10. 1. Visibility of system status

  11. 2. Match between system and the real world • The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. • Examples:

  12. 2. Match between system and the real world

  13. 3. User control and freedom • Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Supports undo and redo and a clear way to navigate. • Examples: Windows provide control and freedom in their application

  14. 4. Consistency and standards • Users should not have to wonder whether different words, situations, or actions mean the same thing. • Examples: • linked styles • Word, Excel, and PowerPoint all use the same style toolbar with the same primary menu options: Home, Insert, Page Layout… Consistency results in efficiency

  15. 5. Error prevention • Even better than good error messages is a careful design which prevents a problem from occurring in the first place. • Examples: • whenever you discover an error message, ask if that error could have been prevented.

  16. 5. Error prevention

  17. 6. Recognition rather than recall • Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. • Examples: • visited hyper text links

  18. 6. Recognition rather than recall Figure 3.1: Type ahead for coding in a development environment (e.g. Visual studio 2008)

  19. 6. Recognition rather than recall Figure 3.2: Just font name Figure 3.3: Previews the fonts you can pick from, instead of just the font name

  20. 7. Flexibility and efficiency of use • Allow users to tailor certain aspects of the system, e.g. level of help, frequent actions. An operation should be achievable in the minimum number of steps necessary. Supply defaults where appropriate. • Examples: • Bookmarks, sitemaps, and personalization all fall under this heuristic.

  21. 8. Aesthetic and minimalist design • Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. • Examples: • Structure reduces complexity. • Are there too many icons? • Do we need all those divider lines? • “Less is more” is the theme here.

  22. 9. Help users recognize, diagnose, recover from errors • Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. • Examples: • A good example of this can be found in most e-commerce interfaces. If a user forgets to enter data in a required field, the system presents an error message and pinpoints which fields are missing data.

  23. 10. Help and documentation • Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. • Examples: • This heuristic deals with the end-user's access to help and documentation. How useful is our help tab? Who actually gets our training materials? Who is allowed to contact our help desk?

  24. Norman’s 7 Principles Seven Principles for Transforming Difficult Tasks into Simple Ones: 1. Use both knowledge in the world and knowledge in the head. 2. Simplify the structure of tasks. 3. Make things visible 4. Get the mappings right. 5. Use the power of constraint. 6. Design for error. 7. When all else fails, standardize.

  25. 1. Use both knowledge in the world and knowledge in the head • Knowledge in the worldwe don't have to overload our short term memory by having to remember too many things (icons, buttons and menus). • knowledge in the headmay be harder to retrieve and involves learning, it is more efficient for tasks which are used over and over again (e.g. like Control P for Print is an example of this). • Don’t make your audience remember what page number they are on, show them clearly

  26. 2. Simplify the structure of tasks • More choices means more control, but makes a system more difficult to use • To simplify tasks: • 1. Reduce number of choices for complex tasks • 2. Provide mental aids to help users to keep track of stages in the complex tasks. • 3. Provide more information about the task and better feedback • 4. Automate the tasks or part of it

  27. 2. Simplify the structure of tasks

  28. 3. Make things visible • The user must be able to figure out what to do with the object and be able to understand that an action has been completed. • The user interface should provide the user with information, feed-forward, to decide which actions he/she should undertake. • Example: I couldn’t understand my hot water heater because I couldn’t see inside it. Now they make electric kettles clear so that you can see the water boil

  29. 4. Get the mappings right • Make sure that the user can figure out what to do, and the user can tell what is going on. • For example, It should be obvious what the function of a button or menu is. From past experience, users understand that clicking on an underlined phrase should take them somewhere else. • You can provide an overview map of your site so that your user can design their own mental map of how things work.

  30. 5. Use the power of constraint • Design the product in such a way that only one action is possible or logical in any given situation. • For example, menus only display the actions which can be carried out at that time (other options are dimmed which means the command is not available).

  31. 6. Design for error • Assume that any error will be made. A user will make errors so the system should be designed to anticipate all possible errors and allow the user to correct them.

  32. 7. When all else fails, standardize • When something can not be explained in any way completely logical or culturally, make sure a universal standard is followed. • For example -Put the logo in the top left in English and top right in Arabic

  33. Shneiderman’s 8 Golden Rules 1. Consistency (terms, icons, data / command flow) 2. Enable frequent users to use shortcuts 3. Offer informative feedback 4. Design dialogs with closure (beginning  end) 5. Offer error prevention and simple error handling (automatic completion, well-defined messages) 6. Permit easy reversal of actions (undo) 7. User in control 8. Reduce short-term memory load

  34. References • http://www.usask.ca/education/coursework/skaalid/theory/interface.htm • Ten Usability Heuristics: • http://www.useit.com/papers/heuristic/heuristic_list.html • http://www.nowwhichway.com/designpractice/lectures-pdf/DonaldNorman_4_Principles.pdf

More Related