A method must be provided to input text that is simple, natural, requires little training and can be used in any environment.
Value in standing, moving, difficult environments, or for populations (or cultures) with little or no experience with keyboard entry, or no standard keyboard for the data type...
Pens work with gloves... etc.
Pen input devices may be used for multiple types of interfaces, and will often be the primary or only method for the device. This pattern covers only character and handwriting input and correction. Although any pen input panel should also support a virtual keyboard, this mode is covered under the Keyboards & Keypads] pattern.
...a couple modes (natural character entry, short-hand character entry (like Graffiti), word entry;
In certain cases, such as where the note taking must be as fast as possible, or the user is combining images, formulas and other data with words, a mode or application may be provided that will store the gestures without live translation. Later, the user may select all or part of the gestures to translate. This behavior should follow the pattern covered here when similarities arise, in order to preserve a consistent interface. Portions will, of course, be different.
...Make sure to mention finger-as-stylus inputs as an aside. Just emerging, but technically possible to do much the same with letter and handwriting recognition.
trace the path taken, in no-shit real time, then translate to words as fast as practical
The translated phrases are the same as the candidate words as discussed in Autocomplete & Prediction. See that pattern for additional details on presentation and the interaction to select alternatives.
Autocomplete and auto-correction is very similar to that used with any input method. Translation and is discussed
To provide sufficient space for the user to write, scrolling must be allowed for within the input panel. When the panel is filled, the system may automatically scroll, or the user may be allowed to scroll manually instead, to enable review and correction. Avoid dynamically adding additional space to the input panel, as this will just obscure more of the screen.
WHEN DONE??? WINDOWS MAKES YOU ACCEPT THE INPUT, LIVE TYPING MAKES SOME SENSE THOUGH ALSO. PRESENT BOTH.
mode switcher (character vs word)
Some provision must be made for functions which are not visible characters, such as line feeds, ok/enter, backspace and tab. These should be keys visible as part of the input panel.
Gestures may also be supported for the user to more quickly input key functions. However, these will require learning, so should be used as a secondary method in most cases; continue to provide keys for these functions as well. ...Win7 gesture to insert corrections, etc.
Writing is entered into an input panel that appears as a part of the screen. For small screens, this should always be a panel docked to the bottom of the viewport, and should automatically open when an input field is placed into focus. For larger screens, the input panel may be a floating area displayed contextually, adjacent to the current field requiring input. This panel must always be below the input field, to prevent obscuring the information.
For very small screens, the input panel may take up essentially the entire screen. In this case, special consideration must be taken to display the text already entered in order to provide context to the user.
When input is completed, the input panel should disappear to allow more of the page to appear. HOW TO CORRECT???? MENTION THE BUTTONS ABOVE< BUT WHERE ARE THEY>???
If the pen can be detected as a unique item, the input panel may be placed anywhere on the screen. Otherwise the panel must always be placed to avoid accidental input, usually along the bottom of the viewport. Resistive and most capacitive screens will perceive multiple inputs and may not be able to tell the difference between the pen and the user's hand.
icon to open panel...
For individual character entry modes, each character should be given a discrete space in which it may be entered. This may be accomplished by simply dividing up the word entry area with ticks or lines, or may present a series of individual input panels.
Cursors -- and all other stuff inside the entry area, are still suggested, for the reason they work on mouse, to express modality; are you on a link, or in a particular tool, you get a different cursor) --- Also a cursor for the entry point, even if just a very small dot or crosshair.
The space taken by input panel must be considered by the page display. Do not allow important information to be obscured by the panel. For example, do not make it so the panel must be closed to scroll to the bottom of a form so the submit button may be activated. Consider the input panel to be a separate area instead of an overlay so items may be scrolled into view.
Handwriting recognition can be very fast and about as error prone as typing on a keyboard. However, correction methods and other parts of the interface can serve to make the overall experience very much slower...Reduce clicks... use gestures, easy access to modes, and predictive stuff to avoid the user having to manually launch the panel, manually switch to another mode to edit, etc.
...Avoid loosing user entered data. Reference exit guard/cancel guard about this, and make a point of the system having to preserve entry even with important warnings popping up, etc...
separate entry areas are generally no longer required technically so are not suggested unless there /is/ some specific technical reason... in which case, make sure that area works as well as possible...