iOS and Android app - data download or page navigation first

Question

What is the best perceived UX for mobile applications which require data downloaded midway through the journey. I cannot find this information online in Apple's Human Interface Guidelines (or I am looking in the wrong place if so), nor Google's Material Design Guidelines.

Given the following scenario: say I have a contact list which contains a name, I then click on the contact and, in a successful scenario, the Contact Details are downloaded from the server (which contains more information on the selected contact), and that information is displayed.

However, this information may not be obtained each time (e.g. because of network coverage on a mobile device) and so an error occurs. What is best in terms of UX?

1. Display a "loading" animation; attempt to download the data; and display an error while remaining on the contact list. This saves unnecessary navigation, but can be perceived as nothing at all happening and in the worst case scenario, it looks like the app cannot even navigate to the user details screen. This also goes against MVC guidelines from a code perspective.

2. Navigate to the page; display "skeleton" text and/or an animation to indicate at least the user's action has been recognised... but in the event of an error is it best to display the error and:

   a. Navigate back to the Contact list; or

   b. Remain on the Contact Detail page.

3. Something else?

I mention MVC above, because each page should only be interested in the data it downloads and displays/handles and if item (1) above is the desired experience, the Contact details will need to be downloaded prior to being handed off to that page, which kind of goes against this pattern.

Answer 1

The issue is losing connection which is a system issue. System issues are top level, they affect everything so you have to handle them at the top level of your UI.

Apps that need connection should regularly check the connection and notify users if it's lost using dialogs or alerts.

Once you think about this, you'll see that it makes sense in every way. Instead of integrating messages everywhere IN your app, put one message OVER your app where it belongs.

This properly indicates to users where the problem is, in the system, not your app. Instead of having your app break down and try to explain how it's not your app's fault, have the system notify them and don't let it break your app.

Keeping users aware of system status is a popular UX concept from NNGroup. There's too much to link to.

REST is like a data transfer engineering concept. It's the best way to engineer web apps. It's all about optimizing backend processing and data transfer.

Answer 2

For (1), you would be effectively blocking navigation momentarily and potentially denying it, which may spoil the users perception of navigation throughout the app (can block discovery of the app and it's features purely because of a lack of or poor connection). Login vs. navigation. Gatekeeper vs. tour guide.

For (2a), you deny yourself the chance to retry (which would be the best solution, as long as the connection is reestablished before the user's patience runs out). It's a bit like a bouncer (gatekeeper/login screen) that let you slip through but boots you out moments after, not a pleasant experience.

(2b) is the normal way to do this, show stubs or progress/loading or cached data while loading and you have ample space to provide reasoning and controls in case of failure.

Consider whether prefetching all or partial amounts of contact data in advance (schedule to your/users' liking) will significantly benefit the user experience while not hurting battery and data use. It is one way to alleviate the lazy loading of detail screen data.

A neater way to handle connection failures related to important downloads on Android: invoke a service (foreground when app is in foreground, background when app is backgrounded and/or retrying) to handle the task as well as notify the user that the task is running. When app is in foreground, you can show that progress is underway + allow the service to show in the status bar - allowing the user to learn about the connection between those things. If app open and there is a failure, if a retry is not to be conducted immediately, the background service can do that whether the app is open or not.