GUIs should be fully keyboard-driven
ckardaris.com686 points by ckardaris 14 hours ago
686 points by ckardaris 14 hours ago
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.
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.
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.
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.
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.
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.
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
that's generally the case with many accessibility features, not just for websites
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.
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.
> 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.
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 :)
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.
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
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.
> 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.
The companies who think AI means they get to reduce headcount will be eaten.
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.
Wait what? We should withhold accessibility features to not marginalize disabled people?
Using AI to close gaps in accessibility is like adding treads to your vehicle because society is too lazy to pave roads.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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 used to do loads of accessibility testing with my sites.
I was fired because I did too much once
> 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.
What do you mean by "a tab is off?"
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.
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 :)
> 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)
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.
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.
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 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.
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?
"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".
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.
> 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).
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.
> 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.
Tons of built in winui3 stuff is still very accessible by the keyboard, metro era though what pretty rough.
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.
> 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.
>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.
It's not even in consideration anymore since the plaque of electron swept over desktop apps.
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.
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
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.)
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
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.
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.
> 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.
> 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.
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.
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.
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
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.
(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.
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?