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.

  • Does MVC try to define data loading? I thought it was just sort of a simple UI concept. REST deals with networked data and processing. How does your app handle loss of connection elsewhere? Or is this the first time you're addressing it?
    – moot
    Commented Nov 27, 2018 at 13:31
  • You're right, it's REST which handles the physical transfer - what I was referring to, was the appropriate location in the MVC architecture to obtain that data. And this is the first time :).
    – keldar
    Commented Nov 27, 2018 at 17:19
  • Sorry - correction: REST is a type of web service and defines a set of rules and verbs for data manipulation, it isn't a protocol however.
    – keldar
    Commented Nov 27, 2018 at 17:33
  • How much data are you trying to load? what is the nature of the content?
    – Nicolas
    Commented Jun 12, 2019 at 12:23

2 Answers 2


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.

  • 1) designers should be careful about dictating technical behaviour, regularly checking connectivity (i.e. polling the web) is the worst thing your mobile app can do. Just determine the situation if/when the app/user actually has to go out to the web to do something for real. (2) If your app doesn't gracefully respond to network problems, then it isn't much of a mobile app (perhaps you should have just made a website?...at least Chrome and Safari will gracefully respond on behalf of websites these days, they learnt that from well crafted mobile apps).
    – straya
    Commented Jun 12, 2019 at 11:26
  • @straya Designers should be careful about dictating technical behavior? What is "technical behavior" exactly? An app checking an OS variable before is uses the connection is hardly polling. The rest of your comment doesn't really make sense. I get you're trolling me but you have to do better. Chrome and Safari gracefully do what? : D
    – moot
    Commented Jun 12, 2019 at 16:00
  • The comments should focus on the question being asked and the response(s) provided, so it would be good to keep the discussion constructive and use the chat for the other things.
    – Michael Lai
    Commented Jun 19, 2019 at 1:36

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.

  • The question is about how to handle the UX of a connection loss mid journey. You give no solution for the issue you just misuse tech terms rambling about foreground and background Android services.
    – moot
    Commented Jun 14, 2019 at 15:53
  • I offer some advice on advanced ways in handling connection failures for important downloads, you are right though that I did not answer the OP well.
    – straya
    Commented Jun 15, 2019 at 8:23

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.