[sofixa]

If anyone is interested in recently made content that recaps the whole thing, all the available information, some of the speculation, including the most recent news/information:

* video by Mentour Pilot - https://youtu.be/Y5K9HBiJpuk

* great read, as usual, by Admiral Cloudberg, slightly older: https://admiralcloudberg.medium.com/call-of-the-void-seven-y...

[JumpCrisscross]

“Malaysia Airlines operations…were tracking the plane on the Flight Explorer website, which, as they would only realize hours later, simply continued to display an aircraft’s projected path if its transponder stopped broadcasting position information.”

What in the actual fuck.

“…the supposed signals from the black boxes must have been false. Only much later was it discovered that the signals had probably come from the scanning equipment pinging itself.”

Wat.

“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.

[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.

[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.

[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.

[rdtsc]

You look for the keys only under the light pole where there is light. If you can’t find them there assume a black hole materialized and swallowed them then disappeared.

https://en.m.wikipedia.org/wiki/Streetlight_effect

[pfdietz]

More generally, sticking with an approach that "works" by some shallow criterion, even though on deeper analysis it doesn't work, because the alternatives are not as good by the shallow criterion.

The example I point to is tokamaks for fusion energy.

[tyingq]

That top one really gets me. That employees in flight operations wouldn't understand the concept of dead reckoning is used in a flight tracker. Well not that some would have been confused... But that nobody in the room would have raised that over a several hours span.

[grotorea]

Even on a pure UI level, any software used in such a role really ought to warn the user somehow for "this aircraft has been X hours out of contact" in a world where this isn't supposed to happen anymore.

[SkyPuncher]

Sit does. They tell you last report time.

You also figure it out pretty quickly when you watch a few plans make physically impossible jumps between their dead reckoning location and their actual location.

[tyingq]

Agreed, just odd in a room full of experts.

[krisoft]

> WAT.

What what? Do you want to pay for the search? How much do you want to pay for it? Every human endeavour is constrained by resources. The art of doing anything is figuring out how to best employ the available resources to achieve goals.

> What in the actual fuck.

Is this your first time hearing about humans being confused by complicated technology?

[JumpCrisscross]

> Every human endeavour is constrained by resources

There is a difference between constraining activities based on resources at hand and adopting a hypothesis because it favours your resource constraints. (Searching for keys under the light is reasonable. Concluding the keys must be under the light is not.)

> Is this your first time hearing about humans being confused by complicated technology?

An airline using a free consumer tool [1] to track its planes is not a problem of complicated technology. (FlightExplorer has a professional edition, but it runs natively. If flightops were looking at a website, they were essentially using Google Flights to track their planes.)

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

[krisoft]

> Searching for keys under the light is reasonable. Concluding the keys must be under the light is not.

Yes. And there is nothing to indicate that they concluded that the keys must be under the lights. In fact there is every reason to assume that they choose this assumption to fit their resource constraints. Because the other option would have been to not even start searching.

But turns out if you assume people are stupid, then they will appear stupid.

> An airline using a free consumer tool [1] to track its planes is not a problem of complicated technology.

Everything about aviation is complicated technology. The fact that there are free tools which provide almost the same answer the professional tools do, but can be misleading in edge cases is further evidence that the technology is complicated.

Also this is the problem with vacuous statements. The statement, I quote "What in the actual fuck." does not let us know what the commenter found curious about the situation. I thought it was that an operator misread the display. You think it is that the operator's had a "free" display instead of a professional one. But who knows. We could even ask why is it the airline who was bumbling around instead of just calling the ATC that the airplane is overdue and letting them figure out with their professional tools and training. Or maybe they are just surprised that airplanes sometimes fly and sometimes not. Who knows.

[JumpCrisscross]

> there is nothing to indicate that they concluded that the keys must be under the lights

"ATSB chose to assume that the plane spiraled in close" based on their resource constraints. The resources are the light. They ruled out--according to this source--a hypothesis based on where the light was.

> the other option would have been to not even start searching

Why?! Even when ATSB chose their hypothesis the entire area wasn't searched.

> there are free tools which provide almost the same answer the professional tools do

Not for flightops! (And not this one.)

> but can be misleading in edge cases is further evidence that the technology is complicated

Have you flown a plane? This isn't an edge case issue, it means MA flightops was always blind on takeoff and approach for its entire fleet. That they thought this website was appropriate for the task represents a massive lack of training and protocol, let alone tooling or oversight.

> You think it is that the operator's had a "free" display instead of a professional one. But who knows

The article said MA flightops "were tracking the plane on the Flight Explorer website" (top comment). I pointed out that FE doesn't have a web-based professional app (comment you responded to). This isn't a "who knows" situation.

> We could even ask why is it the airline who was bumbling around instead of just calling the ATC that the airplane is overdue

Read the article at the top of this thread. Dempsey/Cloudberg goes into this in detail.

[krisoft]

> They ruled out--according to this source--a hypothesis based on where the light was.

That is your reading of the sentence. "choose to assume" does not mean that they ruled out other options. It especially does not mean that they ruled out other options when it is combined with the second part of the sentence which describe that the reason they took this assumption is due to resource constraints.

> Have you flown a plane?

Yes.

> This isn't a "who knows" situation.

You are misunderstanding the whole paragraph. The "who knows" situation is what you, JumpCrisscross was thinking when you wrote "What in the actual fuck.". If instead of emotional venting you would have wrote a complete and full sentence we would not have had to speculate what you are incredulous about. Clear?