Designing for keyboard-oriented users

22 Jan 2009 - 11:32am
5 years ago
5 replies
647 reads
doughollinger@h...
2008

I'm putting together a discovery and research plan for improving the usability of an equities direct trading application. The primary users of the application are day traders, and because they need to act quickly to dynamics in the market in real time, they tend to be very keyboard-oriented. They are constantly scanning across multiple screens/views and don't like to take their hands off the keyboard to use a mouse.

Thus, as we look to improve the interface and functionality of the application, we need to keep mouse usage to an absolute minimum. The traders like to use hotkeys and shortcuts to execute standard commands. In addition, they would like the ability to execute more complex workflows by setting up customizable hotkey shortcuts. Any new UI will need to accommodate this behavior.
Has anyone developed for this kind of environment and specialized user group? Are you aware of related research that might be helpful in terms of designing for keyboard-oriented users?
Thanks in advance for any advice.

Doug
_________________________________________________________________
Hotmail® goes where you go. On a PC, on the Web, on your phone.
http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208

Comments

22 Jan 2009 - 4:41pm
Chauncey Wilson
2007

This is an interesting note since keyboard design to support high-volume
users where errors can be catastrophic is not all that common though there
are still many, many users like yours and order-entry clerks, and sales
professionals, who use tools not to mention tech support personnel.

Some really basic things and later this weekend, I'll try to dig up some of
my references on keyboard design issues:

1. Preventing errors. I've worked with traders and they move quickly so
you want to avoid having high-frequency "save" keyboard functions adjacent
to low-frequency, but destructive keys. You want to avoid bad one-off
errors.
2. Awkward combinations of shortcut keys that require a stretch or that
result in undue crossing.
3. Mnemonic value
4. Data entry forms and data validation (don't interrupt too much with
inline validation)
5. Lag times and typeahead problems
6. Consistency among their specialized apps and with standard apps
7. Feedback for key operations that allows the user to start again after an
interruption (of which there are many)
8. Data logs would be quite useful here.
9. The GOMS KLM model could be quite helpful in your work since you can
model keystroke and mouse operations and get estimate of tasks times early
in design.
10. The design of all forms and use of keyboard efficient widgets. For
example, instead of yes/no/maybe radio buttons, you would just use a text
field since they would quickly learn the 3 codes.
11. The use of efficient and consistent codes for text entry where you
don't want to force mouse-focused widgets on the users.
12. Consistent rules for assignment of keyboard accelerators, shortcuts,
function keys.

Chauncey

I'll dig up some references

On Thu, Jan 22, 2009 at 12:32 PM, Douglas Hollinger <
doughollinger at hotmail.com> wrote:

>
> I'm putting together a discovery and research plan for improving the
> usability of an equities direct trading application. The primary users of
> the application are day traders, and because they need to act quickly to
> dynamics in the market in real time, they tend to be very keyboard-oriented.
> They are constantly scanning across multiple screens/views and don't like to
> take their hands off the keyboard to use a mouse.
>
> Thus, as we look to improve the interface and functionality of the
> application, we need to keep mouse usage to an absolute minimum. The traders
> like to use hotkeys and shortcuts to execute standard commands. In addition,
> they would like the ability to execute more complex workflows by setting up
> customizable hotkey shortcuts. Any new UI will need to accommodate this
> behavior.
> Has anyone developed for this kind of environment and specialized user
> group? Are you aware of related research that might be helpful in terms of
> designing for keyboard-oriented users?
> Thanks in advance for any advice.
>
> Doug
> _________________________________________________________________
> Hotmail(R) goes where you go. On a PC, on the Web, on your phone.
>
> http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

22 Jan 2009 - 5:03pm
Oleh Kovalchuke
2006

Consider using CLI with predictive typing and suggestions for complex
workflows (hotkeys are quicker for simple, repetitive navigation of course).

--
Oleh Kovalchuke
Interaction Design is design of time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On Thu, Jan 22, 2009 at 4:41 PM, Chauncey Wilson
<chauncey.wilson at gmail.com>wrote:

> This is an interesting note since keyboard design to support high-volume
> users where errors can be catastrophic is not all that common though there
> are still many, many users like yours and order-entry clerks, and sales
> professionals, who use tools not to mention tech support personnel.
>
> Some really basic things and later this weekend, I'll try to dig up some of
> my references on keyboard design issues:
>
> 1. Preventing errors. I've worked with traders and they move quickly so
> you want to avoid having high-frequency "save" keyboard functions adjacent
> to low-frequency, but destructive keys. You want to avoid bad one-off
> errors.
> 2. Awkward combinations of shortcut keys that require a stretch or that
> result in undue crossing.
> 3. Mnemonic value
> 4. Data entry forms and data validation (don't interrupt too much with
> inline validation)
> 5. Lag times and typeahead problems
> 6. Consistency among their specialized apps and with standard apps
> 7. Feedback for key operations that allows the user to start again after
> an
> interruption (of which there are many)
> 8. Data logs would be quite useful here.
> 9. The GOMS KLM model could be quite helpful in your work since you can
> model keystroke and mouse operations and get estimate of tasks times early
> in design.
> 10. The design of all forms and use of keyboard efficient widgets. For
> example, instead of yes/no/maybe radio buttons, you would just use a text
> field since they would quickly learn the 3 codes.
> 11. The use of efficient and consistent codes for text entry where you
> don't want to force mouse-focused widgets on the users.
> 12. Consistent rules for assignment of keyboard accelerators, shortcuts,
> function keys.
>
> Chauncey
>
> I'll dig up some references
>
> On Thu, Jan 22, 2009 at 12:32 PM, Douglas Hollinger <
> doughollinger at hotmail.com> wrote:
>
> >
> > I'm putting together a discovery and research plan for improving the
> > usability of an equities direct trading application. The primary users of
> > the application are day traders, and because they need to act quickly to
> > dynamics in the market in real time, they tend to be very
> keyboard-oriented.
> > They are constantly scanning across multiple screens/views and don't like
> to
> > take their hands off the keyboard to use a mouse.
> >
> > Thus, as we look to improve the interface and functionality of the
> > application, we need to keep mouse usage to an absolute minimum. The
> traders
> > like to use hotkeys and shortcuts to execute standard commands. In
> addition,
> > they would like the ability to execute more complex workflows by setting
> up
> > customizable hotkey shortcuts. Any new UI will need to accommodate this
> > behavior.
> > Has anyone developed for this kind of environment and specialized user
> > group? Are you aware of related research that might be helpful in terms
> of
> > designing for keyboard-oriented users?
> > Thanks in advance for any advice.
> >
> > Doug
> > _________________________________________________________________
> > Hotmail(R) goes where you go. On a PC, on the Web, on your phone.
> >
> >
> http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > Unsubscribe ................ http://www.ixda.org/unsubscribe
> > List Guidelines ............ http://www.ixda.org/guidelines
> > List Help .................. http://www.ixda.org/help
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

22 Jan 2009 - 6:23pm
Mark Young
2008

I studied users and designed UI for 3ds max which has a very powerful
system for hotkey customization. 3d artists depend heavily on hotkeys
and resemble your users in that they use the software all-day
every-day. Some of my observations:

1. The customization dialog is a crucial part of the interface.
Assuming that there are a lot of commands, this includes:

a) A list of commands that can be assigned to hotkeys and
key-combinations. This list should make it immediately clear which
commands are unassigned or assigned, and which keys are associated
with each command.

b) If there are a lot of commands then it may be helpful to
categorize commands to make lists more manageable. However, different
users may have different ontologies so categories can make some
commands harder to find - commands might belong in more than one
category.

c) If the commands have names that are not obvious to every user, the
list should pair descriptions with the command names.

d) If the lists are long and users aren't always sure about a
command's name, many wish to find commands with a text search -
another reason to pair commands with descriptions.

e) The method for indicating the hotkey or key-combo should be simple
and informative. Max's method had a text field that you can click on
and then "type" your hotkey or key combo - some people were
confused initially, not realizing that they should simply press a key
combo. After entering a hotkey or combo, the command-hotkey pairing is
indicated in a prominent way. If a hotkey is being reassigned from
another command then there should be a way to cancel the new
assignment.

2. Users like having a keyboard map of their hotkeys. Softimage XSI
has a very nice map that is part of the hotkey assignment GUI. If the
list of commands is not too long, it might be better to have a
keyboard-map-oriented GUI rather than the command-list-oriented GUI
described in #1.

3. It should be possible to export the hotkey mapping so that you can
import it on another computer. Or figure out some way to make it a web
resource that can be connected to from any machine.

4. Users should be able to add "scripts" to the list of commands
that they can map to hotkeys. These scripts are lists of other
commands. Its nice to integrate the GUI for editing these scripts
with the hotkey assignment GUI. The GUI might include a simple text
editor for scripts but how do you enter a command into the script?
Max has a feature called the "Command Listener" that makes this
easy: Each time you execute a command with the GUI, the command's
script syntax appears in the Command Listener's buffer (looks like a
scrolling command shell - it might be only one or two lines tall but
you can scroll to see the previous umpteen commands). Then you can
copy the script for a command from the Command Listener and paste it
into the script editor.

5. Users who use hotkeys heavily still use menus and tool buttons
too. There are some commands they [almost] always execute with
hotkeys and others that they [almost] always execute with
point-and-click even if all commands could be assigned to hotkeys.

6. Even if the hotkey customization facility is excellent, many users
will complain loudly when you change the default mapping.

-Mark

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37518

23 Jan 2009 - 2:46am
Maria De Monte
2008

Reading your post I was thinking about how blind users use the
keyboars ( and not more than a keyboard) to control their movements
on the screen, through the screenreader. As far as I could see, they
are also concerned with not moving hands away from the keyb, as this
would make them loose cognition of the page. In the same time, they
use many combination of keys to switch from one "mode" to the other
(i.e. sequential page reading to mouse simulation and so on...).
Probably taking a look at how these software works could give you a
few hints on how to develop yours.

Cheers,

Maria

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37518

23 Jan 2009 - 3:00am
Angel Marquez
2008

Ableton Live <http://www.ableton.com/downloads> has a key map mode and a
midi map mode. Toggle to either mode and select the UI element you want to
map to it to and hit the key or turn the dial and you are in business. It's
convenient when you want to use real time dial, slider, and kill switches.
The demo allows you to do this easily, the mode switch is in the upper right
of the UI: KEY or MIDI.
Propellerhead Reason <http://www.propellerheads.se/download/> has the same
modes.

The apps are built to support different control surfaces.

M-AUDIO <http://www.m-audio.com/>manufactures a lot of the haptic devices
that map directly to the apps.

On Fri, Jan 23, 2009 at 12:46 AM, Maria <mtdemonte at yahoo.it> wrote:

> Reading your post I was thinking about how blind users use the
> keyboars ( and not more than a keyboard) to control their movements
> on the screen, through the screenreader. As far as I could see, they
> are also concerned with not moving hands away from the keyb, as this
> would make them loose cognition of the page. In the same time, they
> use many combination of keys to switch from one "mode" to the other
> (i.e. sequential page reading to mouse simulation and so on...).
> Probably taking a look at how these software works could give you a
> few hints on how to develop yours.
>
> Cheers,
>
> Maria
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=37518
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Syndicate content Get the feed