How to implement a delay to prevent inadvertent clicks on a touch screen

Question

I'm developing an app that asks users to fill in a questionnaire which consists of multiple screens. Each screen includes the question text, a graphic, and Yes/No buttons that are always in the same spot. What we've noticed is that some users touch the screen multiple times and so inadvertently record "Yes" for a screen without having read it.

To prevent this we've implemented a delay so that clicks are ignored if they happen within 2 seconds of the page being shown. However this can leave some people who don't want to read the question (e.g. testers & trial users) confused about what the program is doing. Does anyone have an idea on how to indicate that the click was ignored due to such a delay?

I'd like to avoid requiring two clicks (i.e. first on a "Yes" then on a "Go to next question").

Answer 1

One idea would be to add an animated transition between the questions. Tapping an answer would slide the next question in view (or turn to new page?), and no touch events would be of course registered during the animation.

Answer 2

Hide the Yes/No buttons or replace them with a "loading..." indicator/graphic until the next question and image have fully loaded.

This way the user will know that they can't answer the question yet because something is happening (i.e. loading the question and image). It can also act as a feedback mechanism. Once the Yes/No buttons "vanish" for a couple of seconds, they'll know that their answer is being processed/submitted. Ergo, no need to tap tap tap on the screen for a response.

we've implemented a delay so that clicks are ignored if they happen within 2 seconds of the page being shown

Some users might actually increase the screen-tapping if their first few clicks are being ignored, thus encouraging more "bad behavior" in your users.

Better to hide the Yes/No buttons and let them think the answers are loading to avoid confusion about the responsiveness of the buttons. :)

Answer 3

You could make answering the question gesture-based with a slide button control with 3 states: not answered (initial state, center), Yes (slide left) and No (slide right). Multiple tapping then won't answer the question, as the user needs to physically drag the control to the left or right.

Plus this way your testers and trial users can still rattle through the questions quickly without reading them and without being forced to wait.

Answer 4

This is usually a function of one of two factors that hopefully are in your control:

1. Touch-screen hardware reliability (e.g. the application should register exactly the same number of taps as the user thinks they performed; sometimes a noisy capacitive touch screen with the threshold very close to the actual touch level will incorrectly resolve a single screen touch into multiple consecutive touch events)

2. Responsiveness of the application to input (e.g. user saw the button get visibly depressed, and saw some indication that their press was registered)

One of the main UX improvements I can recommend making to a desktop/kiosk touch-screen application is the inclusion of what we call a touch point. Windows 7 and 8 show them by default when configured correctly, or you can add them yourself in your software. The idea is that when the user touches the screen, a visible dot (read: larger than their finger) is shown centred on the touch event location. That emphasises to the user that their touch was registered (in the right place—users are relatively used to poorly calibrated touch panels nowadays), and that they're safe to wait.

Of course, that's no substitute for a real active state on all your controls and a properly thresholded touch panel, but it's a neat trick that had immediate value in our testing (mostly on novice users).

Answer 5

You could set the button text to count down the time until it is active.