April 26, 2010 at 17:00The required field myth
There are many myths and misconceptions in the world of software development. To move forward, and not stagnate, it is absolutely necessary to destroy them. Today, one of the most deep-rooted misconceptions, which is also quite harmful, is called the “Myth of Mandatory Sex”.
It will be about almost any systems that use forms to enter information. The required field is the form field, without which the system will not accept information from you. Among the vast majority of software developers, there is an opinion that the required fields should be:
Traditionally, programmers believe that they are doing a favor to the rest of the world, creating for them such a wonderful product as "substitute any name for the product." Their program is almost a Platonic eidos, a pure abstraction, a mathematical formula, naturally calculated strictly on a set of parameters from its domain of definition. From this point of view, the required fields are that annoying little thing that you have to insert in order to educate stupid and uncouth users on how to correctly enter information into the system with which they have been privileged to work.
It is also believed that incorrect (incomplete) data is so scary that even storing them in the database is already incorrect. Well and laziness, of course - from the point of view of the developer it is easier to check the correctness of the data at the input stage and send the user to double-check their data than to write error handling where this data will be really used in the system.
What does the modern science of user interaction design have to say? Firstly, it became clear (I don’t know who and when, but for a long time for sure, see [1] and [2]) that all the same, programs are developed for users. In this sense, the programmer no longer dictates the conditions, but modestly creates a purely utilitarian product, a tool that people will use to solve their problems and achieve theirgoals. Like an iron - if you need to iron something, you turn it on. If he instead of ironing, modally offers to download updates from the Internet, it is clear where such an iron will fly. Alan Cooper [1] recommends introducing users of your product as very smart, but very busy people. They, they say, are not stupid and will understand how to use your product, most importantly, you just do not get in their way.
In general, I believe that every programmer (designer, manager, analyst) should do the meditation mentioned by Sergey Bodrov-ml .:
There will generally be something about the required fields, the habrauser asks? Just starting now.
The thing is that our real world is not a mathematical model whose parameters are known at any given time. For real life, a lack of information is more likely than its availability. The person filling out the form may not have the required data - and may not have it in all the visible range of reach, that is, may not be able to. This problem cannot be solved by simply making the field mandatory - the value is not taken from the air. By entering required fields on forms for the sake of data integrity and completeness, we actually interfere with the use of the system. Faced with this situation, the user either will not fill out the form (and will not be able to work with the system at all), or fill in the missing data with fish - fictitious or meaningless data. And this does not indicate that the user has tried poorly or poorly, but only that the developed system is not flexible enough for use in realof the world. What happened in the second case (fish input) is generally a hoax. The system designer can pretend that everything is in order as much as desired, but in fact it is he who is to blame for this deception. Moreover, it is not clear who and what won in general - the user had a headache, and incorrect data got into the system. Yes, you’ve got it in such a way that it’s already impossible to detect, filter or clean them automatically - in contrast to the case if the user simply indicated that the information was missing.
What to do? You need to do good programs. Namely, yes, after all, do not put the integrity of the database schema at the forefront, but put the goals and objectives of users there. In other words, to accept from the user incomplete, and in some cases incorrect data, of course, with the ability to correct them in the future. Contrary to the error (yes, one more) it is possible, it is not so difficult and it even works. In addition, you still need to somehow help, prompt the user where, what data and why he is missing. So that he sees and controls the situation.
How many required fields should be on the form? Ideally, zero. Is this always possible? For me, one example of aerobatics is the operation of creating a folder in Windows. It would seem that you can’t do less than one field here, but no, they managed to implement the creation in such a way that the system does not ask anything - even though the technical limitations do not allow the system to create a folder without a name. This is the ideal to strive for.
Naturally, the system should be minimally smart, asking the user only what is relevant to the tasks of the user, and not to the needs of the system itself. System as a tool, remember? Just about the Firefox example, Google Chrome, for example, solved the Firefox problem by updating silently at the moment when the user reboots it. The user does not need to know about this at all - he does not know. A worthy role model. I must confess that I didn’t even understand at first, somehow he never asked me when to update him?
There was also a myth about important fields (these are those that are optional but desirable to fill in). It’s still simpler here - you cannot force a field to be filled. Therefore, at least mark the field as mandatory, at least do not mark - all the same they will write fish, rubbish, unsubscribe if they do not want to fill out. There is no interface solution to this problem. The importance of the fields needs to be communicated to field staff. And the developer should mark the field as optional. And let edit.
Literature:
UPD: In the comments, trijin and zhindetz more clearly formulated the main moral of the topic: we are talking about a draft system, about removing the requirement to enter all the data immediately and consistently. That is, yes, to make optional even those fields without which the system will not work. Naturally, it will not work, but let it at least protect the data.
UPD # 2:I’ll clarify one more thing that I myself did not realize clearly when I wrote the topic. I do not discuss here the relevance of certain fields on the form (this is an important, but still slightly different topic than the one I want to convey). Rather, I propose to rethink the very concept of entering information using forms, that traditional approach when you need to fill out the entire form immediately and correctly. Instead, I suggest that an intermediate state (incomplete, incorrect, inconsistent) also be allowed to be stored in the database, explicitly marking such a state as incomplete / incorrect / inconsistent. Thus, all situations “I don’t know everything now, but maybe tomorrow I will find out”, which are traditionally solved by writing on a piece of paper, can be processed using an information system. Naturally, such data should not be allowed into the business process due to its incorrectness - everything remains as before. They just lie in the database until better times - they will not come in handy, well, God bless them.
It will be about almost any systems that use forms to enter information. The required field is the form field, without which the system will not accept information from you. Among the vast majority of software developers, there is an opinion that the required fields should be:
- All fields necessary from the point of view of the subject (for example, full name and date of birth of a person, if it is a passport office)
- All the fields necessary for the functioning of the system (those without which the algorithms will not work - for example, the date from which the provision of services begins in order to make accruals on them);
- Important fields - those that are not necessary, but it is desirable to fill out (for example, the rationale for the change) - with the motivation that it is better for the user to sweat when not needed, than to forget to enter the value when necessary.
Traditionally, programmers believe that they are doing a favor to the rest of the world, creating for them such a wonderful product as "substitute any name for the product." Their program is almost a Platonic eidos, a pure abstraction, a mathematical formula, naturally calculated strictly on a set of parameters from its domain of definition. From this point of view, the required fields are that annoying little thing that you have to insert in order to educate stupid and uncouth users on how to correctly enter information into the system with which they have been privileged to work.
It is also believed that incorrect (incomplete) data is so scary that even storing them in the database is already incorrect. Well and laziness, of course - from the point of view of the developer it is easier to check the correctness of the data at the input stage and send the user to double-check their data than to write error handling where this data will be really used in the system.
What does the modern science of user interaction design have to say? Firstly, it became clear (I don’t know who and when, but for a long time for sure, see [1] and [2]) that all the same, programs are developed for users. In this sense, the programmer no longer dictates the conditions, but modestly creates a purely utilitarian product, a tool that people will use to solve their problems and achieve theirgoals. Like an iron - if you need to iron something, you turn it on. If he instead of ironing, modally offers to download updates from the Internet, it is clear where such an iron will fly. Alan Cooper [1] recommends introducing users of your product as very smart, but very busy people. They, they say, are not stupid and will understand how to use your product, most importantly, you just do not get in their way.
In general, I believe that every programmer (designer, manager, analyst) should do the meditation mentioned by Sergey Bodrov-ml .:
You stand on the corner of a busy street and imagine that you are not here. Rather, you are not at all. Pedestrians walk, honking cars, the doors of shops open, passengers change at a bus stop. That is, in principle, the world continues to live without you. Understanding this is painful. But it’s important ...Of course, I don’t want to say at all that a programmer is an unnecessary profession, I myself do not think a programmer at all. It’s just an ungrateful profession. No one will come and praise for a well-implemented algorithm. If the program is good, they will use it without further questions. So it should be, just to be a programmer, you need to get used to it. And these are the people who walk along the street and take turns at the bus stop - these are your users. They use things the way they are theyare needed. Including your product. Without you. They don’t know anything about you, they don’t want to know, and they will never know. Sergei Vitalievich, when he is trying to drive readings taken from the meter into the system in the polar tundra, it is not at all interesting why the system tells him that you first need to specify some type of tariffing there, even if at the time of design it seemed to you that without the type of tariffication there is no way to do it. As for the example of an iron downloading updates, it is not taken from the finger at all - pay attention to how the Firefox browser behaves when it is turned on.
There will generally be something about the required fields, the habrauser asks? Just starting now.
The thing is that our real world is not a mathematical model whose parameters are known at any given time. For real life, a lack of information is more likely than its availability. The person filling out the form may not have the required data - and may not have it in all the visible range of reach, that is, may not be able to. This problem cannot be solved by simply making the field mandatory - the value is not taken from the air. By entering required fields on forms for the sake of data integrity and completeness, we actually interfere with the use of the system. Faced with this situation, the user either will not fill out the form (and will not be able to work with the system at all), or fill in the missing data with fish - fictitious or meaningless data. And this does not indicate that the user has tried poorly or poorly, but only that the developed system is not flexible enough for use in realof the world. What happened in the second case (fish input) is generally a hoax. The system designer can pretend that everything is in order as much as desired, but in fact it is he who is to blame for this deception. Moreover, it is not clear who and what won in general - the user had a headache, and incorrect data got into the system. Yes, you’ve got it in such a way that it’s already impossible to detect, filter or clean them automatically - in contrast to the case if the user simply indicated that the information was missing.
What to do? You need to do good programs. Namely, yes, after all, do not put the integrity of the database schema at the forefront, but put the goals and objectives of users there. In other words, to accept from the user incomplete, and in some cases incorrect data, of course, with the ability to correct them in the future. Contrary to the error (yes, one more) it is possible, it is not so difficult and it even works. In addition, you still need to somehow help, prompt the user where, what data and why he is missing. So that he sees and controls the situation.
How many required fields should be on the form? Ideally, zero. Is this always possible? For me, one example of aerobatics is the operation of creating a folder in Windows. It would seem that you can’t do less than one field here, but no, they managed to implement the creation in such a way that the system does not ask anything - even though the technical limitations do not allow the system to create a folder without a name. This is the ideal to strive for.
Naturally, the system should be minimally smart, asking the user only what is relevant to the tasks of the user, and not to the needs of the system itself. System as a tool, remember? Just about the Firefox example, Google Chrome, for example, solved the Firefox problem by updating silently at the moment when the user reboots it. The user does not need to know about this at all - he does not know. A worthy role model. I must confess that I didn’t even understand at first, somehow he never asked me when to update him?
There was also a myth about important fields (these are those that are optional but desirable to fill in). It’s still simpler here - you cannot force a field to be filled. Therefore, at least mark the field as mandatory, at least do not mark - all the same they will write fish, rubbish, unsubscribe if they do not want to fill out. There is no interface solution to this problem. The importance of the fields needs to be communicated to field staff. And the developer should mark the field as optional. And let edit.
Literature:
- Alan Cooper about the interface. Basics of interaction design. Symbol Plus, 2009
- Jeff Ruskin. Interface: new directions in the design of computer systems. Symbol Plus 2005
UPD: In the comments, trijin and zhindetz more clearly formulated the main moral of the topic: we are talking about a draft system, about removing the requirement to enter all the data immediately and consistently. That is, yes, to make optional even those fields without which the system will not work. Naturally, it will not work, but let it at least protect the data.
UPD # 2:I’ll clarify one more thing that I myself did not realize clearly when I wrote the topic. I do not discuss here the relevance of certain fields on the form (this is an important, but still slightly different topic than the one I want to convey). Rather, I propose to rethink the very concept of entering information using forms, that traditional approach when you need to fill out the entire form immediately and correctly. Instead, I suggest that an intermediate state (incomplete, incorrect, inconsistent) also be allowed to be stored in the database, explicitly marking such a state as incomplete / incorrect / inconsistent. Thus, all situations “I don’t know everything now, but maybe tomorrow I will find out”, which are traditionally solved by writing on a piece of paper, can be processed using an information system. Naturally, such data should not be allowed into the business process due to its incorrectness - everything remains as before. They just lie in the database until better times - they will not come in handy, well, God bless them.