How should we handle UI when app performs network call and waits for a response?

Question

This is a question related to mobile apps UX, and particularly to iOS apps. So, the question is if the screen contains user input fields and does a call over the network when user clicks send button (to get OR send data) then should we disable user interaction on the screen and show activity indicator (progress indicator) until response is received? Of course, navigation bar with back button or/and close screen buttons should be enabled in case user wants to stop doing that. Otherwise is there any real benefit from doing it differently?

This is the way we always handled that and the only thing what we allowed a user to do was to go back or press close the screen. This prevents a user from for example filling out the same fields, pressing send buttons again and etc. However, we could think about disabling all the fields and buttons to prevent multiple accident clicking, but then there's not much to do in such screens anyway (except to scroll if the screen in long and do scroll bouncing). Are there any "Bible" guidelines on that?

I also found an interesting thing in Human Interface GuideLines regarding using activity indicators (UI controls section) :

An activity indicator:

Spins while a task is progressing and disappears when the task completes
Doesn’t allow user interaction

I'm wondering does the last statement confirms that it's normal practice...

Answer 1

Yes, it's a normal practice. As you mention with an activity indicator and the option to cancel it'd be okay.

A reason for this is because if something goes wrong you want to communicate it to the user as the first step after the "Submit" action. If you introduce more actions "in the middle" of that process, and that action can also have errors, it'll broke the "communication flow".

Most of the time, when filling a form, the only reason as a user to modify it after clicking Submit is due to some server validation which tells the form is invalid and must be edited and re-submitted.

Some reasons that could make you think of making the submit process not blocking:

• The submit takes too much time. "Too much time" could be the time that is needed to an user to fill other the form and click submit.
• The actions that users could perform if the UI wouldn't be blocked should be totally independent from the previously submitted.
• Users should be able to track the state of the previously submitted form. It must be always totally clear for the users what is the result of their submit/request.

This is the case of Google Drive:

The thing is that with standard forms, you may want to change something and re-submit as I explained above, or if you wanted to show a panel with the current state of a previous submit, the problem would be that the form doesn't have a unequivocal name to identify it within a "submit state panel".

In the particular case that the form was inside an accordion or a detail-row (childRow) of a table, and the processing time is considerable, you could collapse after submitting, show a animated processing icon somewhere on the row, and then show a checkMark or an X to show the status of the server response so the user can work with other forms in the meanwhile. Anyway in this kind of form the processing time tend to be fast, so you would probably never even need to think of doing something like this.

Answer 2

The 10 Usability Heuristics are as close to a 'Bible' as you can get.

Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

and

Help users recognize, diagnose, and recover from errors: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Tell the user what is going to happen, let them see what is going on (progress bar, spinner, etc) then give them a way out to conclude: error, retry or success.

Make sure not to overlook error states - they are part of the flow as well and need to be handled just the same as a 200 OK or the like.

Answer 3

Yes, you want an activity indicator. Your typical user won't know what's going on behind the scenes and may assume that it froze if there isn't an activity indicator of some kind.