I don't remember seeing this in any iPhone commercials...

Recently while running a grueling series of usability testing and QA on an in-production web app, I encountered a particularly perplexing issue that seemingly made no sense. When using the web app on certain mobile devices, tapping on buttons or links would have strange, unintended behavior, linking to seemingly random places within the app. It turned out to be a result of a rarely noticed, mobile-specific phenomenon I’d never heard of, known as a ghost click.

The issue was especially difficult to diagnose, and even accurately reproducing it in tests was tricky. Under the hood, everything seemed correct. On desktop devices, the web app’s buttons and links exhibited perfectly normal behavior. In a simulated environment, the behavior on mobile devices seemed normal. What was causing the problematic unexpected behavior on mobile devices? Our team was stumped. There didn’t seem to be an answer. Fortunately, after some research and testing, our UI engineering lead was able to accurately diagnose what was causing the problem, and fix it relatively easily.
Sounds spooky! Don’t worry, the app wasn’t haunted, though the way it was behaving, I certainly wouldn’t have ruled that out. Once I understood what a ghost click is, the problem made perfect sense to me.
Ghost click - A real UX nightmare

In order to understand, it's important to know what occurs behind the scenes when a user interacts with a touch device, and why those occurrences exist.

Most interaction designers are familiar with the two key events that occur every time a user taps a screen: touch interactions, and release interactions. An on-touch event occurs at the precise instant that the user’s finger touches the screen, while an on-release event occurs the instant the user’s finger is lifted off the screen. It’s important for mobile devices to differentiate between these events, because of the innate quality of touch screen input mechanisms: they are gesture based. When a user’s finger touches the screen, they may not necessarily be trying to click a button or link, right? They could be swiping to scroll, pinching to zoom, holding to save the image, or double tapping to zoom.

Typically, what’s happening is the device is looking for what occurs around the same time as the on-touch and on-release events in order to interpret the appropriate gesture, and how to respond. But how does the device know how long to wait in order to determine if the user is double tapping, swiping, etc? As it turns out, there’s a delay that is hard coded into the device before taps are registered as taps. It’s typically a delay of 300 milliseconds (less than one third of a second). This delay is crucial to help devices interpret gestures, but it makes the user experience feel slow, laggy and unresponsive, so developers tend to force interactions to occur on the touch or release events instead of the forced click event.

When a finger touches a screen, the device recognizes that it has been interacted with, and begins the 300 millisecond delay of waiting to see if the user does anything else (pinch, swipe, hold, etc). If the interaction just turns out to be a simple tap, and no other interaction is detected, the tap is then registered as a click (the ghost click), and the interaction is completed.

When is this interaction paradigm problematic?

There is a very specific and particular set of circumstances that need to occur in order to ever even see this problem in action.

  • The app needs to be fast, and I mean really fast. Specifically, the app needs to be able to basically change pages in under 300 milliseconds. In our case, the web app we produced pre-loads content on first load, and operates within a single URL. That means that when a user clicks a button or link, the transition to the next screen is near instant.
  • Interactions within the app itself would need to have been manually assigned to occur at the on-touch or on-release event, effectively bypassing the device’s native 300 millisecond delay.
  • The link or button that the user clicks on (or more specifically, the exact point that the user’s finger makes contact with the screen) would have to occur at the precise screen coordinates of a link or button on the corresponding screen. Since our web app used a tile-based layout, the actual clickable area was very large, covering most of the screen, giving a bigger area of potential overlap. Imagine overlaying two transparent screens over eachother, and seeing where interaction points could overlap between those two screens. Any one of those points is potentially at risk for being hit by a ghost click, if the app responds quickly enough.
ghost click - A real UX nightmare

Essentially what was happening in our case is a very strange series of events. The user would tap a link on screen 1, which registered with the web app, and takes the user instantly to screen 2. However, since this transition was instant, the device’s ghost click hadn’t yet occurred. By the time the ghost click occurred (300 milliseconds later), the app had already transitioned to screen 2, and the click occurred on screen 2 instead of screen 1. Since screen 2 utilized a tile-based layout, the majority of the screen real estate was interactive. When the click event landed, it circumstantially landed on a clickable area, instantly linking over to screen 3. All of this occurs in about 1/3 of a second, so from the user’s perspective, they never even see screen 2 at all, and feel as if screen 1 is linked directly to screen 3. Weird, right?

How do you solve a ghost click?

This certainly isn’t my area of specialty, so I won’t presume to try to explain a solution. I did, however, find a few technical resources that you might find helpful if you’re trying to solve a similar problem:

Gareth Botha

Author Gareth Botha

Gareth is a UI/UX Designer in Atlanta, focused on creating beautiful, engaging, usable and accessible user experiences for mobile and web apps and digital products.

More posts by Gareth Botha

Leave a Reply