USS McCain collision ultimately caused by UI confusion

> The screen showed the operator what objects were detected on radar, and if he clicked on an object, it would track it. But if the operator wanted to get more information about the object (in this case, by listening in on its radio signals) to find out what it actually was, he had to move a separate cursor and click on the object again.

> It's clumsy and unintuitive, and it made it really easy to forget which thing they were highlighting at any given moment -- the operator can be tracking one object and have it display the information for a completely different one because he forgot to move the other cursor. It's the kind of user interface that wouldn't make it out of the testing phase of a cheap browser game. And it cost the passengers of the plane their lives.

> That's because the operator in the USS Vincennes thought he was listening to the incoming aircraft (the Airbus full of innocent people), because that's the thing he selected, when he was actually receiving signals from a parked F-14 several miles away, because that's where his other cursor was.

> Granted, the transmissions alone wouldn't be reason enough to shoot down a plane: They'd also have to think that it was moving like an enemy aircraft. Unfortunately, the stupid system made that mistake pretty easy, too. Instead of telling the operators at the Vincennes if the approaching plane was ascending or descending, the system just showed them the present altitude on a smaller monitor. The operator had to write down or memorize the altitude, wait a few seconds, then ask again and mentally compare the two results to see if the aircraft was going up or going down.

> Because of this, a calculation error led an operator to report that the Airbus was descending toward the USS Vincennes, like a combat aircraft would, when it was probably getting the hell away from them as fast as possible.

This is incorrect. The BEA report explicitly blames the lack of an AoA display and recommends that an AoA indicator be directly visible to the pilots. The aircraft already has sensors to measure AoA to feed the flight computers; asking for a direct readout of AoA is nothing beyond a UI change recommendation (and not fundamental aircraft re-engineering):

> It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required.

The AoA invalidation logic ("mark AoA measurements as invalid if airspeed is less than 60kt") made the stall warning turn off as the stall became even deeper, making diagnosis of the stall more complicated. Worse, the BEA report states that the appropriate (nose down) control input led to the stall warning reactivating (since such an input would increase airspeed above the 60kt threshold -- inherent to a proper stall recovery), leading the pilot flying to reverse their control inputs and return the aircraft into a worse stall:

> A few seconds after the transition to alternate law, the stall warning sounded briefly, even though the PF’s inputs should have made this warning sound for several seconds. The reason for this is the drop in the measured airspeeds, some of which fell temporarily to below 60 kt, while the angle of attack reached 40°. Furthermore, the drop in measured airspeeds to values of less than 60 kt during the stall caused the repeated activation and deactivation of the warning which may have made it considerably more difficult for the Captain to effectively analyse the situation on his return to the cockpit.

> Several nose-down inputs caused a drop in the pitch attitude and the angle of attack, whose values then became valid, such that a clear nose-down input resulted in the triggering of the stall warning. It appears that the PF reacted, on at least two occasions, with a nose-up input, whose consequences were an increase in angle of attack, a drop in measured speed and consequently stopping the stall warning.

Lacking an AoA readout, the pilots would have had to reverse-engineer AoA from their extant instrument displays, the warnings they were presented, the "feel" of the airplane (is it buffeting? how is it responding to various control inputs?, etc), and past control inputs. Every one of those sources were degraded per the BEA report: they didn't trust (to the point of changing the selected inertial data source even if there was no indicated issue with inertial data) their instruments because of the airspeed inconsistency, the stall warning would reactivate every time they made the correct control input (the exact opposite behaviour of a stall warning simply based on an AoA threshold), and buffet might have been interpreted as overspeed buffet.

Expecting pilots to reverse-engineer the aircraft's warnings to guesstimate AoA -- a value that the machinery simultaneously measures and hides from the pilots -- is fatally bad UI (BEA uses the fancier term "ergonomics"), especially in cases when the flight computers deal with air data inconsistencies by forking over more authority to the pilots.