What is the most user friendly way to block user input to form while form is submitting that can be reused i.e. so I don't have to implement it for each form?

For forms with only buttons (I have voting system similar to SE Vote up, Votes count, VoteDown):

  • Should we just disable buttons/links and hope user knows what is happening?
  • Should we put spinners or similar and block button somewhere near button?
  • Replace button with spinner, the show button and remove spinner on unblock?

For normal forms:

  • Should we overlay forms and put spinner in middle or some loading text (this can look ugly IMO, because forms can be different size of container)?
  • Should we change mosue pointer to spinner?
  • Disable all fields/buttons etc.?
  • what kind of input ?
    – Mervin
    Commented Mar 7, 2014 at 10:14
  • @Mervin Whole form which can contain all HTML controls: textboxes, buttons, dropdowns etc. either whole form like with overlay or each control spearatly.
    – formatc
    Commented Mar 7, 2014 at 10:16
  • So I am still confused, do you plan to keep the form fields editable when a person is in the process of submitting a form?
    – Mervin
    Commented Mar 7, 2014 at 10:17
  • @Mervin Like the title says, I want to block user from editing form while form is submitting until the form is submitted, after form has been submitted my usual pattern is to clear form so user can submit it agian.
    – formatc
    Commented Mar 7, 2014 at 10:28
  • If you disable form elements, what happens in instances where the user has lost connectivity while in the process of submitting the form? If the user stops the page loading in an attempt to preserve the completed form, the user will not be able to resubmit.
    – cimmanon
    Commented Mar 7, 2014 at 16:00

3 Answers 3


For Buttons

I would strongly recommend looking at this excellent example which converts the button into an form submission indicator as well.

enter image description here

Here are a couple more resources you might find interesting too which show relevant progress buttons


Loda Buttons

However if you are concerned about users trying to interact the button, you can always disable the button as that gives the affordance that nothing more can be done with the button.

For Forms

So going by our comment conversation, what you are looking for is some kind of interaction or overlay which will inform users that the form submission is going on and hence any interaction cannot be done.

My recommendation would be to show an overlay with a message which informs the user that processing is going on and he would be getting results shortly. A good example would that be this example of incorporating an interesting animation like how http://tweet.grader.com does while it is processing the history of a twitter handle as shown below:

enter image description here

This flight tracker for ipad uses a interesting simulation which shows a plane flying as shown below

enter image description here

Orbitz on form submission shows a spinning indicator to inform users content is being submitted and they have to wait as shown below

enter image description here

  • @Merivn Progress Button Styles are excellent, very creative! :)
    – formatc
    Commented Mar 7, 2014 at 10:55

What you're trying to do is provide visual feedback that:

  1. the user clicked the button,
  2. you've received that click, and
  3. magic is happening to deliver the results.

Disabling the button achieved the first two goals. The items Mervin lists off are good ways to achieve the third goal.

The simplest response is disable the button after it has been clicked once. You can add in other loading / progress bars and animations (like the ones Mervin listed), but those aren't necessary.


Note that it's fairly common to provide a transaction number as part of the form sent down to the user, so that if they rePOST the same form you can detect this and reject it.

(This is particularly important if the POST is coming from Java. There is a known bug in Java where someone forgot that while GETs are idempotent -- ie, it's promised to be safe to issue the same GET several times in a row -- POSTs are not. As a result, if the server is responding slowly Java's POST code may resubmit the transaction even if the user has not said to do so. Sun/Oracle have declined to fix this for fear that someone, somewhere, may be relying upon the broken behavior. There is a system property that can be set to disable that bug, and I highly recommend doing so, but it's another good reason to design the system to recognize unintended rePOSTs.)

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.