Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

471–480 of 513 posts

Re: GUIs should be fully keyboard-driven

#471

Earlier quoted context omitted.

This is true in other fields too. Wheel-chair ramps are used by people with baby strollers. Subtitles work for deaf people, those who can't understand the spoken language, or simple folks in situations where someone is sleeping next to them. Pretty much every accessibility-oriented feature ends up helping out people beyond the original audience.

Baby strollers are not accounted for enough ! One might wonder (wrongly) why everyone should care about the special and expensive needs of a few (or old) people when designing public spaces. But a majority will actually need to use these spaces with a baby stroller. Not a few. Baby strollers are a driving power of our society! Enable them!

And to keep the loop going, stroller-accessible spaces are also walker-accessible spaces and cart-accessible spaces. Worked at a computer store in the early 00s. Our rented retail space had a wheelchair ramp and there were a few elderly regulars who would show up with a desktop PC in the basket of their rolling walkers for repairs. More than once they thanked us for having the ramp because the computer itself was way too heavy for them to carry from the parking lot.

Re: GUIs should be fully keyboard-driven

#472
post #383

It's so weird for me to live through software evolution to the point where this no longer goes without saying. In the Windows 3.1 days, it was nearly impossible to make a program that wasn't fully keyboard-usable. Even if you left out all the hotkeys in the menus and messed up the tab order, it was still possible (even if annoying) to get through it with the keyboard, and adding the hotkeys (as well as actual shortcu…

I wouldn't care to read manual for my microwave, as long as basic functions work. Similarly, people don't seem to bother to use their software to its full potential.

Computers have become appliances.

Re: GUIs should be fully keyboard-driven

#473

Earlier quoted context omitted.

> Windows components however, especially old ones, are incredibly accessible Bing, Bing, Bing! I came here to vent how the new windows 10 and windows 11 interfaces (made by Mac enthusiasts, ughh) have omitted keyboard accessibility for a cleaner look. They also dropped drag and drop support (which I never knew about in windows 7) and I completely missed how useful it could be on Windows 10/11.

For whatever it's worth, the new W10/11 designs aren't in line with traditional Mac design philosophies either. They're more in line with those of iOS and Android with how they tend to bury and omit options entirely and prefer massive whitespace.

Somehow that is a bigger insult: reducing a desktop to act like an iPhone.

Re: GUIs should be fully keyboard-driven

#474

Earlier quoted context omitted.

> Windows components however, especially old ones, are incredibly accessible Bing, Bing, Bing! I came here to vent how the new windows 10 and windows 11 interfaces (made by Mac enthusiasts, ughh) have omitted keyboard accessibility for a cleaner look. They also dropped drag and drop support (which I never knew about in windows 7) and I completely missed how useful it could be on Windows 10/11.

Tons of built in winui3 stuff is still very accessible by the keyboard, metro era though what pretty rough.

Yes the search feature plus using tabs and spaces bring about accessibility. Frequently it misses the underline letter , alt keyboard shortcut.

Re: GUIs should be fully keyboard-driven

#476
post #125
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…

"What does it mean though for a GUI to be keyboard-driven?" For literally decades after they were state of the art, people who used old-school mainframe TUIs would still swear by them. I think the key difference is that they would buffer inputs. You could be on the "Receipt" screen, and know that if you needed to enter the code for some rebate receipt or something, you could hit F6 - F2 - down - down - down - {start…

Making UI interactions bufferable has appeal to me as well.

I had a similar thought but just for the more conventional 'keyboard shortcuts are not discoverable' problem.

Using the status bar or an overlay showing on-screen-keyboard shortcuts, the app could give visual feedback every time you click a button or slide a widget revealing what keyboard shortcut would have triggered that same action.

I click the "GO" button: OSK overlay or status bar shows [GO] (Ctrl+G)

I slide a widget to turn volume up: status bar shows [Volume 22->37] (Alt+V,22)

Re: GUIs should be fully keyboard-driven

#477
post #243

Earlier quoted context omitted.

It's pretty hard for the shortcuts to be consistent and localized. Especially if you also use different keyboard layouts when you're using different languages... Even for keys that aren't mnemonic, do you want undo to be ctrl + z or ctrl + the key closest to left shift?

And for complex languages like CJK, often the key you would press is not even present in the string at all. Example: What should the accelerator be, and how should it be displayed, if your "Exit" option is labeled 終了? I checked VLC and apparently they use: 終了 (Q) Even though "Q" doesn't necessarily make any sense to Japanese people who don't understand any English.

Japanese keyboards also have Latin labels, so it's at least possible to put two and two together there, although it would probably be better to write '終了 (た)' (unless there are local conventions to the contrary).

Re: GUIs should be fully keyboard-driven

#478
One friction point I have out there is that each major OS has differing keyboard shortcuts available, reserved by the OS vendor, reserved by popular global apps registering common keyboard shortcuts, with the net effect being that even for power users, a given app only has 10-20 possible keyboard shortcuts.

I would love to create a collaborative repo that establishes broadly common modern day keyboard shortcut mappings for common actions across OSes (copy is Ctrl+C in Windows, Command+C in MacOS, Ctrl+Insert in Linux), as well as a map of keyboard shortcuts to actions/OSes and if said shortcuts are app specific vs system global.

I'm given to understand historically that Windows intended the Function keys to help with this somewhat, you had F1-F12 (or F24 for IBM Battleship model M keyboard owners), Windows would do Alt+F1, Alt+F2, Alt+F3, Alt+F4 (the latter of which still closes most apps today), and in a magical perfect world where A) every keyboard actually had function key rows and B) there was a conventional place for common actions across apps that could be used, users could learn more than Ctrl+Z, Ctrl+O, Ctrl++ to zoom in (oops, not always), Shift+Insert to paste, Shift+F11 for context menu.

Re: GUIs should be fully keyboard-driven

#479
post #426

Earlier quoted context omitted.

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.

Certain types of colorblindness combined with certain colors makes text much harder to read than black-on-white. If you limit yourself to just universally readable colors, you're heavily limiting the number of different categories you can highlight. There's also the matter of screen real estate - duplicating info isn't helpful for people who can deal with colors just fine. I'm not saying it's a srong thing to do, jus…

Couldn't you distinguish things by their grayscale value? Then you change the hue on top of that for people who can see color.

Re: GUIs should be fully keyboard-driven

#480

Earlier quoted context omitted.

And for complex languages like CJK, often the key you would press is not even present in the string at all. Example: What should the accelerator be, and how should it be displayed, if your "Exit" option is labeled 終了? I checked VLC and apparently they use: 終了 (Q) Even though "Q" doesn't necessarily make any sense to Japanese people who don't understand any English.

Japanese keyboards also have Latin labels, so it's at least possible to put two and two together there, although it would probably be better to write '終了 (た)' (unless there are local conventions to the contrary).

Effectively nobody in Japan uses or even knows the kana keyboard layout though, only QWERTY. My comment was more that they may not know the word "quit" for the Q to be meaningful to them... not that they can't find it on the keyboard.

Similarly as an English speaker I would be quite confused if the shortcut key for exit was a totally different letter like P or something.

Post reply on HN