I'd argue that modal behavior <i>isn't</i> a bad thing <i>so long as those modes are very clearly distinguished</i>.<p>It doesn't hurt if they're encountered frequently enough that the user / operator has a clear sense of their distinction.<p>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 <i>operating</i> on it. While frustrating for new users, with experience using modes becomes transparent, as they're switched in and out of <i>all the time</i>. Though the <i>visual</i> distinction of modes isn't always clear.<p>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.<p>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.
More Airbus deadly UI:<p><a href="http://en.wikipedia.org/wiki/Air_France_Flight_447" rel="nofollow">http://en.wikipedia.org/wiki/Air_France_Flight_447</a><p>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.
Making mistakes with blender won't kill you but the modes are enough to drive anybody nuts.<p>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'.<p>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. I mean, modes are literally <i>everywhere</i>.<p>So long as you can always tell which mode is the current one, I feel modes are fine.<p>That said, the example in the article seems like a pretty severe oversight (crucial indicator, completely identical modes) by itself.
Something doesn't look quite right... in the study linked to from the article, the two figures (archived because the site no longer exists) are:<p><a href="http://web.archive.org/web/20050914030410/http://web.mit.edu/aeroastro/www/labs/ASL/MODE_AWARENESS/figure2a.JPG" rel="nofollow">http://web.archive.org/web/20050914030410/http://web.mit.edu...</a><p><a href="http://web.archive.org/web/20050412110614/http://web.mit.edu/aeroastro/www/labs/ASL/MODE_AWARENESS/figure2b.JPG" rel="nofollow">http://web.archive.org/web/20050412110614/http://web.mit.edu...</a><p>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 ( <a href="http://blog.martindoms.com/wp-content/uploads/2011/01/IMG_8281.jpg" rel="nofollow">http://blog.martindoms.com/wp-content/uploads/2011/01/IMG_82...</a> ), you can see that there are actually <i>two</i> 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?
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?<p>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".
<p><pre><code> the moral of the story is avoid modes whenever possible
</code></pre>
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.
See also this report at the FAA regarding the exact accident being discussed in this blog post: <a href="http://lessonslearned.faa.gov/ll_main.cfm?TabID=2&LLID=57&LLTypeID=2" rel="nofollow">http://lessonslearned.faa.gov/ll_main.cfm?TabID=2&LLID=57&LL...</a><p>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.<p>(I also commented on the original article, but await moderation.)
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:<p><a href="https://www.youtube.com/watch?v=0wp-Dbb2CO4" rel="nofollow">https://www.youtube.com/watch?v=0wp-Dbb2CO4</a><p>Start at 3:34. Very revealing comments at 5:20 about pilots having to fight with the "strong but silent partner" in the cockpit.
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.
<a href="http://www.amazon.com/Set-Phasers-Stun-Design-Technology/dp/0963617885" rel="nofollow">http://www.amazon.com/Set-Phasers-Stun-Design-Technology/dp/...</a> has many stories about user interfaces, bugs and their occasional lethality.
UI/UX in general is extraordinarily complex. I think we can all agree on that.<p>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.<p>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.<p>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?
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.<p>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.<p>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.