Good Tools Are Invisible

This is why LLMs are shit. They get between you and everything and turn it into a negotiation.

I think that's a pretty reductive stance to take. Keyboard nagivation is more productive _if_ the primary use of the tool is text-based. In a word processor, an IDE, a file manager, or anything else where the primary mode of interaction is reading, typing, and processing the things you've read and typed, keyboard navigation can be demonstrated to be faster and more natural _only if_ the user has taken the time to learn the shortcuts.

For tools that are mainly for non-text visual information, then the keyboard versus mouse debate is much more heavily weighted in favor of the mouse. Even then, there are times when effective keyboard shortcuts are far more useful than menus and icons. Take any CAD or 3d modeling software as an example. 90% of what a user does will be interacting with visually-presented spatial data, but even then knowing the shortcuts for changing tools or modifying a tool's settings will make you much faster and remove the need to constantly navigate nested menus of options.

I think this article might miss the point that tools like vim often have a much higher ceiling than the transparent or conventional alternative. You get good at the puzzle part of it (which goes along with any craft), and you are able to do things faster than your former self could have conceived.

I remember coming up as a programmer and seeing someone who was truly excellent at using their text editor making large sets of changes that would have taken me double or triple the time and having this feeling of, "ohhh that's the payout."

Keybooard and Mouse. Everytime. I have the same question.

How much do you type in a day that moving the hand to the mouse is a productivity loss? I spend a lot of time staring (thinking, planning) than typing. So, moving my hand to the mouse and back barely has any impact.

I think of "invisibility" as a way of removing unnecessary friction and the author doesn't quite drive home that point effectively.

Good invisibility is like well designed roads. Smooth, clear markings, adequately wide or narrow for the desired speed, easy and obvious signs. Unbothersome and pleasant. Drivers simply drive, rather than get bothered by, "gotta avoid the pothole. Here's comes the bumpy part. That blindspot, I gotta slow down for way too much. Unseen pedestrians pop out here."

This is where invisibility in interstate highway regulations are obvious.

When I see TUI vs GUI comparisons, it distills to friction for a given context/workflow.

I worked in a restaurant with a micros system. It was a very easy to use GUI that was touch screen button driven. A 1 person order could easily be entered in 6-7 button pushes in 2-3 seconds to a seasoned operator: drink > coke > dish > steak > medium > a1 > submit

The beauty with micros was that it reduced the typical navigate > select > add > back-to-navigate workflow into 1-2 button presses with a receipt-like tally providing immediate state feedback.

In this scenario, telling a user to get into a terminal console and type "cd Foo; ./add ketchup" would violate the invisibility principle. It has nothing to do with TUI or GUI.

To me, good tools get out of the way, in the given context. Micros did that.

CLI users are in a CLI flow, thus introducing a mouse to a keyboard workflow violates the invisibility workflow. But for a GUI user to hit up the terminal violates their flow.

Ultimately, all workflows are in search of a faster/less-toilsome feedback loop to the desired goal and tools are in service to the loop. Well designed tools with rabid followings understand through usage where to add friction, and where to cut toil and I'd argue this is where CLIs shine with decades of refinement of the same tool chain.

GUIs are a, it depends on how composable or self contained the given problem for a GUI interface is.

But yes, tools should be invisible. How they become invisible depends.