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".
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.
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.
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.
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.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
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.
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.
Love it.
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.
I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps
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.
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.
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.
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.
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".
That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.