Yes, at least in some respects, HTML forms could have been that way, but in practice, they are not:

For one thing, and this is important, with every browser I tried, I get periodically interrupted by messages that the browser displays and that are not part of the form. Just recently, I was again asked for security updates by the browser. Sometimes when opening a form it gets prefilled by the browser, sometimes not, and sometimes only some of the fields. Some other times I get asked whether the browser should translate the form. Sometimes it asks me whether some fields should be prefilled. Sometimes when submitting a form the browser asks me whether I would like to store the form contents for later use. Sometimes the browser asks me at unpredictable times whether I would now like to restart it.

An important prerequisite for getting a lot of work done is for the system to behave completely consistently and predictably, and not to interfere with unrelated messages, questions, alarms etc. This is also very important for training new users, writing teaching material etc.

Another important point, and that is very critical as well, is latency: Just recently, I typed text into my browser, and it stalled. Only after a few moments, the text I entered appeared.

I never had such issues with COBOL applications. Today, we can barely even imagine applications that are usable in this sense, because we have gradually accepted deterioration in user interfaces that would have been completely unacceptable, even unthinkable, just a few decades ago.

Of all the woes of modern UI, latency on text input is what I find most irritating. It's physical, visceral, mental, I don't know; when you've been raised by incredibly snappy video games (1980-1990s, 2D glory), it's asinine to suffer input lag in 2020 of some x86 platform. It's just alien an experience, like time suddenly reversed for userland or something.

In the browser, given the steaming pile of code that some pages have become, I may understand some lag, quirks. They broke the web and Chrome is helping so... Yeah. But in a text editor of all applications? No. I mean, just... no. (Looking at you, atom, vscode... WHY?)

Whatever the hell you're trying to search / display / message (I assume, trying to help me...): please begin by not interrupt my input feedback? That should be, I don't know, the only sane priority for UX, to actually respond to the user? Otherwise the computer feels... broken, subpar, unfit for the task? Am I alone in having these feelings when using devices?..

/rant over. I'm not that old for god's sake, 37 and they've got me jaded by UX quality already. All it took was two short decades to flush down the drain the precious good that didn't need fixing.

Ah. I'm sure we'll get back there. Eventually. Even if I have to write it myself (surely, we'll be legions). Someday I wonder what we're waiting for. And then I remember that this is the year of the Linux desktop... It's not that easy, is it?

I gotta agree here. UX seemed so simple just ten- twenty years ago... and still I wonder how the hell people programmed 16 bit video games in a tiny system.

And everything on the web front is so bloated. Yes, I can make a pretty UX with that, but at what cost? I think that the faster and cheaper computers that we have today have made it easier to overlook how bloated everything has become.

Upside is, it does make a lot of things easier. Downside is, everything is slower and fatter. Mostly because of new frameworks, languages, etc that all aim to accomplish something, just easier.

And I get it. I understand why we want to make it easier. But again, what are the costs?

> And everything on the web front is so bloated.

Um, you're posting this on a site that's basically the polar opposite to "bloat" on the web. Badly-engineered systems have always existed somewhere; even the COBOL-based proprietary solutions referenced in the OP are a fairly obvious example of that.

Ok, then the _majority_ seems to be bloated. And I feel like this is the new normal.

HN, in my opinion, is an island of simplicity in a sea of complexity.

This is pure speculation on my part but I like to think that there's literally billions to save. It's about the order of magnitude: even 1 minute per year per person amounts to something like 15,000 man-days (>100 million man hours!).

1 minute per year!

I have a feeling that many programmers and engineers are blind to latency. Not in a sense that they are bad programmers/engineers, but in a sense that they simply cannot feel the difference, so they make stuff that introduce latency they themselves cannot perceive.

So you get stuff like Wayland that introduces latency issues and when you try to explain the issue you feel like trying to describe the difference between magenta and fuchsia to a blind person.

Oh my, I've never thought of it this way. I really get what you mean.

Can't agree more. That might very well be it.

Could it be trained, through exposure, e.g. with video games as I implied?

Or is it maybe related to "snapiness" of the brain?— I think it's been shown that we clearly have difference response times, some people being several times faster/slower than others (with no explicit correlation to a "level" of intelligence", more like the characteristics of different engines in terms of latency / acceleration / max speed / torque / etc).

TBH i don't know. I was playing video and computer games since a very young age, so it might have to do with this but at the same time i know i wasn't paying much attention to latency until my late 20s. Even at 25 i'd be running Beryl (one of the first compositors) with its massive latency and i'd be writing games with software rendered mouse cursors, both being incredibly poor in terms of latency and i'd just not notice it.

So perhaps it can be learned?

The other thing about too many modern user interfaces is that they often get subjected to whatever fad is in vogue this week. Eye candy takes precedence over consistent user interfaces, and gratuitous changes are routine because a new fad has become the Next Big Thing.

The trade-off, of course, is access. Now, computers are cheap and available everywhere. In the COBOL era, what percentage of a family's income would it take to purchase such a machine? How wide-spread were these machines in non-English speaking areas? How easily could a program from one of the machines be used on a machine built by a different vendor? Were said programs resilient to malicious actors?

As always, there are sacrifices, but in general I think we have made rational trade-offs in this realm.

Not to mention executing the program across different kinds of wired and wireless networks, and handling a huge variety of client OS, user agent, and input modalities.

You seem to be complaining more about the browser than HTML per se. Why not use another browser ? or even a lynx like browser then ?

I think despite all of these most of us stick with modern browsers because the tradeoffs are worth it. Removing complexity and unpredictability at all costs has usually worse impacts than being annoyed and surprised. Except if your software drives a cockpit or a nuclear plant.

> For one thing, and this is important, with every browser I tried, I get periodically interrupted by messages that the browser displays and that are not part of the form. ...

Pressing the ESC key should dismiss these messages. It's an annoyance to be sure, but not a deal breaker. Similar for pre-filled content, you can just select and erase it.

Sadly, <ESC>it doesn'<ESC>t really solve t<ESC>he problem of interrupting one's fl<ESC>ow...

At least, such behavior should be user preference— “get out of my way” is like #1 on most users list for a useful toggle.

As for notifications specifically, it's not like we haven't developed 101 notification centers to postpone user response.

The problem, imho, with qualifying this as universally "not a deal breaker" is that it's a slippery slope, all too subjective to boot with— e.g. is Windows auto-rebooting not a deal breaker either? I'm sure to some people, not really...

A showstopper has very different thresholds depending on what you do. Live tasks notably (recording, streaming, etc) should be sanctuarized (down to a "real-time" setting at the thread level, when it's not actually unstable for some ungodly reason). Chrome is just another OS nowadays, videoconference being a prime example of app. I wouldn't like Chrome to nag me during an interview for instance.

If I even have to make just 1 extra move, gesture, click, whatever even a look away from my work, because the machine demands that I do (screen or app locked 'behind' otherwise), in effect creating unsollicited gates between me and my workflow... yeah, there's a big problem. 5 minutes saved a day per user for a big corp is millions saved before a month has passed.

Now think that we're collectively, computer users, like one big human corporation. Think of the time we're losing due to bad design. Let that sink in for a minute... It's a huge and stupid cost we impose on ourselves. Must be funny to some, idk...

There is a way to a better UX. We shouldn't need ESC to get there. ;-)

Indeed, and in fact there are systems that adapt between the two paradigms. For example, taking a system based on IBM 3270 screens and turning it into a series of web pages to enable a web portal for an existing mainframe system.

I worked for a company that had one of these ancient (probably mainframe) systems for inventory, business analytics etc. Users at the factory would access it via 3270 terminal emulators. It was clunky but usable.

Until they wanted to stop paying for terminal emulator licenses and replaced it with a web gateway that translated the 3270 pages into HTML forms. That was pretty horrible to use and of course people began “forgetting” to record inventory moves and process steps. This was for six figure aerospace components so at the end of the day someone knew where they all were and what had been done, it just made it a lot harder to bill for milestones and wasted tons of time. Of course the software was like $15 a seat.

Plain HTML5 forms: they had complex field structures and validation which required JavaScript until we got things like the extra input types and regex patterns.