The 1988 shooting down of Flight 655 as a user interface disaster

IFF Console Operation Flaw: The aircraft identification friend or foe (IFF) system, crucial for distinguishing between civilian and military aircraft, had a critical operational flaw. Although Flight 655's IFF correctly identified it as a civilian airliner, the Aegis system required operators to manually follow the contact with a cursor. In this instance, the operator did not "slave" the cursor to Flight 655, causing the system to query the IFF of a different aircraft, an Iranian F-14, from the same location.

Dashboard Design Issue: Aegis' large displays, used for senior decision-making, failed to show critical information like altitude. This omission made it challenging to assess the intent of an approaching aircraft. Flight 655's climbing trajectory, a non-threatening maneuver, wasn't immediately apparent to the captain from these displays.

Tracking Number Confusion: Aegis' feature of unifying data across multiple ships led to a fatal misunderstanding. Both the Vincennes and its escort, USS Sides, tracked Flight 655 but assigned it different tracking numbers. When Aegis unified these contacts, it chose one tracking number and recycled the other, which was then assigned to a U.S. bomber. This led to confusion about the altitude of Flight 655, as the captain, unaware of the tracking number change, received data about the wrong aircraft, believing it was descending rapidly.

These UI issues, combined with the high-stress environment and other factors, contributed to the crew's misunderstanding of the actual situation, ultimately leading to the tragic decision to fire on the civilian airliner. This case underscores the critical importance of intuitive, clear, and comprehensive user interface design, especially in high-stakes environments like military operations.

Now, maybe what you're actually trying to say is that the content of the Mastodon thread should have been static website instead. That might be your preferred method of consuming this information, and that would be a valid desire. I can't say I'm a fan of twitter-style threads either.

Having said that, that does not take into account what the author of the thread wanted to accomplish. In all likelihood they're on Mastodon precisely because they want interaction with strangers. Otherwise they would have written the static website version. So it's a matter of misaligned needs.

Also, note that Mastodon is built on a protocol - it does not need a web app. So you could build a thread unroller or use an existing one to meet your static website needs, although I have to warn you: current implementations use JavaScript for that[0].

[0] https://unroller.zachmanson.com/

In a tech company this would correctly be thought of as a systemic failure as opposed to a personal one.

There are so many questionable design choices here for a system that is supposed to be used in high-stress situations. A lot of it reads as someone thinking "ooh yeah it would be cool if it did X" instead of "what's the simplest and dumbest possible way to do this".