GUIs should be fully keyboard-driven
341–350 of 510 posts
Re: GUIs should be fully keyboard-driven
#342I 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…
In the context of discussing TUI vs GUI (as the article does), the accessibility and keyboard control balance probably swings very strongly to native GUIs; in a TUI you’re at the whim of the TUI framework’s stabs at accessibility support, while on a full fledged native UI you have all the bells and whistles of focus management and text to speech and voice control and high contrast and magnification and motion adjustm…
Re: GUIs should be fully keyboard-driven
#343Earlier quoted context omitted.
I believe AI can be huge here. Things like ADA are often mechanical (adding the correct attributes to the most important page elements). It is the perfect work to audit and fix using agents. It is a business opportunity as well. I worked at a company that paid for an audit before LLMs. There is tremendous cost savings possible here. I also wonder if WebMCP will be the ultimate final incarnation of this.
> It is a business opportunity as well. I worked at a company that paid for an audit before LLMs. There is tremendous cost savings possible here. Do you know one of the most underemployed groups are disabled people? And do you know where a number of disabled people get employment? Disability audits (unsurprisingly they're extremely good at this). Congratulations on recommending further marginalising an extremely marg…
Re: GUIs should be fully keyboard-driven
#344I think the main reason people prefer TUI are certain assumptions that come with it. Like I assume a TUI runs on vim like shortcuts, allowing me to move with hjkl. It isn't the case everywhere, but it's what I have observed mostly. When a software is created for the terminal, it can expect the users to know these certain shortcuts. But this cannot be assured for GUI.
Re: GUIs should be fully keyboard-driven
#345Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it. HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corn…
Keyboard shortcuts should be an _optional_ way to interact for accessibility and power users! They should never be required!
This is what TUIs get wrong, they make it the required way to navigate and often don’t even let you use the mouse.
Re: GUIs should be fully keyboard-driven
#346Sadly, macos keyboard navigation is dwindling in interactions like the screen sharing pop up when you plug in a monitor
Re: GUIs should be fully keyboard-driven
#347I 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…
Re: GUIs should be fully keyboard-driven
#348Earlier quoted context omitted.
Where this falls apart is commercial software. The issue is we use off-the-shelf frameworks and tools for commercial software. And then we don't train developers on how to write high-volume software. Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years. And still, the software is obtuse point-and-click garbage. Meanwhile commercial software fro…
I think you vaaastly overestimate how excel is used by most users if anything, excel exceeds in being MOUSE-driven - it's intuitive in what you press and what you drag and that's kinda my problem with the TFA - author is not representative of typical user. Mouse interaction is the king
She loved Pages, being able to put images anywhere without stuff moving around behind her back.
She hated Numbers, since there were no cut/copy/paste/undo buttons on the toolbar. This is someone who has been using Excel at work for decades at this point. Definitely had a sudden insight as to how differently many users work.
Re: GUIs should be fully keyboard-driven
#349I 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…
Re: GUIs should be fully keyboard-driven
#350Earlier quoted context omitted.
In some cases they do. 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 publi…
So in none of the cases they do - it shouldn't depend on any tags, that's the whole point of bypassing the app devs! (not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components) What complicated designs do you have in mind?
I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.