guidelines

guidelines - 2/15/10 Basic Guidelines Design Guidelines...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 2/15/10 Basic Guidelines Design Guidelines I CSCI 264 – Design of Human ­ Computer Interface Design for consistency Provide feedback Help users learn system Prevent errors and provide error correcCon Minimize use of short ­term memory Avoid unnecessary spaCal ­linguisCc conversions •  Control response Cme •  •  •  •  •  •  About Guidelines •  OIen become obvious to users of poorly designed interfaces •  Are easy to ignore when deadlines approach •  Are neither complete nor orthogonal •  Have psychological underpinnings •  Guidelines are NOT absolutes Design for Consistency •  Avoid special cases, complex rules, and side ­ effects •  Consistency allows user to generalize, avoids frustraCon •  Consistency has different implicaCons at different levels of abstracCon Design for Consistency •  Example: Xerox Star –  Moving an icon to the file cabinet, mailbox, or trash can causes the icon to disappear –  What should happen when an icon is moved to the printer? –  PossibiliCes: 1. Delete the icon (and hence the file). 2. The icon disappears "in" the printer 3. Return icon to original locaCon. (Actual choice for Star) Lexical Level •  Coding consistent with common usage: –  Red = bad, green = good –  LeI = less, right= more •  Consistent abbreviaCon rule –  Equal length (LAX, SFO, BWI) –  First set of unambiguous characters •  Mnemonic names instead of crypCc codes •  Devices used same way in all phases of interacCon –  Character delete key is always the same –  Programmed funcCon key meanings are consistent throughout applicaCon –  Menu command placement is consistent 1 2/15/10 SyntacCc Level •  Error messages placed at same place (Logical place, not necessarily physical place) •  Always give command first (or last) •  Menu items always at same place in menu (muscle memory) SemanCc Level •  Global commands always available –  Help –  Cancel (command being specified) –  Abort (command underway) –  Undo (completed command) •  No side effects (orthogonality of commands) •  OperaCons valid on all reasonable objects –  If object of class "X" can be deleted, so can object of class "Y" Conceptual Level •  Metaphoric Consistency •  Role Consistency (objects with same roles) –  structure –  sets of acCons –  relaConships Inconsistency Example •  File drag and drop: –  LocaCon on same disk = file move –  LocaCon on different disk = file copy –  Trashcan = file delete •  Categorical Consistency –  similar acCons on enCCes of same type –  "stereotypes" have expected properCes •  Is this good or bad? •  Hierarchical Consistency –  Inheritance –  Containment Feedback •  Feedback provides a context in which user works and makes the system more obvious •  Types of feedback: –  SemanCc –  SyntacCc –  Lexical SemanCc Feedback •  Command received •  Command in progress –  Placebo –  Intermediate results –  Countdown/progress bar –  Restate command for confirmaCon/clarificaCon •  Command completed •  All three are not always necessary –  Final results –  Prompt for next command 2 2/15/10 SyntacCc Feedback •  "Word" being entered is grammaCcally valid –  reverse video menu item under cursor Lexical Feedback •  Cursor movement •  Keyboard (echo, repeat) •  Audio output –  Sounds –  Voice •  In command language systems, parser should not stop at first error •  HapCc –  AcCve –  Passive Feedback Placement •  Consider where the eyes are for visual conCnuity •  InserCon points –  Screen/workspace origin –  Cursor posiCon –  Manual coordinates Help Users Learn •  User skill levels –  Novice –  Intermediate –  Skilled •  Stereo/surround sound •  Prompt to tell users what to do •  Provide help on request so users can ask if they are uncertain or invesCgate a funcCon PrompCng Mechanisms •  Messages (displayed and/or spoken) –  Enter last name –  Type last name –  Type last name, followed by a carriage return Providing Help •  Types –  Task (How to perform a task) –  SemanCc (Available commands) –  SyntacCc (Parameters, order or sequence) –  Lexical (How to enter informaCon) •  Type determined by operaConal state/context: –  Prompt: ? Displays a list of commands –  Prompt: <command> ? DescripCon of command –  Prompt: <command> ... <parm> ? DescripCon of next parameter –  Prompt: <error message from system> ? Details on error recovery •  •  •  •  FuncCon key lights (scroll lock) Shape of cursor (text input, processing, poinCng) Blinking of cursor for text input Menu –  Lists all permissible alternaCves –  Appears only when input is legal –  Relies on recogniCon memory 3 2/15/10 Handling Errors •  Error Messages •  Error PrevenCon •  Error CorrecCon Error Messages •  Amount of informaCon –  Error code: IEB 0071 ABEND (blue screen) –  DescripCon: DISK FULL –  PrescripCon: DISK FULL, DELETE FILES BEFORE PROCEEDING –  PrescripCon (w/aid): DISK FULL, DELETE FILES BEFORE PROCEEDING (USE DELETE) Error Messages •  Tone of message –  Non ­threatening: FILE NAME NOT RECOGNIZED –  Threatening: ILLEGAL FILE NAME Error PrevenCon •  Why? –  Avoid "fear of failure" –  Allow faster work –  Save money/lives –  Key placement –  Distance between commands –  Menu items –  Typed names –  MoCon palerns •  Vocabulary –  User oriented –  Not technology oriented –  Consistent –  Defined in advance •  Things to consider Error PrevenCon PossibiliCes •  Suppress commands not currently available •  Entry of "starCng" token automaCcally creates "ending" token –  Start End –  ( ) –  begin end –  repeat unCl –  /* */ Error CorrecCon •  Typing mistakes   AutomaCc correcCon (while you type) –  Manual (red underline) •  Require confirmaCon of potenCally dangerous acCons, such as deleCng files •  •  •  •  Adjust posiCon before finalizing Re ­specify the parameter in error Restart command completely Undo previous commands 4 2/15/10 Short Term Memory •  Minimize reliance on short term memory •  Data plonng: –  Bad: "plot years 2 3 linestyle 3 dash" –  Beler: "plot years net gross linestyle gross dash" SpaCal – LinguisCc Conversions •  Avoid unnecessary conversions •  Brain specializes funcCon –  leI hemisphere: math, language, sequenCal analysis –  right hemisphere: spaCal and geometric visualizaCon, arCsCc expression –  Placing objects –  SelecCng quanCty –  SelecCng objects / commands •  EdiCng: –  Bad: locate/oldstring/&change/oldstring/ newstring/ –  Beler: change/oldstring/newstring/ •  Select input methods suited to type of task SpaCal – LinguisCc Conversions •  Placing objects –  absolute (X,Y) – linguisCc –  relaCve (posiCon relaCve to other items) – spaCal Response Time •  Needs are very dependent upon user expectaCons •  Lexical –  Appears instantaneous •  SelecCng quanCty –  absolute (know value) – linguisCc –  relaCve (more, less) – spaCal •  SyntacCc –  Nearly instantaneous •  SelecCng objects / commands –  absolute (recall, enter name) – linguisCc –  relaCve (word/icon menu) – spaCal •  SemanCc –  1 to 2 seconds for "simple" work –  User expectaCons vary for complex work Response Time •  Longer mean, smaller deviaCon preferred to shorter mean, higher deviaCon •  Cost of slow response –  Response Cmes 10% to 20% different sCll perceived as the same Style Guides •  Sets general guidelines for a specific project •  Especially important for mulC ­person projects, and for "integrated" systems •  Some parts of style guide can be embedded in soIware tools •  Some parts of style guide may be "enforced" by design reviews –  person idled (cost about $0.01/sec for $75K employee) –  equipment idled –  most cost ­accounCng systems do not capture informaCon needed to analyze true costs 5 2/15/10 Style Guides •  Codifies guidelines in context of a specific environment: –  ParCcular equipment –  User characterisCcs –  ApplicaCon domain Style Guide Example 1. INTRODUCTION 1.1 Purpose of Document 1.2 AssumpCons 1.3 How to Use the Style guide 2.1 Design Decision Filters 2.1.1 User populaCon 2.1.2 InstallaCon context 2.1.3 Device implicaCons 2.2.1 Window management 2.2.2 OperaCng system 2.3.1 Conceptual design 2.3.2 Naming convenCons 2.3.3 InformaCon coding 2. USER INTERFACE DESIGN ISSUES •  Style guide contents 2.2 Global Design Issues –  AssumpCons –  Concepts –  Input and output convenCons –  InteracCon techniques 2.3 SemanCcs of System Concepts Style Guide Example 2.4 Grammar: Input and Output ConvenCons 2.4.1 Input grammar (e.g. CSO paradigm, modes) 2.4.2 Output grammar (e.g. screen layout, messages) 2.5 InteracCon Tasks and Techniques 2.5.1 Tasks: funcConal building blocks 2.5.2 Techniques: physical building blocks 2.6 User Guidance 2.6.1 User aids and control 2.6.2 On ­line help facility 2.6.3 Training 2.6.4 DocumentaCon Style Guide Example – "Select" •  2.5.1 Task: Select •  DescripCon: The user specifies a selecCon from a set of alternaCves on an interacCve display. The implicaCon is that there is something (an enCty) that is selectable, and that there is more than one possible selecCon. The alternaCves might consist of a set of commands, such as items in a menu, or a collecCon of enCCes, such as graphic objects. Style Guide Example – "Select" •  Task Phrase: <specify> <enCty> (from <set of alternaCves>) •  ProperCes: –  <specify>: none –  <enCty>: type as idenCfied in conceptual model (for example, command vs. graphic object selecCon may be two different tasks) –  <set of alternaCves>: ordered vs. not ordered; range(if variable set); size (if fixed set); may be implied by context if there is a 'currently selected object' –  Keyboard: enCty label type ­in –  Mouse: cursor selecCon •  Recommended Techniques: 6 ...
View Full Document

This document was uploaded on 09/02/2010.

Ask a homework question - tutors are online