Why, are we speed running the de-evolution of UI?
Such a crazy take, It does not have to mean removing anything that users already like should they prefer click driven interface, only the option for both keyboard and mouse.
GUIs should be fully keyboard-driven
371–380 of 510 posts
Re: GUIs should be fully keyboard-driven
#372Power 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…
In some cases you may need the keyboard accessibility.
- Your mouse/trackpad breaks or isn't recognized?
- The right mouse button for your trackpad isn't working for some reason (e.g. you spilled a drink on it). It should still be possible to use the context menu keyboard button to bring up the context menu.
- Your hands are on the keyboard (typing a document, email, code, etc.) and it slows you down to move to the mouse/trackpad to perform an operation such as copying/pasting text or bringing up the spell checker context menu actions so you want to do those with the keyboard to keep yourself in the flow.
Most often you'll learn keyboard shortcuts/interactions for your workflow then expand out as and when you need them. Sure, knowing all shortcuts and interactions is fairly limited, but the majority of people will know how to cut/copy/paste with the keyboard as those are common operations.
Re: GUIs should be fully keyboard-driven
#373I 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…
> Democracy is about access No, not really. I know what you are trying to say, and I fully agree. We need to stop using "democracy" or "democratizing". Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way. "Democratizing" means giving a mob control of the thing, it does not mean making it accessible to all at all.
> Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way.
You're just parroting an old urban myth.
The terminus technicus for mob rule is ochlocracy [1]; democracy, per se, includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with).
Re: GUIs should be fully keyboard-driven
#374Earlier quoted context omitted.
Basically everyone in a white collar job who is NOT a developer is using Excel. I'm a developer, even I have to use Excel at work.
that's exactly what I'm saying basically everyone uses Excel. And basically everyone is a MOUSE-first user (or, even further along the chain: TOUCHSCREEN-first) keyboard-based menu navigation is not intuitive. it can be "poweruser" oriented, but it's not for most of the userbase
Keyboard shortcuts for those menu items are what most people will learn -- save, print, cut, copy, and paste will be the common ones that a lot of people will know.
I'd be willing to bet that professional typists and people who spend the majority of their day typing (email, word, IDEs/text editors, etc.) are the ones who will know more keyboard shortcuts and navigation, especially for the things they do repeatedly.
Re: GUIs should be fully keyboard-driven
#375Earlier quoted context omitted.
That's because at the end of the day: - accessibility is just usability. all it is is making sure your product is as usable by as many people as possible. - it's a myth that "people with disabilities" are some other that excludes you, and 'accessibility' or assistive technologies only benefits other people . Everyone is only temporarily 'abled'. You need to use prescription glasses to comfortable read a computer scre…
> accessibility is just usability. all it is is making sure your product is as usable by as many people as possible. Not always. There are things that increase usability for fully abled people but decrease it for disabled people. Color-coding is a common one. Another is using smaller font size to make more info visible at once, or advanced touch gestures that can be accidentally triggered by shaky hands. Then there a…
Color coding doesn't decrease usability for disabled people (and I say that as a screen reader user). You just need to ensure that color is not the only way the relevant information is conveyed.
Re: GUIs should be fully keyboard-driven
#376Earlier quoted context omitted.
Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down. This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu…
> Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down. > I'd even say friendlier than MacOS (heresy!!) Honestly, I disagree. If you've used macOS for a length of time, you might be aware of the…
Usually though, the menu bar only appears on key release, not on holding it down, as part of pressing the ALT+something shortcut.
Re: GUIs should be fully keyboard-driven
#377Earlier quoted context omitted.
I had to keep accessibility in mind a lot in my previous job (web development for a university). The thing that I consistently found was that, the more accessible a website was, the better the experience for everyone , not just people with disabilities.
Some of the things we take for granted in UI/UX originated that way, like automatic hamburger menu hide/show (for very large zoom) and "scroll to content/top" buttons for screenreaders, which, if you've ever tried to read a recipe online are pretty critical. Captions on videos are also like that, although there you might share blame to them for enabling the poor sound mastering on things like, legendarily, Tenet, per…
"Scroll to content" doesn't mean what you think it means.
It doesn't scroll to the "useful" part of an article. It doesn't skip past the introduction / filler / two pages of "this is how my grandma used to make it." The only thing it does is getting you past the top navbar and such, and moving focus straight to the beginning of the article.
Re: GUIs should be fully keyboard-driven
#378I 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…
When building web apps, I prompt humans and AI with “the best design is accessible design” and start from there.
It always ends up being faster, clearer, simpler, and better.
Re: GUIs should be fully keyboard-driven
#379I 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…
I have a traditional desktop app/GUI app, where I have a table (treeview) of words with their translations and pronunciation (like a dictionary). There can be thousands of words in there. Also there is a filter/search field, where one can input any string to filter the table while typing, or confirming pressing enter/return. The words in the table can be in any language, if the configuration of the application is adj…
1. Make sure that the tree view control has screen reader support and that it has all the normal keyboard commands (such as right/left arrow for expanding/collapsing a parent node).
2. Make sure that the text box has a label that says “search” or “filter” and not just a magnifying glass icon. You can only get away with an icon if the GUI toolkit allows you to give it an alt text.
3. Make sure that this label has a hotkey (underlined letter) and that it's properly linked to the textbox so that pressing the hotkey actually focuses it.
4. Make sure that the tree view is next after the textbox in the tab order.
5. Make sure that it's obvious how to cancel a search. You've already assigned Enter to performing the search (as opposed to closing the dialog) which means you can't use Escape because that is already required for closing the dialog. I think one way is to let the user empty the textbox and press Enter to clear the search, but you can also have a separate button as long as it has a hotkey and an alt text if it's just an icon. This kind of button is allowed to sit between the textbox and the tree view in the tab order, but make sure it stays that way and you don't add 10 more buttons there so navigating to the tree view becomes arduous.
I think it's ironic that I can give all of this advice just by being a keyboard user. I'm not visually impaired and I don't use a screen reader.
Re: GUIs should be fully keyboard-driven
#380What 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…
We know what it means for a GUI to be keyboard driven now: Edit with Copilot[1] Press the Copilot key on your keyboard[2] and type the thing you want to happen on your keyboard in English without leaving the home row. Forget the keyboard shortcuts, the path through the menus, the button location in the toolbar, the command name in the omnibar, the marketing name of the feature. Forget queueing up keyboard keys in an…
LLMs do solve the discoverability problem which underpins every power user feature ever. It is fantastic to be able to describe what you want without the domain knowledge that was previously a prerequisite to achieving that goal. Hopefully as more systems create declarative ways to interact with them (MCP, clis), power users will be able to profit from this as a side effect as well.