I'd argue that modal behavior isn't a bad thing so long as those modes are very clearly distinguished.
It doesn't hurt if they're encountered frequently enough that the user / operator has a clear sense of their distinction.
vi/vim is a modal editor. There are two ways of interacting with it: "insert" mode, and "normal" (command) mode. In one, you're editing your document, in the other you're operating on it. While frustrating for new users, with experience using modes becomes transparent, as they're switched in and out of all the time. Though the visual distinction of modes isn't always clear.
In a non-programming context, most sailboats have two primary operating modes: under sail, and under power. Here, the contexts are evident from a large number of cues in the environment, and how the boat is skippered is evident from these cues.
Other tools have many modes of operation -- the various apps on a smartphone/tablet effective change the mode of the device. Is it a phone? A music player? A messaging tool? A web browser? The "mode" is specified by the application. Usually visual cues of the display indicate which specific mode is operative.
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.
> 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).
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.
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?
> 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.
The two sticks can be pointed in different directions. The plane does not complain about this and averages the inputs. One pilot is pulling back, one is pushing forward, plane crashes. Clearly there are some human factors here, but from what I've read, on Boeing's aircraft pushing one stick causes the other to move, much more intuitive.
The Airbus vs Boeing approach to fly-by-wire is a bit of a religious issue, like type safety or memory management in our world. Many words have been written on both sides.
I think the UI issue in AF447 is much less clear cut. It's more a lack of any indicator that pilots are making opposite inputs, rather than a misleading or confusing display. Airbus did not anticipate that a pilot would stall a plane and fly it directly into the ocean. There was a whole chain of events (including some appalling human factors) that led to the tragedy there.
The avionics teams at both companies have put an incredible amount of thought into how these systems are designed, and how they fail. The differences are instructive, but we should refrain from being quick to judge which is more or less intuitive.
It isn't only Airbus that has deadly UI. Boeing came in for some flak in the design of the 777's non-intuitive autothrottle modes in the Asiana 214 crash report. Pilot confusion with Boeing's autothrottle has also been implicated in other crashes.
Horrific. The stall alarm turned off because the control system didn't trust its inputs and couldn't decide whether it was still in a stall. But the crew interpreted the lack of alarm as the aircraft not being in a stall.
I came across this article that suggests warnings sounded when the two sticks were significantly different to each other, but in the stressful situation the warnings were probably ignored...
"The investigation was unable to determine whether the copilot was aware of the pilot in command’s dual sidestick inputs, even though they resulted in aural ‘DUAL INPUT’ synthetic voice messages…The copilot’s focus on correcting the aircraft’s attitude and trajectory, together with the numerous FWS synthetic voice messages, may have resulted in the copilot not comprehending the significance of the aural ‘DUAL INPUT’ warnings…"
Boeing also uses a classic control column rather than a side-stick, emulating physical controls even though the actual mechanism is largely fly-by-wire.
Not surprisingly, the argument fly by wire versus manual input reminds me of countries that switched from medieval measurements to the modern metric system. This is one of the most difficult changes to make, as America’s multiple, but badly implemented attempts since anno 1700 show. Most people have the tendency to stick to what they know regardless whether it is cumbersome, costly, or hopelessly outdated. Yes, there is reason for this inertia and it is called HABIT. Most of us are happy with what we know irrespective of its drawbacks, because it does after all work, doesn’t it? There is a reason for this innate attitude, “it is much more difficult to unlearn something than learn something new”. Yet it can be done as almost 7 billion people on this planet confirm with metrication. It will probably take a new generation of pilots not wedded to manual flying to appreciate the advantages of fbw. If they would have to change back to manual flying they would have all the arguments many of the present pilots have against fbw, such is habit.
Making mistakes with blender won't kill you but the modes are enough to drive anybody nuts.
Another instance of a very poor choice that led to people being killed in aviation was the one where 'take-off power' was interpreted as 'take power off'.
I can't find a reference to that accident but the essence was that during a go-around instead of full throttle the pilot reduced power causing the aircraft to stall and crash.
>I, for one, fail to realize how can one design any half-complex app (gadget, whatever) to be stateless.
It's fairly obvious, isn't it? A keyboard with no shift key is going to need twice as many keys... but of course you'll also never find yourself accidentally typing with caps lock on. That's the trade off. The UI becomes more complicated.
My car has a "reverse" mode which tries to kill me every once in a while when I hit the gas. I think a separate reverse pedal to the left of the brake would do the trick instead, and be nicely symmetrical.
Notice that the mode indicator is only in the middle, far from the value it's indicating the mode of, but in the cockpit picture in the article ( http://blog.martindoms.com/wp-content/uploads/2011/01/IMG_82... ), you can see that there are actually two mode indicators, one in the same position as the one in the study and one right above the value where it should be. A quick Google of other cockpit images shows that the plane does have two. I wonder if this was an oversight?
In the first two images you link there are dual mode indicators - one in the middle and one just by the value itself - in what looks like a manual they are both shown lit up at the same time which seems more like a problem with the documentation than what is shown in the actual aircraft picture (your third link). I'd venture a guess that in "V/S" mode you'd see that indicated next to the number just as you see "FPA" in the cockpit image.
Someone closer to the browser development at Mozilla etc. could answer this better, but wasn't the original implementation of private/incognito or "safe" modes meant to be subtle?
Before we were all concerned for our privacy these modes were (and prob still are) mostly used for surfing porn. When one is surfing for porn in "private" mode it would benefit to have the UI not scream "I'M DOING PRIVATE STUFF".
the moral of the story is avoid modes whenever possible
We try to avoid using global state (and state in general) in software engineering for this exact same reason. Humans just aren't good at keeping track of more than a few things at once, even if they are the ones who designed the system in the first place.
There's nothing at all wrong with state (i.e. variables) in programs - relatively few programs don't use state. The issue is with UI modes ... reusing the same UI which means two different things according to the mode its in.
Coincidentally, I watched an episode of Channel 4's Black Box series just last night that discusses this accident. The whole series is worth watching but this episode is here:
The question is whether a mode-less interface (that necessarily displays more information at once and is therefore inherently more complex) would have caused more problems than this single instance of a problem caused by the mode mechanism.
UI/UX in general is extraordinarily complex. I think we can all agree on that.
With something as complex and data-driven as air flight, managing a UI will always be complex as a result. As any given control needs to be available at any given moment, you cannot obfuscate too much in the interest of cleanliness.
With all that said, this issue is still not a UI issue, but a training issue and perhaps also an issue with a lack of standards (I'm assuming, not in flight) with jet UI. Even with poor UI, understanding what you're changing and verifying it should boil down to training.
Based on this article, it seems like there's a lack of continuity between aircraft in where controls are, and I wonder if there's ever been any push for standardization. I realize not all craft could be complete mimics, but general controls and indicators should be in the same general area, right?
> Even with poor UI, understanding what you're changing and verifying it should boil down to training.
Absolutely not! Yes, I want the pilots flying my plane to be as well trained as possible, but there also better damn well be a good UI in place to prevent human error, because that's the one thing we can count on, no matter how good training is or how well-intentioned people are.
Everyone who is typing on a keyboard is using a mode. For instance, my "mode" is the HN comment box. Now of course that's clear to me because I can see the text appearing in the correct place.
As for the airplane example, isn't it quite natural to expect the pilots to have gone through extensive training? I understand consumer websites need to be intuitive, but highly specialized things can't really be intuitive.
One big problem with complex things like a cockpit is that the guys who build it are specialists in a different field from the guys who use it. So how are they going to know if the thing is intuitive? I would imagine a pilot mostly touches the same few commands each day, leaving most modes out of use most of the time. By contrast, the developer needs to build the whole thing.
Sure, pilots get trained. A cockpit is going to be complex. But there's a big difference between complex and confusing, and some examples shown are not particularly complex but are confusing.
[+] [-] dredmorbius|11 years ago|reply
It doesn't hurt if they're encountered frequently enough that the user / operator has a clear sense of their distinction.
vi/vim is a modal editor. There are two ways of interacting with it: "insert" mode, and "normal" (command) mode. In one, you're editing your document, in the other you're operating on it. While frustrating for new users, with experience using modes becomes transparent, as they're switched in and out of all the time. Though the visual distinction of modes isn't always clear.
In a non-programming context, most sailboats have two primary operating modes: under sail, and under power. Here, the contexts are evident from a large number of cues in the environment, and how the boat is skippered is evident from these cues.
Other tools have many modes of operation -- the various apps on a smartphone/tablet effective change the mode of the device. Is it a phone? A music player? A messaging tool? A web browser? The "mode" is specified by the application. Usually visual cues of the display indicate which specific mode is operative.
[+] [-] VLM|11 years ago|reply
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.
[+] [-] manoDev|11 years ago|reply
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).
[+] [-] lmkg|11 years ago|reply
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.
[+] [-] cturner|11 years ago|reply
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.
[+] [-] andrey-p|11 years ago|reply
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.
[+] [-] kazinator|11 years ago|reply
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.
[+] [-] btown|11 years ago|reply
[+] [-] MrBuddyCasino|11 years ago|reply
[+] [-] nkozyra|11 years ago|reply
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.
[+] [-] bagels|11 years ago|reply
http://en.wikipedia.org/wiki/Air_France_Flight_447
The two sticks can be pointed in different directions. The plane does not complain about this and averages the inputs. One pilot is pulling back, one is pushing forward, plane crashes. Clearly there are some human factors here, but from what I've read, on Boeing's aircraft pushing one stick causes the other to move, much more intuitive.
[+] [-] idlewords|11 years ago|reply
I think the UI issue in AF447 is much less clear cut. It's more a lack of any indicator that pilots are making opposite inputs, rather than a misleading or confusing display. Airbus did not anticipate that a pilot would stall a plane and fly it directly into the ocean. There was a whole chain of events (including some appalling human factors) that led to the tragedy there.
The avionics teams at both companies have put an incredible amount of thought into how these systems are designed, and how they fail. The differences are instructive, but we should refrain from being quick to judge which is more or less intuitive.
[+] [-] ern|11 years ago|reply
[+] [-] andyjohnson0|11 years ago|reply
[+] [-] damian2000|11 years ago|reply
"The investigation was unable to determine whether the copilot was aware of the pilot in command’s dual sidestick inputs, even though they resulted in aural ‘DUAL INPUT’ synthetic voice messages…The copilot’s focus on correcting the aircraft’s attitude and trajectory, together with the numerous FWS synthetic voice messages, may have resulted in the copilot not comprehending the significance of the aural ‘DUAL INPUT’ warnings…"
From: http://criticaluncertainties.com/2011/09/16/pilots-in-the-lo...
[+] [-] dredmorbius|11 years ago|reply
[+] [-] ericson|11 years ago|reply
[+] [-] jacquesm|11 years ago|reply
Another instance of a very poor choice that led to people being killed in aviation was the one where 'take-off power' was interpreted as 'take power off'.
I can't find a reference to that accident but the essence was that during a go-around instead of full throttle the pilot reduced power causing the aircraft to stall and crash.
[+] [-] WalterBright|11 years ago|reply
[+] [-] gear54rus|11 years ago|reply
So long as you can always tell which mode is the current one, I feel modes are fine.
That said, the example in the article seems like a pretty severe oversight (crucial indicator, completely identical modes) by itself.
[+] [-] dunmalg|11 years ago|reply
It's fairly obvious, isn't it? A keyboard with no shift key is going to need twice as many keys... but of course you'll also never find yourself accidentally typing with caps lock on. That's the trade off. The UI becomes more complicated.
[+] [-] sgustard|11 years ago|reply
[+] [-] userbinator|11 years ago|reply
http://web.archive.org/web/20050914030410/http://web.mit.edu...
http://web.archive.org/web/20050412110614/http://web.mit.edu...
Notice that the mode indicator is only in the middle, far from the value it's indicating the mode of, but in the cockpit picture in the article ( http://blog.martindoms.com/wp-content/uploads/2011/01/IMG_82... ), you can see that there are actually two mode indicators, one in the same position as the one in the study and one right above the value where it should be. A quick Google of other cockpit images shows that the plane does have two. I wonder if this was an oversight?
[+] [-] sengstrom|11 years ago|reply
[+] [-] josefresco|11 years ago|reply
Before we were all concerned for our privacy these modes were (and prob still are) mostly used for surfing porn. When one is surfing for porn in "private" mode it would benefit to have the UI not scream "I'M DOING PRIVATE STUFF".
[+] [-] shoyer|11 years ago|reply
[+] [-] damian2000|11 years ago|reply
[+] [-] tboerstad|11 years ago|reply
[+] [-] sehr|11 years ago|reply
[+] [-] cnvogel|11 years ago|reply
This also includes pictures of the displays without (-3.3 and -33) and with (appending two small zeroes for the latter) the fix employed by Airbus.
(I also commented on the original article, but await moderation.)
[+] [-] ExpiredLink|11 years ago|reply
Not a story for Vim aficionados.
[+] [-] camperman|11 years ago|reply
https://www.youtube.com/watch?v=0wp-Dbb2CO4
Start at 3:34. Very revealing comments at 5:20 about pilots having to fight with the "strong but silent partner" in the cockpit.
[+] [-] _pmf_|11 years ago|reply
[+] [-] roma1n|11 years ago|reply
[+] [-] rbanffy|11 years ago|reply
[+] [-] nkozyra|11 years ago|reply
With something as complex and data-driven as air flight, managing a UI will always be complex as a result. As any given control needs to be available at any given moment, you cannot obfuscate too much in the interest of cleanliness.
With all that said, this issue is still not a UI issue, but a training issue and perhaps also an issue with a lack of standards (I'm assuming, not in flight) with jet UI. Even with poor UI, understanding what you're changing and verifying it should boil down to training.
Based on this article, it seems like there's a lack of continuity between aircraft in where controls are, and I wonder if there's ever been any push for standardization. I realize not all craft could be complete mimics, but general controls and indicators should be in the same general area, right?
[+] [-] jonahx|11 years ago|reply
Absolutely not! Yes, I want the pilots flying my plane to be as well trained as possible, but there also better damn well be a good UI in place to prevent human error, because that's the one thing we can count on, no matter how good training is or how well-intentioned people are.
[+] [-] lordnacho1980|11 years ago|reply
As for the airplane example, isn't it quite natural to expect the pilots to have gone through extensive training? I understand consumer websites need to be intuitive, but highly specialized things can't really be intuitive.
One big problem with complex things like a cockpit is that the guys who build it are specialists in a different field from the guys who use it. So how are they going to know if the thing is intuitive? I would imagine a pilot mostly touches the same few commands each day, leaving most modes out of use most of the time. By contrast, the developer needs to build the whole thing.
[+] [-] DanBC|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] SG-|11 years ago|reply