GUIs should be fully keyboard-driven | Hacker News Reader

GUIs should be fully keyboard-driven

ckardaris.com

1,055 pointsckardaris528 comments

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard.

1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a disability flies into a wall.

That's a good point. Accessibility is the next step that should also not be ignored. Navigating to the elements is one thing, but for the voice assistant to work properly it can be a little trickier.

Yeah unfortunately this seems to be something very few outside of bug tech dedicate resources to. Even for them it seems to be an afterthought, at least in my professional experience. It winds up another compliance checkbox just like security.

What do you mean by "a tab is off?"

Normally you press tab to move between widgets. I guess he means if the tab order hasn't been set up properly.

It's been a while since I've done actual development, but determining tabindex ordering was a very big deal in the early 2000s when clerks/admins were moving from legacy systems to the web. They did most of their jobs with a keyboard, and if you set up tabindexing so that they can use a keyboard for 90% of their job then they would fly through tasks. If you didn't then you'd have some very angry clients at the end of the project ;)

So just echoing that this is not just an accessibility thing, but just a good user interface design thing. If your UX designer isn't taking keyboards into account (jettison mobile first development into the sun please) then they have no business building business applications.

I worked on an accounting application once. We had the proper tab order written down on paper docs and checked/updated it regularly.

We would have been murdered by at least the point of sale people otherwise :)

I worked in hotel industry, same deal.

Power users would complain within hours

Using tab to cycle between interactive elements in a window or page. As soon as you tab and it goes somewhere unexpected, you're cooked.

I had to keep accessibility in mind a lot in my previous job (web development for a university). The thing that I consistently found was that, the more accessible a website was, the better the experience for everyone, not just people with disabilities.

I 100% agree. I've been working on a component library rebuild at work and accessibility is a key focus, granted I don't think that would be the case if some of our contracts didn't mandate it but it's fiiiiiine

I'm someone who enjoys this kind of work, especially when the target is a stylized drop down - I got to spend a week with the MDN page for the ARIA combobox open, trudging through all of the ins and outs of keyboard accessibility and I know I'm still missing a couple things (typing when the control is focused but not open, for example), and having clearly defined specs is something we don't seem to get a lot in webdev

My go to when implementing custom controls that can't be achieved in native HTML is the ARIA Patterns (https://www.w3.org/WAI/ARIA/apg/patterns/) site. That has clear documentation on the roles, states, and keyboard interactions for common UI controls. I've used it for things like a search bar with an autocomplete dropdown to get the keyboard interaction right.

that's generally the case with many accessibility features, not just for websites

yep, the curb cut effect is a well-researched and documented phenomenon [0] across ADA development in all aspects of the world.

accessibility work isn't just about making things possible for folks with disabilities, it's about making things better for everyone.

[0] https://en.wikipedia.org/wiki/Curb_cut_effect

Another way to think of this is that everybody occasionally needs to do something unusual. But some people, due to their life circumstances, always need to do something unusual. And making things better for the always-odd folk is also a positive to the occasionally-odd folk.

Which like, we're all eventually gonna be odd folk! That's what age does to us. But we should understand these accommodations as being a net positive, not a cost, to society.

Yep. In accessibility research, they call these "situational disabilities". When you need to open a door with your arms full of groceries, you aren't so different from someone who is never able to open a door. Accommodations that help people with permanent disabilities also help other people in the right situations, too.

My touchpad broke and I couldnt download the touchpad driver to fix it on the spot because there was no way to get to the download button with tab and enter, you had to click it.

That's a funny example, reminds me of how often fresh Windows 7 or older installs were missing the ethernet driver so you had to move stuff over on a flash drive to get started really setting stuff up.

In your situation, a couple possible solutions come to mind. 1) turn on "mouse keys" which lets you use the numpad to move the mouse and click, 2) a vim addon for the browser (e.g. vimperator or tridactyl) likely could've clicked the button via the hints mode. It's in the past now so maybe these wouldn't have worked or you didn't know, of course, just fun to think of what I would've done.

Yup. Or people with temporary disabilities — who have simply broken limb or had a surgery. Most places are hellish to navigate on crutches. Heavy doors alone make so many places nearly inaccessible, and that’s before you even get to stairs.

Some of the things we take for granted in UI/UX originated that way, like automatic hamburger menu hide/show (for very large zoom) and "scroll to content/top" buttons for screenreaders, which, if you've ever tried to read a recipe online are pretty critical. Captions on videos are also like that, although there you might share blame to them for enabling the poor sound mastering on things like, legendarily, Tenet, perhaps.

What are the advantage of “scroll to content/top” buttons over <main> for screen readers? I think that the use of those buttons is for when the CSS fails to load.

It's essentially the same thing, but a lot of the time people will add a sr-only button at the very top that just goes straight there, and one at the bottom if the screen reader gets stuck in the footer nav, as well. Depending on which screenreader people use they sometimes only work on the actual hydrated markup, so <main> isn't always visible the way you'd expect. It's been a while since I did a11y tho so I'm probably hopelessly out of date.

Such buttons are more visible to (screen reader) users who navigate the web exclusively with arrow keys.

Landmarks are important, but to navigate by landmark, you need to be experienced enough to know the right quicknav keys. Some beginner users might not be.

"Scroll to content" doesn't mean what you think it means.

It doesn't scroll to the "useful" part of an article. It doesn't skip past the introduction / filler / two pages of "this is how my grandma used to make it." The only thing it does is getting you past the top navbar and such, and moving focus straight to the beginning of the article.

That's because at the end of the day:

- accessibility is just usability. all it is is making sure your product is as usable by as many people as possible.

- it's a myth that "people with disabilities" are some other that excludes you, and 'accessibility' or assistive technologies only benefits other people. Everyone is only temporarily 'abled'. You need to use prescription glasses to comfortable read a computer screen? You're a parent trying to watch some TV while getting your child to sleep? All benefit from assistive technologies.

> accessibility is just usability. all it is is making sure your product is as usable by as many people as possible.

Not always. There are things that increase usability for fully abled people but decrease it for disabled people. Color-coding is a common one. Another is using smaller font size to make more info visible at once, or advanced touch gestures that can be accidentally triggered by shaky hands.

Then there are accessibility features that actively harm fully abled users, like sticky keys or screen readers that automatically follow focused UI elements.

Colors should be an OS feature. On iOS and macOS you can remap colors globally and it works in all native apps. There are presets fire the common cases: red/green issues, color blindness etc and you can make your own. This has its limitations though eg if you are not able to distinguish at least 5 or so colors… any colors.

That's why you don't just use colour for identification. E.g. include a warning icon next to a button/element in addition to using a warning colour.

Nor just shape, so a warning icon + text message.

and, as is being increasingly forgotten, SOUND QUES. Seriously, I get they can be annoying but they make navigating and interacting with things so much easier if you can't see them. Sure, TTS exists but is far more inefficient and objectively less helpful in these kinds of circumstances

Another great example of increasing accessibility while reducing usability.

*cues

should be, but then you will upset all the marketing folks and their brandings.

But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc.

A good common framework helps here. Then, it's up to each user to set their settings properly.

Riddle me this - why would you want to disable something that increases usability of an application? (Yes, this is a loaded question - I never said these features are bad, just that usability and accessibility are sometimes at odds with each other.)

Sometimes users may prefer to reduce the degree of accessibility of an application in favor of aesthetics.

I have my opinion on aesthetics of additional ways of repeating information already available by color coding. But to each their own.

Other than that, is enabling/disabling any of the aforementioned features ever a question of aesthetics?

For example, opting to not enable high-contrast mode is a question of aesthetics. Arguably reading text would become easier for the user, but they prefer to sacrifice a little of the readability in favor of looks.

In fact, for some people high contrast is headache-inducing.

I’ve installed a utility on my laptop that supports “sub-zero” display dimming for nighttime use because monitors are now over-optimized for max brightness, with min brightness being retina-searing for eyes adjusted to a dim room.

I am a little confused about your response. Do you disagree with me that accessibility features often reduce usability, or do you agree with me and just feel like nitpicking? I'm all for nitpicking, but I'd rather keep it separate from the real debate.

> Riddle me this - why would you want to disable something that increases usability of an application?

Why don't you run your apps/OS with every usability feature enabled? Share your reasons.

I think you are mistaken which side I am on in the "accessibility is just usability" debate. For the record, I am on the side that says not at all.

Nope! But that you can't answer my question says all I need to know about the type of person you are.

unsure this is quite the same thing, but I often swap my phone to gray scale to reduce brightness overall (and 'reduce whitepoint' sometimes) because at night colors are too stimulating.

There are very few accessibility features that increase usability across the board for everyone.

If they did, they'd just be called "features".

Disabling high-contrast display makes the colors more aesthetically pleasing.

Disabling large-print text allows you to view more text on the screen at one time.

My point exactly. Accessibility isn't "just usability" and the great-great-grandparent was wrong to say that.

Color coding doesn't decrease usability for disabled people (and I say that as a screen reader user). You just need to ensure that color is not the only way the relevant information is conveyed.

Certain types of colorblindness combined with certain colors makes text much harder to read than black-on-white. If you limit yourself to just universally readable colors, you're heavily limiting the number of different categories you can highlight. There's also the matter of screen real estate - duplicating info isn't helpful for people who can deal with colors just fine. I'm not saying it's a srong thing to do, just pointing out accessibility and usability are different things.

Couldn't you distinguish things by their grayscale value? Then you change the hue on top of that for people who can see color.

May not always be enough contrast to pass WCAG requirements, for example.

> Another is using smaller font size to make more info visible at once

This doesn't sound very usable to me.

Everybody has some minimum text size they're comfortable with. If you make the text bigger than that, they're forced to scroll unnecessarily, which is less usable. But the size differs from person to person, so it should be configurable. You get this automatically with web browsers and most GUI frameworks if you don't go out of your way to break it (just stick with the default font).

You might be the kind of person who does benefit from accessibility features such as larger font size. On the other hand, I'm not; I can read 10pt font on 100 DPI display just fine, without glasses. I'd rather have an extra column in table view visible without scrolling than larger letters, but for you the tradeoff might be different. That's why it's accessibility and not usability. Usability would be if the bigger font didn't push anything off screen, then of course it's better to make it bigger.

Yes and unfortunately font size is usually one of those things where everyone is subjected to the "improvement". Accessibility guidelines should not be specifying minimum font sizes but rather require websites to respect the browser settings.

Additionally, I found, that simply sticking to web standards, instead of reimplementing everything in JavaScript, goes a long way towards accessibility.

Funny how that works. It's almost as if the web was designed to be a tool for semi-interactive documents instead JVM-esque WODE environment

Exactly; consider that only a percentage of users will actually be sitting at a desktop system using your application. Most people will visit your website on a mobile device, and a percentage of that will be in weird lighting conditions trying to operate the thing with just one hand. As just an example, and that's the people considered abled - anything that isn't the hip startup of the week aimed at 15-25 year olds will need to consider e.g. eyesight issues on top of everything else.

Anyway, it's not even an option anymore, under the European Accessibility Act, government and (since last year) public services (websites, apps, appliances, etc) all need to be accessible; for websites this means implementing WCAG 2.something to level AA, which includes things like minimum contrast requirements, captioned videos, and increasing font size without losing information.

And it's often considered an afterthought because by and large, designers and developers are relatively young, 20-40 some year olds working on Macbooks with 4K displays. Some may be wearing glasses but broadly speaking that's the extent of their disabilities.

This is true in other fields too. Wheel-chair ramps are used by people with baby strollers. Subtitles work for deaf people, those who can't understand the spoken language, or simple folks in situations where someone is sleeping next to them. Pretty much every accessibility-oriented feature ends up helping out people beyond the original audience.

Baby strollers are not accounted for enough !

One might wonder (wrongly) why everyone should care about the special and expensive needs of a few (or old) people when designing public spaces.

But a majority will actually need to use these spaces with a baby stroller. Not a few. Baby strollers are a driving power of our society! Enable them!

And to keep the loop going, stroller-accessible spaces are also walker-accessible spaces and cart-accessible spaces. Worked at a computer store in the early 00s. Our rented retail space had a wheelchair ramp and there were a few elderly regulars who would show up with a desktop PC in the basket of their rolling walkers for repairs. More than once they thanked us for having the ramp because the computer itself was way too heavy for them to carry from the parking lot.

Not to mention luggage. I find it hard to believe that it’s a coincidence that rolling luggage became common shortly after curb cuts and wheelchair ramps did.

Really? Both strollers and wheels on luggage are pretty nice to have even if you have to somehow negotiate curbs. So, I think it is a coincidence.

And yet strollers predate rolling luggage by over a century. (Even 2.5 centuries depending on which sources you trust.)

The rolling luggage is primarily useful in the vicinity of airports. Inside airports there were no curbs. And I don't think people are going on long journeys through downtown areas with their luggage. I think you have a better argument asserting that rolling bags were facilitated by cheap polyurethane skate wheels.

There were fewer ramps and more stairs in airports and their parking garages prior to the 90s, due to the ACA.

And people drag luggage around on city streets all the time. Many tourist destinations are pedestrian cities even outside their most central downtown areas. And luggage also needs to be dragged around hotels — and in suburban areas their absurdly large parking lots.

The skate wheels are a plausible argument, though.

Those are even worse because the tiny wheels do not take well to cobblestone or gravel surfaces that strollers handle just fine.

In fact, in a way, basically everyone will use a baby stroller at some point in their life (at least as a passenger).

I personally never noticed this before becoming a parent, but there's a lot of spaces that are "almost" stroller friendly, but for some reason there is a small obstacle that would not be expensive to remove (if accounted for during planning). For example, a few steps that could easily be a ramp, blocks of flats with a lift that is accessible after ascending a few steps, even high shop entrances.

For me it's not a problem, because I can easily carry stroller with a baby inside up, but for most mothers I know this is usually a huge or unsurmountable obstacle.

I saw a good mental model for this a while ago. Unfortunately I have no idea where.

Three kinds of disability:

1. Permanent (eg, blind)

2. Temporary (eg, pregnant/new parent, recoverable injury)

3. Contextual (eg, holding something with one hand, loud environment)

When people think about accessibility, they often think about 1. But the long-tails for 2 and 3 are huge, and ultimately affect everyone at some point.

In traffic planning everyone who is not a healthy, athletic, young man without baggage is considered disabled.

While this is often true, sometimes accessibility features can be distracting to those who don't need them so should be implemented in a way that they are optional. For example, closed captions intended those who can't hear at all contain much more than spoken lines and are not appropriate for learning the (spoken) language and even less so when watching something in your native language with a good audio environment. Which is why subtitles are not on by default and you have different tracks for closed captions and regular subtitles.

My father is blind, the only tech he knows how to use is a smart tv, when i build him custom apps the first thing i do is turn off talkback when the app opens, so i can control what tts says. The regular talkback is so so annoying and repetitive

The issue with accessibility is bots from scrapefly or browserbase will abuse website to death. There is reason why we can't have good things due to abuser like scrapefly, browser base, anchor browser etc... I had to turn off all the accessible selector and randomized html soup to make their life harder.

The solution is redirecting to an actual API or MCP with the same ability as your GUI, along with a real way to export your data. This is the future with how AI agents will work whether you like it or not. People are not going to want to deal with a GUI if an agent can do it better and faster for them.

Definitely not a substitute, and a bit slow, but GPT computer use is demonstrating an alternative path with live vision models. I'd be curious how this is fairing for those with vision impairments.

I believe AI can be huge here. Things like ADA are often mechanical (adding the correct attributes to the most important page elements). It is the perfect work to audit and fix using agents.

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.

Using AI to close gaps in accessibility is like adding treads to your vehicle because society is too lazy to pave roads.

I think they were suggesting using AI to audit for accessibility, which is probably a better approach, and probably more effective than a lot of the basic accessibility checkers out there that work on a list of fairly simple rules and don't understand the context of what they're doing, so tend to give either very limited advice, or sometimes even offer bad advice.

Research and fallbacks would certainly be better. An 85% design, 15% algorithmic solution is probably the sweet "pobody's nerfect" spot, but a company using AI to solve accessibility is like selling rape whistles -- in a perfect world, your market is nonexistent.

I think people outside of enterprise have no idea the cost to audit and fix a massive website.

The law is a forcing function here. Lawsuits can and do happen when sites of a certain size fail to implement government-mandated laws. This is a good thing, IMO, but it only comes into force in the largest cases.

If there is a credible path to 1/10th the cost (while still providing liability insurance which is a critical piece) then that will likely encourage more enterprise to do it proactively, and will open the door for startups and mid-sized companies.

I have no idea why anyone would choose to see this as bad.

I'm not outside of enterprise and have worked hands-on for over a decade with AI-driven customer workflows. The cost of accessibility audits are NOT higher than AI R&D or third-party B2B contracts for vaporware touting to do the same.

Sorry if that assertion stands opposed to your value prop.

The state of affairs in the last 6 months bears almost no resemblance to the state of affairs in the last decade.

No need to apologize, neither of us can predict the future. I am optimistic Fable-level models can succeed where the old not-actually-AI models failed. No shame in being pessimistic about the same.

Well isn’t it like asking the AI to pave roads?

> 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.

Do you know one of the most underemployed groups are disabled people? And do you know where a number of disabled people get employment? Disability audits (unsurprisingly they're extremely good at this).

Congratulations on recommending further marginalising an extremely marginalised group.

I suppose it is a question of balance between: the entire web being better for all those that require accessibility vs. a subsection of that community holding their jobs. And it raises the possibility that the increased accessibility could lead to more job opportunities.

But I'm not really a consequentialist and think of things in virtue ethics terms. And using technology to scale benefits to a wider group of people doesn't conflict for me. YMMV.

It's not "virtue ethics". It's a fact: turning accessibility testing over to "AI" will deprive a group of low-income low-agency people with skin in the game of employment.

If society were perhaps more compassionate, and supportive of this group, then perhaps it wouldn't be so much of a problem.

As to your point about significantly improving accessibility of the web, we could do that right now, all of us, without "AI". We could have done that yesterday. Use semantic HTML, instead of injecting div-soup using Javascript into ad-riddled dark-patterned user hostile slop-pages.

"AI" (or accessibility audits themselves) are a bandaid after the fact. Accessibility needs to be baked in.

Wait what? We should withhold accessibility features to not marginalize disabled people?

No, we should not withhold accessibility features. I wrote nothing to suggest that we should.

I wrote that a group of marginalised people would be further marginalised, and deprived of income and meaningful work in a sector where they are, by circumstance, subject matter experts. Anything else is projection.

>No, we should not withhold accessibility features.

So if AI finds and fixes the accessibility deficiencies thats good for disabled people right? Not marginalizing.

The point is that there are unintended consequences, a real cost to people who are already struggling. The broader disability community is already noticing, rather sourly, that accessibility for "AI" is suddenly a prime concern, where they have been struggling for decades to get any attention or consideration for their own needs.

What is better for everyone is if the people building the systems start with considering accessibility beforehand instead of shipping something broken then fixing it.

The companies who think AI means they get to reduce headcount will be eaten.

Why not have WMs and DEs specialized for specific disability categories?

Both your window manager, and desktop env, already have a gigantic tree of accessibility systems built into it.

... And then your app turns into a canvas made in Electron.

I used to do loads of accessibility testing with my sites.

I was fired because I did too much once

> Democracy is about access

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.

Democracy is not about mob rule, it's about a dialog. Sure, sometimes it becomes heated argumentation and noise, but it's not so much about "ruling". Lincoln in his union address in 1860 said: "I so adopt it because it furnishes a precise and an agreed starting point for a discussion between Republicans and that wing of the Democracy headed by Senator Douglas."

"Democratization" in a sense is about making things accessible for discussions. "Dictatorship" is the opposing term - things get "dictated" by a single entity - person, political force or a corporation.

> Democracy is not about mob rule, it's about a dialog.

No my friend, Democracy is majority rule, which easily turns into a ruling mob. It has nothing whatsoever to do with dialog.

Also, your quote of Lincoln's address is taken completely out of context. He was talking about his opposition of the ideas of a faction of Democrats who were in favor of slavery and his support of the majority of Republicans who believed slavery was a moral, social, and political evil.

In other words, take the time to at least do some research before you try to use quotes in support of a failed conclusion.

Did you read the Greeks in school? Probably not. I recommend Plato's Republic. Both he and Socrates talked about the flaws of direct/pure democracy that would usually make it degenerate into mob rule.

In Republic Plato developed a hierarchy:

  Aristocracy: Rule by the wise (my comment: a fantasy)
  Timocracy: Rule by the honorable (my comment: another fantasy)
  Oligarchy: Rule by the rich (my comment: a reality in many societies)
  Democracy: Rule by the masses (my comment: glad we don't have this)
  Tyranny: Rule by a despot (my comment: plenty of examples of this in history)

It took until the late 1700's for the idea of a representative democracy to actually take hold, with Alexander Hamilton being credited with the terminology.

So, "democratizing" means letting the masses have their way. It does not mean making things accessible to everyone, which is the hilariously or tragically ignorant way in which Silicon Valley tries to use the term. You see startups all the time say "we are democratizing <X>". Just how stupid are these people? They are saying we are going to let the mob have access and benefit from <X> not making it available to everyone.

In the context of Plato’s political philosophy the modern, casual use of the word "democratizing" completely ignores the historical and philosophical baggage of the root word democracy.

The irony is that modern society uses "democratize" as an undisputed positive term (meaning liberation and fairness), while the very philosophers who birthed western political thought used "democracy" as a warning label for instability and lawlessness.

A better term for what startups want to say would be "commoditizing": turning a specialized, elite resource into a public good or a widely available commodity; not "democratizing", which is an ignorant use of a term that means almost exactly the opposite.

I guess classical education has not been a part of schooling for quite some time. As a kid I did not necessarily enjoy reading the Great Books. As an adult, I can see how much damage has been caused by the abandonment of such valuable teachings.

Classics are still there, at least they were for me. Then again, i didnt have the pleasure of experiencing American public education.

As much as i do agree, overtime language does eventually change but it can happen over our dead bodies

> language does eventually change

Exactly, words do not carry their root's connotations as a permanent tax. 'idiot' used to mean "a layman, someone not holding office or lacking skill', or "a person not interested in politics"; 'nice' comes from Latin 'nescius', which meant "ignorant"; 'cretin' meant "Christian".

Democracy is not mob rule, and the Greeks agreed. They had a separate word for mob rule: 'ochlocracy'. Having two words means the Greeks did not treat them as identical. Plato and Aristotle argued democracy tends toward it, but they still have not treated it for a definition.

Bringing Plato here is kind of weird: The Republic is an anti-democratic aristocrat's argument, written by a man whose teacher was executed by an Athenian jury. Plato was born into the Athenian elite. His mother's family gave Athens tyrants whose regime killed something like 2000 citizens in less than a year. Plato initially was invited to join, he considered it, and pulled back when he saw what they did. He was part of anti-democratic coup. Citing him here for the word definition, is like citing Marx for the only definition of 'capitalism' - not exactly inaccurate, and might be even exactly correct, yet the context and connotation still matters - Plato took neutral-to-positive word and gave it a hostile reading, while Marx haven't even talked about 'capitalism' (he had "kapitalistische produktionsweise"), the actual term as we know it was popularized later.

'democracy' aside, "make accessible to all" is a long-established dictionary sense of 'democratize', it was never a Silicon Valley invention. And you're right - "representative democracy" only took hold in the late 1700s. The term's meaning moved after Plato. If democracy could shift from Plato's warning label to a thing Hamilton endorsed, 'democratize' could shift too.

I implore you, good sire (@robomartin), to unsaddle your high horse and let the language take its course - if people and times decide to give words different meaning, it most likely will happen anyway.

Pantisocracy: rule by socks and panties.

> Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way.

You're just parroting an old urban myth.

The terminus technicus for mob rule is ochlocracy [1]; democracy, per se, includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with).

1. [https://en.wikipedia.org/wiki/Mob_rule]

>democracy, per se, includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with).

Democracy has nothing to do with minority protections. I don't understand you can say it per se includes minority protections. Democracy includes whatever enough people think it should include. If people don't want such protections then there is no need for them.

If a democratic society does not want to live side by side violent murderers and thugs they can agree on ways to deal with that minority group like killing them or imprisoning them.

> Democracy has nothing to do with minority protections. [...] Democracy includes whatever enough people [italized by me] think it should include. If people don't want such protections then there is no need for them.

You just proved my point by demonstrating your utter ignorance of the topic: Your three sentences encapsulate the textbook definition of ochlocracy (or laocracy), i. e. mob rule. Which, as already outlined, is not democracy.

I suggest you read some authoritative and up-to-date texts on democracy before embarassing yourself again.

>Your three sentences encapsulate the textbook definition of ochlocracy (or laocracy)

The textbook definition of ochlocracy is a small group of people taking justice into their own hands. That is not what I described in my post where I explained how they can come up with rules and processes and how to deal with things as opposed to having a mob deal with it.

> The textbook definition of ochlocracy is a small group of people taking justice into their own hands.

No, that's not the textbook definition.

That exchange has sadly run its course for me for I have no interest in reading tedious counterfactual clichés, especially not ones outside the scope of the thread's actual topic. One can only hope you embark on that suggested reading journey to better understand the emergence and evolution of (modern) democracy.

Good luck!

No thank you. I will not be reading about what I already understand. If you want to believe a different set of definitions feel free, but you will find that you are overcomplicating simple concepts.

"democracy, per se, includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with)."

Does anyone believe this?

That was my first thought, that a TUI is still a GUI. Close your eyes and explain how you can use a TUI from the keyboard. The only difference is what the display can render.

Modern GUI frameworks maintain a visual UI tree for on-screen interaction, and a semantic tree for accessibility features. You can find TUI libraries that do things like this, but for most TUIs, if you close your eyes and have the UI read to you, you're going to hear "dash dash dash dash dash dash bracket dash", because the fundamental concept of a TUI is in-band UI signalling.

For accessibility (the topic of this subthread), TUIs are not like GUIs.

I see, modern "GUI" programs aren't just GUI, whereas a TUI is just a GUI.

I don't think that's the right way to frame it. To me, in-band vs. out-of-band signaling is the real dividing line, and has been all the way back to PARC.

I worked on Microsoft’s Windows QA team long ago. My team used to have “No-mouse Tuesdays”: you were supposed to do all your normal work but only using the keyboard.

What I wouldn't give to work for a company that actually cares about QA.

Which is not Microsoft. Maybe back in that day but today no. It's more Quality Assumption now :)

Even back in the day they were bad. Things generally worked but were rarely pleasant

I assume MouseKeys was cheating ?

Send fair to me: someone’s got to test Mouse Keys! :)

I guess that team was dismantled some time ago, with no on carrying the flag anymore. Modern windows is impossible to work on using just keyboard. Some mods & extensions do help. But the native experience is abysmal.

Yes and especially the new web-driven apps are terrible at it.

My touchpad doesn't work anymore. Why is it so difficult to connect a bluetooth mouse without a mouse? The "mouse detected, want to connect?" notification shows up ON THE SCREEN but I need to enter a bunch of shortcuts and navigate through multiple items just to be able to click yes.

The keyboard support in "Modern" Windows apps is so random. In the new Notepad, the dialog that appears asking if you want to create a new files shows Yes and No buttons, but it doesn't accept Y and N keys, only Esc and Enter. However, the dialog that appears when exiting without saving does accept S and N for Save and Don't Save. These inconsistencies are everywhere in UWP.

In the context of discussing TUI vs GUI (as the article does), the accessibility and keyboard control balance probably swings very strongly to native GUIs; in a TUI you’re at the whim of the TUI framework’s stabs at accessibility support, while on a full fledged native UI you have all the bells and whistles of focus management and text to speech and voice control and high contrast and magnification and motion adjustments…

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.

> 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.

That's not why. It's because TUI apps have to be designed around the strong possibility that a mouse isn't even available.

Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes, in which case the screen reader might have issues picking it up too.

And in a TUI you don't have to deal with that window management crap. Moving stuff around because something else is on top. Everything happens within that little square.

> Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes

May I present OpenCode, which somehow managed to break copy from terminal: https://github.com/anomalyco/opencode/issues/4283

Not requiring a mouse isn’t a magic pathway to ‘accessibility’ though. The fact that something can be used with a keyboard does not obviate developers from the need to consider other aspects of accessibility.

Also: when I copy paste out of an application I don’t want a bunch of spurious chrome glyphs and newlines - copying just the text contents of a TUI scrollable text field isn’t trivial and isn’t always guaranteed to work

> Also in a TUI you never ever have that issue that some text isn't copy/pastable

Telle that to Anthropic, as Claude code doesn't let me copy any text from its TUI.

There's TUI and there's CLI. TUI has always been poor man's GUI, back in the day it was even literally called GUI. CLI on the other hand has zero similarities with GUI. You write the command and the command executes and that's it. Writing commands is inherently the most accessible form of controlling computers, second only to dedicated single-purpose buttons that don't mesh well with this whole "general purpose computing" thing.

> Writing commands is inherently the most accessible form of controlling computers

Not if you don't know enough of the commands and have to research every one you need, and it's for a problem you likely won't encounter again. Oh, and you have to do this without breaking anything. To say this can slow a person down is a dramatic understatement.

There is a reason menus were invented very early on in computing history, well before 1970.

Most accessible, not most convenient/efficient/easy to learn. It's very very hard to beat entering text in terms of how many people on Earth are physically capable of doing it (considering all the available methods, including text to speech).

Yes, but this article is about TUIs

It's very hard to make a TUI (or a web app) that has 0 screen reader accessibility. It's also much harder to make a TUI that has great screen reader accessibility (it's much easier for web apps). "native" apps are a much wider spectrum.

With a TUI or a web app, screen readers will always have some access, because no matter what you do, the text layer is always there. This may not be enough accessibility to use the app or to complete some specific workflow, but a screen reader user will at least have a rough idea of what's going on. For web apps, that's a good basis to start from once you finally realize that accessibility is something you need.

Desktop apps are much more of a mixed bag. Most frameworks draw their UI themselves, basically pixel by pixel, instead of using some text-based platform primitives. If your framework doesn't expose UI semantics to the OS, a screen reader user gets absolutely nothing, basically a blank window with no visible content or controls. If you're just a developer using that framework, it's a very difficult situation to get out of, once a11y becomes a business requirement.

GTK on anything but Linux is the major offender these days, so are many niche Rust frameworks and anything involving game or game-like UI. QT, Java Swing and Flash used to be this way historically.

I’m specifically talking about native apps. iOS apps built using UiKit are going to have first class accessibility support.

Besides the TUI program itself, you also have your terminal emulator (unless in a TTY) and possibly a multiplexer like tmux. I use irssi inside tmux from my phone a lot and you can get pretty precise control with keyboard shortcuts that make up for some of the flaws of a touchscreen. Like instead of mashing or holding the arrows to go back and fix a typo, I'll use the readline binds and hit esc and b a bunch of times to close most of the distance, then switch to arrows at the end if needed. The tmux copy mode is also pretty friendly in the same way, you can vary gradually adjust your selection start/end without having to hold anything down.

I'm able. I have no idea or wish to go cosplay as my mental model of someone having to use tools to access my website. I use accessibility tests that make sure content has readable colors. I set a content anchor so people can navigate without sight. I would really like to learn about any frameworks that can help me make my websites accesible to everyone. If there a gold standard?

This is something that we have been working on in our app, but to be honest: it is hard. At first we wanted to be completely keyboard centric, but we had to pivot away from it.

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.

And this is where the conversation gets ugly. Yes accessibility is important. And if you can add it with little additional effort, great. But its not the most important thing when you’re trying to get something off the ground with limited resources.

This has always been a bit of a drag, but the way we/I used to do websites and the way I still like to do them, was to focus on content, then apply a style and javascript layer as decoration. The keyboard navigation and accessibility considerations come more naturally then. For those that don't see this as important it feels like a case of cart before the horse.

I ended up stuck on my back, bed-bound in 2005, with a keyboard on my thighs. Using OSX (probably Tiger) and mostly native apps it was possible to get by with just the keyboard. It was the only platform that I could use without a pointer and I was hardly pushing boundaries.

These days just doing simple things like setting up a computer for the first time, I often can't be arsed with a mouse, or I am in places where there isn't room to use a mouse. I have to resort sometimes to a trackball out of necessity, but it's always a hassle and I frequently hit brick walls. Simple file managers can be nightmare enough. I remember just trying to navigate to a taskbar on some desktops being impossible. I couldn't get to something like the network manager applet. Thankfully there's a CLI for that now.

On the flip side, I also love the idea that you can do most things with a simple pointer.

I was trying Batocera linux recently on a laptop, the touchpad wasn't recognised, it's a gamepad driven OS (I think a layer on retro-arch), and navigating with a gamepad (once you RTM and figure it out) is actually quite nice. Kodi, has always been a bit of a faff on the keyboard, and that works well with the gamepad. Kodi was born on the Xbox so this of course should be a given. The UI for me with a keyboard has always been a bit clumsy.

It's hard if you think of it as an afterthought. It's easy if you keep it in mind from the start and choose your stack and approach correctly from the start.

That's usually the problem with startup software - most if startup engineers will rather burn 10 hours coding that 1 hour thinking and choosing the right things.

What are some examples of the right things to choose? Are you thinking in the direction of technical decisions (e.g. the right programming language), or more about product design decisions?

Having done exactly this for adding accessibility into a crypto wallet in the past, (yes crypto wanted even the disabled), it is plainly obvious why this is not standard.

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.

> the second a tab is off

Can you explain what you mean by this phrase?

A conventional way to navigate GUIs is by using the Tab key to jump from control to control.

A common way this can fail is if the Tab key traverses through the UI elements in an unexpected order.

Also, please avoid animations and transitions, or at least add a button to reduce them.

This is where using a common framework pays dividends. For example, on the desktop I can disable animations for all GTK applications.

I stopped using GNOME after 3, but there were still quite a few animations in the GNOME core programs despite having the disable animation setting set. I wonder if that's changed.

Yeah, wonder if things have changed in 15 years....

My people. I can't tell you how much time I spend trying hack these out, especially when base libraries hard code them. Accessibility isn't just sight/non-sight.

Relevant WCAG sections: https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide.... and https://www.w3.org/WAI/WCAG21/Understanding/animation-from-i.... Basically, respect the "reduce motion" OS settings.

I have a traditional desktop app/GUI app, where I have a table (treeview) of words with their translations and pronunciation (like a dictionary). There can be thousands of words in there. Also there is a filter/search field, where one can input any string to filter the table while typing, or confirming pressing enter/return. The words in the table can be in any language, if the configuration of the application is adjusted to the language.

How would I make this more accessible for the blind or people with bad vision?

1. Make sure that the tree view control has screen reader support and that it has all the normal keyboard commands (such as right/left arrow for expanding/collapsing a parent node).

2. Make sure that the text box has a label that says “search” or “filter” and not just a magnifying glass icon. You can only get away with an icon if the GUI toolkit allows you to give it an alt text.

3. Make sure that this label has a hotkey (underlined letter) and that it's properly linked to the textbox so that pressing the hotkey actually focuses it.

4. Make sure that the tree view is next after the textbox in the tab order.

5. Make sure that it's obvious how to cancel a search. You've already assigned Enter to performing the search (as opposed to closing the dialog) which means you can't use Escape because that is already required for closing the dialog. I think one way is to let the user empty the textbox and press Enter to clear the search, but you can also have a separate button as long as it has a hotkey and an alt text if it's just an icon. This kind of button is allowed to sit between the textbox and the tree view in the tab order, but make sure it stays that way and you don't add 10 more buttons there so navigating to the tree view becomes arduous.

I think it's ironic that I can give all of this advice just by being a keyboard user. I'm not visually impaired and I don't use a screen reader.

Hm OK thanks for the pointers.

Point 1: I don't know whether tkinter's treeview has screen reader support. I will have to look into that. But what I did already do is to make it focusable, which it wasn't by default, I believe, and add controls like: up, down to select rows, pos1/home and end to go to first row or last row, space to select/highlight a row, I left right and left arrow key for opening and collapsing items, added enter and various other keys to trigger actions for focused row or all selected rows.

Point 2 I definitely have.

Point 3: I defined a shortcut (ctrl+f) that always focuses the text input widget of the filter, but I don't have a letter underlined in the label. The label is actually "Quick search" and not "Quick filter", which means I couldn't underline an "f". But also underlining any letter might indicate, that one could press ALT+letter to focus the input. Maybe I should add another shortcut to facilitate that and then truly underline the appropriate character. Maybe change the label to simply read "Filter" and use the "F".

Point 4 I have. The filter is directly under the treeview/table, and only one TAB away.

Point 5 I don't have, because as the user starts typing in the filter input field, the treeview/table is already being filtered concurrently. Pressing enter is just for when you want to repeat a search and not change the filter term. For example, when the words have changed concurrently due to other actions. There is no dialog to close, because this is all in the main window. I have been thinking about adding a dialog that displays a progress bar, or adding a progress bar in the bottom status bar of the application. There a stop button might be useful. But so far the searching/filtering finishes in milliseconds, so no one would have time to click that stop button.

> I defined a shortcut (ctrl+f) that...

Please leave standard shortcuts alone. Ctrl+f lets me search the page for content. It should never search anything other than the current page.

Edit: nvm, thought this was a web app / page. A native app having search this way is normal

When building web apps, I prompt humans and AI with “the best design is accessible design” and start from there.

It always ends up being faster, clearer, simpler, and better.

I understand the sentiment, but there are limitations. You can't make a wheelchair-accessible treehouse, but that's not an argument against treehouses. Democracy is about letting people do whatever they want, the laws that forbid treehouse cafes aren't particularly democratic.

Both Google and Apple have MCP-like interface frameworks for agents that developers can enable so their apps are not dependent on touch or vioce or keyboard or pointing device or D-pad interactions.

This is the correct way to do it because it puts the interaction responsibility into the agent, not the app. That enables the agent to work across multiple apps to achieve tasks by interacting with the user. That's where both sides of the interaction should live. That's where the context of the interaction exclusively lives because no individual app holds the full context. That also makes it the place where solving adaptive interface challenges is best implemented.

Couldn't agree more. Using a screen reader is an incredible learning experience, and it really teaches you just how extraordinary people can be: its incredibly difficult to get anything done. And then there are the people with motor disabilities, the deaf, and on and on.

I got interested in accessibility some 30 years ago, when I got to visit the lab at University of Washington. Its unbelievable the progress that has been made. And AI is having a huge positive impact as well.

I'll also say that if you can get a chance to go to a place like a google accessibility lab for a demo or even better watch a live usability test with disabled users, do it!

How do you square this with YAGNI? A lot of development time can be wasted making something disabled-accessible that will never have a disabled user.

Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter.

Part of the blame lands on the shoulders of popular UI frameworks (or in the case of those choosing to eschew use of such, the developers who made that choice). The older frameworks tend to make this fairly easy; for example, in Cocoa/AppKit (Mac native UI framework), one can pretty easily wire up their entire UI for proper keyboard navigation entirely visually (mostly just consists of connecting nextKeyView outlet between controls to produce a logical chain to tab-focus through). Defining key shortcuts is also simple; add a menu item for a command and set its corresponding shortcut (which in turn allows the user to rebind the shortcut in System Settings at will).

That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.

Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible

As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious.

On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.

MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse.

It’s in the accessibility settings.

https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...

I cannot think of a single reason these would be disabled by default other than Apple stubbornness.

This is the company that popularized the mouse and GUIs, why are you shocked?

Because it's stupid. Why would accessibility features enabled by default on Windows and Linux be disabled by default in MacOS? There is literally zero advantage to disabling it, and it makes life harder on users.

Same thing with tap to click. Once everyone else enabled tap to click Apple disabled it. They just HAVE to be different, even if it's bad for users, and that stubbornness is frustrating.

If you expect your users to mostly work with both mouse and keyboard, it can make sense. Dropping stuff from the tabbing order means that the stuff left is is quicker to tab through. I find it mostly annoying.

Tap to click, though, that’s infuriating. I don’t know how people can stand it. I know people who insist they like it and then I see them accidentally “click” regularly and get annoyed by it.

No, keeping it disabled makes zero sense. There's no reason now to force people to enable it. Most people don't even know you can do it in windows so it's not like there's a huge problem for them. No reason not to leave it on here.

To a large extent, I believe it's a holdover from the earliest days of the Mac, when the mouse was brand-new, and many developers had to essentially be forced to even support it, let alone treat it as a first-class interface device.

I agree that it would be nice if Apple would have more keyboard navigation available by default now than they did then, but given that it is readily available for those who want it, I don't really see it as a huge issue.

"Some holes"? That's an understatement.

There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".

> There's no option to bring up a context menu with the keyboard.

That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.

> Since at least macOS 15 the context menu key on typical keyboards is recognized and functions

Apple's adding it to its own keyboards as well, at least on the third-generation Magic Keyboard with number pad (between F13 and forward delete).

The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user.

I quote from Apple https://developer.apple.com/design/human-interface-guideline...:

> Always make context menu items available in the main interface, too. […] In macOS, an app’s menu bar menus list all the app’s commands, including those in various context menus.

Therefore one can rightly conclude that there is no need for a key to bring up a context menu.

In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users.

This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.

Not working for your particular preferences isn’t a bug; your preferences are just wrong for the vast majority of users.

The hubris of HN posters never fails to astound me. The most niche of workflows, then wonders why regular users don’t all learn esoteric keybindings and use TUIs.

I don't know if this is aimed at me or not. I don't use this workflow; in fact I'm pretty bog-standard in many of the ways I use my computers. In any case, I don't see how expecting to be able to bring up a context menu is in any way esoteric. We're in a thread about navigating GUIs using a keyboard. On many keyboards there's literally a key dedicated to opening a context menu, and on most OSs there's a pretty standard shortcut to do it as well, which is what GP was talking about and what sibling comments discuss being added more recently in MacOS. So, again, not very esoteric.

I also don't see how trying to emphasize empathy toward users translates to hubris. But sounds like you've got a bone to pick, so keep picking I guess.

To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.

My theory is that Mac was born with a mouse while Windows (and Windows apps) originally had to function on machines that might not have one. Thus, keyboard navigablity was prioritized, and that design sensibility stuck around longer.

I think it probably has more to do with Mac's lack of adoption by the US Government and large corporations.

Microsoft took accessibility of Windows and apps as a basic requirement. The fact that Windows is the daily driver desktop for the staff of the regulatory agencies that would bring complaints would not have gone unnoticed.

But really, why wouldn't you? You almost get it for free if you use the standard widgets, and smooth keyboard navigation is far faster for experienced users than having to repeatedly move one's hand between keyboard and mouse.

You would be baffled to know that after the creation of the mouse, Steve Jobs wanted to remove the arrow keys so developers would be forced to create mouse only interfaces.

Not baffling at all. Wasn't he against the two-button mouse?

> Windows components however, especially old ones, are incredibly accessible

Bing, Bing, Bing! I came here to vent how the new windows 10 and windows 11 interfaces (made by Mac enthusiasts, ughh) have omitted keyboard accessibility for a cleaner look. They also dropped drag and drop support (which I never knew about in windows 7) and I completely missed how useful it could be on Windows 10/11.

For whatever it's worth, the new W10/11 designs aren't in line with traditional Mac design philosophies either. They're more in line with those of iOS and Android with how they tend to bury and omit options entirely and prefer massive whitespace.

Somehow that is a bigger insult: reducing a desktop to act like an iPhone.

Tons of built in winui3 stuff is still very accessible by the keyboard, metro era though what pretty rough.

Yes the search feature plus using tabs and spaces bring about accessibility. Frequently it misses the underline letter , alt keyboard shortcut.

>That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.

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

I know of at least 5 different UI frameworks in different languages which are partially accessible or completely inaccessible. Some include Dlangui, Tkinter (although this is getting better), DearImGui... Really any UI that decides to draw it's widgets by frame. QT also has some accessibility problems. In apps made with any of these, they are either impossible to use with assistive technology (and therefore the keyboard) or they are very difficult to use.

Dlangui is so niche that I am amazed to even see it here. DearImGui is intended for thowing together some slap-dash UI widgets for debugging things like interactive rendering.

Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them.

> Dlangui is so niche that I am amazed to even see it here.

Eh, I'm testing whether I can make it fully accessible, since I happen to like the D language itself. But the UI without my changes is entirely inaccessible.

> DearImGui is intended for thowing together some slap-dash UI widgets for debugging things like interactive rendering.

That's probably what it's intended for, but people use it for far more than that, which is a problem. Even if it weren't, it's inaccessibility is a problem.

> Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them.

Sometimes. Depends on the widget. I've had QLineEdit's crash apps when all-select-copy workflows have been used, or with NVDA on win32 you can't ordinarily read a multi-line QT QLineEdit or other multi-line input since the focus will remain on the first line, always. Webviews are entirely inaccessible at the moment.

Thank you for your work in DlangUI. Progress on it has sometimes been so slow that I mistook it for abandoned. It has great ideas as far as its API design goes, but the implementation wasn't very sophisticated yet last time I looked. I think that D deserves to have its own mature UI library and DlangUI is probably still the front runner.

Are there any modern cross-platform GUI frameworks that do this well?

Unfortunately, the intersection between “modern” and “do this well” is pretty much the empty set.

It's not even in consideration anymore since the plaque of electron swept over desktop apps.

> That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.

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.

This has been a source of tremendous frustration for me. I was really happy to discover c. 2009 that you could get browser extensions that let you do anything on a website (like clicking links) from the keyboard. But increasingly, they're failing at making items detectable as clickable. Which is like, why? How do you go through the effort to make a framework to automate the process of putting in UI elements ... and somehow fail to comply with basic standards that would allow interoperability.

I suspect that a lot of the resistance to disability compliance in websites[1] is due to how it would let you bypass ads. If a screen reader can cut through the cruft to get to what you need, then everyone can use software that does it.

[1] like in the Domino's case https://news.ycombinator.com/item?id=21188092

It's so weird for me to live through software evolution to the point where this no longer goes without saying.

In the Windows 3.1 days, it was nearly impossible to make a program that wasn't fully keyboard-usable. Even if you left out all the hotkeys in the menus and messed up the tab order, it was still possible (even if annoying) to get through it with the keyboard, and adding the hotkeys (as well as actual shortcuts) and setting a sensible tab order was super easy and straightforward.

Nowadays more than half of all software is made using non-native GUI toolkits (or sometimes no toolkits at all) that refuse to implement any of the typical keyboard navigation that would previously have come for free.

The keyboard makes computers a joy to use for me. Seeing it disappear makes me very sad. Seeing how the vast majority of people don't care that it disappeared makes me feel like an alien from another planet.

Same. I think part of the problem is that keyboard shortcuts are often not very discoverable. For example on Macos, pop-up dialogs often have keyboard shortcuts for their non-default buttons, but I'm not sure where you're supposed to learn this. Lack of discoverability leads to many people not using them which leads to devs not implementing them.

I wouldn't care to read manual for my microwave, as long as basic functions work. Similarly, people don't seem to bother to use their software to its full potential.

Computers have become appliances.

My favorite example of keyboard power is qutebrowser¹ which turns any website keyboard navigable as well as all browser functionality too. It's a really fast and comfortable work flow.

https://qutebrowser.org/

Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it.

HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corny.

(This reads harsher than I intended. Sorry about that. I love Arch Linux people. It's just think it's no less noble to serve the average Joe than to create the perfect tool for power users.)

The argument is that both should be supported, which seems like a valid wish. There's really no reason to either-or this. Just have both work.

Well the two--building for power users vs for a general audience--often work against each other.

And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.

Do you have an example of how supporting a keyboard shortcut for every action could be bad for a general audience?

Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming (or at least one of many parts that all together become overwhelming) to new users, while not having them shown at all makes them undiscoverable.

I think this is a bad reason. Even MS Office has made this work. But I've seen people act on this type of argument. If nothing else, it should be possible to have a settings menu where you can define your own. Even if no shortcuts are set by default and they aren't shown anywhere else in the UI, it will still be possible for a power user to make the best use of the program.

> showing the relevant keyboard shortcuts in the UI can be overwhelming

Every application did it for decades after the first Xerox guidelines up until Microsoft and Apple decided to retire the concept of usability some time around 2010.

something something smartphones

At least Apple still shows them when you hold option. At least they did when I still used a Mac.

> showing the relevant keyboard shortcuts in the UI can be overwhelming

Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.

This works poorly if you intend to localise your application. Great if you don't though.

It sounds like your complaint might be that it works poorly if you half-ass the localization process and assume that literal translation of strings is most or all of what localization means.

I'm not sure how you read that from my comment.

To be fair to your point though, that's what most localisation of programs are these days.

Windows did both successfully.

I can't remember an example that didn't also include the shortcut written in full, but I might just be drawing a blank here. Care to give an example?

Wasn't easy to find!

https://www.augenbit.de/wiki/images/5/57/Arbeitsplatz.png

Yup, pretty sure I've seen the same sorts of things using Asian characters.

Fair. I just remember them being inconsistent between the English and localised versions of Windows, and given I used both, that turned into a nothing-feature. Another comment mentioned you could edit the underlines in Office 2003, but I never knew that back in the day (or until today for that matter...).

It's pretty hard for the shortcuts to be consistent and localized. Especially if you also use different keyboard layouts when you're using different languages...

Even for keys that aren't mnemonic, do you want undo to be ctrl + z or ctrl + the key closest to left shift?

> It's pretty hard for the shortcuts to be consistent and localized. Especially if you also use different keyboard layouts when you're using different languages...

Hence my original comment. I haven't had a problem with different keyboard layouts, since most of the keys that change are on the outer edge, nowhere near where the most common shortcuts are located (then again, I rarely type using QWERTZ).

> Even for keys that aren't mnemonic, do you want undo to be ctrl + z or ctrl + the key closest to left shift?

CTRL+Z, since that's what it's been since time immemorial, even on ISO keyboards. Consistency is king.

And for complex languages like CJK, often the key you would press is not even present in the string at all.

Example: What should the accelerator be, and how should it be displayed, if your "Exit" option is labeled 終了?

I checked VLC and apparently they use: 終了 (Q)

Even though "Q" doesn't necessarily make any sense to Japanese people who don't understand any English.

Japanese keyboards also have Latin labels, so it's at least possible to put two and two together there, although it would probably be better to write '終了 (た)' (unless there are local conventions to the contrary).

Effectively nobody in Japan uses or even knows the kana keyboard layout though, only QWERTY. My comment was more that they may not know the word "quit" for the Q to be meaningful to them... not that they can't find it on the keyboard.

Similarly as an English speaker I would be quite confused if the shortcut key for exit was a totally different letter like P or something.

(Speaking of menu/drop-downs with underlined characters for alt commands.)

> This works poorly if you intend to localise your application. Great if you don't though.

Sure that's true. But remember M$ allowed you to fairly easily edit those underlined-characters in, oh, for example Office 2002 and 2003. Even if you didn't have a lot of default underlines in your current language settings, it is still possible for someone to add their own underline-shortcuts.

Back in those days, the first thing I did on any personal new install of Outlook, was to disable the shortcut that marked all email as being read. (That's cause I hit that button by accident too many times.)

> Sure that's true. But remember M$ allowed you to fairly easily edit those underlined-characters in, oh, for example Office 2002 and 2003. Even if you didn't have a lot of default underlines in your current language settings, it is still possible for someone to add their own underline-shortcuts.

That's a feature that was hidden from me at least, but honestly, this is a good-ish solution to that problem.

I remember Office having the underlines, but they were inconsistent between the original English and my localised version (and I used both depending on the machine), which made them useless. That wasn't that big of an issue when all the normal keyboard shortcuts are also written out, but it would have been even less of a problem if I knew how to edit them.

Even then, English has become the defacto language of computing. Some amount of knowledge of its basic vocab is expected, and many computer related words in other languages are english loanwords.

> Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming

That is not a requirement, having access to menus, a master help shortcut ir fuzzy search actions shorcut are other options.

Another person here is arguing for accessibility, which may have been overlooked.

Which, if you made say a regular Win32 application, was guaranteed. These newfangled frameworks dropped the ball, if anything.

Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down.

This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu item's mnemonic key, and if you ever forget, just look at the menu.

It was the keyboard-friendliest idea ever, without requiring any sort of terminal. I'd even say friendlier than MacOS (heresy!!) or, yes, VIM (burn the witch!!!)

Even if you didn't have mnemonics, you could use tab, arrow keys and alt if needed, to navigate, and space to "click" buttons and such.

So even if the developer forgot to configure mnemonics, which was as easy as prefixing a letter with ampersand, you could navigate by keyboard. Sometimes tedious but beats not being able.

> Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down.

> I'd even say friendlier than MacOS (heresy!!)

Honestly, I disagree. If you've used macOS for a length of time, you might be aware of the universal menu search system using (cmd+? i.e. cmd+shift+/). Hit that, type the menu item name, and simply hit return to activate it. Doesn't get simpler than that. The alt+ system always feels very janky to me on Windows because on many apps, hitting Alt relayouts the entire app sometimes to show the menu bar on top.

Usually though, the menu bar only appears on key release, not on holding it down, as part of pressing the ALT+something shortcut.

> cmd+? i.e. cmd+shift+/ (...) Doesn't get simpler than that.

That's a very two-handed ableist view. Imagine having lost your arm and being told hitting three keys on opposite ends of the keyboard is simple.

I'm joking, but only about the calling you ableist and the emotional response parts. The situation does really occur. Keyboards aren't always the most accessible option.

(Hotkeys reveal mental limitations in myself. I can rarely remember them. I know a ton, but I've forgotten so many more. On MacOS in particular, when multiple modifiers are involved. Can never remember if it's cmd-shift, cmd-option, option-shift, cmd-ctrl, cmd-fn, or whatever.)

...What? Opposite ends?

The Shift key is right next to the / key.

The Command key is one key away.

Even on laptop keyboards.

I can trivially chord Cmd-Shift-/ with my right hand.

Power user experience is not the same across disciplines either.

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

Why do you introduce the concept of being forced to in the conversation?

Because most people do not get to choose what software they use for working?

Can we stay on topic? We are in the subject of making UIs keyboard drivable.

Accessibility != Keyboard

you are arguing against a strawman.

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.

> For example, why did Edge and possible chrome, remove support for Back via the backspace key?

Because people were triggering it by accident all the time. Firefox and Safari don't navigate back on backspace either.

Enter only auto-submits if there's a visible submit button or if there's just one input, and that behavior goes back as far as I can remember.

I'm surprised the person responsible for <backspace> mapping to Back navigation didn't mandate that <del> would be super awesome for Forward navigation.

Nono, that should close the window xD

right now, i cannot even enable Backspace = go back on Edge. I am forced to use Edge on my work computer and i hate that this feature is gone. Not disabled, just gone.

About enter to auto submit, i've been running into this problem more often where some web frameworks just ignore the Enter key. There is a submit button, but i cannot trigger it via the enter key.

Every small feature is used by some subset of users, but if you don't trim your software from time to time then feature creep will eventually make it incoherent. Yes, it involves even small details like this one. I don't think learning another hotkey is a big problem, and anyone using keyboard navigation on the web should generally be at least aware of a ton of existing Vim-like navigation extensions (and even browsers)

Is alt-left to go back a bad keyboard shortcut for you? It's what I use.

It's also far less likely to be accidentally typed while trying to fill in a form and fumbling the tab navigation.

Yeah, that wasn't an attempt to remove keyboard navigation, that was fixing a painful error in keyboard navigation.

Yes it was an error because backspace does function as a backspace when a text input field has the focus. Making something that should be muscle memory context-dependent.

It should have been Ctrl-Backspace or something.

> For example, why did Edge and possible chrome, remove support for Back via the backspace key?

Because alt+left is a better choice? Really f**ing annoying when some dumb javascript removes focus from a text box you're editing and the page navigates back.

Agreed. I'll say the same about accessibility. People really need to test for this more. If your app is not accessible I literally cannot use your app regardless of how useful it might be. This is pretty much why I currently don't use IDEs like Zed: even if I wanted to I can't because it presents no accessibility tree.

> 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?

Because web pages don't preserve element focus well, web was originally meant for documents in the first place, not UIs. If you're trying to erase a character and the focus has been lost, you go back in history instead. It's a real existing problem in poorly designed pages, not a nefarious plot to annoy power users by Google, Microsoft, or Mozilla. It was always janky as hell.

I specifically had to disable that via about:config in Firefox ages ago because I pressed it by accident all the time. Often while I was going through a 30 point form, only to then lose all my progress. To be fair, browsers probably should try to not undo progress like that, so you can just go forward again and get right back where I started, but I've never trusted them to actually do that. I've been burned too many times.

I can kinda get that one.

Where this falls apart is commercial software. The issue is we use off-the-shelf frameworks and tools for commercial software. And then we don't train developers on how to write high-volume software.

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.

I think you vaaastly overestimate how excel is used by most users

if anything, excel exceeds in being MOUSE-driven - it's intuitive in what you press and what you drag

and that's kinda my problem with the TFA - author is not representative of typical user. Mouse interaction is the king

Maybe by most users, but not by most users who use it for many hours daily for professional tasks (i.e. not just as a kind of tabular list editor).

Basically everyone in a white collar job who is NOT a developer is using Excel. I'm a developer, even I have to use Excel at work.

that's exactly what I'm saying

basically everyone uses Excel. And basically everyone is a MOUSE-first user (or, even further along the chain: TOUCHSCREEN-first)

keyboard-based menu navigation is not intuitive. it can be "poweruser" oriented, but it's not for most of the userbase

Keyboard shortcuts for those menu items are what most people will learn -- save, print, cut, copy, and paste will be the common ones that a lot of people will know.

I'd be willing to bet that professional typists and people who spend the majority of their day typing (email, word, IDEs/text editors, etc.) are the ones who will know more keyboard shortcuts and navigation, especially for the things they do repeatedly.

> Keyboard shortcuts for those menu items are what most people will learn -- save, print, cut, copy, and paste will be the common ones that a lot of people will know.

I would say that it's true that the keyboard shortcuts for those items are the ones most likely for people to learn, but not true that most people will learn them.

I've spent 15 years in (tech support/programming for) academia, working with genuinely very smart people who use computers every day of their life, many of whom are actively looking for better ways to use those computers in their teaching and research, and 9/10 of them go to the Edit menu for Copy and Paste every. single. time.

It really depends on how much you use it. If it's hours a day, you are a power user, and you'll learn the shortcuts. Otherwise it's annoying.

"Most users" are not who choose business software.

Screwing with a keyboard combo in Excel... like Shift-Space to highlight a row... is like an IDE deciding to swap the key-bindings for '{' and '['. You'd have entire accounting and marketing departments in rebellion.

Devs consistently underestimate how many power users of Excel there are, and often don't understand how they operate.

I got my wife a new MacBook Air, and figured there's no point in paying for MS Office, iWork is fine for the household stuff she needs it for.

She loved Pages, being able to put images anywhere without stuff moving around behind her back.

She hated Numbers, since there were no cut/copy/paste/undo buttons on the toolbar. This is someone who has been using Excel at work for decades at this point. Definitely had a sudden insight as to how differently many users work.

> UI constantly shuffling around between updates.

and then 365 came along ... an option to pull stock market data here, a LinkedIn connection there, oh look a wild copilot button appeared.

> …and that means that users can input and navigate at light speed.

Oh yeah? I remember when they introduced these shitty animations that made everything feel extremely laggy.

From the article linked below:

"Microsoft Excel now animates certain actions as you work. For instance, when you move from one cell to another, it animates the move. When you paste copied information, it animates the paste. Or when you enter a formula, it animates the calculation."

https://www.adventuresincre.com/disable-animations-excel/

No honestly some harshness is warranted, most of the people alive have internet access and a smartphone, this is a more ubiquitous activity than many others we require or expect accommodations from. This site has a lot of good to offer, but sometimes the bubble needs a reality check that their needs and concerns are even more niche than disabilities like Blindness.

FWIW, I think it's a blind spot to think of power users as "Arch Linux people" using "developer tooling".

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.

Eh I think things like vimium have kinda solved this.

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"

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

So, omits the text-labelled buttons?

No? I’d say just test or YouTube how it works. Its a bad explanation

It really is not so much about keyboard vs. mouse - power users vs. average Joes. That all is just a discombobulation that distracts from the main issue and the issue is the accessibility of plain text.

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.

> But most people aren’t willing to deal with the learning curve of keyboard-driven GUIs.

Keyboard shortcuts should be an _optional_ way to interact for accessibility and power users! They should never be required!

This is what TUIs get wrong, they make it the required way to navigate and often don’t even let you use the mouse.

In some cases you may need the keyboard accessibility.

- Your mouse/trackpad breaks or isn't recognized?

- The right mouse button for your trackpad isn't working for some reason (e.g. you spilled a drink on it). It should still be possible to use the context menu keyboard button to bring up the context menu.

- Your hands are on the keyboard (typing a document, email, code, etc.) and it slows you down to move to the mouse/trackpad to perform an operation such as copying/pasting text or bringing up the spell checker context menu actions so you want to do those with the keyboard to keep yourself in the flow.

Most often you'll learn keyboard shortcuts/interactions for your workflow then expand out as and when you need them. Sure, knowing all shortcuts and interactions is fairly limited, but the majority of people will know how to cut/copy/paste with the keyboard as those are common operations.

Whoa there.

Allowing people to use keyboard is NOT the same as forcing people to use keyboard.

Also, very few users will use only the keyboard, but quite many will use some part of keyboard access. If today I need to switch between proofreading languages a lot, you bet I will learn the keyboard shortcut for it (and forget day after that, until next time I needit again)

I don't know where you got "forcing" here. The author is arguing for guis that give the option of keyboard use. Unless you think having hot keys underlined nonconsensually imposes visual complexity and confusion on the hapless non-power-user, I don't see where your argument makes sense here.

What does it mean though for a GUI to be keyboard-driven? The obvious way is that every action simply gets a shortcut assigned. My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.There is the issue of discoverability. The best practice right now seems to display the shortcuts of buttons in tooltips, menu items, or when pressing a different shortcut. I’d content that buttons are a fundamental mismatch with keyboards. A keyboard driven UI shouldn’t have buttons. The issue is that genuinely keyboard driven UIs like CLI or TUI suffer terrible discoverability that being the reason that mouse driven UI exists in the first place. So can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?

Oh, finally somebody who gets it! That was incidentally my major disappointment with vim: it is keyboard driven, but the UX wasn't designed to be a perfect keyboard experience (which I expected, given how old it is).

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

Even as a fairly confident nvim user, I still use and recommend <https://github.com/folke/which-key.nvim>

Even as a devoutember of the church of emacs I couldn't live without the emacs version of which-key [1]

[1] I was going to link to a repo, but I just learned that which-key is included in Emacs out of the box.

Yes, they should be discoverable. There are platform conventions for this: on Windows you'll see underlined letters; menus show you the shortcuts. Tab is a pretty much universal "move to next field" shortcut and I don't think that's particularly discoverable if you don't already know it.

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.

Since you mentioned Windows, Microsoft made Ribbon which uses Vimperator-style navigation to make toolbars and buttons discoverable as long as you know one hotkey (Alt). It can also be hidden until triggered with a hotkey. This is miles ahead of most discoverability tricks in power user interfaces, including fuzzy command search which is not guaranteed to remain stable as new commands are added.

One downside to the ribbons that I see is that they somehow inverted the hierarchy between menus and toolbar buttons: Previously, menus were the slow but predictable way to find a command, and both toolbar buttons and keyboard shortcuts were just that - shortcuts. Menus were a sort of "ground truth" which commands existed. They also had a standard way to be navigable through the keyboard: You can press alt and then simply use the cursor keys.

With ribbons, the menus were gone and the toolbar buttons became the "ground truth", but in a much more haphazard way.

Fuzzy command search goes a bit back to menus, but as you say in a way that's much less guaranteed to be stable.

One of the reasons I loved learning Helix is that it shows you the list of possible next keypresses every time you press the first key in a combo. Amazing for discoverability. It even works for user defined shortcuts!

To me spacemacs nails the discoverability aspect through helm-Mx-fuzzy-matching and which-key

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

I think a first step would be a sane tab order, so you can easily navigate to a control using tab or cursor buttons. Second step are keyboard shortcuts.

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.

My logic for determining if a GUI is keyboard driven is pretty simple: if I can fire up a screen reader and completely drive your UI via the keyboard, then by definition your UI is keyboard-driven. If your app ever requires me to emulate mouse clicks to drive it, then it isn't entirely keyboard-driven and that should probably be fixed. This is even something that can be measured/tested for on platforms like Windows where you can both read the accessibility tree (which in itself is amazingly powerful particularly for testing) but you can also simulate arbitrary input.

"What does it mean though for a GUI to be keyboard-driven?"

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.

The fundamental difference is that mouse input requires unpredictable motor movements. We can't queue mouse clicks because the user doesn't even know where a button is going to appear. Even if they did, the actual physical mouse movement needed to get there is different every time. There is a necessary mouse -> screen -> eyes -> hand -> mouse feedback loop for every action.

Keyboard input can, when designed well, be fully predictable and require no feedback loop with the computer. The motor movement involves a fixed set of physical buttons, which we can fairly easily train to press very reliably, and that training is then universally applicable across all software.

That is why you can buffer keyboard input but usually not mouse input. With keyboard input, I know what the software is going to do and I know exactly what hand movement will get it to do the next thing, so I can perform that movement even before it's ready. With mouse input, it's not really possible.

I love this idea. I also just checked out your blog (jerf.org) which also has some gems.

Making UI interactions bufferable has appeal to me as well.

I had a similar thought but just for the more conventional 'keyboard shortcuts are not discoverable' problem.

Using the status bar or an overlay showing on-screen-keyboard shortcuts, the app could give visual feedback every time you click a button or slide a widget revealing what keyboard shortcut would have triggered that same action.

I click the "GO" button: OSK overlay or status bar shows [GO] (Ctrl+G)

I slide a widget to turn volume up: status bar shows [Volume 22->37] (Alt+V,22)

Keyboard specific focus + navigation, shortcuts, poupable command entry/console (eg ~ in mpv, or quake :D) with commands that interact/integrate with the GUI side.

start with CUA standard.

Its only been around for 50 years, but few people ever consider it.

> A keyboard driven UI shouldn’t have buttons.

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.

We know what it means for a GUI to be keyboard driven now:

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...

LLMs do solve the discoverability problem which underpins every power user feature ever. It is fantastic to be able to describe what you want without the domain knowledge that was previously a prerequisite to achieving that goal. Hopefully as more systems create declarative ways to interact with them (MCP, clis), power users will be able to profit from this as a side effect as well.

They sidestep it (partially), but I don't think they solve it. Sure, you'll get your task done if the agent does it for you, but the agent won't show you how to do it without their help. So the next time you have to do the task, you have to ask them again.

I also think this is misunderstanding "discoverability" a bit. For me "discoverability" also means you get an understanding of what options are available at all in the system, which can be helpful to get a better idea of what you want to do in the first place.

Seach and chat-based UIs always assume you already have a perfectly thought-out plan what to do (conveniently in terms if the software you're working with) and just have to type it in.

Look how many programs and features exist on Earth.

Project this forward to the worlds of 2050, 2076, 2126.

Your "understanding of what options are available at all" becomes moot when every program has so many options that you couldn't read them all in a lifetime even if that was all you did. Or when the answer is effectively "everything". Future programs will vibe single-use features like you make a disposable regex for every search. You don't cement xyz\d{3} into a feature, and you don't ask "show me all patterns I could search for".

At what point is "how to do it without their help" a strange thing to say? Select text and press Ctrl+B for bold, you reply "no I want to do it without the software's help". What? Typing [b][/b] markers, coding a function call, pointing to a bolded font - there's no world where you "do the bolding" and the computer "doesn't help". There is a submerged iceberg of bolding with a bit poking above the surface where you press Ctrl+B and feel you are doing meaningful work. Like the story of instant cake mix, it was a market flop until they removed powdered egg from it and turned it into "just add an egg" cake mix, which lets us feel like we are still cooking.

Why does Future Word need an "insert picture" feature? It can press enter a few times and display that picture of your dog in the gap, easy. If you had a personal assistant they would not have a please-call-my-partner-and-say-I-will-be-late-home "feature" and you wouldn't want to micromanage which cellular network and which audio codec was used, and you wouldn't say "I want to call my wife without the telephone's help". "Insert picture" doesn't need to be "a feature" any more than the regex "xyz\d{3}" needs to be "a feature". Future turbo-LLM has seen you write every document you've ever written, future Microsoft Word has been trained on every document ever uploaded to Office 365/SharePoint/OneDrive. Future computer tracks your typing when you pause for emphasis, or hears when you speak with emphasis, or the cameras observe as you scowl for emphasis. When you indicate the bit that you want emphasised, it puts bold markers on that bit, and you won't give a damn how - whether it put [b][/b] markers or whether it printed the document through a virtual fax machine, simulated a hand drawing more ink on the simulated print, virtually faxed that back to itself, ran OCR on the incoming fax, identified the added ink as the bolded font, and put <p class=></p> and a CSS stylesheet indicating the bold font.

> "Seach and chat-based UIs always assume you already have a perfectly thought-out plan what to do"

What? CLIs assume you have a perfectly thought-out plan, and understand the internals of the tool, all its options, and how they combine. You either type `fffmpeg --foo-transform --start-frame=234 --bounding-box=0,0-100,100 --option=reticulate-splines --reticulation-formula-bellard-optimal` or you get an error.

A GUI assumes you have a plan and you can find your way through the menus to find the foo-transform, then the popup dialog box will prompt you with textboxes, comboboxes, radio buttons, for the options, which you can set using your plan. You still need a plan but you don't need as much software internals.

Chat based UIs are even more of that; you type "I want it to look like an old photo" and it says "here I setup the foo transform for you with options that will make it sepia toned, here's preview, accept?".

Yes, there should be a difference between keyboard accessible and driven.

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.

It's perfectly possible to design a GUI without button controls, where literally all the interaction is done with keyboard inputs. It's still not a TUI: it has graphical visual layout, and the UI signaling is out of band with respect to the data it's presenting.

I'll try with an example first, and then will try to extrapolate to something more general.

I'm a longtime Emacs user and I detest tools like VSCode (VSCode in particular) because they aren't fully keyboard driven. "Fully" is the important part here. You can do a lot of things with keyboard in VSCode, but every now and then there isn't a way to do what you want without the mouse. And it screams "bad (no) design". For example, jumping between different panes in the editor is not always possible without a mouse, or the path to doing it is too long.

Before my attempt at generalization, I also want to address these:

> UIs like CLI or TUI suffer terrible discoverability

They typically do, but they don't have to. The reason for making a CLI and, to a lesser extent, TUI is the development speed. A full graphical interface will take longer to develop. So, whoever ends up making a CLI or a TUI tends not to invest time into accessibility either, because their goal was to save time on the UI in the first place.

Another aspect of this problem is the baseline knowledge. Users of graphical interfaces know how to discover functionality, they recognize familiar controls and patterns, they know that a cogwheel icon is likely to be a gateway to a program's settings, that if they want to make their changes persist, they need to look for something that looks like an open folder, or maybe a diskette icon...

Emacs has absolutely amazing discoverability. No program with graphical interface ever made doesn't hold a candle to what Emacs can do. But the user needs to have the baseline knowledge to... ironically, discover the discoverability. And I don't think there's a way to bootstrap from this problem. The minimal knowledge necessary to discover Emacs' features must come from reading the manual or asking a friend etc. Just to give you a few examples: Emacs can easily display all, without exception, keys and associated functionality available in the current editor's layout. It can also display them per individual component (if you, for example, knew that a key was defined, but was missing from the aforementioned list). You could also use the function name, if known, to find what key it binds to in the current layout. You can easily discover what any key (combination) does in the current layout without actually trying it (rather reading its documentation).

> can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?

Absolutely! If we commit to a general set of rules that allow bootstrapping. This would require a degree of uniformity between such tools and, perhaps, some visual or even physical aids in the computer periphery to make this work. Computer interfaces, both physical and on-screen, evolved to support mouse-first UIs. For example, the navigation arrows on the keyboard are virtually never drawn on jklm etc. The keyboard is presented to its users as a tool solely designed for entering text, not a tool to engage UI controls. Compare this to gamers' keyboards that often emphasize wasd keys (because they are often used for moving your character in games) or even more extreme designs like Nostromo that are geared towards typical game interface.

* * *

Being keyboard-driven isn't about, as you said, having a shortcut assigned to an action. This is not how good keyboard-driven programs work. This is the way of thinking if your baseline experience is a GUI, which must be somehow retrofitted into the world with the keyboard as a primary driver.

Keyboard-driven, to me, means that the program has a systematic, hierarchical and consistent approach to deal with the keyboard input. Assigning keys to actions at random will quickly overload the user's ability to memorize such bindings. A keyboard-driven program is designed to have a system that the user can internalize and use to predict the right key for the desired action. Such a program should make no exceptions when binding actions to keys: any action should be accessible in a reasonable small number of keystrokes.

Demoscene music tracker interfaces come to mind.

https://news.ycombinator.com/item?id=49093434

I agree but I think being usable by the keyboard isn't enough, because the shortcuts are often hard to discover and remember. I think the ideal is - like good TUIs - GUIs should put obvious hints on screen how to navigate via keyboard.

It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we can standardize on something.

Agreed. Also, I would support everyone building off of vim principles. If keyboard bindings are somewhat consistent across applications, that would be really nice and there are already a bunch of options using vim bindings as a starting point, since they make intuitive sense once you've learned the "language" vim uses.

Yeah, keyboard binding consistency is what I really want. Ideally, you could choose between Vim, Emacs, <whatever else> keybindings for the program you're using.

I think what's also needed is a standard way of navigating what I guess I'll call the "focus tree". For example, if I'm running Vim inside of a terminal multiplexer (eg: Zellij) inside of a terminal emulator inside of a tiling window manager (eg: xmonad)...

It would be GREAT if I could use Vi keybindings to navigate windows in whatever "focus layer" I'm at... and then have a "standard" keybinding to navigate up and down that tree (eg: "Ctrl + >" and "Ctrl + <").

Right now, everyone seems to solve the "focus tree" problem by trying to choose a control key combination that won't collide with any other process that might be listening for key chords at the same time.

And it's not just for websites.

Analogy: the doorframe is of a standard width so that a wheelchair can get through. This means manufacturers can make equipment that will fit in your house without calling you first! You never have to worry you bought a new refrigerator that needs to be pulled into a hole in the roof because it won't fit through the door. You never have to worry about delivering food to a grocer because your hand truck and boxes will fit, and there is a ramp instead of oddly shaped stairs. Nobody needs to be in a wheelchair for this.

Within built environment and industrial design that's termed universal design.

The canonical example is ramps on footpaths providing equivalent benefit to people in wheelchairs, parents with strollers, and commuters on bikes, scooters or skateboards. The door width example you provide is another perfect case.

There are many aspects of things we design and build where a small focus of accessibility for one group brings benefits to many.

The standard doorway width came before the standard wheelchair width

ty for the correction and my sudden urge to research doorframe design

> While it’s true that if you randomly pick a GUI and a TUI application, the latter is more probable to be fully keyboard-driven, this does not tip the scale in favor of developing TUIs over GUIs3. What it does is highlight the inadequacies of keyboard navigation in many GUI applications.

Something to consider is a terminal that has keyboard navigation of its own. Through a terminal shortcut, I can move the cursor at will and copy any text at all, even if it's part of the interface of a TUI. If I want to copy the filepath of the file I'm working on in vim to then use in a shell, for example, it takes like 5 keys to copy it straight off vim's statusbar. A graphical text editor can display the filepath in a tab or something, but I can't copy the text off the tab.

I don't know if I'm alone in this, but it's very frustrating to want a piece text, see it in front of you, and you can't copy it because the developer for one reason or another didn't implement copying of that text, so you have to type it out even if it's right there.

Sometimes it seems on purpose too. For example, when a game on Steam gets updated terms of use, you get presented with a window showing the terms, but you can't copy them to save them. It's like the purpose is to just accept and forget the terms. A TUI can't prevent the user from copying text by its very nature.

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.

Any text-centric action will have a great advantage when done inside a terminal. I would think the equivalent in GUIs would be first-class OCR support on the compositor level. I am not informed about any progress made in that region to be honest, so I cannot tell how close we are (or not) to this.

OCR will always ultimately be guesswork. It's up to the font used whether 1/I/l/| or O/0 or -/‒/–/—/― can be differentiated.

OCR now comes built in with Spectacle, the default screenshot utility for KDE Plasma and it can copy the result right away.

>A TUI can't prevent the user from copying text by its very nature.

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.

> 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?

Hold Alt while trying to select to make a rectangular/block selection. To avoid a TUI's mouse handling and use the terminal's, hold Shift. So, for example, if you're on tmux with "panes" (internal windows) side-by-side and you wish to copy lines from a middle one into your X11 primary selection, hold Alt+Shift+mouse1 and drag.

Works on xterm and urxvt. I had hoped it worked on all terminals, but I notice it doesn't on kitty. Maybe there's an extension that adds support. Kind of a waste of opportunity to have a grid of monospaced characters and not be able to do rectangular selections.

> 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.

Yeah, the interfaces of coding agents are really poorly made. It's like they only know GUIs but wanted to have it work for a terminal. They really should have been CLIs instead of TUIs. That way you could just use the terminal scrollback buffer. Would've been simpler to implement, and they wouldn't have needed some special support for copying command and reply.

> Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time.

Hmmm... not really? Maybe you're thinking vim vs emacs, but that's just because they're old and have separate histories. From the point they both became established on their own, multiple interfaces have supported their keybindings. Ranger for example supports vim keybindings for navigation.

Something to remember is that GUIs don't have common ground on this except on the use of Tab and Shift-Tab for jumping between different parts of the interface. Also maybe Alt for invoking the menu bar. TUIs don't satisfy themselves with such terrible navigation. It's NIH and not-invented-anywhere. They must invent to be useful with keyboards.

Mouse support comes second for TUIs. For GUIs, mouse support comes first and keyboards are an afterthought if they're ever thought about. It doesn't seem like GUIs have NIH-syndrome only because they either don't support keyboards or people aren't even familiar with the keyboard navigation they came up with since they only use the mouse.

>Hold Alt while trying to select to make a rectangular/block selection.

I don't see how block selection helps on cut text. In GUI you simply select the partial element and copy it, with either mouse or keyboard. You can also display it (or a tooltip) above the rest while selected, which is what compactified tabular views usually do. Turns out layout engines have a purpose in dense interfaces after all.

>Yeah, the interfaces of coding agents are really poorly made. It's like they only know GUIs but wanted to have it work for a terminal. They really should have been CLIs instead of TUIs. That way you could just use the terminal scrollback buffer.

No, they really are much better off with web or GUI, terminals use unreadable monospace and simply aren't well suited for large amount of rich text, schematics, pictograms, and pictures. They are fundamentally not CLIs as well, they're interactive programs with complex interface layout that is not limited to basic chatbot input+scrollback (let alone text input, it's not just text).

That relates to most TUIs I see, they use TUI because it's fashionable - status monitors, dashboards, file managers, you name it. TUI is suited for very few purposes most of which are pretty basic (e.g. status line-style UIs for CLI), anything more complex such as a file manager and it quickly becomes awkward. FAR Manager had to reinvent everything from scratch (including, ridiculously, picture thumbnails in a custom-built terminal) and it's still worse than Total Commander which just used what the UI framework already provides, for the most part.

>Hmmm... not really? Maybe you're thinking vim vs emacs

I'm really thinking everything vs everything, do you know two TUIs with a common schema that is not a convention? Literally every TUI tool I use (and I use dozens) uses its own layout and keybindings. Maybe 30% vaguely imitate vim's hjkl use instead of arrows in some of their elements, some use ? for help, that's literally about all they have in common. There's no common way for hot path traversal, almost no common paradigms at all. Trivial example, top vs htop vs bottom vs nvtop vs powertop vs god knows what else.

>Something to remember is that GUIs don't have common ground on this except on the use of Tab and Shift-Tab for jumping between different parts of the interface.

Major GUI frameworks such as Qt have hotkey schemas and conventions that are used by default in every program built with them, such as Ctrl-O for opening a file, Ctrl-Z and Ctrl-Y for undo and redo (which they actually provide mechanisms for), menu navigation, or Ctrl-Tab for traversing through focused tabbed elements. Plus guidelines that you can and should follow for consistency. They don't provide everything for every specialized use case but they make mundane actions common for every app predictable and consistent, and of course it's a result of practical use (new apps are being made -> framework devs canonize common behavior).

In any case, none of this is specific to GUI vs TUI as a principle, or keyboard navigation, it's rather about centralized frameworks. Nothing prevents devs from spending the energy on making a good unified TUI framework, or a GUI one that takes keyboard first in the way they want it. It's a matter of fashion more than anything. Nothing replaces good design, certainly not hiding behind the flavor of the day paradigm.

last time i built a crud app (oh maybe about 24 years ago) i made it a point to do this. i remember watching the payroll people fly through their terminal mode vax vms applications with such speed and dexterity that it would make any unix admin well versed in the art of the command line blush and it made me think "oh yeah, all these 90s point and click guis got it all wrong. if people are required to make heavy use of a system at work, they would prefer a learning curve followed by speed, comfort and dexterity over an easier learning curve that trades dexterity for discoverability."

it was a webapp framework, but... all browsing/listing screens included row ids and a focused text box- so that typing the row id and enter would select. all action buttons had an underline to signify which ctrl-shift hotkey triggered them. all edit screens defaulted focus to the first editable textbox and at no time was the mouse actually necessary. finally, load times were optimized to target 75ms.

amusingly, the user feedback was "the keyboard control is pretty good but can you please make it faster."

what i thought was chrome ended up being critical to the users not being miserable.

ALT+TAB, TAB, ↓, ↓, ↓, CTRL+HOME.

For a lot of people this is a recognizable pattern. Switch window, select element, scroll down, then snap back to the very top. The keyboard commands above should do the same thing no matter if it's your text editor or your web browser. People should know these are going to work regardless of what they're using. Because these aren't key commands going to the program, these are key commands going to the operating system. The program shouldn't be able to arbitrarily choose whether it abides by these. Consistency is important not only for speed, but for human understanding and capability. If every door had a different way of opening it such as drawing a series of lines or tapping a certain rhythm or belching thirty feet away people would be mentally taxed discovering that particular door's interfacing method, and common tools would not be able to help those who couldn't find the interface or use it because of disability or differing ability. It's only doors with extremely specialized designs like blast doors that have an unusual interface and interfacing method, because they're designed to do one very specific thing that lies far outside of common use cases. Your chatroom program, image viewer, or archive unpacker is not a blast door. Put a door handle on it where everyone expects it to be.

Mildly off topic, but getting to the original GUI vs TUI debate: Speed can also be a factor. I've yet to find a GUI file manager that is better than Midnight Commander/Far. I think there are some graphical orthodox file managers, but I could never do things as quickly in them as I could in mc.

So sure, add keyboard support to the GUIs. That's always a good thing. Just make sure they're also as responsive as in a TUI. Dialogs should appear instantly, etc.

The other headaches I've had with GUIs (in Linux) is the appearance can change if an underlying library changes. Even if I haven't upgraded the SW, if I upgrade one of the toolkits it relies on the app's appearance and behavior can change.

Somehow this is never an issue with TUIs.

The author makes an excellent point. There are too many poor Terminal UIs created just for the sake of having a TUI. Often these are not well constructed or lack sufficient thought to be effective/productive.

But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. Back in the 80s and 90s Photoshop, Illustrator etc. became the powerhouses they are today because they focused on allowing professionals to be extremely efficient using their array of powerful keyboard shortcuts. In 2026 when software companies are dying of KPItis scoring their product management on creating compelling subscription models to hook customers, attention to actually delivering productivity for keyboard users is often an after thought. Mobile apps don't have keyboard shortcuts and desktop apps seem to increasingly be treated as as the narrow "edge case" with only a few hundred million target users versus the billions available on mobile devices. It's an opportunity for those who get serious about delivering value by leveraging the power of keyboard shortcuts to make their GUIs highly productive and comprehensively usable from the keyboard. For all their faults, Microsoft got this right with VSCode.

Professional and power user software is always keyboard-oriented when it makes sense, I don't see it being ignored. Microsoft even addressed the criticism that Windows was largely not possible to use from keyboard, and massively improved it starting with Win10.

> 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.

>Microsoft even addressed the criticism that Windows was largely not possible to use from keyboard, and massively improved it starting with Win10.

And then shit the bed completely with Windows 11. The (lack of) keyboard navigation is by far my biggest gripe there.

I practically live in the terminal but can’t live without a mouse. I’ve been using Vim (now Neovim) exclusively as my sole editor and everything in tmux including my email. I agree with the power of the keyboard but a properly configured mouse is a truly powerful terminal utility.

> In fact, many GUI framework application guidelines explicitly encourage GUI application developers

Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".

In some cases they do.

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.

So in none of the cases they do - it shouldn't depend on any tags, that's the whole point of bypassing the app devs!

(not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components)

What complicated designs do you have in mind?

Maybe not complicated, but unorthodox. A developer who is not familiar with the correct design patterns may, for example, create a dialog using a FrameworkWindow instead of a FrameworkDialog. In that case the framework can not provide any automation, because the developer is not following the guidelines.

I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.

But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation

And more pressure from more options doesn't follow, you only need to study if you actually want to diverge

> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation.

The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut.

  <object class="GtkMenuButton">
    <property name="primary">true</property>

This is easy to omit and then you will never know about the automation.

Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?

> The developer needs to know what to do.

No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed)

> What if the developer creates an unorthodox menu

What is he draws a circle instead of using a letter O? What of it?

> ..., so a user can configure F10 to open it if you, app developer, forgot to mark it as main

So, basically what you want you want, as a user, is to bind arbitrary application actions to shortcuts and force click events in spite of what the developer has predicted or tested in their interface. I do not think this is a trivial problem to solve. The application would need to have a way to expose these actions consistently.

> What is he draws a circle instead of using a letter O? What of it?

Well, then you cannot expect the screen reader to work, for example, and you also cannot expect to do anything with this weird "shape". The developer has broken the standards and the user is helpless in this scenario.

These aren't arbitrary actions, but standard menu actions (open menu, close it, activate an item). Also not sure how forcing clicks entered the scene. These are possible via keyboards in many frameworks already today.

> in spite of what the developer has predicted

The dev has "predicted" the menu by creating it in the first place? The framework just made sure that this menu is addressable by the user

> tested in their interface.

That's not a big loss, it's not like we've come to expect any serious testing of UIs anyway

> The developer has broken the standards

Yes, so? I don't understand the point relevant to this discussion. Should standards not exist if they can be broken? Should frameworks not try to make following standards easier? Should frameworks not allow user customizations if devs can find a way to break them?

This was my point in my comment[0] in that thread. I've used GUI Emacs for years, it's way better than the TUI version and fully keyboard driven.

Interestingly, people have seen my GUI Emacs and commented "I didn't know you could get images in a terminal". Then I have to tell them it's not a terminal...

If I had to pick the absolute worst things about Teams, which is already one of the worst pieces of software ever made, it would be that it's not keyboard driven at all.

[0] https://news.ycombinator.com/item?id=49397145

> Interestingly, people have seen my GUI Emacs and commented "I didn't know you could get images in a terminal". Then I have to tell them it's not a terminal...

...[finishing with], though you *can* also display images in a terminal, including in Emacs running in a terminal.

My first experience with a GUI was the HP-40G calculators. By their nature, they only have arrows and accept/cancel buttons. It featured very advanced symbolic computation features (CAS that would step you through intermediary results), but the magical thing was how equations, rather than being a series of characters, that you piece up into meaningful chunks through parentheses, where actually displayed like mathematicians would write them. Then, to select and edit a specific part of the equation, you have a natural 'box'; numerator/denominator, etc, then you can drill down into the recusirve structure of the mathematical expression. It also means that regular edits are 'correct' by default: delete a parenthesis and your expression is syntactically invalid, whereas "replace the numerator f(x)^2 by 6a" keep you in the space of syntactically valid expressions. In other words, this is the holy trinity of UI: semantic - accessible - efficient

The experience is unparalleled to this day, although writing it down I realize more why it was never really reproduced. For a browser, I would imagine having blocks like:

A. meta (browser itself) / B. page (DOM) A1. page controls (bookmark, ...) / A2. Navigation experience (font size, dark mode, ...)

One can dream :-)

I agree 100%. The mouse is great and I don't think GUIs should drop it or anything, but it's wonderful to have the ability to keep your hands on your keyboard when doing data entry tasks and the like. I also think that when you design for both keyboard and mouse input, it will force you to consider rough edges of your UI design in a way that you wouldn't have to if you were just designing for one. So the app will be better as a result.

Three levels of GUI workflow operation: touchpad < mouse < keyboard. This is the main reason people fall in love with programs like vim: with enough experience it allows one to completely eliminate interface friction.

I think the main reason people prefer TUI are certain assumptions that come with it. Like I assume a TUI runs on vim like shortcuts, allowing me to move with hjkl. It isn't the case everywhere, but it's what I have observed mostly.

When a software is created for the terminal, it can expect the users to know these certain shortcuts. But this cannot be assured for GUI.

Most TUIs give you keyboard but mouse is a second class citizen, most GUIs give you mouse but keyboard is a second class citizen. To that extent, I’ll take the mouse only any day. I really want to learn over time the 5-15 shortcuts that speed up my day, not be forced to learn all of them day 0. And I say this as a power user, a casual user will use 2-3 shortcuts per app at most.

Nano always shows most important (all?) hotkeys on the screen. (works really well for its usecase)

I work for a company that for years has had a very old-school, terminal style POS. Lots of key shortcuts. Like, black/white text terminal POS.

The folks who learn how to use it well navigate through it faster than the system can process their inputs.

The new system has lots of fancy GUI, but is slower, and the folks used to their shortcuts hate it. But it's so much faster to train people to use.

Keyboard driven, and a lot more!

I love the following patterns for GUIs:

- command-driven (e.g. command palette of VSCode) - keyboard shortcuts call commands, are customisable - scriptable: ability to call those commands from the outside, controlling the running app, for example with CLI calling D-Bus (or socket), and not necessarily having macros from inside the GUI - reorganisable: the different GUI elements like panels, tabs, should be moved by the user and remembered (ideally having layout presets) to let the user adapt the GUI to his/her needs.

I'm thinking of VSCode, Blender

I'm not especially aware about common toolkits like Qt or GTK, whether they provide tools for that.

In web front-end dev, I'm using Svelte, and there are awesome UI libraries like shadcn-svelte, however I didn't find anything rather standard implementing these architecture patterns.

The problem with keyboard navigation is that there seems to be no mature GUI keyboard-first UX concept. "Mouse things" are the way they are, because they fit the mouse-way. We need the same for the keyboard-way. Until then, there seems to be no design concept that can just be copied.

There is, whether or not developers follow it is a different story.

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

That's not what I mean. The site you linked is about how to make a mouse-first website more keyboard friendly, but what I would like to exist is a mature keyboard-first guide.

I mean something like this (my wip keyboard-first file manager): https://ibb.co/G3WBW5C1

The hard part is, there seems to exist no UI & UX design language I can follow to create a nice keyboard-first app, so I have to think through everything (which is fun but tiring).

I don't think this really addresses GP's comment as far as I understood it.

Your resource mostly describes how to make keyboard-based workflows accessible. But just because the full functionality of an app is keyboard accessible, doesn't mean that it works as well as the pointer-based approach - especially if you have an app with multiple menus, sidebars, headers, footers etc. Maybe you could tab through everything, but a pointer will be faster. This is where a "keyboard-first UX concept" is missing (from GP).

I think an interesting idea to solve this would be a "focus navigation mode". Enter this mode with 1 shortcut and then navigate between items with a few keys; like a combination of mnemonics and screen reader navigation e.g. jump between headers with "h" etc.

Top of my head:

- 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".

This does not work great. What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?

Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.

> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?

If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "<N>G", but such a shortcut would seem absurd in another application.

I love VIM-like TUIs, but the discoverability of of them is absolutely awful.

- Underlined letter: Alt-<letter> takes you to that field.

- Spreadsheet-like stuff: arrows, PgDn, PgUp, Home, End, … move inside of it.

>there seems to be no mature GUI keyboard-first UX concept.

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/...

People gave the ribbon interface a lot of shit but one thing they definitely got right was making absolutely every option reachable from some keyboard shortcut. Some of the shortcuts get a little long but you can just add those as a hotkey if you use them a lot.

This is a very narrow viewpoint, considering the majority of computing is done on touch screens now. Sometimes keyboard controls are critical, sometimes they're not, sometimes your users don't care, sometimes they do. Sometimes a pointer is a better human interface for something, sometimes a purpose built controller is, sometimes a multi touch sensitive touchpad is. I wouldn't make an FPS that was just keyboard controls and the same is true of some other types of UIs. Just measure it and be creative and empathetic to how people will use your product who aren't like you and consider the physical interactions as a part of your design space and not just the software.

I moved to KDE from Gnome for a variety of reasons, but I genuinely miss Gnome and Native GTK apps. They weren't as customizable, but the features you did get work so well.

One of my main issues with KDE is that the default keybindings for desktop operations feel like they were designed by people who don't navigate their desktop with a keyboard.

Then there are little things like in Gnome the screenshot implicitly copies to the clipboard, while in KDE you have to click the copy button. There are just little points of friction I experience in KDE that make me yearn for Gnome's workflow. I think my ideal world I would have a KDE desktop that used all the Gnome shortcuts, and worked more like Gnome.

You can set your own shortcuts in KDE. And there is a setting in the screenshot tool to auto copy to the clipboard.

Couldn't agree more, but I think it's majorly a "geek" thing. I'm using i3 on my personal linux and aerospace on my work mac ; vimium in the browser, Neru on the other apps (does something similar to Neru). I recently ended up finding a way to create user-scripts for electron app and since then I'm adding vimium-esque extensions (e.g. in Teams) wherever I go.

I wish this was a default, but also that there was more of a standard to navigate UIs. That's why I really like vimium and other similar extensions, it's following the vi logic across websites, rather than having to learn everyone's idea of how to navigate.

"Just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard."

"It should be possible to move around and interact with every part of your user interface using the keyboard."

Yes, finally. It works both ways; when I have hold of the mouse, I don't want to reach for the keyboard, and vice versa. Windows has had this problem for ages, and probably always will. There are some workarounds, "ctrl-esc" (I do this all the time) and "windows-button", but some of them require really jumping through hoops.

Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.

What's specifically is the limitation?

Let’s use the obvious example of a paint program. Clearly continuous 2D pointer input is an essential feature that would be almost impossible to replicate with only a keyboard. To step back a few levels, a node graph editor with many elements will simply always be easier to interact with using a mouse. But editing text and interacting with other applications such as visual debugger are really only a tiny bit removed from that.

> with only a keyboard

But that's a limitation you've made up, driven by keyboard doesn't mean "only"! It just means that all actions should be possible with a keyboard. So in your 2D paint ideally there should be a way to draw a line with a keyboard

I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).

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 have seen more GUIs these days that don't support even the bare minimum of using tab to cycle through various fields and selector buttons. Which as I recall was introduced in like windows 3.0.

Or page up/down.

I'd posit that less than a half a percentage of users have used the page up/down keys in the last year.

I love TUIs.

I move much faster when I don't have to take my hands off the keys to nudge the rat.

However, I don't think my preference for TUIs is about my efficiency. The most important reason I love TUIs is that they generally only have a base set of features needed to get the job done. Most GUIs go off the rails, implementing features for use cases few people have. TUIs tend to be small, fast, and focus on a small use case.

So even though I started out claiming I love TUIs, what I really love is small software: CLI > TUI > GUI.

Thats really true, small software thats easy to run, and launches instantly has a place in my heart as well. The get sh*t done centric workflow that TUIs offer is so unfortunately often lost in multiple layers of GUI controls...

I haven't seen this mentioned, but... let's talk for a moment about testing automation, and what pain it is to test GUI programs that are mouse-first... It is coincidental, but, in reality, it's pretty much a given, that a program that can be controlled through keyboard will be a lot easier to automate (not only for testing) because of the choice.

A typical way of doing things in a GUI program is to handle "events". The framework arranges for event delivery. The event has properties s.a. what UI element registered it and the sort of mouse action performed, and the handler code specializes on that combination to take the (hopefully) intended action.

When it comes to testing, in order to emulate such events, one would have to calculate the location of the element that "registered" the desired event in order to trigger the desired functionality. This is usually very hard to do because elements change their positions on screen, it can depend on screen resolution, display style of scrollbars and so on.

Another problem with the event-driven model is that it's typically asynchronous. The automation code has no good way of telling when the action associated with the even should take place, or, rather, when it should finish taking place, to assess the results.

Typically, programs controlled through keyboard expose functions associated with desired functionality (because they need to bind something to the key). The test automation then can call these functions instead of emulating events. The detection of the moment when the action finished execution thus becomes trivial.

Agreed, but what "prevents" it is that making a good keyboard-driven UI takes a lot of taste, extra effort to build it, and it must be revisited any time the UI changes. It's duplicated work.

Ideally all GUIs/TUIs are usable with keyboard and mouse independently.

A good example of this is when you have a fancy keyboard-driven workflow yet you can't even do the most trivial task without placing two hands on your keyboard. Sometimes I just want to reach over and do it with one hand on the trackpad.

> extra effort to build it

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.

> This is why we have the “how do I exit vim?” meme.

How to exit is literally the second thing `vimtutor` teaches you, after hjkl cursor movement.

One friction point I have out there is that each major OS has differing keyboard shortcuts available, reserved by the OS vendor, reserved by popular global apps registering common keyboard shortcuts, with the net effect being that even for power users, a given app only has 10-20 possible keyboard shortcuts.

I would love to create a collaborative repo that establishes broadly common modern day keyboard shortcut mappings for common actions across OSes (copy is Ctrl+C in Windows, Command+C in MacOS, Ctrl+Insert in Linux), as well as a map of keyboard shortcuts to actions/OSes and if said shortcuts are app specific vs system global.

I'm given to understand historically that Windows intended the Function keys to help with this somewhat, you had F1-F12 (or F24 for IBM Battleship model M keyboard owners), Windows would do Alt+F1, Alt+F2, Alt+F3, Alt+F4 (the latter of which still closes most apps today), and in a magical perfect world where A) every keyboard actually had function key rows and B) there was a conventional place for common actions across apps that could be used, users could learn more than Ctrl+Z, Ctrl+O, Ctrl++ to zoom in (oops, not always), Shift+Insert to paste, Shift+F11 for context menu.

Where possible, there should be keyboard shortcuts/navigation.

Where appropriate, the labeling of fields and so forth should be such that it will work for a screen reader.

Often, the expedient option is to use an HTML front-end so that one can off-load most of that to the user's selection of web-browser (and where possible, things should be engineered so that Lynx is a valid option).

That said, I use OneNote and Macromedia Freehand and so forth w/ a stylus --- horses for courses.

I have really come to think that most GUI's are misguided, they seek to be easy and intuitive to pick up from the get go hugely at the expense of of speed of the user once they are familiar with the software.

Although where possible software should be easy to learn for lots of programs the user can expect to use the program lots those ones would improve productivity of the user by focusing on speed of use for the user not discoverability and intuitive. Again there is plenty of intuitive design that is also fast once the user becomes familiar with the system but the discoverability and intuitive aspect is weighted higher then speed of a knowledgeable user.

I do think lots of programs would benefit from being more CLI accessible and allowing users to build scripts that lots of modern propriety programs do not allow you to do, at best they have some script engine running in the program that you can call with more effort then it should.

I recently had a revelation when I made an extended qwerty midi controller app that permanently shows the states and functions of all keys including when modifiers are held.

It occurred to me that this is a wonderful way to design software: you immediately know the keyboard shortcuts because you’re already looking at them. I’m working on taking what I’ve built for the qwerty midi keyboard controller (which is built on hammerspoon) and making it just a generic interface for any kind of app.

If the end goal is navigating and controlling the app via keyboard shortcuts, so why not bake that into the design of the GUI itself?

My project if you’re curious: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

Sadly, even interfaces that do support keyboard navigation tend to implement it poorly. Microsoft Office is probably the gold standard here, almost everything can be navigated using mnemonics, all keypresses are buffered and the user seldom needs more than 5 presses to get anywhere.

On the web, keyboard accessible web UIs are a WCAG 2.1.1 level A requirement - that's literally the most basic level of accessibility standard (unless you count 'failed' as a level). If your website / web app isn't achieving that then you haven't tried very hard.

Keyboard driven, and keyboard accessible are not the same thing.

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.

Worth noting that Windows 3.x Paint could be used entirely from the keyboard, as the arrow keys moved the cursor and you could position it with pixel-precision. This is in addition to the fact that the rest of the OS was also entirely usable without a mouse.

At this point what keeps me on Firefox is less the browser engine diversity than [tridactyl](https://tridactyl.xyz/), without which I feel almost helpless in a browser.

some of the most touching reviews we've had have been from people who for whatever reason can't use mice due to physical disabilities.

always happy to hear from people like that if there are things we can improve.

(people who just don't like using mice need no such encouragement to share their opinions :) )

I am kind of obsessed with keyboard shortcuts, ever since discovering Vim a million years ago. The Vim shortcuts are burned into my brain.

I've found that that itch is pretty much entirely solved by Sway (especially since it supports modal navigation, which I have become pretty addicted to), but honestly I actually found Gnome Shell (as of about ~2 years ago) pretty keyboard friendly. Hitting the Windows key [1] brings up the global search and that worked to launch stuff, moving between workspaces worked ok. I know it's popular to hate on Gnome 3 and beyond but honestly I rather liked it.

[1] Or whatever the official name for it is; it's a Windows logo on my keyboard.

I don't know if it's OSX itself or one of the common GUI engines implementations on OSX, but I notice a lot of apps (including Firefox when you try to save a file which would overwrite another file) will have popup modals with multiple buttons and there's no way to click the non-default button with just keyboard.

For example, in Firefox, trying to save a file when a file by that name already exists, you get a "Cancel" or "Replace" prompt and you can "Cancel" by pressing return, but if you want to "Replace", you apparently HAVE to use mouse or trackpad!?!

The mouse is amazing, if you have a good sensor, a mousepad and no mouse acceleration. Not many have this setup, but those who do can wield their cursor with insane speed and accuracy. Consider top osu! or Starcraft players.

In video games, you're typically resting one hand on the mouse and the other on the keyboard fairly consistently.

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.

I use a cheap notebook Logitech mouse, have for years, it's light weight is easy on my wrist. And I'm a gamer but to the FPS type games as much.

Besides JavaFX[1] are there any free, open-source, object-oriented, event-driven, cross-platform, native GUI frameworks that allow for keyboard-accessible UIs? Preferably using a modern language such as Go.

When I developed KeenWrite[2] over 12 years ago, I chose JavaFX because it was (a) bundled with Java; and (b) ran on Linux, Mac, and Windows. JavaFX was later ripped out of Java, to my chagrin, forcing a number of technical contortions.

[1]: Not free on Windows due to Microsoft's $500 cert signing process.

[2]: https://keenwrite.com/

I wish that every app had the StarCraft system where the letter to press a button is indicated. Like:

- New *G*ame - *S*ettings - *Q*uit

Ideally keys should be centered around an area of the keyboard and not just the first letter.

I do agree to some extent, but were GUIs not made specifically to reduce so much reliance on the keyboard? And a few people here did mention that this "fully keyboard-driven" workflow would probably be used by power users primarily.

Like anything else in life, I think there's no single answer to this.

But for people interested in seeing the difference between mouse-driven vs keyboard-driven flows while web browsing, check out the Vimium extension. It made my sentiments very much favour keyboard-driven workflows

I would submit that the point of the GUI was necessarily "anti-keyboard" as more "pro-discovery", plus adding gestures that would be difficult on a keyboard.

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.

I've been on this kick for a long time. A few years ago I was exploring a UI design tool that was entirely keyboard-driven, using pneumonic keychords inspired by Vim: https://github.com/danielvaughn/stride

My experience is that while it's awesome to have really deep keyboard-driven experience, it can't _only_ be that. You need some graphical controls to help guide users.

Ideally you should have both. Every action should be doable by mouse only and by keyboard only. That way you can cater to all kinds of users.

I say this as a vimium user:

Don't make me use a keyboard for drawing.

Don't make me use a keyboard for video games.

Don't make me use a keyboard for 3D modeling.

There are probably many more exceptions.

Stop pushing for global rules.

Accept diversity.

Given Bloomberg Terminal's success, and all the IBM terminals at warehouses and big stores - this is more than apparent. But only few understand UI to design it right.

surprising that this is the only comment about the bloomberg terminal, used by all the financial industry wordlwide. Actually i'm surprised than there is no financial website using the same mechanism of the bloomberg terminal. This is crazy simple to learn and use.

screams market opportunity. but then it took roughly 20 years for search-in-endless-menus to be discovered by majority of software. still not there in its complete form though...

Co-sign. This is one of the reasons I’ve always loved NetNewsWire as my RSS reader and few things have been able to displace it. Everything is doable by keyboard, and the keyboard commands are extremely logical and intuitive. You can FLY through your backlog.

Excel is the same way. I’ve been an excel power user as well as a Sheets power user and the latter just never managed to enable the level of speedy keyboard navigation Excel could. I can almost work blindfolded in Excel.

the fully keyboard driven website is difficult to achieve, in some part because of accessibility tools, first off every OS has their own hotkeys and keyboard shortcuts, generally with some explicit modifier, the reason for modifiers is that it is good to have a key you push in coordination with some other key to force something to happen outside the functionality of whatever thing you are currently interacting with.

Second browsers often have their own hotkey combinations. Same things apply.

Third screenreaders have their own hotkey combinations that make the screenreader do something.

fourth parts of your site probably have their own specific functionality for key presses, like this text box I am writing in right now.

fifth people with accessibility issues and just anybody with some technical needs or abilities may have set their own global hotkeys in their particular OS.

sixth some keyboards might not have the keys you think of as really clever modifier keys.

So, if you really wanted to get around problems of potential hotkey collisions you should provide a default hotkey set that users can edit and override , and that is why I always get accused of over-complicating everything I do.

One of the pieces of software I sell is motorsports timing software [0], it has a GUI for newbs, but at the bottom of every window is a little bar that shows the list of shortcuts. People pick them up quickly!

And it's auto generated from the UI code. It still surprises me how many people just prefer the mouse anyway, though. But the option is there!

[0] https://sidewaysdata.com

A GUI is indeed superior to a TUI. And keyboard driven should be both. But neither is my preferred UI. I want CLI programs callable from my shell.

This way I can quickly repeat an action from the past. I get a history of commands inserted. _And_ I can bind my own keyboard shortcuts if necessary. TUI and GUI do not meet this level of platform independence.

If a tool is TUI only I will not adapt it. That's not the case with a GUI, though.

Keyboard driven UIs are easier to instrument by alternative interfaces and has very positive accessibility implications. However, "shoulds" in computing lead toward a "tyranny of compounding responsibilities"; adding interface complexity to a project, particularly the suggested alternative input vectors may cross an upfront and/or maintenance development cost limit for a project.

Back in the early 1990s, mice were fragile enough that Apollo salespeople were trained to be able to do their demos keyboard-only as backup (at least for tradeshows) and that was just generally how interfaces were built. It wasn't an accessibility thing, it was a "we're demoing expensive systems to even more expensive people, it had better work" thing...

I'll go one step further: anything you can do in a GUI should also be possible to do through a CLI and yes, also with code libraries. If webapps have n-tier architectures, then so should GUI software.

(we can lie and say that this is to support AI, in actuality it's to have proper programmatic automation and support for custom interfaces instead of GUI apps being black boxes)

I agree but how does this work with stateful apps

Pass data around. Run a local HTTP server or any other type of socket, like how Docker does.

The one UI invention many web UIs now add is the universal command search bar. I’m most familiar from it from Jetbrains IDEs where it’s been for over a decade and it is a remarkable upgrade on browsing menus. With the KeyPromoter extension on I even learned the keyboard shortcut over time. Good UI pattern and now this universal command search is everywhere: Cloudflare, Mercury, etc.

Love it.

Similarly, under macOS in most apps ⌘⇧/ opens a full menubar search which can surface most app functionality from the keyboard. Not quite as good as a command palette but close, and devs don't need to do anything to opt in except populate the app's menus properly.

Well TIL. Great tip. I only ever hit that key combination when I look around Finder and find myself unable to go up one level easily from the icon bar - an action I do constantly.

A few years back I started to try to use my computer by not touching the mouse. Ended up writing a bunch of Tampermonkey scripts for my most used web pages to add fast keyboard navigation shortcuts.

Also a lot of webpages have it already built in, by pressing "?" they show a nice overlay. For example github and gmail have it.

For github I still ended up adding a quite a few more shortcuts.

You can always take it to the next level by using an extension like vimium[1].

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

Yes I tried it for a while, it can be nice.

I really like this kind of thing but I wish there were more tutorials to help get good with keyboard shortcuts. vimtutor was lifesaving

My take in this case is to learn incrementally. Like the pebbles in the shoe, I remove the more painful one first (the shortcut for the action I do the most), get used to it, then remove next more painful., and so on. Usually I begin to get a little comfortable with 4 or 5 shortcuts.

I think we should also be finding ways to make things keyboard-driven that currently require a mouse. My side project is a keyboard centric flowchart editor which tries to merge the two between something typically 2D with pixel coordinates (normal flowchart software) and fitting it into a grid that has discrete coords so you can navigate with arrow keys.

> The takeaway is simple. Do not compromise on the user experience you provide with your application

Same thing I hear from everyone.

"You can't compromise on UX" - UX experts.

"You can't compromise on security" - Security experts.

"You can't compromise on Accessibility" - a11y experts.

We gotta make trade-offs, and I gotta get my thing shipped (for me I learn toward security for my service)

> We gotta make trade-offs

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

Or even the original premise of agile, which was to iterate on it. But "iterate" these days means "onwards to the next feature that we'll only drive to MVP", not, "polish & fix bugs" or … do things like enhanced UI for power users.

Not if you have a deadline.

You are right. Maybe the wording is a little too absolute. If you gotta ship and later try to slowly address any shortcomings in different areas, this is also a step in the right direction in my opinion. Just don't completely forget about those areas just because you have already shipped by that point.

this is absolutely not true since December 2025. the amount of "nice to have" items I've been commanding LLM to develop is a dream come true.

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 driven is fine, when you have a keyboard. But many users are now on phones or tablets, with a severely limited keyboard that takes a big part of the screen. But they have a variety of gestures that regular desktop machines don't have. A good UI should happily handle both of these extremes, and everything in between.

Smartphones and tablets support keyboards, and often even have official ones to buy.

When I learned Webdesign accessibility was a main factor, always. Today it seems more like the absolute exception, even Ai doesn't care about it by default.

In professional work many customers were like "nah, we don't need that, we won't pay for that"

I don't get how and why we evolve backwards in these things.

Hotkey usage means speed. Ironically you hinder people using their capabilities to the fullest. It also works in the other direction.

And I agree with you: Vibe Coding literally automagically includes it, and I had the notion, that you must actively advise an LLM to ignore Web Accessibility.

I understand that developers in the traditional sense were shunning the topic, but via LLM?

I never found it easier. Of course here and there you have to lead the LLM in the right direction as usually.

TUI, GUI.. we need a marriage of both, with configurable levels of integration, which controls to favour TUI or GUI. If it's well done, no need for a mouse, but nice and easy to have. Add to this a thin glove checking for certain movement patterns when the user is not typing and voice to set certain things - all at once.

I am sad to see what happened with GTK. It seems gtk2 was the last good GTK version. Then it went downhill from there.

It is excellent when I can do common tasks in an application without taking my hands off the keyboard. Especially utility apps like a calculator or password manager that I usually just need for a few seconds.

Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.

That one of the reasons which makes noscript/basic HTML a good thing (there are other additional reasons, one of the main is interop with small web engines, aka not "whatwg cartel").

Slap a 1D or simple 2D document (simple table), give some love to those ids/names, should do wonders.

No. GUIs exist across a spectrum of form factors and use cases, many of which would be terrible with a keyboard.

My issue is that taking a strictly GUI driven approach makes you build an application (in the browser presumably) that will require more permissions than you would typically want in the terminal so TUIs win out by being in proximity to those tools (cat, ls, rm, etc) for development use cases

Relatedly, I think that GUI frameworks should make it easier to make your app fully keyboard driven. But my experience with making GUIs is that it seems harder than necessary to make an efficient keyboard-driven interface.

And it should also be easy to make the keyboard controls customizable.

Funny that they mention Gnome. Whenever I happen to use a Gnome application, opening and saving files via keyboard is a major PITA. One can navigate via tabs, but some controls are skipped and those that are selectable do not show this clearly on-screen.

There used to be a tiny macos app that allowed you to navigate the websites typing letters to follow links instead of needlessly roam your mouse around.

Sadly, macos keyboard navigation is dwindling in interactions like the screen sharing pop up when you plug in a monitor

While I agree that almost all GUIs should support keyboard control as a first class citizen, there are exceptions where that doesn't make sense like an image editor.

I'm a keyboard based UI lover, but I wonder if the supportive crowd is, and will ever, be too small.

Even crude AS400 days keyboard UIs were beyond nice. But then if people want to try and replicate emacs keymaps or vi command composition, better for the dozens of us. ^^

once again, I get to cite the IBM AS/400 CallPath system demonstrated here https://youtu.be/5pY6Xxptp9A?t=2083 which almost brought a tear to at least one viewer's eye

Pretty cool video. I would love to know more about the internal design of the as400 platform and how people thought and designed user interfaces. I can't shake the feeling that these interfaces are so lean they're satisfying. Also, I feel that a lot of interfaces today are wasting resources.

watch the whole video from the beginning! :-)

oh i will, i let the second half run, but i'll make sure to see the first part too

Shortcat.app fills some of this gap.

I still haven't found generic solutions to selecting and copy-pasting text using the keyboard only though, when the text is not in a textbox/area.

I had used a vim-like plugin in firefox that let you do that somewhat, but nothing OS level.

Something like this?

https://www.homerow.app/

I quite literally cannot remember anything I've ever read as simple and correct, on the topic of UX/UI as this.

I tend to deride UX/UI as almost a joke because it nearly never understands that fashion and science are different things.

This one gets it.

This is also why i like the blackberry still. iPhone uses too much of cognitive overhead. At least the iPad is a good mix and i mostly depends on my keyboard/mouse connected iPad to use my apps if I’m not virtualising them.

I use Vimium [0] for this very reason -- highly recommend it! Although admittedly this only solves for a fully keyboard-driven _browser_ experience.

[0] https://vimium.github.io

GUIs used to be fully keyboard driven. At least old windows. You could do everything, and those things that were broken (no tab order etc) were accessible by numeric keypad's steered mouse (accessibility settings)

I've thought how i dislike both keyboard and mouse navigation from an ergonomics standpoint. Fine motor control for hours. I'd low-key want a neuralink beacuse speech is too awkward. Maybe mixed with eye monitoring.

https://vimium.github.io/

Hacker browser: allows to navigate browsers without ever needing to use the mouse.

I highly recommend it, it's such a productivity booster

It's interesting because now we're in the era where click-supported TUIs are gaining market share. Will we now see keyboard-driven TUIs fall out of support now because click-support is easier?

I hate nothing more than when a random mistype on a website or app causing shit i don’t understand to happen without reasonable ways to undo it or discover it. I don’t really care if the app can be controlled with a keyboard i want the ui to be discverable and usefull.

This can happen if the applications exposes single keys as shortcuts. If they are "hidden" behind the different modifiers (i.e. Ctrl, Cmd, Alt), then mis-clicks should not be possible or should be more tolerated.

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

Adding keyboard support gets very annoying after a while. I recently posted a new version a package I made that makes it really simple to add keyboard shortcuts to javascript apps: keyboardist.io

They used to be. Now everything’s a website or a website inside a chrome engine pretending to not be a website and is completely hostile to UI conventions like keyboard navigation.

And tablets should have a "direct touch only, all options present mode" (no long-presses, no drags, no drags from edge, no swipes." It would really improve accessibility.

fully keyboard-driven is a high bar, I'd settle for prioritizing the most common actions for keyboard shortcuts.

I would love a return to function keys. You get 12, make 'em count.

Funny, I don’t want to use the keyboards at all, everything should be accessible to the mouse pointer.

Tiling WMs are cool and all but I’d rather use something like AwesomeWM.

Command palettes are great in this regard. They make commands accessible and discoverable entirely from the keyboard. I'm happy to see them becoming more popular.

yes totally agree. I build macOS apps and found out that not every apps support this. One of the reason people buy my file search app https://www.fileminutes.com/ is, it is fully keyboard driven. I'm trying the same with my new AI chat app https://www.vinaa.ai/

Spin up a Windows 3.11 and later instance to try this out.

3.x really

This is something Windows and Mac OS got right in the 1990s. I remember reading specifically about it in terms of digital accessibility too at the time.

For Firefox and surely for Chrome and Safari aswell, there are vim extensions. I have one, it’s beautiful and wouldn’t want to miss it.

A game changer for me was the link hints extension on firefox and chrome: instantly enabled a lot of websites to be keyboard-driven.

Learning this the hard way as I add gamepad support for my touch-based game. All UI elements need to be interlinked, spatially!

This article does not make a good argument on why it should be fully keyboard driven other than the author likes it.

I agree, but it's not that easy.

All UI's should be tab-able, but that's still a miserable experience for keyboard users. A keyboard-centric UI must provide instantly discoverable shortcuts. Possible methods:

- Put all elements on a grid so that they can be navigable with the keyboard. This is a significant restriction for the designer.

- Put keyboard shortcuts next to every button. It's not enough to put them in tooltips (*cough* Raycast). Common in games, but wastes space.

- Add a Command Palette. This is the easiest, but it requires mirroring every action, and is suboptimal when you have the same action for each item in a set.

When designing for technical users: all of the above please. But for average users it's less clear. I think there's still room for innovation, both on the software architecture and the UI side.

I agree completely and that’s exactly what I did for my site:

https://vimgolf.ai

Jump navigation is a nice way to solve this. Something like FlashJump for Mac. Tab navigation too for close proximity jumping.

Yeah I would rather just have a single interface(the terminal) for all of the tools that I use that are keyboard driven by default. There isn't anything I need from a GUI that the terminal doesn't give me.

I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs. I think GUIs are for the most part tailored towards non-power users unless its something like video editing or 3d modeling that is aimed more towards professionals

>I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs.

Sounds like a window manager problem

No, I use i3 but terminal is still better because of how the applications size up

It used to annoy me that on Windows I could press ENTER to close a message box, but on Mac I had to reach for the mouse.

Hm, you should generally be able to hit Return to close a message box on Mac. Or, more specifically, to activate the default action in a dialog (the button whose background is the tint color of the application). Spacebar activates the button that has the focus ring around it, which may or not be the default button, but you can use Tab to move the focus around.

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

This was classic Mac era.

A lot of comments on VIM here. Vim is a terrible example and a pretty bad design overall, objectively. Legends of great productivity with vim is highly legendary, i.e. fiction. Classic Notepad/Word and similar Guis that have been widely adopted in Linux windowing systems are clearly superior and that's why they're so widely and silently adopted. Not a lot of fanfare for hierarchical GUI menus with keyboard shortcuts.

Your making a subjective statement not an objective one about VIM.

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 style of flamebait is at least as old as Vim itself.

I agree, it's bad if like your mouse isn't working and you need to use a app that only works with a mouse

I'm glad the fad of TUIs are dying, I don't get the hype of them.

We just need better, efficient and faster GUIs to put these TUIs to an end.

Take a look at gpgui and glaze leading on this. There should be no reason to use TUIs anymore.

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

https://gpui.rs/

https://glaze.app/

> We just need better, efficient and faster GUIs to put these TUIs to an end.

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.

> gpui.rs

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.

> We just need better, efficient and faster GUIs to put these TUIs to an end.

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

For people who want to navigate browsers only with the keyboard, I recommend vimium https://vimium.github.io/

It's a plugin that enables many keyboard shortcuts, so that you almost don't need to touch the mouse to navigate.

For me, it's such a productivity booster, especially the ability to navigate links without pointing at them to click

Such a funny coincidence. I opened HN in this new, 100%-rust browser[1] I'm working on to actually test some keyboard fixes I did last night.

Every action was keyboard first and only got mouse access later. Browsing by keyboard is not the browser's specific goal, but it was a feature from day 1!

[1] https://github.com/tayler/hww

Exactly, as the author very well points out it isn't for lack of support, rather laziness.

TUIs should be fully mouse-driven

At one time accelerator keys were considered mandatory for a fully realized interface.

The days are not far that all keyboard short cut pass through AI prompt gateway

There is much more to it.

For me personally it goes I like TUI/CMD for things I use as a daily driver, I know what I want to accomplish I know exactly what movements to do and clicking GUI items is just too slow.

Then there are GUI things that I don't use that often I need some kind of map, I don't to "read the fucking manual" every 3 months when I use it and I barely remember, but if I see it in GUI my memory will kick in. It also works for most new things better than TUI/CMD because for a new tool I don't want to invest my focus, I just want to find out how to be done with my things or just learn what it is, reading manual is not fastest way, fastest way is clicking around.

Nowadays we have 3rd mode namely "chat interface" I can just chat with whatever bot is integrated in the app or just chat with the bot to use the application for me. Command line utilities work like charm in that mode I can accomplish a lot by asking vague stuff to a bot that will make stuff for me in a ways I don't even have to know how or what.

But I do believe final form of interface is not "chat interface" alone. I do believe what Karpathy already outlined, that there will be specific interfaces for systems that will use GUI elements to make it clear for the user what is going on and will be faster to clear the information to the user instead of having user to read back text.

This guy is gonna love OMARCHY

Isn't this the perfect use case for LLM driven code refactoring? Hey AI - Here is an app with poorly implemented keyboard shortcuts etc.. Make it adhere to this well defined standard. I think these simple fixes are where LLMs are going to really shine.

This is an interesting ACID test, because at its root hotkeys as they are usually called, are a graph structure.

And LLMs struggle a lot with kind of complexity - as we all do at a certain level, if we don't visualize it i.e. using paper and pencil to paint a picture. Then it is the smoothest thing ever.

But again, then you test it - nice loop for a LLM.

I had no success so far using LLM to sketch my database schema for graphs. I do it by hand and recommend it. Later changes can be nasty and ugly. Changes will occur, but even dry runs make Claude, ChatGPT etc. go rookie level in what they do.

Processing a table and creating a graph structure out of it - no way. And so before a LLM could work on it, it needs lots of preparation. Or we create a new benchmark category.

Sequential work is easy for LLMs now, but Graphs are domains, were they massively struggle.

Nice idea.

So it's the opposite of smartphone, where keyboards are UI driven

Honestly, they should be keyboard first. Yes, let all the mouse stuff work as normal, but choose keys so that the fastest way to navigate the app is with the keyboard whenever possible.

Yes, for efficiently of course but at the very least for accessibility.

>But I want to oppose a recurring argument in favor of TUIs that in my opinion does not have a solid foundation. To paraphrase various commenters: TUIs should be preferred because they are keyboard-driven.

Yes. One problem with this argument in particular is that every TUI reinvents the wheel and designs its own schema.

To reinforce author's point, classic GUI frameworks and their guidelines actually provide hotkey schemas for common actions by default, and hot paths for quick interface traversal. They're universal and work by default, so in a lot of cases you don't even need to think about it, only extend it with your own actions. Absolutely nothing prevents you from doing the same in a TUI framework, but at this point the supposed simplicity and flexibility is lost.

New GUIs have other innovations, see for example Microsoft Ribbon that adopted link navigation from Vimperator to make classic toolbars discoverable, compact, accessible from the keyboard, and customizable - all at the same time! Unthinkable for any other UI paradigm.

It's incredible that after the Electron devastation era this unification and keyboard accessibility feels like some kind of lost art, and the perceived lack of keyboard driven GUIs is used a strawman to criticize GUI as a principle. Status quo of "most apps do X" is not the principle. It's also not true, essentially all good GUI apps are keyboard driven, and surely most professional/heavy user ones.

Design good interfaces, not bad ones, regardless of the paradigm. This is harder than it seems, and TUI is not a automatic substitute for your lack of this skill. If you think it is you will design a bad app, in the same way pixel art looks hideous when used to compensate for game designer's laziness. In fact, a lot of recent TUI apps I see are pure terminal cargo cult and are simply worse by being TUIs.

I miss Windows 98/XP and its fully keyboard driven UIs

That title reads like a spoof of hackernews culture

to a man with an LLM everything looks like a nail

Why, are we speed running the de-evolution of UI?

Because not everyone has a mouse or is able to use a mouse. Accessibility matters.

Not everyone has a (non-screen) keyboard either, you know.

Right, so we should have both options.

Such a crazy take, It does not have to mean removing anything that users already like should they prefer click driven interface, only the option for both keyboard and mouse.

Modern Computer keyboard is one of the best and most brilliant piece of ui ever invented.

Far beyond mouse, stylus wich are themselves infinitely superior to touchscreen.

Someone explain this to Apple

Why though?

The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...

In the latest app my company is working on, we deliberately wanted to support usage over SSH.

We basically designed the app as a TUI, but implemented mouse events so you can also drive it like a GUI.

When we hit the limits of the terminal (couldn’t register the app as a DWM window and throw up separate windowed modals etc) we forked and extended ghosttty.

Now it also supports mouse hover events, DWM popups, and a bunch of other good stuff. We plan to add icons next.

Honestly, it'd be nice if people remembered about keyboard controls more often. I'm not saying it should replace the mouse, but it'd be great if both options were kept around

That's because I am keen of TUIs. Keyboard-only and so necessarily intuitive.

I mean like the original article, I gotta say, Tabs vs Spaces.

I just prefer TUIs, I think if you prefer GUIs you should very much use them and ask for more of them, but if you prefer TUIs please do use those too. I could go into all the reasons I prefer TUIs but this is a HN comment not a manifesto.

Please just use and develop what you prefer.

reasonably sound and soundly reasonable :)

yes please ! even AI would appreciate this !

Accessibility aside, I’ve never understood the keyboard maximalism that some people insist on. Are you really so locked in that you can’t move your hand off the keyboard? Really? Even in this, the era of turn based programming?

ain't no way my mom is learning vim

Read the article. The argument is not "GUIs should require keyboard navigation", it's "everything should be possible with the keyboard".

But it is really hard to remember the shortcuts

You don't really need to remember everything though. Mouse navigation does not need to go away. The keyboard shortcuts should be available if you opt to use them, after which point you will be able to memorize them in short time.

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.

Tool-tips, having an accelerator next to the item in the menu/context menu, accelerator underlines, god forbid documentation … UIs have long had ways of having a simple way and hinting at, documenting, or showing to the user how to accelerate if you want to get quicker.

Can we start with TUIs? At some point Claude code CLI stopped responding to the keys I had been using to scroll the presented plan and it seems only the mouse wheel works

No.

I'm surprised there's only a single mention of tiling window managers here. No talk about i3[0] or hyprland[1]?

I mean these things aren't only highly usable, they're absolutely beautiful[2].

I'll also add that being keyboard driven helps people with disabilities AND makes things easier for AI agents. For exactly the same reason too. It's far easier for programs to hit key codes than try to determine pixel locations on a screen.

As a "power user" I still love TUIs but I also love good GUIs. Why should I be constantly lifting my hand to reach for the mouse? Though one of the big reasons I love living in the terminal is that it is extremely light weight. So many GUIs just eat up your system resources. I don't have that issue with TUIs. FFS, just compare 2 editors: (neo)vim vs Word. And before you say "Word does more" go ahead, add a hundred plugins to vim and then run that test again. vim will still win while also replacing VS Code, Obsidian, and a dozen other applications. The other big reason I love it is portability. Like the author mentions and is discussed in last week's thread, I can jump between machines (even through ssh!) and have no friction. I can have full control of my machine through ssh in a TUI while my mouse jitters while streaming the screen through either ssh or a VNC. I literally have to set different PS1s on my machines because otherwise there's no feedback telling me I'm connecting to something locally vs remotely.

But more importantly, let people do what they want. If you prefer to live in GUIs, do that. If you prefer to live in the terminal, do that. What's great about computers is the choice and flexibility. A big reason I'd support the OP here is that it exclusively adds to that. The ability to program computers and make them do what we, a random user and not an employee at some big tech company, want them to do is what made them take over the world. That even includes smart phones, where no two are alike (you all have different apps). Let's just make good products and let the best ideas flesh out. That's better than just arguing. I don't care if you use emacs, Atom, or program in fucking notepad++. You do you. But as devs we should add flexibility, not put people into boxes.

[0] https://i3wm.org/

[1] https://hypr.land/

[2] https://github.com/caelestia-dots/shell

Well said. Now I just need a universal way to maintain consistency of my F-keys across all applications, including various browsers.

TUI? sure.

GUI? not really possible for tools like blender, solidworks etc.

Keyboard alone is not going to make sense for lots of tasks in something like Blender, but Blender is one of the most keyboard driven 3D apps for tasks where it makes sense. It's operations and modalness feel almost like vim. Built in and widely used plugins like node wrangler even bring that to the graph stuff.

TUIs are an abomination and most GUIs should just be web.

CLIs should be preferred when available. Learning them pays you back when it's time to write a script or pipe massive amounts of data.

> most GUIs should just be web.

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.

yeah--the reason is the bloat and overhead electron brings.

nobody cares about the web layer

You're ignoring all of the other things I said.

Keyboard shortcuts, navigation, and more are inconsistent in web apps. Will they work at all? Will they use different keys? No one knows. Will they respect my OS theming? What about my font choices or font sizes? Almost certainly not.

> and most GUIs should just be web.

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.

Doing GUI on web is obnoxious for people who want to stay offline for things that clearly don't benefit from a network connection (and where a network connection can really only introduce dark patterns). TFA is all about how GUIs should do the things that TUIs just do natively. If you don't like the aesthetic, it's just an aesthetic after all. If you want to use the mouse, you typically can in TUIs.

CLI pipelines are obviously not a real solution to, for example, arbitrary text editing, especially if you don't know what you want to change until you see the text.

Reply on news.ycombinator.com