Disabled User Inputs

A disabled user input is a user interface element that displays information inside a conventionally editable component but is actually uneditable. This element may be styled differently from the editable user inputs or it may be indistinguishable to them. Disabling an input implies that there is some scenario in which the input can become editable, otherwise, the interface could just use a conventionally read-only element. You may disable an input because the user is not authorized to edit the value, because there is no other valid value to be selected, or because the value does not currently exist. In all these cases, there exists a scenario where the user would be able to edit the inputs value, either by authenticating themselves as an authorized user, or changing other values in the application which makes updating the disabled input viable.

What a disabled input represents

A disabled input implies that the value it holds may be edited, but not given the current application state, otherwise the value would not be displayed in an input at all. This could be because the user is not allowed to edit the input, or editing the input would lead to some invalidity. If the user is not allowed to edit the input, and there is some mechanism to allow them to do so, then an edit button should be provided which either walks the user through the process of unlocking the input or informs the user of why they are not able to edit the input.

If, however, editing the input would lead to invalidity, then the input should either have an edit button which can fix the invalidity, or the invalid state should be allowed temporarily so that the user may fix the issue as they see fit. Invalidity that is caused by an incompatibility with another editable value is referred to as an Input Conflict, which should always be allowed to occur so that the user may work toward a valid state without having to navigate around invalid states.

Sometimes the invalidity occurs because the editable value does not exist given the state of the application. Consider a flight booking form which provides a dropdown to select one-way and two-way flights along with two date pickers for the departure and return dates. The return date would be irrelevant if the flight is one-way. The application could allow the user to edit the date, but this would only lead to confusion when the value is thrown out after the user submits the form. We could say that a one-way flight is incompatible with having a return date, and that providing the date when the flight is marked as one-way makes the form invalid. This would imply that we should display an error on submission of the form, but there is another solution. We have talked about rejecting invalidity—disabling the input—and allowing the invalidity, but there is one more solution to an input conflict. For our flight booker, whenever the user edits the return date, we could switch the flight to being two-way, and whenever the flight is switch to one-way, we could remove the return date.

This solution is not perfect, however, as unorthodox side-effects from user edits may go unrealized, leading to unintended results. This solution also makes it difficult for the user to reverse their action. If a user has changed their flight from two-way to one-way by accident, they cannot easily change it back to two-way, as the return date could have been deleted. Of course, a disabled input could retain this value, which may imply that disabling the input is the best solution, but there is another, almost identical approach that is still better.

Instead of secretly updating the flight from one-way to two-way as a side-effect of editing the return date, the return date should be rendered into a display component, and a button should be provided to both add a return date and switch to a two-way flight. Buttons are understood by users to be consequential, and provide a label for the action they perform. A button labeled “add return flight” provides feedback for the effect of its activation, unlike an input, leading to less confusion by the user. Buttons can also then be used to provide reversibility to the user action. Once the return time is activated, a button to “remove return flight” would take the user back to the state of a one-way flight, and subsequently clicking the “add return flight” again could being back the return date input with its prior value, such that the action is easily reversible.

See Disabled Buttons.