Beautiful Code [326]
When a Button Is All That Connects You to the World > Efficiency of the User Interface
30.3. Efficiency of the User Interface
In order to help in evaluating the efficiency of eLocutor in helping you type, the bottom right of the screen shows two numbers (see Figure 30-2). These indicate the number of clicks and the number of seconds between the last click and the first, since the middle box was last empty.
We found that when the prediction worked reasonably well, the ratio of clicks to characters typed was better than 0.8—i.e., it usually required significantly fewer clicks than an able-bodied person would have needed using a full keyboard. When prediction was poor—for instance when constructing a sentence radically different from any in the database—it required up to twice as many clicks as characters typed.
When a Button Is All That Connects You to the World > Download
30.4. Download
ELocutor is free, open source software downloadable from http://holisticit.com/eLocutor/elocutorv3.htm. A discussion list is located at http://groups.yahoo.com/group/radiophony.
Part of the download is the entire source code. I might warn you, though, that it bears some resemblance to a bowl of spaghetti, for which I bear full responsibility. I hadn't programmed for more than 10 years when I started this project, so my skills were outdated and rusty. I did not have a design, only a few hints now and then on the direction in which it should evolve. The code grew with my understanding of the problem, and the results show it. Very simple programming techniques have been used, as is obvious from the code shown in this chapter.
When a Button Is All That Connects You to the World > Future Directions
30.5. Future Directions
eLocutor was always intended as a rapid application development (RAD) project,[||] something that would allow me to show Professor Hawking during our infrequent and short meetings how far the design had progressed. The intention was to rewrite it some time, after the design could be frozen in the shape of a working prototype that people had actually been using and providing feedback on. At that point, I would pick a programming language that worked across platforms, so that Macs or Linux should also be accessible to those severely motor disabled.
[||]http://en.wikipedia.org/wiki/Rapid_application_development.
However, inspired by what T. V. Raman achieved with Emacspeak (covered in Chapter 31), I am now considering an entirely different kind of project. Emacs is, of course, not just an editor, but a very versatile platform that people have extended over the years to allow you to read mail, handle appointments, browse the Web, execute shell commands, etc. By merely adding on a smart text-to-speech capability and context-sensitive commands, Raman brilliantly made everything that could be accessed through Emacs accessible to the blind.
So, I'm wondering whether the same can be done for the motor disabled. Advantages of this approach are:
Designers would no longer have to worry about the mouse, for Emacs allows you to do everything without it.
eLocutor wouldn't just be an accessible editor, but would rather make all the capabilities of the computer accessible.
I might also find more support this way among the open source developer community, which seems to be far better on platforms historically associated closely with Emacs use than in the MS Windows world.
I am therefore appealing to readers of this chapter to teach me how to extend Emacs such that the same one-button navigation of a tree becomes possible. Better still would be someone wishing to take up this project with whatever help I might be able to provide.
Another direction