Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

191–200 of 513 posts

Re: GUIs should be fully keyboard-driven

#191
post #176

Shortcat.app fills some of this gap. I still haven't found generic solutions to selecting and copy-pasting text using the keyboard only though, when the text is not in a textbox/area. I had used a vim-like plugin in firefox that let you do that somewhat, but nothing OS level.

Something like this?

https://www.homerow.app/

Re: GUIs should be fully keyboard-driven

#192

Earlier quoted context omitted.

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

Windows did both successfully.

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

Re: GUIs should be fully keyboard-driven

#193
post #95
post #79

Earlier quoted context omitted.

Top of my head: - Tab to move across fields. - Left-to-right, top-to-bottom focus. - Space to toggle togglable stuff. - Alt-Down Arrow to deploy drop-down stuff. - Arrows to move around. - Enter/Esc to accept/discard a modal. Or maybe I misunderstand the things you call "mouse things".

This does not work great. What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with? Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.

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

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

Re: GUIs should be fully keyboard-driven

#194

Earlier quoted context omitted.

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

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

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

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

Re: GUIs should be fully keyboard-driven

#195

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

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

Re: GUIs should be fully keyboard-driven

#196
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

Re: GUIs should be fully keyboard-driven

#197
post #62

Earlier quoted context omitted.

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

Well the two--building for power users vs for a general audience--often work against each other. And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.

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

Re: GUIs should be fully keyboard-driven

#198
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)

Re: GUIs should be fully keyboard-driven

#199

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

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

Re: GUIs should be fully keyboard-driven

#200

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

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

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