Comment by blauditore

The average user, by Google's own studies, wants a faster experience.

By far.

Is there any evidence that web apps of today are faster in achieving what equivalent non appy web pages of the past managed? Despite the fact that those older "apps" were running on computers which were orders of magnitude slower than our cell phones today.

I've worked with 2 companies now where their users (and both these companies have users who pay 4 digit annual fees per user) have refused to migrate to the new Web 2.0 apps these companies have tried to foist on them.

The difference in these cases is that the users, by virtue of paying, actually have a say and so have required the companies to provide parity with the older and newer applications, and usage continues to not just be higher, but grow faster on the older versions (despite having a larger base).

Regular users have no such option. Google changes GMail, but its users still insist on using the older versions of the app, which is why they provide HTML mode, etc. However, it's users do not pay Google, and are forced to go with whatever Google wants to do, which is constantly hiding the older version and making it progressively worse to use.

It's not evident to me at all that regular users "want" to use these new web 2.0 apps, as much as they don't have a choice.

That's a cop-out. Being a developer and a long-time computer user biases me, but also gives me a more informed perspective on what's productive and ergonomic, and what's distracting and annoying. I can name the issues I see, instead of writing off the frustration as "this computer must have viruses" or "this is just how things have to be".

Bloat because of inefficient design isn't delivering any value to regular people that a developer is oblivious to. It's just bad engineering. Similarly for distractions, abandoning all UI features provided by default for the sake of making a control have rounded corners, setting the proficiency ceiling so low that no user can improve their skill in using a product over time, etc.

A faster horse.

People value privacy when made aware of the issue, but very few people are aware of how websites track (and manipulate) them.

I think there's a faulty premise in there somewhere. An architect or an engineer is not a candy salesman. A candy salesman really shouldn't have a say in what flavor, texture, sweetness, etc. is appropriate for any given client.

However, the way the poster you're replying to sees this issue is not as a candy salesman; but, as a public engineer. There's a problem, like "what should web be", "how should web work", which is akin to "how to build a railway over this valley", "how to minimally disturb the ecosystem", etc. That's not a realm of likes and dislikes, but of practicality.

One of the realities of today is that the average user is extremely distanced from the technicalities of Web, whether that's desirable or not. That puts a lot of burden on the informed and on the developers, which are often the same people. The few are obligated to make decisions for the many.

Do you deliver a box-shadow, but increase technical debt? Do you migrate to a more energy efficient platform, but alienate some users? Do you broaden the scope of your system, in turn increasing system complexity, or do you delegate to a dedicated third-party system, having the user possibly learn to use that third-party system?

It's a question of which compromise best serves the user. It shouldn't be a question of likes and dislikes. This is a complex situation rife with miscommunication, ignorance, conflict of interests, and inertia. Any simple solution, such as disregarding the opinions of developers, should be regarded with great suspicion.

Many "average" users don't know what they want, don't even realize the options that are available to choose from (i.e. the different ways an app can be built), and/or will accept whatever is offered.

Though it wasn't patently insulting, you have gone ad hominem - "to the man" - rather than the idea. Whether one is a developer or not, doesn't have any bearing on whether economy and efficiency are worthwhile values in a computer application. Although it so happens that developers tend to also be users. If they ARE users, then they represent users. Also in the sense of acting as an advocate of sorts for the user, developers represent users.

"Average" users having never been offered the thing being proposed here (faster and ad-free versions of the same apps, with the same network effects etc.), I don't see how you can state with any confidence that they wouldn't have chosen them, were they available.

It's ironic that Google got "lucky" because of its minimalistic approach back in the day. Now, it's just a huge mess.

The best practices that encourage you to minimize content and maximize whitespace on your screen. To change text for icons. To hijack the scrollbar. To replace perfectly good default controls with custom alternatives that look prettier, but lose most of the ergonomic features the default controls provided. To favor infinite scrolling. Etc.

Some "best practices" articles discourage all this, but in my experience, that's ignored. The trend is in ever decreasing density.

It all makes sense if you consider apps following the practices I mention as sales drivers and ad delivery vectors. Putting aside the ethical issues of building such things, my issue is that people take practices developed for marketing material, and reapply them to tools they build, without giving it any second thought.

Rounding rectangles is superfluous fluff, but it also is nice, and serves a purpose in the context of the whole design language they're using. I'm not against rounding rectangles and other such UI fluff in general. But I am against throwing away perfectly working controls, with all the ergonomy their offer, and replacing it with a half-broken, slower version of that control that only works if you use it in one particular way, but hey, it has rounded rectangles now.

Thank you for writing this. I had this feeling that the document model isn't that bad for software in the first place (a feeling that I noticed when I prototyped some of the stuff I was working on in Observable, and realized the prototype in an interactive notebook format fits the problem more than the SPA we were building). But I haven't considered the implications. You might be very right that the document model could support a lot more than we give it credit for, if we just stopped pushing the established "appliance" UI paradigm.

If you're talking about "forms" as the interface, then sure. I 100% agree. But the moment things get more interesting, you'll fail. Video editing for example. Lastly, I believe that if forms suffice, you don't need any of the recent CSS features. Simple forms without css should be fine. So no panels, modals, popups, nested navigation or single page apps.