Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

Post reply on HN
Print view View original

111–120 of 507 posts

Re: GUIs should be fully keyboard-driven

#111

Post by orbital-decay »

regularfry wrote: post #98
YmiYugy wrote: 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…

Yes, they should be discoverable. There are platform conventions for this: on Windows you'll see underlined letters; menus show you the shortcuts. Tab is a pretty much universal "move to next field" shortcut and I don't think that's particularly discoverable if you don't already know it. There's nothing wrong with a keyboard driven UI having buttons as long as they advertise their key, though. That's one way discover…

Since you mentioned Windows, Microsoft made Ribbon which uses Vimperator-style navigation to make toolbars and buttons discoverable as long as you know one hotkey (Alt). It can also be hidden until triggered with a hotkey. This is miles ahead of most discoverability tricks in power user interfaces, including fuzzy command search which is not guaranteed to remain stable as new commands are added.

Re: GUIs should be fully keyboard-driven

#112

Post by toast0 »

eldaisfish wrote: post #97
manlymuppet wrote: post #56

Power 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…

you are arguing against a strawman. Most reasonable people want support for both keyboard and mouse-based navigation. For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use? Same with some web forms where hitting enter in a text box does nothing. I expect it to submit a form, but very often, it does nothi…

> For example, why did Edge and possible chrome, remove support for Back via the backspace key?

Because alt+left is a better choice? Really f**ing annoying when some dumb javascript removes focus from a text box you're editing and the page navigates back.

Re: GUIs should be fully keyboard-driven

#113

Post by [deleted] »

YmiYugy wrote: 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…

[deleted]

Re: GUIs should be fully keyboard-driven

#114

Post by xg15 »

YmiYugy wrote: 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…

I think a first step would be a sane tab order, so you can easily navigate to a control using tab or cursor buttons. Second step are keyboard shortcuts.

I don't see why removing the buttons would be desirable. All that would do is to make the GUI unusable with the mouse and also make the discovery of the keyboard shortcuts much harder.

Re: GUIs should be fully keyboard-driven

#115

Post by dan_gggggg »

dietr1ch wrote: post #105
YmiYugy wrote: 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…

To me spacemacs nails the discoverability aspect through helm-Mx-fuzzy-matching and which-key No clutter, but hints come as you stutter on what to press next

[dead]

Re: GUIs should be fully keyboard-driven

#116

Post by thangalin »

Besides JavaFX[1] are there any free, open-source, object-oriented, event-driven, cross-platform, native GUI frameworks that allow for keyboard-accessible UIs? Preferably using a modern language such as Go.

When I developed KeenWrite[2] over 12 years ago, I chose JavaFX because it was (a) bundled with Java; and (b) ran on Linux, Mac, and Windows. JavaFX was later ripped out of Java, to my chagrin, forcing a number of technical contortions.

[1]: Not free on Windows due to Microsoft's $500 cert signing process.

[2]: https://keenwrite.com/

Re: GUIs should be fully keyboard-driven

#117

Post by ethin »

YmiYugy wrote: 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…

My logic for determining if a GUI is keyboard driven is pretty simple: if I can fire up a screen reader and completely drive your UI via the keyboard, then by definition your UI is keyboard-driven. If your app ever requires me to emulate mouse clicks to drive it, then it isn't entirely keyboard-driven and that should probably be fixed. This is even something that can be measured/tested for on platforms like Windows where you can both read the accessibility tree (which in itself is amazingly powerful particularly for testing) but you can also simulate arbitrary input.

Re: GUIs should be fully keyboard-driven

#118

Post by Telaneo »

toast0 wrote: post #109
Telaneo wrote: post #91

Earlier quoted context omitted.

Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming (or at least one of many parts that all together become overwhelming) to new users, while not having them shown at all makes them undiscoverable. I think this is a bad reason. Even MS Office has made this work. But I've seen people act on this type of argument. If nothing else, it should be possible to have a settings menu where y…

> showing the relevant keyboard shortcuts in the UI can be overwhelming Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.

This works poorly if you intend to localise your application. Great if you don't though.

Re: GUIs should be fully keyboard-driven

#120

Post by thibran »

ckardaris wrote: post #107
thibran wrote: post #95

Earlier quoted context omitted.

This does not work great. What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with? Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.

> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with? If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with " G", b…

I love VIM-like TUIs, but the discoverability of of them is absolutely awful.
Post reply on HN