Re: [SHR] illume predictive keyboard is too slow - Usability features
On Tue, 03 Feb 2009 20:15:53 +0100 Marco Trevisan (Treviño) m...@3v1n0.net said: Carsten Haitzler (The Rasterman) wrote: On Mon, 02 Feb 2009 21:53:26 +0100 Marco Trevisan (Treviño) m...@3v1n0.net said: However in the past days I sent you privately also a mail about some issues of the keyboard in latest e17 svn [1], but I got no answer. Maybe the mail wasn't sent correctly?! got it - i just tend to ignore some of my mailboxes for a while and cycle around to them... got a lot of email here :) i'll get back to you on it. it just is that kbd isnt a focus at the moment so it tends to take a back-burner position. Ah, ok... It's understandable... They seem unrelated, but why not workarounding them by allowing these actions only after a small timeout (i.e. waiting few ms from the latest char pressure)? so lets say 0.4 sec after the last keyboard key press it will allow for swipes and match hits etc. that could be done. again - tuning a timing value. will people then complain that :i often try and swipe or hit a match and it doesnt respond. i need to do it again?. h. Maybe 0.4 seconds is too much. I think that we could use a lower value too. And maybe configurable directly from the keyboard (also if I don't think that this is needed at all). Generally you never confirm a word or switch keyboard as fast as you type over a char (since typing can be un-precise thanks to the keyboard correction, switching a keyboard or selecting a word must be precise)... correct. it's a fine line to walk tho - as above :) And... What about making the horizontal word list (the one over the keys) scrollable [right-left] as the configuration toolbar is? Would it require more computation? I figure that that could improve the usability. no - it'd be not much of a problem - i just didnt do it. :) Ok, so please put it in your/illume TODO :P :) nb - i can see why you often hit a match word. your kbd layout doesnt have padding ABOVE the qwerty line like the default does... :) Yes. That's true. But people could have also keyboards with more keys than the mine (see Norwegians :P), and make the words-list and the keys closer. The fact is that also using the default qwerty keyboard, that has more padding, it could happen to hit a word if you're writing while walking/driving[ehm... :P]/talking (or simply writing quickly)... Don't you agree? oh indeed it can happen.. but its much less likely - it never has happened to me, thus why i think its probably ok. but with that padding removed on your kbd, i can see how it becomes much more probable you hit these things at the top. you should just add more padding :) the problem is the kbd wont resize per layout atm so the default determines the size so if yours is the default then just make sure it has padding and the problem should go away. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] illume predictive keyboard is too slow - Usability features
Carsten Haitzler (The Rasterman) wrote: On Wed, 28 Jan 2009 18:59:32 +0100 Marco Trevisan (Treviño) m...@3v1n0.net said: Maybe using something like a trie [1] to archive the words could help (both for words matching and for compressing the dictionary). Too hard? [1] http://en.wikipedia.org/wiki/Trie so back to the trie... the trie would only be useful for the ascii matching - i need something more complex. it just combines the data with the match tree (letters are inline). i need a match tree + lookup table to other matches to display - and possibly several match entries (all the matches to display also need to be in the tree pointing to a smaller match list). Ok, thanks... I got it. However I hope we could have made something that is based on that idea (the trie) but that can be applied to non ascii-chars too. However in the past days I sent you privately also a mail about some issues of the keyboard in latest e17 svn [1], but I got no answer. Maybe the mail wasn't sent correctly?! However I've wrote there also some features that I'd suggest to implement in the Illume keyboard. I'll write them here too to make the community aware: I use the illume keyboard every day and I'm very happy with it as I've said many times in this ML, but sometimes it happens that it performs some unwanted actions like: - I involuntarily click on a suggested word while I'm still typing my word (cause I'm not too precise I tap over a word, instead of a top char). - It happens that I got my keyboard switched while typing (yes, I know that this mainly an hardware-related issue, due to the touchscreen jitters). They seem unrelated, but why not workarounding them by allowing these actions only after a small timeout (i.e. waiting few ms from the latest char pressure)? Generally you never confirm a word or switch keyboard as fast as you type over a char (since typing can be un-precise thanks to the keyboard correction, switching a keyboard or selecting a word must be precise)... And... What about making the horizontal word list (the one over the keys) scrollable [right-left] as the configuration toolbar is? Would it require more computation? I figure that that could improve the usability. Bye. [1] http://i43.tinypic.com/i4il2d.png -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] illume predictive keyboard is too slow - Usability features
On Mon, 02 Feb 2009 21:53:26 +0100 Marco Trevisan (Treviño) m...@3v1n0.net said: Carsten Haitzler (The Rasterman) wrote: On Wed, 28 Jan 2009 18:59:32 +0100 Marco Trevisan (Treviño) m...@3v1n0.net said: Maybe using something like a trie [1] to archive the words could help (both for words matching and for compressing the dictionary). Too hard? [1] http://en.wikipedia.org/wiki/Trie so back to the trie... the trie would only be useful for the ascii matching - i need something more complex. it just combines the data with the match tree (letters are inline). i need a match tree + lookup table to other matches to display - and possibly several match entries (all the matches to display also need to be in the tree pointing to a smaller match list). Ok, thanks... I got it. However I hope we could have made something that is based on that idea (the trie) but that can be applied to non ascii-chars too. However in the past days I sent you privately also a mail about some issues of the keyboard in latest e17 svn [1], but I got no answer. Maybe the mail wasn't sent correctly?! got it - i just tend to ignore some of my mailboxes for a while and cycle around to them... got a lot of email here :) i'll get back to you on it. it just is that kbd isnt a focus at the moment so it tends to take a back-burner position. However I've wrote there also some features that I'd suggest to implement in the Illume keyboard. I'll write them here too to make the community aware: I use the illume keyboard every day and I'm very happy with it as I've said many times in this ML, but sometimes it happens that it performs some unwanted actions like: - I involuntarily click on a suggested word while I'm still typing my word (cause I'm not too precise I tap over a word, instead of a top char). thats a problem. mostly of spacing. its actually hard to figure that out. i really dont know what to do there - if u reduce the hit area for matches - it gets harder to select them. if i add more spacing you lose more screen to the kbd. somewhere someone loses. it's a matter of fine adjustments i guess in the spacing to add more space. - It happens that I got my keyboard switched while typing (yes, I know that this mainly an hardware-related issue, due to the touchscreen jitters). hmm thats hard to do. either u make swipes less sensitive and thus make it harder to change layout and solve your problem, or you live with the occasional swipe... or we have another way to change layout thats easy. They seem unrelated, but why not workarounding them by allowing these actions only after a small timeout (i.e. waiting few ms from the latest char pressure)? so lets say 0.4 sec after the last keyboard key press it will allow for swipes and match hits etc. that could be done. again - tuning a timing value. will people then complain that :i often try and swipe or hit a match and it doesnt respond. i need to do it again?. h. Generally you never confirm a word or switch keyboard as fast as you type over a char (since typing can be un-precise thanks to the keyboard correction, switching a keyboard or selecting a word must be precise)... correct. it's a fine line to walk tho - as above :) And... What about making the horizontal word list (the one over the keys) scrollable [right-left] as the configuration toolbar is? Would it require more computation? I figure that that could improve the usability. no - it'd be not much of a problem - i just didnt do it. :) nb - i can see why you often hit a match word. your kbd layout doesnt have padding ABOVE the qwerty line like the default does... :) Bye. [1] http://i43.tinypic.com/i4il2d.png -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
