I second the TUI argument here.

Back in ... maybe 2005 or what, in our ~60 people family business, I had the pleasure to watch an accountant use our bespoke payroll system. That was a DOS-based app, running on an old Pentium 1 system.

She was absolutely flying through the TUI. F2, type some numbers, Enter, F5 and so on and so on, at an absolutely blistering speed. Data entry took single-digit seconds.

When that was changed to a web app a few years later, the same action took 30 seconds, maybe a minute.

Bonus: a few years later, after we had to close shop and I moved on, I was onboarding a new web dev. When I told him about some development-related scripts in our codebase, he refused to touch the CLI. Said that CLIs are way too complicated and obsolete, and expecting people to learn that is out of touch. And he mostly got away with that, and I had to work around it.

I keep thinking about that. A mere 10 years before, it was within the accepted norm for an accountant to drive a TUI. Inevitable, even. And now, I couldn't even get a "programmer" to execute some scripts. Unbelievable.

We had a tower of bable collapse, when we switched to web UI. We gained a million things and lost a million things. There was an era from around 1985 to early 2000s, where a large majority of applications had a (somewhat) consistent UI, based partially around MS-Windows, partially around some IBM 'common ui' design guide principles. The hall-marks of it was - keyboard navigation was possible - mostly consistent keyboard nav - common limited set of UI controls with consistent behaviour - for serious applications, there was some actual thought related to how the user was supposed to navigate through the system during operation (efficiency)

Post-web and post 9/11, where web browser UI has infested everything, we are now in a cambryan explosion of crayon-eating UI design.

It seems our priorities have been confused by important things like 'Hi George. I just noticed, that for the admin panels in our app, the background colours of various controls get the wrong shade of '#DEADBF' when loading on the newest version of Safari, can you figure out why that happens?'. 'Oh, and the new framework for making smushed shadows on drop-downs seems to have increased our app's startup time on page transitions from 3.7 seconds to 9.2 seconds, is there any way we can alleviate that, maybe by installing some more middleware and a new js framework npm module? I heard vite should be really good, if you can get rid of those parts where we rely on webpack?'

These days most web apps aren’t written to take advantage of the browser’s built-in tab navigation, and unless the dev is a keyboard user, they don’t even think to add it. This is largely the fault of React reinventing everything browsers already have built in, and treating accessibility as an afterthought. Bare metal web apps written in straight-up HTML do have decent tab navigation. They’re still not as snappy as a green terminal app, though. My first summer temp jobs during college were data entry, in the era when you might get a terminal app or a web app, and the old apps invariably had better UX.

>The green screens tend to be much quicker and more responsive than the web frontends that are developed to replace them.

Agree! Back in 2005, I was involved in a project to build a web front end as a replacement for the 'green screen' IBM terminal UI connecting to AS400 (IIRC). All users hated the web frontend with passion, and to this day, I do not see web tech that could compete in terms of data entry speed, responsiveness, and productivity. I still think about this a lot when building stuff these days. I'm hoping one day I'll find an excuse to try textualize.io or something like this for the next project :)

This only matters if "quick and more responsive" is the only thing that matters. Yes of course you can enter payroll timesheets on a TUI if you spend days/weeks/months gaining that muscle memory. The same way you can edit in vim much faster than vscode or Eclipse if you spend weeks/months/years gaining that muscle memory.

The fact that someone who has been doing it for years can do it faster is obvious, and pretty irrelevant.

Take someone who has never used either, and they'll enter data on the web app much faster.

You don't see keyboard nav in most web apps for similar reasons. First-time users won't know about it, there's no standard beyond what's built-in the browser (tab to next input, that kind of thing), and 90% of your users will never sit through a tutorial or onboarding flow, or read the documentation.

Is there a good tuinfor web?

There are people even today who want Lotus Notes back, still mourn its loss.

huh isn't it funny when you dogfood but instead of food it's... nvm

But yeah some elements of that list have convinced me to steer very clear from any products from that company

DOORS is/was a requirement management tool and frankly speaking was crap but I have never seen another software as good and comprehensive in requirement management.

I expect it to be still used in aviation or army related domain, maybe pharma.

Yeah I was just about to say this -- I used Sametime via Pidgin (I think it may still have been called Gaim back then) on my work Linux machine and it was actually quite nice.

My favourite Sametime feature within Pidgin was, well, tabs (I can't remember if the Windows client had tabs as well..?), which was revolutionary for an IM client in 2005.

But my secret actual favourite feature was the setting which automatically opened an IM window /tab when the other person merely clicked on your name on their side (because the Sametime protocol immediately establishes a socket connection), so you could freak them out by saying hello even before they'd sent their initial message.

You mean Lotus Notes?