10 ms·

GUIs should be fully keyboard-driven

• sublinear 1mo ago
  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.
  • Arainach 1mo ago
    > 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.
    • sejje 1mo ago
      yeah--the reason is the bloat and overhead electron brings. nobody cares about the web layer
      • Arainach 1mo ago
        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.
  • BeetleB 1mo ago
    > 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.
  • zahlman 1mo ago
    Doing GUI on web is obnoxious for people who want to stay offline for things that clearly don't benefit from a network connection (and where a network connection can really only introduce dark patterns). TFA is all about how GUIs should do the things that TUIs just do natively. If you don't like the aesthetic, it's just an aesthetic after all. If you want to use the mouse, you typically can in TUIs. CLI pipelines are obviously not a real solution to, for example, arbitrary text editing, especially if you don't know what you want to change until you see the text.
  • deleted 1mo ago
    [deleted]
• olivewong 1mo ago
  ain't no way my mom is learning vim
  • Arainach 1mo ago
    Read the article. The argument is not "GUIs should require keyboard navigation", it's "everything should be possible with the keyboard".
    • deleted 1mo ago
      [deleted]
• dcrazy 1mo ago
  Why, are we speed running the de-evolution of UI?
  • Arainach 1mo ago
    Because not everyone has a mouse or is able to use a mouse. Accessibility matters.
    • Joker_vD 1mo ago
      Not everyone has a (non-screen) keyboard either, you know.
      • sejje 1mo ago
        Right, so we should have both options.
  • deleted 1mo ago
    [deleted]
  • kodoman 1mo ago
    Such a crazy take, It does not have to mean removing anything that users already like should they prefer click driven interface, only the option for both keyboard and mouse.
• bigstrat2003 1mo ago
  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.
• WillAdams 1mo ago
  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.
• arjie 1mo ago
  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.
  • cosmic_cheese 1mo ago
    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.
    • arjie 1mo ago
      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.
• cosmic_cheese 1mo ago
  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.
  • pathartl 1mo ago
    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
    • cosmic_cheese 1mo ago
      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.
      • dpark 1mo ago
        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/mac https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
• marklar423 1mo ago
  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.
  • OroPla 1mo ago
    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.
    • emacdona 1mo ago
      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.
• danielvaughn 1mo ago
  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 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.
  • ckardaris 1mo ago
    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.
• walrus01 1mo ago
  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.
  • kps 1mo ago
    Or page up/down.
    • g3f32r 1mo ago
      I'd posit that less than a half a percentage of users have used the page up/down keys in the last year.
• ModernMech 1mo ago
  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.
• hombre_fatal 1mo ago
  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.
  • halfcat 1mo ago
    > 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.
    • zahlman 1mo ago
      > This is why we have the “how do I exit vim?” meme. How to exit is literally the second thing `vimtutor` teaches you, after hjkl cursor movement.
• onion2k 1mo ago
  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.
  • phoghed 1mo ago
    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.
• binary132 1mo ago
  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.
  • eviks 1mo ago
    What's specifically is the limitation?
    • binary132 29d ago
      Let’s use the obvious example of a paint program. Clearly continuous 2D pointer input is an essential feature that would be almost impossible to replicate with only a keyboard. To step back a few levels, a node graph editor with many elements will simply always be easier to interact with using a mouse. But editing text and interacting with other applications such as visual debugger are really only a tiny bit removed from that.
      • eviks 28d ago
        > with only a keyboard But that's a limitation you've made up, driven by keyboard doesn't mean "only"! It just means that all actions should be possible with a keyboard. So in your 2D paint ideally there should be a way to draw a line with a keyboard
  • ckardaris 1mo ago
    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.
• colesantiago 1mo ago
  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://gpui.rs/ https://glaze.app/ https://glaze.app/
  • Joker_vD 1mo ago
    > 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.
  • sejje 1mo ago
    > 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.
  • mglvsky 1mo ago
    > 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
• ivanjermakov 1mo ago
  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.
• escot 1mo ago
  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.
• gjvc 1mo ago
  Spin up a Windows 3.11 and later instance to try this out.
  • gjvc 1mo ago
    3.x really
• sciencesama 1mo ago
  yes please ! even AI would appreciate this !
• eviks 1mo ago
  > 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".
  • ckardaris 1mo ago
    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.
    • eviks 1mo ago
      So in none of the cases they do - it shouldn't depend on any tags, that's the whole point of bypassing the app devs! (not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components) What complicated designs do you have in mind?
      • ckardaris 1mo ago
        Maybe not complicated, but unorthodox. A developer who is not familiar with the correct design patterns may, for example, create a dialog using a FrameworkWindow instead of a FrameworkDialog. In that case the framework can not provide any automation, because the developer is not following the guidelines. I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.
        • eviks 1mo ago
          But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation And more pressure from more options doesn't follow, you only need to study if you actually want to diverge
• ungreased0675 1mo ago
  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.
• BeetleB 1mo ago
  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.
• yangshi07 1mo ago
  But it is really hard to remember the shortcuts
  • ckardaris 1mo ago
    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.
  • deathanatos 1mo ago
    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.
• jvreeland 1mo ago
  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.
  • ckardaris 1mo ago
    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.
• projproj 1mo ago
  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 https://github.com/tayler/hww
• thibran 1mo ago
  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.
  • esikich 1mo ago
    There is, whether or not developers follow it is a different story. https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/ https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...
    • thibran 1mo ago
      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 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).
    • leleat 1mo ago
      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.
  • Rygian 1mo ago
    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".
• keriati1 1mo ago
  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.
  • ckardaris 1mo ago
    You can always take it to the next level by using an extension like vimium[1]. [1]: https://github.com/philc/vimium/ https://github.com/philc/vimium/
    • keriati1 1mo ago
      Yes I tried it for a while, it can be nice.
• manlymuppet 1mo ago
  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.)
  • OroPla 1mo ago
    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.
    • manlymuppet 1mo ago
      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.
      • oneeyedpigeon 1mo ago
        Do you have an example of how supporting a keyboard shortcut for every action could be bad for a general audience?
        • Telaneo 1mo ago
          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.
• kixiQu 1mo ago
  I really like this kind of thing but I wish there were more tutorials to help get good with keyboard shortcuts. vimtutor was lifesaving
  • az09mugen 1mo ago
    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.
• jolmg 1mo ago
  > 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.
  • ckardaris 1mo ago
    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.
    • jolmg 1mo ago
      OCR will always ultimately be guesswork. It's up to the font used whether 1/I/l/| or O/0 or -/‒/–/—/― can be differentiated.
    • GreenWatermelon 1mo ago
• yipinwong 1mo ago
  > 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)
  • Rygian 1mo ago
    > We gotta make trade-offs You could compromise on not-shipping-before-it's-ready.
    • deathanatos 1mo ago
      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.
    • bitwize 1mo ago
      Not if you have a deadline.
  • ckardaris 1mo ago
    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.
  • doubleorseven 1mo ago
    this is absolutely not true since December 2025. the amount of "nice to have" items I've been commanding LLM to develop is a dream come true. while being better at QAing i finally get the time to work on the things that got me into programming in the first place, which in the point where human interact with the machine.
• neuroelectron 1mo ago
  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.
  • yndoendo 1mo ago
    Your making a subjective statement not an objective one about VIM. Objective would be making the statement that not all GUIs need to be keyboard-driven manged or have accessibility built-in. Example, GUIs in automation are primary touchscreen driven and have user requirements base on the environment they are in. GUI standards are objective to who the users actually are or will be.
  • zahlman 1mo ago
    This style of flamebait is at least as old as Vim itself.
• mattpk 1mo ago
  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.
  • sakjur 1mo ago
    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.
  • newsoftheday 1mo ago
    I use a cheap notebook Logitech mouse, have for years, it's light weight is easy on my wrist. And I'm a gamer but to the FPS type games as much.
• FranklinMaillot 1mo ago
  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.
• waffletower 1mo ago
  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.
• phegler 1mo ago
  Why though? The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...
• orbital-decay 1mo ago
  >But I want to oppose a recurring argument in favor of TUIs that in my opinion does not have a solid foundation. To paraphrase various commenters: TUIs should be preferred because they are keyboard-driven. Yes. One problem with this argument in particular is that every TUI reinvents the wheel and designs its own schema. To reinforce author's point, classic GUI frameworks and their guidelines actually provide hotkey schemas for common actions by default, and hot paths for quick interface traversal. They're universal and work by default, so in a lot of cases you don't even need to think about it, only extend it with your own actions. Absolutely nothing prevents you from doing the same in a TUI framework, but at this point the supposed simplicity and flexibility is lost. New GUIs have other innovations, see for example Microsoft Ribbon that adopted link navigation from Vimperator to make classic toolbars discoverable, compact, accessible from the keyboard, and customizable - all at the same time! Unthinkable for any other UI paradigm. It's incredible that after the Electron devastation era this unification and keyboard accessibility feels like some kind of lost art, and the perceived lack of keyboard driven GUIs is used a strawman to criticize GUI as a principle. Status quo of "most apps do X" is not the principle. It's also not true, essentially all good GUI apps are keyboard driven, and surely most professional/heavy user ones. Design good interfaces, not bad ones, regardless of the paradigm. This is harder than it seems, and TUI is not a automatic substitute for your lack of this skill. If you think it is you will design a bad app, in the same way pixel art looks hideous when used to compensate for game designer's laziness. In fact, a lot of recent TUI apps I see are pure terminal cargo cult and are simply worse by being TUIs.
• YmiYugy 1mo ago
  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?
  • Fire-Dragon-DoL 1mo ago
    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
    • smoothbraindev 1mo ago
      Even as a fairly confident nvim user, I still use and recommend <https://github.com/folke/which-key.nvim https://github.com/folke/which-key.nvim>
      • DerArzt 1mo ago
        Even as a devoutember of the church of emacs I couldn't live without the emacs version of which-key [1] [1] I was going to link to a repo, but I just learned that which-key is included in Emacs out of the box.
  • regularfry 1mo ago
    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.
• gorjusborg 1mo ago
  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.
  • 111nation 1mo ago
    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...
• tracerbulletx 1mo ago
  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.
• Gecko4072 1mo ago
  I've thought how i dislike both keyboard and mouse navigation from an ergonomics standpoint. Fine motor control for hours. I'd low-key want a neuralink beacuse speech is too awkward. Maybe mixed with eye monitoring.
• thangalin 1mo ago
  Besides JavaFX[1] are there any free, open-source, object-oriented, event-driven, cross-platform, native GUI frameworks that allow for keyboard-accessible UIs? Preferably using a modern language such as Go. When I developed KeenWrite[2] over 12 years ago, I chose JavaFX because it was (a) bundled with Java; and (b) ran on Linux, Mac, and Windows. JavaFX was later ripped out of Java, to my chagrin, forcing a number of technical contortions. [1]: Not free on Windows due to Microsoft's $500 cert signing process. [2]: https://keenwrite.com/ https://keenwrite.com/
• armandososa 1mo ago
  Adding keyboard support gets very annoying after a while. I recently posted a new version a package I made that makes it really simple to add keyboard shortcuts to javascript apps: keyboardist.io
• randusername 1mo ago
  fully keyboard-driven is a high bar, I'd settle for prioritizing the most common actions for keyboard shortcuts. I would love a return to function keys. You get 12, make 'em count.
• nickandbro 1mo ago
  I agree completely and that’s exactly what I did for my site: https://vimgolf.ai https://vimgolf.ai
• x1colegal 1mo ago
  I agree, it's bad if like your mouse isn't working and you need to use a app that only works with a mouse
• tombert 1mo ago
  I am kind of obsessed with keyboard shortcuts, ever since discovering Vim a million years ago. The Vim shortcuts are burned into my brain. I've found that that itch is pretty much entirely solved by Sway (especially since it supports modal navigation, which I have become pretty addicted to), but honestly I actually found Gnome Shell (as of about ~2 years ago) pretty keyboard friendly. Hitting the Windows key [1] brings up the global search and that worked to launch stuff, moving between workspaces worked ok. I know it's popular to hate on Gnome 3 and beyond but honestly I rather liked it. [1] Or whatever the official name for it is; it's a Windows logo on my keyboard.
• nautilus12 1mo ago
  My issue is that taking a strictly GUI driven approach makes you build an application (in the browser presumably) that will require more permissions than you would typically want in the terminal so TUIs win out by being in proximity to those tools (cat, ls, rm, etc) for development use cases
• Rover222 1mo ago
  That title reads like a spoof of hackernews culture
• minimeow 1mo ago
  The author makes an excellent point. There are too many poor Terminal UIs created just for the sake of having a TUI. Often these are not well constructed or lack sufficient thought to be effective/productive. But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. Back in the 80s and 90s Photoshop, Illustrator etc. became the powerhouses they are today because they focused on allowing professionals to be extremely efficient using their array of powerful keyboard shortcuts. In 2026 when software companies are dying of KPItis scoring their product management on creating compelling subscription models to hook customers, attention to actually delivering productivity for keyboard users is often an after thought. Mobile apps don't have keyboard shortcuts and desktop apps seem to increasingly be treated as as the narrow "edge case" with only a few hundred million target users versus the billions available on mobile devices. It's an opportunity for those who get serious about delivering value by leveraging the power of keyboard shortcuts to make their GUIs highly productive and comprehensively usable from the keyboard. For all their faults, Microsoft got this right with VSCode.
  • orbital-decay 1mo ago
    Professional and power user software is always keyboard-oriented when it makes sense, I don't see it being ignored. Microsoft even addressed the criticism that Windows was largely not possible to use from keyboard, and massively improved it starting with Win10. > But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. It's not a trend, it's a fallout of Electron being the default choice. Devs that use non-web UI frameworks are aware of keyboard navigation, or at least don't disrupt the builtin thing. And of course what devs that don't target power users tend to do is irrelevant to GUI vs TUI debate in the context of power users.
    • luke727 1mo ago
      >Microsoft even addressed the criticism that Windows was largely not possible to use from keyboard, and massively improved it starting with Win10. And then shit the bed completely with Windows 11. The (lack of) keyboard navigation is by far my biggest gripe there.
• jnpnj 1mo ago
  I'm a keyboard based UI lover, but I wonder if the supportive crowd is, and will ever, be too small. Even crude AS400 days keyboard UIs were beyond nice. But then if people want to try and replicate emacs keymaps or vi command composition, better for the dozens of us. ^^
  • gjvc 1mo ago
    once again, I get to cite the IBM AS/400 CallPath system demonstrated here https://youtu.be/5pY6Xxptp9A?t=2083 https://youtu.be/5pY6Xxptp9A?t=2083 which almost brought a tear to at least one viewer's eye
    • jnpnj 1mo ago
      Pretty cool video. I would love to know more about the internal design of the as400 platform and how people thought and designed user interfaces. I can't shake the feeling that these interfaces are so lean they're satisfying. Also, I feel that a lot of interfaces today are wasting resources.
      • gjvc 1mo ago
        watch the whole video from the beginning! :-)
        • jnpnj 1mo ago
          oh i will, i let the second half run, but i'll make sure to see the first part too
• SebastianKra 1mo ago
  I agree, but it's not that easy. All UI's should be tab-able, but that's still a miserable experience for keyboard users. A keyboard-centric UI must provide instantly discoverable shortcuts. Possible methods: - Put all elements on a grid so that they can be navigable with the keyboard. This is a significant restriction for the designer. - Put keyboard shortcuts next to every button. It's not enough to put them in tooltips (*cough* Raycast). Common in games, but wastes space. - Add a Command Palette. This is the easiest, but it requires mirroring every action, and is suboptimal when you have the same action for each item in a set. When designing for technical users: all of the above please. But for average users it's less clear. I think there's still room for innovation, both on the software architecture and the UI side.
• utopiah 1mo ago
  Yes, for efficiently of course but at the very least for accessibility.
• arakas4488 1mo ago
  [flagged]
• beej71 1mo ago
  Honestly, they should be keyboard first. Yes, let all the mouse stuff work as normal, but choose keys so that the fastest way to navigate the app is with the keyboard whenever possible.
• rietta 1mo ago
  This is something Windows and Mac OS got right in the 1990s. I remember reading specifically about it in terms of digital accessibility too at the time.
• rootedbox 1mo 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.
  • ckardaris 1mo ago
    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.
  • thefunnyman 1mo ago
    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.
  • deleted 1mo ago
    [deleted]
  • CamperBob2 1mo ago
    What do you mean by "a tab is off?"
    • IshKebab 1mo ago
      Normally you press tab to move between widgets. I guess he means if the tab order hasn't been set up properly.
      • theeyescanner 1mo ago
        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.
• tommyage 1mo ago
  A GUI is indeed superior to a TUI. And keyboard driven should be both. But neither is my preferred UI. I want CLI programs callable from my shell. This way I can quickly repeat an action from the past. I get a history of commands inserted. _And_ I can bind my own keyboard shortcuts if necessary. TUI and GUI do not meet this level of platform independence. If a tool is TUI only I will not adapt it. That's not the case with a GUI, though.
• Decabytes 1mo ago
  I moved to KDE from Gnome for a variety of reasons, but I genuinely miss Gnome and Native GTK apps. They weren't as customizable, but the features you did get work so well. One of my main issues with KDE is that the default keybindings for desktop operations feel like they were designed by people who don't navigate their desktop with a keyboard. Then there are little things like in Gnome the screenshot implicitly copies to the clipboard, while in KDE you have to click the copy button. There are just little points of friction I experience in KDE that make me yearn for Gnome's workflow. I think my ideal world I would have a KDE desktop that used all the Gnome shortcuts, and worked more like Gnome.
  • bombela 1mo ago
    You can set your own shortcuts in KDE. And there is a setting in the screenshot tool to auto copy to the clipboard.
• zomiaen 1mo ago
  I work for a company that for years has had a very old-school, terminal style POS. Lots of key shortcuts. Like, black/white text terminal POS. The folks who learn how to use it well navigate through it faster than the system can process their inputs. The new system has lots of fancy GUI, but is slower, and the folks used to their shortcuts hate it. But it's so much faster to train people to use.
• redlewel 1mo ago
  Yeah I would rather just have a single interface(the terminal) for all of the tools that I use that are keyboard driven by default. There isn't anything I need from a GUI that the terminal doesn't give me. I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs. I think GUIs are for the most part tailored towards non-power users unless its something like video editing or 3d modeling that is aimed more towards professionals
  • orbital-decay 1mo ago
    >I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs. Sounds like a window manager problem
    • redlewel 29d ago
      No, I use i3 but terminal is still better because of how the applications size up
• godelski 1mo ago
  I'm surprised there's only a single mention of tiling window managers here. No talk about i3[0] or hyprland[1]? I mean these things aren't only highly usable, they're absolutely beautiful[2]. I'll also add that being keyboard driven helps people with disabilities AND makes things easier for AI agents. For exactly the same reason too. It's far easier for programs to hit key codes than try to determine pixel locations on a screen. As a "power user" I still love TUIs but I also love good GUIs. Why should I be constantly lifting my hand to reach for the mouse? Though one of the big reasons I love living in the terminal is that it is extremely light weight. So many GUIs just eat up your system resources. I don't have that issue with TUIs. FFS, just compare 2 editors: (neo)vim vs Word. And before you say "Word does more" go ahead, add a hundred plugins to vim and then run that test again. vim will still win while also replacing VS Code, Obsidian, and a dozen other applications. The other big reason I love it is portability. Like the author mentions and is discussed in last week's thread, I can jump between machines (even through ssh!) and have no friction. I can have full control of my machine through ssh in a TUI while my mouse jitters while streaming the screen through either ssh or a VNC. I literally have to set different PS1s on my machines because otherwise there's no feedback telling me I'm connecting to something locally vs remotely. But more importantly, let people do what they want. If you prefer to live in GUIs, do that. If you prefer to live in the terminal, do that. What's great about computers is the choice and flexibility. A big reason I'd support the OP here is that it exclusively adds to that. The ability to program computers and make them do what we, a random user and not an employee at some big tech company, want them to do is what made them take over the world. That even includes smart phones, where no two are alike (you all have different apps). Let's just make good products and let the best ideas flesh out. That's better than just arguing. I don't care if you use emacs, Atom, or program in fucking notepad++. You do you. But as devs we should add flexibility, not put people into boxes. [0] https://i3wm.org/ https://i3wm.org/ [1] https://hypr.land/ https://hypr.land/ [2] https://github.com/caelestia-dots/shell https://github.com/caelestia-dots/shell
• userbinator 1mo ago
  Worth noting that Windows 3.x Paint could be used entirely from the keyboard, as the arrow keys moved the cursor and you could position it with pixel-precision. This is in addition to the fact that the rest of the OS was also entirely usable without a mouse.
• naravara 1mo ago
  Co-sign. This is one of the reasons I’ve always loved NetNewsWire as my RSS reader and few things have been able to displace it. Everything is doable by keyboard, and the keyboard commands are extremely logical and intuitive. You can FLY through your backlog. Excel is the same way. I’ve been an excel power user as well as a Sheets power user and the latter just never managed to enable the level of speedy keyboard navigation Excel could. I can almost work blindfolded in Excel.
• drdec 1mo ago
  Can we start with TUIs? At some point Claude code CLI stopped responding to the keys I had been using to scroll the presented plan and it seems only the mouse wheel works
• andsoitis 1mo ago
  No. GUIs exist across a spectrum of form factors and use cases, many of which would be terrible with a keyboard.
• 6thbit 1mo ago
  Shortcat.app fills some of this gap. I still haven't found generic solutions to selecting and copy-pasting text using the keyboard only though, when the text is not in a textbox/area. I had used a vim-like plugin in firefox that let you do that somewhat, but nothing OS level.
  • estetlinus 1mo ago
    Something like this? https://www.homerow.app/ https://www.homerow.app/
• anotheraccount9 1mo ago
  TUI, GUI.. we need a marriage of both, with configurable levels of integration, which controls to favour TUI or GUI. If it's well done, no need for a mouse, but nice and easy to have. Add to this a thin glove checking for certain movement patterns when the user is not typing and voice to set certain things - all at once.
• advis 1mo ago
  I do agree to some extent, but were GUIs not made specifically to reduce so much reliance on the keyboard? And a few people here did mention that this "fully keyboard-driven" workflow would probably be used by power users primarily. Like anything else in life, I think there's no single answer to this. But for people interested in seeing the difference between mouse-driven vs keyboard-driven flows while web browsing, check out the Vimium extension. It made my sentiments very much favour keyboard-driven workflows
  • whartung 1mo ago
    I would submit that the point of the GUI was necessarily "anti-keyboard" as more "pro-discovery", plus adding gestures that would be difficult on a keyboard. Keyboard interfaces can be, but not necessarily, quite opaque. There's a reason in the old days companies shipped keyboard overlays and function key templates to help users (or went all in with custom keyboards built for the application). In contrast consider something like Wordstar where you pretty much just needed to memorize the three prefix keys, and if you pressed one and waiting, you'd get a menu describing all of the options. Obviously, things like early Smalltalk and, probably, Xerox (having never used any of the early Xerox systems), relied heavily on the mouse, but even it had command accelerators. The CUA standard was that crossover that Windows, and MOTIF, adopted. Much of that work is still with us today, and it worked well both on GUIs and TUIs (witness the old Turbo Pascal/C++ IDEs, and other applications). Those character based applications had to assume there was no mouse, but offer the flexibility of being good citizens should a mouse be present.
• cryptolobster 1mo ago
  Honestly, it'd be nice if people remembered about keyboard controls more often. I'm not saying it should replace the mouse, but it'd be great if both options were kept around
• globular-toast 1mo ago
  This was my point in my comment[0] in that thread. I've used GUI Emacs for years, it's way better than the TUI version and fully keyboard driven. Interestingly, people have seen my GUI Emacs and commented "I didn't know you could get images in a terminal". Then I have to tell them it's not a terminal... If I had to pick the absolute worst things about Teams, which is already one of the worst pieces of software ever made, it would be that it's not keyboard driven at all. [0] https://news.ycombinator.com/item?id=49397145 https://news.ycombinator.com/item?id=49397145
  • frumiousirc 1mo ago
    > Interestingly, people have seen my GUI Emacs and commented "I didn't know you could get images in a terminal". Then I have to tell them it's not a terminal... ...[finishing with], though you *can* also display images in a terminal, including in Emacs running in a terminal.
• KronisLV 1mo ago
  I'll go one step further: anything you can do in a GUI should also be possible to do through a CLI and yes, also with code libraries. If webapps have n-tier architectures, then so should GUI software. (we can lie and say that this is to support AI, in actuality it's to have proper programmatic automation and support for custom interfaces instead of GUI apps being black boxes)
  • aetherspawn 1mo ago
    I agree but how does this work with stateful apps
    • KronisLV 1mo ago
      Pass data around. Run a local HTTP server or any other type of socket, like how Docker does.
• theflyingelvis 1mo ago
  Someone explain this to Apple
• chatgpt_ljhxeqq 1mo ago
  [flagged]
• bijowo1676 1mo ago
  I miss Windows 98/XP and its fully keyboard driven UIs
• eichin 1mo ago
  Back in the early 1990s, mice were fragile enough that Apollo salespeople were trained to be able to do their demos keyboard-only as backup (at least for tradeshows) and that was just generally how interfaces were built. It wasn't an accessibility thing, it was a "we're demoing expensive systems to even more expensive people, it had better work" thing...
• jehnnysmith 1mo ago
  No.
• xbar 1mo ago
  Well said. Now I just need a universal way to maintain consistency of my F-keys across all applications, including various browsers.
• red_admiral 1mo ago
  It used to annoy me that on Windows I could press ENTER to close a message box, but on Mac I had to reach for the mouse.
  • marcellus23 1mo ago
    Hm, you should generally be able to hit Return to close a message box on Mac. Or, more specifically, to activate the default action in a dialog (the button whose background is the tint color of the application). Spacebar activates the button that has the focus ring around it, which may or not be the default button, but you can use Tab to move the focus around. At least, this is the way it's always been on OS X and later. I'm not sure about classic Mac OS.
    • red_admiral 1mo ago
      This was classic Mac era.
• jakzurr 1mo ago
  "Just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard." "It should be possible to move around and interact with every part of your user interface using the keyboard." Yes, finally. It works both ways; when I have hold of the mouse, I don't want to reach for the keyboard, and vice versa. Windows has had this problem for ages, and probably always will. There are some workarounds, "ctrl-esc" (I do this all the time) and "windows-button", but some of them require really jumping through hoops.
• heikkilevanto 1mo ago
  Keyboard driven is fine, when you have a keyboard. But many users are now on phones or tablets, with a severely limited keyboard that takes a big part of the screen. But they have a variety of gestures that regular desktop machines don't have. A good UI should happily handle both of these extremes, and everything in between.
  • alpaca128 1mo ago
    Smartphones and tablets support keyboards, and often even have official ones to buy.
• Arubis 1mo ago
  At this point what keeps me on Firefox is less the browser engine diversity than [tridactyl](https://tridactyl.xyz/ https://tridactyl.xyz/), without which I feel almost helpless in a browser.
  • bovine3dom 1mo ago
    some of the most touching reviews we've had have been from people who for whatever reason can't use mice due to physical disabilities. always happy to hear from people like that if there are things we can improve. (people who just don't like using mice need no such encouragement to share their opinions :) )
• charles_f 1mo ago
  Couldn't agree more, but I think it's majorly a "geek" thing. I'm using i3 on my personal linux and aerospace on my work mac ; vimium in the browser, Neru on the other apps (does something similar to Neru). I recently ended up finding a way to create user-scripts for electron app and since then I'm adding vimium-esque extensions (e.g. in Teams) wherever I go. I wish this was a default, but also that there was more of a standard to navigate UIs. That's why I really like vimium and other similar extensions, it's following the vi logic across websites, rather than having to learn everyone's idea of how to navigate.
• shevy-java 1mo ago
  I am sad to see what happened with GTK. It seems gtk2 was the last good GTK version. Then it went downhill from there.
• larodi 1mo ago
  Given Bloomberg Terminal's success, and all the IBM terminals at warehouses and big stores - this is more than apparent. But only few understand UI to design it right.
  • thetis 1mo ago
    surprising that this is the only comment about the bloomberg terminal, used by all the financial industry wordlwide. Actually i'm surprised than there is no financial website using the same mechanism of the bloomberg terminal. This is crazy simple to learn and use.
    • larodi 1mo ago
      screams market opportunity. but then it took roughly 20 years for search-in-endless-menus to be discovered by majority of software. still not there in its complete form though...
• edwin2 1mo ago
  to a man with an LLM everything looks like a nail
• a-dub 1mo ago
  last time i built a crud app (oh maybe about 24 years ago) i made it a point to do this. i remember watching the payroll people fly through their terminal mode vax vms applications with such speed and dexterity that it would make any unix admin well versed in the art of the command line blush and it made me think "oh yeah, all these 90s point and click guis got it all wrong. if people are required to make heavy use of a system at work, they would prefer a learning curve followed by speed, comfort and dexterity over an easier learning curve that trades dexterity for discoverability." it was a webapp framework, but... all browsing/listing screens included row ids and a focused text box- so that typing the row id and enter would select. all action buttons had an underline to signify which ctrl-shift hotkey triggered them. all edit screens defaulted focus to the first editable textbox and at no time was the mouse actually necessary. finally, load times were optimized to target 75ms. amusingly, the user feedback was "the keyboard control is pretty good but can you please make it faster." what i thought was chrome ended up being critical to the users not being miserable.
• jmount 1mo ago
  And tablets should have a "direct touch only, all options present mode" (no long-presses, no drags, no drags from edge, no swipes." It would really improve accessibility.
• ozim 1mo ago
  There is much more to it. For me personally it goes I like TUI/CMD for things I use as a daily driver, I know what I want to accomplish I know exactly what movements to do and clicking GUI items is just too slow. Then there are GUI things that I don't use that often I need some kind of map, I don't to "read the fucking manual" every 3 months when I use it and I barely remember, but if I see it in GUI my memory will kick in. It also works for most new things better than TUI/CMD because for a new tool I don't want to invest my focus, I just want to find out how to be done with my things or just learn what it is, reading manual is not fastest way, fastest way is clicking around. Nowadays we have 3rd mode namely "chat interface" I can just chat with whatever bot is integrated in the app or just chat with the bot to use the application for me. Command line utilities work like charm in that mode I can accomplish a lot by asking vague stuff to a bot that will make stuff for me in a ways I don't even have to know how or what. But I do believe final form of interface is not "chat interface" alone. I do believe what Karpathy already outlined, that there will be specific interfaces for systems that will use GUI elements to make it clear for the user what is going on and will be faster to clear the information to the user instead of having user to read back text.
• winrid 1mo ago
  One of the pieces of software I sell is motorsports timing software [0], it has a GUI for newbs, but at the bottom of every window is a little bar that shows the list of shortcuts. People pick them up quickly! And it's auto generated from the UI code. It still surprises me how many people just prefer the mouse anyway, though. But the option is there! [0] https://sidewaysdata.com https://sidewaysdata.com
• jonbrauninddott 1mo ago
  For people who want to navigate browsers only with the keyboard, I recommend vimium https://vimium.github.io/ https://vimium.github.io/ It's a plugin that enables many keyboard shortcuts, so that you almost don't need to touch the mouse to navigate. For me, it's such a productivity booster, especially the ability to navigate links without pointing at them to click
• jonbrauninddott 1mo ago
  https://vimium.github.io/ https://vimium.github.io/ Hacker browser: allows to navigate browsers without ever needing to use the mouse. I highly recommend it, it's such a productivity booster
• aetherspawn 1mo ago
  In the latest app my company is working on, we deliberately wanted to support usage over SSH. We basically designed the app as a TUI, but implemented mouse events so you can also drive it like a GUI. When we hit the limits of the terminal (couldn’t register the app as a DWM window and throw up separate windowed modals etc) we forked and extended ghosttty. Now it also supports mouse hover events, DWM popups, and a bunch of other good stuff. We plan to add icons next.
• josht 1mo ago
  I use Vimium [0] for this very reason -- highly recommend it! Although admittedly this only solves for a fully keyboard-driven _browser_ experience. [0] https://vimium.github.io https://vimium.github.io
• iammattmurphy 1mo ago
  I recently had a revelation when I made an extended qwerty midi controller app that permanently shows the states and functions of all keys including when modifiers are held. It occurred to me that this is a wonderful way to design software: you immediately know the keyboard shortcuts because you’re already looking at them. I’m working on taking what I’ve built for the qwerty midi keyboard controller (which is built on hammerspoon) and making it just a generic interface for any kind of app. If the end goal is navigating and controlling the app via keyboard shortcuts, so why not bake that into the design of the GUI itself? My project if you’re curious: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon
• thayne 1mo ago
  Relatedly, I think that GUI frameworks should make it easier to make your app fully keyboard driven. But my experience with making GUIs is that it seems harder than necessary to make an efficient keyboard-driven interface. And it should also be easy to make the keyboard controls customizable.
• sujee 1mo ago
  yes totally agree. I build macOS apps and found out that not every apps support this. One of the reason people buy my file search app https://www.fileminutes.com/ https://www.fileminutes.com/ is, it is fully keyboard driven. I'm trying the same with my new AI chat app https://www.vinaa.ai/ https://www.vinaa.ai/
• k3vinw 1mo ago
  Jump navigation is a nice way to solve this. Something like FlashJump for Mac. Tab navigation too for close proximity jumping.
• jrm4 1mo ago
  I quite literally cannot remember anything I've ever read as simple and correct, on the topic of UX/UI as this. I tend to deride UX/UI as almost a joke because it nearly never understands that fashion and science are different things. This one gets it.
• aristofun 1mo ago
  Modern Computer keyboard is one of the best and most brilliant piece of ui ever invented. Far beyond mouse, stylus wich are themselves infinitely superior to touchscreen.
• belabartok39 1mo ago
  This guy is gonna love OMARCHY
• lunar_rover 1mo ago
  Sadly, even interfaces that do support keyboard navigation tend to implement it poorly. Microsoft Office is probably the gold standard here, almost everything can be navigated using mnemonics, all keypresses are buffered and the user seldom needs more than 5 presses to get anywhere.
• anArbitraryOne 1mo ago
  So it's the opposite of smartphone, where keyboards are UI driven
• Tanoc 1mo ago
  ALT+TAB, TAB, ↓, ↓, ↓, CTRL+HOME. For a lot of people this is a recognizable pattern. Switch window, select element, scroll down, then snap back to the very top. The keyboard commands above should do the same thing no matter if it's your text editor or your web browser. People should know these are going to work regardless of what they're using. Because these aren't key commands going to the program, these are key commands going to the operating system. The program shouldn't be able to arbitrarily choose whether it abides by these. Consistency is important not only for speed, but for human understanding and capability. If every door had a different way of opening it such as drawing a series of lines or tapping a certain rhythm or belching thirty feet away people would be mentally taxed discovering that particular door's interfacing method, and common tools would not be able to help those who couldn't find the interface or use it because of disability or differing ability. It's only doors with extremely specialized designs like blast doors that have an unusual interface and interfacing method, because they're designed to do one very specific thing that lies far outside of common use cases. Your chatroom program, image viewer, or archive unpacker is not a blast door. Put a door handle on it where everyone expects it to be.
• xyzsparetimexyz 1mo ago
  I wish that every app had the StarCraft system where the letter to press a button is indicated. Like: - New *G*ame - *S*ettings - *Q*uit Ideally keys should be centered around an area of the keyboard and not just the first letter.
• dosisking 1mo ago
  TUIs should be fully mouse-driven
• xamuel 1mo ago
  I don't know if it's OSX itself or one of the common GUI engines implementations on OSX, but I notice a lot of apps (including Firefox when you try to save a file which would overwrite another file) will have popup modals with multiple buttons and there's no way to click the non-default button with just keyboard. For example, in Firefox, trying to save a file when a file by that name already exists, you get a "Cancel" or "Replace" prompt and you can "Cancel" by pressing return, but if you want to "Replace", you apparently HAVE to use mouse or trackpad!?!
• stevesajeev 1mo ago
  I think the main reason people prefer TUI are certain assumptions that come with it. Like I assume a TUI runs on vim like shortcuts, allowing me to move with hjkl. It isn't the case everywhere, but it's what I have observed mostly. When a software is created for the terminal, it can expect the users to know these certain shortcuts. But this cannot be assured for GUI.
  • laserbeam 1mo ago
    Most TUIs give you keyboard but mouse is a second class citizen, most GUIs give you mouse but keyboard is a second class citizen. To that extent, I’ll take the mouse only any day. I really want to learn over time the 5-15 shortcuts that speed up my day, not be forced to learn all of them day 0. And I say this as a power user, a casual user will use 2-3 shortcuts per app at most.
    • reamaer 1mo ago
      Nano always shows most important (all?) hotkeys on the screen. (works really well for its usecase)
• sjbzbeiks 1mo ago
  I mean like the original article, I gotta say, Tabs vs Spaces. I just prefer TUIs, I think if you prefer GUIs you should very much use them and ask for more of them, but if you prefer TUIs please do use those too. I could go into all the reasons I prefer TUIs but this is a HN comment not a manifesto. Please just use and develop what you prefer.
• gfalcao 1mo ago
  reasonably sound and soundly reasonable :)
• usern20260720 1mo ago
  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
• chrisXOXO 1mo ago
  For Firefox and surely for Chrome and Safari aswell, there are vim extensions. I have one, it’s beautiful and wouldn’t want to miss it.
• dingdongditchme 1mo ago
  A game changer for me was the link hints extension on firefox and chrome: instantly enabled a lot of websites to be keyboard-driven.
• igkougkousis 1mo ago
  [flagged]
• kodoman 1mo ago
  I have really come to think that most GUI's are misguided, they seek to be easy and intuitive to pick up from the get go hugely at the expense of of speed of the user once they are familiar with the software. Although where possible software should be easy to learn for lots of programs the user can expect to use the program lots those ones would improve productivity of the user by focusing on speed of use for the user not discoverability and intuitive. Again there is plenty of intuitive design that is also fast once the user becomes familiar with the system but the discoverability and intuitive aspect is weighted higher then speed of a knowledgeable user. I do think lots of programs would benefit from being more CLI accessible and allowing users to build scripts that lots of modern propriety programs do not allow you to do, at best they have some script engine running in the program that you can call with more effort then it should.
• Timwi 1mo ago
  It's so weird for me to live through software evolution to the point where this no longer goes without saying. In the Windows 3.1 days, it was nearly impossible to make a program that wasn't fully keyboard-usable. Even if you left out all the hotkeys in the menus and messed up the tab order, it was still possible (even if annoying) to get through it with the keyboard, and adding the hotkeys (as well as actual shortcuts) and setting a sensible tab order was super easy and straightforward. Nowadays more than half of all software is made using non-native GUI toolkits (or sometimes no toolkits at all) that refuse to implement any of the typical keyboard navigation that would previously have come for free. The keyboard makes computers a joy to use for me. Seeing it disappear makes me very sad. Seeing how the vast majority of people don't care that it disappeared makes me feel like an alien from another planet.
  • unfamiliar 1mo ago
    Same. I think part of the problem is that keyboard shortcuts are often not very discoverable. For example on Macos, pop-up dialogs often have keyboard shortcuts for their non-default buttons, but I'm not sure where you're supposed to learn this. Lack of discoverability leads to many people not using them which leads to devs not implementing them.
  • oleggromov 1mo ago
    I wouldn't care to read manual for my microwave, as long as basic functions work. Similarly, people don't seem to bother to use their software to its full potential. Computers have become appliances.
  • wraptile 1mo ago
    My favorite example of keyboard power is qutebrowser¹ which turns any website keyboard navigable as well as all browser functionality too. It's a really fast and comfortable work flow. https://qutebrowser.org/ https://qutebrowser.org/
• harhargange 1mo ago
  This is also why i like the blackberry still. iPhone uses too much of cognitive overhead. At least the iPad is a good mix and i mostly depends on my keyboard/mouse connected iPad to use my apps if I’m not virtualising them.
• tsoukase 1mo ago
  That's because I am keen of TUIs. Keyboard-only and so necessarily intuitive.
• charcircuit 1mo ago
  This article does not make a good argument on why it should be fully keyboard driven other than the author likes it.
• woolion 1mo ago
  My first experience with a GUI was the HP-40G calculators. By their nature, they only have arrows and accept/cancel buttons. It featured very advanced symbolic computation features (CAS that would step you through intermediary results), but the magical thing was how equations, rather than being a series of characters, that you piece up into meaningful chunks through parentheses, where actually displayed like mathematicians would write them. Then, to select and edit a specific part of the equation, you have a natural 'box'; numerator/denominator, etc, then you can drill down into the recusirve structure of the mathematical expression. It also means that regular edits are 'correct' by default: delete a parenthesis and your expression is syntactically invalid, whereas "replace the numerator f(x)^2 by 6a" keep you in the space of syntactically valid expressions. In other words, this is the holy trinity of UI: semantic - accessible - efficient The experience is unparalleled to this day, although writing it down I realize more why it was never really reproduced. For a browser, I would imagine having blocks like: A. meta (browser itself) / B. page (DOM) A1. page controls (bookmark, ...) / A2. Navigation experience (font size, dark mode, ...) One can dream :-)
• userfrie 1mo ago
  [flagged]
• crabbone 1mo ago
  I haven't seen this mentioned, but... let's talk for a moment about testing automation, and what pain it is to test GUI programs that are mouse-first... It is coincidental, but, in reality, it's pretty much a given, that a program that can be controlled through keyboard will be a lot easier to automate (not only for testing) because of the choice. A typical way of doing things in a GUI program is to handle "events". The framework arranges for event delivery. The event has properties s.a. what UI element registered it and the sort of mouse action performed, and the handler code specializes on that combination to take the (hopefully) intended action. When it comes to testing, in order to emulate such events, one would have to calculate the location of the element that "registered" the desired event in order to trigger the desired functionality. This is usually very hard to do because elements change their positions on screen, it can depend on screen resolution, display style of scrollbars and so on. Another problem with the event-driven model is that it's typically asynchronous. The automation code has no good way of telling when the action associated with the even should take place, or, rather, when it should finish taking place, to assess the results. Typically, programs controlled through keyboard expose functions associated with desired functionality (because they need to bind something to the key). The test automation then can call these functions instead of emulating events. The detection of the moment when the action finished execution thus becomes trivial.
• NSUserDefaults 1mo ago
  Learning this the hard way as I add gamepad support for my touch-based game. All UI elements need to be interlinked, spatially!
• sparse-Matrix 1mo ago
  At one time accelerator keys were considered mandatory for a fully realized interface.
• bsramin 1mo ago
  [flagged]
• sam_lowry_ 1mo ago
  Funny that they mention Gnome. Whenever I happen to use a Gnome application, opening and saving files via keyboard is a major PITA. One can navigate via tabs, but some controls are skipped and those that are selectable do not show this clearly on-screen.
• DarmokTanagra 1mo ago
  TUI? sure. GUI? not really possible for tools like blender, solidworks etc.
  • cma 1mo ago
    Keyboard alone is not going to make sense for lots of tasks in something like Blender, but Blender is one of the most keyboard driven 3D apps for tasks where it makes sense. It's operations and modalness feel almost like vim. Built in and widely used plugins like node wrangler even bring that to the graph stuff.
• sylware 1mo ago
  That one of the reasons which makes noscript/basic HTML a good thing (there are other additional reasons, one of the main is interop with small web engines, aka not "whatwg cartel"). Slap a 1D or simple 2D document (simple table), give some love to those ids/names, should do wonders.
• bryanrasmussen 1mo ago
  the fully keyboard driven website is difficult to achieve, in some part because of accessibility tools, first off every OS has their own hotkeys and keyboard shortcuts, generally with some explicit modifier, the reason for modifiers is that it is good to have a key you push in coordination with some other key to force something to happen outside the functionality of whatever thing you are currently interacting with. Second browsers often have their own hotkey combinations. Same things apply. Third screenreaders have their own hotkey combinations that make the screenreader do something. fourth parts of your site probably have their own specific functionality for key presses, like this text box I am writing in right now. fifth people with accessibility issues and just anybody with some technical needs or abilities may have set their own global hotkeys in their particular OS. sixth some keyboards might not have the keys you think of as really clever modifier keys. So, if you really wanted to get around problems of potential hotkey collisions you should provide a default hotkey set that users can edit and override , and that is why I always get accused of over-complicating everything I do.
• p0w3n3d 1mo ago
  GUIs used to be fully keyboard driven. At least old windows. You could do everything, and those things that were broken (no tab order etc) were accessible by numeric keypad's steered mouse (accessibility settings)
• badgersnake 1mo ago
  They used to be. Now everything’s a website or a website inside a chrome engine pretending to not be a website and is completely hostile to UI conventions like keyboard navigation.
• meitham 1mo ago
  I practically live in the terminal but can’t live without a mouse. I’ve been using Vim (now Neovim) exclusively as my sole editor and everything in tmux including my email. I agree with the power of the keyboard but a properly configured mouse is a truly powerful terminal utility.
• herbst 1mo ago
  When I learned Webdesign accessibility was a main factor, always. Today it seems more like the absolute exception, even Ai doesn't care about it by default. In professional work many customers were like "nah, we don't need that, we won't pay for that" I don't get how and why we evolve backwards in these things.
  • _the_inflator 1mo ago
    Hotkey usage means speed. Ironically you hinder people using their capabilities to the fullest. It also works in the other direction. And I agree with you: Vibe Coding literally automagically includes it, and I had the notion, that you must actively advise an LLM to ignore Web Accessibility. I understand that developers in the traditional sense were shunning the topic, but via LLM? I never found it easier. Of course here and there you have to lead the LLM in the right direction as usually.
• johnwatson11218 1mo ago
  Isn't this the perfect use case for LLM driven code refactoring? Hey AI - Here is an app with poorly implemented keyboard shortcuts etc.. Make it adhere to this well defined standard. I think these simple fixes are where LLMs are going to really shine.
  • _the_inflator 1mo ago
    This is an interesting ACID test, because at its root hotkeys as they are usually called, are a graph structure. And LLMs struggle a lot with kind of complexity - as we all do at a certain level, if we don't visualize it i.e. using paper and pencil to paint a picture. Then it is the smoothest thing ever. But again, then you test it - nice loop for a LLM. I had no success so far using LLM to sketch my database schema for graphs. I do it by hand and recommend it. Later changes can be nasty and ugly. Changes will occur, but even dry runs make Claude, ChatGPT etc. go rookie level in what they do. Processing a table and creating a graph structure out of it - no way. And so before a LLM could work on it, it needs lots of preparation. Or we create a new benchmark category. Sequential work is easy for LLMs now, but Graphs are domains, were they massively struggle. Nice idea.
• timnetworks 1mo ago
  And it's not just for websites. Analogy: the doorframe is of a standard width so that a wheelchair can get through. This means manufacturers can make equipment that will fit in your house without calling you first! You never have to worry you bought a new refrigerator that needs to be pulled into a hole in the roof because it won't fit through the door. You never have to worry about delivering food to a grocer because your hand truck and boxes will fit, and there is a ramp instead of oddly shaped stairs. Nobody needs to be in a wheelchair for this.
  • _kb 1mo ago
    Within built environment and industrial design that's termed universal design. The canonical example is ramps on footpaths providing equivalent benefit to people in wheelchairs, parents with strollers, and commuters on bikes, scooters or skateboards. The door width example you provide is another perfect case. There are many aspects of things we design and build where a small focus of accessibility for one group brings benefits to many.
  • bethekidyouwant 1mo ago
    The standard doorway width came before the standard wheelchair width
    • timnetworks 1mo ago
      ty for the correction and my sudden urge to research doorframe design
• pjmlp 1mo ago
  Exactly, as the author very well points out it isn't for lack of support, rather laziness.
• eahm 1mo ago
  Funny, I don’t want to use the keyboards at all, everything should be accessible to the mouse pointer. Tiling WMs are cool and all but I’d rather use something like AwesomeWM.
• OhNoNotAgain_99 1mo ago
  [dead]
• iamgopal 1mo ago
  The days are not far that all keyboard short cut pass through AI prompt gateway
• rirze 1mo ago
  It's interesting because now we're in the era where click-supported TUIs are gaining market share. Will we now see keyboard-driven TUIs fall out of support now because click-support is easier?
• effnorwood 1mo ago
  [dead]
• Multicomp 1mo ago
  One friction point I have out there is that each major OS has differing keyboard shortcuts available, reserved by the OS vendor, reserved by popular global apps registering common keyboard shortcuts, with the net effect being that even for power users, a given app only has 10-20 possible keyboard shortcuts. I would love to create a collaborative repo that establishes broadly common modern day keyboard shortcut mappings for common actions across OSes (copy is Ctrl+C in Windows, Command+C in MacOS, Ctrl+Insert in Linux), as well as a map of keyboard shortcuts to actions/OSes and if said shortcuts are app specific vs system global. I'm given to understand historically that Windows intended the Function keys to help with this somewhat, you had F1-F12 (or F24 for IBM Battleship model M keyboard owners), Windows would do Alt+F1, Alt+F2, Alt+F3, Alt+F4 (the latter of which still closes most apps today), and in a magical perfect world where A) every keyboard actually had function key rows and B) there was a conventional place for common actions across apps that could be used, users could learn more than Ctrl+Z, Ctrl+O, Ctrl++ to zoom in (oops, not always), Shift+Insert to paste, Shift+F11 for context menu.
• cbenz 1mo ago
  Keyboard driven, and a lot more! I love the following patterns for GUIs: - command-driven (e.g. command palette of VSCode) - keyboard shortcuts call commands, are customisable - scriptable: ability to call those commands from the outside, controlling the running app, for example with CLI calling D-Bus (or socket), and not necessarily having macros from inside the GUI - reorganisable: the different GUI elements like panels, tabs, should be moved by the user and remembered (ideally having layout presets) to let the user adapt the GUI to his/her needs. I'm thinking of VSCode, Blender I'm not especially aware about common toolkits like Qt or GTK, whether they provide tools for that. In web front-end dev, I'm using Svelte, and there are awesome UI libraries like shadcn-svelte, however I didn't find anything rather standard implementing these architecture patterns.
• stanleykm 1mo ago
  Accessibility aside, I’ve never understood the keyboard maximalism that some people insist on. Are you really so locked in that you can’t move your hand off the keyboard? Really? Even in this, the era of turn based programming?
• adverbly 1mo ago
  I say this as a vimium user: Don't make me use a keyboard for drawing. Don't make me use a keyboard for video games. Don't make me use a keyboard for 3D modeling. There are probably many more exceptions. Stop pushing for global rules. Accept diversity.
• devguardian2026 1mo ago
  [flagged]
• account42 1mo ago
  While I agree that almost all GUIs should support keyboard control as a first class citizen, there are exceptions where that doesn't make sense like an image editor.