Debouncing
A user's single touch on the screen may be interpreted as two touches. On a pressure sensitive resistive display, the pressure of the user's finger might be uneven resulting in more than one touch. Or a user might start to remove their finger and then hesitate leading to an action similar to a double click on a mouse button.

In some cases pressing a button navigates to another screen and the button that was pressed to cause the navigation has now disappeared. The user's finger is then left hovering over a non-sensitive area, or possibly the finger is touching a new button, which is unrelated to the button just pressed. It is very easy to accidentally activate this new button with the second 'bounce' on the same location.

Some of this can be avoided with an algorithm similar to debouncing mechanical buttons. If a press action happens a very short time period after a release, then treat it as if only a single press happened.

While this is a useful approach, it can be tricky to decide some of the thresholds. An alternative is to disable all buttons for 0.25 seconds after they first appear. This is always reasonable, since you do not want a user to press a button that they have not had time to read.

Orientation
When arranging the layout of touch sensitive buttons take account of the fact that a user's horizontal control of their finger is far better than their vertical control.

Users tend to drag down slightly, perhaps due to the way knuckles bend, as they lift their finger from a touchscreen. This raises the danger that they might touch a button just below the one they intended.

So a button in a horizontal row of buttons, as seen in Figure 5 below will be an easier target than a button of the same size in a vertical row. If you have to use vertically arranged buttons then try to give them more separation than you use for horizontally arranged rows of buttons.

This difficulty with vertically arranged items is the reason pull down menus work fine in a mouse driven interface but do not transfer to a touchscreen. I have observed another behavior which can lead to error with vertical lists of buttons. Users are inclined to touch the lower half of the intended button.

Possibly this is so that the text inside the button can still be read. Whatever the reason it increases the chances that the detected touch position will be below the visible area of the button. The touch might then be in a non-sensitive are leading to no action, or it might be in the sensitive area of a button below the one intended.

One way to make an allowance for this is to make the sensitive area of a button extend a larger distance beyond the lower edge of the button and a shorter distance above the top.

Windows 7 has implemented an interesting touch enhancement. Some vertical menus open with more spacing between items, whenever windows detects that the menu was opened using a touch event and not a mouse.

This is a refreshing acknowledgement in the world of desktop operating systems that you can not simply replace a mouse with a touchscreen and expect a good user experience.

Multi-touch - or not
While the iPhone has made detecting multiple simultaneous touches a trendy topic, on many applications this has limited use. If your GUI consists of buttons and simple data entry then you may not need the kind of gesture detection appropriate on a device which supports image manipulation.

If your screen can only detect a single touch, it is important that you consider the possibility that a user might accidentally touch more than one place on the screen at the same time.

If the screen is mounted close to the horizontal then the user may rest the heel of their hand on the display as they touch an item with their finger. A vertical orientation makes users inclined to rest the hand that they are not using on top of the display, and sometimes that hand will touch the touchscreen while the active hand is pressing buttons lower down.

There is no perfect solution to these scenarios, and most common touchscreens do not give you a way to detect that this has happened. If you can detect that there are multiple touches far apart on the screen, then the best policy is to ignore all touches until you get a single touch again.

If you can not tell, as with a resistive touchscreen, then there are a couple of scenarios that you should consider and bring them into your test suite. On a resistive touchscreen touching in two points which are far apart usually results in the driver returning a point which is in between the two touched points.

Consider the scenario where a finger is on a button which the user has pressed, but not yet released. If the user then accidentally touches another part of the screen, the software will see this as the touched point suddenly moved to a place half way between the intended touch and the accidental touch.

Assuming that the accidental touch was brief, the position will revert to the correct position after the accidental touch ended. This is a second motivator for allowing the touch location to move out of the button and back in since the touch location's sudden jump away from the button and back again will still allow the user to activate that button.