Comment by bensyverson | Hacker News Reader

Comment by bensyverson | Hacker News Reader

The effect of the interface becoming "invisible" is actually a function of time spent in the interface. I think what the author is reacting to is discretionary friction; designers or product folks adding features or complexity. The thing is, that friction may be necessary in order to achieve a certain task (think about resolving a merge conflict). And given enough time in the interface, even those "disruptive" steps fade into the background.

To give a concrete example, the console of a 737 is incredibly dense with controls. The airplane itself has many different modes, and there are many moments of intentional friction.

However, if you interview a pilot with 10+ years in a 737, they will tell you the interface has become invisible.

The same goes for the supposedly "bad" Bloomberg terminal. You'll find the same thing in Healthcare, where an interface cluttered with buttons is exactly the right solution for someone who spends 8+ hours/day in a MR scanning software and wants instant access to all the controls.

As programmers, I think we're too quick to generalize our own experience and preferences and try to apply them to others.

Source: I spent 10 years designing consumer and professional software at IDEO

> The effect of the interface becoming "invisible" is actually a function of time spent in the interface.

emacs starts with "extensible", so wouldn't extending the tool be part of the interface?

Purchased tools rarely align with this - they provide functionality over customization. especially in the apple world.

It really depends on the tool… CRMs and EHRs are often designed to be customizable. But end-users typically don't want to spend a lot of time configuring and customizing the interface itself. All the choices quickly become overwhelming.

A "customizable" tool for any task sufficiently complicated to be someone else's profession inevitably results in a tiny micro-economy of configuration engineers who specialize in customizing the tool to be just so.

But the crazy thing is this is still a better solution in the majority of cases than not offering extensibility at all. It turns out buying one piece of enterprise software for $250,000 and hiring one specialist in it for $150,000 per year has historically been a better deal than dumping millions into building it yourself. The gains in efficiency for the fifty $400,000 per year doctors, and 500 $100,000/ye nurses, etc who use it are still worth it.

> … discretionary friction; designers or product folks adding features or complexity.

This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.

>> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.

> The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.

With Vim, Emacs, Git,... there's a core concept that all those extras get backs to. The issue with normal editor is that their concept of a text file is an array of lines of characters. Some goes further with providing some parsing to further isolate things like strings or symbols.

With Vim, there's the buffer (aka the content), the window (where user view the content), the cursor (which is the point of origin of many actions) and various commands that moves the cursor according to what's in the buffer. Like with the hand, you can draw, write, make dough, play the piano,..., you use the same hand, you don't have to replace it to do any other actions, you only taught yourself how to do it.

Same with git. It has a core concept that encapsulate everything to do with versioning text files, you just have to compose them to do what you want.

This kind of conceptual simplicity, even though the interfacing may be rough, is good because you are solving classes of problems instead of solving them one at time. For a particular problem, you only need to switch configurations, not to learn a new tool.

The issue is when you tackle a bunch of features not related to each other, or simplify the model so much that it's a toy instead of a tool.

> a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.

I don't think this was actually established. The author may have a point about the UX of multiple cursors in Sublime, but comparing that to Vim macros is missing the point of the macro system — i.e. that you can create something that persists between editing sessions, and encapsulate a sequence of steps even of fundamentally different kinds. (For example, do multiple cursors allow you to implement a new command to transpose elements of a comma-separated list?) More importantly, though, this is not addressing the general principle about "extra features".

I haven't known other Vim users to speak of such "games".

Yeah I think this is all coming from someone who never got good at vim.

Multi-cursors can be nice, but a sufficiently powerful implementation of that looks like helix or kakoune, and those are at least as complex as vim, if not more.

When you're good at vim, it is invisible. Once you're good at writing macros, you can do stuff which is impossible with Sublime-style multi cursors.

I assume those are situations where the author would have "just written a quick script," but vim macros are an interactive scripting language specifically designed to tersely express text transformations. Your script is never going to be quicker than that.

I'm not saying this as a vim partisan or anything. You could easily argue that vim over-optimizes and saves little time in the grand scheme—that's a fair critique. But it's strange to insist that complex tools are complex only for the sake of complexity. It's a weirdly conspiracist mindset.

> but vim macros are an interactive scripting language specifically designed to tersely express text transformations

Yes, I think this is important here. Although it's still hard for me to imagine a level of mastery where one deliberately "writes" macros (what, directly in the vimrc?) as opposed to recording them. Perhaps it's within my grasp to optimize them later, but.

All that said, there are quite a few things I don't like about Vim even though the overall editing model clicks with me, and ideas I've had for something I'd like better. Although I guess I really should check out alternatives before running my mouth about that…

> a level of mastery where one deliberately "writes" macros (what, directly in the vimrc?)

Oh it's so simple you'll kick yourself. If you save the macro to the q register, just paste from the q register and it'll print out the corresponding inputs. Copy the inputs into the w register and now you have that macro saved in a second place.

Some people probably do save macros in their vimrc this way, but I use it to correct typos I made when recording the macro. BIG help.

> but I use it to correct typos I made when recording the macro.

Oh you mean like, now that you have the keystrokes inserted into the current document temporarily, edit and move back to a register?

Exactly. Modifier sequences and escape presses show up as special characters and can be inserted with `C-v Esc` or whathaveyou. It works seamlessly.

The 737 example is actually quite fitting. Sure, a long time pilot will perceive the interface as invisible.

But if you contrast it with the complexity of the same functions on other aircraft, you start to see how complicated it really is. The F-22 for example handles a lot of faults (like engine fires) automatically.

Reply on news.ycombinator.com