Yes, it's more of a UX issue than an engineering one. But users don't give a shit. If something appears slow, no one knows/cares if it's an animation or a slow server.
It is true that Intuit inserted some explicit delays to give the impression that their software is "working" really hard to deliver value. But, TurboTax is still very snappy in response to user action. That response is often an intentionally long, slow animation carefully designed to help you keep calm through a stressful process. But, the response came quickly.
Personally, I have measured direct correlations between our apps' latency&stutters vs revenue trends. This effect has been well publicized by Google and others. Users don't consciously give much of a shit. But, their behavior in end is significantly affected regardless.
It's amazing how often people confuse discussion for mathematics...
Also: if an operation is fast, you always have the option to make it appear slower. The inverse is not true.
That's just too general of a statement. That's like saying a landing page with a hero image is, generally, a better page. It's a good place to start, but it's just bad advice in the long-term.
I agree that response times from the backend should be fast, especially the initial response (as the article mentions). But anything on the frontend experience should be judged on a case-by-case basis.
Every time I've ever conducted user experience testing the results have always been far more positive the faster the app or page is. In fact, while it's still only anecdotal, I have never seen a decrease in any of the overall measurements of a user study where, between two versions, the speed of the app or page improved and little else changed.
Honestly I think it's a great general statement. I'm sure there are exceptions but that's the case with almost any general rule of thumb.
> That's like saying a landing page with a hero image is, generally, a better page.
No, not at all. Speed isn't everything and no one was suggesting that. A faster application, however, is always better than a slow one as long as you are comparing apples to apples.
With the way technology works nowadays it's actually very doable to get the 75th percentile to load really, really fast. But it's not without effort and earlier work may need to be redone, something many avoid at all costs.
Even if the message is nonsense, I just want to know work is still occurring
"Reticulating splines" may not mean the app is just reticulating splines, but I know it's doing something, and I'm less concerne my Sim City hasn't loaded
But with things like my iPhone where the UI just halts after some requests and quits responding to input without me knowing why, is bullshit
I want my software to listen to me and inform me about the status of work I'm performing
I wish more work was done in operating system UIs informing users. I use a terminal a lot and can see what's going on as I work
The OS should be capable of detecting overload, and take control enough to alert to degraded general operation and inform as to what's up. Possibly offering options to resolution
I can't recall the numbers, but it was something like under xxxms was consitered "instant" and therefore wasn't an annoyance, from xxxms to 1 second is consitered annoying because it's too slow to be "instant" but not slow enough to let you context switch. Then from like 3-5 seconds was another "island" as it's enough time to context switch then return.
The end of the study found that by delaying some actions that were in the "valley" to be slightly longer and making them consistent it was reducing frustration while using the application.
Also, I ditched TurboTax for TaxACT in part because it was a much less ponderous experience. Anecdotes aren't data and all that, but I doubt TurboTax is super sophisticated about measuring their in app funnel.
I feel like Hacker News is pretty much the best example for the concepts mentioned in the blog post and it proofs that beeing fast can be a sites main feature (or one of them).
I just ran a split test (>99% significance) where adding a heavy Salesforce chat widget to the site correlated with a 40% increase in the primary CTA actions taken. Adding in the chat leads, it was more like a 70% lift. From making the page load more slowly.
We verified that one a few times, but the results were consistent.
Also, performance is important in the same sense that efficiency is important. If you can run the same logic with half the processing power you'll be able to either run more processes or shrink the necessary processor size.
Software may be a heavenly world of abstraction, but in the end the hardware has to pay for our sins.
Too often speed is seen as a back-end engineer thing when it should be handled the same way as any customer-facing feature.