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

Question

If I have a form where some fields are fixed, what is the best way to present these fields to the user, from the UX 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 field hidden:

  <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):

In my opinion, the camps disabled They were more beautiful, but they are not sent with the form... (and are easily confused with "not applicable" fields) readonly do not give any visual indication that they are read-only, and in practice some of them do not respect this attribute (the select and the checkbox can still be changed). Using hidden is up OK, but I don’t know what would be the best way to present some of this data to the user (for example, in the case of the value "on/off" I used the word "yes", but I didn’t really like the result).

Is there any principle of Usability or User Experience indicating which is the best way or, if there is no better, what I should take into account when choosing between a representation and another?

Note: Unlike that related question, in this case fixed fields are not editable never (i.e. is different from a field that does not apply in this context but could apply in another). They are only displayed to situate the user, no action on their part is required.

Answer 1

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

That is, they are not edit fields/boxes (Edit boxes) yes labels (Labels). So your answer is: use option C (Hidden).

Justifications

1. In the vast majority of operating systems and, mainly, in the interaction via Web, there is the visual convention already widely established that an area bounded by a thin line (a "box") containing text is a "field" and thus used for typing text (i.e., editing). If you use option A (Disabled), you will pass to the user the information that this field is disabled for some reason and that it may eventually be enabled if this reason is changed. As is not the case, this is essentially wrong (although the problem is "just" confusion). This mess gets even worse in the case of the check-box drop-down (or combo-box), where there is even an arrow to indicate that there is more information below.

2. In my opinion, read-only option (readonly) in text boxes should be discontinued (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 an installer’s license, for example), which can also be done with labels (Labels) of C format (Hidden) in most modern languages and without a shadow of a doubt in HTML. Regardless, out of that context (where [1] text needs to be presented read-only, [2] if you want the user to be able to select and copy it and [3] there is no other way to implement it) you will only produce difficulty for the user by leaving a field visually similar to the others but read only. The user will understand that the field is editable until they try to change it once, which can generate frustration and confusion.

3. If the fields are fixed, it means they never change. Ok. Now, if you present them anyway, it’s because you judge that the user needs this information. So an important question you need to ask yourself is: is this your judgment correct? That is, does the user really need this fixed information presented in the form? If so, does it need to be in the middle of the form fields? If your concern is to present something to help the user feel safe in the interaction, this can be done in several different ways, from a text message higher up or below the form (and so, outside its contextual scope) or as a dialog window at the time of sending (Alert box), among many others. For example, "yes" means an affirmation to what? Suppose a purchase form and you are saying that "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 on transport.

Answer 2

I don’t know 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 by observing the usability of the system.

Using the readonly feature is just a convenient way where we don’t 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 may still need the field in a hidden form:

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

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

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

Of course the gain with performance is ridiculous, but anyway saves a little more memory in processing. In addition to having the cleanest code.

Could also play processing for customer:

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

In this third example, the use of process on the server is much lower compared to the previous two.

Additionally, if you want to avoid the situation exposed by @Williamnovak

From personal experience, if using disabled field, hide it and puts a text in the same format as the label. I’ve heard a lot of user saying "the system does not work, can not edit the [...] field".

The comment is correct because, if poorly employed 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, it is recommended to format visually with CSS so that you do not give the impression that it is an editable field.

It could be solved by applying a formatting in a way that presents the field as disabled. Usually with a more opaque color or eliminating the edges and background color of the input text.

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

In a CSS leave already predefined

.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 attribute "disabled" which makes the element opaque, but still you may have the problem described by William.

_{There are N ways to make these examples above. I stress that they are examples with didactic purpose.}

Finally, there is no general rule. Each 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 so a simple readonly and making the opaque element would already solve but when dealing with lay users (non-technical) 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 doesn’t even need an instruction manual. And of course it’s even more convenient when you can deliver an efficient UI at a low cost.