- Debugging Versus Browsing
- The Human Problems of Debugging
- Cognitive Psychology and Program Debugging
- Human Input Channels Affect Debugging
- Using Auditory Channels in Applications
- Final Thoughts
- Bibliography
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Using Auditory Channels in Applications
The use of the auditory channel in mission-critical applications has long been understood in some application domains; heads-up targeting displays in combat aircraft provide visual feedback while the auditory channel provides information from aircraft state alarms to warnings of hostile actions targeted to the aircraft to feedback on target acquisition. Auditory alarm channels in critical environments such as industrial process control are assumed, and in some cases mandated. Yet in programming, we are almost always limited to a single beep as our sole form of audio feedback, either to the developer or the user. That should no longer be a limitation.
The author built a system in the 1980s using a VOTRAX voice response unit. The system was a data concentrator system that was the front end to a telephone company host computer. The data concentrator established the phone connection for subsequent stored voice message responses to the phone calls. The debug software voice response unit was placed so that the programmer could hear the voice messages relating to debugging independent of where the programmer’s current focus-of-attention was. This system was built using the Intel RMX86 Real-Time Operating System. While a modern GUI was not available, the generation of text messages in conjunction with the voice activity messages was a key feature. The use of the two communication channels shortened both the debug time and the acceptance time of the system. Even users who were not programmers could form a good understanding of the system behavior. A second system built along these lines was used as a data concentrator for an oil company whose gas stations made daily activity reports. The use of voice output again shortened the debug time over the expected time experienced for similar systems, and hastened customer acceptance of the resulting product.
Another project was developing a program that models semantic behavior of the brain. This was a system with very deep nested layers. It was implemented using the RMX86 system, so the VOTRAX unit was connected, and voice response messages were judiciously placed in the program to describe what the program was doing. As the system operated and spoke, it was possible to pore over the listings and gain a cognitive insight to the program’s behavior, and thus quickly complete the programming task and meet the expected goals.
In a lower-tech solution, the author has observed, while watching work in developing real-time computer music software the use of an MIDI output channel to help debug program flow. When the MIDI channel was being debugged, the speaker on the computer was used. Short two-note to four-note sequences were used to indicate the current state of the program. For example, a high pitch indicated interrupts-enabled and a low pitch indicated interrupts-disabled, and the expected sequence always alternated tones. A failure in the tone sequence immediately drew the programmer’s eye to the debug printout and thus focus-of-attention was directed by the sounds, rather than by parsing and then comprehending the printout. The beeps had the additional advantage that they could be done at the driver level while the text messages required the application be running at user level.
A similar technique was adopted for compilations: two short high-pitched beeps meant an individual compilation had failed, three longer low-pitch beeps indicated a successful compilation and link, and five intermediate-length medium-pitch beeps indicated the link had failed (usually due to one of the modules having failed to compile). A colleague adopted this technique to play the first measure of various compositions for the same purpose (a successful compilation was signaled by the famous first four notes of Beethoven’s Fifth Symphony). Since the machines were adjacent, we always knew whose machine was demanding attention.
Many older programmers may remember how an AM radio sitting on the main processor box (that was in the days when the CPU size was measured in cubic feet rather than in fractions of square inches) could reveal what the processor was doing, even when they were off doing something else that required a different level of concentration. The author remembers how the sudden cessation of a certain regular sound pattern would notify him, from across the room that the program had syntax errors and the compilation had been rejected. More recently, a colleague complained that her new high-capacity, and quiet, SCSI drive made it harder to use the computer, because she had to keep watching the screen to know when the report had completed; previously, the sound of the older noisy disk seeking had indicated the report was in progress and the cessation meant it was done, freeing her concentration for other tasks.
While these anecdotes represent local experience, they are consistent with more formal studies, and illustrate the importance or usefulness of the audio channel from the viewpoint of programmers and users.