How to submit forms with really good UX?

[bernhard]

Forms are a pain. They are not only quite complex to build from a technical point of view but also from a UI/UX perspective. I've done some research and surprisingly I was not able to find helpful information on one crucial part of forms: Form submission!

All blog posts and videos (like this one https://youtu.be/hPS7LUW7SlA) show all the necessary steps to make the form+fields look good and behave well, but none of the posts that I found showed anything about form submission.

How do you handle that? Or do you have any information about that topic for me? I mean... There's so many ways how you can tackle that and I'm still not 100% happy with the way I implement forms with my forms module.

There are two main ways of submitting forms:

1. Regular HTTP get request
2. AJAX

AJAX are maybe a little harder to implement but have the benefit that they don't need another page load. Regular form submissions need to show a success message though and that has often been a challenge for me to implement that in an appealing way. Most of the time I show a success message instead of the form and add an anchor to jump directly to the success message if the page should be longer.

On AJAX submitted forms on the other hand it is easy to show a modal (submitting form.... done, success!) but then you have the question what to do with the form that was submitted in the background? On one project I've made all fields disabled after submission so that the form is still there and takes up the same place as before (to not get any layout shifts/quirks) but it is obvious that it can't be submitted again (and the submission has worked).

Does anybody have better ideas?

 

 

[wbmnfktr]

I personally prefer to show a page/redirect to a page after a successful form submission.

The reason for that is quite easy... a few examples:

Contact form:
I can inform people about how fast they can expect an answer and/or already offer a selection of FAQs - especially when the contact form was used from an info page.

Forms on lead pages (newsletters or downloads):
I can offer more "options" such as products, services or explain how to make sure they will receive e-mail updates (like "add our e-mail address to your contacts and check for spam"). The last part can be used for newsletter sign-ups as well. In case you offer a newsletter archive, tell and show your visitors about it.

Forms on pre-sale pages:
In real estate after someone submits a request for a house, flat, office or whatever you can offer already details and downloads they will need in order to rent or buy something and even answer questions. Or even tell them who their contact person will be.

You car dealer for example: contact form submission with topic "parts" or "inspection" you could tell them "Mr/Mrs Doe, our expert for parts/inspection will contact you and answer your question. In case you might need it, here are the contact details..."

You can even personalize those pages based on the form details, like name, topic, and whatever else.

 

This way a form submission is not a dead end and I can keep the visitor/user a bit longer on the page(s).
I really enjoy it (UX) when a contact form isn't a show-stopper but keeps it somehow going.

Sure this might not work with every form or super simple contact forms. You might need more data to decide wether to show a page or just a short confirmation.

 

Are there good reasons against it? Probably.
Are there good reason for it? Absolutely.

[bernhard]

Thx!! I really like that approach, it absolutely makes sense to me ? 

[ukyo]

@bernhard

Did you try htmx ?

on validation side, i am using https://www.sirius.ro/php/sirius/validation/ and https://www.sirius.ro/php/sirius/upload/

you can use PHP for process, only you need some attributes for form element (no need javascript).

you can redirect page with headers

here is an example with htmx and processwire

 

 

[bernhard]

Hey @ukyo thx, but you missed my point (sorry if that was not clear enough).

9 minutes ago, ukyo said:

Did you try htmx ?

Yes I've played around with it and like it but still haven't had the need to really add it to my toolset.

9 minutes ago, ukyo said:

on validation side, i am using https://www.sirius.ro/php/sirius/validation/ and https://www.sirius.ro/php/sirius/upload/

I'm happy with https://doc.nette.org/en/forms and https://github.com/contributte/live-form-validation you can try that by trying to submit an empty contact form on https://www.autohaus-bendel.at/

12 minutes ago, ukyo said:

you can use PHP for process, only you need some attributes for form element (no need javascript).

you can redirect page with headers

here is an example with htmx and processwire

My question was not about how to implement forms in general. I know how to do that and I've already built a module for that similar to @Juergen's FrontendForms module. It was about the submission process only since I did not find any good instructions on that part even though it's a very important one! Your answer and your video kinda proves that as it's also stopping exactly at the spot where it get's interesting ? I'll update the post title!

[szabesz]

On 12/10/2022 at 6:56 PM, bernhard said:

My question was not about how to implement forms in general.

I think a lot depends on the form's purpose, the client's needs and – of course – on how much time you can spend on a given task.

For example, I am working on an "online ordering solution", where the management of multiple addresses is needed, and this is what I already have working for this particular purpose: [image has been removed]

 

So, for this form and for other "record management like" forms in the system, I opted for modal windows, toast messages and inline form error notifications (validation messages). I use Unpoly 2 and Bootstrap 5, btw.

[szabesz]

On 12/10/2022 at 3:01 PM, bernhard said:

I've done some research and surprisingly I was not able to find helpful information on one crucial part of forms: Form submission!

If you have the time, maybe reading some Sitepoint articles you can find some useful info. Just a few examples:

• https://www.sitepoint.com/premium/books/designing-ux-forms/read/1/jzjar4hq/
• https://www.sitepoint.com/premium/books/form-design-patterns/read/1/jz0sdfcg/
• https://www.sitepoint.com/premium/books/html5-forms-interactive-elements/read/1/
• https://www.sitepoint.com/html-forms-constraint-validation-complete-guide/

I have not read those, but in the past I did read some Sitepoint articles and there were all very good reads.

[LostKobrakai]

To me the biggest factor missing here is intent. Why is the form where it is? What does it allow the user of the form to accomplish? What does the user want to have happened at the end? Answering those questions will bring out the UX part of what you want to do on submit, which technology you want to use to handle the submit. This is likely best described by examples:

Contact Form: This is a form of allowing users to reach out. It allows users to put a message in whomever reads the messages' backlog. For these I think the outcome of the submit is ensuring the user that the submission was successful, so I usually have custom pages to redirect to, which show a success message and some prose telling them how soon they can expect an answer, …. If there's useful info to link to, e.g. FAQ, or something link to that. Also link back to the website if there isn't navigation anyways. As for technology simple is better.

WebApp Create Resource form: When a form is meant to create (or edit) some resource in a system, the best way to ensure a user about having created/edited things correctly is just redirecting to that resources' details page and show a flash message of "Successfully created" or such. As for technology use whatever fits best with the rest of the system.

Chat Input Form: Here the intend is to leave a message for wherever chat messages are visible, but not at all to leave the page. Make sure the form submits via AJAX, there shouldn't really be ways to input something, which is not "valid". Probably track acknowledgement of persistance by the server async (e.g. message rendered opaque until acknowledged).

In the end don't think the page you get to after submitting the form successfully needs to be the page the form was on. There are places where this makes sense, but imo that's more the exception than the default.

[szabesz]

2 hours ago, LostKobrakai said:

To me the biggest factor missing here is intent.

2 hours ago, LostKobrakai said:

In the end don't think the page you get to after submitting the form successfully needs to be the page the form was on. There are places where this makes sense, but imo that's more the exception than the default.

Another factor is the user's personal preference. For example, when adding products to a cart in a webshop, I prefer a short notification of some sort (even just an animated counter on the shopping cart's icon) so that I know my submit action worked, ie. the item was added to cart. I never want to be redirected to the Cart, for example, nor I need a modal window trying to sell me something else as well. 

So, what is pleasant UX for me might not be a pleasant experience for others and vice versa, of course.