223User interface, keyword USER [Was: Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]]
- Aug 1, 2004it'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-----I have been following this thread while doing a training this week with
From: Larry Constantine [mailto:lconstantine@...]
Sent: Saturday, July 31, 2004 5:49 PM
Subject: RE: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]
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 its 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@...]
Constantine & Lockwood, Ltd.
58 Kathleen Circle | Rowley, MA 01969
tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com
- << Previous post in topic Next post in topic >>