← Back to context

Comment by manlymuppet

13 hours ago

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

(This reads harsher than I intended. Sorry about that. I love Arch Linux people. It's just think it's no less noble to serve the average Joe than to create the perfect tool for power users.)

Where this falls apart is commercial software. The issue is we use off-the-shelf frameworks and tools for commercial software. And then we don't train developers on how to write high-volume software.

Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years. And still, the software is obtuse point-and-click garbage. Meanwhile commercial software from 25 years ago could be navigated at light speed.

That's part of the reason Excel can't be dethroned. Excel is from the old age of software, and that means that users can input and navigate at light speed. All these fancy tools claim to dethrone Excel, but when you actually use them you realize it's a goo goo ga ga Fisher Price level UI. Extreme amounts of whitespace, buttons hidden behind submenus of submenus (which you have to navigate by eye, by the way!), features stripped, UI constantly shuffling around between updates.

Look, that works fine for a website on the open web where you assume your users have never touched a computer before. That does not work for commercial software.

  • I think you vaaastly overestimate how excel is used by most users

    if anything, excel exceeds in being MOUSE-driven - it's intuitive in what you press and what you drag

    and that's kinda my problem with the TFA - author is not representative of typical user. Mouse interaction is the king

    • Screwing with a keyboard combo in Excel... like Shift-Space to highlight a row... is like an IDE deciding to swap the key-bindings for '{' and '['. You'd have entire accounting and marketing departments in rebellion.

      Devs consistently underestimate how many power users of Excel there are, and often don't understand how they operate.

    • I got my wife a new MacBook Air, and figured there's no point in paying for MS Office, iWork is fine for the household stuff she needs it for.

      She loved Pages, being able to put images anywhere without stuff moving around behind her back.

      She hated Numbers, since there were no cut/copy/paste/undo buttons on the toolbar. This is someone who has been using Excel at work for decades at this point. Definitely had a sudden insight as to how differently many users work.

    • Maybe by most users, but not by most users who use it for many hours daily for professional tasks (i.e. not just as a kind of tabular list editor).

  • > UI constantly shuffling around between updates.

    and then 365 came along ... an option to pull stock market data here, a LinkedIn connection there, oh look a wild copilot button appeared.

> But most people aren’t willing to deal with the learning curve of keyboard-driven GUIs.

Keyboard shortcuts should be an _optional_ way to interact for accessibility and power users! They should never be required!

This is what TUIs get wrong, they make it the required way to navigate and often don’t even let you use the mouse.

The argument is that both should be supported, which seems like a valid wish. There's really no reason to either-or this. Just have both work.

  • Which, if you made say a regular Win32 application, was guaranteed. These newfangled frameworks dropped the ball, if anything.

    • Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down.

      This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu item's mnemonic key, and if you ever forget, just look at the menu.

      It was the keyboard-friendliest idea ever, without requiring any sort of terminal. I'd even say friendlier than MacOS (heresy!!) or, yes, VIM (burn the witch!!!)

      2 replies →

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

FWIW, I think it's a blind spot to think of power users as "Arch Linux people" using "developer tooling".

My wife is a UX Design consultant and she had an engagement where a bunch of state government accountants were bemoaning how a redesigned procurement platform took away all their keyboard shortcuts.

It really is not so much about keyboard vs. mouse - power users vs. average Joes. That all is just a discombobulation that distracts from the main issue and the issue is the accessibility of plain text.

Majority of computer professionals (programmers included) come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, in terminal, in PDFs, Word or LaTeX documents. Code by the way is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier. That's why using multiple cursors feature for the first time feels so amazing, even though the practical cases for it are not that common.

And when I say "text", I don't only describe the process of "grabbing some text" and "piping it" into another process, or manipulating it. It's not only about the input, the act of consuming text is equally, if not more important.

We argue that keyboard-driven UIs are more efficient for the input, but hundreds of memorized shortcuts can't really fix the fundamental problem.

Vendors are designed to own you and ownership can take different forms. Slack app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their stupid, quirky wysiwyg editor - owns you. Note-taking app that keeps the data on the cloud ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in, it is behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.

And when you get to that point, you'd feel helpless - all your knowledge and muscle memory can't help you there - not only the app is not favoring power-user experience, it's forcing everyone downgrade to the "average Joe" levels.

Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on our workflows.

Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.

Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like a boxer moving in a ring and casually throwing heavy punches. Long-time Vim and Emacs users "get it", even though they often don't follow through - some things just never become gratifying instincts. Sometimes, even the opposite forms - like redundant muscle memories. Some outright would reject using a new app because it messes with one shortcut they keep accidentally pressing. Sometimes, I wish there was an agreed standard for every UI - to have only the core, commonly used keys pre-set, while making everything else configurable.

Eh I think things like vimium have kinda solved this.

Push a button, every icon is now labeled with a key, type that key, counts as a click, done.

I get that this does NOT solve for say, someone who's blind (i guess you could announce them, not sure), but it is easy enough I've found even lower tech people are fine with it.

As always, a lot of the trick is communicating the interface and using modern standards, not "Well it's ctrl + insert because that's what it is on linux"

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.

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

    Because people were triggering it by accident all the time. Firefox and Safari don't navigate back on backspace either.

    Enter only auto-submits if there's a visible submit button or if there's just one input, and that behavior goes back as far as I can remember.

    • Yeah, that wasn't an attempt to remove keyboard navigation, that was fixing a painful error in keyboard navigation.

    • Yes it was an error because backspace does function as a backspace when a text input field has the focus. Making something that should be muscle memory context-dependent.

      It should have been Ctrl-Backspace or something.

    • I'm surprised the person responsible for <backspace> mapping to Back navigation didn't mandate that <del> would be super awesome for Forward navigation.

      1 reply →

    • right now, i cannot even enable Backspace = go back on Edge. I am forced to use Edge on my work computer and i hate that this feature is gone. Not disabled, just gone.

      About enter to auto submit, i've been running into this problem more often where some web frameworks just ignore the Enter key. There is a submit button, but i cannot trigger it via the enter key.

      2 replies →

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

  • I specifically had to disable that via about:config in Firefox ages ago because I pressed it by accident all the time. Often while I was going through a 30 point form, only to then lose all my progress. To be fair, browsers probably should try to not undo progress like that, so you can just go forward again and get right back where I started, but I've never trusted them to actually do that. I've been burned too many times.

    I can kinda get that one.

  • > 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?

    Because web pages don't preserve element focus well, web was originally meant for documents in the first place, not UIs. If you're trying to erase a character and the focus has been lost, you go back in history instead. It's a real existing problem in poorly designed pages, not a nefarious plot to annoy power users by Google, Microsoft, or Mozilla. It was always janky as hell.

  • Agreed. I'll say the same about accessibility. People really need to test for this more. If your app is not accessible I literally cannot use your app regardless of how useful it might be. This is pretty much why I currently don't use IDEs like Zed: even if I wanted to I can't because it presents no accessibility tree.

No honestly some harshness is warranted, most of the people alive have internet access and a smartphone, this is a more ubiquitous activity than many others we require or expect accommodations from. This site has a lot of good to offer, but sometimes the bubble needs a reality check that their needs and concerns are even more niche than disabilities like Blindness.