4 ms·

i'd be curious to hear the reasoning that lead to "silently ignore the button press." even basic consumer devices bark at you when a button press is invalid, a

by a-dub 4y ago

i'd be curious to hear the reasoning that lead to "silently ignore the button press." even basic consumer devices bark at you when a button press is invalid, and the people who work at boeing are obviously not idiots. my guess is that there are a series of guidelines, solid reasoning or standardizations that lead to this nonsensical result and that decision-making and design process itself would be the interesting thing to understand in what went wrong here...

pas 4y ago
> the people who work at boeing are obviously not idiots well... knowing what we know of MCAS, and their whole approach to user interaction ... that bar is very shaky. anyway, the answer seems to be that the button has a clear feedback in the form of physical thrust set-point indicators. basically the pilot (if I remember the post correctly, the first officer) should have noticed that despite pressing the button the set-point indicators did not move.
- a-dub 4y ago
  mcas seems sort of different, in that it was a software/computer patch for a hole that was opened up in the physical handling characteristics of the aircraft as part of the retrofit to make it more efficient. it seems clear to me that it was an experiment in fusing computer with modified airframe to try and thread the needle of "no additional training required" and increase the financial performance of the program. i suspect the story behind most decisions in flight control ui is a very long one, with a long list of lessons learned, expectations set and human factors. these things arise in any complicated design, where some new feature violates the existing design principles and a compromise is made that on its face makes no sense, but in context is totally understandable. that context would be interesting.
  - pas 4y ago
    sorry, I wasn't clear what I meant. As far as I know - please correct me if write this wall of text based on inadequate information - the problem with MCAS was that they wanted to hide it, but that's not necessarily bad UX. what's bad is that they obviously failed in two distinct, but connected and together critical steps/aspects. 1) MCAS did its thing in 10 sec bursts. which was just crazy, never before seen madness. (I agree local design context is important, and I would like to know WTF was the context for this.) 2) it was undocumented because Boeing argued that it was technically just a runaway stabilizer failure, already covered by the manual/training I would argue that the 1st failure was the (more) fundamental one, the UX one. because if the fucking thing looks like what a typical runaway stabilizer malfunction looks like, then yeah, it's "okay", pilots should be able to recognize/remember the correct remediation method for it. ... of course it's debatable how close the new airframe + engines (without MCAS) were to the old one in terms of flight characteristics. it's possible that it really flies like an old one with too much weight in the back, and that's routine for pilots. ... and just to be clear, I think it's just inexcusably dumb to try to cheap out on proper training.

by a-dub 4y ago

pas 4y ago

> the people who work at boeing are obviously not idiots well... knowing what we know of MCAS, and their whole approach to user interaction ... that bar is very shaky. anyway, the answer seems to be that the button has a clear feedback in the form of physical thrust set-point indicators. basically the pilot (if I remember the post correctly, the first officer) should have noticed that despite pressing the button the set-point indicators did not move.

a-dub 4y ago
mcas seems sort of different, in that it was a software/computer patch for a hole that was opened up in the physical handling characteristics of the aircraft as part of the retrofit to make it more efficient. it seems clear to me that it was an experiment in fusing computer with modified airframe to try and thread the needle of "no additional training required" and increase the financial performance of the program. i suspect the story behind most decisions in flight control ui is a very long one, with a long list of lessons learned, expectations set and human factors. these things arise in any complicated design, where some new feature violates the existing design principles and a compromise is made that on its face makes no sense, but in context is totally understandable. that context would be interesting.
- pas 4y ago
  sorry, I wasn't clear what I meant. As far as I know - please correct me if write this wall of text based on inadequate information - the problem with MCAS was that they wanted to hide it, but that's not necessarily bad UX. what's bad is that they obviously failed in two distinct, but connected and together critical steps/aspects. 1) MCAS did its thing in 10 sec bursts. which was just crazy, never before seen madness. (I agree local design context is important, and I would like to know WTF was the context for this.) 2) it was undocumented because Boeing argued that it was technically just a runaway stabilizer failure, already covered by the manual/training I would argue that the 1st failure was the (more) fundamental one, the UX one. because if the fucking thing looks like what a typical runaway stabilizer malfunction looks like, then yeah, it's "okay", pilots should be able to recognize/remember the correct remediation method for it. ... of course it's debatable how close the new airframe + engines (without MCAS) were to the old one in terms of flight characteristics. it's possible that it really flies like an old one with too much weight in the back, and that's routine for pilots. ... and just to be clear, I think it's just inexcusably dumb to try to cheap out on proper training.