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.)
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.
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.