Passive Foolproof

    Due to the fact that my rather simple but convenient idea with protection against removal inadvertently gathered a lot of positive reviews, I decided to seriously consider the problem of “protection against the fool”. In principle, the topic is quite interesting, and not beaten by many bloggers, so it should be useful to most of my readers.


    What do I mean by foolproof? These are some details of the interface that prevent accidental deletion of information, which, of course, will lead to the loss of data and nerve cells of the user.

    From the suggestion above it follows that each of us at least once found ourselves in a situation of such a "fool", accidentally clicked on the "Clear" buttons, which the grateful usabilists placed next to the "Send" button, the information was naturally lost after that, and entering it again was too lazy. I am sure there have been such cases in the life of every person. So let's get started.

    Stage One. Issue

    Let's make sense of the most popular mistakes made by site creators. Of course, they are not sadists, they are simply not always guided by reason during the creation of their brainchild.
    1. The cursor focus automatically becomes on the cancel, delete button.
    2. Buttons for deleting, canceling, erasing - are in suspicious proximity to the main navigation elements (such as buttons for moving to the next step, useful links, etc.)
    3. Elements leading to irreversible consequences are arranged so as to callus to the user of the eye.
    4. Actions leading to data loss are irreversible.

    Stage Two. Solutions

    The second stage is to deal with these problems, and decide how to avoid them.

    So: the trick.

    Focus is a very important thing. When filling out the form, the focus when you press tab should go to the adjacent field, and only after all the fields are filled in - to the button for moving to the next stage. In no case should the focus be set to the cancel, delete button, etc. If the user accidentally presses enter, in no case should there be a loss of information that has been entered for so long.

    The cancel buttons themselves must be located at some distance from the dominant button, but at the same time in direct connection with it. In this case, you can apply the grouping by color, which I described in a note on forms. Still, as an option, you can (and need) the main button to do more than the cancel button somewhere in the 1.5-2 times - then the look of the user by itself will lie on the main button, and not on the cancel button. It is also best to apply color separation: it will be best if the dominant button is brighter, more saturated than the delete button. Ideally, the delete button should be gray.

    It is best if the loafs (buttons, yeah) leading to consequences that cannot be undone far from the user's eye, but at the same time, not so that the user would need to search for it with a torch until the end of time. Those. you need to place this button OUTSIDE the first screen (the area in the browser that opens immediately after the page loads). As a positive example, you can use the WordPress engine - it has a delete post button at the very bottom, you can’t accidentally press it.

    Ideally, all user actions can be undone. But practice, as always, is very, very far from ideal, so you need to take into account 3 of the above points.

    Stage Three. Ideological

    I devoted most of this attention to this stage - in it I will describe several ideas that will help protect against non-intentional user actions.

    1. The delete / cancel button is inactive by default. There is a checkbox next to it, when checked, the button is activated - a very, very promising and intuitive idea, I recommend using it in your projects.

    2. The delete / cancel button is inactive by default. There are no elements near it, except for text of approximately the following content: “Click on the button to activate it.” Those. the first time the button is activated, and after that, you can click on it. Random clicks are eliminated, but especially gifted people can crawl through this protection.

    3. Put the “delete” link, when clicked, the removal does not occur, but the corresponding button appears. Again, eliminates accidental clicks into this area.

    4. If you plan to place several functions in addition to deletion in the system, it is best to create a drop-down list with the default option “select an action”, which, of course, does not lead to anything. Next to the drop-down list, the OK button is also placed to protect against random selection.

    Now about the disadvantages:

    1. If there is a checkbox next to a button, it is intuitively clear to most that this checkbox also activates a button. Unfortunately, this is far from clear to everyone.

    2. Without an inscription, it is rather unclear what to do. And, as you know, not all people read signatures to interface elements before clicking on them.

    3. There are practically no minuses, except for the irritation of particularly impressionable personalities, for whom making an extra click for their own good is worse than losing a pip.

    4. Monstrous protection, which, however, involves as many as three clicks, not every audience will support this decision: geeks will be unhappy, and ordinary users will not immediately understand. It is necessary to seek a compromise among the above.

    Posted by Yaroslav Birzul (DezmASter).
    Source: Web UI Blog .
    Image to post: Designfrick

    Also popular now: