Program outline
This page describes the main aspects of the program. More detailed designs and description of each aspect are needed.
Functionality
basic functionality
The end user will enter codes. The codes will be translated into characters. The charactes will form words and become a phrase. Once the phrase is completed the end user has a way to indicate this and the speech syntheziser will say the entire phrase. The phrase will be added to a chat list like window (for later reading) and a new phrase can be started.
future possibilities
For a future release there are the following ideas already:
- send a text by e-mail. There can be a small list of predefined addresses the end user can choose from.
- send a text by sms. Also from a pre-defined list
- a music player (simple version of iTunes, WinAmp) with an aural interface.
Interface
The interface falls apart into three parts:
- an aural interface for the end user. This will make it possible to use the program without any eyesight. Switch off your screen during the development of this interface.
- a visual (graphical) interface for the end user. This will make it possible to use the program without hearing. The interface is to be designed in such a way that it can be used by people with poor eye vision.
- a visual (graphical) interface for the supporting people (nurse, family) around the end user. They will do difficult and one time tasks such as setting preferences.
Input device
The program will have a modular structure in such a way that we can easily support different kind of input devices. During the development phase we will use input by keyboard to start with.
Several possible input devices:
- standard keyboard. This doesn't conform to the requirements. We will use a standard keyboard during development - because it is easy.
- numeric keypad. This is actually the right, numeric part of the keyboard. They can be connected to a USB port, are cheap and will be recognized as a normal keyboard.
- joystick. The axes represent 4 switches, then there are usually two more switches. As this is a standard device this is fairly easy to support. Joysticks are on the market in very diverse forms, which can be a benefit for our users. Besides the ones for games there also exist so called 'industrial' joysticks which are smaller and might be very usable. A big advantage of a joystick is that the end user can keep it into the fingers and so avoids the need to find the buttons.
- specific devices. By attaching an I/O board (a small piece of hardware) to the computer you get connections for several switches. This makes it possible to build a specific input device customized for an end user. The I/O board should posses an USB connection. Because the support of an I/O board is time consuming we will carefully consider what boards to support based on criteria such as price, platform and Java support, availability and so on.
Technology & components
The program will be written in Java. The many arguments in favor of this choice are a high degree of portability and the many components and source libraries we can use. Java has sufficient performance and a good degree of stability for the program.
For the graphical interface we will use the Java Swing library. There does exist a speech synthesizer in Java that we can use: FreeTTS.
Modularity
In order to build a flexible program that can be adapted to the specific needs of a user a modular apprach is usefull.
- input module. This interacts with a physical input device and sends the switch events to the decoding engine. In the case of morse it will send a 'dot' or a 'dash'.
- decoding engine. The decoding engine takes care for the translation to plain text
- process engine. This is the heart of the program. It gets the input codes, sends them to the decoding engine, addresses the speech engine and interacts with the end user.
- sound module. A module that contains sounds like 'space added', 'error' etc.
- speech engine. This is an interface that can address multiple speech synthesizers. In this way it will be possible to change from one synthesizer to another.
For each module a Java interface will be designed. For the first version we will do the groundwork for this architecture but limit ourselves in the extent to which we support it. It will not be necessary to hot swap modules while the program is running.