The myth of the mandatory field
In the world of software development there are many myths and misconceptions. To move forward, and not to mark time, they absolutely must be destroyed. Today, one of the most inveterate errors, which is also quite harmful, is called the “Myth about the obligatory field”.
It will be about almost any system that uses to enter information forms. Required field is a 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 by creating such a wonderful product for them, like “substitute any product name”. Their program is almost a Platonic eidos, the purest abstraction, a mathematical formula that is computable, naturally, strictly on a set of parameters from its domain of definition. From this point of view, the required fields are the annoying little thing that you have to put in to teach stupid and uncouth users how to correctly enter information into the system with which they got the honor to work.
It is also believed that incorrect (incomplete) data is so terrible that even storing it in the database is incorrect. Well, laziness is, of course - from the developer’s point of view, 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 the data will actually be used in the system.
')
What does modern science of user interaction design say? First, it became clear (I don’t know to whom and when, but quite a long time ago, see [1] and [2]) that, after all, 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 their goals. Like an iron - if you need something to stroke, you turn it on. If, instead of ironing, he will modally offer to download updates from the Internet, it is clear where such an iron will fly. Alan Cooper [1] recommends representing your product users 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 Sergei Bodrov Jr.:
There will generally be something about the required fields, ask habraiser? Just now will begin.
The thing is that our real world is not a mathematical model, the parameters of which are known at any time. For real life is characterized by a lack of information rather than its presence. A person filling out a form may not have the required data - and there may not be any data within all visible limits, that is, there may not be any. This problem cannot be solved simply by making the field mandatory - the value will not be taken out of thin air. Entering mandatory fields on forms for the sake of integrity and completeness of data, we actually interfere with the use of the system . Faced with such a situation, the user either will not fill out the form (and will not be able to work with the system at all), or will fill in the missing data with fish - invented or meaningless data. And this is not evidence that the user is bad or trying hard, but only that the developed system is not flexible enough to be used in real- world conditions. What happened in the second case (entering fish) is generally a hoax. The system developer can pretend that everything is all right, but in fact he is to blame for this deception. And it is not clear who and what won at all - the user had a headache, and incorrect data got into the system. Yes, they got so that it is already impossible to detect, filter or clean them automatically - unlike the case if the user simply indicated that the information is missing.
What to do? You need to make good programs. Namely, yes, still not put the integrity of the database schema at the forefront, but set there the goals and objectives of users. In other words, to accept incomplete and in some cases incorrect data from the user, naturally, with the possibility of correcting them in the future. Contrary to delusion (yes, to another one) it is possible, it is not so difficult and it even works. In addition, you need to somehow help, to prompt the user, where, what kind of data and why he does not have enough. That he saw and controlled the situation.
How many required fields should be on the form? Ideally, zero. Is it always possible? For me, one of the examples 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 doesn’t ask for anything — even though 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 related to the user's tasks, and not to the needs of the system itself. System as a tool, remember? Just about the example with Firefox - Google Chrome, for example, solved the Firefox problem, being updated quietly at the moment when the user reboots it. The user does not need to know about this - he does not know. Worthy example to follow. I confess I didn’t even understand at first, why didn’t he ever ask me when to update?
There was also a myth about important fields (those that are optional, but desirable to fill out). It is still simpler here - it is impossible to force the field to be filled. Consequently, at least mark the field as mandatory, though not mark it - they still write fish, bullshit, 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. A developer to mark the field as optional. And allow to edit.
Literature:
UPD: In the trijin and zhindetz comments, the main moral of the topic was clearer: it’s about the draft system, about removing the requirement to enter all data at once and consistently. That is, yes, to make optional those fields, without which the system will not work. Naturally, it will not work, but at least let it save the data.
UPD # 2: I will clarify one more thing that I myself did not realize clearly when I wrote the topic. I do not discuss here the questions of the appropriateness of certain fields on the form (this is important, but still a slightly different topic than the one I want to convey). I would rather suggest rethinking the very concept of entering information using forms, the traditional approach, when you need to fill out the entire form at once and correctly. Instead, I propose an intermediate state (incomplete, incorrect, contradictory) to also allow storing in the database, explicitly marking such a state as incomplete / incorrect / contradictory . Thus, all situations “I know not everything now, but maybe I’ll find out tomorrow,” which are traditionally solved by writing down a piece of paper, can be processed using an information system. Naturally, such data do not need to be allowed into the business process due to their incorrectness - everything here remains as before. They simply lie down in the database until better times - they will not be useful, well, and God bless them.
It will be about almost any system that uses to enter information forms. Required field is a 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 necessary from the point of view of the subject field (for example, full name and date of birth of the person, if we are talking about the passport office);
- All 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 to make accruals on them);
- Important fields are those that are not necessary, but it is desirable to fill in (for example, the justification for the change) with the motivation that the user should rather sweat when not needed, than forget to enter a value when needed.
Traditionally, programmers believe that they are doing a favor to the rest of the world by creating such a wonderful product for them, like “substitute any product name”. Their program is almost a Platonic eidos, the purest abstraction, a mathematical formula that is computable, naturally, strictly on a set of parameters from its domain of definition. From this point of view, the required fields are the annoying little thing that you have to put in to teach stupid and uncouth users how to correctly enter information into the system with which they got the honor to work.
It is also believed that incorrect (incomplete) data is so terrible that even storing it in the database is incorrect. Well, laziness is, of course - from the developer’s point of view, 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 the data will actually be used in the system.
')
What does modern science of user interaction design say? First, it became clear (I don’t know to whom and when, but quite a long time ago, see [1] and [2]) that, after all, 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 their goals. Like an iron - if you need something to stroke, you turn it on. If, instead of ironing, he will modally offer to download updates from the Internet, it is clear where such an iron will fly. Alan Cooper [1] recommends representing your product users 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 Sergei Bodrov Jr.:
You stand on the corner of a busy street and imagine that you are not here. Rather, you are not at all. Pedestrians go, honking cars, store doors open, passengers change at the bus stop. That is, in principle, the world continues to live without you. It hurts to understand. But it is important ...Of course, I don’t want to say at all that a programmer is an unnecessary profession, I myself am a programmer and I don’t really think so. It's just a thankless job. No one will come and praise the well-implemented algorithm. If the program is good, it will be used without additional questions. So it should be, just to be a programmer, you need to get used to it. And these are the people who walk down the street and take turns at the bus stop - these are your users. They use things as they need them. Including your product. Without you. They do not know anything about you, do not want to know and will never know. Sergei Vitalyevich, when he is trying to drive readings 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 any type of rating, even if at the time of design you thought that without rating I can not do. As for the example of the iron that downloads updates, it is not taken from the finger at all - note how the Firefox browser behaves when turned on.
There will generally be something about the required fields, ask habraiser? Just now will begin.
The thing is that our real world is not a mathematical model, the parameters of which are known at any time. For real life is characterized by a lack of information rather than its presence. A person filling out a form may not have the required data - and there may not be any data within all visible limits, that is, there may not be any. This problem cannot be solved simply by making the field mandatory - the value will not be taken out of thin air. Entering mandatory fields on forms for the sake of integrity and completeness of data, we actually interfere with the use of the system . Faced with such a situation, the user either will not fill out the form (and will not be able to work with the system at all), or will fill in the missing data with fish - invented or meaningless data. And this is not evidence that the user is bad or trying hard, but only that the developed system is not flexible enough to be used in real- world conditions. What happened in the second case (entering fish) is generally a hoax. The system developer can pretend that everything is all right, but in fact he is to blame for this deception. And it is not clear who and what won at all - the user had a headache, and incorrect data got into the system. Yes, they got so that it is already impossible to detect, filter or clean them automatically - unlike the case if the user simply indicated that the information is missing.
What to do? You need to make good programs. Namely, yes, still not put the integrity of the database schema at the forefront, but set there the goals and objectives of users. In other words, to accept incomplete and in some cases incorrect data from the user, naturally, with the possibility of correcting them in the future. Contrary to delusion (yes, to another one) it is possible, it is not so difficult and it even works. In addition, you need to somehow help, to prompt the user, where, what kind of data and why he does not have enough. That he saw and controlled the situation.
How many required fields should be on the form? Ideally, zero. Is it always possible? For me, one of the examples 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 doesn’t ask for anything — even though 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 related to the user's tasks, and not to the needs of the system itself. System as a tool, remember? Just about the example with Firefox - Google Chrome, for example, solved the Firefox problem, being updated quietly at the moment when the user reboots it. The user does not need to know about this - he does not know. Worthy example to follow. I confess I didn’t even understand at first, why didn’t he ever ask me when to update?
There was also a myth about important fields (those that are optional, but desirable to fill out). It is still simpler here - it is impossible to force the field to be filled. Consequently, at least mark the field as mandatory, though not mark it - they still write fish, bullshit, 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. A developer to mark the field as optional. And allow to edit.
Literature:
- Alan Cooper on the interface. Basics of interaction design. Symbol Plus, 2009
- Jeff Raskin. Interface: new directions in the design of computer systems. Symbol Plus, 2005
UPD: In the trijin and zhindetz comments, the main moral of the topic was clearer: it’s about the draft system, about removing the requirement to enter all data at once and consistently. That is, yes, to make optional those fields, without which the system will not work. Naturally, it will not work, but at least let it save the data.
UPD # 2: I will clarify one more thing that I myself did not realize clearly when I wrote the topic. I do not discuss here the questions of the appropriateness of certain fields on the form (this is important, but still a slightly different topic than the one I want to convey). I would rather suggest rethinking the very concept of entering information using forms, the traditional approach, when you need to fill out the entire form at once and correctly. Instead, I propose an intermediate state (incomplete, incorrect, contradictory) to also allow storing in the database, explicitly marking such a state as incomplete / incorrect / contradictory . Thus, all situations “I know not everything now, but maybe I’ll find out tomorrow,” which are traditionally solved by writing down a piece of paper, can be processed using an information system. Naturally, such data do not need to be allowed into the business process due to their incorrectness - everything here remains as before. They simply lie down in the database until better times - they will not be useful, well, and God bless them.
Source: https://habr.com/ru/post/92054/
All Articles