Next we give more details on the input devices and the way they were used in the experiment.
The EasyCat has two buttons that can be used as mouse buttons, but it can also emulate the mouse buttons through tapping the surface. Tap on the brighter colored area in the upper right corner of the active surface emulates the second mouse button. A tap anywhere else emulates the first mouse button. Dragging with button emulation happens through a double tap where the finger is left down on the second tap. EasyCat acts as though the first button was pressed until the finger is lifted again. If the finger drifts close to the edge of the touchpad during a drag, the finger may be lifted and placed elsewhere on the pad without breaking the dragging mode. These standard features of the EasyCat work conveniently with MDTIM and thus we did not bother to disable them. The dragging mode allows the user to utilize a kind of CapsLock feature. This is convenient if the user holds the touchpad in an orientation that does not allow pressing the buttons easily.
EasyCat is designed to be used while resting on a desk. In our test, however, the touchpad was held in the non-dominant hand to simulate using a small portable device.
Like the touchpad, the gamepad was also held in the hands of the user. The most common style adopted by the users was to envelope the gamepad in both hands and use the dominant hand to control the joystick while the thumb of the non-dominant hand was held over the buttons.
The dominant hand was used to operate the mouse. A mouse does not suit well for use without a desktop and thus it was used on a desk.
As seen in figure 5.2 the Trackball Pro is a typical trackball construction with a big ball mounted on a box with buttons. The buttons are located symmetrically and their functions can be reversed so that the trackball is equally suited for left and right handed operation.
While some trackballs are small enough for desk-free operation, the Trackball Pro is not one of them. Thus the trackball experiments were done while the trackball rested on a desktop. Again, the dominant hand was used for operating the trackball.
The keyboard was yet another desk-bound device. Like with the other devices, the dominant hand was used for operating the keyboard.
Figure 5.3 shows the interface that was visible to the test subjects during the test sessions. The largest window within the main window is a ''working space`` where the software displays the current MDTIM character during the input. Above the large child window we have two smaller windows. The upper of these displays the phrase that the user is supposed to write using MDTIM. The lower window shows what the user has written. The tall window on the right shows the tail of the data written to the log file.
As can be seen in figure 5.3 the user can see both the actual input and MDTIM interpretation of that input. The actual input is the thin line and the MDTIM interpretation is the thick black direction sequence that we are already familiar with from chapter 4.
Although the idea was to test MDTIM in a form as simple as possible without any fancy signal processing, dictionary support for recognition, or other external means of improving the performance, some measures were necessary to make it usable at all. First the joystick data is gathered with some filtering as discussed in chapter 4. Second, the mouse data needed some filtering too. A minimum threshold was set for interpreting the difference between two consecutive coordinates to be a direction. Without filtering out the tiny movements the result would be an uncontrolled stream of directions as soon as the user touches the touchpad or mouse. When the acceleration was set close to minimum in the mouse driver settings, a good threshold seemed to be around three pixels. This filtered out most of the small unintentional movements while reacting soon enough when the user actually tried to do something.
While MDTIM may allow eyes-free operation with some input devices, this is not the case for novice users using a touchpad. Thus, as described above, the software gives visual feedback. While the benefits of auditory feedback may not be as clear as they are with the visual feedback, the software also emits a click through the Windows' sound system when a character is recognized.
Five volunteers were chosen from the staff of the Department of mathematics, statistics and philosophy in the University of Tampere. All were between 23 and 29 years of age. Our sample was clearly biased towards the best young brains in town at least in terms of mathematical ability. Clearly a sample like this cannot be claimed to represent the population in general. However, we did not have much choice. Ten sessions, preferably on different days during a two-week period, is too much to ask from a complete stranger without any compensation. Thus we chose to accept the warped sample to get the test done at all. Because the test subjects worked in the same building, the test sessions at the beginning or end of the day were easy to arrange.
We tried to schedule the sessions for consecutive days. However to accommodate the test subject's summer holiday schedule we sometimes conducted two sessions each day with a minimum of five hours between the sessions. Weekends caused a two day break. Few one day breaks were also allowed if the test subjects had more important things to do.
The first measured task was the typing and handwriting speed test. All subjects were presented with the beginning of the test phrase file in one window and were asked to type as much of it as possible into another window in five minutes. They were asked to avoid or correct all errors while writing as fast as they could.
The handwriting speed was measured using the same data, paper, and a ballpoint pen. This time the subjects were asked to write as fast as possible while keeping the text legible by most people. They were especially reminded to write all characters including punctuation.
Two subjects started with the typing test and three with the handwriting test. The purpose of these tests was to get a rough idea of the writing speed of the subject using two familiar methods for comparison with MDTIM.
Before starting the first 30-minute MDTIM practice session, the subjects were told and asked to try out the following features of the touchpad-MDTIM combination.
Additionally the visual representation of the characters in the reference chart was explained until the subjects seemed to understand it.
The rest of the session 1 was just like sessions 2-9.
Often researchers are satisfied with a small subset of characters such as lower or upper case alphabet and space (for an example see MacKenzie's paper mackenzie_soft_keyboard). While this approach does give a good basis for comparing the input methods, the input speeds and especially the learning rates are unrealistically good. The non-alphabet characters may be rare, but if it takes the user a minute to figure how to input the @ character (or to deduce that it cannot be written at all), the average input speed may be reduced significantly. The more important result of a larger character set may become evident in the speed of learning and ability to retain the learned character sets. MacKenzie and Zhang recognize this fact in their 1997 paper on Graffiti mackenzie97. For these reasons we chose not to artificially limit the size of the character set. The test data is exactly what we found in the fortune databases.
Using a wider set of characters is expected to make the results look bad in comparison to figures measured for other writing method using fewer characters. However, having many characters including many relatively rare characters probably brings the measured speeds and learning rates closer to what we can expect in real-world situations. Therefore, we consider the wider character set justified even at the cost of some difficulty in comparing the results with figures measured for other writing methods.
In addition to the automatic recording of events, we used a notepad and a pen to record user remarks and behavior during the tests.