Speed control designed to help the user

A keyboard with a customisable extended character pad that I modelled back in 2000 - this was done in an early 1990s UNIX version of AutoCAD, and it shows!

Something with an interesting ‘forcing function’ story has been right in front of me all this time: the QWERTY keyboard, developed by Christopher Sholes and then Remington, with the intention of controlling the user’s behaviour. Until typists became proficient with the QWERTY system, the non-alphabetical layout with deliberate, if arbitrary, separation of common letters allowed the maximum typing speed to be slowed to something approaching writing speed, which reduced the amount of keys sticking and thus benefited both the manufacturer (less product failure, fewer complaints) and the customer (less product failure, less irritation). It also locked users who learned on a Remington QWERTY typewriter into staying with that system (and manufacturer, at least until the patents expired).

Whether or not QWERTY is a real example of market failure (in the sense that it’s an ‘inefficient’ system which nevertheless came to dominate, through self-reinforcing path-dependence, network effects, lock-in, etc), it’s an interesting design example of a commonplace architecture of control where the control function has long become obsolete as the configuration becomes the default way of designing the product.

Would designers today dare to create anything so deliberately idiosyncratic (even if clever) for mass consumption? (Systems that have evolved collaboratively to create complex, powerful results, such as UNIX, probably don’t count here.) The individualistic interfaces of some 1990s modelling software (e.g. Alias StudioTools, Form Z, Lightwave) which required a significant learning investment, were presumably designed with making the user experience easier “once you got used to it” (hence not really architectures of control) but have increasingly fallen by the wayside as the ‘standard’ GUI model has become so commonplace.

Today’s architecture of control is more likely to be something more robust against the user’s adaptation: if for some reason it was desirable to limit the speed at which users typed today, it’s more likely we’d have a keyboard which limited the rate of text input electronically, with a buffer and deliberate delay and no way for the user to learn to get round the system. Indeed, it would probably report the user if he or she tried to do so. Judging by the evidence of the approaches to control through DRM, such a wilfully obstructive design seems more likely.

Returning to the idea of slowing down users for their own benefit, as commenter ‘Apertome’ points out on Squublog:

“One way in which some such designs [i.e. architectures of control] can be GOOD is when mountain biking – a lot of times, they’ll put a tight curve before an obstacle to force you to slow down.”

Note how this is a somewhat different practice to deliberately reducing visibility at junctions: using a bend to slow down a rider before an obstacle does not impede riders who are already travelling at a lower speed, while it makes the higher-speed riders slow down and hence keeps them safe, whereas wilfully removing sightlines at roundabouts would seem in many cases to work to the detriment of drivers who like to assess the road ahead well before the junction, and force all to stop instead.


  1. Even a cursory amount of research indicates that the QWERTY layout was not intended to slow typists, but to allow them to type faster. The layout reduced the possibility of jams, which made the machine more efficient, not less.

    That reason has indeed been obsoleted, but it was never to slow down users.

    As you say, it’s debatable whether QWERTY is a market failure; compared to DVORAK (allegedly designed for speed), the only unbiased test on record showed that there was no advantage to DVORAK.

  2. Dan

    Well, OK, you have a point in that it allowed the typists to type more quickly, since if the keys jammed the speed would fall to zero.

    But imagine if a jam-less keyboard could have been built before the QWERTY system had become established, then ABCDEF… would surely have been more efficient than QWERTY… – at least for novice users. Assuming they knew their alphabet, there would have been less need to hunt-and-peck, and thus a higher speed could have been achieved. Hence, in comparison to this, QWERTY slowed down users, though, as you say, in a world of jamming keys, this allowed a more efficient machine, which was indeed faster than one which jammed often.

  3. I’m glad you guys mention the fact QWERTY was faster than the alternative: a jammed keyboard.

    Another thing to consider is:
    Why do we have keys staggered from row to row? ‘E’ is up and to the left from ‘D’, when it might be more useful to have it be directly above.
    Here’s a good review of one with a more rational layout:

    There’s a good write-up of Dvorak here:

    Anecdotally, Dvorak is supposed to help prevent/help with RSI, which is why I’m interested in it. (I haven’t finished learning it.)

    Apparently, world record speed typists favor Dvorak as well.

  4. Craig Brown

    I suffered with RSI. Dvorak did help and it is faster too as your fingers have less distance to travel and less is done with the little fingers.

    Rich: come back and tell us about the unbiassed speed test between the layouts! The Strong report apparently was biassed.

    I understand that most arguments in favour of QWERTY are simply because of the cost of retraining or changing equipment.

    PS I just use a standard keyboard and the Dvorak setting in the operating system. If you touch type you don’t need to change the actual layout of the keys.

Comments are closed.