Usability Principles Concepts, Principles, Guidelines Agenda • Usability Principles – Why? – Systems of categorization – Levels of detail – Example system of Principles 2 Why Principles & Guidelines? • …Because, well, not everything goes… • Intended to prevent many bad designs, before they begin, or evaluate existing designs on a scientific basis • Guidelines based on previous designs, experimental findings • Rules can all be “broken” (but usually in order to satisfy another principle) 3 Concepts, Principles, Guidelines • No “cookbooks” • No simple, universal checklists • There are many concepts, principles, and guidelines • Understand the higher level principles that apply across situations, display types, etc. • Implement the standards and guidelines …a few details… 4 Levels of Consideration 1. Meta-display level – Apply to the whole system, across media & across displays – Focus on this in Basic Layout Stage 2. Display Layout – Apply to groups of elements in a display – Focus on this in Prototyping and Redesign 3. Element level – Details about specific parts of a display – Colors, sound attributes, symbols 5 UI Design Principles (Dix et al.) • Categories 1. Learnability • support for learning for users of all levels 2. Flexibility • support for multiple ways of doing tasks 3. Robustness • support for recovery • Think about these in terms of meta-display, display, and element levels 6 1. Learnability Principles • Ease with which new users can begin effective interaction and achieve maximal performance – Predictability – Synthesizability – Familiarity – Generalizability – Consistency 7 Predictability • What will this action do?…. • Operation visibility - can see avail actions – grayed menu items – menus vs. command shell 8 Synthesizability • Support for user in assessing the effect of past operations on current system state Can the user figure out what caused this error? – Moving a file in UNIX shell vs. GUI – Is same feedback needed for all users, all apps? 9 Familiarity • Does UI task leverage existing real-world or domain knowledge? – Really relevant to first impressions – Use of metaphors • Potential pitfalls (see next page) – Are there limitations on familiarity? • (e.g. parking lot colors and traffic light) 10 Generalizability • Can knowledge of one system/UI be extended to other similar ones? – Example: cut & paste in different applications – Does knowledge of one aspect of a UI apply to rest of the UI? • e.g. file browser in OS, file locater in MS-Word – Aid: UI Developers guidelines 11 Consistency • Likeness in behavior between similar tasks/operations/situations – In different things • interacting • output • screen layout • Is this always desirable for all systems, all users? 12 2. Flexibility Principles • Multiplicity of ways that users and system exchange information – Dialog Initiative – Multithreading – Task migratability – Substitutivity – Customizability 13 Dialog Initiative • Not hampering the user by placing constraints on how dialog is done – User pre-emptive • User initiates actions • More flexible, generally more desirable – System pre-emptive • System does all prompts, user responds • Sometimes necessary 14 Multithreading • Allowing user to perform more than one task at a time • Two types – Concurrent • Input to multiple tasks simultaneously – Interleaved • Many tasks, but input to one at a time 15 Task migratability • Ability to move performance of task to entity (user or system) who can do it better – Auto-pilot/FMC in planes – Spell-checking – Safety controls in plant • For what kinds of tasks should the user be in control? 16 Substitutivity • Flexibility in details of operations – Allow user to choose interaction methods – Allow different ways to • perform actions • specify data • configure – Allow different ways of presenting output • to suit task, user 17 Customizability • Ability of user to modify interface – By user - adaptability • Is this a good thing? – By system - adaptivity • Is this a good thing? 18 3. Robustness Principles • Supporting user in determining successful achievement and assessment of goals – Observability – Recoverability – Responsiveness – Task Conformance 19 Observability • Can user determine internal state of system from what she perceives? – Browsability • Explore current state (without changing it) – Reachability • Navigate through observable states – Persistence • How long does observable state persist? 20 Recoverability • Ability to take corrective action upon recognizing error – “UNDO” – Difficulty of recovery procedure should relate to difficulty of original task – Forward recovery • Ability to fix when we can’t undo – Backward recovery • Undo previous error(s) 21 Responsiveness • Users perception of rate of communication with system – Response time • Time for system to respond in some way to user action(s) – Users perceptions not always right – Consistency important – Response OK if matches user expectations 22 Task Conformance • Does system support all tasks user wishes to perform in expected ways? – Task completeness • Can system do all tasks of interest? – Task adequacy • Can user understand how to do tasks? – Does it allow user to define new tasks? 23 Application of Principles • In doing design and implementation of your project, revisit this list • Assess your design against these usability principles • REMEMBER: There are other principles! 24 Upcoming • Human Capabilities – Physical – Cognitive 25 Some Practical Principles • The following pages contain a number of different, practical guidelines at each of the three levels (meta, display, and element levels) • Some are the same or similar to ones we have discussed in class • Some are more specific • They have proven useful to me, but, of course, your mileage may vary 26 Meta-display Principles, I • Navigation model – Decide on one navigation metaphor (e.g., menu structure vs. home page), and use it consistently. • Consistent navigation cues – Families of logos, color schemes, and sounds used to indicate displays are related. Be subtle, consistent, and don’t forget aesthetics! • Fail-safe design principle – Allow user to go back to previous items, steps, screens, etc. Allow user to undo as many actions as possible. Provide a true “Quit” or “Cancel” option. 27 Meta-display Principles, II • Open-ended vs. Task completion model – Distinguish between browsing (open-ended) interaction, and task completion behavior. • Concert vs. Conversation model – A continuum of interaction types from passive recipient of the information (“concert”) to ask-and-respond dialog between the user and the system (“conversation”). • Computer vs. Appliance model – May need to avoid “computerese” and jargon. 28 Meta-display Principles, III • Logo/icon principle – Top level has a logo (or melody). Lower levels have icon version of logo (or “theme” of melody). • Family of logos principle – Related applications have icons (and earcons) that form a “family;” in fact, a simple symbolic language to help users navigate. • Process preview and progress indicators – Provide a preview or summary of what is to come, and provide an indication of how far along the user is at all times. 29 Display Level Principles, I • Compatibility (cognitive and physical) – Left is left, up is up. Align display dimensions (in all modalities!) with real-world data dimensions. • Familiarity principle – Provide users with interface items that relate to their real world. • Appropriate medium/modality – Choose the best medium to display a given type of information (like function allocation). • Population stereotypes and mappings – Where possible, build on the expectancies of your user population (red = stop; high pitch = hot). 30 Display Level Principles, II • Process flow = display flow – (Western) readers work left-to-right, top-to-bottom. If there is a most frequent order of actions, design display to correspond (left or up = “back;” right or down = “continue”). • Conceptual size = hierarchical position – Items, objects, groups that are larger (even conceptually) or hierarchy are displayed before smaller items (take note of process flow). • Group like items – Items similar in content or function should be grouped together n space or time. They should share spatial, physical, or temporal attributes. 31 Display Level Principles, III • Continuous vs. Discrete data – Does data “flow” or is it displayed in “chunks”? • Object + action vs. Action + object (action grammar) – Is an object selected, then an action indicated, or vice versa? • Most important info in “center” – Center the important info in the display space (both visual and auditory). Controls in the periphery. • Avoid modes – Each display should have one meaning only, and certainly only one meaning with a screen’s context. 32 Element Level Guidelines, I • A few “controls” guidelines… • Label-Action match – Controls say what they do, and do what they say. Consistent both within and across applications. Note: “OK” is not okay! • Button location / icon /action compatibility – (1) Control icon is compatible with action – (2) Control location is compatible with the action (and with the icon) • Consistent menus – Menus should be consistent within and across applications. Most frequently used options located to the top and left. 33 Element Level Guidelines, II • Several auditory guidelines… • Duration: 100 ms minimum • Loudness: 10-15 dB over ambient; max 90 dB • Onset (“attack”) rate: 1-5 dB per second; 20 ms minimum • Frequency: 300 - 3000 Hz. Varies with age. • Levels of data in a dimension: – Intensity (pure tones) 4-5 – Frequency 4-7 – Duration 2-3 34 Element Level Guidelines, III • More auditory guidelines… • Appropriate spectrum – Complex spectral features for warning or detection; transients for localization; simple spectrum for discrimination • Avoid similar frequencies – (Leads to “beating”, poor discrimination) • Use population expectancies for mappings – Louder, brighter, faster, higher pitch = “more” or “up” – Rising pitch = “moving up” or “getting full” – Major key, bright spectrum = “happy” or “good” Note: Make sure you know which population stereotypes apply (e.g., sighted vs. blind listeners) 35