Patent Application
20200183531
This invention relates to virtual keyboards such as are displayed on smart phones and portable tablet devices.
To provide a large viewing area, smart phones and tablets have touch-sensitive screens that extend across substantially their entire surfaces. When keyboard entry is needed, part of the screen is used to display a keyboard, and the touch screen employs a map to generate entry of characters based on the section of the map that receives a touch contact.
With screens of limited size, the keyboards tend to be smaller than desired, leading to occasional and potentially frequent typing errors. To minimize the effect, the devices rely in part on spell correction to infer the intended word from the entered characters, occasionally leading to awkward errors.
In general, large and hurried fingers, small keys that are hidden by the fingers lead to some types of errors that may be characterized as “random” in that they are as likely to be errant in any particular direction.
However, in existing systems, a typical user may find that certain typing errors recur. For example, a user may find that instead of reaching far enough to select the central “space-bar” he occasionally errantly contacts the more peripheral “return” key, rarely if ever making the reverse error. Or a user may have any other predictable bias, striking certain keys on average off center in a selected direction.
There is a need to avoid such predictable errors patterns to reduce overall errors.
The limitations of the prior art are addressed by providing a touchscreen keyboard system for operating a smart device having a touch screen. The system comprises an array of key elements which can generate a map of touch sensitive areas, each corresponding to a respective key element. The touchscreen keyboard system detects error correction activity and based on detecting error correction activity, it will modify the map.
In the display area 12, a user has typed a message, and after the word “for has inadvertently touched the area of the “return” key image instead of the intended spacebar. This is indicated with touch center-point 24 and circular area of contact 26. Whether a device detect the first point of contact or infers a center point from an area of contact, the result is the same. As shown, the selected point is just to the right of the boundary segment 30 that separates the touch areas for the spacebar and the return key.
Typographic errors with small smart device touchscreens may have a number of sources. Some may be errors of user intent, “aiming” for the wrong letter. Others may be simple imprecision in which intentions are correct, but there is significant random or unbiased error in which aim is poor but in no particular direction. These are generally addressed with practice and care.
A second type of error occurs repeatedly, and may be specific to an individual, or a type shared by many or most individuals. This is a general bias. A typical bias is for a user who cradles a device in the fingers of each hand, and operated the keyboard with thumbs extending laterally inward and upward, each thumb covering its right or left half of the keyboard. In this example, many users may tend to find that their thumbs didn't reach far enough, and fell short from the intended key and struck laterally away from the intended key. This may be due to a psychological subconscious expectation that the tips of the thumbs are the making contact with the keys (when it is the pad of the thumb, some distance from the tip). Or it may be because users desire to see the key they are striking, and extending the thumbs far enough medially blocks the view of the desired key creating a reluctance to fully extend medially.
For an individual, repeated errors may occur due to physiological limitations or imbalanced thumb or finger shapes, or for any other reason particular to the user.
To reduce the frustrations and inefficiencies of typing errors caused by predictable tendencies, such as the “short thumb” syndrome described above, and touch grid or map may be developed that is offset from the apparent key locations. This can be set to minimize typing errors either for a population or for a user. There may be “types” of users that have certain errors other than “short thumb” types, and there may be several standard maps developed, one for each type.
In an alternative embodiment shown in
This is shown in two dimensions for illustrative purposes, but the preferred embodiment will generate a two-dimensional map placing the grid lines at the locations to minimize errors.
There are several ways to collect or generate the data from which to generate the shifted touch grid maps. A manufacturer may conduct extensive testing to determine what trends there are in broad populations to generate a default shifted map. If several “types” of users with different tendencies are found, then several default maps may be generated. Users with small fingers may have different common tendencies than users with larger fingers, for instance.
The preferred approach is to generate a customized map that is optimized for a given user. This may be created by a typing test that causes the user to type enough text to determine the initial distributions of keystroke locations for the standard keyboard. This may be effective, but requires a deliberate user involvement, and time to take the test. It also does not adjust for changes in user practices over time, requiring additional testing to reoptimize. A new device may have different characteristics, and many users will avoid the task of generating a new touch location data set from which to generate the remapped grid.
A system that bases the remapped grid on ongoing use, even potentially all the data over a significant recent period of time, can generate optimized results without the user even being aware of the process and without the time spent in a test.
During a data-gathering period (which may be ongoing) for every keystroke the system determines whether the keystroke was intended or errant. User correction such as backspace and retyping indicates an error. For example, changing “applw” to “apple” using the backspace key to erase the W followed by typing an E and proceeding shows that the “w” stroke was intended as an “e”. The location of the W stroke is put in the E distribution/population even though it was across the line. Similarly, if a user types “applw” and the autocorrect function corrects this, the system also records the same information about the error. Each keystroke location is stored along with whether or not it was an error, and if an error, the intended letter to which the stoke location should be assigned. If the auto-correct is an error and the user corrects this, it is noted. In the end, the intended letter is inferred by the final result, and the initial keystroke is assigned to that intended letter.
Some features may be used to ignore spelling errors that are identified by the system, but tolerated by the user. The system may have a bias to ignore strokes or words when in doubt, or to assume that results were intended when in doubt.
Whether in product development or in use, the system may track a score of a user's typing accuracy in order to determine whether implemented shifts of the touch grid are successful. If a change in the grid causes worse results, the system may revert to a prior more successful version.
Typing speed may also be used to generate different modes, because a user may have certain types of errors when typing fast vs. carefully. These differences may be caused by typing with two hands vs one, for instance, and have different error patterns and grid shift biases.
As shown in the right section of the keyboard of
Changes may be offered at an option to the user with specific prompts: “You are sometimes hitting the return key when you apparently intend to select the spacebar—do you want the keyboard adjusted to help reduce these errors?”
