Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

91–100 of 510 posts

Re: GUIs should be fully keyboard-driven

#91

Earlier quoted context omitted.

Well the two--building for power users vs for a general audience--often work against each other. And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.

Do you have an example of how supporting a keyboard shortcut for every action could be bad for a general audience?

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 you can define your own. Even if no shortcuts are set by default and they aren't shown anywhere else in the UI, it will still be possible for a power user to make the best use of the program.

Re: GUIs should be fully keyboard-driven

#92
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…

Oh, finally somebody who gets it! That was incidentally my major disappointment with vim: it is keyboard driven, but the UX wasn't designed to be a perfect keyboard experience (which I expected, given how old it is).

Some examples of what you are asking for can be found in videogames due to controllers

Re: GUIs should be fully keyboard-driven

#93
post #91

Earlier quoted context omitted.

Do you have an example of how supporting a keyboard shortcut for every action could be bad for a general audience?

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

Every application did it for decades after the first Xerox guidelines up until Microsoft and Apple decided to retire the concept of usability some time around 2010.

Re: GUIs should be fully keyboard-driven

#94
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 Every application did it for decades after the first Xerox guidelines up until Microsoft and Apple decided to retire the concept of usability some time around 2010.

something something smartphones

Re: GUIs should be fully keyboard-driven

#95
post #79
post #52

The problem with keyboard navigation is that there seems to be no mature GUI keyboard-first UX concept. "Mouse things" are the way they are, because they fit the mouse-way. We need the same for the keyboard-way. Until then, there seems to be no design concept that can just be copied.

Top of my head: - Tab to move across fields. - Left-to-right, top-to-bottom focus. - Space to toggle togglable stuff. - Alt-Down Arrow to deploy drop-down stuff. - Arrows to move around. - Enter/Esc to accept/discard a modal. Or maybe I misunderstand the things you call "mouse things".

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.

Re: GUIs should be fully keyboard-driven

#96
I love TUIs.

I move much faster when I don't have to take my hands off the keys to nudge the rat.

However, I don't think my preference for TUIs is about my efficiency. The most important reason I love TUIs is that they generally only have a base set of features needed to get the job done. Most GUIs go off the rails, implementing features for use cases few people have. TUIs tend to be small, fast, and focus on a small use case.

So even though I started out claiming I love TUIs, what I really love is small software: CLI > TUI > GUI.

Re: GUIs should be fully keyboard-driven

#97

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 nothing.

Re: GUIs should be fully keyboard-driven

#98
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 discoverability is supposed to work. It means you can fall back to the mouse when it makes sense.

Re: GUIs should be fully keyboard-driven

#99

Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter. 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 fair…

Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible

To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.

Re: GUIs should be fully keyboard-driven

#100
This is a very narrow viewpoint, considering the majority of computing is done on touch screens now. Sometimes keyboard controls are critical, sometimes they're not, sometimes your users don't care, sometimes they do. Sometimes a pointer is a better human interface for something, sometimes a purpose built controller is, sometimes a multi touch sensitive touchpad is. I wouldn't make an FPS that was just keyboard controls and the same is true of some other types of UIs. Just measure it and be creative and empathetic to how people will use your product who aren't like you and consider the physical interactions as a part of your design space and not just the software.
Post reply on HN