Input Method
From Openmoko
Contents |
Overview
The Input Method Widget provides a general method for data input, supporting both handwriting recognition, and keyboards.
Usage Cases
- Commonly used in Native Stylus-Based applications.
Appearance & Interaction
Dock Keyboard Mode
- Typewriter Mode
- Numeric Mode
- Symbol Mode
Constraints
(TBD)
Architectural Details
UI Image Files
Download the UI images: click here
- bg_keypad.png -- Background of the keypad
- bg_input_switch.png -- Background of the Input Switch Area
- key_cap_*.png -- Upper case keys
- key_low_*.png -- Lower case keys
- key_num_*.png -- Numeric keys
- key_sym_*.png -- Symbol keys
- key_comm_backspace_*.png -- Backspace key
- key_comm_space_*.png -- Space key
- key_comm_enter_*.png -- Enter key
- switch_input_*.png -- Input Method Switch keys
UI Icon Files
(TBD)
UI Position
- Typewriter Mode
- Numeric Mode
- Symbol Mode
Implementation Recommendations
See some suggestions: Wish_List#Text_Messaging
Cross-Widget Interactions
(TBD)
Unresolved Issues
- What is the best interface for Chinese (Simplified and Traditional)?
- Do we want to have a Personal Word List?
Steven I think it is not necessarily in Chinese (Simplified and Traditional) environment, because many chinese input methods have auto-remember function.
Questions and Answers
Alex Q:About input method widget's position and size. Depend on application's type finger-based or stylus-based, will the input method widget to resize itself (for finger-based application it should be large enough to be pressed)? Where should the input method widget appear when it's first activated, the bottom or with the cursor? If with the cursor how to adjust its size and position?
(Sean Moss-Pultz) I really don't have the answers to these questions at this point. Can Shanghai please take some time and study various possibilites?
Alex So I get a reasonable solution,the input method is only for stylus-based application use. Finger-based application should only use finger as input. And the input method widget's position conventionally appears at the bottom of the screen and just above the footer. What do you think ?
Steven I also think a solution. 1) All input method widgets always appears the bottom of application area. 2) All input method widget's width is 480 pixels. 3) The three input method widget's size is not change between finger-based and stylus-based mode. they are Numeric Mode, Phone Mode and Date & Time Mode. 4) In Typewriter Mode, Personal Word List Mode and Symbol Mode, these widget's height will be adjust between finger-based and stylus-based mode. Applications with the three mode will adjust itself accordingly.
(Sean Moss-Pultz) These ideas all sound quite good. Let me talk with my graphics designers and ask them to draw up some layouts based upon these ideas. Please keep working with this methods in mind.
xkr47 Were the keys too small to be used in the below picture?
(User:Seba) Q: I did some calculations: One key of the Input Method Widget (the one on top of this page) is approx. 3 mm x 3mm? I got it right?
(User:Seba) Even for stylus use this is extremely small (imagine riding in a crowded bus and trying to write a message). Don't let the 480 pixel fool you. :-) I suggest to try out design variants with landscape orientation otherwise we need a pretty error tolerant dictionary algorithm.
(User:Flerchjj)We can also ascertain there is less than 18mm x 43mm in the image above for the keyboard, based off the resolution & screensize. It will be very hard to allow typing by finger, except in landscape. Using a stylus in portrait mode will be hard enough. Moving the keyboard layout selector on the side & adding it on the top or bottom of the keyboard can give some extra room for keys. The screen size is a huge limiting factor, I'd rather see a bigger screen without an increase in resolution. Just 10mm wider could make a big difference. Hopefully I'll get OpenMoko compiling soon & I can play with layouts on my PC. Maybe I'll just look at the c code for the moko-keyboard in the mean time.
(User:Flerchjj)I just had some great inspiration... A Double Click Keyboard. Press a key once and it's displayed at a larger size. Press it again and that key is accepted and returns to normal size. Press anywhere else instead and it returns to normal size without being accepted. It could increase reliability and make it more accessible to fingers.
(User:lhboi) Q: How to add additional keyboard layout? I am interested in having a Vietnamese keyboard layout. In X-Window, we can write a layout describing which codes generated by what keys. In OpenMoko, how do we do the similar thing? How about dead-keys, will there be similar things in OpenMoko? Another question about fonts, May I assume that OpenMoko renders Unicode glyphs well?
(User:Cg) I have been playing with an idea that could improve the accuracy of text input with tiny onscreen keyboard. This is an visual enhancement to a standard keyboard, so one should be able use it without learning any special strokes or so. I've made a small demo of how the concept works: Warp keyboard This might be an interesting alternate input method for OpenMoko. Maybe I'll try to implement this myself, but I will probably wait for the final hw... (I want WiFi;) Comments?
(User:Historybuff) I'm willing to help. I'd like to see something flexible for the dialer too, with audio feedback. Now I have to get Audio working. :)
(User:Abnormal) "Q: One thing that has come from the iPhone is the lack of the period key from the on screen keyboard and I noticed that the OpenMoko keyboard is also lacking a period key on the main keyboard. It is a widely used key(how many times is it used in web addresses alone,not even including emails). Why was the choice made to place it on a separate keyboard?
(User:Historybuff) A: I think there is room to add some things to the default keyboard. It is quite small though, and might only be really useful with a stylus.
(User:Rhuys1234) "Q: Some thoughts about on-screen keyboards. I have a Palm Tungsten, and I find the on-screen keyboard not productive, because you need two hands (one to hold the PDA and one to hold the stylus), you always have to focus your attention on the keyboard layout, and the keyboard itself occupies too much space. Furthermore, in vibrating environments, I find it very difficult to type without errors. I also have a Treo 650 (with a real keyboard), and after some practice, I can enter text blindly with one hand, due to the fact that your fingers have 'force feedback' on the keys, and you develop some sort of motoric memory. This is why I like solutions as presented on [[1]] more appealing. The idea from [[Werner Almesberger][2]] looks promising. I think a good PDA input method would need following properties: *1* single finger operation, *2* blind operation (after some practice), *3* not occupying too much display space (or no space at all, e.g. blind strokes). What do you think of these thoughts?
(User:Historybuff) A: Having used the onscreen keyboard on the 1973, I can say you can become adept at either fingernail or stylus-type input, even for things that are somewhat lengthy. That said, I still think that a one-finger option is something to look into.
