Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

481–490 of 507 posts

Re: GUIs should be fully keyboard-driven

#481

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 the…

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 b…

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

Re: GUIs should be fully keyboard-driven

#482

Earlier quoted context omitted.

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

that's exactly what I'm saying basically everyone uses Excel. And basically everyone is a MOUSE-first user (or, even further along the chain: TOUCHSCREEN-first) keyboard-based menu navigation is not intuitive. it can be "poweruser" oriented, but it's not for most of the userbase

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

Re: GUIs should be fully keyboard-driven

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

Re: GUIs should be fully keyboard-driven

#484
post #177

Earlier quoted context omitted.

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

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

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

Three kinds of disability:

1. Permanent (eg, blind)

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

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

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

Re: GUIs should be fully keyboard-driven

#485
post #426

Earlier quoted context omitted.

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

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

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

Re: GUIs should be fully keyboard-driven

#486
post #428

Earlier quoted context omitted.

But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc. A good common framework helps here. Then, it's up to each user to set their settings properly.

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

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

Re: GUIs should be fully keyboard-driven

#488
post #317
post #138

I'm a keyboard based UI lover, but I wonder if the supportive crowd is, and will ever, be too small. Even crude AS400 days keyboard UIs were beyond nice. But then if people want to try and replicate emacs keymaps or vi command composition, better for the dozens of us. ^^

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

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

Re: GUIs should be fully keyboard-driven

#489
post #403

Earlier quoted context omitted.

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

They sidestep it (partially), but I don't think they solve it. Sure, you'll get your task done if the agent does it for you, but the agent won't show you how to do it without their help. So the next time you have to do the task, you have to ask them again. I also think this is misunderstanding "discoverability" a bit. For me "discoverability" also means you get an understanding of what options are available at all in…

Look how many programs and features exist on Earth.

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

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

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

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

and a CSS stylesheet indicating the bold font.

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

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

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

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

Re: GUIs should be fully keyboard-driven

#490
post #59

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

>A TUI can't prevent the user from copying text by its very nature. Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? It breaks. Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TU…

> Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window?

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

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

> Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TUI is just a poor choice here, it doesn't play well with formatted text like markdown, UI controls, long text, and so on. Terminals are good for CLI where the text is presented as lines, not TUI with spaced layout.

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

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

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

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

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

Post reply on HN