The first issue is parallax which is the error introduced by the viewing angle. The second issue is that the size of the human finger means that there is an area of touch where the flesh of the finger flattens itself against the screen, and the detected touch point will be in the middle of that area.

This means that the user can not see the point that they have touched and so the exact place they think they have touched may be different to what the software detected.

Given that some error has to be tolerated, what can we do to minimize its impact on the user experience? Most touch events involve the user pressing a graphical button. With a mouse the visible area of the button is the clickable area. The user can see if the cursor point is inside or outside of the graphical button and so they know if a mouse-button-click will activate it.

A touchscreen user does not have the same certainty. So there is benefit in making the touch sensitive area bigger than the visible dimensions of the button. If the user presses quite close to a button, it is a reasonable assumption that their intention was to press that button.

If some of the buttons are close together there is the possibility that their touch sensitive areas may overlap, as seen in Figure 2 below. If the user then touches in between button A and button B, which one should the software respond to?

The best answer is neither. It is usually better for the application to do nothing rather than risk doing the wrong thing. A non-sensitive area between two adjacent buttons will force the user to retouch in a less ambiguous location.

Figure 2: Dashed lines show boundary of touch sensitive areas. A and B have overlapping areas and so touching the shaded area will not activate either one.

There are some special cases where a smarter decision can be made when the touch event happens in between two objects. If an on-screen keyboard is being displayed, then each button represents a letter of the alphabet. If the user touches in between two letters then a predictive text application could guess at which letter is more likely based on the preceding letters.

Release me
A button can be programmed to respond when touched or to respond on release. I prefer to respond to the release. It provides the opportunity to give visual feedback when the object is touched.

On a mouse based interface it might be subtle, like a dotted line appearing around the object. For a touchscreen you are better off being less subtle. Some, or possibly all, of the button being touched is obscured from view by the user's finger or hand.

A complete color change for the button is required, so that if only a small portion of the button is visible to the user then there is a noticeable change. Some systems also display a border around the touched object in the hope of making the indication visible beyond the user's finger.

The on-screen keyboard is a special case. Some applications display the letter touched with a larger rendering in the area above the finger. This allows the user to see exactly which letter will be activated once the key is released.

If the touch has not caused the button to perform its main action, then the user still has the opportunity to slide their finger out of the button in order to cancel the action.

Button state machine
Allowing the user to slide their finger out of a button gives them the option to cancel that button action. We also want to allow them to slide back into the selected button. The main motivation for this can be seen in the following scenario.

Consider a user touching at the edge of the touch sensitive area of a button. Finger shake or electrical noise may lead to the position of the finger moving out of the buttons sensitive area and back in again.

If we cancel the selection when we slide out, then the button will be cancelled before the user has the chance to perform a release by lifting their finger. A preferable interaction is to allow the button to be selected again when they slide into that button.

I have seen implementations which allow the finger to slide into a different button to select it but I am not in favor of that approach. I think it makes the display more likely to perform button actions due to a random touch, such as a person rubbing against the screen as they walk by. Forcing the touch and release to both happen within the sensitive area of the button makes random touches less dangerous.

This leads us to a simple state machine for a button as shown in Figure 3 below. This is also close to the operation of a typical button in Microsoft Windows.

Figure 3: The state machine of a touchable button

In the state machine highlighting refers to the visual change in the button color or outline to indicate that the button is about to perform its action as soon as the user releases their finger from the touchscreen.