> We keep adding tech and tools and experiences - if you asked users - aren't improving all that much.

Nowadays, when a provider adds an "experience" resulting only in no improvement, I feel actually quite happy. The general rule seems to be (not so slowly) migrating to activelly deteriorate functionality.

Past week my bank changed their UI to show a cute animation of a hand shaking some cash in a transaction confirmation screen. And, in the process, they've removed the button to immediatelly logout after the transfer is completed -- something I used to do frequently.

It's infuriating.

It's the only way promos can happen -- adding more gratuitous useless "features" to an already-steaming pile of crap.

I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync.” Even for B2B “back-of-office” software, the standards for software usability are really high, especially for new entrants.

Those kinda features are hard without a pretty complex frontend.

Not saying those things are always necessary, or that people don’t add bells and whistles where they aren’t wanted.

> I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync

I'm inclined to disagree.

One of the most successful web apps I know is a CGI (not FastCGI) app written in Pascal and containing some 30-yo code.

100% of users I met are happy but they don't even know why. "It's good", they say.

I believe their underlying reasons are:

- the app is extremely fast. Full screen reloads are not a matter anymore with broadband internet.

- client side code is light enough to run well in crappy, old windows-based PCs running internet explorer

- lots of reports and features. The vendor's team has time to develop them since they are not busy trying to centralize stuff, fighting w/ CSS properties and other stupidities.

This! I often build Django apps without any javascript and it's so light weight that the pages render instantly. If there is some interactivity needed then I toss in htmx where needed.

The problem is that most of these front end apps end up calling out to the server all the time. So you end up with essentially the same latency of SSR with the complexity of an application split across a HTTP boundary.

I do think there's a place for real time web UIs in business apps. I spent a chunk of my career replacing green screens with web UIs. Usually ended up slowing people down because they lost the ability to chain commands.

With green screens they'd know that the navigation to change and address was like 3, 2, down, down, enter. So they'd get there in a split second. With a web UI they'd have to wait for the screen to render in between each action. Ultimately it's much slower.

So much this.

You see it with the death of paged result views, and their replacement with "Yet Another Query Lang/Search Widget". Sometimes, to a User, that God's eye paginated view of a dataset is a lifesaver, because over time you start learning it's shape.

You learn datapoint X is on page 5, and as time goes on, you can further optimize, and you gain a visceral, kinesthetic sense for the dataset/program.

You have to use it though; and you have to document it. People aren't going to just magically intuit how your obtuse arse search widget works. They don't know your data model.

Even worse, they don't know your company calls something the industry now calls "Fred" "Bob", because "Bob" was the standard before "Fred", but you're a late adopter for reasons.

Or worse, that you labelled a field "Barney" in the UI, but in your search widget query, it has to be dealt with as BRNE. Or even worse: you enter "Fred=fredvalue AND Barney=BRNEvalue", yet you end up finding out someone had a fundamental misunderstanding down the line, and it turns out fredvalue is mapping to BRNE on the backend, and BRNEvalue is mapping to Fred.

These are all examples of actual bugs I've had to squash in the last 2 and a half years; and which only get worse and worse as time and system integrations move on, because they'll tend to echo out of your system under development into other auxilliary systems like your call center IVR or CRM, or customer service tool. Now you have three disparate systems to get fixes/work scheduled for, and which all need to be done in lockstep to roll out coherently across an org.

I've had to sit with Users, watching them, learning the desire paths, then sit down and have a long talk with a designer to explain the heuristics they weren't taking into account given the people who were actually using the thing.

Compared to snappy interfaces that your hands can master, and to be honest, it feels like a lot of web app is just regression, and an excuse to justify enploying someone to wholesale change the aesthetics of the interface no matter how much of a detriment that in the end becomes to the functionality of the tool.

Nah. They never say that. Ever. At best they say cut the crap and help me get done what *I* need to do.

The point is, tech for the sake of tech is the wrong target. And once you go down that road you're already lowing your odds of having satisfied users.

> Gimme a UI with rich interactions

You sure? Because all I hear on daily basis is "please don't make me learn new shit" and "get these annoying ads out of the way". Web is so "rich" these days that disabling Adblock should come with epilepsy warning.