I tend to deal with the UI parts of a large product we are building where I work, today I had a disagreement with my boss about how to handle some potentially long operations on the android app which is intended for tablets and now I'm unsure what's the right approach. I'd like to know what the general consensus is on how to handle the following type of operation so I'm better equipped next time I need to do similar.

The problem involves making network calls, two or three calls consecutively, each should complete in a second or two but with a busy network you could potentially wait up to a minute and a half for all 3, highly unlikely, but possible.

When we start the call we display a spinner with some loading text. When the first call returned I chose to update the text (in my head, that is to show there has been some progress and that the app hasn't hung). The text didn't explain what the app was doing, just changed from 'Loading' to 'Still working'.

My boss insists that this is bad for the following reasons (a) having our code need to provide a ui callback adds more maintainability issues (b) it exposes how the app is doing what it is doing (c) it could overwhelm the user because most of the time the message wil lswitch after just 1 second

My question is, what do professional UX consider a good experience when doing an operation like this?

2 Answers 2


Here are some clues on how you can deal with these things:

  • Make it a background process if possible (display status onscreen, yet allow user to user the app in other ways if there are any).
  • If the aforementioned is inapplicable to your case for any reason, try any of these:
    1. Display three dots, each representing a single call. The active call would be blinking smoothly, until the call is complete, then it would stop blinking and get darker or so.
    2. As said, put some informational text below. If the call takes longer than some agreed time, change the text; change it once more if it takes extraordinarily long. I assume that these long phone calls depend on busy line, which probably, correct me if I'm wrong, groups them into just two sets: these that get executed in up to 3-4 seconds, and the very rare rest. If yes, measure the average anticipation time and set the first text change time to the result plus two or three seconds.

As it comes to exposing what app is precisely doing, my guess is that user should know it anyway...

Summing up: divide the process into three parts and indicate the status of each part separately, also, try giving as much feedback as possible. If you choose the text-change time properly, user will only see the text changing when it's necessary, which will prevent superfast text appearances on the screen.

  • Thank you, sorry to press further, I want to know more - It's a background process as you expect. Instead of dots we have a circular spinner (standard android), however I feel users ignore this as they are used to those lasting forever when something has failed. Do you think the dots idea avoids this presupposition? Lastly the calls can't provide progress midway, so to do a 'timeout' as you have suggested we have to time it separately, the issue being it could still change the text during first call, and display the same for a full minute while the other calls complete. Is that an OK UX? Jan 27, 2014 at 19:10
  • The flow I mentioned and the way the dots along with the labels would represent them would clearly represent activity by their motion; as it comes to labels, it's easy enough to provide labels in this fashion (example scenario in which first call goes OK, then 2nd takes more time than predicted): "Making the first call..." -> "First call complete, making the second call..." -> "Second call takes a little longer, please be patient"... Etc. Are the calls made each one after other, or simultaneously? Jan 27, 2014 at 19:38

I don't get what call in your question means. What do you think is a good experience if you take the user as a starting point? Your conversation with your boss sounds like focusing on technology.

My suggestion is; don't think how software should work. First think about how your target users would work; tasks and goals. Think about how software should interact based on that. If you really have to let them wait be clear what's happening under the hood. If they understand what you are showing in that context you are okay. Reflect your language to your target users.

  • Yes he is entirely focused on technology but weighs in on all the UI stuff based on opinion, but it's very hard to convince him to think from my perspective which is why I'm interested in the UX community view on this type of problem. Call in this context means 'communicate with the server and wait for a response' Jan 27, 2014 at 19:33
  • Aha okay! Hmmm sounds familiar. I had a CTO who was responsible for the design-phase. Haha yes a technological oriented company as you might have guessed! So this client-server communication is based on user input?
    – myradon
    Jan 27, 2014 at 19:39
  • No, its based on a piece of information we load about a user when they take a certain action, the action can be carried out regardless but this background progress loads some other incidental supplementary information Jan 27, 2014 at 20:50
  • Ans what about just pushing the information?
    – myradon
    Jan 27, 2014 at 21:27

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.