This site will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device.


Home




Logo

Button Dasher

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:

  • B=4, r=44: p ={0.40,0.26,0.19,0.13}
  • B=4, r=88: p = {0.33,0.24,0.17,0.12,0.09,0.06}
  • B=6, r=44: p = {0.50,0.25,0.12,0.06,0.029,0.026}
  • B=6, r=88: p = {0.54,0.25,0.13,0.06}

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.

Uwpm.png (3659 bytes) N1bps.png (3623 bytes) N2wpm.png (3961 bytes) Dwpm.png (3255 bytes) D2wpm.png (4061 bytes)

 

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.

 

Ubps.png (3533 bytes) N1bps.png (3623 bytes) N2bps.png (3887 bytes) D2bps.png (3264 bytes)

 

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.

 

Ue.png (3496 bytes) N1e.png (3359 bytes) N2e.png (3403 bytes) De.png (3372 bytes) D2e.png (3316 bytes)

 

Information inefficient button pressing

  • Loops

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.

Ul.png (3579 bytes) N1l.png (3674 bytes) N2l.png (3806 bytes)

 

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.

  • Backing up

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.

 

Uz.png (3857 bytes) N1z.png (3949 bytes) N2z.png (4665 bytes) Dz.png (3073 bytes) D2z.png (3469 bytes)
  • Total information inefficient button presses for Menu Dasher users

Given that users don't stop making unnecessary loops, direct users have the clear advantage of not ever needing to loop. The only information inefficient button press a direct mode user can make is a one-button press that zooms out when a mistake is made. Menu users must also zoom out to correct errors, and the cost for their zoom-outs is again proportional to the number of selection boxes available. Thus, menu users have two possible ways of making inefficient navigating decisions, and each of these costs them a factor of B more button presses than the direct mode 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.

Ui.png (4395 bytes) N1i.png (4462 bytes) N2i.png (5150 bytes)

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

  • Direct mode, expert users, s=0, Austen training text, updated software. In previous user trials, the same passages from Emma were used as dictation tasks and Dasher was trained using the remaining portion of the novel. In these trials, Dasher was trained using a corpus consisting of text of different genres taken from a wide variety of sources. The results therefore do not represent the upper bounds on the writing speeds that learning or experienced users can achieve. It is also expected that results will improve given software modifications which remove disorienting screen flashes and allow users to click more quickly. It would be useful to determine the maximum writing speeds and information rates attainable.
  • Chris mode, novice & expert users. When an expert user spent 10 minutes using Direct Dasher with no safety margin and a very large non-uniformity, information rates and writing speeds were comparable to Direct Dasher results. This suggests a two-button adaptation of Direct Dasher in which one of the zoom-in buttons is controlled by Dasher, leaving the user to control the zoom-out button and the timing of one zoom-out button.
  • Direct or Chris mode, variable safety margin. For the purpose of these trials, the safety margin was set somewhat arbitrarily. Making this overlap smaller would theoretically increase information efficiency, but may cause problems when users can't distinguish on which side of a boundary their desired text sits. More work should be done to quantify exactly how small this overlap can be before it has a negative effect on user performance. Theoretically, the performance of the above users would improve by 7% if the safety margin could be set to zero.
  • Menu mode, B=2.  It was initially thought that one of the advantages of the direct mode was that it would operate essentially as a two-button mode, relying primarily on only the two zooming-in buttons with the third button used only rarely. As this third button is turning out to be an important feature in direct mode, it could be interesting to reconsider ways in which users who can't perform time-critical tasks could most effectively communicate with only two buttons.
  • Compass mode. A four-button mode allows users to navigate in both dimensions of the Dasher canvas.