Hacker News Reader

"most sailboats have two primary operating modes"

I have a better example for your argument, using sails.

Reach port sail config or reach starboard sail config. Its been 20+ yrs since I've sailed but for the landlubbers that means the sails are hanging off one side of the ship or hanging off the other side of the ship.

Tacking between them is quite hazardous you can get whacked in the head and knocked out and swept overboard or if lines are not handled correctly you could tangle a foot and get tossed overboard etc etc, and thats before operator dangers like improper line handling hurting you or rope burns or who knows how else you can get hurt while mode switching. I suppose if you screw up the guying of the mast you could shatter it while tacking and that just isn't good.

So yeah, to a landlubber, a sailboat that can only deploy sails to starboard is obviously a huge UI win because its modeless. Of course that makes the boat uncontrollable and useless most of the time. This is how sailboats would be designed if landlubber UI professionals designed sailboats.

If you'd like an EE analogy of modes, look at multimeters. You're not going to get away with selling dedicated ammeters or dedicated hardware voltmeters other than specialized apps (clamp on current meters, safety inspection high voltage voltmeters, thats about it). People would rather switch modes than pay twice as much. Of course its worse and many meters do semiconductor forward voltage drop, and continuity, and resistance, and frequency, and capacitance, so next thing you know you have 50 meters on your desk or one multimeter.

Interesting example, though in this case the challenge isn't distinguishing modes but in surviving switching between them.

But you also neatly capture the reason for modes: they provide more capabilities and make a tool more useful. Again the main UI/UX problem isn't that there are modes -- we deal with modes all the time: inadequate vs outside voice, kitchen vs. bathroom activities, behavior with your BFFs vs. your boss or a customer, stadium vs. museum. It's just that these are so totally and fully integrated into our experiences that we don't often think of them as modes. But they are. And the behaviours are learned.

The trick in UI is to make the distinctions so obvious that the user responds like this. Behavior in a given mode is obvious, using the wrong behaviour a glaring error.

> I'd argue that modal behavior isn't a bad thing so long as those modes are very clearly distinguished.

No, that's bad. Your user can always miss the cues, in fact, you have to design considering they will miss.

In vim and other examples you gave, modes aren't a problem less because the distinction is clear and more because being in the wrong mode is not a cause of disaster - but they're still annoying.

The problem with the Airbus VS would exist regardless of indication of the mode it's in, even if it had a giant bright orange screen explaining the value shown is in feet not degrees, because the operator would develop blindness to it. A possible solution is having two VS displays, one for feet and another for degrees, such that the operator can disambiguate at a glance. Another is standardizing to one unit only (which is harder).

One display, clearly labeled with a different color, different font, using degree symbols vs. "ft/s" units - you're saying this is bad, but two displays right next to each other, labeled similarly, isn't?

A display like this...

    [ ] Mode [10.0000 DEG]

...that once toggled turns into this...

    [X] Mode [32.1234 FTS]

... is bad. This is better:

    [10.0 DEG] [32.1234 FTS]

You don't have to think, you can use different decimal places to reinforce cues, you can confirm the values are correct by seeing both values at a glance. Further, there's no mode button to fault, the display can't be in an inconsistent state (accusing one mode and showing the value of another).

Sometimes you can use modes to hide unnecessary information, but for something that answers the question how fast am I falling you really don't want ambiguity or cognitive load.

Barring all other problems, there's no cognitive overhead when it's clearly labeled. You simply read what it says.

There is [1] if the user is used to it showing something and it's showing another. This is the core problem with modes.

What people have to understand is that it doesn't matter how clearly you think you're labeling it, if it breaks the user expectation, it's not clear at all - and an experienced user reads even less, which is the case of a pilot.

Once the pilot develops an habit of, e.g., switching the vertical speed display from feet/s to degrees during final approach (and that may have been what happened), and one day he forgets to switch, or the mode button malfunctions, or double clicks by mistake... there you have a recipe for disaster.

[1] http://en.wikipedia.org/wiki/Inattentional_blindness

Modal behavior always introduce cognitive overhead. It's something that you have to track, and it introduces the possibility of getting it wrong.

To your point, that overhead can be reduced through various UI techniques, but it cannot be eliminated. It's an extra bit of information you need to track. It's an extra check you need to make before reading the situation (and critically, it cannot be done in parallel). Switching modes is an extra step you need to take before performing an action. These are all additional points of failure. In a high-stress, high-stakes situation that's something you want to avoid.

That's not to say that modal UI's are always bad and never should be used. I'm saying that there's a tradeoff, and that tradeoff is not worthwhile in safety-critical applications.

This is really interesting to me. The modal war (say emacs/vi) has always felt weird to me. It's just how you split and dispatch the input a system can receive. How fine grained this distinction is will decide how parallel things can be afterwards. I never searched too much about it because I lacked the terminology, but I wish I knew some studies, theories and reference about ergonomy, information and UI.

The tradeoff is in minimizing the overhead while maximizing the utility of the modal switch. Because that's what modes offer: clusters of functional utility grouped by association.

It's exactly as you say: if anything, the obstacle with vi for new users is that its display fails to be modal.

An interesting consideration though: experienced users know to develop unstacking habits. They wouldn't need the visual indicator even if it were there. Getting out of insert mode is akin to tidying up your ropes after a tack.

I agree about being able to distinguish between Vim modes being easier (I notice when I'm in the wrong mode within one or two keystrokes).

The other very important thing is being able to recover from using a wrong mode easily.

With Vim, it's often a matter of dropping into Normal mode and pressing "u" once or twice. Recovering from closing a private tab will take a bit longer, but you can still live with it. Sailboat and airplane modes are a different story.

Vim has ":set showmode". The you see "-- INSERT --" in the status bar when completing an insert command.

The concept in vi is to make reasonably small edits and finish them with ESC, not to type "i" followed by a five day long brain dump. Just like you would not leave your GUI editor in "Alt-F" with the file menu popped up, or your Emacs in Ctrl-X mode, expecting another character like Ctrl-S to save, don't leave your vi hanging in the middle of an insert command. When you get distracted by a phone call, lunch or washroom break, finish the partial edit.

Most creative editors (from Photoshop to Apple's audio workstation Logic) have huge numbers of modes in terms of the number of cursors available - and it's very disconcerting to use an eraser when you mean to use an intensity-editing tool! Whereas most programs allow you to select a cursor with a keystroke or button click, and that cursor mode stays until you explicitly change it, Logic actually takes a unique approach to this, allowing you to easily assign cursors to modifier keys and right-clicks - that way, the default mode remains the selection cursor, and you explicitly need to "push" a global state every time you want to change the mode. Much more intuitive than sticky modes.

Everyone I've seen has trouble with this in the beginning. I'm not an advanced vim user, would it really be impossible to make it modeless without losing too much power?

You could probably make an equally powerful modeless editor but I don't see how it could be anywhere near vim-like. Maybe if you had a foot pedal to indicate what modes to interpret input sequences in.

What about ditching the caps-lock key and making it a "command" key, that you hold down to type in a command?

Typing ":%s/<complex regex>/<replacement>" while holding caps-lock would get old rather fast, in my opinion.

You'd really only need to hold it for the first character of any command, I guess. Though holding shift+capslock+; to write a capslock-: feels weird.

That's not a mode trigger?

But isn't it interesting that people would find that easy to use, despite being modal? This suggests that the conclusion from the article - to avoid modes - misses the point.

Which was precisely my point :)

imo not any more than hitting ctrl-f in notepad to bring up the search dialog is a mode trigger. Meaning I guess technically it is one but I don't parse it as such.

Note that on Mac and Windows, at least, you can trivially do this remapping. I do it on all my computers.

On a Mac, the keyboard preference pane in system prefs has a "modifier keys" section, which is bizarrely separately configurable for the built-in keyboard vs. a USB keyboard on their laptops. On Linux, the configuration is different for the VT vs. window managers.

It's configurable per-keyboard because not all keyboards have modifiers laid out the same way. Mac keyboards have the bottom row ordered Ctrl, Alt, Cmd; Windows keyboards are ordered as Ctrl, Win, Alt. So, if you're using a Windows USB keyboard on an Apple laptop, you'll often want to swap Cmd (= Win) and Alt on the USB keyboard, but leave them alone on the internal one.

Some built such a foot pedal: https://github.com/alevchuk/vim-clutch

I should have known. Still made my day.

Use of this silly pedal will hamper the user from learning various insert commands like a, A, o and O, and ones that combine motions with insert like C, cw, and so on.

A switch built into the chair seat which generates ESC when the user gets up could be useful, though.

Vim kinda has this. You can spend your entire time in insert mode, and then use <CTRL>-O to run an individual command.

In direct contrast to Vim is Emacs, a modeless editor which uses modifier keys to distinguish inserting text from navigation commands. From my perspective, there doesn't appear to be any other way of choosing keybindings that keep Vim's mnemonic/composable command structure without introducing the slight mental overhead of modes.

Right. I wasn't saying that you can't make a modeless editor, only that vim is a modal one.

I find vim's shorthand notation for commands far easier to deal with than emacs's long alt-meta-command constructs. After a quarter-century, I've pretty much got over the weirdness.

Emacs is not modeless. Firstly, it obviously has numerous modes, which have names like fundamental-mode.

Secondly, its commands are modal. When you begin a command with Meta-X or Ctrl-X, Emacs goes into a different mode: the next character typed will not self-insert.

All command parsing is modal.

Well now you're just nitpicking. Vim's notion of a mode is far more central to its operation than that of Emacs. Major/minor modes work differently than do vim's modes.

>All command parsing is modal.

Are you sure? Consider the way command lines are executed in Plan's Acme editor: you drag the pointing device to select the text you want to execute, then you click on the selection with the middle mouse button. (Alternatively, drag with the middle mouse button, then release that button.) There is an one-line-high area (called the tag) at the start of every editor window for typing in commands when you do not want the typing to mess up the buffer (the in-memory copy of the file being edited) itself.

Excellent point. Emacs's modality is in a different dimension than vim's. And includes vim. :)

I'm a vim user myself and I prefer modes.

Part of the vim cult's belief is the Never-Leave-Home-Row. That is, where you first rest most of your fingers on the asdfjkl; keys. Your hands are 99% of the time if you're not actively typing in the document. If Vim didn't have modes then you'd have to drop this concept. But of course, mistakes in vim don't normally result in dozens of people dying. If something happens that I didn't expect I just glance to the lower-left corner of my terminal to see what mode I'm in.

Raskin had a shot at building an editor along these lines but died too soon. His attempt to remove the pain of vi-style modes was by having users hold keys down to get the modal effects. As soon as you release, you're back in command mode. There's a problem with this for frequent interaction: holding down keys contributes to rsi.

A common path to fluency with vi is to live in command mode. When you type something, immediately press escape out of habit. When you want to type something new, develop a habit of pressing a/i/o with confidence that you're already in cmd mode.

If you find yourself navigating in insert mode, that's a red flag.

About RSI, I believe chorded keybindings can alleviate it. And I've seen some nice vi configs where 'jj' == escape, so you're easily back to command mode. Cute idea.

Wow. That jj idea is a good one. I've been down a similar path to that for other purposes. I changed my leader key to space, and now I can save with <leader>w instead of having to do shift to get :w. But I hadn't thought of making escape more convenient. That's an excellent idea.

I also took a moment to appreciate the full beauty of that trick the first time I saw it. And I'm an Emacs user.

> I'd argue that modal behavior isn't a bad thing so long as those modes are very clearly distinguished.

I suppose that's the problem - making a mode intuitive isn't universal to all people, which is why sometimes we design things and hand it to someone else who is completely baffled by what seemed to be intuitive.