Filing errors. Part 3. Errors in the forms.

Travel Guide: Part 1. Introduction ● Part 2. Speech barrier ● Part 3. Errors in forms ● Part 4. Errors on the server ● Part 5. Helping hand



01 An important element of site interaction with the user are data entry forms (or simply forms), as well as their individual elements. A form can be represented by one OK button or by a whole set of text fields, selection lists, checkboxes and radio battles. Today I will speak about the second case, when there are a lot of elements.

')

“A good form is a form that is filled quickly and easily, even if there are many elements in it”

02 What is good shape? A good form is a form that is filled quickly and easily, even if there are many elements in it. The speed of filling out the form depends on how well the user understands how to fill it. This is comparable to filling out forms in any organization. Only, if in the case of pieces of paper, a beautiful girl helps you, then the correct error presentation and prevention should help you.



03 I divide all forms into active and passive. The difference between these forms is that the active immediately warn the user about the error, and the passive issue it only after sending the request. To say which of them is better will be in a bad tone, because both are relevant at the moment. Passive forms are usually used in services designed for a wide contingent of users, since some users intentionally disable support for the technologies on which the active forms are based (JavaScript). Each species has its own rules for submitting errors, which I partly dealt with in previous articles and which I will recall today. Well, let's get started.

“Every mistake should be prevented whenever possible.”

04 Prevention of errors in passive forms. Recently, I again rethought the registration form in Gmail. In this passive form, the following things attracted me. First, there is no selection of required fields. It is absolutely clear that every field should be filled in here (although why should I give my last name?), However, it can generate unnecessary errors and delay the process of filling out the form. Perhaps it was worth writing in a prominent place that all fields are required. Second, Google confused the explanatory text with the error:





Gmail account registration form



Examples, of course, are good, but they are clearly not enough. Alternatively, the error text should look like this: “The field is filled in incorrectly,” and what Gmail now issues should have been written under or above the field. On the one hand, this is a good method, but on the other hand, there is a risk of turning the interface into a non-human one. Imagine that all errors will be of the form: "The field is filled in incorrectly", - brr:





Account registration form on Free-lance.ru



Therefore, I recommend using it only in small passive forms, and for large forms use a different solution. Take a look at the incorrectly filled in password field:





Gmail account registration form



Why duplicate information? The essence of the second method is to highlight in red the explanatory text and pass it off as an error. Thus, the user will not think how to fill the field correctly, but will immediately recognize it. It seems to me that if the Gmail designers used these recommendations, I would fill out the form faster. Every error should be prevented as far as possible. Remember this.



05 Submission of errors in passive forms. Here are the recommendations given in previous articles (in the Introduction and the speech barrier). Let's remember them:

- it is necessary to use the attachment of errors to their causes or place them in the expected place (otherwise: place them with an incorrectly filled field);

- if it is not possible to use attachment, use color coding (otherwise: highlight the error field and callout with one color);

- write the text of the error only in the language of the site;

- to formulate the error clearly, without using literary turns and incorrect verbal sequences.

"The main rule of the active form: it should send a request only once per case"

06 The organization of the active form. So let's start with a good example:





Image upload form on Flickr.com



The main rule of the active form: it should send a request only once per case. This is achieved by analyzing the data entered into the form on the fly and instantly giving an error, as well as disabling the Submit button. If the send button is turned on before all errors are corrected, then this form is not of great value and does not significantly improve its filling process:





Form to send a request to Business Lynch



I found out that my photo is larger only after I clicked on Submit, which for some reason turned on.



07 Warn the user against errors in this case in different ways. Whether to use fancy pop-up windows in which, when you hover on the field, an explanation will be shown, to give more visibility, or simply write from below that you can only use Latin letters from A to Z in the login depends on your tasks and fantasy:





The first step is to register at Photobucket.com



08 The basic rules for submitting errors in the active form do not differ from the rules of the passive form. The only thing is that you have the opportunity to experiment and create new interesting solutions for submitting errors. This, again, depends on your imagination.



The original article can be found in my LJ .

Roman Gorshkov ( FUEL )