Performance Matters

In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration.

The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays.

I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.

One detail I've noticed is that even if you do a shitty job of hitting the deadlines, users will often find workarounds. As long as a critical mass of features respond consistently within the deadlines, users will fiddle around to make the rest work-- even if you tell them directly that it isn't possible.

Say the dropdown menus here performed fast enough, but going to the "next page" required a bunch of DOM mutation or something that grinds to a halt for two seconds. I'd bet EMTs would have trained themselves to do branch prediction-- hit the button to change pages before setting it down, hit it again based on what the patient is communicating to the other EMT, and so forth. I've seen users do weirder stuff.

The fact that they discarded it altogether tells you how bad the UI was.

I'm skeptical that's the reason they didn't use it unless it's a high-volume application. Like everything in IT, it depends.

A high-volume app definitely needs attention to response and performance because employees will be wasting tons of hours if it's not. That's why primary applications should probably be desktop client-server applications, where it's easier to control the UI. But that's typically only roughly 1/4 of all apps used by an org.

Something used only occasionally, such as for customers with special conditions, a somewhat sluggish web app is probably fine. If it's easy to make it snappy, great, but not everything is, due to our annoying web (non) standards[1]. If it takes 100 hours of programming to reduce 50 hours of UI waits over say a 10 year period, then the org doesn't benefit. 10 years is a good default rule of thumb duration for software lifetime. Your org may vary. Remember to include program maintenance, not just initial coding.

In short, use the right tool for the job, and do some analysis math before starting.

[1] My "favorite" rant is that web-standards suck for typical work-oriented productivity applications, and need a big overhaul or supplement. Nobody wants to solve this.

Your example of caching is almost basic programming, maintainable code also caches values after calculation for use elsewhere. You don't not cache the results of a database query and pass it around, that's just spaghetti.

In reality you have to break out your design into components that can later be rewritten one at a time in order to eek out performance. Easier said then done, but at a high level this first means keeping your big areas (UI, database queries, File IO, networking) separate, and work out the infrastructure from there.