3

I am developing a mobile application. In cases where the server takes too long to respond during form submission, what is considered a best/widely acceptable practice to prevent users from trying to resubmit the form in cases of a maximum 30s timeout.

1) Loading indicator with full view block
2) Disable button only
3) Other choices?

To me, disable button only seems to have a better user interface, but users are still able to resubmit the form by tapping into any of the input fields and pressing mobile keyboard go key. On the other hand, full view block will force users to wait and no action can be taken until timeout. Both have pros and cons and I am undecided.

Or maybe there is a general guideline that is being outlined for Android / iOS that I did not notice.

  • 1
    How likely is it that the server response time will be this long? Is a 10sec+ response time an edge case or the norm? I ask because this could impact the decision you should make. – Brett East Jun 11 '16 at 19:26
  • It also depends where the delay is. If you expect the "save" to be quick, but the resulting "load" to be slow... Blocking only the button/form controls? Has the benefit that the user can initiate the save (async fire and forget) then navigate elsewhere in the app if they so choose. As a user it drives me nuts when apps block the full screen when it isn't necessary. – scunliffe Jun 11 '16 at 22:48
  • @BrettEast 10sec+ response time should be an edge case, unless server is having an heavy load. – vincentsty Jun 12 '16 at 3:17
  • @scunliffe what do you mean by "save" to be quick, but the resulting "load" to be slow – vincentsty Jun 12 '16 at 3:18
  • @vincentsty let's say you are adding a "task" in your app. Often times when you submit the "add task form" the next screen shown is the full list of tasks. In this scenario the "save" is just a handful of properties being inserted in a DB (e.g 1 row, very fast) but upon success the "load" for the next screen could be very slow if you need to execute a complex query and/or return a ton of data from the DB. I was trying to ask if you have a scenario like this... Where the "load" is the slow part and thus you may want to provide options to the user vs fully block them. – scunliffe Jun 12 '16 at 12:29
2

I would do both 1 and 2, but also present the user with a message. Having a message will guide the user's expectation and avoid unnecessary concern by the user. The message doesn't have to say much, even just that the form is submitting and will take up to 30s.

  • I generally agree with your approach, but aren't sure about the full view block aspect of the first option. I think showing a loading indicator is good, along with disabling the submit button, and your suggestion to present the user with some sort of message is a must in my opinion! – Monomeeth Jun 12 '16 at 3:12
  • isnt it duplicating to do both (1) and (2) at the same time? – vincentsty Jun 12 '16 at 3:19
2

Just a quick suggestion, you could possibly disable the submit button, but have the text on it change to 'Submitting...' and also disable all of the form fields, so that the user can't then submit the form using the keyboard.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

I don't know about the feasibility of adding a loading progress bar, but I prefer that to a spinner, as it also shows the progress of time, but you could potentially put that somewhere on the screen as well.

Personally, I don't like the blocking the whole page with an indicator, particularly if it is likely to take a long time (it can look like the screen is hanging and just going forever). But if 10sec+ is an edge case, and it hopefully only takes a couple of secs max, then I think it should be okay, if you wanted to do that option.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.