User interface design timeframes: from 0.1 seconds to 10 years (2009)

100 milliseconds is still an atrocious amount of latency in many contexts (typing for example). There were some Microsoft usability studies of tablets, people dragging their fingers on the touchscreen to draw things. They needed on the order of single-digit millisecond latency to make it feel immediate, because otherwise you could see the drawn brushstroke noticeably lagging your finger.

It's true that human reaction time is at roughly the 100ms timescale, but that got thoughtlessly transmuted into "latency below 100ms doesn't matter" (or 200ms or whatever they read), which doesn't follow at all. The hand-eye-brain system is a very complex prediction-feedback system, used to working in real life where there's usually zero real latency between what your fingers do and how the world reacts. When primitive man threw a spear, its ballistic trajectory started the instant it lost contact with his hand, not 100ms later.

Your brain is already doing the biological equivalent of lag compensation and rollback to account for how long nerve signals take to travel and how long muscles take to move and how fast its own neurons can process information. What you consciously perceive is a gestalt model, continuously smeared over what the brain thought the world was 100ms ago, and what it predicts it will be 100ms in the future. Adding more latency and jitter on top of that can only make the error rate worse.

And doubly so when there are different amounts of latency for the different sense modalities, e.g. visual vs audio vs tactile. I remember reading about a prototype for a sinister riot control weapon that echoed people's voices back to them at a slight delay, it totally fucked up the auditory feedback that underlies the ability to speak fluently.

See: https://danluu.com/keyboard-latency/#appendix-counter-argume...

4+ hours: At most one iteration per work day. Because of the wait times, users will try to fit as many changes into each iteration as possible. Users just want to find something that works because trying alternatives can cost days, making results less optimal. Users will typically run jobs over night so they can work on the next iteration all day.

1 - 3 hours: 1 - 3 iterations per day. Users will do some exploration on the most important components. Context switching is a large cost because they have to do something else while it's running.

10 - 60 minutes: Still limited to a handful of iterations per day, largely because users don't want to do more context switches than that in a day. The run will finish sooner, but user won't be ready to switch back. Especially true later in the day as people get tired.

30 seconds - 10 minutes: Context switches can be simpler because they can be small tasks like catching up on email. Exploring different options is starting to pay real benefit here.

< 30 seconds: Context switches are now minimized, keeping the user in flow. Feels more like interactive exploration rather than idea -> do something else -> remember idea -> evaluate. Users will try lots of different options, often yielding much more optimal results.

Doing a bunch of work to get things from 5 hours to 4 hours is not of much use. Getting things from 10 minutes to 10 seconds greatly multiplies the value that others can create.

But people don't.

--

[1] which really means “we see your preference not to be stalked, but fuck you and your silly preferences”

[2] if I see the admiral³ logo in a consent pop-over my time on the site is ~0.1s as I know my choice is “uncheck literally hundreds of boxes as there is no say-no-to-all single click, accept hundreds of 3rd parties might track me, or leave”.

[3] not an issue with this site, their opt-out seem relatively sane though I did need to click a few times to make sure “legitimate interest” wasn't hidden in nested minimised content.

This stood out to me:

> This is also from The Soul of a New Machine: One of the engineers in the book burned out and quit and he left a note that read: “I am going to a commune in Vermont and will deal with no unit of time shorter than a season.”

The idea of slowing things down is a very interesting idea to me. I'm fairly certain that all the fluff in the world about moving fast actually slows us down in the long run. I also really need to read The Soul of a New Machine.

If there’s multiple dials to change, debounce and throttle aggressively to batch together as many design changes as possible.

Show a progress bar - O(n^2) algorithms suck in most regards, but one advantage is they are ideal candidates for progress bars. Initialize the bar with n steps and put a call to tick() in the outer loop, you get a very truthful and satisfying progress bar.

Take a page from web dev: don’t block the main thread. Let the user move the view around while it’s recalculating. Let the user make another design change while it’s recalculating (just start the recalculation over if they do).

For inspiration on hardcore stuff you can do to handle this “user wants to make iterative changes but each change involves heavy computation” problem, you can check out Affinity Photo. They go to extreme lengths in the pursuit of “feels like real-time feedback”, like taking a heavily scaled down copy of your image and applying the filter to that so they can show you an approximate preview of the final result while it’s computing. This is probably more effort than just making a better algorithm though.

I like the way old desktop UIs used to work: the action happened immediately, but there was also a fast animation that acknowledged it. Like, minimizing caused the window to disappear instantly, but there was also the wireframe rectangle that quickly shrank into the taskbar over the following few frames. The animation didn't interrupt user flow at all!