[grotorea]

After a lot of aircraft accident youtube videos, I can think of a couple where people misunderstanding where their computers get their information from and how they work.

* This one where the operations team apparently doesn't understand how their flight tracker works, and/or it fails to inform their users that last contact was X hours ago.

* One where the aircraft has a broken altimeter, and the suspicious pilots decide to ask the ATC for altitude confirmation, but the ATC radar only gets horizontal coordinates, the altitude information that ATC sees actually comes from a datastream from the aircraft itself. So they fatally decided to trust that instead of their own aircraft radar altimeter which was correctly telling them they were about to crash.

* The aircraft had either a single failed engine or the wheels were stuck outside, and the pilots asked the computer for how far they could travel in their current state, assuming it worked like a car, by projecting current consumption, but actually the computer just uses fixed data that does not take such exceptional situations into account. So they ran out of fuel early.

> “ATSB chose to assume that the plane spiraled in close to the seventh arc because it had not received enough funding to extend the width of the search area to 100 nautical miles.”

> WAT.

It seems the police department has insufficient funding to help drunks look for keys in the dark.

[JumpCrisscross]

> the operations team apparently doesn't understand how their flight tracker works

The operations team didn't have a flight tracker. The Flight Explorer website is a free consumer tool [1]. The actual flight tracking software is native [2].

Malaysia Airlines' flightops was essentially using Google Flights to track their planes. That's the WTF.

> actually the computer just uses fixed data that does not take such exceptional situations into account

I've never flown a 777. But modern GA flight computers, e.g. G1000, are pretty advanced about projecting fuel consumption. (Of course, this wasn't always the case [2].)

[1] https://travel.flightexplorer.com

[2] https://en.wikipedia.org/wiki/Gimli_Glider

[2] https://www.flightexplorer.com/products/professional/FE-Prof...

[carlmr]

You could of course blame the individuals for not knowing where which information comes from, but that wouldn't help in avoiding such problems in the future.

I think it's a UX failure in some sense. It's important information to know which number comes from what source.

So it should be clearly visible if a trajectory is prediction without up to date positional data.

It should be clearly visible which values are from the aircraft and which are from the ground.

It should be clearly visible that a range estimate is derived only from fuel sensors.

I hope that the 5Y process or whatever they used came to this conclusion as well, and not human error.

Human error is constant, design issues can be fixed.

Sometimes I think UX design should be mandatory for software developers and engineers. Even only reading The Design of Everyday Things would probably prevent a lot of catastrophes.

[krisoft]

> Sometimes I think UX design should be mandatory for software developers and engineers.

Human Factors is very much part of every airplane's design. From the ground up, and it involves all roles and every subsystems.

> Even only reading The Design of Everyday Things would probably prevent a lot of catastrophes.

I think you have a twisted assumption about how much care goes into aviation UX. The people who do these designs did much more than read a single book.

> It should be clearly visible that a range estimate is derived only from fuel sensors.

Good plan! Now tell us how you will do it. (Also clearly you are misunderstanding even the problem. The problem was that the range estimate was NOT derived from fuel sensors.)

[carlmr]

>I think you have a twisted assumption about how much care goes into aviation UX. The people who do these designs did much more than read a single book.

I don't work in that sector which is why I went by the posted examples. Showing a predicted trajectory exactly the same as a measured trajectory seems like no care at all was taken.

>Good plan! Now tell us how you will do it.

I'd have to see an actual implementation. But e.g. the air traffic controller gets their trajectory shown the same? Make it a dashed differently colored line from the point you haven't gotten a sensor reading.

But by the way you're attacking people over small oversights in a comment I can't assume good faith from you.

[krisoft]

> But by the way you're attacking people over small oversights in a comment I can't assume good faith from you.

The problem is not with any small oversights. The problem is with the attitude of your comment. You proposed that developers should should read a design book and that would prevent catastrophes. That is insulting.

Aviation is a mature field. People much more clever than you or me spent decades of their lives thinking deeply about how to make it safe. That includes the proper UX design of the systems involved. And they did a very, very good job at it. Aviation has an exemplary safety record, especially when contrasted with how inherently dangerous the activity is.

This means that all the low hanging fruits have been already picked. One can further increase safety of course. Nothing is perfect. But it requires very careful analyses, testing, and deep understanding to achieve very small wins.

This is the background we live in. In contrast to this your comment reads as "Everyone is an idiot. I know better. They should read this one book and it would save lives." It lacks humility. You don't even know what you don't know, and yet you act as if you possesses some deep insight the field lacks. At the same time you demonstrate your lack of knowledge with those small oversights you talk about. The problem is not the small oversights, but the momentous lack of humility.

[carlmr]

>Aviation is a mature field. People much more clever than you or me spent decades of their lives thinking deeply about how to make it safe.

I know this, and I'm not saying there weren't clever people working on it. Maybe that came out wrong.

However I have worked on safety-critical systems in a mature industry (not aviation). And the maturity of the industry has IME often meant that a lot of the especially obvious low-hanging fruit are not looked at properly.

Overly bureaucratic processes and people that are too focused on their roles, means that especially a lot of those things that require empathy for the user and a bit of a wide-angle view get ignored until something happens.

This is a two-edged sword since institutions need the bureaucracy and processes to remember it the next time.

For example I'd be that a UX designer with empathy for the user would not put a touchscreen focused control into a car.

The lack of feedback makes it distracting which arguably cost a few lives already. But it's hard to measure without cameras observing people in the last seconds before the crash.

Since there's no numbers there's probably less of a pressure on automotive companies to make it safer. Bureaucratic companies don't work this way. They need to hurt in their profits first.

Yet almost all cars in the last ten years have a lot of touchscreen controls. Because it looks cool in the showroom, and Tesla already did it.

It's a really obvious safety issue. A really low-hanging fruit. But it's in the blind spot of the mature automotive industry.

[krisoft]

> Maybe that came out wrong.

No worries! What matters is that we can discuss it and figure things out eventually.

What i can totaly agree with you is that correct design is critical, and blaming individuals for their failings is not the way forward if we want to make an activity safer. I think this is the gist of what you wrote and it is absolutely correct.

The only thing i bristled at is that it is not a new insight and widely accepted tenet in aviation.

> For example I'd be that a UX designer with empathy for the user would not put a touchscreen focused control into a car.

Yeah. I agree with that point. I think modern cars have touchscreens for two reasons: It is cheaper for the manufacturers, (Less parts to assemble, and less parts to keep in stock) and it is slightly prefered by the costumers due to the showroom appeal. (As you also mention.) It is kind of like candy in that regard. Not good for people but they still want it.

In other words it is not the empathy and the understanding what is lacking. Just that the cost savings combine with the consumer appeal in such a way that they overpowered the UX considerations. Sad thing. But sadly not a situation where people reading a design book will change the incentive structure.

In fact I bet that if we dug into it we would find internal memos written by UX engineers pointing out exactly what you wrote, and other engineers in response pointing out that all those functions on the touch screens are “non safety critical”. I have seen those arguments often.

[jvanderbot]

> Good plan!

Looking at an aircraft cockpit I see Billions of Buttons https://tvtropes.org/pmwiki/pmwiki.php/Main/BillionsOfButton...

Would writing the equation, data sources, and output format for each of those buttons on the button be good UX?

No, I agree with you, this is not a UX problem it's a training one - a test question along the lines of "How does fuel prediction work on a B790" etc ...

[krisoft]

Exactly. Now if we decide that on some type of aircraft we will display both kind of information to the pilots then it is a user interface task how to present these two similar but different information in such a way that it is clear which one is which.

[JumpCrisscross]

> Looking at an aircraft cockpit I see Billions of Buttons

Not true for glass cockpits. While there is a lot of skeuomorphism in avionic UI, there is also a good amount of situation-driven dynamism.

Modern GA avionics' fuel estimates are pretty much on the money given a flight plan.

[lxgr]

Which incident are you referring to with the altitude confusion example?

[aaronmdjones]

Aeroperu 603.

[beerandt]

Not knowing your altimeter is connected to your transponder, and that you provide the altitude along with your squawk to the atc screens is a pretty glaring wtf.

[aaronmdjones]

I can forgive the pilots for not knowing that ATC is getting altitude information from the plane. They're not air traffic controllers after all, and the training back then was a lot less thorough than it is today.

What's more alarming is that they had a perfectly functional radar altimeter and ought to have known that this is a completely self-contained system; it doesn't depend on the flight computers, the pitot-static system, or any external information such as your current position or a programmed flight plan. If it's telling you that you're only a couple thousand feet above terrain, you really should listen to it and respond accordingly.

Neither of the pilots did.

EDIT: https://www.youtube.com/watch?v=jIz6vODilro

[anonfornoreason]

On general aviation planes there are usually two altimeters that are independent. The instrument a pilot uses to fly with (round dial gauge or digital version in glass cockpit) and one inside the transponder itself. If you lose your altimeter you actually can call up atc if you have a mode-c transponder and have them read it to you. It’s separate.

No idea how it works on a passenger jet, but I would be shocked if it was different.

[aaronmdjones]

On the aircraft in question (the 757-200) there are 3 altimeters (captain, FO, standby/backup) fed by two different colocated static ports (that were both taped over). The transponder sends the altitude reported by the captain's altimeter.

This is why the crew trusted the captain's altimeter over either of the other two because it precisely lined up with what ATC was telling them. Neither set of parties knew that they were the same incorrect figure derived from the same source. The captain correctly diagnosed that the entire pitot-static system had gone to shit, but still trusted ATC's figure, right up until they started hitting the ocean, even with the GPWS alarm from the (correctly functioning, entirely separate) radar altimeter blaring in the cockpit for over a minute.

[coredog64]

ATC does have access to radar that locates aircraft via skin paint. TBH, I’d push that back on ATC. If I’m confused about my altitude, it’s not because I suddenly can’t read the numbers on the dial. ATC should understand that the confusion can be resolved by checking with an outside source.

[aaronmdjones]

Primary radar as used by ATC is extremely limited. It is not designed to identify targets at all; nor does it have particularly good vertical resolution. It can tell you where in 2D space a plane is, but without secondary radar and a cooperating transponder, it can't tell you what plane it is, and its uncertainty with respect to altitude can be several thousand feet.

[lxgr]

What do you mean by “skin paint”?

Civil primary radar usually isn’t 3D and does indeed depend on transponder, i.e. secondary radar, supplied altitude data.

They should know what their radar supports in any case, and get suspicious when an aircraft asks them for a readback of airplane-supported altitude data.