Re: Yet another finger keybord (gui mock-up).
Just an information about: That will be a very different layout than someone who does short hand or abbreviated messaging. the layouts are not so different as you think... Using the same language on conversations if you produce a layout optimized to that language it will cover the full word and the abbreviated one. Check this paper : http://www.almaden.ibm.com/u/zhai/papers/ZhaiHunterSmithHCIGalley.pdf on Digraph Frequency Guy On Sun, 26 Aug 2007 11:35, Andraž 'ruskie' Levstik wrote: On 20:15:37 2007-08-26 Edwin Lock [EMAIL PROTECTED] wrote: So you have to get used to it every time again? doesn't seem like a very good idea. My experience is that people like to get used to things and do them like the got used to, not change.. - Edwin A dynamic input... I like it... But let's put it this way... it shouldn't be to hard to add an option to either use a dynamic input or a pre-defined/custom static one. Give the user the final choice. But then that's just me... I like the user having as much choice as possible. -- Andraž ruskie Levstik Ok, I didn't actually mean after each and every keystroke. I was trying to float the idea. The actual implementation would obviously be up to some kind of experimentation. I can't see how removing the unused characters and adding more used characters could be a bad thing. Granted you let the user decide to switch and always have the ability to go back to default.. But each user will have a different vocabulary and thus a different optimization specifically for them. as a bad example take someone who always talks in leet speek when messaging. That will be a very different layout than someone who does short hand or abbreviated messaging. If the program could figure out, say each night or when the user chooses or what not, which letters or symbols they use most and build an appropriate step heirarchy then you could optimize the path for fewest drag type operations and more click operations. Or at least that's how it seems to me. Then once the sequences are determined, let the user position them on the grid in a manner that feels right to them. For each user that might be different. Anyway, some will like it and some will disable it in favor of the default or non-assisted but customly defined layout. Personally, I would not mind having the least used letters changed out for more used letters based on my usage patters in a semi automatic way, if I could anchor my most used letters to positions where they feel comfortable. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Lars Hallberg wrote: You mean 8 drag directions + just press+relese... 9 functions per key. Might work. Guess testing on the device is how to find out. But 6x5 keyboard with 8 drag directions give: 6 9 9 9 9 6 6 9 9 9 9 6 4 6 6 6 6 4 A total of 128 'keys'... Good *if* it works :-) As someone who used MessageEase, which is what I think this topic is somewhat related to, my opinion is below. http://www.exideas.com/ME/faq.html Especially since the screen is smaller than most pda's, the actual button sizes need to be even larger to make it easy to hit what you meant without having to concentrate too much. The version that I used had two setups. One had lots of buttons that allowed you to input most any character, the other had only a 4x4 grid (shown in that link). It had just 3x3 that were used for input, with 6 others that allowed for switching modes (uppercase, text/numeric, punctuation). I personally found that *MUCH* easier to use with just my fingers. Considering that just a 3x3 grid allows for 56 combinations (which is quite a lot). If you surround a 3x3 grid with 7 switches, you can achieve 7*56 or 392 different keys, all from just a 4x4 grid! So not only would the buttons be much larger, but you would also be able to have a much higher key density. 6 9 6 X 6 9 6 X 4 6 4 X X X X X I guess what I am trying to say is that less is more, and that is even more so with buttons competing for screen real estate. -Jonathon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
[ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. Please check http://de.wikipedia.org/wiki/Buchstabenh%C3%A4ufigkeit#Buchstabenh.C3.A4ufigkeiten_in_deutschsprachigen_Texten for a list of mostly used letters in german. In english, the frequency is similar, but unfortunately I can't find the table right now. I remember I have seen the english table as I was searching for information about dvorak keyboards on wikipedia, but I can't find it anymore. I suggest to add a second layout, and use one of the unused drag positions to switch between your original phone layout and a second text layout. We could even have a third programmer layout or something. When the nine mostly used characters (e,n,i,s,r,a,t,d,h) are put in the middle of the buttons, 71% of all keystrokes would be done without dragging. When the 15 mostly used characters (e,n,i,s,r,a,t,d,h,u,l,c,g,m,o) are put in the middle, 90% of all keystrokes would be done without dragging. Unfortunately, the table don't contain special characters. I suggest to put at least the space onto a main position. This mail, up to (and including) this paragraph, has this frequency: pos char cnt %cum% == 1 SPACE: 224 14.79 14.79 2 e: 131 8.65 23.43 3 t: 107 7.06 30.50 4 a: 85 5.61 36.11 5 o: 78 5.15 41.25 6 n: 75 4.95 46.20 7 i: 73 4.82 51.02 8 s: 73 4.82 55.84 9 r: 61 4.03 59.87 10 h: 56 3.70 63.56 11 u: 45 2.97 66.53 12 d: 44 2.90 69.44 13 l: 42 2.77 72.21 14 c: 33 2.18 74.39 15 CR: 33 2.18 76.57 From this table, we can see two tings: 1. space most definitely needs to be on a main position 2. while the order is different, eight of the nine characters mentioned above are on the first nine positions in the table. BTW: Vi users would probably like to have the colon on a main position. Emacs users would probably like ESC and CRTL-X on a main position, so I guess having it configurable would be the best. Opinions? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. In the screen shots of 2007.2 the filer toolbar have 6 buttons... and a little free space. Everyone having phones with 2007.2 is that tool bar comfortably usable with fingers? If it is 6x3 is probably the best choice. Lifting the keys up a little from the bottom (maybe put modifier status indicators at the bottom) will add the side down alternative to the bottom keys changing the number of functions on the bottom row to: 4 6 ... 6 4 5x3 - 88 keys, 6x3 - 108 keys. . . . . . . The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Thinking 5/8 of a quickwriting wheel, so the 'neutral area' is in the bottom. Put it on the bottom of the screen You get tactile feedback from the screen bevel (may cut a small 'mark' in case at the middle). One such wheel give 25 'keys'. lay a row of keys at the bottom of the screen. press one key and slide to the middle to activate a wheel (the covers bevel can have small cuts to guide You to this buttons also). If the wheel is big enough the tactile feedback given by the screen edge should make 'blind' use comfortable. I'm not sure hove many button to use... but 3 - 5 (75 - 125 'keys')... However, some keys would probably be duplicated... one wheel for numbers and arithmetic, one for the most common letters... both of these want space for sure one for the least common letters and other less common symbols (can probably do without space) ... Then You probably want at least one more wheel for cursor control, enter, edit keys etc. This is far less intuitive and far less suited for the average user and a poor default, but the one handed blind use is good for walking in traffic or in the woods. And it us only one row of buttons att the bottom of the screen, leaving most for the apps. It's a good 'power option'. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Sun, 26 Aug 2007 9:36, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. /snip /LaH What about a continuously variable system which starts with the most commonly used letters and then adjusts itself based on user input. It could learn which letters a specific person uses to type and make them more prominent. Then, depending on modes the programming or web searching or other keyboards would automatically adapt to the best layout based on the users individual behavior. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
So you have to get used to it every time again? doesn't seem like a very good idea. My experience is that people like to get used to things and do them like the got used to, not change.. - Edwin On 26/08/07, Tim Newsom [EMAIL PROTECTED] wrote: On Sun, 26 Aug 2007 9:36, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. /snip /LaH What about a continuously variable system which starts with the most commonly used letters and then adjusts itself based on user input. It could learn which letters a specific person uses to type and make them more prominent. Then, depending on modes the programming or web searching or other keyboards would automatically adapt to the best layout based on the users individual behavior. --Tim ___ 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: Yet another finger keybord (gui mock-up).
Tim Newsom skrev: What about a continuously variable system which starts with the most commonly used letters and then adjusts itself based on user input. It could learn which letters a specific person uses to type and make them more prominent. Then, depending on modes the programming or web searching or other keyboards would automatically adapt to the best layout based on the users individual behavior. A main factor in speeding up typing is learning the layout, so a layout that change under the users fingertips is bad. But collecting usage statistics and have some function to assist the user in making there own layout at will might be good. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On 20:15:37 2007-08-26 Edwin Lock [EMAIL PROTECTED] wrote: So you have to get used to it every time again? doesn't seem like a very good idea. My experience is that people like to get used to things and do them like the got used to, not change.. - Edwin A dynamic input... I like it... But let's put it this way... it shouldn't be to hard to add an option to either use a dynamic input or a pre-defined/custom static one. Give the user the final choice. But then that's just me... I like the user having as much choice as possible. -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html Be sure brain is in gear before engaging mouth. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Sun, Aug 26, 2007 at 06:04:15PM +0200, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. It is perfect for the phone functions. But we don't want to stop at trivial functions. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. I'm not sore what is the best layout for text input. While I am pretty that numbers-on-main-positions is the second worst possibility (the worst would be to change positions automatically), I am not really sure what the best layout would be. As an example, for an emacs user, about half of the keystrokes are either ESC or CTRL-X. A lisp programmer would like parentheses on the main positions. I don't think we will ever be able to find the perfect layout for everybody. But we might be able to give people the ability to choose. As an exmple, I would like three layouts: 1. For phone functions, your original phone layout. 2. For mails, mostly used letters on main positions (as described in my last mail) but ESC and CTRL-X also on main positions. 3. For programming, some special chartacters should move on main positions. In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Ough, I don't really understand... You want up to 7 functions per key? Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. Too bad they are sold out :-( No chance to buy one :-(( The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Maybe 8 functions per key (instead of 6) would be a benefit? Only a guess. You can't tell unles you actually tried it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Josef Wolf skrev: On Sun, Aug 26, 2007 at 06:04:15PM +0200, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. It is perfect for the phone functions. But we don't want to stop at trivial functions. The phone function got it's own dialer keypad. But a numeric keypad may be useful for allot else... and I believe it to be most beginner friendly... And... I don't really think it's any big difference in hitting the main function or the secondary functions of a key. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. Sorry for my English... but I think I try to say about the same thing You did her :-) In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Ough, I don't really understand... You want up to 7 functions per key? One only press+release, then press and drag in one of six directions = 1 + 6 = 7. But the keys on the edge of the screen can't be dragged in off screen directions giving less 'functions'. As described in: http://www.micropp.se/openmoko/ Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. Too bad they are sold out :-( No chance to buy one :-(( Well, there will come new ones :-) The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Maybe 8 functions per key (instead of 6) would be a benefit? Only a guess. You can't tell unles you actually tried it. You mean 8 drag directions + just press+relese... 9 functions per key. Might work. Guess testing on the device is how to find out. But 6x5 keyboard with 8 drag directions give: 6 9 9 9 9 6 6 9 9 9 9 6 4 6 6 6 6 4 A total of 128 'keys'... Good *if* it works :-) /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
I believe a simple two character per key would be more than enough as a start (where the current phones are 3 chars per key). A full qwerty is too dense, so cut the density in half by bundling 2 keys into one. I've attached a 2 minute mokup. Image is 480px accross. just tossing ideas.. layout would be discussed. - Original Message From: Josef Wolf [EMAIL PROTECTED] To: community@lists.openmoko.org Sent: Sunday, August 26, 2007 3:51:50 PM Subject: Re: Yet another finger keybord (gui mock-up). On Sun, Aug 26, 2007 at 06:04:15PM +0200, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. It is perfect for the phone functions. But we don't want to stop at trivial functions. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. I'm not sore what is the best layout for text input. While I am pretty that numbers-on-main-positions is the second worst possibility (the worst would be to change positions automatically), I am not really sure what the best layout would be. As an example, for an emacs user, about half of the keystrokes are either ESC or CTRL-X. A lisp programmer would like parentheses on the main positions. I don't think we will ever be able to find the perfect layout for everybody. But we might be able to give people the ability to choose. As an exmple, I would like three layouts: 1. For phone functions, your original phone layout. 2. For mails, mostly used letters on main positions (as described in my last mail) but ESC and CTRL-X also on main positions. 3. For programming, some special chartacters should move on main positions. In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Ough, I don't really understand... You want up to 7 functions per key? Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. Too bad they are sold out :-( No chance to buy one :-(( The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Maybe 8 functions per key (instead of 6) would be a benefit? Only a guess. You can't tell unles you actually tried it. Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca attachment: simple_screen.gif___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Mohammed Musallam skrev: I believe a simple two character per key would be more than enough as a start (where the current phones are 3 chars per key). A full qwerty is too dense, so cut the density in half by bundling 2 keys into one. The point with the design is not to use modifiers for the keys. You ether tap the key for main function, or press and drag on different directions for secondary functions. Making it almost as fast to reach the secondary function as the main functions. How many functions per key, and how many keys is factors to experiment with. Think ether 5x3 (like Your design) or 6x3 is the best number of keys. The number of function per key reasonable is on of: tap + drag up, down, left, right. 1+4 = 5 functions. The hexagon design 1 + 6 = 7 functions. The first but with added diagonal drag, 1 + 8 = 9 functions. Higher density and higher number of functions mean less need for modifiers to reach input functions. Lower density and fewer functions mean faster and less error prone input but more need for modifiers. Modifiers are harmful as they have to be inputted in serial.. not parallel like on a physical keyboard. Think it takes experimentation to find the optimum. One possibility is to us 5x3 but have an option to add one more column that can be used for user defined keys and app specific accelerators. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Yet another finger keybord (gui mock-up).
Is setting up a keyboard for programming really all that necessary? The screen is too small and it's too easy to just ssh into the phone to want to sit there staring at the screen long enough to be able to write programs for it. I think a keyboard setup to be able to add contacts, sms and other simple input should be the primary task for the keyboard. I've been thinking about how I would like to be able to input text onto the phone and the easiest solution I find is to have the phone switch to landscape and a full screen keyboard with a small text box at the top just like how Nintendo does it with the Wii. Richard Reichenbacher -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josef Wolf Sent: Sunday, August 26, 2007 12:52 PM To: community@lists.openmoko.org Subject: Re: Yet another finger keybord (gui mock-up). On Sun, Aug 26, 2007 at 06:04:15PM +0200, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. It is perfect for the phone functions. But we don't want to stop at trivial functions. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. I'm not sore what is the best layout for text input. While I am pretty that numbers-on-main-positions is the second worst possibility (the worst would be to change positions automatically), I am not really sure what the best layout would be. As an example, for an emacs user, about half of the keystrokes are either ESC or CTRL-X. A lisp programmer would like parentheses on the main positions. I don't think we will ever be able to find the perfect layout for everybody. But we might be able to give people the ability to choose. As an exmple, I would like three layouts: 1. For phone functions, your original phone layout. 2. For mails, mostly used letters on main positions (as described in my last mail) but ESC and CTRL-X also on main positions. 3. For programming, some special chartacters should move on main positions. In 2007.2 the scroll wheel is gone, so the key layout should probably be 5x3 giving the number of functions / key like (the status bar is gone so the bottom keys get less functions): 5 7 7 7 5 5 7 7 7 5 3 4 4 4 3 Ough, I don't really understand... You want up to 7 functions per key? Make a total of 80 keys. Alternatively 6x3: 5 7 7 7 7 5 5 7 7 7 7 5 3 4 4 4 4 3 Make a total of 98 keys... Think You need a real device to find out what is best. Too bad they are sold out :-( No chance to buy one :-(( The main good with this input method is its intuitive and probably reasonable fast. But now I'm thinking more on how to use minimal of screen space and work good one handed without visual attention... and still be reasonable in speed. Maybe 8 functions per key (instead of 6) would be a benefit? Only a guess. You can't tell unles you actually tried it. ___ 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: Yet another finger keybord (gui mock-up).
Richard Reichenbacher skrev: Is setting up a keyboard for programming really all that necessary? I for one is more likely to ssh out of the phone. My main drive to get a neo is: a) Make some good fun and use out of time wasted in places where there are no computer or net around. Think trapped in the tent some rainy days. b) Be able to spend more time in those places I like better (like the forest and the mountains, festivals and happenings). So... I want a keyboard god enugh to use any CLI/text app and gui tools like editors. If I can occasionally compile on the phone it's even better (need not be fast)! /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Yet another finger keybord (gui mock-up).
Well if this phone is going to make some kind of impact on the cellular industry it needs to offer simple and easy to use text input primarily intended for sms, adding contacts, etc. Coders are in the minority here. 90% of the time you're not going to be programming for the phone anyways, you're going to be texting or adding tasks and contacts. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hallberg Sent: Sunday, August 26, 2007 4:52 PM To: community@lists.openmoko.org Subject: Re: Yet another finger keybord (gui mock-up). Richard Reichenbacher skrev: Is setting up a keyboard for programming really all that necessary? I for one is more likely to ssh out of the phone. My main drive to get a neo is: a) Make some good fun and use out of time wasted in places where there are no computer or net around. Think trapped in the tent some rainy days. b) Be able to spend more time in those places I like better (like the forest and the mountains, festivals and happenings). So... I want a keyboard god enugh to use any CLI/text app and gui tools like editors. If I can occasionally compile on the phone it's even better (need not be fast)! /LaH ___ 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: Yet another finger keybord (gui mock-up).
On 27 Aug 2007, at 01:39, Richard Reichenbacher wrote: Well if this phone is going to make some kind of impact on the cellular industry it needs to offer simple and easy to use text input primarily intended for sms, adding contacts, etc. Coders are in the minority here. 90% of the time you're not going to be programming for the phone anyways, you're going to be texting or adding tasks and contacts. I think a minute rule applies, if someone who's used a smartphone before can pick up a phone using openmoko and use the basic features in under a minute then it's all pretty well designed and logical Obviously people who are used to awful interfaces like UIQ might struggle at first :) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Sun, 26 Aug 2007 11:35, Andraž 'ruskie' Levstik wrote: On 20:15:37 2007-08-26 Edwin Lock [EMAIL PROTECTED] wrote: So you have to get used to it every time again? doesn't seem like a very good idea. My experience is that people like to get used to things and do them like the got used to, not change.. - Edwin A dynamic input... I like it... But let's put it this way... it shouldn't be to hard to add an option to either use a dynamic input or a pre-defined/custom static one. Give the user the final choice. But then that's just me... I like the user having as much choice as possible. -- Andraž ruskie Levstik Ok, I didn't actually mean after each and every keystroke. I was trying to float the idea. The actual implementation would obviously be up to some kind of experimentation. I can't see how removing the unused characters and adding more used characters could be a bad thing. Granted you let the user decide to switch and always have the ability to go back to default.. But each user will have a different vocabulary and thus a different optimization specifically for them. as a bad example take someone who always talks in leet speek when messaging. That will be a very different layout than someone who does short hand or abbreviated messaging. If the program could figure out, say each night or when the user chooses or what not, which letters or symbols they use most and build an appropriate step heirarchy then you could optimize the path for fewest drag type operations and more click operations. Or at least that's how it seems to me. Then once the sequences are determined, let the user position them on the grid in a manner that feels right to them. For each user that might be different. Anyway, some will like it and some will disable it in favor of the default or non-assisted but customly defined layout. Personally, I would not mind having the least used letters changed out for more used letters based on my usage patters in a semi automatic way, if I could anchor my most used letters to positions where they feel comfortable. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Lars Hallberg skrev: Gabriel Ambuehl skrev: I meant for the second level, where they are essentially already in a hexagonal shape... Yes, hexagons is better then yes.. just harder to mock up ;-) Thinking more on it... hexagons is not best... as the splash pops up in the center of the press, the middle button need not be big (just cover for accidental slip). Better to increase the drag targets (making it more of a drag vector thing. Updated: http://www.micropp.se/openmoko/ with new 'splash' design and more explanation. Thanks everyone for the feedback so far. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Wed, 7 Mar 2007, Lars Hallberg wrote: Lars Hallberg skrev: Gabriel Ambuehl skrev: I meant for the second level, where they are essentially already in a hexagonal shape... Yes, hexagons is better then yes.. just harder to mock up ;-) Thinking more on it... hexagons is not best... as the splash pops up in the center of the press, the middle button need not be big (just cover for accidental slip). Better to increase the drag targets (making it more of a drag vector thing. Updated: http://www.micropp.se/openmoko/ with new 'splash' design and more explanation. Thanks everyone for the feedback so far. /LaH By the way, your mock ups are beautiful, well documented, and very professionally presented. You must be a graphic or industrial designer (or something like that) in your day job. Thanks for your work in this area. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up)
http://www.inference.phy.cam.ac.uk/dasher/ Is an really interesting project, which might be nice to use on the phone for writting. Any thoughts? - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up)
[EMAIL PROTECTED] writes: http://www.inference.phy.cam.ac.uk/dasher/ Is an really interesting project, which might be nice to use on the phone for writting. Dunno -- it's a cool idea, but when I played with it I found it very difficult to actually control. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Monday 05 March 2007 03:21:15 Florent THIERY wrote: Hey, great idea ! I'd be happy to use such a system. Yeah, it looks neat. I think I'd downscale the number of special chars though. I very much doubt you could actually read the characters on the Neo screen right now. But there's a problem i didn't find an answear to: - the neo will have a monopoint touchscreen (at least at first) - a finger is way bigger than a detectable area - What point will exactly be detected while pressing somewhere with a finger? I don't think those an issue here: you tap on the key (might want to scale it down to 6 keys, that still gives you 36 characters which is enough for just about any character based language I can think of), hold your finger, then move it towards the character you actually want. The phone doesn't actually need you to tap the character exactly, the direction of the vector of your fingers movement should be enough (with 6 adjacent characters, i.e. honeycomb [1] like layout, you still have a 60° field to hit)? [1] which brings me to the point that maybe round buttons aren't the most efficient way of doing it? pgpryc3sWXecp.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl skrev: On Monday 05 March 2007 03:21:15 Florent THIERY wrote: Yeah, it looks neat. I think I'd downscale the number of special chars though. I very much doubt you could actually read the characters on the Neo screen right now. Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special purpose :-) Hopefully, You soon learn where the keys are. And allot can be done to improve the graphics :-) But there's a problem i didn't find an answear to: - the neo will have a monopoint touchscreen (at least at first) - a finger is way bigger than a detectable area - What point will exactly be detected while pressing somewhere with a finger? I don't think those an issue here: you tap on the key (might want to scale it down to 6 keys, that still gives you 36 characters which is enough for just about any character based language I can think of), hold your finger, then move it towards the character you actually want. The phone doesn't actually need you to tap the character exactly, the direction of the vector of your fingers movement should be enough (with 6 adjacent characters, i.e. honeycomb [1] like layout, you still have a 60° field to hit)? Yes, it's that 'spalash' effect of adjacent keys that's the main concept, not the exact layout. However.. 36 keys may be good for entering contacts data... but I *want* a full-blown keyboard level of functionality. For me, a common use case is remote admin of servers with ssh... and any legacy terminal app may be used (completely unaware of 'mobile envirionment'). [1] which brings me to the point that maybe round buttons aren't the most efficient way of doing it? Round match hexagons well. Putting them in a square layout is suboptimal, but the screen is square anyway and i like the common looking keypad, with the 0 in unusual but still logical place. It's familiar in more ways... T9 users should fast pick up where the letters are. I think the size is close to optimal with 6 buttons wide (but it must be tested on a neo to be sure). The total area is not to big and high, and the 'drags' is not so long. Should make it usable in 'tumb' mode with one hand. The press areas should be smaller then the buttons anyway... It's not really that hard hitting a small target, what's hard in finger operation is avoiding adjacent targets. At least from my experiences with a Qteck (os name unrevealed to not hurt anyone innocent). One question is if the scroll wheel is needed simultaneous with the keyboard. That would else leave room for 4 buttons (24 keys) more. But in that case maybe 5*3 with 'space' on the sides so all buttons can have all 7 combinations would be better... 5*3*7 - 105 keys. And I'm unsure about the 3 boxes on top... maybe completion should go in the app area with 'normal' keyboard interface (enter, tab). reminder on link: http://www.micropp.se/openmoko/ /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
I find this idea interesting but I thought of some modification - what about using there full QWERTY keyboard? There could be something like miniature keyboard displayed at the buttom but in QWERTY layout. You could use thumbs to press keys (more accuartely: areas where keys are - your thumb would press more than one key at a time). On each key press, the part of keyboard that you pressed could be zoomed and you would be able to choose the key you wanted to enter (keys would be bigger now because they lay in zoomed aread). That could be pretty fast way of inserting data, using your thumbs, on small screen keyboard. cayco ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... purpose :-) Hopefully, You soon learn where the keys are. Which gives rise to the question of how to best arrange them... Yes, it's that 'spalash' effect of adjacent keys that's the main concept, not the exact layout. However.. 36 keys may be good for entering contacts data... but I *want* a full-blown keyboard level of functionality. For me, a common use case is remote admin of servers with ssh... and any legacy terminal app may be used (completely unaware of 'mobile envirionment'). Add another button that allows to tap shortcuts (for example like it is done in some of the vnc clients). In general, I find I'm using LESS keys for terminal work than for text entry. YMMV. [1] which brings me to the point that maybe round buttons aren't the most efficient way of doing it? Round match hexagons well. Putting them in a square layout is suboptimal, I meant for the second level, where they are essentially already in a hexagonal shape... I think the size is close to optimal with 6 buttons wide (but it must be tested on a neo to be sure). The total area is not to big and high, and the 'drags' is not so long. If you use drag vectors instead of actual taps on the buttons, you might get away with very short drags, really. One question is if the scroll wheel is needed simultaneous with the keyboard. That would else leave room for 4 buttons (24 keys) more. But in that case maybe 5*3 with 'space' on the sides so all buttons can have all 7 combinations would be better... 5*3*7 - 105 keys. Do you really need all those keys? I generally don't. Then again, I don't plan on doing non emergency work in terminals either... And on a notebook you usually don't have all of them for direct access, either. pgpczEfdZkzC6.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl wrote: On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... purpose :-) Hopefully, You soon learn where the keys are. Which gives rise to the question of how to best arrange them... Ideally - if designing it from a completely clean sheet, you want it so that 'typos' result in very different letters. a e 0 i o would be a spectacularly bad pick, for example, whereas a d 0 q f might be good. This is so autocorrection software can function well. Then there is the fun question of how many 'initial' points, and how many vectors per point. 10 numbers, with 8 drags from each number gives you alphanumeric, and easily 30 common phrases, or word components. 'I'll be ' 'home ' 'at ' '6' 'P' 'M' ' ' 'Love you!' In 8 strokes. If you go slightly further, and each stroke can either terminate normally, go longer, go clockwise, go anticlockwise, or return, that takes you up to 5 per stroke, or 400 'keys'. It would be lovely if this was incrementally learnable. First level - press 0, hold, get d a 0 q f splashing out. Once you're comfortable, you get D d Q a 0 q A f F Drag and hold to F, and you get Finish First Found F Find Friday ( down-right stroke from 0 = F, turning clockwise is Find ) And the words for 'f' might be 'food, friend, ...' Being silly, you can then hold on food, and go out to 'pizza, chips, kebab, lunch' ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl wrote: On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... purpose :-) Hopefully, You soon learn where the keys are. Which gives rise to the question of how to best arrange them... Ideally - if designing it from a completely clean sheet, you want it so that 'typos' result in very different letters. a e 0 i o would be a spectacularly bad pick, for example, whereas a d 0 q f might be good. This is so autocorrection software can function well. Then there is the fun question of how many 'initial' points, and how many vectors per point. 10 numbers, with 8 drags from each number gives you alphanumeric, and easily 30 common phrases, or word components. 'I'll be ' 'home ' 'at ' '6' 'P' 'M' ' ' 'Love you!' In 8 strokes. If you go slightly further, and each stroke can either terminate normally, go longer, go clockwise, go anticlockwise, or return, that takes you up to 5 per stroke, or 400 'keys'. It would be lovely if this was incrementally learnable. First level - press 0, hold, get d a 0 q f splashing out. Once you're comfortable, you get D d Q a 0 q A f F Drag and hold to F, and you get Finish First Found F Find Friday ( down-right stroke from 0 = F, turning clockwise is Find ) And the words for 'f' might be 'food, friend, ...' Being silly, you can then hold on food, and go out to 'pizza, chips, kebab, lunch' ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl wrote: Clear yes, but also about 3 times smaller than on your desktop screen... First, I really like this idea for input and think it has potential to being very intuitive while allowing a decent input rate. That said, the screen size (and corresponding button size) is an issue to be conscious of. You want to find the happy medium where you make the most efficient use of as little space as possible. As you make the button input area larger, you are taking up more of the application area. But without seeing how this would look on the actual device, it at least looks like a good ratio. Which gives rise to the question of how to best arrange them... That is a question that people will probably have different opinions on. How much effort would it be to have several different layouts. Some with more characters, some with less. Some more similar to qwerty other more sequential (abc...) and possibly others mimicking fitaly. You could define your default layout as a preference. And you could switch between layouts at any time (possibly via the scroll-wheel or other method). Add another button that allows to tap shortcuts (for example like it is done in some of the vnc clients). In general, I find I'm using LESS keys for terminal work than for text entry. YMMV. See everybody has their own unique usage requirements. So lets keep it flexible to accommodate the most amount of people possible. I think the size is close to optimal with 6 buttons wide (but it must be tested on a neo to be sure). The total area is not to big and high, and the 'drags' is not so long. If you use drag vectors instead of actual taps on the buttons, you might get away with very short drags, really. Exactly. I don't think it would be that hard. You've got 60deg of area for an accurate hit. Also, having the background of the keys change as you are on the key gives great visual feedback. Do you really need all those keys? I generally don't. Then again, I don't plan on doing non emergency work in terminals either... And on a notebook you usually don't have all of them for direct access, either. Again, just showing that different people have different opinions. Lets try to make it useful for everyone. I would prefer less keys, but that is just me. Heres another thought. Don't know how it would work/feel, but it might give good tactile feedback to give a quick vibration pulse after every key press (on the release). It might help to minimize the disjoint that can sometime happen with you are just touching a flat surface. One step further, it might also help if it gave a quick vibration when you dragged into different areas. That way you could tell via touch when you were in the different sectors. Keep the ideas going. This is one of the best to come out in a while! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Ian Stirling wrote: Ideally - if designing it from a completely clean sheet, you want it so that 'typos' result in very different letters. a e 0 i o would be a spectacularly bad pick, for example, whereas a d 0 q f might be good. This is so autocorrection software can function well. Then there is the fun question of how many 'initial' points, and how many vectors per point. 10 numbers, with 8 drags from each number gives you alphanumeric, and easily 30 common phrases, or word components. 'I'll be ' 'home ' 'at ' '6' 'P' 'M' ' ' 'Love you!' In 8 strokes. If you go slightly further, and each stroke can either terminate normally, go longer, go clockwise, go anticlockwise, or return, that takes you up to 5 per stroke, or 400 'keys'. It would be lovely if this was incrementally learnable. First level - press 0, hold, get d a 0 q f splashing out. Once you're comfortable, you get D d Q a 0 q A f F Drag and hold to F, and you get Finish First Found F Find Friday ( down-right stroke from 0 = F, turning clockwise is Find ) And the words for 'f' might be 'food, friend, ...' Being silly, you can then hold on food, and go out to 'pizza, chips, kebab, lunch' ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community One thing to do is look at existing designs for reference/inspiration. I mentioned the fitaly layout in a different post, but here is a link to help with the visualization. http://www.fitaly.com/wince/pocketpcfitaly.htm Auto-correction software is great when it works, but annoying when it doesn't. So it should be configurable and not mandatory. You had some good ideas in there. The food = 'pizza, chips, kebab, lunch' is stretching it a little bit, but still not a bad idea. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
About the graphics part, there's something i always found frustrating with existing virtual keyboards (say, the motorola EZX one): they remain hidden most of the time, but when you start typing in a text area, the keyboard appears, taking 70% of the screen. What could be done here (but it depends on the graphics capabilities of openmoko), is a fully transparent keyboard, letting you see what's under, so that text input is optimized for unobtrusivity. For instance, type on a text input area; background (app) stays the same, the keyboard shows up, 80% transparent, but using optimized coloring (for instance, taking the exact negative of the background on every point), so that it's still readable. About autocompletion/T9: are there plans for or already existing T9 implementations ? Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Monday 05 March 2007 16:43:38 Florent THIERY wrote: For instance, type on a text input area; background (app) stays the same, the keyboard shows up, 80% transparent, but using optimized coloring (for instance, taking the exact negative of the background on every point), so that it's still readable. I don't think the first Neo based upon s3c2410 is powerful enough for transparency like that (yes that means the mockups on the wiki won't be real for a while). However, the summer refresh supposedly should be. pgpJxTyBPOntb.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Gabriel Ambuehl skrev: On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... You can always take a closer look by pressing a button, and drag out of the 'splash' if it's wrong. Which gives rise to the question of how to best arrange them... Yes.. I'm most unhappy about esc and del, and I want to get PG Up and Pg Dn in there to. The numbers are OK, The letters reuse knowledges that T9 users have. The 3 buttons at the right feels OK, as do the cursorcontrolls. Add another button that allows to tap shortcuts (for example like it is done in some of the vnc clients). In general, I find I'm using LESS keys for terminal work than for text entry. YMMV. Is not this more the apps responsibility The messenger app know who I'm typing to, and can analyse what I usably type to that person. I meant for the second level, where they are essentially already in a hexagonal shape... Yes, hexagons is better then yes.. just harder to mock up ;-) I think the size is close to optimal with 6 buttons wide (but it must be tested on a neo to be sure). The total area is not to big and high, and the 'drags' is not so long. If you use drag vectors instead of actual taps on the buttons, you might get away with very short drags, really. To short drag might make it hard to just tap the 'central' button. But the splash should come up centered round the actual press point, not the pressed buttons center. That way ju can just strike your key... a reasonable right strike starting in the reasonable right spot will work. One question is if the scroll wheel is needed simultaneous with the keyboard. That would else leave room for 4 buttons (24 keys) more. But in that case maybe 5*3 with 'space' on the sides so all buttons can have all 7 combinations would be better... 5*3*7 - 105 keys. Do you really need all those keys? XHTML with embedded both javascript and embedded PHP with embedded SQL... Lots of strange chars... Then there's the editors. A lot of stuff use emacs key binding. Other 'windows' style (like press shift and move the cursor to mark)... ~90 should work. A lot of char may be changed when shift is pressed. And removing the 3 boxes frees 3 keys... but as the strokes still is slower than typing on a real keyboard, keeping the number of needed strokes down is good. so many keys is good. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Mon, 5 Mar 2007, Ian Stirling wrote: Gabriel Ambuehl wrote: On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... purpose :-) Hopefully, You soon learn where the keys are. Which gives rise to the question of how to best arrange them... Ideally - if designing it from a completely clean sheet, you want it so that 'typos' result in very different letters. a e 0 i o would be a spectacularly bad pick, for example, whereas a d 0 q f might be good. This is so autocorrection software can function well. How about making use of AI techniques and having the layout self-adjust to generate a layout that pushes frequently used letters to the right places, and then arranges the surrounding letters to reduce typos? If this consumes too much processing power for normal use, there could be a separate learning mode during which you would tolerate the slowness, and later switch to fixed mode. Or it could be like SpamAssassin - keystrokes (both correct and incorrect) are logged in some efficient way, and later you can train the layout engine when the device is not in use, perhaps even pushing the processing to a different computer. Additionally, one might even have different layouts for different activities - emailing friends might have a different vocabulary, and hence suggest a different layout, than C programming. Although I recognize that at some point the inefficiency of remembering the layout in different modes offsets any advantage of the layout efficiency. But, having the choice might be interesting. At the very least I may want to experiment with a new layout but retain the ability to switch back to a previous layout. I know, somewhat extreme, but at this early brainstorming stage I like thinking extreme. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
This technology is eventually going to be available on Linux according to the author, there was a demo at ETel. http://www.almaden.ibm.com/u/zhai/shapewriter.htm Adrian On 3/5/07, Joe Pfeiffer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: How about making use of AI techniques and having the layout self-adjust to generate a layout that pushes frequently used letters to the right places, and then arranges the surrounding letters to reduce typos? If this consumes too much processing power for normal use, there could be a separate learning mode during which you would tolerate the slowness, and later switch to fixed mode. Or it could be like SpamAssassin - keystrokes (both correct and incorrect) are logged in some efficient way, and later you can train the layout engine when the device is not in use, perhaps even pushing the processing to a different computer. That would not be a good idea: there is no key layout so bad that's it's worse than one that changes out from under the user. ___ 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: Yet another finger keybord (gui mock-up).
On Mon, 2007-03-05 at 13:50 +0100, Gabriel Ambuehl wrote: On Monday 05 March 2007 11:34:47 Lars Hallberg wrote: Should be as clear as on the pictures... But You might need to look close... But the neo case have a hole for the nose for that special Clear yes, but also about 3 times smaller than on your desktop screen... purpose :-) Hopefully, You soon learn where the keys are. Which gives rise to the question of how to best arrange them... I have been thinking along very similar lines to this idea, except that I have been envisioning this as a stylus application. However I think it makes a lot of sense to have as an input method for both finger and stylus. From a stylus point of view it makes sense to treat the centre as a neutral or home position with letters being determined by the subsequent movements you make* (as drag vectors). This way you would not need to lift the stylus off the screen** -- movement would be relative to the position of the stylus at the end of the last letter. I think you could write very fast like this. *a hexagon arrangement would give you all the alphabet + common punctuation in unique combinations of two strokes. (Modifier keys/areas could be added for more). This would be very quick and easy to learn. ** Unless you were getting close to the edge -- but since movement would be relative you could just pick it up and re-center it. If you use drag vectors instead of actual taps on the buttons, you might get away with very short drags, really. Agreed treating it as vectors rather than as an absolute position makes it much more flexible. Paul M -- There are no innocent bystanders, what were they doing there in the first place? William S. Burroughs ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Yet another finger keybord (gui mock-up).
a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
Hey, great idea ! I'd be happy to use such a system. But there's a problem i didn't find an answear to: - the neo will have a monopoint touchscreen (at least at first) - a finger is way bigger than a detectable area - What point will exactly be detected while pressing somewhere with a finger? Plus, what about using the selection wheel / T9 ? Any news/details about this feature yet, by the way? Anyway, please keep up the brainstorming :) I was thinking about self-completion. On such a machine, we'll need maximum efficiency for passable on-the-go cmd line typing, and therefore we'll need to have some sort of T9 for command line, sophisticated autocompletion (sh should do that i guess), if we also want parameters autocompletion. What will the embedded terminal be? GPE's? Thanks Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
