The iOS platform relies heavily on the use of gestures to enable both basic and complex activities across the core OS and within applications. One such gesture is the “swipe” gesture, which in most cases is used to advance content within a view, either horizontally or vertically. It is a very natural way to interact with what’s on screen and is particularly suited to scrolling, being extensively used as such in iOS via UITableView and its’ superclass, UIScrollView.
UITableView and Vertical Scrolling
UITableView is perhaps one of the most common iOS UI elements. In it’s basic form, it displays a list of cells that takes up the majority of the screen and allows the user to scroll vertically by swiping up or down. It was used in many, if not all of Apple’s own apps from day one, and its’ presence is almost instantly recognizable. Additionally, while scrolling, UITableView (via UIScrollView) provides a scroll bar at the right of the screen and it is possible to programmatically flash this bar in order to indicate the ability to scroll. And so it is, that the swipe gesture in this case, does not have a discoverability problem. A user sees a list of elements on screen, and they know, that more often than not, they can swipe to interact.
The Problem: Horizontal Scrolling
What if however, you are presenting data using a UIScrollView in a horizontal orientation. If the UIScrollView has paging enabled, i.e the scrolling is paged, rather than fluid, the Apple convention is to use a paging indicator (the little dots that can be seen on the iOS home screen). That’s fine if there is a relatively small number of pages, but if there are too many pages, you run the risk of your page indicator running right off the side of the screen. If your scrolling is fluid, you have a few other options. You can rely on the scroll bar, programmatically flashing it when your view appears, but the user won’t be looking for this and might miss it. Alternatively, you can modify the size and number of elements so that part of the first or last element hangs off screen (this technique can be seen in Apple’s Trailers app). When trying to address this problem in Serentripiti, we were not satisfied with any of these approaches and opted for something more obvious.
Another Solution: NBSwipeIndicator
That something is a very simple UI element I’ve created called NBSwipeIndicator. In a nutshell, it displays a set of arrows below or above horizontally scrollable content to make it clear to the user that they can swipe to interact with said content. It supports the ability to dynamically show left, right, or both arrows, depending on which portion of the content is currently visible. This dynamic behavior can be driven directly or based on paging, so it should be flexible enough to support several scenarios. Finally, the arrows are drawn with CG routines so it is very fast, but also allows size and color customization. If you want to use custom art for the arrows, they are just UIView subclasses within the NBSwipeIndicator subview, so they can be easily swapped out with UIImageView instances.
check out the latest version of Serentripiti (it’s free), in the Trippy Creator (pictured above).
The source code is available under a liberal BSD license for use in your own projects and can be found on GitHub in my NBUIElements repository. If you use it, let me know what you think in the comments or contact me directly.