Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

151–160 of 507 posts

Re: GUIs should be fully keyboard-driven

#151
post #60
post #34

Earlier quoted context omitted.

"Some holes"? That's an understatement. There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".

The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user. I quote from Apple https://developer.apple.com/design/human-interface-guideline... : > Always make context menu items available in the main i…

In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users.

This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.

Re: GUIs should be fully keyboard-driven

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

Re: GUIs should be fully keyboard-driven

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

Re: GUIs should be fully keyboard-driven

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

Re: GUIs should be fully keyboard-driven

#155

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

Are there any modern cross-platform GUI frameworks that do this well?

Re: GUIs should be fully keyboard-driven

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

Re: GUIs should be fully keyboard-driven

#157
post #88

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

> A keyboard driven UI shouldn’t have buttons.

You mean because they're basically just in the way, right?

I know it's asking a bit much, but IMO advanced software ideally has

- buttons, pretty colors and icons where they make sense

- keyboard shortcuts for everything

- complete documentation that ships with it (sure "it's online anyway".. so find a way to automate putting what you have on the website into the release in a form that works offline)

- preferences to hide some or all buttons/toolbars, turn off the icons, and change some or all keyboard shortcuts. GUI is cool for that, text files are also cool. In other words, why not have everything? Maybe you could even compile a version that strips out all the stuff that can be turned off, or at least hardcodes some preferences, so the compiler can skip some things that are no longer called etc.

Not a must-have but nice-to-have: tooltips for all things and maybe advanced help, so you don't need the documentation as much, or not at all for simple use cases. But if the docs are complete, I think it's fine to keep the program and development process simpler by not duplicating that in tooltips. Don't go out of your way, unless you want to.

But as I said, that's for "advanced software", by which I mean software you spend a lot of time in. Browser, text editor, email client, file manager, graphics software, and so on. With simpler tools I'm usually just happy they exist.

Re: GUIs should be fully keyboard-driven

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

Re: GUIs should be fully keyboard-driven

#159
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/

[1] https://hypr.land/

[2] https://github.com/caelestia-dots/shell

Re: GUIs should be fully keyboard-driven

#160

Earlier quoted context omitted.

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

It sounds like your complaint might be that it works poorly if you half-ass the localization process and assume that literal translation of strings is most or all of what localization means.

I'm not sure how you read that from my comment.

To be fair to your point though, that's what most localisation of programs are these days.

Post reply on HN