usability

Document Sample
usability Powered By Docstoc
					Andy Brice, Oryx Digital ltd
at ESWC2007
   A quick dash through the huge field of usability:
     what usability is
     why usability is important
     how we can write more usable software
   Questions at the end
   Developing software professionally since 1987
   Interests include:
     usability, optimisation, cross-platform development,
      developer productivity, effective marketing
   Full-time MicroISV since Jan 2005
     product: www.perfecttableplan.com
     consulting services to other software companies, big and
      small
   Blog: www.successfulsoftware.net
   Email: andy@oryxdigital.com
   Bad ol’ days
     maybe read a review in a PC magazine
     go to shop
     look at 1 or 2 choices available
     pick software with nicest packaging
   Internet consumer nirvana
     read reviews on forums and blogs
     look at lots of product websites
     trial several most promising
     buy the best one
  Heard of?
Credible website?
  Does what I want?

     Right price?

     Easy to use?
   Highly usable software is:
       familiar
       predictable
       consistent
       responsive
       efficient
   Result:
       shorter learning time
       reduced time to perform a task
       fewer errors
       improved decision making
       happier customers
       more sales
       increased GGH (Gross Global Happiness)
 “A user interface is well designed when the program
  behaves exactly how the user thought it would” Joel
  Spolsky
 Occurs when the model of the world presented to
  the user closely matches their own mental model
   There is no ‘intuitive’, only familar
     “The only ‘intuitive’ interface is the nipple. After that it's all
      learned.” Bruce Ediger
   Make your app look/behave like other apps the user is
    familiar with
     e.g. Outlook, Excel, Word, Internet Explorer
   Follow platform conventions
   Use familiar idioms and patterns
     idioms: explorer, web page, shopping cart, first person shooter,
      IDE, discussion forum, media player
     patterns: browse files button, tabbed dialog, hyperlink, tool bar,
      pop-up menu, wizard
   Errors increase as responsiveness degrades
   Give feedback on all actions
     let the user know their action succeeded
     ideally within 0.2 seconds
     errors noticeably increase above 0.5 seconds
   Use timer cursor for longer actions
     ideally with % completion feedback
     group all user interaction at the start/end of a long task
     use threads to keep application responsive
   Remember that users usually have slower PCs than
    developers
   Minimise the number of clicks/key presses for
    common tasks




                 ‘Up’ is in a different place each time
   Kai’s Power Tools




MSOffice 2007 ribbon bar
   Can be more misleading than helpful
     your software will never behave exactly like a real world
      object
   May overly constrain what you can do
   Can get in the way once the user has learnt the
    software
   Know your user
     personas
   Realise that they probably think very differently to you
     try to understand and match their mental model
   What is appropriate depends on:
     how IT literate your users are
     what terminology, idioms and metaphors your users are familiar
      with
     how often your users use the software
     the platform
     the sort of tasks they are trying to achieve
   Put the user in control
   Novices use the menu
   Intermediate users use the tool bar
   Experts use shortcuts and accelerators
   Step-by-step wizards may be helpful for novices
   Defaults should be tuned to the novice
   Experts may want a command line interface, macros,
    scripting language or API
   Novice users:
     might not use double-click
     might not use right-click
     might not drag and drop
     don’t use keyboard shortcuts/accelerators
   Elderly users:
     might require larger fonts or higher contrast
   Disabled users:
     might use only a keyboard or only a mouse
     all of the above
   The user should feel they are controlling the
    application, not vice versa
     all actions initiated by user as far as possible
     allow interruption of extended tasks
     avoid disruptive validation
     avoid excessive use of modal dialogs
     don’t move the cursor for the user
     don’t overly constrain
   A well designed UI will minimise use of cognitive
    resources as well as machine resources
     less resources to drive software=more resources to solve
      real problem
   Useful to understand a bit about human perception,
    processing and memory
     limited short-term memory (7±2 ‘chunks’)
     has built in hardware for some tasks
     perception is highly complex
      ▪ uses lots of cues and assumptions
      ▪ optimised for movement/change
   Compared to a computer, brains are good at
    recognising patterns and making decisions and bad
    at arithmetic, handling simultaneous tasks and
    detailed recall
   Don’t assume users can easily commit information to
    long-term memory and retrieve it again
     it is better to allow the user to select from alternatives rather
      than try to retrieve items from long-term memory
   Don’t assume that users can hold large number of items
    simultaneously in memory
     choices between alternatives should be restricted to around 7; if
      more are required they can be organised hierarchically
   Allow for ‘closure’
     having lots of ‘open’ tasks puts a big burden on short-term
      memory, so tasks should be grouped into well defined
      transaction units
   The eye is naturally drawn to movement, so use
    sparingly
     flashing cursor
     animation
 Rapidly changing textual or numerical displays can
  be fatiguing and difficult to read
 Large blinking areas are believed to aggravate
  epilepsy
 “Everything should be made as simple as possible, but
  no simpler” Albert Einstein
 Fashion for simpler UI (e.g. 37 signals)
     ‘users only use 20% of the features in MSWord’ –
      unfortunately they all use a different 20%
   SUV effect
     users have a tendency to buy more than they need
   Trick is to provide a rich feature set while presenting
    a simple UI
   The digital SLR is a good model for managing a rich
    feature set
     complexity is hidden, not flaunted
     huge number of options (focal length, focus, aperture,
      shutterspeed, ISO, whitebalance) but usually get a fair
      result from just point and shoot
   AutoStitch just requires a list of image files and uses
    sensible defaults and intelligence to create a
    panorama
     complexity hidden in the ‘Options’ window
   The first few minutes are critical
   Spend some time getting the installer right
   Provide a soft landing
     avoid the ‘blank canvas’ effect




             Blank canvas               Soft landing
   Take the user through step-by-step
   Only show relevant information at each stage
   Don’t enforce the sequence
   Users will usually scan top-
    left to bottom-right
     use a logical ordering
     place most important
      information at top-left
     group controls appropriately




                                     Poor layout
   Only small children and idiots ask the same
    question again and again
     e.g. If the user is going to overwrite n files, give them an
      option to ‘Overwrite all’ instead of forcing them to click
      ‘Overwrite’ n times
   Tooltips and hint text can be very helpful
   Examples are easier to understand than abstract
    definitions (even for programmers)
   Most users won’t read your documentation
   Many users won’t even read what is on the screen
    (PEBKAC)
     get over it
     keep text short
     use pictures




                           Your dialog, as seen by the user
   Use words your users will understand
     e.g. if your users aren’t developers use ‘window’ instead of
      ‘dialog’ and ‘document’ instead of ‘file’
   Remember that users count from 1 (not 0)
   Why didn’t they caption the buttons ‘Abort’, ‘Debug’
    and ‘Ignore’?
   Some real error message:
     ‘This error should not occur’
     ‘(77) Unknown Bogus Error
      Code’
     ‘Nasty practice #4720’
     ‘osgbpg syntax
      error#%BootMenu already
      loaded.#Press any k"#"!’
     ‘Keyboard not present, press    Not helpful
      F1 to continue’
   Use colour sparingly as an additional cue, not as the
    only form of information
     8% of males and 0.5% of females have some form of
      colour blindness
     red-green colour blindness is the most common
     allow colours to be customisable
     check your UI on http://vischeck.com
   Don’t use large areas of saturated colour
   Get the default colours from the OS
   Colours have cultural associations
   Work better for nouns than verbs
   Try to make them all look different to each other in
    terms of shape and colour




   Beware of cultural issues
   Users should be able to turn off non-catastrophic
    warnings
   Window checklist
     Title & icon
     explanatory text/images
     consistent terminology & layout
     sensible tab order
     sensible default focus
     tooltip for each control
     keyboard shortcuts/accelerators
     context-sensitive help button
     useable on lowest spec machine e.g. 800x600 pixels
 Amount of information that can be conveyed
  through sounds much less than vision
 Many business machines don’t have speakers
 Generally not appropriate in an office environment
     make sure there is an option to turn it off
   Decide your minimum system requirements and
    test the UI under these conditions
     screen size
     colour depth
     processor
   Use web logs to decide minimum system
    requirements
   The user’s experience will be very different to yours
     you have lived this software for months/years, they will
      judge you in minutes or seconds
     you probably have very different skills to your user
     the user doesn’t really care about your software, they care
      about the task they want to achieve
   Corollary: you need user feedback
 Support emails/forum
  posts/phone calls
 Pro-active requests for
  feedback
 Instrumentation




                            crazyegg heat map
   Requires just a suitable ‘virgin’ user, PC, software
    and (if you are being fancy) a video camera
   Set tasks
   Ask user to verbalise thinking
   Don’t help!
   Rinse and repeat
 UI guidelines are being loosened
 Separation of presentation and logic
 Convergence of web and desktop
 Ribbon bar
 Animation and multi-media
 Gradients, round edges, transparency and other
  ‘eye candy’
 Experience engineering
 Metrics/instrumentation
   Concentrating on usability:
     makes users more productive and happier
     increases sales
     Is the right thing to do
   Good UI design:
     is difficult to do
     is iterative
     looks obvious in hindsight
 If a significant number of users find your software
  hard to use it’s your fault, not theirs
 But you can’t please all of the people all of the time
   ‘User interface design for programmers’ J.Spolsky
    (2001)
   ‘Designing interfaces’ J.Tidwell (2005)
   ‘Don’t make me think 2nd Ed’ S.Krug (2005)
   ‘Design of everyday things’ D.Norman (2002)
   ‘Mind Hacks’ T.Stafford & M.Webb (2005)
   ‘Programming as if people mattered’ N.S. Borenstein
    (1991)
   ‘Guidelines for Designing User Interface Software’ Smith
    & Mosier (1986)

   My blog: www.successfulsoftware.net

				
DOCUMENT INFO