Using call-to-action or primary buttons to show status of form completion instead of form UI element

Question

I noticed this while using a form to submit some information that the nature place where you indicate the status of the transaction isn't being used but instead the call-to-action or primary button is being used for this instead:

So in this example, a progress bar is being used to show the status of a document being attached but it is the call-to-action down at the bottom of the form that is displaying the status of the transaction (with the button being grayed out at the same time).

I think that it is rather ambiguous to have a call-to-action button showing the status of a process but also indicating its own status at the same time.

Is this a common trend to use the call-to-action button to indicate the status of a step in the process rather than the status of the action transaction or action when you click it?

Answer 1

The practice of using the button signature or animation to indicate the status of a step in the process is pretty common and I use it.

And this portal uses this approach too - try to add a picture to your reply).

Using the progress bar in the field is a bit strange example, and looks like "feature for the feature". I would use only one pattern (button progress indication).

Answer 2

There are two aspects to your observation, Michael:

1. The behavior of the CTA button 2. The position of the progress bar

Ad 1.: I'd consider the message on the button to be an explanation of why that button is currently disabled.

In "earlier web times," ;) the confirmation button would not be disabled. If users got impatient with the upload — or, more generally, the lack of progress —, they might click that button several times. That could potentially result in triggering the action multiple times, which is especially annoying in a payment transaction.

Nowadays, sites will often disable the button to prevent such multiple clicks. Without context, though, the user might not understand why the button is disabled. Stating that reason right on the buttom provides meaningful feedback.

Depending on the size and complexity of the screen, providing that info on just the button might suffice, or it might make sense to provide additional progress feedback elsewhere on the screen.

Ad 2: The placement of the progress bar is a judgement call, IMHO.

If multiple documents can be uploaded to the site shown in the screenshot, it might be helpful to the user to see upload progress for each document. Then again, maybe a single, "summary" progress bar would have sufficed here, as well.

In the latter case, I'd have placed it to the left of the button.

That's because, once you've completed the form, you've now arrived at the bottom of the page. And clicked the button to submit your input. So why force the user to look higher on the page to see additional status feedback?

P.S.: As for Aleks's suggestion, I agree that this treatment of buttons has become common these days. While I find the progress spinner inside a button OK, though (although it took me a long time to get used to it ;) ), I would not display a progress bar inside one.

A spinner indicates just two states: "active" and "done." It's easy to distinguish between the two by just seeing whether the spinner is there, or not.

In contrast, a progress bar provides more precise data: it shows the actual progress, and the bar also reflects the speed with which the process is progressing.

Most buttons aren't wide enough to provide sufficient space for the progress bar to be easily "digested" by the user, and an overlaid label makes it harder yet to take it in visually.

So if the precision of a progress bar is required, I'd place a dedicated one in the vicinity of the button.