Performance Matters
hillelwayne.com
hillelwayne.com
I pretty much never bother opening the laptop until I'm at the hospital. There are a lot of reasons for that, but a laggy UX isn't really one of them (despite the fact that the UX is indeed super laggy on any ePCR I've ever used). Instead I use a pen and paper (or a pen and a strip of white medical tape on my thigh, for a more critical patient).
The reason I don't bother is because the whole UI is just too much of a hassle. Not the application frontend, the whole thing. The laptop, the keyboard, etc. With a pen and paper I don't have to keep taking my gloves off and putting new ones on each time I need to switch from documenting something to caring for the patient (a pen is trivial to wipe down, or just toss if needed). With a pen and paper I can jot simple notes in a shorthand I'm familiar with, rather than having to navigate to the right page to enter the information I want to record at the moment.
I know very few providers that bother touching the laptop prior to arrival at the hospital. Generally we write notes on paper, then bring the laptop into the ER and start typing while we we're waiting for a bed for our patient (it's not uncommon that this takes long enough to get the whole chart written). At my agency we have two hours from when we transfer care to when the chart has to be signed off and locked.
I also chuckled at the suggestion that "0.1% of PCRs have errors that waste an hour of a doctor's time". In my experience 0.1% is pretty much how frequently the PCR gets reviewed at all in the ER, and anything important enough to spend an _hour_ on would have been mentioned up front during the transfer of care (nevermind the fact that an hour is an absurd amount of time for a doctor to be spending on a single patient).
Extremely relatable. Someone needs to come up with a stylus that is permanently attached to a laptop using a wire or some other sort of contraption, similar to writing pads with permanently attached pens. The slot (hole) for the stylus should still stay, so that it can be packed up/stored neatly.
The main reason it was not done yet, my guess, is because of the dangling cable from the tablet when the stylus is stored in the slot, but it could be retractable for storage or something like that.
(Thank you for the insights!)
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.
IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.
Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be.
EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.
It's just that modern software is garbage. That's all.
But over time things degrade. I don't know why, but every year or so I have to format the internal SD card to keep the OS in shape. If I install too many apps which run in the background the RAM gets crowded and everything starts lagging.
And finally, the app itself is not as optimized as it should be, so that when I use it with the data I enter during a year or so, there are some steps which take a few seconds (rendering a list with >300 items/DOM nodes). By the way, a 'couple of seconds' is unacceptable from a UX perspective.
So this is just one example where you can have a 100% good experience but also a very degraded experience with the same hardware and software, due to different factors (from OS degradation to awful O(n) optimization).
It's more than just an "optimization" that is making UIs on these plenty-fast processors so slow, it's a large scale failure of software engineering, building slow layers on top of slow layers.
The processor is not the reason for slowness, and we've had absolutely responsive UIs not just 10 years ago, but 50 years ago too. The actual reason is economic: cheap engineering. Using freely available components not well suited to embedded devices, writing layers using scripting languages because it's easy, treating the problem as solved when the functionality is there without regard to the speed.
Yes, we won't again have the responsiveness we had 30 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.
> we won't again have the responsiveness we had 30 years ago.
Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response.
Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip.
> the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over.
I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.
W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today.
With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels.
Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.
That's all true, and thanks for an insightful comment!
I would just add though that it's easy to frame things in a way that makes it seem harder than it really is to maintain responsiveness. For example, while yes caching makes guaranteeing exactly repeatable timing a problem, that's an issue at the nanosecond/microsecond level, and not really a problem at the millisecond (human perception) level at all. Today's hardware doesn't have issues maintaining 60hz unless the software isn't even trying.
Another counter-example would be that while yes, browsers and desktop UIs are doing compositing and don't have direct access to the pixel buffer, the compositing is actually done on the GPU via low-latency commands. Direct access to the pixel buffer would actually be much slower than what we have right now. The browser has no trouble responding and rendering at 60hz unless you do things that cause more than the ~16ms of compute you have time for. Triggering page reflows will do that, but compositing an animated WebGL canvas over something else on the page is plenty fast.
For example, Lenovo Carbon X1 4th gen running Windows has about 5x the latency of an Apple 2e.
Just in case you were thinking this is perhaps a counter-example to what I said, I think it's the other way around, it very much supports my claim. The processors have (obviously) gotten faster, and yet for some applications latency has seemingly gone down. Why? Software and requirements are the reason, not hardware.
Terminals also are not an example of the "best systems" in terms of latency. You'd be much closer if you looked at video game latency, or tracked industrial applications that have low latency requirements from the start. The whole reason terminals have gotten slow is that they aren't trying to go fast.
Quite a few of today's most modern terminals have recently added performance as a feature, started rendering with the GPU, and quite predictably, they are restoring super fast response times to our terminals. iTerm2 would be an example of this.
Performance is always a business decision. Most people don't want to pay for it.
Anyway, you mentioned phones: 16ms from touch to response on screen? That's hard for me to believe and I'd love to read up on that, if you got any sources. The ones I've found were not that great but don't paint such a good picture. [0] is an article claiming touch sensors scan only once per frame, aka 16ms at the time. [1] claims ~85ms to response on an iPhone 4, ~55ms on iPhone 5. How were you able to easily beat those by such a margin?
[0] https://www.anandtech.com/show/9605/the-ios-9-review/9#Input...
[1] https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-tha...
Nowadays you have 120hz scrolling on the ipad and the very fast responsiveness of things like the apple pencil, which shows you that responsive hardware and software is definitely possible.
There is no good technical reason for slow UI elements in 2019.
Windows XP on a Pentium 4 was snappier than Windows 10 is on an i7 today.
I cringe every time I see a laggy but 'nice' looking interface. I'd rather see a wireframe with just text, it will still be more useful than a button I can never trust.
This app ran on a regular computer running normal Microsoft Windows 95. It wasn't terribly complicated, but it also wasn't simple. It accessed a database over the wired network for most everything it cared about doing.
It took some thought and care, but it wasn't impossibly difficult to ensure that the app was always highly responsive.
I think it comes down to priorities. I worked closely with the doctors who were actually using this app on a day to day basis, and working with an app that didn't slow them down was quite important for them.
I'm reminded of the discussion the other day about military procurement ignoring software. Prototype the UI first, then choose a processor that's fast enough.
If the progress bar doesn't differentiate which stage it's in then it's purpose is mostly just to let the user know it's doing something.
That has always stood out as one of the more impressive engineering feats I've seen.
A friend's sister is a doctor. We happened to be visiting her hospital the week they were rolling out a new system. If if I recall rightly, her hospital was part of a multi-hospital company, and they were developing it in house. The developers were in some location distant to the hospital, and my doctor pal had never met anybody who worked on it.
From my perspective, the thing was a disaster. Not only was it laggy as hell, but the interface was dumbfoundingly bad. For a doctor to prescribe something for a patient, the would have to pick the medication name from an absurdly long drop-down. Then they could type in a quantity and pick a unit from a pulldown that had mcg, mg, g, and kg choices. Once that was entered, it would show up on the reports nurses would use to give medication. However, they didn't have the field sizing right on the reports, so 100 mg would turn into 10 mg. It was only nurse experience that kept people from getting dangerously wrong doses of their medication.
The whole thing was hot garbage of exactly the sort made in a big waterfall process by developers who never met the users and never saw them in action. I'm sure every bit of it was technically to spec, but I'd be amazed if nobody died from it.
[1] https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and...
> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
"Premature optimization is the root of all evil" is incomplete without the surrounding context, and people unfortunately take it to mean "never worry about how efficient your code is," which is not at all what Knuth intended.
What many people today mean by optimization is a far cry from that.
Here’s a real-life example. Some code was super-slow and nobody could figure out why. It took only a minute to see the code was passing a string (in C++) by value, causing unnecessary copy construction and destruction (in a tight loop, to boot).
Writing that code by passing a const reference in the first place is Good Coding 101, but many people might consider that “premature optimization”.
I've spoken with numerous people in my life who deal with these types of systems. Everyone complains. Fields for information are in unexpected places. There are too many things to click on. All of the people I've talked with agree on the same things.
It's as if no UX people were involved. The experience doesn't fit the need quite right.
What would motivate the makers of these things to improve on the situation? How are the contracts won? Do the people who have to use this stuff have a say in it? Do the hospitals and doctors offices measure stats to see what's working and what's not?
This space is ripe for disruption simply based on user experience.
The county wants to collect data on if a drowning incident happened at a pool without a locking gate. Now all services need to update their software to include a random checkbox. An EMT was caught without gloves and now the parent hospital wants EMTs to record what levels of PPE they wear on every run. The customer might get a grant if they can help track infectious diseases so now there is an extra box where the EMT can guess if the patient has the flu.
In the abstract that is good data to want to know, but it ends up being more junk on the screen for the EMT to skip over while dealing with the patient or sitting in the hospital parking lot after a run.
Furthermore, Epic is sold to administrators, not physicians. It checks all the boxes so it gets the contract.
The people making the purchasing decisions are almost always pretty removed from day-to-day usage of clinical software (and the bigger the company, the more true this is).
But how will you present to them that your new product is "better" than that of the incumbent's? You can say, "our product can do X feature 10x better than another product", but if they reply with "unless your product has dark mode for a select number of physicians who live in WA and NY state, it's going to be a no-go. We already have another quote from someone else who will do this for us", what are you going to do? You may resist at first, but in order to win the business, you too will likely repeat this process ad-nauseum, until your "MVP" becomes just a "VP".
These decision-makers are also cautious about "new" technology (and rightly so, for the most part). Since if something does go wrong with patient data, it is considered catastrophic - and who will be to blame then?
Another often-overlooked requirement: environment. Does the human using your software system have to pay attention to more important situations around them? Is the environment they're using your software in noisy, stressful, dangerous or dirty? Should you expect frequent wireless interference or degraded wireless performance?
Reading the ISO specs are pretty boring, so is the SWEBOK guide, but it's rather interesting to think about software in terms of the whole system and not as an artifact unto itself.
Paper can be edited, even after the point at which you given a carbon copy to a hospital, if you're friendly enough. This probably doesn't happen often or at all but there is a psychological safety there.
People make small mistakes all the time on the ambulance in the rush to get them to the ER. We live in an extremely litigious society.
And I don't think it's just that society is litigous, but that databases actually (mostly?) work in terms of enforcing the rules you give them.
One anecdote of how things changed was that you used to be able to arrive on post, and if you didn't like your orders, talk to a sergeant major of another unit and quietly get your orders changed, which no doubt drove PERSCOM crazy.
When things were done with paper, there was a certain degree of flexibility in the rules that gave people some amount of local autonomy. When those rules are enforced by a computer, there's much less possibility of someone being able to override the rules when it makes sense.
Normal human social interaction tends to create unwritten rules that are simply more flexible and realistic than the rules we're willing or able to write down.
We did a demo the other day to a large new customer. I learned that when they filled in the existing paper form, they didn't just sign it, they also stamped in the signature box with a little rubber stamp that "signed on behalf of the CEO".
It wasn't immediately clear whether anyone handling the form was looking for that stamp, nor what they did when they saw it. As a result, it's not clear to us at this stage whether our pdf generation now needs a new feature to allow a user-uploadable image file to be imprinted over the form.
That's the sort of thing you get with the joyous "flexibility" of paper.
Now, if all that meant was that the programmer has to do some more work, and you aren't worried about paying more for the software, this may not matter, but that is far from the only (or even most important) result of optimizing everything for performance. Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy.
For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This can result in big improvements to software performance if done in the places which are the current limiting step, but now you have to make sure you invalidate the cache correctly. In particular, if you don't, you get stale values in the cache, which is to say false data.
If you make a system with cacheing all over the place, it will be very hard to make changes correctly, which means sometimes they will get made incorrectly. In mission-critical systems, this is even less acceptable than elsewhere.
It's not just "I don't feel like optimizing". More often, it's the cost of optimizing is not worth the benefit, for this particular part of the code. How do you know what spots in the code it's worth it? You don't optimize, at first, and then see which two or three spots in the system are rate-limiting.
This made me cringe. This is filling out a form. It could conceivably be a single record (or small set) in memory that gets committed/updated somewhere else in the background. Overly complicated solutions for simple problems are one of the primary things that kills performance.
You don't have to optimize everything for performance, you just have to realize it's a primary feature and avoid doing anything that kills it. We carry super computers in our pockets, you don't have to write complex game code to get performance these days, just don't write shitty things.
I insisted, and probably still do, that since this list hasn’t changed since World War II, odds were really good that the server would reboot before the next change was made, and so looking it up at startup should be just fine.
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.
In the modern business environment, time is most often not allocated for optimization after functionality is complete. And even when it is, if performance is completely ignored throughout the development process, your options for improving it at the end are severely limited.
1. True.
2. The primary reason that most software is painful to use and occupies significantly more resources than strictly necessary.
Programmers, like everyone else, focus on their own pain spots rather than the issues of others. If you don't at least think about optimizing at first, you won't ever do it.
On one hand, it seems a clear failure. On the other hand, it's hard to judge these kinds of decisions from the outside. The product seems to be successful; the customer paid for it and installed it in ambulances. Maybe if they'd focused on performance instead of adding feature XYZ, or increased the price by adding a faster CPU, the customer would have bought something else. Your competition checks more boxes, therefore must be better!
Mostly when I see shitty software, I think not "who wrote this?" but "who bought this?"
I'm gonna repost a chart I made previously[0][1].
Spectrum of performance:
LO |---*-------*--------*------------*-------| HI
^ ^ ^ ^
| | | |_root of all evil if premature
| | |_you should be here
| |_you can be here if you don't do stupid things
|_you are here
--
LO |---*------------------*----*--*-| HI
^ ^ ^ ^
| | | |_root of all evil if premature
| | |_you should be here
| |_you can be here if you don't do stupid things
|_you are hereTo me it seems like Knuth's comment is taken out of context more often than not. He wasn't trying to give people a free pass to make things as slow as possible and ignore system performance. He was assuming that you're making reasonable choices, and not doing overtly stupid things like running the inner loop of your screen drawing in Python, just because it's easy. People always seem to forget the 2nd sentence of the premature optimization quote too: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
If responsiveness is a goal, as it should be in any GUI but especially must be in a system intended for use in medical emergencies, there are high-level decisions that can be made to keep things in the right ballpark. One of these decisions may be "the interface should never have to wait for a network response", for example.
The process of micro-optimizing specific segments of program code still needs to depend on actual benchmarks and measurements, but the value of reasonable and experienced system architecture that considers the actual requirements of the problem domain cannot be overstated. You're sunk from the get-go if you make the wrong tradeoffs here.
Unfortunately, the industry is mostly populated by clowns who are just blistering to get the hottest buzzword listed on their resume, very frequently rising up to the point of blatant professional misconduct. This leads to many truly absurdist design decisions that sink projects long before the first chunk of code goes into production.
This isn't a question of optimizing something that doesn't need optimizing. It's about making fundamental choices from the beginning that are optimized and won't need to be optimized later.
It's the choice between using native code v.s. electron to build your app. You can make the argument that electron might be better for various reasons, but if you choose to go native, that's an optimization step you are taking.
Basically, you are saying "Premature optimization is the root of all evil" without including the rest of the quote and misreading what Knuth wrote.
> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
There are certain fundamental things you can do, optimization you can do before you ever write the software. This comes from experience.
> Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy.
No, this does not have to happen. In fact, if you build it first and worry about optimization later, you're more likely to end up in this state.
> How do you know what spots in the code it's worth it?
Experience. You get that from experience with code. And you can't get that experience if you are frequently changing jobs.
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.
Worse, I can use two different programs in Windows and one will be dog-slow compared to the other.
I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there were for example programs having multiple version of the same library link into the code even while the program only used one library ever.
Also the screen layout is runned thru a layout program/library that slows things down, the layout system is great when you are designing the system, but once you reach the point of final and fixed design there are faster ways to display it.
on the other hand, management is too often cheap, and says "It works, don't it?" and do not want to pay for the extra coding that would make so much faster.
First, nobody measures performance. If they do, it is often done poorly (without using performance tools)
Second, when performance is a problem, everyone guesses on the cause. Remember how they don't measure? Well, they also will say things like "this is probably slow because of X" where X is the database, the network, a method they hate, etc.
Performance analysis requires accurate measurement.
thankfully at my work nothing goes into production without a performance eval measured at least by Lighthouse & webpagetest on Fast 3G/2015 mobile/chrome.
it's nice to be able to dictate these requirements ;)
On the other hand in Haiku everything uses the native Haiku APIs.
But from what i've seen ever since Qt and Java were ported to Haiku, a bunch of applications started relying on those to run on it instead of using the native APIs (which IMO defeats the entire point of Haiku).
Haiku does use a lot of prewritten libraries BTW, they're just hidden behind the scenes and shared among applications instead of each one bringing their own copy.
See Dan Luu's analysis here: https://danluu.com/input-lag/
and here https://danluu.com/keyboard-latency/
> Moreover, a modern computer with one of the slower keyboards attached can’t possibly be as responsive as a quick machine from the 70s or 80s because the keyboard alone is slower than the entire response pipeline of some older computers.
Haiku (BeOS) was always promoted on its native multithreading and responsive UI, with early demonstrations showing windows being dragged around while playing video, IIRC, it's impressive that it still holds to that.
But it also says a bit about what software people pay for and keep using - if sluggish Windows software has thrived, and BeOS crashed and burned. And then on Windows and Linux, light fast software gives way to bloaty huge sluggish software left and right.
So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.
EDIT: Or to put it another way: "perceived performance can be more important than actual performance".
Performance does work as fast as possible regardless. You always want more but you’re capped by the system, hardware, and algorithms and not human perception.
Feels like I’m splitting hairs though
Even when responsiveness is great, you can still work on performance to improve: resources utilisation, energy usage, jitter of responsiveness, etc. Users may not notice, but the spending account may do. This distinction is more relevant with multi-user or time sharing systems, less so with single-user game consoles. (If you're hitting the right framerate at the most demanding scenes, why bother?)
I know it's easy to dump on electron, so I will. Multiple electron apps, especially the ethereum client, are the worst programs I have ever used, because there is enormous lag on a computer that runs everything else flawlessly. It's so bad it can't even be all blamed on electron, but more than bloat or memory use, interactivity is what I consider the most important factor in an interface. I even put it above great design or intuitiveness. I would take blender's ridiculous interface choices over something better that lags like the ethereum client any day of the week.
That the task takes an hour to complete may or may not indicate a problem with performance.
The fact that the task shows a progress bar at all is likely because at some point the task would complete synchronously and without a progress bar in say 10 seconds or 60 minutes. In that case, the programmer mistake was to allow the problematic performance of the program affect the responsiveness of the program.
So a progress bar is used when the performance can't be easily fixed but the program must be responsive.
Let's say you have a client app with checkbox that toggles some boolean variable that communicates with a server. If you're on a 3g connection in an ambulance, it might take a few seconds to send that request to the server and get a response back.
An unresponsive UI would sit there and make you wait for the request/response to complete. You click the checkbox, then nothing happens, then suddenly, some time later, the checkbox is checked and the page refreshes, or a state change happens. It's jarring and weird. A responsive UI would update the state of the app based on the user's actions even if the request hasn't completed yet.
Tightly related to this the concept of optimistic UIs - the UI acts optimistically and updates the state of the app under the assumption that server-backed state changes will work. The iPhone's messages app sending messages is the prototypical optimistic UI interaction. You send a message, the blue / green speech bubble shows up on your messages app while the message is in flight. If it succeeds, nothing changes and you're none the wiser. If it fails, you get an option to delete the message or resend.
A responsive UI is necessary, but it's not sufficient to make up for a slow back end.
This seems like a lot of imagining of scenarios that may or may not have happened. Perhaps another way of looking at this is - did the company hired to build this actually care whether EMTs used their software, or were they looking to get a paycheck?
So many health tech firms fall in the latter bucket. Such is the reality of the business - with huge enterprise sales funnels and hospital networks that don't understand the value of UX & great product (and caring a lot about their bottom line), this result isn't unexpected.
"Premature optimization" in reality is a vacuous phrase, because premature anything is bad - it's right there in the word! (Insert joke here.) The problem is that most developers (myself included in many cases) are just not qualified to say when it is premature to optimize, because the requirements do not state anything meaningful about performance.
If you think this is overly pessimistic, I would encourage running pretty much any Android app or opening any major website on a 2018 or older smartphone. It's pretty obvious developers don't know how to build software for the probably 50% or more of customers who don't buy a new top-of-the-line phone every year.
As for performance guidelines, have a look at Jakob Nielsen's amazing evidence-backed UX guidelines such as Response Times: The 3 Important Limits[0]. The ones which should stick are that 0.1s feels instantaneous (probably not when using a scroll bar, but that's another matter) and 1s is the limit for not interrupting the user's flow of thought. In other words, if anything your program does takes more than 0.1s to respond to user input on the target hardware that should at least be acknowledged and prioritized (maybe at the end of the backlog, but at least then it's a known issue).
[0] https://www.nngroup.com/articles/response-times-3-important-...
When you are juggling and prioritizing a list of tasks, they are occupying short term memory. If you can perform the current task from muscle memory, you don’t upset working memory. But as soon as you start having to think about it, and worse once you start editorializing in your head, things start to drop off.
Worst case results of this phenomenon have occurred when you finish a hard task and you have to ask yourself, “what was I doing?/why was I doing this?”
So you want your tools to be unobtrusive. People who love hand tools know this. Somehow we do not.
"If I have to pay nearly as much or more attention to the use of this software than it saves me, it is by definition worthless."
Intellisense in VS/Resharper went through a nice period a few years back where it was smart enough to match what was meant, fast enough that it didn't (usually) drop keypresses, and (crucially) stupid enough that typing the same thing twice would get the same results. Sadly, all of the above have been lost in the hail of features...
Context sensitivity is not always a good thing in a tool. Muscle memory wins.
UI up front can be very fast capture, with asynch layer to parse and formalize constructs, with a third stage of prefilling the final form (if paper layout needs to be maintained etc) and allowing very flexible revision.
Last step would be archiving locally and then transmitting to whatever outside system.
Slow solutions have a dramatic business advantage: using libraries, you can shave months off your delivery schedule by adding miliseconds to your UI delays. The months add up; so do the miliseconds. By using someone else's crufty libraries, you can write a calculator app over the weekend. Libraries will handle the double buffering for screen painting, unpacking fonts and rendering them into bitmaps, how to reflow text onto a screen, etc. It might take seconds for the app to load all it's assets and display the first user activity, but it was cheap to create, easy to iterate, and it gets the job done. These are hallmarks of a valuable startup engineering effort.
But the development process for speedy applications is anathema to businesses of any size. You have to throw away Electron and hire systems engineers with knowledge of the entire platform. After some profiling, they may determine that the required speed is only possible once the system event handler has been replaced with a pared down routine, or when the framework's audio interface is bypassed so the sound card can be accessed through low-latency DMA mode. You have to repeat this for every platform you intend to support. You have to throw away the wheel that everyone else is using and pay to reinvent one that spins a little faster.
To paraphrase Joel Spolsky's comment on rewriting software: are you sure you want to give that kind of a gift to your competitor? For most companies it isn't worth it.
Are there exceptions? Yes: a motivated engineer like John Carmack may work months to eliminate another 3ms frame latency out of a VR headset simply because of personal passion. Google can amortize additional billions by wringing 100ms out of page load times by funding a browser project so complex that you also have to design a new build system for it. But if you're not Carmack and you're not Google, you probably can't afford to reinvent the wheel.
I used to work with WebForms and Cocoa (before iPhone) back when enterprise was completely allergic to web. Not only those tools were faster, but the development process itself was quicker and less traumatic than it is today. Interfaces were crude, but snappier. All grey, and users preferred using the return key to move between fields. And we could knock a calculator app in a few hours.
The landscape was much more diverse too, a lot of women, and older folks (40/50+) coming from Fox Pro, Clipper or even COBOL (mostly on WebForms). I don't know what happened to those people when everyone moved to web tech. A lot of people my age moved to backend because they find HTML/CSS/JS too hard. Cocoa guys moved to iOS. I'm on frontend + iOS now.
For the enterprise shops around here I know it all went to hell when both business AND developers started pushing modern multi-platform development: Qt, Java, Adobe, Cordova, you name it. Suddenly apps became crappier and a lot of people got pushed away from development because it was becoming too hard for them. After that everything became browser based. Mobile was weird for a while (too much Cordova), but it later settled on React Native.
I know WebForms (and Interface Builder!) might look primitive and limited to today's developers, and I might be looking trough rose-colored glasses, but I remember when it was enough to build 90% of the apps people need, you don't need John Carmack or dealing with the audio buffer directly. Since this tech still exists, I can't see why that's not the case anymore :/
As someone who works in the performance arena myself I feel like a lot of the work I do is undoing the mistakes that the attitude that it's OK to not care about performance so I'll just do it the 'easy' way. It's pretty much a form of technical debt that is somehow culturally acceptable. For years we've had Moore's law covering everyone's asses but perhaps there will be a reckoning yet.
Let's say we have a $1M/year business opportunity with a requirement that a user be able to take 1MB photos on a phone and have them appear on a PC/laptop which are both connected to a 802.11G access point and on the same internet-connected network segment. The time requirement on this phone->pc transfer will dramatically affect the software development effort in terms of time, money, and skills.
With a requirement spec of 1 photo every 10 seconds, commodity software can already accomplish this. With a cloud account from their smartphone vendor, a user can monitor their photo album from their PC browser, and photos taken on their phone will be sync'd to the cloud, then visible on the laptop. Assuming both devices are on wifi with a typical cable modem connection, the transfer of the photo from phone->cloud->PC-browser would occur within 10 seconds. No software engineering required, supports MAC/Windows/Linux and iOS/Android out of the box.
Now let's spec a 1 second transfer time. Cloud syncing is out; we'll need the phone and the PC to communicate directly over the wifi link; we'll have to write a phone app that sends the photo file over a socket, and a PC app to receive it and display it on screen. 1MB will take 500ms across a healthy 802.11G link, so we have 500ms leftover to allow the phone's camera app to store the photo as a file, for our app to establish a TCP connection, for our PC app to accept the incoming file, and display it in an ImageBox control. We can still meet the 1 second spec on a poor wifi connection... Wait, how does the phone know the address of the PC it's going to send the picture to? We'll need to write our own discovery service to allow the phone to learn the IP of the PC... Should we do layer 2 , or cloud assisted? Or maybe we'll have the phone scan a QR code on the PC in order to link the phone to the PC... We've only imposed a 1-frame-per-second requirement, but we're going to require a software team familiar with PC app development, phone app development, layer 2 and layer 3 network protocols. You could hard code the IP addresses for a quick demo, but you're looking at a small team coding in several languages for several months just to support a single platform (say, Windows PC with Android phone.) Additional platforms will require a repeated effort.
But Carmack would never be happy with 1FPS. What if we spec a 40ms transfer time (24FPS), such that the user could use the laptop/PC screen as a hollywood-movie-grade viewfinder. Now we have to throw away the phone's camera app and write our own that bypasses the save-to-file step and streams the image data directly to the PC over UDP, perhaps RTP. Since the raw camera data takes too long to send over the network, we may also need to visit image compression techniques. Some techniques will be faster on certain phones, so we'll need a heuristic compression algorithm selector to make sure we're correctly optimizing for spending the least amount of time in the combination of compression+transport. On the PC side we'll need an RTP client to receive the data, but also a method to paint the frame buffer data directly into the viewport (no more loading files into an ImageBox control). We may need to explore the gains from painting the image as an OpenGL texture. At this point, our engineering budget has exploded! We're talking about hiring telecom engineers with experience tuning VoIP stacks, digital signal processing and codecs, and video game engine experts to help with low level graphics in OpenGL/DirectX. Perhaps we'd need to retain Carmack himself to advise.
If you have a business opportunity worth $1M/year that relies on moving photos from your iPhone to your Macbook, spec'ing 10s is a great way to get your business started leveraging existing technology. Spec'ing 1s might be acceptable to give your app some polish once you're established, and if you're not FAANG and not Carmack himself, spec'ing 10ms would be a great way to kill your business regardless of size.
It does not mean that performance doesn't matter or that you shouldn't think about performance.
What it means is two things:
(1) It's usually a waste of time to tinker with small optimizations until you've made things work and until you've profiled.
(2) Don't compromise your design or write unmaintainable code out of premature concern over performance.
The second is the more important and subtile meaning. It means don't let concern for performance hobble your thinking about a problem.
Performance matters... the article talks about a case that most of us aren't confronted with.
Beside, it concludes that in spite of paper being slower, it's still prefered, so how does that prove that "performance matters"?!
Should an article be upvoted just because an article is about life and death and has a catchy (pretentiously) laconic title?
Then I bought a new one, which was faster and more responsive and my tablet usage completely changed ;-)
So I can personally testify that performance is a most relevant part of the user experience.
"Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other."
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.
A quarter-second lag does not sound like a significant problem to me, and may require a lot of IT funds to remove. Often such is only justified if it's a high-use application. Would you agree that 100 hours of extra programming to save 50 hours of data entry time is usually not worth it (all else being equal)? If so, let's start there and slice into further factors.
Please don't give me bad scores for trying to be logical and rational, people! Resources are limited, orgs have to spend with care. Sure, it's nice job security for us IT people if orgs spend big bucks to make all apps snappy, but from a business and/or accounting standpoint, it could be the wrong decision. You view the world different when your money is on the line.
If you know a way to make all apps cheap, good, AND snappy at the same time, let's here it! I'm all Vulcan ears.
Note that one can make web apps snappy, but there are often maintenance and/or creation time tradeoffs for doing such. A few well-run shops do it well, but most shops are average-run.