Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

511–520 of 528 posts

Re: GUIs should be fully keyboard-driven

#511
post #490

Earlier quoted context omitted.

>A TUI can't prevent the user from copying text by its very nature. Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? It breaks. Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TU…

> Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? Hold Alt while trying to select to make a rectangular/block selection. To avoid a TUI's mouse handling and use the terminal's, hold Shift. So, for example, if you're on tmux with "panes" (internal win…

>Hold Alt while trying to select to make a rectangular/block selection.

I don't see how block selection helps on cut text. In GUI you simply select the partial element and copy it, with either mouse or keyboard. You can also display it (or a tooltip) above the rest while selected, which is what compactified tabular views usually do. Turns out layout engines have a purpose in dense interfaces after all.

>Yeah, the interfaces of coding agents are really poorly made. It's like they only know GUIs but wanted to have it work for a terminal. They really should have been CLIs instead of TUIs. That way you could just use the terminal scrollback buffer.

No, they really are much better off with web or GUI, terminals use unreadable monospace and simply aren't well suited for large amount of rich text, schematics, pictograms, and pictures. They are fundamentally not CLIs as well, they're interactive programs with complex interface layout that is not limited to basic chatbot input+scrollback (let alone text input, it's not just text).

That relates to most TUIs I see, they use TUI because it's fashionable - status monitors, dashboards, file managers, you name it. TUI is suited for very few purposes most of which are pretty basic (e.g. status line-style UIs for CLI), anything more complex such as a file manager and it quickly becomes awkward. FAR Manager had to reinvent everything from scratch (including, ridiculously, picture thumbnails in a custom-built terminal) and it's still worse than Total Commander which just used what the UI framework already provides, for the most part.

>Hmmm... not really? Maybe you're thinking vim vs emacs

I'm really thinking everything vs everything, do you know two TUIs with a common schema that is not a convention? Literally every TUI tool I use (and I use dozens) uses its own layout and keybindings. Maybe 30% vaguely imitate vim's hjkl use instead of arrows in some of their elements, some use ? for help, that's literally about all they have in common. There's no common way for hot path traversal, almost no common paradigms at all. Trivial example, top vs htop vs bottom vs nvtop vs powertop vs god knows what else.

>Something to remember is that GUIs don't have common ground on this except on the use of Tab and Shift-Tab for jumping between different parts of the interface.

Major GUI frameworks such as Qt have hotkey schemas and conventions that are used by default in every program built with them, such as Ctrl-O for opening a file, Ctrl-Z and Ctrl-Y for undo and redo (which they actually provide mechanisms for), menu navigation, or Ctrl-Tab for traversing through focused tabbed elements. Plus guidelines that you can and should follow for consistency. They don't provide everything for every specialized use case but they make mundane actions common for every app predictable and consistent, and of course it's a result of practical use (new apps are being made -> framework devs canonize common behavior).

In any case, none of this is specific to GUI vs TUI as a principle, or keyboard navigation, it's rather about centralized frameworks. Nothing prevents devs from spending the energy on making a good unified TUI framework, or a GUI one that takes keyboard first in the way they want it. It's a matter of fashion more than anything. Nothing replaces good design, certainly not hiding behind the flavor of the day paradigm.

Re: GUIs should be fully keyboard-driven

#512
post #60

Earlier quoted context omitted.

The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user. I quote from Apple https://developer.apple.com/design/human-interface-guideline... : > Always make context menu items available in the main i…

In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users. This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then --…

Not working for your particular preferences isn’t a bug; your preferences are just wrong for the vast majority of users.

The hubris of HN posters never fails to astound me. The most niche of workflows, then wonders why regular users don’t all learn esoteric keybindings and use TUIs.

Re: GUIs should be fully keyboard-driven

#513
post #235

Given Bloomberg Terminal's success, and all the IBM terminals at warehouses and big stores - this is more than apparent. But only few understand UI to design it right.

surprising that this is the only comment about the bloomberg terminal, used by all the financial industry wordlwide. Actually i'm surprised than there is no financial website using the same mechanism of the bloomberg terminal. This is crazy simple to learn and use.

Re: GUIs should be fully keyboard-driven

#514

And it's not just for websites. Analogy: the doorframe is of a standard width so that a wheelchair can get through. This means manufacturers can make equipment that will fit in your house without calling you first! You never have to worry you bought a new refrigerator that needs to be pulled into a hole in the roof because it won't fit through the door. You never have to worry about delivering food to a grocer becaus…

The standard doorway width came before the standard wheelchair width

ty for the correction and my sudden urge to research doorframe design

Re: GUIs should be fully keyboard-driven

#515
post #504

Earlier quoted context omitted.

This is the company that popularized the mouse and GUIs, why are you shocked?

Because it's stupid. Why would accessibility features enabled by default on Windows and Linux be disabled by default in MacOS? There is literally zero advantage to disabling it, and it makes life harder on users. Same thing with tap to click. Once everyone else enabled tap to click Apple disabled it. They just HAVE to be different, even if it's bad for users, and that stubbornness is frustrating.

If you expect your users to mostly work with both mouse and keyboard, it can make sense. Dropping stuff from the tabbing order means that the stuff left is is quicker to tab through. I find it mostly annoying.

Tap to click, though, that’s infuriating. I don’t know how people can stand it. I know people who insist they like it and then I see them accidentally “click” regularly and get annoyed by it.

Re: GUIs should be fully keyboard-driven

#516
post #177

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

Additionally, I found, that simply sticking to web standards, instead of reimplementing everything in JavaScript, goes a long way towards accessibility.

Funny how that works. It's almost as if the web was designed to be a tool for semi-interactive documents instead JVM-esque WODE environment

Re: GUIs should be fully keyboard-driven

#517
post #359

Earlier quoted context omitted.

That's why you don't just use colour for identification. E.g. include a warning icon next to a button/element in addition to using a warning colour.

Nor just shape, so a warning icon + text message.

and, as is being increasingly forgotten, SOUND QUES. Seriously, I get they can be annoying but they make navigating and interacting with things so much easier if you can't see them. Sure, TTS exists but is far more inefficient and objectively less helpful in these kinds of circumstances

Re: GUIs should be fully keyboard-driven

#518
post #428

Earlier quoted context omitted.

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

> Riddle me this - why would you want to disable something that increases usability of an application? Why don't you run your apps/OS with every usability feature enabled? Share your reasons.

I think you are mistaken which side I am on in the "accessibility is just usability" debate. For the record, I am on the side that says not at all.

Re: GUIs should be fully keyboard-driven

#519

Earlier quoted context omitted.

What I wouldn't give to work for a company that actually cares about QA.

Which is not Microsoft. Maybe back in that day but today no. It's more Quality Assumption now :)

Even back in the day they were bad. Things generally worked but were rarely pleasant

Re: GUIs should be fully keyboard-driven

#520
post #428

Earlier quoted context omitted.

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

There are very few accessibility features that increase usability across the board for everyone. If they did, they'd just be called "features". Disabling high-contrast display makes the colors more aesthetically pleasing. Disabling large-print text allows you to view more text on the screen at one time.

My point exactly. Accessibility isn't "just usability" and the great-great-grandparent was wrong to say that.
Post reply on HN