Hi, > Will be cool if we can take dasher and run with the concept. For > some languages and usage patterns it makes a lot more sense than > keyboard input.
Given that we employ someone who worked as the lead Dasher developer full-time for two years, it's quite possible. :) > (OTOH, it's extremely awkward for other stuff - like programming! > And I do suspect that dasher is a big battery hog too.) Yes, repeatedly calculating probabilities for nodes while you zoom in uses lots of CPU. That said, we had it running totally smoothly on 100MHz iPaqs five years ago.. The main problems with Dasher will be: * the visual/cognitive load from the zooming metaphor * the time-critical nature of typing (not present at all with an on-screen keyboard) * the requirement to understand tree structures -- ie. "I want to write 'chair', so I have to find the r inside the i inside the a inside the h inside the c, and no other path containing the same letters will do." This kind of hierarchy turns out to be a way of thinking that doesn't come easily to many people. For those reasons, I wouldn't encourage Dasher as a panacea here. As an optional input method, though, it can be much faster than hunt and peck on an on-screen keyboard after some practice. Here we compared an eyetracker with Dasher to an eyetracker with an on-screen keyboard, finding that Dasher was faster with fewer errors: http://www.inference.phy.cam.ac.uk/dasher/presentations/Closing05/mgp00021.html - Chris. -- Chris Ball <[EMAIL PROTECTED]> _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel