Imagine a full width image slider that slides to left and right in a page that can scrolled to up and down. When user touches the screen and move her finger to left and right we want to change the slider slide. When user moves her finger vertically we want to scroll the page.

We can avoid any scrolling when a touch starts from slider area or we can allow scrolling in that area and at the same time do the slide change animations. (this cause a wired two way move of slide) OR we can look at direction of touchmove event and decide which action to is best the best fit for the touchmove.

enter image description here

Which approach is better and why?

  • This may be a little beneath your level, but Stephen Woods (iPad / touch mobile HTML5 developer at Flickr) has a really good YUI Theatre presentation that (sort of) touches on this, as well as responsive touch design. Someone might find it useful: "Stephen Woods: Creating Responsive HTML5 Touch Interfaces" youtu.be/lcD9CF0bxyk
    – msanford
    Commented Jun 21, 2012 at 4:54

3 Answers 3


I'm sure this is not the answer you want to hear, but there are THREE behaviors that should be implemented. When a user's touchstart occurs outside the slider area, the default behavior should occur (either scrolling or a link click ect.), but when the touchstart is inside the slider area one of three things needs to happen:

  1. Lock touchmoves to the slider, and only slide.
  2. Lock touchmoves to scrolling, and only scroll
  3. Allow both scrolling and sliding simultaneously.

Which one you pick is based on thresholds and requires some tuning. I will give an example of what has worked for me:

enter image description here

Here the center of the circle is touchstart. As the finger moves away from the center if it falls within the 'green' area (2) lock to scroll. If the touchmove falls into the 'orange' area (1) slide only. If neither, 'blue', then (3) do both.

The idea here is to attempt to make the behavior reflect user intent. I encourage you to experiment with the threshold of degrees, as well as how far the touchmove must fall from touchstart before you measure angle ( I use 10px ).

The idea here is to never let a touch fail. No matter where the users touches the display, the expected interaction should take place. Choosing any specific behavior to always occur, with the foreknowledge that the user may expect a different behavior is bad UX. We should always attempt to have our applications behave as expected, even if the user does the 'wrong' thing.


I would say, determine the appropriate action based on the users touchmove event no matter where they are in the page. Users that have touch devices are already accustom to many of the different gestures and touch actions they can make. Also because of the freedom of how touch devices work they is an expectation for specific actions like moving their finger up and down the device will cause the page to scroll.

By allowing touchmove events to originate from any location on the page you eliminate the possibility of user frustration from a touchmove event being ignored because it originated in one area and ended in another. Even more frustrating to a user is for a unexpected action such as advancement of a slider to occur when a gesture clearly is to scroll but was ignored because of the location it was preformed.

While common gestures have for the most standardized across devices, device sizes have not a its quite possible some devices might become more frustrating to some users if there events are limited for different sections of a page. The freedom brought by touch devices can quickly aggravate a user if a common gestures stop working as they do compared to other sites and apps.

If you are worried that some users might not know how to use the slider on a touch device, look into different method of informing users of the type of actions they can take when working with your content. Just make sure that this additional information does no continually distract the user. Constant nagging of contextual help can be just as frustrating to repeat visitors. The example mockup below shows what I mean by contextual help.


download bmml source – Wireframes created with Balsamiq Mockups


I brought this up in a question that I answered recently: I can't come up with a single time where I've appreciated the dual-scrolling "ability" that some apps have. I am OK with it in the latest Google Talk app on ICS because you rarely scroll up/down, so swiping left/right to change conversations is sensible. This happens on the Blackberry Playbook, as well - the app drawer is paged, but bafflingly also scrolls down, making me think I'd lost several icons for a while.

I have similar issues with some apps that use a swipe gesture for page turns, yet allow zooming in on the content. You end up getting bumped up against the page-turn margin without expecting it as you scroll around the page.

It does look like your case is slightly different in that there are two separate sections of content in the app. In that case, I'd recommend making the image at the top narrower than the screen width so the user can see the next image hanging off the screen. Add in a separator between the image and the text at the bottom and, similarly, hang the text off the bottom of the screen so they know to scroll.

This modification is actually implemented in the Google Play App - you can swipe to see an app's images, and, in the same screen, scroll to view more of the description.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.