Button Dasher

• Paper describing four new ways of using Dasher with buttons.

  dasherButtons.ps.gz. dasherButtons.pdf. abstract. | <- UK | Canada -> | dasherButtons.ps.gz. dasherButtons.pdf. abstract.

  ` Efficient communication through one or two buttons '.
  by David MacKay, Chris Ball, and Mick Donegan.

• Sketch of the menus for selecting among these control modes

Notes on the new subroutines added to Dasher for button mode

The core zooming function of regular Dasher involves the following sequence of subroutines[in files shown]

 TapOn[DasherInterface]
   -> TapOnDisplay [DasherViewSquare]
      -> Tap_on_display[DasherModel]
   -> Render
	DrawMouse
	Display
   -> NewFrame 
 

 GoTo[DasherInterface]
                                 which calls
 MultiStepGoTo[DasherInterface]
   -> PlanGoTo [DasherViewSquare]
       -> PlanGoTo [DasherModel]
   Loop through iSteps{
   -> StepGoTo [DasherViewSquare]
       -> NewGoTo [DasherModel]
   -> Render
   -> Display
   }
   -> FinalGoTo [DasherViewSquare]
       -> NewGoTo [DasherModel]
   -> Render
   -> Display
 

More notes on static one-button mode

It is important that we exploit the full accuracy of the user's click timing. It is very likely that their accuracy is similar to, or possibly even smaller than, the time between successive renderings of the falling pointer. It's thus essential, I think, that we keep track of the actual TIME of the click event, relative to the last rendering time, in order to get SUPERRESOLUTION of the mousey coordinate.

So the code should look something like this:

set pointer coordinate
render the pointer at y1
note the time t1
decide where the next pointer will be rendered y2, and
estimate the time t2 at which that will happen

IF ( click event happens )
        Note time t at which click event happened
        Define
                y = (t-t1) * y2 + (t2-t) * y1
                    -------------------------
                            t2-t1
			    
        Initiate zoom in on location y.


                (Special case event handling:
                if t>t2, declare t=t2, before doing the y formula;
                and if a click occurs before we have rendered the first
                pointer at y1=CANVAS_TOP, declare y=CANVAS_TOP)

During a zoom: When the above computation of "y" has occurred, I think it will be very helpful to the user to see visualized on the screen a splat mark that shows WHERE Y WAS. That way, they will learn whether they clicked earlier or later than they intended. I think a good way to do this will be to create a new routine called draw_splat_at_dasher_coordinate_y(dashery) .

The way this will work is: when the zoom is initiated, my GoTo routine, which receives dashery (which has been put through screen2dasher) remembers that dashery value, and, every time it does a Render and Display, it will also Draw a splat object (which should be an object that looks just like the pointer arrow object, except maybe it could have a different colour, like red) at that dashery coordinate (appropriately mapped through dasher2screen). Because a zoom is busy happening, the splat object won't be rendered at the same canvas y coordinate as the click happened - indeed, during the zoom, it will be rendered at a sequency of positions that drift to the CENTRE of the screen, because of the zoom being a zoom-in-on y.

I'd like there to be two objects, a splat object that GoTo knows about and renders, and the regular bouncing pointer, which is not rendered during the zoom event (or else is rendered at CANVAS_TOP during every frame of the zoom), and which is another piece of code's responsiblity. The regular bouncing pointer should be reset to CANVAS_TOP when the zoom event is started.

Wed 11/8/04

Some handwritten notes on Dasher code are here