Keyboard vs Mouse

Maybe it is because I am enamoured with the world's ugliest, but potentially coolest mouse, or maybe it's that my own mouse is developing quirks that cause me to believe that it is not long for this world, but I've been looking at acquiring a new primary HID. Along those travels, I came across a very old discussion comparing the Keyboards vs Mice. Apparently, Apple spent $50,000,000 in the late '80s, and that's when $50 million was worth something, to study the Apple Human Interface. The result was the discovery of two facts:

  • Test subjects consistently report that keyboarding is faster than mousing.
  • The stopwatch consistently proves mousing is faster than keyboarding.

Like many things tech, and especially since Apple is involved, opinions run strongly in many directions. My own concerns are my own requirements for interfacing with the hunk of plastic, silicon and dopants at my desk and what sort of experience do I offer users in the applications that I create, web or otherwise.

I gotta imagine that there are thresholds and conditions that would impact the truth of those two "facts". One person mentioned in the article says that "there are NO command key equivalents in my product, Smart Labels, except for Undo, Cut, Copy and Paste". The reasoning is that, even though the user may perceive there to be a value in using additional shortcuts, he won't allow it. That seems extreme. What happens when the desired action is hidden behind several layers of menuing or if the action is contextual and you are already using the mouse to highlight the text (modifying case through shortcuts would be very preferable to highlighting and hunting). My own inclination is to add keyboard shortcuts when time or interface will allow me. That doesn't always work and I have lost some recent battles at work to implement minimalistic interfaces that use only keyboard shortcuts.

In that case, it was a dialog box, created by a mouse event that just contained a single text input with listeners for ENTER and ESCAPE. My reasoning was that the act of calling the dialog would provide the context for the input, hence no label, and that ENTER and ESCAPE are natural behaviors. As I said, I lost and now the little interface that could have been was obliged to support a Label, a submit Button, a Cancel button (as the corner "X") and an instruction line. My opinion is that, styling aside, the interface is uglier and code is heavier. (Apparently, I might be a little bitter about this)

Anyway, where are the lines between performance and usability? I've been perusing user experience resources and the focus has been on eliminating the need for a user to think. And, for casual use software, that makes a lot of sense. However, for productivity software where a user will spend much of the day, I gotta imagine that the kind and thoughtful UI developer is going to allow for improvements in performance that occur through user training - though that means a lot more than just adding keyboard shortcuts.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1.001. Contact Blog Owner