Loading ...
Sorry, an error occurred while loading the content.

223User interface, keyword USER [Was: Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]]

Expand Messages
  • Jon Kern
    Aug 1 7:55 AM
    • 0 Attachment
      it's all about the users and their needs...
       
      the notion that user interactions (like Tab) are idiomatic, does not mean that they are optional. For example, when I travel/live in foreign countries, I am very careful not to use idioms (since idioms are locale-specific).
       
      ...the worse offense to the users moving from field to field via the mouse would be if the UI design (for example, for a standard POS system) prohibited the use of a Tab, that is, if the idiom was not supported.
       
      the favorite Cooperism for me is "the inmates are running the asylum" -- too many times, apps are driven by technology and not user or stakeholder needs. I've seen such brain-dead stupid UI designs -- for example, an application to supposedly help a Physical Therapist enter their daily work, patient stuff, etc. Or, the new-and-improved Windows-based library catalog system that frustrates the heck out of customers and librarians alike, making them swear under their breath that the old system was just fine and that programmers stink. Or the lovely airline systems with arcane escape codes for doing weird functions at the "terminal."

      -- jon

      -----Original Message-----
      From: Larry Constantine [mailto:lconstantine@...]
      Sent: Saturday, July 31, 2004 5:49 PM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

      I have been following this thread while doing a training this week with
      barely time to read much less reply. I'll respond to several different
      postings in one rush.

      Keyboard "shortcuts" like <Tab> to go to next field or <Alt>+<Tab> to switch
      windows are interaction idioms (yet another useful Alan Cooper coinage).
      Like idiomatic expressions in ordinary language, they do not really make
      sense but have acquired meaning through conventional association that has
      little or no relationship to their literal meaning (if any). They are not in
      any reasonable sense intuitable.

      Supporting <Tab> and <Shift>+<Tab> is an absolute requirement for all
      Windows apps and Web forms not only because it’s the standard but because
      many (though certainly not all) users expect it. The ones who don't know
      about or expect it are unaffected but the ones who routinely rely on it are
      deeply affected if you don't do it or do it right. Getting it right is more
      than just supporting field-to-field tabbing but supporting it in a way that
      enhances usability, which means getting the right tab order that makes sense
      with the likely use of fields, sequencing vertically or horizontally
      depending on the workflow and how user thinks of the fields, planning the
      right field behavior onfocus and onblur, etc. For some users (heavy
      keyboarders, production staff, etc.) in some applications, these details can
      make as much as 40-50% difference in end-to-end productivity.

      Back to Jeff's original post, the preference for keyboard or mouse is not
      only an individual trait but it is heavily conditioned by context. Some
      evidence suggests that, aside from habit and manual skills, users shift
      between mousing and keyboarding to fit how they see the immediate task or
      the upcoming one. (For example, changing from one idiom to the other when
      they reach the bottom of a screen with content "below the fold.")

      Contrary to the claims of keyboard fanatics and the now largely discredited
      early Apple research, one technique is not necessarily or universally faster
      than the other. In general, most people can type successive keystrokes
      faster than a move-to-mouse, saccade-and select, move-back, but this is not
      always the case nor is it the whole story. For example, all but highly
      trained clerks doing repetitive heads-down data entry make a distinct
      (sometimes fairly long) pause at the end of entering each field anyway
      during which they typically reread what they have typed, confirm its
      content, form the intent to move on, mentally select the method (interaction
      idiom), and execute it. In most work contexts where there is not high volume
      input, the impact of the user choosing the "wrong" idiom is minimal.

      In any case, as interaction designers (or developers subbing in as
      interaction designers) we have a responsibility to understand our users and
      the context of use. Responding to the Phlip remark about expecting keyboard
      competence and weaning users off help, we always have to see the
      "time-and-motion" thing in the larger context. In a POS app, the total
      number of fields and user steps per customer is typically relatively modest.
      The savings of seconds here or there through keyboard rather than mouse
      operation will be unlikely to have much impact on the length of the queue.
      Far more important is presentation and interaction design that reduces the
      chance of error and that promotes rapid learning and acquisition of skill
      (high turnover means many users will be still ramping up). Just one need for
      a supervisor void can cancel out the gains from thousands of keyboard-only
      steps. Or consider the user typing-and-tabbing at a snail's pace because
      they are trying to figure things out on a poorly conceived screen. Or the
      clerk flumuxed by a message that makes no sense....

      As we consultants say, it all depends. By exquisite attention to what nurses
      actually do when charting and managing patient care, right down to shaving
      milliseconds here and there, we and the crack team at McKesson were able to
      speed these tasks by almost 50% while cutting training time to a fraction of
      what it was.

      --Larry Constantine [mailto:lconstantine@...]
        Chief Scientist
        Constantine & Lockwood, Ltd.
        58 Kathleen Circle | Rowley, MA 01969
        tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com



    • Show all 102 messages in this topic