The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me.

It is a business opportunity as well. I worked at a company that paid for an audit before LLMs. There is tremendous cost savings possible here.

I also wonder if WebMCP will be the ultimate final incarnation of this.

There is so much to learn in this space.

There are small things, like dropping a 'jump to main content anchor' before the navigation so you don't have to tab through the top navigation everytime.

But there are also certain pages en layouts which require a lot of thought on a good keyboard navigation flow. Combine that with the need for responsive layouts, our inexperience with accessibility tools, etc; and the required effort quickly adds up.

I was fired because I did too much once

Can you explain what you mean by this phrase?

No, not really. I know what you are trying to say, and I fully agree. We need to stop using "democracy" or "democratizing".

Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way. "Democratizing" means giving a mob control of the thing, it does not mean making it accessible to all at all.

It is an absolute train-wreck trying to get everything to work and for the overwhelming majority of products it isnt work the effort. It isnt like you put a wheelchair ramp up and are done. It is a constant battle with every change.

It is just another one of those things where the minuet minority suffers. Now if a company got some tax write off for it, that would change things.

This is even more visible when using Apple’s own apps on macOS. Choose any of them that have been ported from iOS without any attention to detail or any QA for accessibility, like Reminders or Settings or Notes or another app. The tab key will not take you where you might expect. There is no way to navigate only using common keyboard shortcuts. Nobody working on all these Apple apps have heard of tab order or keyboard based navigation.

Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.

Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years. And still, the software is obtuse point-and-click garbage. Meanwhile commercial software from 25 years ago could be navigated at light speed.

That's part of the reason Excel can't be dethroned. Excel is from the old age of software, and that means that users can input and navigate at light speed. All these fancy tools claim to dethrone Excel, but when you actually use them you realize it's a goo goo ga ga Fisher Price level UI. Extreme amounts of whitespace, buttons hidden behind submenus of submenus (which you have to navigate by eye, by the way!), features stripped, UI constantly shuffling around between updates.

Look, that works fine for a website on the open web where you assume your users have never touched a computer before. That does not work for commercial software.

My wife is a UX Design consultant and she had an engagement where a bunch of state government accountants were bemoaning how a redesigned procurement platform took away all their keyboard shortcuts.

Majority of computer professionals (programmers included) come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, in terminal, in PDFs, Word or LaTeX documents. Code by the way is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier. That's why using multiple cursors feature for the first time feels so amazing, even though the practical cases for it are not that common.

And when I say "text", I don't only describe the process of "grabbing some text" and "piping it" into another process, or manipulating it. It's not only about the input, the act of consuming text is equally, if not more important.

We argue that keyboard-driven UIs are more efficient for the input, but hundreds of memorized shortcuts can't really fix the fundamental problem.

Vendors are designed to own you and ownership can take different forms. Slack app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their stupid, quirky wysiwyg editor - owns you. Note-taking app that keeps the data on the cloud ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in, it is behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.

And when you get to that point, you'd feel helpless - all your knowledge and muscle memory can't help you there - not only the app is not favoring power-user experience, it's forcing everyone downgrade to the "average Joe" levels.

Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on our workflows.

Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.

Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like a boxer moving in a ring and casually throwing heavy punches. Long-time Vim and Emacs users "get it", even though they often don't follow through - some things just never become gratifying instincts. Sometimes, even the opposite forms - like redundant muscle memories. Some outright would reject using a new app because it messes with one shortcut they keep accidentally pressing. Sometimes, I wish there was an agreed standard for every UI - to have only the core, commonly used keys pre-set, while making everything else configurable.

Push a button, every icon is now labeled with a key, type that key, counts as a click, done.

I get that this does NOT solve for say, someone who's blind (i guess you could announce them, not sure), but it is easy enough I've found even lower tech people are fine with it.

As always, a lot of the trick is communicating the interface and using modern standards, not "Well it's ctrl + insert because that's what it is on linux"

God forbid I should ever be forced to use Blender or Inkscape with only buttons.

Most reasonable people want support for both keyboard and mouse-based navigation. For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use?

Same with some web forms where hitting enter in a text box does nothing. I expect it to submit a form, but very often, it does nothing.

There's nothing wrong with a keyboard driven UI having buttons as long as they advertise their key, though. That's one way discoverability is supposed to work. It means you can fall back to the mouse when it makes sense.

You mean because they're basically just in the way, right?

I know it's asking a bit much, but IMO advanced software ideally has

- buttons, pretty colors and icons where they make sense

- keyboard shortcuts for everything

- complete documentation that ships with it (sure "it's online anyway".. so find a way to automate putting what you have on the website into the release in a form that works offline)

- preferences to hide some or all buttons/toolbars, turn off the icons, and change some or all keyboard shortcuts. GUI is cool for that, text files are also cool. In other words, why not have everything? Maybe you could even compile a version that strips out all the stuff that can be turned off, or at least hardcodes some preferences, so the compiler can skip some things that are no longer called etc.

Not a must-have but nice-to-have: tooltips for all things and maybe advanced help, so you don't need the documentation as much, or not at all for simple use cases. But if the docs are complete, I think it's fine to keep the program and development process simpler by not duplicating that in tooltips. Don't go out of your way, unless you want to.

But as I said, that's for "advanced software", by which I mean software you spend a lot of time in. Browser, text editor, email client, file manager, graphics software, and so on. With simpler tools I'm usually just happy they exist.

I don't see why removing the buttons would be desirable. All that would do is to make the GUI unusable with the mouse and also make the discovery of the keyboard shortcuts much harder.

Screen readers allow users to use their keyboards and other assistive devices to navigate websites and apps by tabbing through elements with extra controls and shortcuts to skip to regions, interact with elements and such.

To that degree I agree that all GUIs should be keyboard accessible.

This is obviously not what the original author had in mind, if he had to tab through every item in a web app he would probably get frustrated rather quickly. What he is imagining is like TUIs where all the interactions are through keyboard shortcuts and macros. These are not popular with the majority of users of modern day software, especially if the software is something that is used infrequently. I think we take for granted how component we, people who create software, are.

What has become more popular are interfaces that expose extra controls with a single key press, where the user can type to get the result they want. So instead of memorizing the keyboard shortcuts to dozens of actions, you can press something like Crl+K or / to summon a palette where you can search for the action.

Edit with Copilot[1]

Press the Copilot key on your keyboard[2] and type the thing you want to happen on your keyboard in English without leaving the home row. Forget the keyboard shortcuts, the path through the menus, the button location in the toolbar, the command name in the omnibar, the marketing name of the feature. Forget queueing up keyboard keys in an input buffer based on memorising which dialog will popup next, or the tab ordering on this or that screen. DWIM is back, and this time it still isn't determinstic, but it's the way we are going to manage ever-growing software features and task complexity and finally turn computing declarative instead of imperative.

"Move rows with dates from 2020 to the bottom of the table"

"Change the date format in the table from mm/dd/yyyy to yyyy-MM like 2026-Aug"

"Style the table with alternating dark/pale contrasting colour backgrounds and a different header row colour"

[1] https://support.microsoft.com/en-us/word/edit-with-copilot-i...

[2] https://blogs.windows.com/windowsexperience/2024/01/04/intro...

No clutter, but hints come as you stutter on what to press next

Some examples of what you are asking for can be found in videogames due to controllers

For literally decades after they were state of the art, people who used old-school mainframe TUIs would still swear by them.

I think the key difference is that they would buffer inputs. You could be on the "Receipt" screen, and know that if you needed to enter the code for some rebate receipt or something, you could hit F6 - F2 - down - down - down - {start typing code}, and even if the UI took multiple seconds to actually get to the point that the code was being entered, the input would be kept.

Normal GUIs have discarded this for fairly good reasons. Especially when it comes to queuing mouse clicks. If you get down to the nitty-gritty of what it means to queue a "mouse click" it get very conceptually complicated. But you could create a GUI toolkit that still had the same idea integrated into it for a keyboard interface, if you have well-defined points where you are and are not accepting keyboard input.

I would submit that "keyboard-driven UI that is as intuitive as clicking with a mouse" is actually the wrong direction to cut on. You need to beat the conventional mouse GUI completely in some other dimension, one where it can't even compete. This is the only one I know of that has historical precedent.

The downside is that on a desktop I'm pretty sure you're looking at a completely new widget toolkit. Trying to force this on the current ones is going to be hard and could even be impossible.

If I were going to create a new web frontend framework, this is what I'd focus on to have an actual new feature that isn't just a respelling of the current set of features. And I can't guarantee that it won't also be missing something crucial, though, I think everything you need is actually there. You could even have modern nicities like, store the entire GUI field state transition diagram statically at the beginning and as the user types ahead of the GUI's current state, show them a rendered view of where they are going, e.g., the key sequence I showed above could be "[Rebates] -> [Rebate Receipt] -> [Name Field] -> [Address 1 Field] -> [Address 2 Field] -> [Rebate Code Field] -> [Entering {'A8F2-132A-9283'}]", live updating as it goes so if the user can just bang that out even while the first screen hasn't loaded they can even be sensibly editing the text input they're going to put in.

Combined with something as simple as making sure everything always has a keyboard shortcut in a defined format, which is conspicuously displayed every time you change something, e.g., every time the user clicks the Rebate Code Field you can also display something like "Ctrl-F R" or something so they also learn how to drive the screen with a keyboard and you would, if nothing else, have something different than what's out there today.

Anyone who wants to, steal this idea. I'm not going to do anything with it. I don't see this as something you want in every app necessarily, but people who spend hours a day in the same app for whatever reason would be confused for a week, then I bet you couldn't pry it from them with a crowbar.

> But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users.

It's not a trend, it's a fallout of Electron being the default choice. Devs that use non-web UI frameworks are aware of keyboard navigation, or at least don't disrupt the builtin thing. And of course what devs that don't target power users tend to do is irrelevant to GUI vs TUI debate in the context of power users.

For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.

In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.

In that case, it is up to the developer as well to read and try to follow the published guidelines.

Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? It breaks. Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TUI is just a poor choice here, it doesn't play well with formatted text like markdown, UI controls, long text, and so on. Terminals are good for CLI where the text is presented as lines, not TUI with spaced layout.

>Any terminal can implement this kind of arbitrary-text keyboard navigation on its own and have it work for all TUIs. Were e.g. GTK to implement something like this, it would only work for GTK apps, not for all GUI apps. This is exclusive of TUIs because TUIs are text-driven while GUIs are pixel-driven.

Terminal navigation has nothing to do with TUI navigation. Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time. Of course absolutely nothing prevents you from writing a TUI framework with a common schema, at which point you will be at the mercy of the dev using this or that framework and schema, same as with GTK and Qt. None of this is unique to TUIs or GUIs.

Also extra effort to use it. This is why we have the “how do I exit vim?” meme.

A good user interface needs escape hatches so users can keep their head above water while they learn to swim.

Most of what people want when they say keyboard-driven is closer to a cockpit (requires expert knowledge) than a general purpose UI.

- Tab to move across fields.

- Left-to-right, top-to-bottom focus.

- Space to toggle togglable stuff.

- Alt-Down Arrow to deploy drop-down stuff.

- Arrows to move around.

- Enter/Esc to accept/discard a modal.

Or maybe I misunderstand the things you call "mouse things".

https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...

I don't know about 'first' because I don't see a reason to privilege keyboard workflows over mouse workflows given how ubiquitous the latter is but Windows has had, for literally decades a 35 page Keyboard UI spec. They've put a fair amount of effort in applications being navigable in a consistent way.

https://learn.microsoft.com/en-us/previous-versions/windows/...

I’ve made a web application at work able to be keyboard driven one time and exactly 0 users out of thousands made use of it. People just don’t want to pay the upfront cost. In the old TUI days it was the only way to use something so you had no choice.

To be completely keyboard inaccessible I’d argue that you almost have to try and achieve it.

Going back and forth between the keyboard and the mouse is what's awful about bad interfaces in my opinion, not the mouse as a pointing device.

Sounds like a window manager problem

https://www.homerow.app/

[1]: https://github.com/philc/vimium/

You could compromise on not-shipping-before-it's-ready.

while being better at QAing i finally get the time to work on the things that got me into programming in the first place, which in the point where human interact with the machine.

Keyboard interfaces can be, but not necessarily, quite opaque. There's a reason in the old days companies shipped keyboard overlays and function key templates to help users (or went all in with custom keyboards built for the application).

In contrast consider something like Wordstar where you pretty much just needed to memorize the three prefix keys, and if you pressed one and waiting, you'd get a menu describing all of the options.

Obviously, things like early Smalltalk and, probably, Xerox (having never used any of the early Xerox systems), relied heavily on the mouse, but even it had command accelerators.

The CUA standard was that crossover that Windows, and MOTIF, adopted. Much of that work is still with us today, and it worked well both on GUIs and TUIs (witness the old Turbo Pascal/C++ IDEs, and other applications). Those character based applications had to assume there was no mouse, but offer the flexibility of being good citizens should a mouse be present.

At least, this is the way it's always been on OS X and later. I'm not sure about classic Mac OS.

The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.

The intuitive part of my argument also falls under this. By following known conventions as close as possible, we can eliminate the need to remember the most common actions.

Additionally, it is important to present your shortcuts in a shortcut window/dialog in a logical way for when the user needs to remember something.

In any case, an excesive number of keyboard shortcuts can have a negative effect on usability, so this is also important to keep in mind.

Objective would be making the statement that not all GUIs need to be keyboard-driven manged or have accessibility built-in.

Example, GUIs in automation are primary touchscreen driven and have user requirements base on the environment they are in.

GUI standards are objective to who the users actually are or will be.

This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.

I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps

I clicked. Never trust a gui library without screenshots.

I'll never quit building TUIs, though. I'm building more TUIs now than ever, with AI assistance making it easy.

Well, yeah, it just that those GUIs failed to appear for at least 30 years.

> It is time to move on from using this arcane technology from the 60s-70s.

You mean the GUIs? They were being in development since the early 70s, you know, but they really have flourished in the 80s. So, it's already a 40-years-old paradigm that still haven't managed to displace another contemporary paradigm of TUIs. Well, who knows, maybe in 40 more years it'll make it.

Yikes, no! One of the reasons old timers like me say that using a computer has sucked a lot in the last ~20 years is the use of a browser as an interface to everything.

If you want to make an app that needs a browser to use, then please drastically improve the browser's interface. I mean, this is a no brainer. TUIs are way more superior to doing things via Safari/Firefox/Chrome.

Hard disagree. Most web interfaces are worse than most native UIs. Inconsistent rendering, keyboard shortcuts and navigation between apps, slow response times, and more.

There's a reason everyone who knows what Electron is bashes every "native" app built with Electron.