information efficient text enty using dasher

Ben Burdette bburdette at comcast.net
Wed May 30 03:51:16 CEST 2007


> Dasher is only really information efficient considering the input only.
> The output stream needs to be quite dense.
>
> This pretty much means that you have to stare at the display all the time
> when inputting text.
> Sure - in theory, dasher may approach arithmetic coding in terms of
> information input.
> But unless you can do the coding in your head, you've got to stare at the
> screen, making it less useful for environments where you've got vibration,
> sunlight, walking down the street, or less likely for a phone, if you're
> blind. (Hmm. /me ponders dasher with audio prompting)
> T9 or even abc def ... you can use blind.
> Even qwerty with real hardware keys. (I think on-screen keyb would be
> optimistic :) )
>
>   

To me, it looks like Dasher has a some drawbacks:

one, it seems to be CPU intensive - there's a lot of animation going on 
during text entry.  Not a problem for PCs, but it might not be optimal 
on a low power device.

two, its storage intensive.  You have to have a dictionary of some sort 
available for it to do its prediction.  Or, several dictionaries, each 
for a different type of text entry (like english and japanese, or 
english and C++ programming).

three, it takes up a lot of screen space.  If you are just doing pure 
text entry without needing to look at something else, that's ok.  But 
I'd rather it didn't take up the whole screen so that I can't see an IM 
that I'm replying to, or several lines of the website form I'm filling 
out. 

That's not to say I'm against Dasher.  But I'd like to see a lot of 
flexibility available in openmoko text entry so that I can change to 
dasher, or some other text entry method when needed, or just to try 
things out.  I hope someone will implement it for openmoko, together 
with several other alternatives for doing text entry. 




More information about the community mailing list