While the original thought behind pull-to-refresh was to take advantage of the scroll motion, which a user would use to see if any new messages appeared at the top or bottom of the list, to refresh a list and see if there isn't something new.

Unfortunately, this pattern is being used where that no longer applies -- for example, to refresh Chrome pages -- and it's not very discoverable. Is there any research on whether people have problems with this gesture, and, conversely, whether they expect it in all apps with refresh now?

  • 3
    Always assume hidden functionality is a problem. Some people will definitely not know it was there. I upgraded to a new phone a month or so ago, but didn't realize this was how you refresh a page in Chrome until your question prompted me to try.
    – user31143
    Jul 27, 2016 at 14:03
  • I want to note that it's certainly gaining traction as a standard UI function, Android phones use swipe from the top as a way to un-hide the menu bars. Google uses it in its "Inbox" email client and, of course its youtube app. Reddit, Facebook and Twitter are also doing it too. It won't be too long until its considered mainstream. Sep 12, 2016 at 21:57
  • I've lost my "open remote positions" emails because wasn't aware (just forget) about that "pull-to-search" Apple's standard mail client feature. I think that Apple should burn in hell fire because of the wrong adoption of Twitter's idea (they provided an alternative button in past). The world is mad. No more UX research based design. Let's make mad ideas just popular! Crazy, right?.. Apr 19, 2017 at 18:41
  • "Reddit, Facebook and Twitter are also doing it too." - the fact that most popular guys doing the same never means that they "doing the right thing" LOL. Apr 19, 2017 at 20:02

1 Answer 1


I do not think that there is publicly available research specifically on the pull-to-refresh feature. However, I synthesized some similar materials and came up with an answer of my own.

Taps vs Swipes

Swipe gestures are faster and easier, but often considered "hidden."

Florian Weil's research on touchscreen gestures concludes only that screens are best paired with thumbs as opposed to the whole hand or arm. Pulling down (usually with a thumb) fits the bill. Likewise Jianwei Lai's findings point out that swipes are more reliable than double-taps and faster for the user. UserInsight weighed the pros and cons between taps vs swipes in general which coincides with your question's observations:

Our research has shown that often the only thing that causes people to swipe is the knowledge of the convention of swiping itself. [...] Users who are unfamiliar with the convention of swiping may completely overlook the interaction and miss features and functionality because of it.

Twitter's Delicate Balance

Enough said: Twitter invented pull-to-refresh, yet they supply a button.

In my original draft of this answer, I pointed out that Twitter pioneered the pull-to-refresh gesture. When you use twitter today, there is a button presented as an alternative method however. Despite that the gesture was absorbed into the mainstream by Apple. If there are new tweets in your stream, a button will show either at the top of the screen which you can tap, or at the bottom if you're scrolled down far enough. It's a very tiny button, but because the pull-to-refresh feature exists they can afford to do that. The button at the top still gives you instructions. It reads "Pull to refresh" so you know how to work the gesture. And once you know how to use the gesture you may not want to go back to using anything else. Twitter's nailed a delicate balance between satisfying a user that wants a button, educating a user that might not know that pull-to-refresh exists, and satisfying the power user that assumed it was there all along by making the reminder UI so small that it's impact on the experience is negligible.

Pull-to-[Action] Fragmentation

A 2013 Fast Co.Design article scythes at the pull-to-refresh feature because despite being innovative, the pull down action was ubiquitous and being used for things other than refreshing a page.


When users open Jawbone’s Up app, for example, it automatically syncs and updates with the company’s companion activity tracking wristband, UP24. So now, when users pull-to-refresh, Jawbone instead displays a bite-size, digestible summary of what data was just transferred when the program synced.


on Apple's home screen in iOS 7, pulling down now gives now users access to a search box

Why [Action]-to-Refresh At All?

Because losing your place is annoying

HTML4's <marquee> was pretty popular in the late 90s. The trouble with a ticker is the same as Twitter's old live stream: as you're trying to read, the text keeps moving away from you. As more applications developed ways to stream in data, there's been a growing number of developers trying to figure out the technical issues of how to make applications reactive. Reactivity means that as soon as a change is made anywhere, it's propagated everywhere else—think Google Sheets shared between 2 or more users simultaneously. But instantly updating your UI to reflect changes from other users sometimes is an annoyance. The designer needs to make sure that the user won't get disoriented. There are lots of people trying to figure out how to take advantage of reactive frameworks wisely because too much reactivity isn't just disorienting, it also is expensive for the server, the browser, the app, the user's data plan, etc. Some related subjects that might interest you would be "Optimistic UI." In an ideal optimistic-ui method of refreshing, you would silently get new posts as they are ready, contents and all. Then when the user decides to refresh, you present the stuff in RAM instantly, while double-checking the server for anything else. If there's anything that was missed, update a second time then stop.

A Final Thought on Infinite Scroll

Think for a moment about infinite scrolling. The user has a batch of content, and when they scroll down, the next batch is fetched. In the best case of Infinite Scroll, the user doesn't notice that the computer is fetching more batches. Typically, the scrolling direction is down as the user travels further into the past. The end of the stream is the oldest piece of content, and it's usually understood that the user can stop scrolling.

Now consider the opposite. What would an upward scroll that goes in to the future look like? Almost exactly the same with one caveat: reaching the end of the stream. When the user reaches the present—now—how do they know that the "now" that they're looking at is actually "now"? You could design the content to keep populating upwards while allowing the user to keep their place until they're ready to keep scrolling up. And just the same, you could give them a sanity check so they could ask on command if there is anything newer than what they're looking at. And if scrolling for more is already in place... scroll to refresh seems like a natural pathway, and I think that's maybe why we're all so comfortable with the idea of pull-to-refresh.

  • Pull-to-refresh and notifications about new tweets are fundamentally different. The former is used by a person to check on new items manually, the latter is used when the items are refreshed by the app (which can happen at different intervals).
    – Tin Man
    Jul 27, 2016 at 22:07
  • 1
    The article you link to describes reactive programming. It's not research and it has nothing to do with the pull-to-refresh gesture.
    – Tin Man
    Jul 27, 2016 at 22:09
  • 1
    @TinMan I'll be first to agree that it's not pull-to-refresh specific. If you don't find it useful, that's fine. I've been looking for something more useful for you, because I want to help. It's a difficult subject to find very specific primary sources on. I don't think there is any. The closest we'll likely get is a theory built on fragments. Meanwhile, I'd appreciate you being constructive; contributing whatever you're finding. Jul 29, 2016 at 13:51
  • Sorry if you took offence to what I wrote -- I didn't mean any. I still don't understand how the article (about reactive programming) you linked to at all pertains to the question I asked, though -- care to explain?
    – Tin Man
    Jul 29, 2016 at 17:06
  • 1
    @TinMan I just reworked the answer so that it's hopefully more useful. That's about as much time as I think I can put in to this one. Maybe someone else can dig up a better specific research paper that I'm not finding. Aug 11, 2016 at 18:58

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.