SOK

Differences between revisions 5 and 6
Revision 5 as of 2006-05-17 12:57:39
Size: 5087
Editor: vodsl-7993
Comment:
Revision 6 as of 2006-05-17 17:40:58
Size: 5180
Editor: vodsl-7993
Comment:
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
 * A way to do the right click by using the left click; maybe by activating a button on sok

A simple on-screen keyboard

Summary

A simple on-screen keyboard will be useful for those who are not able to use a standard keyboard, either due to a disability, or because they use a tablet PC, or because the device they are using does not have a physical keyboard (information terminals at expos), or wish to input in a language for which they do not have a keyboard (usually with a different glyph-type).

Rationale

The Gnome On-screen Keyboard is a flexible application for entering text with the pointer or with switching devices. However, it is highly complicated, trying to solve many problems.

There is scope for the creation of a much simpler on-screen keyboard with fewer features but greater stability and usability. In order to make it really useful, the on-screen keyboard should provide as much as possible, the same functionality as the physical keyboard. Further the on-screen keyboard should be available as soon as possible when starting the computer (login screen).

A focus not only on accessibility, but also on tablet PC hardware and localisation would create a wider user-base with more testing and development.

Use cases

  • Liza is a student who uses a head-mouse device to interact with her computer. Her school has migrated all their desktops to Edubuntu and she would prefer to use that as well. She can move the mouse cursor by moving her head and can activate the left click using a specially designed button. She is not able to use a normal keyboard, but can work quite efficiently with an on-screen version. The head-pointer uses a standard PS/2 connection and is the only pointing device connected to the computer. She can navigate the Gnome desktop and the web perfectly well with this setup so she only needs the on-screen keyboard for text-entry.
  • Eduardo is a travelling sales rep. who gives presentations to customers on his tablet PC. For major text entry he can unfold the physical keyboard on the device, but using an on-screen keyboard is often more convenient.
  • Signe has started learning Russian and wants a simple way to input some Russian characters without putting sticky tape on her keyboard.
  • At expositions there are sometimes terminals consisting only of a screen where the visitors can get informations. The on-screen keyboard will improve the interaction with this devices.

Scope

Design

  • The basic initial configuration is a simple Qwerty Keyboard (or local equivalent), without keypad, function keys, etc.
  • Additional keys can be supported as add-on panels that slide out from the main one.
  • The keyboard is by default configured to be always on top, even if the active application takes over the whole screen
  • The keyboard is continuesly resizable
  • The keyboard can be reduced to a floating resizable icon by clicking on a button on the keyboard (instead of turning it off); by clicking on the icon, the keyboard reappears
  • Pressing virtual key sends a letter to the active window.
  • Modifier keys, like Shift, Ctrl and Alt are included; a single click on a modifier will make it stick until the next keypress; a double click on a modifier will make the modifier stick until the next click on the modifier; the preferences of sok contain an option to make a modifier sticky with a single click, thus eliminating the distinction between single- and double-click
  • A way to do the right click by using the left click; maybe by activating a button on sok
  • Can be launched from panel applet

Implementation

  • Use a higher level framework like python and pyGTK.
  • Use the existing XML file structure used by GOK and port the keyboard parsing code to python.

Deferred features

Some features which currently exist in some on-screen keyboard should be kept out of the first implementation in order to keep it simple. These could be implemented later as plug-ins.

  • Multiple pointers, scanning and dwelling
  • Predictive Word Completion; single word prediction, multiple word prediction by learning expressions used by the user even if they are not grammaticaly correct
  • Multiple dictionaries and user-dictionaries that can be individualy and simultaneously activated; so the user can create dictionaries for different purposes and activate only those that he needs; for example a dictionary with the names of friends,...
  • Macros
  • Full desktop navigation (menus, etc.)
  • Anti-pointer-grabbing measures

Outstanding issues

  • Should we use the Sticky Keys feature of Gnome to keep the key states of Shift, Alt and Ctrl or should we

BoF agenda and discussion

References

Accessibility/Specs/SOK (last edited 2008-08-06 16:14:01 by localhost)