This site will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device.
Links may not work--navigation under construction!
Two-button Menu Dasher and three-button Direct Dasher: User Trials
MacKay, Ball & Donegan (2004) discuss several versions of Dasher that could be driven with discrete button presses rather than continuous motion. Two of these, Menu Dasher and Direct Dasher, have been implemented and subjected to the first round of user trials.
Menu Dasher subdivides the Dasher canvas into a number of boxes, B. The user can choose between two buttons: a cycling button and a zooming button. The former rotates through the available boxes and the latter zooms in on the part of the Dasher canvas adjacent to the currently selected box. If the user makes a mistake, cycling past all B box choices gives the user the choice to back up. Pressing the zooming button at this point allows the user to zoom out rather than in, effectively backing up so that the user can correct the error. A further press of the cycling button returns the user to the first possible box choice, beginning the cycle anew.
In uniform menu mode, the selection boxes are equally sized on the screen, so a zooming action will zoom in on a region of width 1/(B+s) where s is a small robustness parameter which allows a certain amount of text that lies on the boundary between two adjacent selection boxes to stay on the screen when either of those boxes is selected. In non-uniform menu mode, a non-uniformity parameter r can be set such that the boxes are of different sizes. Larger boxes will have a larger probability of containing the user's target text, and are thus situated first. Smaller boxes require more button pushes to access, but will have a greater zoom factor.
Direct Dasher also subdivides the screen, but only into two halves. The user chooses between three actions: zoom in on the top half of the screen, zooming in on the bottom part of the screen, and backing up when a mistake is made.
MacKay, Ball & Donegan consider the potential information rates achievable with each mode for a variety of model users and derive fixed settings for the number of boxes and the non-uniformity that optimise the performance of Menu Dasher for a wide range of model users. These parameters are B=5 for uniform menu mode, and B=6, with r=44 for non-uniform menu mode. This non-uniformity parameter corresponds to the geometric progression in which the relative sizes of boxes correspond to probabilities p = {0.33,0.24,0.17,0.12,0.09,0.06}.
All sessions were performed using a Pentium M laptop at 1.2 GHz running Linux 2.4.23 with the keyboard serving as the input device. The Dasher application was run as a 640x580 pixel display on a 12" LCD monitor. In all trials, the robustness parameter was set at s=25, corresponding to a 2.5% 'safety margin' on either side of a boundary between selection boxes. For uniform menu trials, B=5 for all trials. For non-uniform menu trials, the box numbers and non-uniformity parameters tested correspond to the following selection box probabilities:
All participants were unpaid volunteers with vision that was normal or corrected to normal. Participants reported no physical factors that would affect performance, apart from the red-green colourblindness of one user. This user found some of the colours used on the Dasher canvas difficult to distinguish.
Writing speed
For each five-minute trial, a user's average writing speed is measured in words per minute and shown as a function of time. As can be seen, uniform menu novices are the slowest, averaging about six words per minute after the first hour of practice. The three of these volunteers who then switched to the non-uniform menus did not become significantly faster after another hour of practice and novice users starting with non-uniform menus also end their first hour writing at six words per minute. In contrast, direct mode novices reached the maximum writing speed of the menu mode users after only half an hour and were writing nine words per minute after only an hour of practice, a rate already competitive with an expert menu user who was able to produce 14 words per minute using the direct mode.
Information Rate
Because it requires more button presses to spell uncommon words, users' writing speeds vary from trial to trial and some correlation between the commonality of the words in the dictation task and the users' writing speeds is expected. Words that are less common may take longer to spell, but they have a higher information content. Hence, by plotting information rate as a function of time, it is possible to determine whether a user is becoming more information efficient, even though her writing speed can vary depending on the implemented language model. As can be seen below, the information rate achieved by novice direct mode users has caught up with that of an expert menu user and is approaching almost double that of novice menu users after the first hour. An expert direct mode user attained a maximum of 2.59 bits per second and consistently maintain a rate of over 2.35 bits per second. Even better performance is expected given a smaller safety margin and a more appropriate training text.
User Errors
Dictation errors are represented as the percentage of words written differently from the dictation text. Participants were not penalised for using lower case letters to begin capitalising proper nouns, although erratic capitalisations of common nouns were counted as an error, unless they appeared at the beginning of a sentence. By the end of the twelve sessions, even those novices most resistant to grammatical convention had discovered that Dasher's language model rewards capitalising properly. In a few cases, a word or phrase on the recording was misunderstood. These cases were not counted as errors since the users successfully generated the text that they intended to write. Here we see that errors greater than 10% are rare after about thirty to forty minutes of experience with a particular mode, and it is not uncommon for even novice users to complete some trials with no errors at all.
Information inefficient button pressing
An ideal user would generate text by always selecting the correct zooming-in action without mistake. Real users, however, make information inefficient button presses. It would seem reasonable to expect that users make fewer information inefficient selections as they gain experience using Dasher. Interestingly, however, this does not always seem to be the case. Menu Dasher users sometimes overshoot their target box and have to cycle through the other boxes and backup option to get back to their intended box, costing a number of extra button pushes equal to the total number of boxes, B. The percentage of button presses corresponding to needless looping back through menu options is shown here.
Although novice uniform menu users show an initial improvement after an hour of experience, users still spent between 15 - 25 % of their button presses on unnecessary cycling. Of these users, those who spent another hour using the non-uniform menu mode did not show significant improvement. One might expect that eventually users would get better at hitting their target without overshooting, but even an expert menu user spends nearly a fifth of total clicks on looping unnecessarily through menu options!
For expert user C, it is particularly easy to see how a larger number of boxes penalises a user who overshoots his target; this user alternated between having four and six selection boxes in non-uniform menu mode and because each loop required two extra button pushed to start a cycle over again, the percentage of the time user C spent on looping was consistently higher for the six-box trials.
One might again expect users to learn to move toward their target letter or string with less and less backing up required, but neither direct nor menu users stop zooming out. For direct mode users, a zooming out event is accomplished by one press of a button, but for menu users, backing up requires a number of button pushes equal to the number of boxes, B. Again, the disadvantage of a larger number of selection boxes is illustrated by user C's non-uniform menu results.
Given that users
Plotting the total percentage of technically unnecessary button presses that menu mode user are making per trial, the results are shocking, especially when compared to the percentage of zoom-outs that direct mode users make. In the beginning, the majority of button presses novices make are information inefficient, and even after an hour or two of practice, many users, including experts, are still using 20 - 40% of their button presses inefficiently!
By comparing the percentage of the total information inefficient button presses zoom-outs in direct mode (i.e. the percentage of zoom-outs shown above) to the following plots showing the total number of information inefficient button pushes made by menu modes users, it's easy to see why Direct Dasher users are performing so much better.
This may not even be the full story; with experience, Direct Dasher users seem to begin to use the occasional information inefficient zoom out to help them write faster. Instead of navigating directly to a target string of characters by a completely information efficient series of buttons like, say, {up down down up down down up up}, more experienced direct users tend to learn to use the back-up button to align the target text such that they can navigate towards it by only changing zoom-in buttons once, like, say, {back up up up up up up up up down}. Thus, direct mode users seem to be able to write more quickly by aligning their target text between the two halves of the screen in a favourable way, even when this means using theoretially information inefficient gestures.
Next trials under consideration