Re: Virtual QWERTY Keyboards to be used with Fingers...
On Mon, 07 Apr 2008 01:31:03 +0200 "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> babbled: > Carsten Haitzler (The Rasterman) wrote: > > interesting you mention this. i actually thought of using aspell as the > > core of a probability and correction matching engine, but as such it's api > > isn't sufficient to use it. > > That was my idea/hope too... > > so anyway- aspell would have been great - it'd offload the matching to a > > library designed for this kind of stuff, but alas, it's api is not > > sufficient, so i need to do a custom one. :( > > I agree with your ':('... :P > BTW maybe the aspell data (dictionaries) could be used, isn't it? I hope > it will be possible to have some compatibility with it since it's the > most used correction tool on open systems, and this would allow to use > the many resources that are already available for it without creating > them (again) from scratch. i'd love to - but i need to do this fast. no moretime to look. what i need from aspell api-wise is a: "do any words start with "age" for example (not just does this match anything in the dictionary). in fact that is all i need - start with... :) right now it's probably faster/easier for me to just take /usr/share/dict/words and turn that into a binary file i can mmap and quickly search (or build an index file into the words file for lookups). we can look at aspell later. this would be a worthy api to add to aspell. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Carsten Haitzler (The Rasterman) wrote: interesting you mention this. i actually thought of using aspell as the core of a probability and correction matching engine, but as such it's api isn't sufficient to use it. That was my idea/hope too... so anyway- aspell would have been great - it'd offload the matching to a library designed for this kind of stuff, but alas, it's api is not sufficient, so i need to do a custom one. :( I agree with your ':('... :P BTW maybe the aspell data (dictionaries) could be used, isn't it? I hope it will be possible to have some compatibility with it since it's the most used correction tool on open systems, and this would allow to use the many resources that are already available for it without creating them (again) from scratch. -- 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: Virtual QWERTY Keyboards to be used with Fingers...
On Thu, 27 Mar 2008 21:41:24 +0100 "Flemming Richter Mikkelsen" <[EMAIL PROTECTED]> babbled: > On 3/1/08, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > On Fri, 29 Feb 2008 18:50:14 +0100 "Marco Trevisan (Treviño)" > > <[EMAIL PROTECTED]> i WANT to type "waste". > > > > i press w - but really my finger may easily hit q,e,a or s - maybe even r, > > d, z or t. as such every key has a center point. my finger will try and > > press somewhere close to this center, but may fail and be closer to > > something else. distance from the center point of a key will be the > > probability that you wanted that key. for practical computation u need to > > have a cutoff of X pixels away and ignore any possibilities greater than > > that, so then u press another key. now u are close to 1 key - but also to > > others. so as you type you get something like (a key, then a closeness > > value from 1 to 9 lets say, where 9 is the closest. closeness is just a > > measure of distance - inverted): > > I really like this idea. I think it should also use aspell (a great > dict. with many words in many languages) in combination with a user > dictionary. interesting you mention this. i actually thought of using aspell as the core of a probability and correction matching engine, but as such it's api isn't sufficient to use it. you need to be able to quickly eliminate probability sequences letter by letter, otherwise your "possible matches" space is so huge it'll never compute the corrected word. as such though, a corrective keyboard is doing spelling correction for you anyway - it needs to just to be able to correct the inaccurate typing :) so anyway- aspell would have been great - it'd offload the matching to a library designed for this kind of stuff, but alas, it's api is not sufficient, so i need to do a custom one. :( -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On 3/1/08, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Fri, 29 Feb 2008 18:50:14 +0100 "Marco Trevisan (Treviño)" <[EMAIL > PROTECTED]> > i WANT to type "waste". > > i press w - but really my finger may easily hit q,e,a or s - maybe even r, d, > z > or t. as such every key has a center point. my finger will try and press > somewhere close to this center, but may fail and be closer to something else. > distance from the center point of a key will be the probability that you > wanted > that key. for practical computation u need to have a cutoff of X pixels away > and ignore any possibilities greater than that, so then u press another key. > now u are close to 1 key - but also to others. so as you type you get > something > like (a key, then a closeness value from 1 to 9 lets say, where 9 is the > closest. closeness is just a measure of distance - inverted): I really like this idea. I think it should also use aspell (a great dict. with many words in many languages) in combination with a user dictionary. -- Please don't send me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Join the FSF as an Associate Member at: http://www.fsf.org/register_form?referrer=5774> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Lorn Potter wrote: On Monday 03 March 2008, Karsten Ensinger wrote: [...] Survey (after half an hour of testing and three complete screen lockups): I don't want to put down the implementation of the Qtopia keyboard at all. I have much respect for the quality one can see. But to me it seems as if the keyboard was not designed for finger use in first place. A "hit rate" of 90 percent (when using an adult fingertip) is barely acceptable. Actually it was. You only have to come close to a letter to select one. It tries to guess what word you are wanting, as well as looking at the letters in the general area of your finger pressing. If you do not like the predictive feature, then you can hold down on a letter to select only that one. The usage is not yet intuitive (how to do a backspace, a delete, use upper case letters, use special characters (like @,$,&,/)?) move your finger up or down to get to get to caps, numbers and symbols. backspace is moving your finger from right to left. and due to the "look alike" of a regular "hardware" keyboard and the expectations caused by this, the frustration is high, when one can not handle simple things without looking for help (is there a helpfile for the keyboard input? I only found help for the application itself but not for the usage of the keyboard). There should be yes. But looking at the input method help from the menu I am not seeing it. I will look into this and make sure it gets fixed. Maybe you should think about a small question mark somewhere on the edges of the keyboard, so one can press it to get help on the input methods. [...] Maybe I am too biased, but most of the critics we discussed months ago became manifest in this implementation of a screen keyboard. It is smart, but needs "tricks" to handle the problems of imprecise finger touches, lack of screen space for great numbers of keys and fault tolerance. This leads to a learning curve one has to master before being able to use the keyboard as such. A qwerty keyboard also has a learning curve at first. Ever tried graffiti input? Today, nearly everyone has some small experiences with qwerty keyboards. So this learning curve is not an issue here. It is more the opposite, due to the differences (advantages?) in handling. Unfortunately one has to use "tricks" (finger movements) instead of keys (like shift, ctrl or alt) to get to additional characters in Qtopia and this contradicts to the usage of a regular qwerty keyboard. I do NOT want to say that this is bad at all, but you have to get the user an extremely easy way to get help on your "tricks" to prevent frustration at the first usage (this is based on my own experience with Qtopia, where I had no assistance by others, but was left by my own. It was EXTREMELY frustrating to feel like a complete fool due to not being able to delete a typed character or to switch to another layer of characters, even though I do have used computers for more than 25 years (but maybe this 25 years also were the cause :-) )). Maybe you should think about the suggestion to place a "help" key on the keyboard itself. At least, every first time user will be very thankful. And yes, I do have used graffiti input. I used a Palm for several years and it took me some weeks to switch from the "regular" keyboard to the graffiti input. If the user has to master a learning curve anyway, why not take a completely different approach, which is designed exactly for the problems first and foremost? If the approach is different enough, the user will accept/expect a learning curve (and will tolerate it, if it is not too steep). Knowing four things for the predictive keyboard in Qtopia will get you going. 1) tap on the letters like normal, a word, or words will appear, you have to tap on the word to enter that in whatever text you are inputting. 2) slide your finger up and down to switch caps, undercase, numbers and symbols. 3) slider your finger right to left to backspace 4) to select a letter without the word prediction, hold down your finger over a letter. You can even rotate your finger to select letters around it if it detected the wrong one. Is that a too high learning curve? No it is not. But one has to be able to get this information "on a fingertip" and not by searching a help database or asking at a user forum. :-) Using only a finger, the predictive keyboard cannot be beat. Qtopia also has handwriting and a 'normal' qwerty keyboard with the use of a stylus. Someone has also gotten dasher running. Although I DO think that the predictive keyboard can be beat in terms of intuitivity (does this word exist?), I will give it another try in terms of usability. So I will give Qtopia another try and do revise my report/opinion if necessary. Regards Karsten ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Monday 03 March 2008, Karsten Ensinger wrote: > Then I started Qtopia (without a SIM card inserted) and had a look > at the notes application (this was the first application I found > which offers text input). > The keyboard contained only lower case characters and there was no > obvious way to get upper case letters. I was also missing a > possibility to remove mistyped characters. > So the first impression was: an "intuitive user interface" looks > different to me. > Although the character distance was very small, I managed to get > a "hit rate" of more than 90 percent for hitting the intended > "key". > The word prediction was great when writing simple english stuff, > but absolutely useless, when typing german. In addition to this, > it missed most of the complicated english vocabulary I tried. > I could not find a way to switch a dictionary, so this was not > an option. > > > Survey (after half an hour of testing and three complete screen > lockups): > I don't want to put down the implementation of the Qtopia > keyboard at all. I have much respect for the quality one can > see. > But to me it seems as if the keyboard was not designed for finger > use in first place. A "hit rate" of 90 percent (when using an adult > fingertip) is barely acceptable. Actually it was. You only have to come close to a letter to select one. It tries to guess what word you are wanting, as well as looking at the letters in the general area of your finger pressing. If you do not like the predictive feature, then you can hold down on a letter to select only that one. > The usage is not yet intuitive (how to do a backspace, a delete, > use upper case letters, use special characters (like @,$,&,/)?) move your finger up or down to get to get to caps, numbers and symbols. backspace is moving your finger from right to left. > and due to the "look alike" of a regular "hardware" keyboard and > the expectations caused by this, the frustration is high, when > one can not handle simple things without looking for help > (is there a helpfile for the keyboard input? I only found help > for the application itself but not for the usage of the keyboard). There should be yes. But looking at the input method help from the menu I am not seeing it. I will look into this and make sure it gets fixed. > > The GUI of Qtopia itself looks very impressive from a design > point of view. But I am missing something like a bubble-help > (e.g. press and hold a key and get a small hint of what the > meaning of the key is), although this is not specific to Qtopia > but is missing in Openmoko also. It is NOT always true that > a picture says more than a thousand words (at least not pictures > of 64x64 pixels). > > Maybe I am too biased, but most of the critics we discussed > months ago became manifest in this implementation of a screen > keyboard. It is smart, but needs "tricks" to handle the problems > of imprecise finger touches, lack of screen space for great numbers > of keys and fault tolerance. This leads to a learning curve one > has to master before being able to use the keyboard as such. A qwerty keyboard also has a learning curve at first. Ever tried graffiti input? > If the user has to master a learning curve anyway, why not take a > completely different approach, which is designed exactly for the > problems first and foremost? If the approach is different enough, > the user will accept/expect a learning curve (and will tolerate it, > if it is not too steep). Knowing four things for the predictive keyboard in Qtopia will get you going. 1) tap on the letters like normal, a word, or words will appear, you have to tap on the word to enter that in whatever text you are inputting. 2) slide your finger up and down to switch caps, undercase, numbers and symbols. 3) slider your finger right to left to backspace 4) to select a letter without the word prediction, hold down your finger over a letter. You can even rotate your finger to select letters around it if it detected the wrong one. Is that a too high learning curve? Using only a finger, the predictive keyboard cannot be beat. Qtopia also has handwriting and a 'normal' qwerty keyboard with the use of a stylus. Someone has also gotten dasher running. -- Lorn 'ljp' Potter Software Engineer, Systems Group, MES, Trolltech ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, Mar 1, 2008 at 12:47 AM, Karsten Ensinger <[EMAIL PROTECTED]> wrote: > Sorry to jump into the thread this late, but I am wondering > if you already examined the following Wiki-Link? > We had a very extensive discussion about text input running > on the community list several months ago. > Nearly all proposals were documented on the following Wiki: > > http://wiki.openmoko.org/wiki/Wishlist:Text_Input > > My personal favourites are the Quickwriting (there is even > a java demo available) and "another text input" (although > it seems to be another implementation of this more moko-like > implementation: http://www.micropp.se/openmoko/splash.html ). I think for the finger use case, Raster's idea sounds very well thought-out, especially the part about choosing the dictionary according to context and selecting most-likely words or commands. I just hope we don't end up infringing any Apple patents. :-) I think the keyboard should have fewer and larger keys though; the one in the November release has such tiny ones that you can hardly read them. There's nothing wrong with switching to another view to get the "extra" keys (e.g. any punctuation beyond period, comma and @-sign) as long as the switching is easy. For the stylus case, I like this one: http://www.strout.net/info/ideas/hexinput.html and after implementing a prototype I think I like the experience of using it, too. It is something extra to learn, though, and one is not always using a stylus. In the end it should be possible to implement various kinds of entry methods, and people will have their preferences about which one to actually use. The teenagers know T9 pretty well nowadays (can type without looking) but that's on a tactile keyboard, not a touchscreen. Goes to show how adaptable people are, I guess. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Virtual QWERTY Keyboards to be used with Fingers...
To change between character types on the keyboard flick on the keyboard up or down. To backspace drag across the keyboard back. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karsten Ensinger Sent: Monday, March 03, 2008 5:31 AM To: List for OpenMoko community discussion Cc: "Marco Trevisan (Treviño)" Subject: Re: Virtual QWERTY Keyboards to be used with Fingers... Marco Trevisan (Treviño) wrote: > Karsten Ensinger ha scritto: >> I am afraid, I have to admit that I have NOT tried the Trolltech stuff >> at all. Maybe because I thought I would deceive the openmoko movement >> by trying "other" stuff on the Neo. ;-) >> I will give it a try until next weekend and will change my mind if >> it is as cool as you claim. > > Ok, we're waiting for your report...! > OK, I installed the latest reviewed u-boot, kernel and rootfs. Then I tried to install Qtopia on the SD-Card. Unfortunately every "scp" failed (even if my laptop "thought" it was successful). I made some test and dicovered that it was possible to copy arbitrary stuff from flash to SD-Card but not via USB->scp. I tried to format the SD-Card, but after successful (means: no error messages) formatting, it was impossible to mount the SD-Card. Even my laptop (Ubuntu based) denied to mount the SD-Card then. Lucky me, a new build appeared at buildhost and I tried the latest and greatest u-boot, kernel and rootfs. SD-Card could be formatted without any problem and even "scp" succeeded this time. I followed the instructions on the wiki and configured the Qtopia stuff for manual starting. Then I started Qtopia (without a SIM card inserted) and had a look at the notes application (this was the first application I found which offers text input). The keyboard contained only lower case characters and there was no obvious way to get upper case letters. I was also missing a possibility to remove mistyped characters. So the first impression was: an "intuitive user interface" looks different to me. Although the character distance was very small, I managed to get a "hit rate" of more than 90 percent for hitting the intended "key". The word prediction was great when writing simple english stuff, but absolutely useless, when typing german. In addition to this, it missed most of the complicated english vocabulary I tried. I could not find a way to switch a dictionary, so this was not an option. Survey (after half an hour of testing and three complete screen lockups): I don't want to put down the implementation of the Qtopia keyboard at all. I have much respect for the quality one can see. But to me it seems as if the keyboard was not designed for finger use in first place. A "hit rate" of 90 percent (when using an adult fingertip) is barely acceptable. The usage is not yet intuitive (how to do a backspace, a delete, use upper case letters, use special characters (like @,$,&,/)?) and due to the "look alike" of a regular "hardware" keyboard and the expectations caused by this, the frustration is high, when one can not handle simple things without looking for help (is there a helpfile for the keyboard input? I only found help for the application itself but not for the usage of the keyboard). The GUI of Qtopia itself looks very impressive from a design point of view. But I am missing something like a bubble-help (e.g. press and hold a key and get a small hint of what the meaning of the key is), although this is not specific to Qtopia but is missing in Openmoko also. It is NOT always true that a picture says more than a thousand words (at least not pictures of 64x64 pixels). Maybe I am too biased, but most of the critics we discussed months ago became manifest in this implementation of a screen keyboard. It is smart, but needs "tricks" to handle the problems of imprecise finger touches, lack of screen space for great numbers of keys and fault tolerance. This leads to a learning curve one has to master before being able to use the keyboard as such. If the user has to master a learning curve anyway, why not take a completely different approach, which is designed exactly for the problems first and foremost? If the approach is different enough, the user will accept/expect a learning curve (and will tolerate it, if it is not too steep). A car is not the adequate vehicle when travelling on a river, even though it is possible to adapt one. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Marco Trevisan (Treviño) wrote: Karsten Ensinger ha scritto: I am afraid, I have to admit that I have NOT tried the Trolltech stuff at all. Maybe because I thought I would deceive the openmoko movement by trying "other" stuff on the Neo. ;-) I will give it a try until next weekend and will change my mind if it is as cool as you claim. Ok, we're waiting for your report...! OK, I installed the latest reviewed u-boot, kernel and rootfs. Then I tried to install Qtopia on the SD-Card. Unfortunately every "scp" failed (even if my laptop "thought" it was successful). I made some test and dicovered that it was possible to copy arbitrary stuff from flash to SD-Card but not via USB->scp. I tried to format the SD-Card, but after successful (means: no error messages) formatting, it was impossible to mount the SD-Card. Even my laptop (Ubuntu based) denied to mount the SD-Card then. Lucky me, a new build appeared at buildhost and I tried the latest and greatest u-boot, kernel and rootfs. SD-Card could be formatted without any problem and even "scp" succeeded this time. I followed the instructions on the wiki and configured the Qtopia stuff for manual starting. Then I started Qtopia (without a SIM card inserted) and had a look at the notes application (this was the first application I found which offers text input). The keyboard contained only lower case characters and there was no obvious way to get upper case letters. I was also missing a possibility to remove mistyped characters. So the first impression was: an "intuitive user interface" looks different to me. Although the character distance was very small, I managed to get a "hit rate" of more than 90 percent for hitting the intended "key". The word prediction was great when writing simple english stuff, but absolutely useless, when typing german. In addition to this, it missed most of the complicated english vocabulary I tried. I could not find a way to switch a dictionary, so this was not an option. Survey (after half an hour of testing and three complete screen lockups): I don't want to put down the implementation of the Qtopia keyboard at all. I have much respect for the quality one can see. But to me it seems as if the keyboard was not designed for finger use in first place. A "hit rate" of 90 percent (when using an adult fingertip) is barely acceptable. The usage is not yet intuitive (how to do a backspace, a delete, use upper case letters, use special characters (like @,$,&,/)?) and due to the "look alike" of a regular "hardware" keyboard and the expectations caused by this, the frustration is high, when one can not handle simple things without looking for help (is there a helpfile for the keyboard input? I only found help for the application itself but not for the usage of the keyboard). The GUI of Qtopia itself looks very impressive from a design point of view. But I am missing something like a bubble-help (e.g. press and hold a key and get a small hint of what the meaning of the key is), although this is not specific to Qtopia but is missing in Openmoko also. It is NOT always true that a picture says more than a thousand words (at least not pictures of 64x64 pixels). Maybe I am too biased, but most of the critics we discussed months ago became manifest in this implementation of a screen keyboard. It is smart, but needs "tricks" to handle the problems of imprecise finger touches, lack of screen space for great numbers of keys and fault tolerance. This leads to a learning curve one has to master before being able to use the keyboard as such. If the user has to master a learning curve anyway, why not take a completely different approach, which is designed exactly for the problems first and foremost? If the approach is different enough, the user will accept/expect a learning curve (and will tolerate it, if it is not too steep). A car is not the adequate vehicle when travelling on a river, even though it is possible to adapt one. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On 3/1/08 Karsten Ensinger wrote: Sean Moss-Pultz wrote: > On 3/1/08 Carsten Haitzler (The Rasterman) wrote: >> On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger >> <[EMAIL PROTECTED]> babbled: >> >> > > If I remember correctly, "all" participants of the discussion >> > > came to the conclusion, that a regular qwerty keyboard is not >> > > sufficient no matter how clever you "pimp" it, due to >> > > restriction of precision of finger typing and lack of screen >> > > space. >> >> i disagree. reality of the qtopia predictive keyboard and actual use of it >> disagrees. talk and theory is fine - actual code that works is disagreeing. >> users of that code are disagreeing. > > I have to agree with Raster here. Trolltech did an amazing job on their QWERTY (onscreen) keypad. I highly recommend you trying it out on the Neo if you haven't already. Personally, I think it's the best touchpanel keyboard on the market now. Bar none. > > Sean I am afraid, I have to admit that I have NOT tried the Trolltech stuff at all. Maybe because I thought I would deceive the openmoko movement by trying "other" stuff on the Neo. ;-) On the contrary. The Openmoko movement will only be wildly successful if great stuff is developed by others! Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, 01 Mar 2008 21:10:14 +0100 "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> babbled: > Carsten Haitzler (The Rasterman) ha scritto: > > thats why dictionaries can be added to, imported, words learnt automatically > > and added, etc. etc. :) > > I had also an idea about this... What about a dictionary-sharing using > internet? I mean a kind of repository of dictionaries that users could > integrate using their personal dictionaries that they've generated using > the phone itself. > The process of submission could be also automatized but - of course - > there are some privacy isses that should be considered! sure. i see no reason that over time such things could not be done. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On 3/1/08, Ortwin Regel <[EMAIL PROTECTED]> wrote: > On 3/1/08, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: > > On 3/1/08 Carsten Haitzler (The Rasterman) wrote: > > > On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger > > > <[EMAIL PROTECTED]> babbled: > > > > > > > > Sorry to jump into the thread this late, but I am wondering > > > > > if you already examined the following Wiki-Link? > > > > > We had a very extensive discussion about text input running > > > > > on the community list several months ago. > > > > > Nearly all proposals were documented on the following Wiki: > > > > > > > > > > http://wiki.openmoko.org/wiki/Wishlist:Text_Input > > > > > > > > > > My personal favourites are the Quickwriting (there is even > > > > > a java demo available) and "another text input" (although > > > > > it seems to be another implementation of this more moko-like > > > > > implementation: http://www.micropp.se/openmoko/splash.html ). > > > > > > > > > > If I remember correctly, "all" participants of the discussion > > > > > came to the conclusion, that a regular qwerty keyboard is not > > > > > sufficient no matter how clever you "pimp" it, due to > > > > > restriction of precision of finger typing and lack of screen > > > > > space. > > > > > > i disagree. reality of the qtopia predictive keyboard and actual use > > > of it > > > disagrees. talk and theory is fine - actual code that works is > > > disagreeing. > > > users of that code are disagreeing. > > > > I have to agree with Raster here. Trolltech did an amazing job on their > > QWERTY (onscreen) keypad. I highly recommend you trying it out on the > > Neo if you haven't already. Personally, I think it's the best touchpanel > > keyboard on the market now. Bar none. > > > > Sean > > > > Maybe it is. I still hate it and any other form of predictive text > input I have used so far. That doesn't mean I want to prevent anyone > else from having it. I can understand that some people are happy with > it and it would probably be a good idea to use it as the default input > method. What I want is an alternative I can very easily switch to. > > We don't want the perfect input method because it probably doesn't > exist. Let's agree on disagreeing and try to figure out a base set of > alternative input mechanisms that should be included in Openmoko as > well as making it easy for the user to install more of them. > > Some options I can think of that would find an audience: > -Predictive QWERTY, maybe with different prediction modes (dictionary, > closeness, combination, none) > -Multitap 3*4 standard phone layout (maybe with optional prediction if > patent issues can be avoided) > -Dasher > -A sliding method. My favorite, even though I never used one and don't > really know which of the ideas floating around will be the best one. > > The next thing to consider is size. There are basically two options: > -Use about 1/3 of the screen so that the running program is still > visible. The problem with this is that the space is very small and > some of the methods above would not work at this size or only work > with a stylus. > -Use pretty much the whole screen while inputting something and close > the input method afterwards. This worked very well on my Palm device > for two thumb landscape QWERTY input but that screen was twice as big > as the Neo's. It is my prefered way of doing input because I don't > need to see the program while typing. I only need to see about two > lines of the text I last typed. > For all methods where this makes sense, both sizes should be available. > > > Last, let me describe my imaginary perfect input method: > The input area is divided in 3*3 squares. A letter is written by > starting on a defined square and moving over one square to end in a > 3rd square. So every letter is a combination of 3 adjacent squares > drawn in the right direction. > Now here is what makes this fast and thus great: If the next letter > you want to draw starts on the square you just ended on, you simply > continue your slide and add two squares. This way, many letter > combinations and even whole words could be written in one continuos > sliding motion. > There are 44 possible combinations (if I counted right) which should > be plenty if we plan for a shift-combination and a numbers/special > characters-combination. > The character layout shouldn't follow any alphabet or QWERTY logic but > instead be entirely based on language. The reason is that it would > require learning from the ground up anyway so it should be as fast as > possible once you have learned it. > The small version for only taking up 1/3 of the screen would be > perfect in 2*5 which would also result in 44 combinations (again, if I > counted them right...). > Feedback and actual implementation of this would be very welcome! In > fact, I offer 30 Paypal €uros to the first person to make this work on > my Neo (meaning it has to come with simple installation instructions). > > Ortwin > Well, so I can't c
Re: Virtual QWERTY Keyboards to be used with Fingers...
On 3/1/08, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: > On 3/1/08 Carsten Haitzler (The Rasterman) wrote: > > On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger > > <[EMAIL PROTECTED]> babbled: > > > > > > Sorry to jump into the thread this late, but I am wondering > > > > if you already examined the following Wiki-Link? > > > > We had a very extensive discussion about text input running > > > > on the community list several months ago. > > > > Nearly all proposals were documented on the following Wiki: > > > > > > > > http://wiki.openmoko.org/wiki/Wishlist:Text_Input > > > > > > > > My personal favourites are the Quickwriting (there is even > > > > a java demo available) and "another text input" (although > > > > it seems to be another implementation of this more moko-like > > > > implementation: http://www.micropp.se/openmoko/splash.html ). > > > > > > > > If I remember correctly, "all" participants of the discussion > > > > came to the conclusion, that a regular qwerty keyboard is not > > > > sufficient no matter how clever you "pimp" it, due to > > > > restriction of precision of finger typing and lack of screen > > > > space. > > > > i disagree. reality of the qtopia predictive keyboard and actual use > > of it > > disagrees. talk and theory is fine - actual code that works is > > disagreeing. > > users of that code are disagreeing. > > I have to agree with Raster here. Trolltech did an amazing job on their > QWERTY (onscreen) keypad. I highly recommend you trying it out on the > Neo if you haven't already. Personally, I think it's the best touchpanel > keyboard on the market now. Bar none. > > Sean > Maybe it is. I still hate it and any other form of predictive text input I have used so far. That doesn't mean I want to prevent anyone else from having it. I can understand that some people are happy with it and it would probably be a good idea to use it as the default input method. What I want is an alternative I can very easily switch to. We don't want the perfect input method because it probably doesn't exist. Let's agree on disagreeing and try to figure out a base set of alternative input mechanisms that should be included in Openmoko as well as making it easy for the user to install more of them. Some options I can think of that would find an audience: -Predictive QWERTY, maybe with different prediction modes (dictionary, closeness, combination, none) -Multitap 3*4 standard phone layout (maybe with optional prediction if patent issues can be avoided) -Dasher -A sliding method. My favorite, even though I never used one and don't really know which of the ideas floating around will be the best one. The next thing to consider is size. There are basically two options: -Use about 1/3 of the screen so that the running program is still visible. The problem with this is that the space is very small and some of the methods above would not work at this size or only work with a stylus. -Use pretty much the whole screen while inputting something and close the input method afterwards. This worked very well on my Palm device for two thumb landscape QWERTY input but that screen was twice as big as the Neo's. It is my prefered way of doing input because I don't need to see the program while typing. I only need to see about two lines of the text I last typed. For all methods where this makes sense, both sizes should be available. Last, let me describe my imaginary perfect input method: The input area is divided in 3*3 squares. A letter is written by starting on a defined square and moving over one square to end in a 3rd square. So every letter is a combination of 3 adjacent squares drawn in the right direction. Now here is what makes this fast and thus great: If the next letter you want to draw starts on the square you just ended on, you simply continue your slide and add two squares. This way, many letter combinations and even whole words could be written in one continuos sliding motion. There are 44 possible combinations (if I counted right) which should be plenty if we plan for a shift-combination and a numbers/special characters-combination. The character layout shouldn't follow any alphabet or QWERTY logic but instead be entirely based on language. The reason is that it would require learning from the ground up anyway so it should be as fast as possible once you have learned it. The small version for only taking up 1/3 of the screen would be perfect in 2*5 which would also result in 44 combinations (again, if I counted them right...). Feedback and actual implementation of this would be very welcome! In fact, I offer 30 Paypal €uros to the first person to make this work on my Neo (meaning it has to come with simple installation instructions). Ortwin ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Karsten Ensinger ha scritto: I am afraid, I have to admit that I have NOT tried the Trolltech stuff at all. Maybe because I thought I would deceive the openmoko movement by trying "other" stuff on the Neo. ;-) I will give it a try until next weekend and will change my mind if it is as cool as you claim. Ok, we're waiting for your report...! -- 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: Virtual QWERTY Keyboards to be used with Fingers...
Sean Moss-Pultz wrote: On 3/1/08 Carsten Haitzler (The Rasterman) wrote: On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger <[EMAIL PROTECTED]> babbled: > > If I remember correctly, "all" participants of the discussion > > came to the conclusion, that a regular qwerty keyboard is not > > sufficient no matter how clever you "pimp" it, due to > > restriction of precision of finger typing and lack of screen > > space. i disagree. reality of the qtopia predictive keyboard and actual use of it disagrees. talk and theory is fine - actual code that works is disagreeing. users of that code are disagreeing. I have to agree with Raster here. Trolltech did an amazing job on their QWERTY (onscreen) keypad. I highly recommend you trying it out on the Neo if you haven't already. Personally, I think it's the best touchpanel keyboard on the market now. Bar none. Sean I am afraid, I have to admit that I have NOT tried the Trolltech stuff at all. Maybe because I thought I would deceive the openmoko movement by trying "other" stuff on the Neo. ;-) I will give it a try until next weekend and will change my mind if it is as cool as you claim. Regards ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On 3/1/08 Carsten Haitzler (The Rasterman) wrote: On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger <[EMAIL PROTECTED]> babbled: > > Sorry to jump into the thread this late, but I am wondering > > if you already examined the following Wiki-Link? > > We had a very extensive discussion about text input running > > on the community list several months ago. > > Nearly all proposals were documented on the following Wiki: > > > > http://wiki.openmoko.org/wiki/Wishlist:Text_Input > > > > My personal favourites are the Quickwriting (there is even > > a java demo available) and "another text input" (although > > it seems to be another implementation of this more moko-like > > implementation: http://www.micropp.se/openmoko/splash.html ). > > > > If I remember correctly, "all" participants of the discussion > > came to the conclusion, that a regular qwerty keyboard is not > > sufficient no matter how clever you "pimp" it, due to > > restriction of precision of finger typing and lack of screen > > space. i disagree. reality of the qtopia predictive keyboard and actual use of it disagrees. talk and theory is fine - actual code that works is disagreeing. users of that code are disagreeing. I have to agree with Raster here. Trolltech did an amazing job on their QWERTY (onscreen) keypad. I highly recommend you trying it out on the Neo if you haven't already. Personally, I think it's the best touchpanel keyboard on the market now. Bar none. Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger <[EMAIL PROTECTED]> babbled: > Sorry to jump into the thread this late, but I am wondering > if you already examined the following Wiki-Link? > We had a very extensive discussion about text input running > on the community list several months ago. > Nearly all proposals were documented on the following Wiki: > > http://wiki.openmoko.org/wiki/Wishlist:Text_Input > > My personal favourites are the Quickwriting (there is even > a java demo available) and "another text input" (although > it seems to be another implementation of this more moko-like > implementation: http://www.micropp.se/openmoko/splash.html ). > > If I remember correctly, "all" participants of the discussion > came to the conclusion, that a regular qwerty keyboard is not > sufficient no matter how clever you "pimp" it, due to > restriction of precision of finger typing and lack of screen > space. i disagree. reality of the qtopia predictive keyboard and actual use of it disagrees. talk and theory is fine - actual code that works is disagreeing. users of that code are disagreeing. > An "intelligent" input prediction (e.g. T9) sucks, when one > is using different languages regularly (you always have to > remember switching to the right dictionary BEFORE typing). > ( Not everyone on this planet is using english in day to day > conversations. ;-) ) sure - but t9 is ambiguous. it REQUIRES a lookup or multi-press (turn t9 off) to be useful. i was talking of an error correction system that uses dictionaries. if you use a stylus the error correction never needs to take place - if you use a finger it will be needed. but it doesn't predict. it corrects - much like a spell checker does. different from t9. the other keyboard entry methods there are much harder to learn to use. you add a barrier of entry for many people. if others wish to pursue these funky keyboard entries - please do. i don't intend to to start with. i intend todo a qwerty style keyboard with multiple configurable layouts (eg qwerty, then a numberpad entry - u can have a more complicated terminal hacker entry etc.) as for dictionaries - that's part of life i guess. anyone is free to work on another keyboard if they want. in the end the proof is in the pudding. who will go and actually write code. you can have all the ideas in the world, but he who puts them into code and makes them usable by others "wins" :) so don't stop- please, work on alternate input methods. i am going with the one i have seen work, demonstrated live on a Neo and used. > They also suck if ones vocabulary is much more advanced than > the one which is implemented (and I personally do not want > to adjust my vocabulary to fit the needs of the input system). thats why dictionaries can be added to, imported, words learnt automatically and added, etc. etc. :) > Just my 2 cents. > > Regards > Karsten > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Sorry to jump into the thread this late, but I am wondering if you already examined the following Wiki-Link? We had a very extensive discussion about text input running on the community list several months ago. Nearly all proposals were documented on the following Wiki: http://wiki.openmoko.org/wiki/Wishlist:Text_Input My personal favourites are the Quickwriting (there is even a java demo available) and "another text input" (although it seems to be another implementation of this more moko-like implementation: http://www.micropp.se/openmoko/splash.html ). If I remember correctly, "all" participants of the discussion came to the conclusion, that a regular qwerty keyboard is not sufficient no matter how clever you "pimp" it, due to restriction of precision of finger typing and lack of screen space. An "intelligent" input prediction (e.g. T9) sucks, when one is using different languages regularly (you always have to remember switching to the right dictionary BEFORE typing). ( Not everyone on this planet is using english in day to day conversations. ;-) ) They also suck if ones vocabulary is much more advanced than the one which is implemented (and I personally do not want to adjust my vocabulary to fit the needs of the input system). Just my 2 cents. Regards Karsten ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Fri, 29 Feb 2008 18:50:14 +0100 "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> babbled: > > What you're talking about already exists - the qtopia guis have such a > > predictive qwerty keyboard that works - maybe it's possible for you to > > give it a try or find a video. > > No it isn't the same thing... I meant reducing the size of each > key-button keeping it proportional to the possibility of being pressed > to complete a word (ie: It's hard to find a "r" after "hel", but it's > more probabile that next char will be a "l" for example, so why showing > "r" and "l" of the same size, on the keyboard?!) > Predictive keyboard acts on words, I'd act on input (keys). > Have I been more clear? i would disagree that changing size is good - don't change the UI view. you don't have time to see it and react anyway (do you really press the 'h' remove your finger so u see the whole keyboard, then press the 'e', then remove again and inspect the keyboard, then press 'l etc. etc.?). you likely have 0.2 to 0.5 or so seconds between presses. don't change size. simply have fuzzy correction. your keyboard has a layout: qwerty... asdfg... zxcv... i WANT to type "waste". i press w - but really my finger may easily hit q,e,a or s - maybe even r, d, z or t. as such every key has a center point. my finger will try and press somewhere close to this center, but may fail and be closer to something else. distance from the center point of a key will be the probability that you wanted that key. for practical computation u need to have a cutoff of X pixels away and ignore any possibilities greater than that, so then u press another key. now u are close to 1 key - but also to others. so as you type you get something like (a key, then a closeness value from 1 to 9 lets say, where 9 is the closest. closeness is just a measure of distance - inverted): press 1: w7q3e4a2s3d1 press 2: a6s4d1q4w3e1z3x2 press 3 s4a5d2q3w4e2r1z3x1 press 4: t8r2y3d1f2g1 press 5: e7w4w1r5t2a3s4d2 every time a "space" is entered (could be a key - or ala qt kbd a stroke to the right) the word buffer resets. so as you type, each press builds a list of probable targets. you order each entry from closest to least. so the above raw data will at pres 5 give the following list of "matches" (i'll shorten it for this email): wadte waste wawte wsate wsste wswte ... (you get the idea). and so on down to the least probable. yes - you need to type the whole word, BUT as you type a word, it adjusts the probability of some key presses being wrong/off based on matching it against a dictionary of commonly used words (including a user dictionary so it will learn). in this example the most probable input was #2 in the list. each combination of the above letters can be assigned a probability value based on the closeness values per letter in the combination (the higher, the better) and simply do a lookup of the top N probable combinations and those that exist as a whole word in a dictionary are the best matches, those that match the start of 1 or more words are also next in line as being probable. in fact the dictionary would also have a probability value for each word in it based on historical usage (input from english test sources for example). with this kind of scheme: 1. it's plain qwerty. nothing new to learn. simple. 2. it fixes your entries (yes - we can add unix commands in $PATH to the dictionary etc. etc. so shell users get their commands predicted) based on probable matches 3. the ui is static - so easy to get motor memory in your fingers working. 4. requires either a full XIM/SCIM/UIM etc. integration system where the vkbd acts as the SCIM/UIM/XIM front-end so it is possible to enter whole words and correct as you go, OR you need to fake it via the X Test extension and fake fixups of words with backspaces, or buffer input until a space then output a series of key fakes. the 2nd method is simpler and universal so apps/toolkits that don't do XIM/UIM/SCIM integration work, but it is more limiting. it is also much less work. 5. the keyboard is a simple set of buttons. it'll be trivial for having multiple layouts (one for text messaging, one for using the shell/terminal with more symbol characters, etc. etc.( as it can just be a config file. the vkbd just provides a little switcher button to switch between layouts. i'm definitely leaning this way. of course i wouldn't and don't preclude the idea of any other keyboard styles/types as everyone is discussing here. one size does NOT fit all. i just want to do something a little more conservative to start with as it's tried and tested, familiar and known to work well at least with a stylus. correction based on dictionary lookups is an added finesse to work around fat fingers :) -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Without a doubt it's slower then standard-qwerty if you take only the non-capital non-special chars. The biggest problem with qwerty is, that you simply don't have the space to make it usable on the neo in non-landscape mode. Apple has a really good and efficient design for their qwerty keyboard on a much bigger screen without a high bezel, and as also Gustavo mentioned it's not really good usable (that's my personal experience, too). Also they use about 50% of the whole screen for the keyboard what (imho) sucks. What you're talking about already exists - the qtopia guis have such a predictive qwerty keyboard that works - maybe it's possible for you to give it a try or find a video. I'm still the opinion that qwerty isn't possible and it also isn't nice. I'll finish my own try, let's see how good it will be. Of course it's great to have multiple solutions, so openmoko has the chance to get the best mobile input method. If my design works and the people like it it would of course be possible to have prediction and other cool features, too, but that's not planned yet. My goal is it to have all needed chars, usable with fingers, without wasting 80% of the screen (like the multitap-pad does for example), and to be still fast. Imho this is already possible - enter currently needs about 30% of the screen for input, is really fast for 1-finger-touchscreen-input, and it has 144 possible keys. On 2/29/08, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > > Thomas Gstädtner ha scritto: > > > I'm currently working on another system that requires one drag per sign > > (no matter what sign, be it capitals, special chars, ...) and can be > > extremely easy and fast with a proper layout. > > You can see a basic preview here: > > http://videos.gstaedtner.net/enter_neo_native.mkv > > I'm a total newbie in programming, but I expect some results in the next > > time. > > The system allows 144 key-combinations with buttons big enough to easily > > hit them with your thumbs. > > It allows fast one-handed writing of all ascii-signs and it will be very > > flexible with the layouts. > > > Well, the idea is good but isn't it slower than a standard qwerty > keyboard? > I was thinking also to an implementation of the qwerty mixed with a > dictionary file that while you're writing shows the keys in different > sizes proportional to the possibility of each key of being pressed... > > What do you think about this? > > > -- > > 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: Virtual QWERTY Keyboards to be used with Fingers...
At moment it's only square - with the reason to need as less space as possible (like you can see it needs about the same amount of space on the screen as the matchbox-keyboard but way more efficient). As I use the efl and especially Edje as layout engine, it's no problem at all to just make a circular theme! Also there currently is only the alphabetic (yet not complete) layout that is easy to understand (without learning), but pretty unefficient. In future this all will be fully flexible. The themers can decide what form they'd like to have, it's easy to try different ways to find the best, and it also should be easy to find fast and efficient key layouts. At least that's what planned. Needs some time (I'm a newbie), but is no real problem. The only fix thing is the 12-button design, but as long this is implemented in the theme somehow everything is possible. A problem migt be matchbox, I just don't know how flexible the docks are and what is possible with them. I don't like wasting that much screen for a bit more comfort, but let's see. On 2/29/08, enaut <[EMAIL PROTECTED]> wrote: > > Thomas Gstädtner schrieb: > > > I don't think qwerty is what we want really. > > Also that it requires only one keypress per letter is not fully true, > > as you have to use "shift" very often (capitals, special charakters, > ...). > > Imho the display on the neo is way to small to have qwerty. The iphone > > shows, that eben the much bigger screen (without a high bezel!) is not > > really great for a extremely basic qwerty variant. > > I'm currently working on another system that requires one drag per > > sign (no matter what sign, be it capitals, special chars, ...) and can > > be extremely easy and fast with a proper layout. > > You can see a basic preview here: > > http://videos.gstaedtner.net/enter_neo_native.mkv > > I'm a total newbie in programming, but I expect some results in the > > next time. > > The system allows 144 key-combinations with buttons big enough to > > easily hit them with your thumbs. > > It allows fast one-handed writing of all ascii-signs and it will be > > very flexible with the layouts. > > So it would be possible to have a layout that allows single-click > > without dragging for keys needed often in a row (backspace/del e.g.), > > as you can see with the "o" on the video. I'm writing "HelloWorld" > > there (you can see the output on the terminal, as there is only a > > stdout-function at moment), the "Hello" to show the interface, the > > "World" to show the speed (that will improve quite a bit so that the > > interface will be fast enough to follow you :) ). > > Of course in the end it will be on the bottom of the screen as the old > > matchbox-keyboard is (at moment I'm working on the matchbox > > integration), so you can hold it in your right hand and type with your > > right thumb without needing the left hand at all. > > It doesn't even need prediction to be fast and easy, although it would > > be a possibility to enhance it. > > There's a tarball with the source, but not ready to be usable, so I > > will release the code later. > > Interested people can have the link and maybe an ipkg, but I'd > > recommend at least to wait until the matchbox-integration is ready. > > I like this Idea. > Did you try to implement this in a circular fashion? that would look > better and it may even be easy to use with one hand. With your square > layout you often have prety long distances to drag. Moving my thumb over > a display i feel only for a pretty small area comfortable the rest ist > really hard to reach in an acurate way so that I actually hit the button > i want to. > > > enaut > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
Thomas Gstädtner schrieb: > I don't think qwerty is what we want really. > Also that it requires only one keypress per letter is not fully true, > as you have to use "shift" very often (capitals, special charakters, ...). > Imho the display on the neo is way to small to have qwerty. The iphone > shows, that eben the much bigger screen (without a high bezel!) is not > really great for a extremely basic qwerty variant. > I'm currently working on another system that requires one drag per > sign (no matter what sign, be it capitals, special chars, ...) and can > be extremely easy and fast with a proper layout. > You can see a basic preview here: > http://videos.gstaedtner.net/enter_neo_native.mkv > I'm a total newbie in programming, but I expect some results in the > next time. > The system allows 144 key-combinations with buttons big enough to > easily hit them with your thumbs. > It allows fast one-handed writing of all ascii-signs and it will be > very flexible with the layouts. > So it would be possible to have a layout that allows single-click > without dragging for keys needed often in a row (backspace/del e.g.), > as you can see with the "o" on the video. I'm writing "HelloWorld" > there (you can see the output on the terminal, as there is only a > stdout-function at moment), the "Hello" to show the interface, the > "World" to show the speed (that will improve quite a bit so that the > interface will be fast enough to follow you :) ). > Of course in the end it will be on the bottom of the screen as the old > matchbox-keyboard is (at moment I'm working on the matchbox > integration), so you can hold it in your right hand and type with your > right thumb without needing the left hand at all. > It doesn't even need prediction to be fast and easy, although it would > be a possibility to enhance it. > There's a tarball with the source, but not ready to be usable, so I > will release the code later. > Interested people can have the link and maybe an ipkg, but I'd > recommend at least to wait until the matchbox-integration is ready. I like this Idea. Did you try to implement this in a circular fashion? that would look better and it may even be easy to use with one hand. With your square layout you often have prety long distances to drag. Moving my thumb over a display i feel only for a pretty small area comfortable the rest ist really hard to reach in an acurate way so that I actually hit the button i want to. enaut ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
I don't think qwerty is what we want really. Also that it requires only one keypress per letter is not fully true, as you have to use "shift" very often (capitals, special charakters, ...). Imho the display on the neo is way to small to have qwerty. The iphone shows, that eben the much bigger screen (without a high bezel!) is not really great for a extremely basic qwerty variant. I'm currently working on another system that requires one drag per sign (no matter what sign, be it capitals, special chars, ...) and can be extremely easy and fast with a proper layout. You can see a basic preview here: http://videos.gstaedtner.net/enter_neo_native.mkv I'm a total newbie in programming, but I expect some results in the next time. The system allows 144 key-combinations with buttons big enough to easily hit them with your thumbs. It allows fast one-handed writing of all ascii-signs and it will be very flexible with the layouts. So it would be possible to have a layout that allows single-click without dragging for keys needed often in a row (backspace/del e.g.), as you can see with the "o" on the video. I'm writing "HelloWorld" there (you can see the output on the terminal, as there is only a stdout-function at moment), the "Hello" to show the interface, the "World" to show the speed (that will improve quite a bit so that the interface will be fast enough to follow you :) ). Of course in the end it will be on the bottom of the screen as the old matchbox-keyboard is (at moment I'm working on the matchbox integration), so you can hold it in your right hand and type with your right thumb without needing the left hand at all. It doesn't even need prediction to be fast and easy, although it would be a possibility to enhance it. There's a tarball with the source, but not ready to be usable, so I will release the code later. Interested people can have the link and maybe an ipkg, but I'd recommend at least to wait until the matchbox-integration is ready. On 2/29/08, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > > Carsten Haitzler (The Rasterman) ha scritto: > > > i intend to first give a predictive qwerty keyboard a go - why? well > qwerty is > > familiar and requires only 1 press per letter. it seems the qtopia > predictive > > kbd works pretty well on the gta01 and gta02 - so now it's a cvhance to > improve > > on it wiht configurable layout, keys etc. etc. > > > To agree again, in these days I've tried a Motorola A1200E [1] and it > has a built-in predictive full qwerty keyboard [2] (not like the > openmoko one, this is better imho since it only shows the possible words > using the written combination of chars) that has been made to be used > with a stylus, but I'm able to use it with no problems with fingers > (both using the thumb and the forefinger) with a good speed! > Imho a keyboard like the Motoming one is quite good for wrigin after a > little "training" :P > > Treviño > > [1] http://wiki.openezx.org/A1200 > [2] http://www.flickr.com/photos/trevi55/2299163770/ > > > -- > 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: Virtual QWERTY Keyboards to be used with Fingers...
I just played with the java applet version: http://www.inference.phy.cam.ac.uk/dasher/TryJavaDasherNow.html -Steven On Sun, Feb 24, 2008 at 9:08 AM, JW <[EMAIL PROTECTED]> wrote: > On 24/02/2008, Steven ** <[EMAIL PROTECTED]> wrote: > > I found dasher to be very usable with a mouse. > > Its an intriguing concept! > > 1) (long but interesting) dasher Google talk > > http://www.google.co.uk/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fvideo.google.com%2Fvideoplay%3Fdocid%3D5078334075080674416&ei=JYfBR4D9KIPUwwHewPiRDQ&usg=AFQjCNHPLpw6J0mNpCdiI71pmE7k9b563A&sig2=vSrR8kyg4wwdAEIxO6GKqQ > > 2) how did you get dasher to work on the desktop to try out.i > tried on desktop (ubuntu 7.10) > sudo apt-get install dasher > but there was an error at run time > > JW > > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
JW ha scritto: On 24/02/2008, Steven ** <[EMAIL PROTECTED]> wrote: I found dasher to be very usable with a mouse. Well, after few minutes of use I felt more confortable with it, but I'm always slower (I think) than using other mobile inputs... Anyway while writing in english with it was much easy for me, it wasn't so with italian language (try to write the easy "Ciao" :o), so maybe the localized dictionaries should be improved (maybe simply with use?). 2) how did you get dasher to work on the desktop to try out.i tried on desktop (ubuntu 7.10) sudo apt-get install dasher but there was an error at run time That worked for me, btw I'm using feisty :/. Btw, we're talking of Dasher in Openmoko, but... Has it been ported? Because I don't know if it is so slow to use in a device with no 2d hardware acceleration... Bye -- 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: Virtual QWERTY Keyboards to be used with Fingers...
On 2/24/08, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: ... > I've tried dasher on my PC but it doesn't seem usable with the mouse, I > can't guess using a finger... Maybe I'm wrong while using it, but it > seems really hard to use! I tried dasher on my laptop with the joystick mouse thing in the center of the keyboard and it worked perfectly. I will use dasher on the Free Runner with input from the accelerometers. Just a tiny little tilt (sideways and up/down) would be great for navigating through the dictionary:) It is not my idea... it has been the topic here before and I will need to try it out. I love the idea, because it would really speed up the typing:) > > Treviño -- Please don't send me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Join the FSF as an Associate Member at: http://www.fsf.org/register_form?referrer=5774> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sun, 24 Feb 2008 05:38:50 -0500 "Kevin Dean" <[EMAIL PROTECTED]> babbled: > Having fussed myself about the change from QWERTY to T9, what raster > is planning solves the issue. I actually prefer non-qwerty as long as > there's some kind of predictive input that reduced the number of key > presses. > > I'm quite excited to see what comes of this. Any idea where on this > list of things to do this falls? next month :) > On Sun, Feb 24, 2008 at 4:14 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Sun, 24 Feb 2008 04:53:34 -0300 "Gustavo Sverzut Barbieri" > > <[EMAIL PROTECTED]> babbled: > > > > i intend to first give a predictive qwerty keyboard a go - why? well > > qwerty is familiar and requires only 1 press per letter. it seems the > > qtopia predictive kbd works pretty well on the gta01 and gta02 - so now > > it's a cvhance to improve on it wiht configurable layout, keys etc. etc. > > > > > > > > > On Sat, Feb 23, 2008 at 10:43 PM, "Marco Trevisan (Treviño)" > > > <[EMAIL PROTECTED]> wrote: > > > > Gustavo Sverzut Barbieri ha scritto: > > > > > > > > > On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)" > > > > > <[EMAIL PROTECTED]> wrote: > > > > >> I'm really excited waiting for the Freerunner to be available to > > > > >> the public, so I'm looking around searching the resources I'll > > > > >> need more. > > > > >> > > > > >> I think that one of the most important thing when it comes to the > > > > >> daily phone use, is the virtual input device that imho it should be > > > > >> completely usable with *fingers* (the stilus isn't portable!) > > > > >> giving the users the same confort that the key-based devices give. > > > > >> > > > > >> To get the best usability and speed while writing I do think that > > > > >> is needed a QWERTY style keyboard (If you've ever tried a > > > > >> blackberry you'd know what I mean). > > > > >> Actually there are two alternatives: the QTopia predictive > > > > >> keyboard [1] that works quite well if used with a good dictionary > > > > >> (also if it should be improved for writing new words), and the > > > > >> iphone-like virtual keyboard [2] that is already available for > > > > >> N800 and that should be easily portable to Openmoko too. > > > > >> > > > > >> Any other? If there are some others I don't know them, but the > > > > >> solutions I've tried using the Openmoko GUI with qemu aren't so > > > > >> good imho. I think that some virtual qwerty keyboards should be > > > > >> developed also considering that Openmoko supports the landscape > > > > >> view (not using accelerometers yet, but it does it!) and that mode > > > > >> could/should be used for writing, so we could use more space to > > > > >> put keys in! > > > > > > > > > > Hi Marco, > > > > > > > > Hi Gustavo! > > > > > > > > > > > > > I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm > > > > > using iPhone for about 2 months and I wrote the one you cited, so I > > > > > think I have some knowledge about it :-) > > > > > > > > > > Reasons: > > > > > - iPhone vkbd is not so great, even on iPhone hardware. The > > > > > landscape version is almost usable, but the vertical is bad - but > > > > > acceptable, see below. > > > > > > > > Well, I've tried the iPhone virtual keybard (not only on the iPhone > > > > but also in the iPod touch, that it's the same) and it's not so bad > > > > imho... Of course the vertical view is really better than the > > > > landscape one but considering how I use the T9 based phones, I'm > > > > really a much faster > > > > > > I guess you mean the other way around, using keyboard in landscape > > > mode (like iPhone browser) > > > > > > > > > > writer using this kind of keyboard, also if sometimes I do mistakes. > > > > That's why I think that the pressure should be compared char-by-char > > > > with a dictionary! > > > > > > > > > - iPhone has no sunken screen, with borders that make you loose > > > > > many physical space. This happens on Maemo devices as N800 and it's > > > > > painful in Canola and that vkbd mockup I wrote. I do not have a > > > > > OpenMoko hardware yet, but I suspect it will be even worse, as the > > > > > screen is more high dpi and smaller in physical size. > > > > > > > > Yes, that's could be true, but in landscape view I think it could be > > > > usable in Freerunner too... > > > > > > I dare to say it's not even without trying. Our experience with Canola > > > is that you waste more than 30px in each edge due the border, in > > > OpenMoko it should be even more. Given that each click area must be > > > around 100x100 to have good hit rate, then you guess you'd not have > > > much space to fit around 10 keys on 1 row. > > > > > > > > > > > - iPhone has a capacitive (not pressure based), VERY sensitive > > > > > touch screen. > > > > > - Running my prototype on
Re: Virtual QWERTY Keyboards to be used with Fingers...
On 24/02/2008, Steven ** <[EMAIL PROTECTED]> wrote: > I found dasher to be very usable with a mouse. Its an intriguing concept! 1) (long but interesting) dasher Google talk http://www.google.co.uk/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fvideo.google.com%2Fvideoplay%3Fdocid%3D5078334075080674416&ei=JYfBR4D9KIPUwwHewPiRDQ&usg=AFQjCNHPLpw6J0mNpCdiI71pmE7k9b563A&sig2=vSrR8kyg4wwdAEIxO6GKqQ 2) how did you get dasher to work on the desktop to try out.i tried on desktop (ubuntu 7.10) sudo apt-get install dasher but there was an error at run time JW ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
I found dasher to be very usable with a mouse. I played with it for just a few minutes and was already "typing" faster than I do on my cellphone with T9 equivalent. The only hard part was finding some of the punctuation. Once I have those positions memorized, I think I could blaze through conversational English. I anticipate it being my default entry method. -Steven On Sat, Feb 23, 2008 at 8:02 PM, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > I've tried dasher on my PC but it doesn't seem usable with the mouse, I > can't guess using a finger... Maybe I'm wrong while using it, but it > seems really hard to use! > >Treviño > > -- > 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: Virtual QWERTY Keyboards to be used with Fingers...
On Sun, 24 Feb 2008 04:53:34 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: i intend to first give a predictive qwerty keyboard a go - why? well qwerty is familiar and requires only 1 press per letter. it seems the qtopia predictive kbd works pretty well on the gta01 and gta02 - so now it's a cvhance to improve on it wiht configurable layout, keys etc. etc. > On Sat, Feb 23, 2008 at 10:43 PM, "Marco Trevisan (Treviño)" > <[EMAIL PROTECTED]> wrote: > > Gustavo Sverzut Barbieri ha scritto: > > > > > On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)" > > > <[EMAIL PROTECTED]> wrote: > > >> I'm really excited waiting for the Freerunner to be available to the > > >> public, so I'm looking around searching the resources I'll need more. > > >> > > >> I think that one of the most important thing when it comes to the daily > > >> phone use, is the virtual input device that imho it should be > > >> completely usable with *fingers* (the stilus isn't portable!) giving > > >> the users the same confort that the key-based devices give. > > >> > > >> To get the best usability and speed while writing I do think that is > > >> needed a QWERTY style keyboard (If you've ever tried a blackberry you'd > > >> know what I mean). > > >> Actually there are two alternatives: the QTopia predictive keyboard [1] > > >> that works quite well if used with a good dictionary (also if it should > > >> be improved for writing new words), and the iphone-like virtual > > >> keyboard [2] that is already available for N800 and that should be > > >> easily portable to Openmoko too. > > >> > > >> Any other? If there are some others I don't know them, but the > > >> solutions I've tried using the Openmoko GUI with qemu aren't so good > > >> imho. I think that some virtual qwerty keyboards should be developed > > >> also considering that Openmoko supports the landscape view (not using > > >> accelerometers yet, but it does it!) and that mode could/should be used > > >> for writing, so we could use more space to put keys in! > > > > > > Hi Marco, > > > > Hi Gustavo! > > > > > > > I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm using > > > iPhone for about 2 months and I wrote the one you cited, so I think I > > > have some knowledge about it :-) > > > > > > Reasons: > > > - iPhone vkbd is not so great, even on iPhone hardware. The > > > landscape version is almost usable, but the vertical is bad - but > > > acceptable, see below. > > > > Well, I've tried the iPhone virtual keybard (not only on the iPhone but > > also in the iPod touch, that it's the same) and it's not so bad imho... > > Of course the vertical view is really better than the landscape one but > > considering how I use the T9 based phones, I'm really a much faster > > I guess you mean the other way around, using keyboard in landscape > mode (like iPhone browser) > > > > writer using this kind of keyboard, also if sometimes I do mistakes. > > That's why I think that the pressure should be compared char-by-char > > with a dictionary! > > > > > - iPhone has no sunken screen, with borders that make you loose many > > > physical space. This happens on Maemo devices as N800 and it's painful > > > in Canola and that vkbd mockup I wrote. I do not have a OpenMoko > > > hardware yet, but I suspect it will be even worse, as the screen is > > > more high dpi and smaller in physical size. > > > > Yes, that's could be true, but in landscape view I think it could be > > usable in Freerunner too... > > I dare to say it's not even without trying. Our experience with Canola > is that you waste more than 30px in each edge due the border, in > OpenMoko it should be even more. Given that each click area must be > around 100x100 to have good hit rate, then you guess you'd not have > much space to fit around 10 keys on 1 row. > > > > > - iPhone has a capacitive (not pressure based), VERY sensitive touch > > > screen. > > > - Running my prototype on N800 was not so bad because the screen is > > > huge and you have plenty of space, but you often miss some clicks due > > > the pressure based touch screen. > > > > I don't know how it is in Freerunner, but there's no software control on > > it? > > it's a physical limitation: the screen need pressure to emit hardware > signals, while the capacitive just needs contact, you barely need to > touch in order to produce hardware signals. > > > > > That's why I think it's not a good option. We better keep with some > > > kind variation of T9. I already talked to rasterman about that and he > > > have a great idea of a key matrix (3x3 or 4x3) that would behave like > > > number keypad, but the labels would weight the key with greatest > > > probability of being used (based on dicts, T9 like). > > > > As I've said, I don't love T9 neither 9x9 keyboards as they're commonly > > meant (the ones used for years by key-based phones) maybe Lars >
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, Feb 23, 2008 at 10:43 PM, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > Gustavo Sverzut Barbieri ha scritto: > > > On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)" > > <[EMAIL PROTECTED]> wrote: > >> I'm really excited waiting for the Freerunner to be available to the > >> public, so I'm looking around searching the resources I'll need more. > >> > >> I think that one of the most important thing when it comes to the daily > >> phone use, is the virtual input device that imho it should be completely > >> usable with *fingers* (the stilus isn't portable!) giving the users the > >> same confort that the key-based devices give. > >> > >> To get the best usability and speed while writing I do think that is > >> needed a QWERTY style keyboard (If you've ever tried a blackberry you'd > >> know what I mean). > >> Actually there are two alternatives: the QTopia predictive keyboard [1] > >> that works quite well if used with a good dictionary (also if it should > >> be improved for writing new words), and the iphone-like virtual keyboard > >> [2] that is already available for N800 and that should be easily > >> portable to Openmoko too. > >> > >> Any other? If there are some others I don't know them, but the solutions > >> I've tried using the Openmoko GUI with qemu aren't so good imho. > >> I think that some virtual qwerty keyboards should be developed also > >> considering that Openmoko supports the landscape view (not using > >> accelerometers yet, but it does it!) and that mode could/should be used > >> for writing, so we could use more space to put keys in! > > > > Hi Marco, > > Hi Gustavo! > > > > I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm using > > iPhone for about 2 months and I wrote the one you cited, so I think I > > have some knowledge about it :-) > > > > Reasons: > > - iPhone vkbd is not so great, even on iPhone hardware. The > > landscape version is almost usable, but the vertical is bad - but > > acceptable, see below. > > Well, I've tried the iPhone virtual keybard (not only on the iPhone but > also in the iPod touch, that it's the same) and it's not so bad imho... > Of course the vertical view is really better than the landscape one but > considering how I use the T9 based phones, I'm really a much faster I guess you mean the other way around, using keyboard in landscape mode (like iPhone browser) > writer using this kind of keyboard, also if sometimes I do mistakes. > That's why I think that the pressure should be compared char-by-char > with a dictionary! > > > - iPhone has no sunken screen, with borders that make you loose many > > physical space. This happens on Maemo devices as N800 and it's painful > > in Canola and that vkbd mockup I wrote. I do not have a OpenMoko > > hardware yet, but I suspect it will be even worse, as the screen is > > more high dpi and smaller in physical size. > > Yes, that's could be true, but in landscape view I think it could be > usable in Freerunner too... I dare to say it's not even without trying. Our experience with Canola is that you waste more than 30px in each edge due the border, in OpenMoko it should be even more. Given that each click area must be around 100x100 to have good hit rate, then you guess you'd not have much space to fit around 10 keys on 1 row. > > - iPhone has a capacitive (not pressure based), VERY sensitive touch > screen. > > - Running my prototype on N800 was not so bad because the screen is > > huge and you have plenty of space, but you often miss some clicks due > > the pressure based touch screen. > > I don't know how it is in Freerunner, but there's no software control on it? it's a physical limitation: the screen need pressure to emit hardware signals, while the capacitive just needs contact, you barely need to touch in order to produce hardware signals. > > That's why I think it's not a good option. We better keep with some > > kind variation of T9. I already talked to rasterman about that and he > > have a great idea of a key matrix (3x3 or 4x3) that would behave like > > number keypad, but the labels would weight the key with greatest > > probability of being used (based on dicts, T9 like). > > As I've said, I don't love T9 neither 9x9 keyboards as they're commonly > meant (the ones used for years by key-based phones) maybe Lars > Hallberg keyboards [1] are a little more usable... I think it's not much diferent from T9, just a implementation that utilizes software capabilities better. > > The major problem with T9 is it takes time to train and have it behave > > fine for you. One option would be to provide a service (pc, web or on > > the device itself) to feed with personal texts (mails, docs, ... text > > you wrote) so it will optimize for it. Other improvements could be > > abbreviations and maybe mode selection to use even more optimized > > dicts (language based and
Re: Virtual QWERTY Keyboards to be used with Fingers...
Flemming Richter Mikkelsen ha scritto: ... That's why I think it's not a good option. We better keep with some kind variation of T9. I already talked to rasterman about that and he ... The major problem with T9 is it takes time to train and have it behave ... What we need to do is implement something fast, with good feedback and users will get used... people already got used to write "graffiti", T9, ... and even QWERTY... they will learn yet another, just make the behavior predictable and help the user whenever possible. I will use dasher for writing SMS, e-mails, etc:) It is designed for fast writing and is predictive. I've tried dasher on my PC but it doesn't seem usable with the mouse, I can't guess using a finger... Maybe I'm wrong while using it, but it seems really hard to use! Treviño -- 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: Virtual QWERTY Keyboards to be used with Fingers...
... > That's why I think it's not a good option. We better keep with some > kind variation of T9. I already talked to rasterman about that and he ... > The major problem with T9 is it takes time to train and have it behave ... > What we need to do is implement something fast, with good feedback and > users will get used... people already got used to write "graffiti", > T9, ... and even QWERTY... they will learn yet another, just make the > behavior predictable and help the user whenever possible. I will use dasher for writing SMS, e-mails, etc:) It is designed for fast writing and is predictive. When it comes to stuff like coding, scripting, writing commands, etc, T9 would be great. > -- > Gustavo Sverzut Barbieri -- Please don't send me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Join the FSF as an Associate Member at: http://www.fsf.org/register_form?referrer=5774> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Virtual QWERTY Keyboards to be used with Fingers...
On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > I'm really excited waiting for the Freerunner to be available to the > public, so I'm looking around searching the resources I'll need more. > > I think that one of the most important thing when it comes to the daily > phone use, is the virtual input device that imho it should be completely > usable with *fingers* (the stilus isn't portable!) giving the users the > same confort that the key-based devices give. > > To get the best usability and speed while writing I do think that is > needed a QWERTY style keyboard (If you've ever tried a blackberry you'd > know what I mean). > Actually there are two alternatives: the QTopia predictive keyboard [1] > that works quite well if used with a good dictionary (also if it should > be improved for writing new words), and the iphone-like virtual keyboard > [2] that is already available for N800 and that should be easily > portable to Openmoko too. > > Any other? If there are some others I don't know them, but the solutions > I've tried using the Openmoko GUI with qemu aren't so good imho. > I think that some virtual qwerty keyboards should be developed also > considering that Openmoko supports the landscape view (not using > accelerometers yet, but it does it!) and that mode could/should be used > for writing, so we could use more space to put keys in! Hi Marco, I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm using iPhone for about 2 months and I wrote the one you cited, so I think I have some knowledge about it :-) Reasons: - iPhone vkbd is not so great, even on iPhone hardware. The landscape version is almost usable, but the vertical is bad - but acceptable, see below. - iPhone has no sunken screen, with borders that make you loose many physical space. This happens on Maemo devices as N800 and it's painful in Canola and that vkbd mockup I wrote. I do not have a OpenMoko hardware yet, but I suspect it will be even worse, as the screen is more high dpi and smaller in physical size. - iPhone has a capacitive (not pressure based), VERY sensitive touch screen. - Running my prototype on N800 was not so bad because the screen is huge and you have plenty of space, but you often miss some clicks due the pressure based touch screen. That's why I think it's not a good option. We better keep with some kind variation of T9. I already talked to rasterman about that and he have a great idea of a key matrix (3x3 or 4x3) that would behave like number keypad, but the labels would weight the key with greatest probability of being used (based on dicts, T9 like). The major problem with T9 is it takes time to train and have it behave fine for you. One option would be to provide a service (pc, web or on the device itself) to feed with personal texts (mails, docs, ... text you wrote) so it will optimize for it. Other improvements could be abbreviations and maybe mode selection to use even more optimized dicts (language based and terms based, like "polite", "3733t speech", "development"...). What we need to do is implement something fast, with good feedback and users will get used... people already got used to write "graffiti", T9, ... and even QWERTY... they will learn yet another, just make the behavior predictable and help the user whenever possible. -- Gustavo Sverzut Barbieri http://profusion.mobi - Embedded and Mobile Software Development -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community