When should I use fields that are disabled, read-only, or hidden?

11

If I have a form where some fields are fixed, what is the best way to present these fields to the user, from UX's point of view?

  • A common field, disabled :

    <label>Foo: <select name="foo" disabled>
      <option value="1">A</option>
      <option value="2" selected>B</option>
    </select></label>
    
    <label>Bar: <input type="text" name="bar" value="C" disabled></label>
    <label><input type="checkbox" name="baz" checked disabled> Baz</label>
    
  • A common field, readonly :

    <label>Foo: <select name="foo" readonly>
      <option value="1">A</option>
      <option value="2" selected>B</option>
    </select></label>
    <label>Bar: <input type="text" name="bar" value="C" readonly></label>
    <label><input type="checkbox" name="baz" checked readonly> Baz</label>
    
  • A simple text, accompanied by a hidden field:

    <input type="hidden" name="foo" value="2"> Foo: <strong>B</strong>
    <input type="hidden" name="bar" value="C"> Bar: <strong>C</strong>
    <input type="hidden" name="baz" value="on"> Baz: <strong>sim</strong>
    

The appearance of these options looks like this (Chrome on Windows):

Inmyopinion,thedisabledfieldsweremorebeautiful,butthey are not sent next to the form ... (besides being easily confused with "not applicable" fields) The readonly gives no visual indication that they are read-only, and in practice some do not respect this attribute ( select and checkbox can still be changed). Using hidden is up to OK, but I do not know how best to present some of this data to the user (for example, in the case of the on / off value I used the word "yes", but I did not like the result ).

Is there a principle of Usability or User Experience that indicates the best form or, if there is no better, what should I take into consideration when choosing between one representation and another?

Note: Unlike this related question , in this case the fixed fields will not are editable never (ie it is different from a field that does not apply in this context but could apply to another). They are only displayed to locate the user, no action on his part is necessary regarding them.

    
asked by anonymous 13.08.2016 / 06:34

2 answers

7
  

[...] in this case fixed fields are never editable [...]

That is, they are not edit boxes ( labels), but labels labels. So your answer is: Use the C option.

Justifications

  • In most operating systems, and especially in web-based interaction, there is already a widely-established visual convention that an area delimited by a thin line (a "box") containing text is a "field" and therefore used for typing text (ie editing). If you use the A ( Disabled ) option, you will give the user the information that this field is disabled for some reason and that may be enabled if that reason is changed. As is not the case, this is essentially wrong (although the problem is "only" confusion). This confusion gets even worse in the case of the drop-down (or combo-box ) box, where there is even an arrow to indicate that there is more information below.

  • In my opinion , the readonly option in textboxes should be deprecated in all languages that allow visual programming. As far as I know it exists only to allow the user to select and copy the text to the clipboard (in a window that displays the license of an installer, for example), which can also be done with labels ( labels ) of the C format ( Hidden ) in most modern languages and undoubtedly in HTML. Regardless of that, outside of this context (where [1] text needs to be read-only, [2] if you want the user to be able to select it and copy it, and [3] there's no other way to implement that) will produce difficulty for the user when leaving a field visually similar to the others but only reading. The user will understand that the field is editable until you try to change it once, which can lead to frustration and confusion.

  • If the fields are fixed, it means that they never change. Okay. Now, if you introduce them anyway, it's because you judge that the user needs this information. So one important question you need to ask yourself is this: is your judgment correct? That is, does the user really need this fixed information presented in the form? If so, does it have to be in the form fields? If your concern is to present something to help the user feel safe in the interaction, this can be done in a number of different ways, from a text message either above or below the form (and thus outside his contextual scope ) or as a dialog box at the time of sending (em> alert box), among many others. For example, the "yes" means an affirmation to what? Assume a purchase form and you are saying "yes, the credit card will be recorded for future transactions" (and you do not want to give this option to the user, since the field is fixed). This "message" should not be a checkbox , but a warning in a yellow box somewhere else. Also, technically speaking, something fixed should not even be transmitted to the server, because if it is fixed the server can already (or should) know this information and you save data in the transport.

  • 16.08.2016 / 00:07
    3

    I do not know of any rule that says you have to do X or Y. Nor would it make sense to have a rule that dictates how to do it. This is the developer's free choice noting the usability of the system.

    Using the readonly feature is just a convenient way where you do not need to create a conditional to write as a label.

    Example with PHP,

    if ($readonly) {
        echo 'foo';
    } else {
        echo '<input type="text" value="foo">';
    }
    

    Or, depending on the case you may still need the field in a hidden way:

    if ($readonly) {
        echo '<input type="hidden" value="foo">
        foo';
    } else {
        echo '<input type="text" value="foo">';
    }
    

    If you choose the "readonly" attribute, it could be something like this:

    echo '<input type="text" value="foo"'.($readonly? ' readonly': '').'>';
    

    Of course, the performance gain is ridiculous, but it does save a little more processing memory anyway. In addition to having the code cleaner.

    I could also play processing to the client:

    <input type="text" value="foo" id="foo">
    <script>
    var readonly = <?php echo $readonly;?>;
    $("#foo").prop("readonly", readonly);
    </script>
    

    In this third example, the process usage on the server is much smaller compared to the previous two.

    In addition, if you want to avoid the situation exposed by @WilliamNovak

      

    From your own experience, if you use a disabled field, hide it and   places text in the same format as the label. I've heard a lot of user   speaking "the system does not work, you can not edit the [...] field".

    The comment is correct because if misused and depending on the target audience, it can be inconvenient and a better option is to avoid using a simple readonly . If you use, it is recommended to format visually with CSS so it does not give the impression that it is an editable field.

    You could solve by applying a formatting in a way that presents the field as disabled. Usually with a more opaque color or by eliminating the borders and background color of input text .

    <input type="text" value="foo" id="foo" class="readonly_<?php echo $readonly;?>">
    

    In a CSS leave already pre-defined

    .readonly_0 {
        border:1;
        background-color:#05bbcc;
    }
    .readonly_1 {
        border:0;
        background-color:#fff; /*na mesma cor do fundo da página*/
    }
    

    We could use the "disabled" attribute which makes the element opaque, but you may still have the problem described by William.

    There are N ways to do these examples above. I stress that they are examples with didactic purpose.

    Finally, there is no general rule. Each one defines what is best for your project. As it is something visual, the biggest concern would be with the type of user. Technical users would not cause inconvenience then a simple readonly and making the opaque element would already solve but when dealing with lay (non-technical) users may have situations that waste time with support and customer service.

    The main point is to create an intuitive design. Think about UX (user experience). An efficient intuitive design is one that no user has difficulty understanding and does not even need an instruction manual. Of course, it's even more convenient when you can have an efficient UI at a low cost.

        
    16.08.2016 / 04:13