Hi,
I have three layers of "degradation" in the event of various degrees of system failure:
1) if just some *aspect* of the system fails (e.g., an application crashes, etc.) then I provide high level error reporting with diagnostic assistance. E.g., a "window" can appear explaining the nature of the problem and suggested remedies, etc. [note that I only offer that by way of an example to which you might relate; that's *not* what I actually do...]2) if significant portions of the system are in an unreliable state, I present an unadorned error that, at least, *says* that there is an error and what it is (accompanied by a unique identifier that helps pinpoint where the error is raised). E.g., this is the equivalent of the "blue screen of death".
3) if *most* of the system appears unreliable, I need to fall back to some sort of "if all else fails" mechanism that is *guaranteed* to be able to convey information (unless the processor is toast).This last level is roughly the equivalent of BIOS "beep codes" -- where the hardware and software required to drive the *display* can't be relied upon, etc.
Obviously, beep/blink codes can't say much in a manner that the casual user will be able to comprehend. So, the goal is to pare down the information presented to a careful balance that addresses three classes of people:
- the casual user who knows little more than "it's broke"
- the motivated user who will look up an error code for more information
- service personnel who can pinpoint the exact cause for the signaled error "code"
[note that I also have a means of passing "diagnostic data" out to service personnel -- but, that requires them to have possession of the device]So, I want a scheme that addresses all of the above without requiring their intervention -- since that would require more of the system to be functional than an "output only" mechanism as well as requiring some confidence in their ability to correctly interact with a failed device (which is an exceptional condition so not the sort of thing they are likely to have "practice" doing!).
Taking audible annunciators, first...
You can vary only a few characteristics of an audio signal:
- volume
- frequency
- duration/interval/rate
- count
[note that amplitude modulation and/or frequency modulation fall into these categories]You can't control "absolute" volume -- there are no controls in the device that you can count on as functioning (it's broke, remember??). So, in practical terms, you pick *a* volume level that you expect to be audible without alarmingly so (too loud is worse than too soft since a user realizing the device to be broken will pay closer attention to listen to "soft" sounds whereas a *loud* device report may be inappropriate for the current environment (e.g., a business meeting).
And, a user can't probably resolve more than two relative volume levels. And, since they are *relative*, EVERY error code mapping would have to employ both levels for the user to judge between them.
The same sorts of arguments apply to frequency and duration et al. (HIGH/LOW, LONG/SHORT, FAST/SLOW, etc.)
All of these "relative" indicators require the user to remember past sounds in order to qualify them based on *future* sounds. I.e., "Was that LOUD LOUD LOUD or SOFT SOFT SOFT?" The answer isn't known until the user has been exposed to all variations.
With that in mind, any error code format should ensure that these variations are in expected places. For example, beginning each error with a LOUD SOFT preamble lets the user *know* what loud and soft levels are *before* he has to "listen to the DATA".
IMO, the format should be fixed so the user knows what to expect and when to expect it. E.g., preamble, value, postamble. So, this implies all error codes should be the same number of "digits".
Further, the number of different *types* of digits should be small. So, perhaps three groups of 1 to 4 beeps. Or, a series of three different beeps (LONG, SHORT, SHORT vs. LONG, SHORT, LONG).
Obviously, there are lots of ways of encoding data with these different attributes.
I'm pretty convinced that varying amplitude (two levels) is The Wrong Way to go about encoding things.
In my opinion, the classic "beep COUNT" approach, takes a fair bit of time to emit a complete "error code" (e.g., imagine three groups of 1-4 beeps at 1 second intervals with a 2 second pause between groups -- 64 possibilities taking as much as 15+ seconds to issue). This requires the user to "remember" what has come before while concentrating on what is happening *now* (i.e., "There were 3 beeps, followed by 2 beeps and now this is the first beep in the third group of beeps...")
I *think* a better approach may be to alternate between a set of frequencies. E.g., 64 codes can be expressed with a set of six tones -- ~8 seconds for the entire code to be emitted. I think even those folks who need a bucket to carry a tune could "remember" something like "dah dee dee dee dah dee".
OTOH, it's not intuitive to map dah's and dee's to "symbols" so a non-techy would never think of translating this to the more memorable ABBBAB or 011101 or ...
Argh... tired of typing. Hopefully, this is enough to get some initial comments on various approaches. Let's avoid the visual analog of all this for the time being -- unless your argument relates to a duality that is or is not present in different encoding schemes...
Thanks,
--don