Forms are such an essential part of an online experience, I cannot imagine any site or service without forms. They start right from signup/signin, and are there every step of the way whenever any kind of data needs to be collected from humans, in a structured form. One might have never given this a lot of thought, but forms are everywhere, and I dare say the Internet would not have been possible without forms.
Hah, for that matter, life on earth also probably would not exist without forms. Are you born? Fill a form. Are you dead? Nope, cant die till you fill that form. Yes that one, in triplicate, and attested by the Raja of Gaipajama himself.
High quality forms are a delight, and the converse leads to immense frustration, esp when coupled with data loss - here's looking at you ugly ass Indian govt websites.
Data loss causes great sadness to users.
Some of the worst things that can happen when filling forms:
- Form fields are shown one at the time. The worst culprit of this needless and unnecessary bullshit is TypeForm aka the form is better than function school of thought.
- Why anyone would use this torturous method of data input is beyond me. By the time one gets to the 10th field, one has forgotten what one entered in field 1.
- If you want to review the entire form at a glance before submitting, too bad.
- If you want to save or screenshot the form for future reference, screw you and the horse you rode in on.
- And even worse is the use of TypeForm for serious stuff like long-ass applications to VCs for funding. One needs to fill out dozens and dozens of questions ONE AT A TIME. What is this, some joke application form?
- Complex requirements are shown only after form validation fails, esp related to password setting eg select 2 uppercase, 3 lowercase, 4 numbers and 5 special characters, aiiiyo but no not that special character you punk (Digression - see how we did away with this idiocy)
- Form validation fails, and the entered info disappears! Which means one has to reenter all the information again.
- Form validation fails, but there is no indication as to which field has flunked whatever validation is being done.
- Generic error messages - "Something has gone wrong", so now you can p*** off and go do something else
Well, it's no wonder that a lot of attention is paid to #forms at MainCross. Even with all this, are we doing a stellar job with forms?
No.
We are certainly better than most. We are aware of the best practices, we are aware of the limitations and we are constantly improving.
Ok, now lets go to design town
The form fields UI being used for a long time across the MainCross system was based on Google Material design guidelines, and they were fine for a while since they were used for short labels.
Once we released our #FormBuilder which allowed customers to create forms, we saw a serious limitation - Material design form fields are geared towards short labels, and if a label was long, it would overflow and cause serious usability issues.
I've talked about this at a number of places, eg on the MUI package where this issue has been discussed in July 2021 - https://github.com/mui/material-ui/issues/12255#issuecomment-882853518
Irrespective of what the Goog says, the world is full of long questions in forms. The idea of short labels only holds good for limited cases of "username / password / address / credit card" and the like. I can give dozens of examples of long questions in forms, that needs be there, and not all of it can be turned into helper text. Eg surveys / questionnaire are terrible on small screens.
For more than a year, we tried many different ways to get longish labels to work by hacking around with the Material design UI. All such attempts failed.
We saw some limited success by limiting label length to ~50 characters and pushing everything into the helper text below the label.
Neither of these were an elegant solution.
As our FormBuilder started being used by customers, we began to get serious pushback on this.
Customers wanted to be able to write long questions, without needless character limitations and jumping through hoops.
Around this time, after looking through dozens of resources on form (and form field) design, it was becoming obvious that Google didnt know what it was doing, and sticking with Material design was silly.
Using Material guidelines for form fields were leading to loss of info or legibility and/or cognitive overload - which is basically bad UX, and form fields being really important cannot afford to have poor UX.
Dec '22 - Form field redesigned, or rather revert to "Classical" design
It was time to drop the chic-but-useless Material design for form fields and adopt the time-tested classical format. Once we adopted this practice it relieved our customers and end users.
Here are some screenshots of the changes for forms made by customers using our #FormBuilder :
Google material design:
Classical:
For non-english characters and perhaps even non-sophisticated audiences, we find it better to use classical format for forms, even for short fields.
Google material design:
Classical:
We received positive feedback from customer regarding this change, and then we adopted it across the entire platform for all forms - signup, signin, contact, profile, admin interface, etc.
Frankly its been a relief not to have to fiddle with Material design form fields anymore.
