Beautiful Code [327]
Here, the challenge for the software writer is even greater. Normally, you assume that a person using a computer is literate. In this case, the child has to be able to use a computer in order to become literate. The software we write must appeal to a child enough to entice her to use it as her primary means of communicating with the world, before she can read. What a daunting, yet hugely interesting task! Of course, the software would be great in teaching any child how to use a computer at a very early age, not just disabled kids. Anyone willing to collaborate?
Emacspeak: The Complete Audio Desktop > Producing Spoken Output
31. Emacspeak: The Complete Audio Desktop
T. V. Raman
A desktop is a workspace that one uses to organize the tools of one's trade. Graphical desktops provide rich visual interaction for performing day-to-day computing tasks; the goal of the audio desktop is to enable similar efficiencies in an eyes-free environment. Thus, the primary goal of an audio desktop is to use the expressiveness of auditory output (both verbal and nonverbal) to enable the end user to perform a full range of computing tasks:
Communication through the full range of electronic messaging services
Ready access to local documents on the client and global documents on the Web
Ability to develop software effectively in an eyes-free environment
The Emacspeak audio desktop was motivated by the following insight: to provide effective auditory renderings of information, one needs to start from the actual information being presented, rather than a visual presentation of that information. This had earlier led me to develop AsTeR, Audio System For Technical Readings (http://emacspeak.sf.net/raman/aster/aster-toplevel.html). The primary motivation then was to apply the lessons learned in the context of aural documents to user interfaces—after all, the document is the interface.
The primary goal was not to merely carry the visual interface over to the auditory modality, but rather to create an eyes-free user interface that is both pleasant and productive to use.
Contrast this with the traditional screen-reader approach where GUI widgets such as sliders and tree controls are directly translated to spoken output. Though such direct translation can give the appearance of providing full eyes-free access, the resulting auditory user interface can be inefficient to use.
These prerequisites meant that the environment selected for the audio desktop needed:
A core set of speech and nonspeech audio output services
A rich suite of pre-existing applications to speech-enable
Access to application context to produce contextual feedback
31.1. Producing Spoken Output
I started implementing Emacspeak in October 1994. The target environments were a Linux laptop and my office workstation. To produce speech output, I used a DECTalk Express (a hardware speech synthesizer) on the laptop and a software version of the DECTalk on the office workstation.
The most natural way to design the system to leverage both speech options was to first implement a speech server that abstracted away the distinction between the two output solutions. The speech server abstraction has withstood the test of time well; I was able to add support for the IBM ViaVoice engine later, in 1999. Moreover, the simplicity of the client/server API has enabled open source programmers to implement speech servers for other speech engines.
Emacspeak speech servers are implemented in the TCL language. The speech server for the DECTalk Express communicated with the hardware synthesizer over a serial line. As an example, the command to speak a string of text was a proc that took a string argument