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

421–430 of 507 posts

Re: GUIs should be fully keyboard-driven

#421

Post by ckardaris »

eviks wrote: post #393
ckardaris wrote: post #388

Earlier quoted context omitted.

> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation. The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut. true This is…

> The developer needs to know what to do. No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed) > What if the developer creates an unorthodox menu…

> ..., so a user can configure F10 to open it if you, app developer, forgot to mark it as main

So, basically what you want you want, as a user, is to bind arbitrary application actions to shortcuts and force click events in spite of what the developer has predicted or tested in their interface. I do not think this is a trivial problem to solve. The application would need to have a way to expose these actions consistently.

> What is he draws a circle instead of using a letter O? What of it?

Well, then you cannot expect the screen reader to work, for example, and you also cannot expect to do anything with this weird "shape". The developer has broken the standards and the user is helpless in this scenario.

Re: GUIs should be fully keyboard-driven

#422

Post by ack_complete »

high_priest wrote: post #288
cpeterso wrote: post #262

Earlier quoted context omitted.

I worked on Microsoft’s Windows QA team long ago. My team used to have “No-mouse Tuesdays”: you were supposed to do all your normal work but only using the keyboard.

I guess that team was dismantled some time ago, with no on carrying the flag anymore. Modern windows is impossible to work on using just keyboard. Some mods & extensions do help. But the native experience is abysmal.

The keyboard support in "Modern" Windows apps is so random. In the new Notepad, the dialog that appears asking if you want to create a new files shows Yes and No buttons, but it doesn't accept Y and N keys, only Esc and Enter. However, the dialog that appears when exiting without saving does accept S and N for Save and Don't Save. These inconsistencies are everywhere in UWP.

Re: GUIs should be fully keyboard-driven

#423

Post by Xirdus »

slfnflctd wrote: post #418
Xirdus wrote: post #342

Earlier quoted context omitted.

There's TUI and there's CLI. TUI has always been poor man's GUI, back in the day it was even literally called GUI. CLI on the other hand has zero similarities with GUI. You write the command and the command executes and that's it. Writing commands is inherently the most accessible form of controlling computers, second only to dedicated single-purpose buttons that don't mesh well with this whole "general purpose compu…

> Writing commands is inherently the most accessible form of controlling computers Not if you don't know enough of the commands and have to research every one you need, and it's for a problem you likely won't encounter again. Oh, and you have to do this without breaking anything. To say this can slow a person down is a dramatic understatement. There is a reason menus were invented very early on in computing history,…

Most accessible, not most convenient/efficient/easy to learn. It's very very hard to beat entering text in terms of how many people on Earth are physically capable of doing it (considering all the available methods, including text to speech).

Re: GUIs should be fully keyboard-driven

#424

Post by loglog »

wolvoleo wrote: post #329
jameshart wrote: post #277

Earlier quoted context omitted.

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…

> The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me. That's not why. It's because TUI apps have to be designed around the strong possibility that a mouse isn't even available. Also in a TUI you never ever have that issue that some text isn't copy/pastable like…

> Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes

May I present OpenCode, which somehow managed to break copy from terminal: https://github.com/anomalyco/opencode/issues/4283

Re: GUIs should be fully keyboard-driven

#425

Post by eviks »

ckardaris wrote: post #421
eviks wrote: post #393

Earlier quoted context omitted.

> The developer needs to know what to do. No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed) > What if the developer creates an unorthodox menu…

> ..., so a user can configure F10 to open it if you, app developer, forgot to mark it as main So, basically what you want you want, as a user, is to bind arbitrary application actions to shortcuts and force click events in spite of what the developer has predicted or tested in their interface. I do not think this is a trivial problem to solve. The application would need to have a way to expose these actions consiste…

These aren't arbitrary actions, but standard menu actions (open menu, close it, activate an item). Also not sure how forcing clicks entered the scene. These are possible via keyboards in many frameworks already today.

> in spite of what the developer has predicted

The dev has "predicted" the menu by creating it in the first place? The framework just made sure that this menu is addressable by the user

> tested in their interface.

That's not a big loss, it's not like we've come to expect any serious testing of UIs anyway

> The developer has broken the standards

Yes, so? I don't understand the point relevant to this discussion. Should standards not exist if they can be broken? Should frameworks not try to make following standards easier? Should frameworks not allow user customizations if devs can find a way to break them?

Re: GUIs should be fully keyboard-driven

#426

Post by Xirdus »

miki123211 wrote: post #375
Xirdus wrote: post #339

Earlier quoted context omitted.

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

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, just pointing out accessibility and usability are different things.

Re: GUIs should be fully keyboard-driven

#427

Post by nonethewiser »

MrVandemar wrote: post #385
nonethewiser wrote: post #312

Earlier quoted context omitted.

Wait what? We should withhold accessibility features to not marginalize disabled people?

No, we should not withhold accessibility features. I wrote nothing to suggest that we should. I wrote that a group of marginalised people would be further marginalised, and deprived of income and meaningful work in a sector where they are, by circumstance, subject matter experts. Anything else is projection.

>No, we should not withhold accessibility features.

So if AI finds and fixes the accessibility deficiencies thats good for disabled people right? Not marginalizing.

Re: GUIs should be fully keyboard-driven

#428

Post by Xirdus »

ckardaris wrote: post #357
Xirdus wrote: post #339

Earlier quoted context omitted.

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

But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc. A good common framework helps here. Then, it's up to each user to set their settings properly.

Riddle me this - why would you want to disable something that increases usability of an application? (Yes, this is a loaded question - I never said these features are bad, just that usability and accessibility are sometimes at odds with each other.)

Re: GUIs should be fully keyboard-driven

#430

Post by sylware »

That one of the reasons which makes noscript/basic HTML a good thing (there are other additional reasons, one of the main is interop with small web engines, aka not "whatwg cartel").

Slap a 1D or simple 2D document (simple table), give some love to those ids/names, should do wonders.

Post reply on HN