I was thinking about improving UX in my builds, so I started Googling how to disable submit button until all (required) fields/inputs are filled in. Maybe I did a bad research but I did not find a solution — some related stuff yes, though the suggested code is hit a bit different solutions.
Hence, my question: how to do it in Webflow? It is indeed a great UX decision (sometimes at least) to allow users to submit a button until they complete a form.
The thing is users don’t know which field is required and which is not unless I make it crystal clear in the design — they will know about it only when they click the submit button because a popup will appear stating that they need to fill the required field(s). Moreover, as far as I know, there is no way to customize that popup, but it is not the main point.
In the UX I want to implement in my builds, the solution is quite simple — the form’s submit button is disabled unless all the inputs are completed. Of course, this solution is not for every project, though it is perfect for simple forms.
IMHO, not indicating clearly to the form filler that a field is required is a UX failure. Add a text element that is colored (typically red) that reads “this field is required” offset from the label or the commonly used Splat before the label, is the best design practice. I have conversion data from that proves it. Browsers display a consistent overlay popup on required fields that are unfilled. Users see the same behavior across multiple sites and can easily respond without being alarmed. Not something that should be interfered with.
Thanks a ton, Stan! Even more, I’m really thankful for the how-to explanation
I’m still not that knowledgeable in code, so can you clarify where are the variables in your code (I do not see var, so I guess you’ve meant changing classes). Actually, I would be really grateful if you could list all the variables that I need to change and tell me what each variable are responsible for (for example, there is div class="form_w", but I’m not sure if it should be the name of the class of my Webflow Form element.
Again, thank you one more time!
Edit: not at home right now, but I’m gonna test your code right away when I come back in Tuesday.
I agree and disagree at the same time — UX patterns can be improved and not all the websites have the same form UX design.
I would add that you are right about indicating in the UI which field is required and which is not (I’ve said it in my last reply to you) but we can improve this UX by disabling submit button so the users will explicitly see how they need to complete the form to submit it.
Again, I didn’t take this UX pattern out of nowhere — I’m reading a book about user interfaces and there was that pattern.
If you think you have a better pattern, then make sure you test it. My experience shows hiding the submit button confuses users into thinking the form is broken or is a multipage form that requires much more information, and both of these things create friction which is the last thing I want to do when gathering submissions. A/B Testing and eye tracking testing can provide real answers to how your choices impact users. Just something to consider.
Sure, you are right about it. I agree that A/B testing is crucial, especially if uncommon practices take place in the build.
They being said, the UX pattern I want to use is quite common. Moreover, I’m not gonna hide it but disable it — it’s different because disabling means somehow show that the button does not work in the UI. For example, make the button greyed out is a common practice that I’ve seen in this UX pattern. Also, the pointer can be changed to the default one instead of a pointer, so it will be more explicit that the vein doesn’t work.
There is no need to change names for const and/or let variables I only mentioned as I have used eg. inputEl instead common i. As @webdev mentioned good practice is to let visitors know what fields are required. It can be in form of a asterisk ‘*’ next to field label or as text as mentioned alongside form validation warning as tooltips etc…
Thanks a ton, mate! I’ve just implemented the solution in one of my client’s project and… well, it didn’t work very well because I couldn’t use native Webflow elements due to the inability to use some attributes such as “disabled” (they are reserved by the system), so I did write some custom code with a bunch of tweaks.
I‘ll make a cloneable later, so people can understand how it works.
Hope you are okay with me mentioning that you helped me!
Hi @GeorgyDesign the solution I have provided on CodePen was only a hint how it can be done, but I feel your pain as I pulled my hair to make it work in WF. Most of code that worked outside WF wasn’t working in WF. To make it work I had to redesign code logic. More in video.
Hopefully this will work for you, but not sure about multiple WF forms on one website as I have never done it.