Why Pull-To-Refresh Isn’t Such a Bad Guy

A couple of weeks ago, Austin Carr wrote a post titled “Why The Pull-To-Refresh Gesture Must Die”. The article is pretty much what the title implies– an explanation of reasons why pull-to-refresh is no longer needed and should go away. Ignoring the overly-aggressive title, the post simply doesn’t make a compelling argument for why we need to abolish pull-to-refresh. At best it offers some reasons why developers may want to reconsider whether or not their app needs pull-to-refresh.

A Different Gesture, A Different Time

The primary reason given for killing pull-to-refresh is that the gesture was designed for a different time – “smartphones are fast and strong enough to auto-refresh.” I’m not sure what Carr means by “strong enough,” but most smartphones are certainly capable of faster connections today than they were a few years ago. Carr goes on to explain that the reason developers can’t drop pull-to-refresh is it’s so universal at this point that users have come to expect it. Finally, Carr quotes Loren Brichter (the creator of pull-to-refresh): “The fact that people still call it ‘pull-to-refresh’ bothers me–using it just for refreshing is limiting and makes it obsolete. I like the idea of ‘pull-to-do-action.'”

With this, Carr argues that the pull-to-refresh gesture needs to evolve, which is the one part I agree with. My problem with the article is the first two parts: arguing that pull-to-refresh is no longer needed and that the reason it still exists is simply because users are used to it.

Not There Yet

The era of slow and unreliable data connections has not passed. Slow data connections are still very much a reality, particularly when you expand your view outside of the US. We can’t assume that all users will be on devices with reliable broadband connections at all times.

The other problem is that pull-to-refresh isn’t just a refresh strategy. Pull-to-refresh is about giving users control. Apps should handle refreshing data in a sensible matter wherever possible. Developers should make informed decisions on which feeds should refresh how frequently, and for the most part this isn’t something users should have to worry about. However, many of us are familiar with the scenario where an app is displaying what appears to be stale data and it’s not immediately clear why. Maybe the app isn’t refreshing like it’s supposed to. Maybe the app isn’t refreshing as frequently as you want it to. Maybe the app tried to refresh, but the connection timed out. Maybe the app tried to refresh, but the server had an error. There are a lot of things that can go wrong when refreshing data, particularly on mobile platforms.

When a user is staring at an app with what appears to be old data, pull-to-refresh is one of the few mechanisms that can give them some control over the situation. Automatic refresh strategies are transparent to users which means when problems occur, no error should be shown to the user (most of the time). Pull-to-refresh is an explicit user action which means if a problem occurs, feedback to the user is warranted and expected. If an app is failing to update in the background, it can silently fail and periodically retry to refresh the data. But if a user notices this, they should be able to manually attempt to refresh the data and if there is an error, see it. Even when data is properly refreshing, pull-to-refresh can offer reassurance to a user who’s not sure if it is. If the most recent tweet I see in Tweetbot in the middle of the day is 20 minutes old, I’m inclined to think my timeline hasn’t refreshed recently. Pull-to-refresh enables me to ensure my timeline is up-to-date, while also providing the perfect place for Tweetbot to display a last updated timestamp.

It would be delightful if apps could instantly show new data in realtime, but we’re not there. Even Carr’s own example of Gmail on the desktop doesn’t do this. Gmail does update in the background, that much is true, but it still refreshes on an interval; a delay still exists between when a new email arrives and when Gmail refreshes and is able to show it. Users can click the refresh button, or click on Inbox to manually refresh it, but by no means are they required to if they’re okay waiting for an automatic refresh, just like how pull-to-refresh works in most iOS apps. Nobody would argue that a user should have to manually refresh any time they want to check for new emails, but it makes perfect sense to leave mechanisms that allow users to refresh manually when they want to.

Moving Beyond Pull-To-Refresh

Carr would like to see more developers experiment with new interactions for swipe down gestures, and I cautiously agree. Pull-to-refresh is one of those ideas that seems so obvious in hindsight, but took a talented engineer to think of it. The brilliance of pull-to-refresh is just how well it fit into the existing design. When users try scrolling past the top of a table cell view, they’re trying to view newer content. Pull-to-refresh intelligently extends that scrolling to have an app refresh the content to load any new data. A perfectly logical and intuitive extension of the existing functionality.

There are a lot of very intelligent developers and designers out there with ideas. Some good ideas, a few brilliant ideas, and a lot of really really bad ideas. We will continue to see pull-to-refresh evolve and adapt. However, there’s a big difference between identifying a need then engineering a solution, and designing new crap for the sake of designing new crap. If you have an idea to improve usability with an interesting gesture, then do it. In the meantime, if you have an app where pull-to-refresh makes sense, there’s no need to shy away from it.