I'm working on a desktop UI that uses a lot of form elements like input fields, spinners, radio buttons etc. to fill out what is basically one big form.

This form has a lifecycle with different check (validation) points that allows the user to put in data at different times (you can save in between). All form fields are enabled from the beginning. To pass through a check point, some of the fields are required. After one passes through, the respective fields will be disabled, because editing is not allowed after passing through (you can go back tho). Passing through the next check point means filling out additional required fields, and so on.

What I'm worried about is how the disabled fields are interpreted?

  • In my case, the content of a disabled field is very relevant. The disabled state says "You're not allowed to edit this value" In the mockup, name and address are already locked because the form is past the "approve" check point.


download bmml source – Wireframes created with Balsamiq Mockups

  • More often, disabled field can be seen as "not relevant". In this example the disabled state says "This value makes no sense in this configuration". The field says there are two decimal points but it's not relevant since decimal notation is not checked.


download bmml source

I tried changing the input fields into labels after they are locked, but I didn't like it because there is no indication that a field is editable at some point.

So I'm thinking: what is the intended meaning of a disabled form field?

  • Displaying information for reference that cannot be changed. – Kristiyan Lukanov Jun 1 '16 at 13:52

It is possible to distinguish between uneditable text and locked fields by placing a small lock-sign symbol against the form-field. You can enable a hover and describe why you are locking that field or simply state that "this field is locked"

Check my https://moqups.com/tapa8728@colorado.edu/yjB41GXd for a mockup. Based on your design, you can choose to place the lock symbol to the left or right

  • I like the lock icon idea. But wouldn't it be better to display the input field at least in some form? If you place a normal read-only field (a label) close to a locked field, it might be confusing and the lock icon could be interpreted as "the value is locked" instead of "the input is locked". – J_rgen Jun 2 '16 at 7:10
  • 1
    Good point. I would box the value of the "locked input field" to differentiate against the read-only fields. See my mockup moqups.com/tapa8728@colorado.edu/yjB41GXd/p:afb1f464b for updated designs. I hope this helps or at least inspires :) – icequeentanz Jun 2 '16 at 19:58
  • 1
    I went down this road (showing lock icons over read-only input fields) in my own platform recently and the problem with it, in my opinion, is that it ends up adding a lot of extra clutter to the interface. I think that's why the more common solution is to show fields as disabled. I did, however, end up keeping the lock icon solution myself, but under the compromise that it only appears when the field is hovered over or clicked on. – ke11en Jun 3 '16 at 19:07

I work on an SaaS platform with similar forms to the one you described and i don't necessarily agree that users automatically interpret disabled fields as, "This value makes no sense in this configuration", especially if there's a value in the field. In my experience, disabled fields that contain a value indicate that they're not editable, but the information being provided is still relevant to my understanding our interaction.

If you have cases where fields are disabled and the value being populated is irrelevant then i would recommend not displaying any value at all (EDIT: but still showing the empty disabled field), but in cases where valid information exists but isn't editable, display the information and show the entire field as disabled.

  • In my second example, the "decimal points" field contains a value "2". In this case it's the default value for decimal notation but it's not exactly relevant unless you want to know what the default value would be IF you checked "use decimal points". If the "2" was removed, one would think that there is no default value and you would have to input it yourself after selecting the checkbox. – J_rgen Jun 2 '16 at 7:14
  • Right, so it defaults to 2 decimal points even when the 'Use decimal notation' checkbox is unchecked? In my mind, if the user doesn't check that box they expect values to be displayed in whole numbers only, in which case i would blank out the "2" in the affiliated field when the box is unchecked. If 2 decimal places are used by default regardless of the user's selection then I would think the 'Use decimal notation' toggle doesn't belong. – ke11en Jun 2 '16 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.