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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
"Airbus did not anticipate that a pilot would stall a plane and fly it directly into the ocean"
Stalling and flying into the ground have been two common failure modes since flying began and they often happen in sequence. I would think they would be high in the list of misuse cases any aircraft designer would consider.
"we should refrain from being quick to judge which is more or less intuitive."
We should not be quick to judge which UI is more effective, but by definition we can be quick to judge which is more intuitive. In fact, the more time you spend with a system, the less qualified you are to comment on whether it is intuitive. Judging whether a UI is intuitive should take very little time and no expertise past understanding basic operations. I'm certainly not qualified to judge, but I'd think anyone who has experience with modern flight systems would be qualified to comment on whether a particular design was intuitive.
I think he meant "stall a plane and keep it stalled for many minutes, flying it into the ocean". Stall/spin accidents are common, but they normally arise from loss of control at low altitude when there's not enough time or space to recover.
If it's really so implemented, averaging "full left" and "full right" inputs to the "keep going straight" response is deeply wrong. Apparently missing mechanical feedback really contributed to the accident.
Sorry but you are wrong, it´s not a religious issue, it´s a clear IU mistake by Airbus.
I´m currently flying A-320, I´ve also flown B 737(300 and 800), and MD88. It´s true that at the beginning the new airbus received a lot of heat from pilots. After all they were trying to reinvent cockpits UI from 0. This led to a series of design accidents (due to initial design mistakes ) like the one on the article.
The initial idea it´s not bad: reducing weight (removing all mechanical and hydraulic controls), inventing the glass cockpit, simplified system management, etc..
It took over a decade to polish the cockpit (and the whole airplane, that had tons of electronics related failures all around) to it´s actual safe and workable state. Those issues, plus the idea that pilots had to readjust your whole idea of a cockpit, were the ones that created that opposition. The opossition it's almost gone now, although in general we pilots still prefer Boeing aircraft (at least in Europe). Airbus airplanes fly very nicely and are great too.
But now that we are used to the new IU, the concept problems are still there.
Main diference between flying normal fly controls and a moving auto-throttle and airbus fly-by-wire:
-Airbus throttle levers don´t move while the auto-thrust is changing the power setting. All the other airplanes as far as I know do it.
-Airbus side-sticks don´t move when the autopilot or the other pilot is giving an input. Also as somebody explained above, the inputs are added, you can end with a double (or zero input), if you forget to push the priority button (in stress situations like last second corrections to land it´s easy to forget it).
Why this is a mistake? because when flying a modern airliner you have an excess of information to process, all at once. A moving auto-throttle let´s you know what the engines are doing through your hands, without having to look at a tiny indicator at the instruments. Also it let´s you override the auto-throttle briefly because you need more power or less power at a given moment, without having to disconnect it. With airbus auto-thrust either the airplane or the pilot has the control, and you have to manually takeover. This may be dangerous at an approach that it´s already hard enough with cross winds or heavy rain.
The same apply to the side-stick. Normal autopilots move the fly controls at the cockpit while actuating them. This let´s you know what the autopilot it´s doing. And of course when a pilot it´s flying manually, the other pilot knows exactly what he is doing ALL THE TIME. He can slightly correct a maneuver without having to take over the controls from zero.
Airbus has wiped a layer of fundamental information available to the pilots, increasing the information overoosd through the vision. It´s the equivalent of driving a race car with a playstation control. Most of the time this information it´s not used(like in cruise), but you really, REALLY need it when things become hairy close to the ground. In fact I routinely disconnect the auto-thrust to land, with the Boeing and MD88 I kept it engaged.
Airbus knows this, but it´s too late to change 20 years of airplane development. They´ll need to change too many things (systems, procedures, certification, instruction), also right now it´s easy to change from flying let´s say a A320 to a A 330, due to having very similar cockpits and systems (that´s a great idea). The conversion course it´s short and relatively cheap. Changing the controls would make this fleet changes much more expensive and time consuming to Airlines.
I think the concept you're referring to is self-indicating, or in this case the lack thereof. A much more commonplace example that comes to mind is volume control knobs on things like stereo amps; the "old style" had a knob directly connected to the potentiometer controlling the volume, so it was self-indicating and at a glance (or even just by feel if the pointer is tactile) you could see what position it was set to. Now it seems fashionable to use knobs that don't have any markings and will spin continuously, meaning that you have to look at the display to see what the setting is.
To me it sounds like a cost-cutting measure - to have controls that move, there has to be an actuator in them, which makes it more expensive. My stereo which has self-indicating volume knobs actually contains a small motor that rotates them when I use the remote control.
In airliners without flight by wire, the levers move because the automatic system it's engaged directly to them. With fly by wire you have to replicate that system, at least with the throttle levers. I guess that a servo motor and a control-indication circuit it's not the cost that concerns Airbus. It's all the chain of costs related to changing the flight philosophy.
In the case of the sidestick you could link them mechanically, with a disconnect lever to isolate them.
Concerns about errors is another reason they might not do this: extreme corner cases and/or wear and tear might result in incorrect feedback. This would be at least roughly equivalent to the display meters displaying the wrong values; obviously a horribly bad occurrence.
It's a real pity that the resistance to improving (or even fixing!) these shortcomings is mostly economic in nature, I can't imagine that the pilots would object to having these issues solved once and for all.
Unfortunately pilots don't have a whole lot of options to exert meaningful pressure on aircraft manufacturers.
>Unfortunately pilots don't have a whole lot of options to exert meaningful pressure on aircraft manufacturers.
If a group of pilots came together to declare an aspect of a plane's functionality as unsafe, wouldn't that send strong signals to the public, governments, ICAO, etc? Even if those signals were ignored initially, they could become more important later if an accident occurred in which the same functionality is (or "was"?) involved. At that time, the media groups, great lovers of scandal and tragedy, would come out and say, "Functionality X contributed to the accident. These pilots warned about the dangers of functionality X back in year Y, and everyone ignored them." After that, the pilots' opinions might be more heavily considered.
and when they do apply pressure on Airbus from their side of the cockpit, they can't tell if countervailing pressure is being applied from the other side?
The stalling was a consequence, the fundamental problem is that there's no indication that two pilots are fighting over the plane.
And that is an obvious problem. It's literally one of the first things you cover when you begin learning how to fly. The instructor will sit you down and walk through how you hand off the controls and agree who's flying the plane at any given time. Likewise, when flying with another pilot you always do a positive handoff. "You have the plane." "I have the plane." The physical link between the two sets of controls is an important backup mechanism that ensures this happens.
Not linking the two sets of controls is insane. It's unrelated to the different approaches to fly-by-wire. Taking two radically different control inputs and simply averaging them together makes no sense.
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.
Nothing about flying a plane is really intuitive. The Asiana crash was a pretty clear case of pilot error. At some point you have to either trust the pilots or just enable autoland.
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.
Interestingly the word 'take-off' is only ever used in conjunction with a take-off clearance over the radio (e.g. "Speedbird 101, cleared for take-off") where as any other reference will use the word 'departure' (e.g. "After departure contact London control on 123.12").
Not that I'm aware (though I'm not an expert). It is certainly used for one of the many air traffic control units you can encounter at larger airports (e.g "Contact departure on 123.45").
My understanding is that the word 'take-off' over the radio is (or at least should be) treated like a loaded gun, you only say it when you mean it. Departure is used in place of take-off where appropriate (e.g. "Speedbird 101, holding short of runway 13, ready for departure.")
In my experience around towered airports, I can't say I've heard "take-off" used in any radio comms I've had. In the example you've given, "departure" would be used instead of take-off as you've said. Towers are encouraged to use other terms[0], like the following:
"N1234 cleared onto the active runway" which means you're free to proceed with your take-off roll.
When you leave the airspace(at least at a class D airport), the controller will contact you with "N1234 frequency change approved", which means you either contact the next frequency planned in flight(such as flight following, or no frequency if you're just flying around in class E).
>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.
The shift mode key is usable, as the position of your finger gives you tactile feedback of which mode you are in; and it enters a predictable state when you let go.
The caps lock key does a very similar thing to shift, and is not very useful on a modern keyboard. In my experience it is more often engaged by accident than on purpose.
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.
By "state in general", I particularly meant mutable or nonlocal state in general. There is obviously nothing wrong with using variables.
To restate my analogy: the problem is when you can run the same function twice with the same input and get a different result. Or when the same variable can mean two totally different things depending on some external context.
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.
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.