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?
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.
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!
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
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
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.
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.
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.
> 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.
> 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.
>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.
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.)
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.
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.
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.
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 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.
> 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".
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.
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...
> 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.
>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)? 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.
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.
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.
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.
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 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
>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 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 like 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.
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.
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 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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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?
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.
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
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!
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
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
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.
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/...
"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.
> 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.
>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.
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.
Which, if you made say a regular Win32 application, was guaranteed. These newfangled frameworks dropped the ball, if anything.
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.
> 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
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.
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.
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 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.
> 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.
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...
> 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.
>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)? 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.
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.
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 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.
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.
There is, whether or not developers follow it is a different story.
https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...
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.
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).
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.
> 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)
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.
> 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.
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.
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.
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.
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.
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.
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.
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 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'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.
>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 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 like 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.
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.
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 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.
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.
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
Why though?
The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...
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.
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.
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.
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.
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.
Spin up a Windows 3.11 and later instance to try this out.
But it is really hard to remember the shortcuts
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.
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.
yes please ! even AI would appreciate this !
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.
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.
What's specifically is the limitation?
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".
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/
> 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
> 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.
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.