This means it takes a full second to load most websites or apps, and this is further compounded by slow server code, daisy-chained sequential calls, living further away from the undersea cables, and bad infrastructure.
Am I missing a detail of terminology here? By "loading spinner" I meant it in opposition to "do absolutely nothing for three full seconds and make me refresh the page with the network tab open." I didn't mean to suggest any particular indicator of a pending network request, only that there should be an indicator.
> do absolutely nothing for three full seconds and make me refresh the page with the network tab open
This is what I was talking about. A pattern I see is papering over this deficiency with a massive “spinner”. Barely noticeable for the devs accessing the app on 127.0.0.1 on fancy machines - so frustrating for everyone else.
Absolutely agree indication of activity is important. Especially so considering how buggy many of these web apps are.
For example, I've worked on add-ons to other software. But it's cloud and you gotta make certain calls back to your "host" app. Said host app responds to most calls in more than the 150ms they claim is the max. Because of what guarantees our plugin makes to the user and despite us caching whatever we can we need to make multiple such calls to make our guarantees... well guarantees.
So what can we do? Of course we show spinners while we make those necessary calls and make absolutely everything we can get away with async.
But we can't get away from things potentially taking more than a second when something isn't in cache, the host app is slower than usual and under 150ms is impossible for anything that doesn't just hit our own database.
Slow server calls and daisy chained sequential operations are both people doing a bad job. My last job had backend calls that took over 1s to do basic CRUD on a low traffic service (bouncing around a dozen micro services on the backend). That should never happen.
For this reason, they are mostly useless. Even worse than useless if errors aren't even propagated to the user.
This is only really true with stable, high speed internet connections. We still cannot take for granted that everyone has that, especially not in rural areas and double especially not on mobile devices
Suppose you're doing gig delivery. You're delivering to two customers in the same neighborhood on the same run. You drop the first order, take your photo of the drop, and the app spins. It's waiting for the photo to be delivered before it moves on. You can't get directions to the next customer until the app moves along. Why can't it just take the photo, take the text description, and hold that until service is better? Just give the driver the map, and upload the other stuff when you can.
I have similar issues with every app. It seems like every user interaction, every button press requires a round-trip to the server before the app moves to the next step. There's no reason for this. I wager that every app can keep its UI and the user's data locally, and send and receive teensy data updates.
But all "the best" software development employees (that they claim their hiring process hires) in these companies can't seem to work that out.
They require a mobile phone number now. If I give them one, they'll enforce SMS as a login path.
I live in an area with excellent cell service, except for a few miles around my house. I'm not going to try to log in, while buying something, then drive down the road and wait for the SMS.
Sheer stupid.
One would think this is the case. I agree it should be.
> That’s bizarre.
Unfortunately, it's not. It's normal operation.
The whole point of app is to gather your info from the phone and to send you tons of notifications.
And don't forget mandatory updates, when you open an app and cannot use it without updating to the latest crappy version.
Plenty could exist as a web app.
The obvious answer is because asynchronous workflows are brittle, and require intervention from the end user to correct if they break
Then most end users aren't going to care to fix it when it breaks, or be able to fix it when it breaks for a variety of reasons
Recall the driver can’t continue without an address.
There's some strong "Seeing Like a State" vibes here. I'm pretty sure these apps are intentionally designed as tools to force the users (here, drivers) into a specific flow, a flow that minimizes complexity for the vendor, reality be damned.
Another way to look at it: the job of the driver side of a delivery (or taxi) app isn't to be useful to the driver; the job is to be a remote control with which the business can control the driver like they were an automaton.
When a customer shows up saying something went wrong with the delivery, the CSRs will need evidence and if the driver did their job then they can be exonerated.
The logistics are a bit more complex than a restaurant where customers are eating at tables in the same building.
I don’t see how this benefits anyone.
This is one reason that package delivery drivers often will say that they've attempted delivery when they at best drove past the delivery point. Marking the delivery as attempted gets them off the hook for that delivery, and they can finish their shift that much faster.
Having a broken app that forces the driver to 100% complete every delivery before moving to the next one thus costs the company relatively little, but saves some complexity, missing proof of delivery, etc.
In any case, if the network is down, a spinner is a lie. It's pretending to be working on something when it's not. It should show an error at least.
I'm not entirely sure what your point is at all
If you drive away from the delivery before that photo is uploaded, then you risk not having the proof that you delivered the package successfully
That is actually worse for the driver than having to wait for the upload so they can retry immediately
Because "[driver] doesn't know where to go till it confirms the upload"
Nobody cares about quality anymore.
Satellite Internet will be slow, but should still be well under a second? I'd still expect that even extreme cases, you wouldn't expect a spinner to complete a single revolution. So it still seems unnecessary.
Anyway, I'm generally on a reliable 300 Mbit/s connection where my pings are more like 20-70 ms, so I suppose you could alter my statement to "if I see a spinner, I interpret it as incompetence".
uploading to server (xx%)...OK
waiting for response...delayed. Check again in 3 minutes.
Not as cool, but at least somewhat informative. Engineers have a responsibility to push back on this kind of thing, because marketing people frequently do not think about failure modes or actually put themselves in the customer's shoes.It’s literally the job of marketing people to put themselves in the customer’s shoes. If engineering isn’t looping in marketing on UX challenges, or if marketing is too focused on top-of-funnel vanity metrics to engage deeply with product usability, things fall through the cracks.
But that’s a company culture issue, not a marketing deficiency.
I’m sorry you only worked with terrible, unethical, incompetent marketing people. There are good ones, just like there are bad programmers who do all sorts of terrible and dumb things without creating universal truths about programmers.
Of course marketing people do a valuable job in terms of figuring out how to sell things and minimize the gap between producers and customers. But - just like engineers - there are lots of cynical and amoral people who work in that industry who make things worse for everyone else. By contrast, I can't think of any society that is suffering because they don't have enough advertising.
If anything, societies suffer when good marketing is absent—because that’s when bad actors fill the void with misinformation, hype, and scammy tactics.
If that's your metric, I can confirm the GP's statement, at least when it comes to online marketing people. Increasingly, I can not find the right products and services online.
Except, marketing too is a market for lemons. Scammy marketing outcompetes good marketing. Simple as that.
Deceptive brands burn their audiences, lose customer trust, and either get regulated out of existence or collapse under their own churn rates. Meanwhile, companies that invest in clear, honest positioning, strong customer relationships, and long-term brand value consistently outperform in the long run. Apple, Patagonia, and Tesla aren’t winning because they spam pop-ups.
If marketing were purely a race to the bottom, all successful brands would look like clickbait farms. They don’t.
Hello fellow Canadian
Now of course if the spinner is merely cosmetic and doesn't represent any actual work going on, that can be a problem especially if the process you're waiting for dies.
I frequently put spinners just in the individual components that need loading. I tend to use them more for large data loads that will hang around awhile, so I have to do fewer round trip transactions. Loading a list of a customer's last 1000 transactions? I'm going to bring on all that data at once, not keep calling the server as you try to scroll through it.
I want user actions to have an INSTANT consequence, not 150ms latency. So even if not a spinner, that button needs to gray out and something should affirm that they tapped it.
Also, spinners are very useful for me in tracking down bugs. When a few customers report stuck spinners in the same day, I can almost immediately determine if some particular action is failing or whether it's a server issue. Even better, they can send screenshots helping me isolate the problem. If no stuck spinner and the app just freezes, they reload it and forget what exactly they did to trigger an error. And endpoints do go down, nothing has 100% uptime. I want to FEEL how long a call is taking on a heavy operation on a busy day.
The reason is that the app's backend (and many of the servers on which it depends) can be hosted on the lowest-tier-dogshit-shared-hosting plan. I would love to have a better backend server, but we are a nonprofit, and can't afford better. This app would be a lot faster, with a more robust backend.
But error handling/reporting is a true art, and should never be an afterthought. In my experience, I need to start thinking about error management, as soon as I start planning.
In my experience, the best error handling is to not have errors, and, quite often, good UX is the answer to that. If the user doesn't do something that might cause agita, then they don't get an error.
This so much. If your site is so slow that it can load what is usually a video file (non-SVG animated graphics) before it can load the text on the page, then you have failed at making a website
Looking at Discourse® here, and iirc Google AMP did something similar except it was a blank page for 8 seconds (until it hit a timeout) if you blocked their tracking
I emailed IT About it and they replied "try restarting your machine"
I then produced a video of the process for them.
I am 99.9% certain its just a poorly written SQL query, but no one responsible knows where that code is.
For most CRUD apps
Sometimes wheels within wheels can slow down even modern computers.
Server in Australia?