We're inundated with too much information (TMI in today's slang) from too many sources, and much of it useless. All this does is raise the noise level, reduce our mental SNR, and distract us by forcing needless context switching.
But there's one large area where we suffer from the opposite syndrome of too little information, or TLI: the “Check Engine” light in the car. Today's highly sensored car generates numerous sensor signals, which go through the car's Electronic Control Module (ECM) to this one user indicator. The problem is that the light can indicate anything from a relatively minor, non-critical problem to a major, “stop the car now” problem.
Many of the check-engine indications are due to a sensor reading out of the OK range, emissions system going out of spec, or even a loose gas cap. Further, many are “false positives,” where the sensor itself is not working properly, but the car is otherwise operating fine. Of course, the owner's manual says you're supposed to get the car checked immediately when the light comes on.
Regardless of the immediacy or severity of the problem, we get the check-engine indicator in just two variations: steady-on for modest problems, and blinking for immediate, severe ones such as engine misfire. This limitation is ironic, since the TMI syndrome elsewhere around us all day, and yet we have this TLI indication where we could really use more.
It may not be practical from a cost or user-interface perspective to have a numeric or alphanumeric display instead of a single light, but perhaps the light could say just a little more? Maybe its output could go from yellow to amber to red, depending on the severity of the problem? Or perhaps it could blink at a rate related to the situation's criticality?
When you design a product, it's a real challenge to balance user needs, system self-assessment, ease of use, needless alarm, cost, display area, and other factors. There is no easy or single answer to these tradeoffs, especially as all users are not the same. Still, it would be nice to have an indicator that tells more, or allows those users who want it to drill down and get some more meaningful information.
As for my check-engine dilemma, I'm taking the do-it-yourself technology route, and getting one of those test meters which can read the actual internal trouble code via the OBD II interface (On Board Diagnostics, version II). Required in all cars sold since 1996, it provides a standardized connector, format, and protocol for the diagnostic interface. OBD II demonstrates the virtues of vendors providing an industry standard that benefits the same customers whom they have just scared, perhaps unnecessarily. (Yes, OBD II was mandated by the government fiat, but at least the auto vendors had a lot of input into it, and generally did welcome it.) Perhaps I'll try next to decode my PC's operating system error messages—or should I even have to?