Skeleton Screens and Loading Spinners

 

Members should be able to pull (swipe) down on any of our main tabs to refresh those screens. While they are swiping down a loading spinner appears to indicate they can pull down to refresh. While we check for updates, the member sees a loading spinner spin directly above the content that is refreshing. Once the update is complete, the page slides back up and the loading spinner disappears. 

We use one loading spinner design throughout the experience.

 
 

Where possible, we use skeleton screens instead of loading spinners. Skeleton screens build anticipation for the content that is going to appear whereas loading spinners (and progress bars) put the focus on the wait time that the member has to endure. 

When the app is refreshing an already loaded screen (rather than loading content for the first time) it is okay to update content in the background (without a loading spinner or a skeleton screen). For example, on my day, after content has been loaded for the first time using a skeleton screen, it is okay to update content in the background in subsequent refreshes. 

 

Where possible, when we know the general visual structure of a screen, we should use a skeleton screen to indicate that the page is loading. Examples of this are Connect, Food details, Coaching.

While we load a screen, the member sees a skeleton version of it (similar to what a wireframe for that screen would look like). Pieces of the screen update as content comes through from the server.

When showing a skeleton screen, don’t allow scrolling until the content loads. This is important for screens that have paging, so the member doesn’t continue to scroll and make calls for more content before the previous call is complete.