Primal Skill Programming

Primal Skill Programming

9 Form Mistakes to Avoid

9 Form Mistakes to Avoid

Forms are one of the hardest things to get right in front-end development. They represent the user input for any application.

Working in web development for almost 20 years now, these common mistakes I found developers (including myself) are making.

Not Trimming the Input

trimming.png

Not trimming both ends of the field contents, even if it's just a simple text field.

Users often leave white spaces before or after a text, not trimming these characters is a mistake because it's how gets saved in the database.

Always trim BOTH ends of a text field content.

Falsely Counting Length

This mistake closely ties into the previous one. By not trimming the white spaces in the text, the length will be wrong.

Let's say we need to count a name field to be at least three characters long. If the user enters a followed by two white space characters the length of the string will be 3. Which is wrong.

Make sure the length of the user input is always correct.

Not Escaping Form Data

Text encoding is a hard thing to do right, especially in programming languages where the encoding is not explicitly defined or the implementation is buggy. (Looking at you PHP, but hey I get it, encoding is hard).

Make sure to always escape the form data in order to save the correct data.

Wrong E-mail Text Case

email.png

Not lower-casing a field where the user needs to enter their e-mail address is a mistake because it gets saved in the database as-is.

Later on, at the log-in phase, when comparing the saved e-mail address with the user-entered input could give wrong results.

For example, at the sign-up phase, the user enters MyName@example.com, then later at the log-in phase enters MYNAME@example.com.

Always lowercase e-mails before saving it into the database.

Wrong E-mail / Password Combination

This is more of a semantic / user experience issue, but oftentimes on sign-up forms, we see the following.

image.png

Non-technical users often confuse this type of form because they don't know which input they need to enter.

At my company, we did a small-scale focus group for a large client where we asked users to fill out the form then we asked if the password they gave was their e-mail address password or another password of their choice. 90% of the users responded "Yes" thinking they NEED to enter their e-mail's password.

This could be a security exploit. Create a little note or tool-tip for these kinds of fields so the users know they can enter different passwords too.

Not Disabling Submit Buttons

This is a really obvious mistake that almost every developer makes at least once in their professional career.

By not disabling the submit button during the form submit phase, you risk the user clicking the button multiple times sending multiple requests, and saving the form multiple times.

ALWAYS disable the submit button during the form submit phase.

Not Redirecting After a Form Submit

Submitting a form to the back-end should always result in a simple redirect back to the same page or to a "Success" page if there are no validation errors.

This is important because a user can successfully submit a form, click the back button, then submit the form again with the same data or the user can refresh the page after the form submits and triggering another submit again.

This pattern is called PRG or POST-Redirect-GET. More info here.

Always redirect the user to another page after a form submit.

Not Using Proper HTML Form Fields

html.png

With the advent of modern front-end development and SPAs, most developers seem to forget the "Semantic Web".

HTML is a continuous evolution of the specifications, in recent updates, most modern browsers already support input types such as "date", "number", "range" and so on.

Use the appropriate type for the input. More info here.

Not Securing for SQL Injections and CSRF

This should be at the top of this article. It's an obvious mistake, yet developers still commit it to this day.

A whole article can be written just on this point alone, and others wrote about it so I won't.

Here are the resources to learn more about SQL injection and CSRF


If you found this article useful please share it on social media and/or comment below.


Photos Credits

 
Share this