RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
78% Positive
Analyzed from 2801 words in the discussion.
Trending Topics
#keyboard#should#guis#shortcuts#mouse#tuis#gui#driven#more#web

Discussion (71 Comments)Read Original on HackerNews
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.)
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.
God forbid I should ever be forced to Blender with only buttons.
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.
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.
It’s in the accessibility settings.
https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
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".
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.
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.
Same thing I hear from everyone.
"You can't compromise on UX" - UX experts.
"You can't compromise on security" - Security experts.
"You can't compromise on Accessibility" - a11y experts.
We gotta make trade-offs, and I gotta get my thing shipped (for me I learn toward security for my service)
You could compromise on not-shipping-before-it's-ready.
Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...
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.
[1]: https://github.com/philc/vimium/
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.
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.
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.
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.
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.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
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
Love it.
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.
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.
This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.
We just need better, efficient and faster GUIs to put these TUIs to an end.
Take a look at gpgui and glaze leading on this. There should be no reason to use TUIs anymore.
It is time to move on from using this arcane technology from the 60s-70s.
https://gpui.rs/
https://glaze.app/
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.
I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps
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.
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.
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.
nobody cares about the web layer
Keyboard shortcuts, navigation, and more are inconsistent in web apps. Will they work at all? Will they use different keys? No one knows. Will they respect my OS theming? What about my font choices or font sizes? Almost certainly not.
Yikes, no! One of the reasons old timers like me say that using a computer has sucked a lot in the last ~20 years is the use of a browser as an interface to everything.
If you want to make an app that needs a browser to use, then please drastically improve the browser's interface. I mean, this is a no brainer. TUIs are way more superior to doing things via Safari/Firefox/Chrome.