Differences between revisions 1 and 10 (spanning 9 versions)
Revision 1 as of 2011-02-21 18:56:32
Size: 600
Editor: shoobe01
Comment:
Revision 10 as of 2011-02-26 14:17:55
Size: 3514
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Three-variants: Press and hold, press-twice, or dedicated secondary lock keys. Cover labeling of the modifier key and the individual keys: show the correct mode for virtual keypads, never caps labels when in lower-case, put the shifted label above it and gray if needed, as on a hardware keypad, etc. Make sure to keep consistent: avoid having one lock key and the rest use press-twice, but if you do then make sure there's a reason like access to the fn number pad is needed sometimes; never switch modes between virtual and hardware keyboards, or when you switch between keypad and keyboard, etc. I like this, and we've even seen an apple stylus patent (and since I typed this, several other tablets have them at shows, Synaptics has new cap screens with pen capability, etc... patterns are well-established and --

, so easy to do, and coming back into vogue so we'd be on the cutting edge. ALSO: I have been thinking that the only issue with handwriting is corrections (not error rate, but fixing errors) and just played with some Windows 7 tablets. They have fixed it. Really want that input panel on my tablet. Some stuff to learn there: reduce clicks, like offer gestures for state changes such as 'correct' which switches to a character entry mode.




== Problem ==


== Solution ==
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...

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.


== Variations ==
a couple modes (natural character entry, short-hand character entry (like Graffiti), word entry;

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.


== Interaction Details ==
panel auto opens

trace the path taken, in no-shit real time, then translate to words as fast as practical

mode switcher

Function buttons

Gestures for key functions; Win7 gesture to insert vs scroll then... etc.


== Presentation Details ==
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. 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.

When input is completed, the input panel should disappear to allow more of the page to appear. HOW TO CORRECT????

icon to open panel...

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)


== Antipatterns ==
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.

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.

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...


== Examples ==

I like this, and we've even seen an apple stylus patent (and since I typed this, several other tablets have them at shows, Synaptics has new cap screens with pen capability, etc... patterns are well-established and --

, so easy to do, and coming back into vogue so we'd be on the cutting edge. ALSO: I have been thinking that the only issue with handwriting is corrections (not error rate, but fixing errors) and just played with some Windows 7 tablets. They have fixed it. Really want that input panel on my tablet. Some stuff to learn there: reduce clicks, like offer gestures for state changes such as 'correct' which switches to a character entry mode.

Problem

Solution

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...

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.

Variations

a couple modes (natural character entry, short-hand character entry (like Graffiti), word entry;

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.

Interaction Details

panel auto opens

trace the path taken, in no-shit real time, then translate to words as fast as practical

mode switcher

Function buttons

Gestures for key functions; Win7 gesture to insert vs scroll then... etc.

Presentation Details

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. 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.

When input is completed, the input panel should disappear to allow more of the page to appear. HOW TO CORRECT????

icon to open panel...

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)

Antipatterns

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.

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.

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...

Examples

Pen Input (last edited 2013-03-13 16:36:15 by shoobe01)