Alternate titles: Swipe to refresh.
The user wants to to retrieve more data or refresh already available contents on the screen.
As the user pulls down on the screen with a finger, visual feedback (refresh indicator) appears at the top of the list showing a progress of content update. If the user releases before reaching the refresh threshold, the refresh aborts and visual feedback disappears.
A user’s wait time begins the moment he initiates an action (swipe the screen for content update). Immediately after that, the application should provide a visual feedback in order to communicate that it has received the request. The user’s confidence in the fact that the refresh is happening, is directly correlated to the visual feedback. You will want to let your refresh indicator continue spinning until data is loading in order to engage the user and prevent confusion.
Refreshing content should only be triggered manually by user why the refresh indicator should appear only in conjunction with a refresh gesture. If you do want to notify users about automatically updating content (syncing), you should refrain from using the same indicator.
Refresh indicators act as intermediaries between different states of the view, helping users to understand what is going on as the screen changes. Refresh indicators should remain visible until the refresh activity completes and any new content is visible, or the user navigates away from the screen.
Pull to refresh are sometimes considered as an extra unnecessary step to refresh, as the user has to manually trigger refreshing or the loading content process of the application. As the pull-to-refresh gesture signifies a manual request for updates, it requires a user involvement into the process and creates a superficial layer between users and their content.
In most cases such kind of operations can be performed automatically using auto-sync procedure, without user involvement. For example, when users use Gmail in the browser on their desktops the service show them the latest emails automatically (and keeps the inbox up-to-date in the background). So why would email clients on mobile devices act differently?
Manual refreshing do provide benefits for the user interface, and can act as a great supplement to syncing:
Using the Pull-to-refresh pattern helps the user perform a content update task, but this pattern isn’t universally applicable and has its own downsides.
Many developers consider using ‘pull-to-refresh’ as a way to save space on screen (remove UI clutter). While it obviously saves screen estate (nothing is visible on screen at all), users have to know it’s there. Gestures are hidden controls. Thus, it’s not as intuitive as a visible “Refresh” button. A visible refresh button is easier to implement for developer and to use for user (since it’s always visible and available).
You might want to consider a refresh button…
Consider no refresh button (or auto-refresh in addition to a button) whenever the things are changing too fast (refreshed becomes stale within a minute or less). Examples:
Pull-to-refresh feels natural on a mobile device, but it looks kind of odd on the iPad (especially in landscape mode). It’s almost impossible to update the content using one-thumb interaction — you need either stretch your thumb or put the device on a flat surface in order to comfortably operate with user interface.
In the Google Chrome app, the functionality of the pull to refresh interaction has been expanded with the ability to perform two other actions — open a new tab or close the current tab. Like the standard pull-to-refresh design pattern, pulling down on the screen and then letting it go will just refresh the screen:
However, when user pulls down and swipe right, Chrome will close the current tab. Alternatively, swiping left will open a new tab. This augmented pull-to-refresh interaction gives users three possible actions to choose from, instead of just one. Opening a new tab with the augmented pull-to-refresh interaction is much more efficient since it can be done with just one smooth gesture.