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.

I find the best features, or mechanics in games too, are ones that fall out of greater architectural design. For example, if you've ever played popular hero shooter games like Overwatch, Marvel Rivals, or Paladins, they all have different physics engines; you can tell as you switch between the games. Which one's the "most correct" is up for personal interpretation, but they all try to grant the player affordances, abilities, and special 'tech' all while staying a simple engine for models and hitboxes to interact in.

Then there's coyote time and networking latency. All these little but meaningful details to consider on top of the base action of making a space for 'things to happen'.

When implementing a feature, I feel I'm always thinking back to when I'd get frustrated with the ways Paladins characters clip on walls more than in Overwatch, or the jarring air mobility difference between games like TF2 and the floaty feel found in the others already mentioned so far. I want the feature to feel like it could emerge as a result of the first natural instinct from play. Like when you enter a game world and you obviously know the keyboard and mouse 'control the world', so you start there and begin mapping your intuition of the experience. It starts with the surface visual communications. The HUD, the world itself, the buttons. Maybe your keyboard lights up and shows you what keys to press (chroma sdk for example). Then gets deeper as your experience grows. And the best features, ui, designs, games, etc. engage people who are curious enough to keep digging without enforcing the digging upon the average user.

One important thing falls out of a design philosophy like that. You never exclude a power user, and never baby a new user. It just... is the tool itself.

> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.

I think it’s fine if that’s your hobby, but I agree that in a professional context one should be much more critical of their tools. Even asking “why do I need a tool for this at all?” will reveal shortcomings in processes, data structures or other tools that will reap much greater rewards if effort is put into fixing those instead of optimizing use of a quirky tool.

This is also true from the inverse. Making every tool visible may feel good to some users. They sit in their F16 cockpit, and they like having all those buttons, and knowing what they do.

But this does not scale. You can fit 100 buttons in front of you. You can learn each one and the best situations to use each. But can you fit 1000 buttons in front of you? No. Different humans have different complexity thresholds. Some humans can deal with 10 buttons, and some 250 buttons! But no human can deal with 2000 buttons. There exists a hard limit on tool complexity.

If you want your tool to be useful, then as you increase the number of different humans that sit in your cockpit, you naturally must lower the number of buttons in front of them. The tools must tend towards invisibility.

The best tool has just a single button that has already been pressed for you. The mechanical action is there just for satisfaction.

I rarely use vi{,m} these days but I sometimes still instinctively type motions or :commands into other terminal editors (which naturally blurts them out into the text buffer). When using something like Sublime or VSCode, I'm always hunting through menus, documentation and search engines to do something simple like ":%!sort -u". Kate is a bit unwieldy—far from invisible—but I've found it to be the most frictionless editor on the market by a wide margin.

"I want the defaults to be good and just work, and when I do need to tweak something minor, it should take seconds."

This is Apple's secret, its strange how so many people can't see this or why no ine has comprehensively replicated it.

"The year of the Linux desktop still isn’t upon us (in 2026), and part of the reason why it has taken so long to get to that point is fundamental: a lot of the people who use Linux love fiddling with configuration files to reshape their system"

"part of the reason", yes, besides people's familiarity with Windows, it being pre-installed, Linux's splintered ecosystem in general, games, drivers for hardware, and so much more...

But what I want to contribute: LLMs like codex can be brilliant for custom setups, maybe not for the layman, but for the now lazy but previously-into-tuning your setup person with an itch remaining. For years I've not been wanting to tune my system, I have actual work to do. A few hours spent configuring a tool for small marginal gains is hours I could spend more productively.

Hence, Default Ubuntu with Gnome, good enough, let's do actual work. But I as I get to work more away from my desk setup (hence away from a docking station and external monitors) and more on my Laptop alone, I recently started to long for my i3 setup from years ago...

A few hours of prompting codex and I have sway set up w/ vim like keybindings, all the information I want in a task bar (I couldn't even tell you which, swaybar I think), a good launcher for applications that I like (it's graphically fancier than the simple default launchers for tiling wms), have kitty as terminal with awesome shortcuts for tab navigation, have bash aliases for saving and loading terminal sessions, no shortcuts (sway versus vim vs kitty) are in conflict, all overlap beautifully and make sense (different modifier keys, but same vim motion like fundamentals). I can simply pull the plug on my docking station or re-attach and everything keeps being fine.

So I have a custom setup, custom to me, that especially on a single screen makes me far more productive, setting it up is 10% the time it used to be, making changes in the future will be 10% it used to be, and I still a) leveraged the capabilities for customization and b) it being simple text based configs I can still leverage that going forward and c) have still the insight if needed (looking at the configs).

Codex on Linux in general feels like a super power. Due to the heavy text-based workflow Linux allows for, the Composability of terminal tools etc, I doubt working together with an LLM on setting up a system could work so well on any other system.

The Linux on the desktop one was the biggest “hell, yeah” moment for me. 99% of the desktop preference is familiarity. Since my personal computing has been on a Mac exclusively for the last 24 years and I’ve not used Windows for work more recently than 2018 (and it was sporadically the case in the decade before that), when I do use Windows, it feels like I’m typing in molasses. A Linux desktop feels like I’m typing in molasses with casts on both hands. That the desktop varies depending on the distro and whoever decided on the defaults makes it that much worse.

Meanwhile, I largely use a vanilla setup in MacOS. The only changes in the UI I make beyond the default are installing rectangle and flycut, switching the default keyboard to ABC-Extended and turning off caps lock. Everything else runs with default settings and I’m happier for it, especially when I need to do something on someone else’s machine. Losing those minor customizations doesn’t make the machine unusable or introduce too much friction.

Somebody wanted you to try their favorite tool, so they showed you how easy it is to do weird things in it. That doesn't mean they're using it because they can do puzzles!

If you're a programmer, you enjoy being able to get most of your editing done in your editor without going into the menus and digging for a feature, or searching a store for a plugin that allows you to do that. Of course if you have used your editor for years, and you know all the menus, shortcut keys, and have all the necessary plugins added, then you're fine!

Vim or Emacs allow you to learn some fundamental small tools and mix them to get your job done. Sublime and others allow you to find exact tools for those jobs that others put together. At the end, 10 years later, they're the same.

You're not better. They're not better.