The Economic Value of Rapid Response Time (1982)

The Economic Value of Rapid Response Time (1982)(jlelliotton.blogspot.com)

27 points by unsignedqword 9 years ago | 3 comments

The response time here is terminal/UI response to user inputs, not, say, HFT, though that might make for an interesting side discussion.

There's a related set of discussions on Jakob Nielsen's Site Formerly Known as UseIT (now the vastly less memorable "nngroup.com"): "Response Times: The 3 Important Limits": https://www.nngroup.com/articles/response-times-3-important-...

TL;DR: the limits are 0.1s, 1s, and 10s.

Nielsen also notes that response can be too fast: https://www.nngroup.com/articles/too-fast-ux/

A classic current example is of redrawn Web or application dialogs, in which the element under a pointer (mouse, finger, stylus) changes as the user is attempting to click it. An elegant solution I've seen suggested: that the UI register the click on the UI element which had occupied the spot 300ms PRIOR to the click.

(Redrawn elements are a particular problem for visually, motor-control, or cognitively disabled users -- the changes are too fast and confusing to keep track of.)

Website response times: https://www.nngroup.com/articles/website-response-times/

Time scales in user experience: https://www.nngroup.com/articles/powers-of-10-time-scales-in...

From 0.1s to 100 years.

swiley 9 years ago | |

A far better solution would be to just not draw UI elements on top of each other. I would like to point out that CLIs don't have this problem.

dredmorbius 9 years ago | | |

CLIs generally aren't highly dynamic and offer only limited screen-addressability. It's possible though for, say, a rapidly updating CLI list to get away from you.

The other element, though, is that your selector point in a CLI is very frequently (though not always) keyboard-driven, and tends to stay with the item it's on, rather than drift up or down as elements are added or removed other than by direct user control.