6 ms·

Decades ago when I was training I was lucky enough to work under a very smart engineer who taught me that the ergonomics of indicators and how people interact w

Decades ago when I was training I was lucky enough to work under a very smart engineer who taught me that the ergonomics of indicators and how people interact with them was important (and thus ergonomics itself is also an important part of engineering). The issue arose after I raised the question about why the indicator lights on the racks of communications equipment that we were developing in our prototype laboratory did not light up when the power was applied. He explained that in large plants such as a telephone exchange where there were hundreds of racks of essentially identical equipment that the only important indicator when all the equipment was working was a lit green bezel at the base of the rack immediately above the plinth to indicate that the rack had power. Thus a tech peering down a row of racks all of whose bezels were alight was informed immediately that all those racks were working. If a bezel was not lit then power to that rack had failed. Indicators on individual items of equipment in the racks remained off unless a fault developed within the unit upon which a red indicator would light up. Maintenance and faultfinding was much quicker if the presence of a light indicated a fault rather than no light at all. If the tech peered down a row of racks and saw a red light he knew exactly where the fault was located. This went hand in hand with what's known as the fuse indicate which is a led or globe in series with a resistor and wired across a fuse. Only when the fuse failed would the fault light appear (because of its simplicity such indicators are highly reliable). Simply, using too many indicators is confusing. Unfortunately, these days, the baubles, bangles and beads brigade of designers who use leds for just about everything has never understood this. Similarly that green indicators should be used to indicate power is present and red to indicate fault. Unfortunately, no one bothers with these conventions anymore. The Christmas tree panels in submarines and in just-in-time manufacturing plants are similarly designed—strategically located/placed lights on the panels only light up to indicate trouble (such as water breaching a watertight compartment, etc.). I've never understood why such an important subject as human ergonomics isn't mandatory in university engineering degrees.

rstuart4133 6y ago
That reminds me of the original Unix philosophy: programs should succeed silently, issuing (error) messages only on failure. You had to add a --verbose flag to get it to tell you what it had done. I'm not sure how it arose, but one observation is even in the beginning the Unix world was full of shell scripts. If every command that shell script ran was chatty, the average shell script would overwhelm you very quickly with noise.
- Too 6y ago
  I think that also stems from shell using the stdout as data transfer for both humans and machines at the same time, and people expect to be able to pipe the output into another process for further processing. Extra text intermittently added would make this far less repeatable and lots of extra lines to filter away before processing. Sure, you've got stderr, but most terminals will print these in the same way so a user doesn't know what is output and what is error really. Goes to show how bad such tools are for automation really.
hilbert42 6y ago
Having now read many of the posts, I'd add that the best way to deploy indicators will depend on the application and the situation in which they're installed. My key point is that if the system isn't fully automatic—that's to say where humans are involved in the process—designers must always consider human ergonomics. Simply put: indicators should be so configured so as to optimise the 'coupling' between the equipment and human observers. This not only goes for lit indicators, bulbs, LEDs etc, but also dials and gauges, etc. For example the color of the dial and the ballistics (damping/settling) in audio VU (level) meters is closely defined. Moreover, although the VU meter has been around for many decades, dispute still surrounds it in that many prefer the PPM (Peak Program Meter) as pioneered by the BBC. Even the color of the dial was changed to the traditional aircraft white on black. I point this out because engineering with human ergonomics at its center is often far from being either obvious or simple. Another example is the analog multimeter versus a digital one. A digital readout meter will give you precision but an analog one with the correct ballistics (usually with critical damping) is much better for nulling or following a drift, trend or rate of change.
jcrawfordor 6y ago
Airbus is known for their "dark cockpit" concept which is similar. Essentially, the presence of indicator lights or icons on MFDs should indicate to pilots that some action needs to be taken. Ideally, the action needed is the same one done by pressing the button that has lit up. This should make it easier for pilots to identify what needs attention, especially when something abnormal happens. A similar strategy they've taken, which the computing industry could learn from, is a central fault management system which prioritizes any faults or alarms that occur during flight and only minimally alerts pilots (e.g. single warning light) if they do not require immediate attention. Instead of distracting pilots with minor alarms, minor faults are displayed for review after landing, when they are actionable by reporting the problems to maintenance. If an emergency does occur in flight, having all fault indications displayed in one place by severity hopefully makes it faster/easier for pilots to understand the problem.
- hilbert42 6y ago
  Fair enough, but unfortunately Airbus did not extend that concept to the fault 'system' in the A380. When a Trent 900 engine in Qantas flight 32 exploded and cut through the control lines the pilots were overwhelmed by the amount of error data to the extent that they had considerable difficulty in interpreting the data. https://en.wikipedia.org/wiki/Qantas_Flight_32 https://en.wikipedia.org/wiki/Qantas_Flight_32 In this emergency, it's clear the fault indicators (and the data they supplied) were not fit for purpose. If you get a chance it is worth watching the documentary where the cabin crew discuss the problem. It seems to me that there were other problems too with insufficient redundancy built into the control of the aircraft's ailerons (insufficient resiliency in a critical system) but that's off-topic here.
- liotier 6y ago
  Same with commands with no output in nominal execution - output only happens in case of error
  - kibwen 6y ago
    This one's a little trickier to apply: if e.g. I'm executing a command to update some rows in a database, a successful execution can tell me how many rows were changed. If the number seems too high or too low, that's useful for setting off my own internal alarms that something might have been wrong with my query.
SpikedCola 6y ago
Genuinely curious about the fuse indicate you mention. On one hand it seems very useful! On the other hand, wouldn't this: a) pass a small amount of current in what would otherwise be a 'fault' condition? a few mA or so to light the globe/led b) depend on the load you have? a resistive load would allow the few mA to pass, but what about a regular led lightbulb (with a driver inside)?
- hilbert42 6y ago
  The indicator in any fuse indicate system draws minuscule current compared with the normal running current of the device (one hundredth the normal operating current or less would not be uncommon). Essentially, if say the power supply capacitors short-circuit and they blow the fuse then the residual current through the indicator and its current limiting resistor is so low that no additional damage will result. Incidentally, the current limiting resistor and indicator are power rated for short circuit conditions (i.e.: I^2R rating of the indicator and its limiting resistor are such as to maintain the indicator working indefinitely). extrapickles is correct, and he's right about spring-loaded fuses in old telco gear. Moreover, there are many other systems for indicating faults depending on the type of fault. The issue here is that they don't indicate a fault until one actually occurs—by default they're 'off' until a fault appears.
- extrapickles 6y ago
  In older telco gear they used fuses that were basically a spring held down with fuse wire, that when blown, made contact with the fault circuit. They effectively where a fuse activated switch. When doing the led across the fuse trick, you need to make sure that the few mA passed is not harmful.
theamk 6y ago
I am not sure I'd want this at my server room. Every modern device has some sort of power supply -- even 48V devices have "soft-on" switches. Those can, and will fail. A single green LED is essential to indicate this. I can imagine a "smart rack" that would have a proprietary system to detect if a device is plugged in but has a faulty power supply.. but I cannot image this being practical outside of a huge server room with homogeneous devices, like a telephone exchange.

rstuart4133 6y ago

That reminds me of the original Unix philosophy: programs should succeed silently, issuing (error) messages only on failure. You had to add a --verbose flag to get it to tell you what it had done. I'm not sure how it arose, but one observation is even in the beginning the Unix world was full of shell scripts. If every command that shell script ran was chatty, the average shell script would overwhelm you very quickly with noise.

Too 6y ago
I think that also stems from shell using the stdout as data transfer for both humans and machines at the same time, and people expect to be able to pipe the output into another process for further processing. Extra text intermittently added would make this far less repeatable and lots of extra lines to filter away before processing. Sure, you've got stderr, but most terminals will print these in the same way so a user doesn't know what is output and what is error really. Goes to show how bad such tools are for automation really.

hilbert42 6y ago

Having now read many of the posts, I'd add that the best way to deploy indicators will depend on the application and the situation in which they're installed. My key point is that if the system isn't fully automatic—that's to say where humans are involved in the process—designers must always consider human ergonomics. Simply put: indicators should be so configured so as to optimise the 'coupling' between the equipment and human observers. This not only goes for lit indicators, bulbs, LEDs etc, but also dials and gauges, etc. For example the color of the dial and the ballistics (damping/settling) in audio VU (level) meters is closely defined. Moreover, although the VU meter has been around for many decades, dispute still surrounds it in that many prefer the PPM (Peak Program Meter) as pioneered by the BBC. Even the color of the dial was changed to the traditional aircraft white on black. I point this out because engineering with human ergonomics at its center is often far from being either obvious or simple. Another example is the analog multimeter versus a digital one. A digital readout meter will give you precision but an analog one with the correct ballistics (usually with critical damping) is much better for nulling or following a drift, trend or rate of change.

jcrawfordor 6y ago

Airbus is known for their "dark cockpit" concept which is similar. Essentially, the presence of indicator lights or icons on MFDs should indicate to pilots that some action needs to be taken. Ideally, the action needed is the same one done by pressing the button that has lit up. This should make it easier for pilots to identify what needs attention, especially when something abnormal happens. A similar strategy they've taken, which the computing industry could learn from, is a central fault management system which prioritizes any faults or alarms that occur during flight and only minimally alerts pilots (e.g. single warning light) if they do not require immediate attention. Instead of distracting pilots with minor alarms, minor faults are displayed for review after landing, when they are actionable by reporting the problems to maintenance. If an emergency does occur in flight, having all fault indications displayed in one place by severity hopefully makes it faster/easier for pilots to understand the problem.

hilbert42 6y ago
Fair enough, but unfortunately Airbus did not extend that concept to the fault 'system' in the A380. When a Trent 900 engine in Qantas flight 32 exploded and cut through the control lines the pilots were overwhelmed by the amount of error data to the extent that they had considerable difficulty in interpreting the data. https://en.wikipedia.org/wiki/Qantas_Flight_32 https://en.wikipedia.org/wiki/Qantas_Flight_32 In this emergency, it's clear the fault indicators (and the data they supplied) were not fit for purpose. If you get a chance it is worth watching the documentary where the cabin crew discuss the problem. It seems to me that there were other problems too with insufficient redundancy built into the control of the aircraft's ailerons (insufficient resiliency in a critical system) but that's off-topic here.
liotier 6y ago
Same with commands with no output in nominal execution - output only happens in case of error
- kibwen 6y ago
  This one's a little trickier to apply: if e.g. I'm executing a command to update some rows in a database, a successful execution can tell me how many rows were changed. If the number seems too high or too low, that's useful for setting off my own internal alarms that something might have been wrong with my query.

SpikedCola 6y ago

Genuinely curious about the fuse indicate you mention. On one hand it seems very useful! On the other hand, wouldn't this: a) pass a small amount of current in what would otherwise be a 'fault' condition? a few mA or so to light the globe/led b) depend on the load you have? a resistive load would allow the few mA to pass, but what about a regular led lightbulb (with a driver inside)?

hilbert42 6y ago
The indicator in any fuse indicate system draws minuscule current compared with the normal running current of the device (one hundredth the normal operating current or less would not be uncommon). Essentially, if say the power supply capacitors short-circuit and they blow the fuse then the residual current through the indicator and its current limiting resistor is so low that no additional damage will result. Incidentally, the current limiting resistor and indicator are power rated for short circuit conditions (i.e.: I^2R rating of the indicator and its limiting resistor are such as to maintain the indicator working indefinitely). extrapickles is correct, and he's right about spring-loaded fuses in old telco gear. Moreover, there are many other systems for indicating faults depending on the type of fault. The issue here is that they don't indicate a fault until one actually occurs—by default they're 'off' until a fault appears.
extrapickles 6y ago
In older telco gear they used fuses that were basically a spring held down with fuse wire, that when blown, made contact with the fault circuit. They effectively where a fuse activated switch. When doing the led across the fuse trick, you need to make sure that the few mA passed is not harmful.

theamk 6y ago

I am not sure I'd want this at my server room. Every modern device has some sort of power supply -- even 48V devices have "soft-on" switches. Those can, and will fail. A single green LED is essential to indicate this. I can imagine a "smart rack" that would have a proprietary system to detect if a device is plugged in but has a faulty power supply.. but I cannot image this being practical outside of a huge server room with homogeneous devices, like a telephone exchange.