Improving UX: How to Trigger Loading Wheel Before Webhook Response?

[lea]

Hello everyone,

I hope you’re all doing well. I’m currently working on a project and using @matthieu_chateau and @artur 's code to display a loading wheel after a user submits a form (here is the original post). The code works well from a CSS standpoint, but there’s a catch. I’ve included a GIF with this message where you can see that the loading wheel only appears after the form has received a response from the webhook.

For context, my use case is text generation by chatGPT. I use a softr form, send the data to make.com through a webhook, wait for the response from the webhook and redirect to the softr page with an lsit-detail block.

In this example, the webhook is intentionally misconfigured and doesn’t redirect, but the point remains the same. If the page were correctly redirected, the loading wheel would be displayed for barely a second, which is not the desired effect. At the end of the GIF, the text appears but too late for a good UX.

I’d like to know if it would be possible to adapt the code so that the loading wheel appears immediately after the user clicks the submit button.

Any help or guidance would be greatly appreciated. Thank you so much!

Best regards

Here is the custom code,

<div id="loader" style="display: none">
  <div class="spinner-container">
    <div class="spinner-border" role="status">
      <span class="visually-hidden">Chargement...</span>
    </div>
  </div>
  <p class="loading-message">Génération du contenu en cours, patienter...</p>
</div>

<style>
  #loader {
    position: fixed;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
    z-index: 9999;
  }
  .spinner-container {
    display: flex;
    justify-content: center;
    align-items: center;
  }
  .spinner-border {
    border: 4px solid #E9651C;
    border-top: 3px solid transparent;
    border-radius: 50%;
    width: 30px;
    height: 30px;
    animation: spin 1s linear infinite;
  }
  .spinner-border span {
    display: none;
  }
  .loading-message {
    font-size: 18px;
    font-weight: 500;
    color: #000000;
  }

  @keyframes spin {
    0% {
      transform: rotate(0deg);
    }
    100% {
      transform: rotate(360deg);
    }
  }
</style>

<script>
  const loader = document.getElementById("loader");

  window.addEventListener("submit-form-success-form3", function () {
    loader.style.display = "block";
  });
</script>

[matthieu_chateau]

Hi Lea,

The best wouldn’t be to add a delay in Make before redirect and stay with the current script?

Updating the script to make it work only on click is not the best, IMO.

1. If any failure, the text would display “Génération du contenu en cours”… which wouldn’t be the case actually

2. Updating the script is in fact quite more complex than it appears => if you have a rule saying display this on click, you also need to say “and then submit the form”… which is not easy to do in Softr

[lea]

Hello Matthieu and Community

I’m in agreement with the general sentiment that having a spinning wheel appear every time a form is submitted may not be the most elegant solution—especially if it fails to deliver on its promise of generating content. However, in my specific use-case, this issue is quite rare. Usually, the user submits their data and patiently waits for the generated content.

In my application, the content generation process takes anywhere between 15 seconds and 1 minute. The challenge is that, in the absence of any visual feedback confirming the data submission, the user might prematurely close the tab, disrupting the process.

Here’s a gif to illustrate my point: a slice of cheese and pickles are far more rewarding to wait for than merely a slice of bread. (source)

To improve user experience, I’m contemplating introducing a block that displays upon clicking the ‘Submit’ button. This block, initially hidden during DOM loading, would feature an endlessly looping GIF to engage the user while they wait for content generation.

I would love to hear your thoughts on the feasibility of this. Specifically, what JavaScript trigger would you recommend for initiating this click event? If anyone has alternative suggestions for enhancing this user experience, I’m all ears.

Thanks for your help Matthieu !

[matthieu_chateau]

So, if your action takes 15 seconds to 1 minute, the “on form submit” (success) event listener would be ok, no?
There would be a 1 second difference between an onclick event and an “on form submission event”.
Compared to the 15 sec to 1 minute you mentioned, there is no difference for the user.

I believe you use a webhook (Make or Zapier) on form submit? So it should work.

That being said, even if I understand your point to force them to wait, my opinion about these use cases is clear: you don’t force the user to wait . You let them do whatever they want. For the simple reason that 15 seconds to 1 minute is simply something a user is not patient enough for. They won’t stay in front of your app tab.

An email automation (with Airtable) saying that their content is ready might be a better solution for example.

Anyway, your use case might be specific but I need to know more:

What is the context of this form? What is the user persona touching this form? What will be the added value for this user persona when the content will be generated? What will be the content?
Behaviours can change according to the output received by a specific user persona.

I introduce the new Softr community lead @sisa into this conversation, as with her background she may have some thoughts and good points to bring about your use case.

[matthieu_chateau]

Update to your problem of loader displaying only when the form has received a response from the webhook.
I was sure that the event listener submit-form-success-form3 occured earlier… but it appears that in your use case, it doesn’t.

So the solution would be to add a 200 response earlier in your Make scenario, I think.
The 200 response should be given immediately. You should be able to do it with the HTTP module.

You have a 200 code status in your Make scenario?

I don’t know what other code status could be used (a 102?) to match the submit form success event listener @artur / @sisa ?

[lea]

Hello Matthieu and Community ,

Your suggestion about triggering an early HTTP 200 response in the Make scenario is intriguing. If I understand correctly, this would display the loading block sooner. However, I have a concern. Redirecting to the page earlier would mean that I can’t display the record that will be generated by GPT, which could take up to a minute. Is it possible to include two HTTP responses in a single Make scenario—one for displaying a “waiting” block and another to perform the redirect once the record is ready?

As an alternative, I’m considering displaying a progress bar beneath the form after a user submits their data. This bar would reach 100% within a minute, and if the redirection occurs before that, it would go largely unnoticed by the user. What are your thoughts on this?

While I appreciate your points about the timing of the loader and the potential for email automation, I believe that an immediate visual cue—like a progress bar—could serve as an effective middle-ground solution to enhance the user experience.

I’m also eager to hear insights from @artur and @sisa on this matter, given their expertise in UX design and custom coding.

Here is my make.com automation :

Best regards

[matthieu_chateau]

Nope, the idea is not to have a redirection sooner.
The idea is to insert a webhook response (forget about the make http module I wrote about, above) just after the first webhook module to send a message to the softr form like “I received it => the form submit is a success”. The thing is … 200 http code statuses should be used for this.
300 http code statuses are made for redirection.
But I know there was a problem with Make/Softr so the 200 code statuses are used instead of the 300 (if I remember well) which is a problem.

Another way to solve it would to use a router in Make => add a 200 http code status

For information, all about code statuses: Codes de réponse HTTP - HTTP | MDN

Here is an example of what would work with a router and with the right code status (?) in the first webhook response:

[lea]

Hi @matthieu_chateau ,

Thank you for sharing your insights and suggestions regarding the use of HTTP status codes in webhooks. I appreciate your input.

However, I must admit that I’m not entirely sure how to implement these changes correctly. It seems a bit complex for me, and I want to make sure we handle the HTTP status codes properly.

Given the intricacies you’ve highlighted, I’m going to reach out to Softr.io’s support team for guidance and assistance in configuring these webhooks and status codes correctly.

Stay connected, thanks