in this question (How do I choose between disabled input fields and plain text for a read only view?) the problem has been discussed for web.

Do these answers also apply for desktop apps? I have this Windows desktop application, where we have to decide what to do with disabled input.

I see two types:

  • information that is always read-only, eg. the name of a supplier next to the supplier id. Could be due to user rights to.
  • Information that is sometimes editable, sometimes not (depending on e.g. a status for the record)

How do you deal with this. Do you show read-only info as plain text or in items. Also, the user should be able to copy the values.

  • 2
    Why do you believe the answers might be different for a desktop application? – dhmstark Sep 27 '12 at 10:46
  • I don't know, platform guidelines, best practices for desktop...? also, can you mix plain text with disabled items for these two types? – Kim Sep 27 '12 at 11:23

Whether you’re talking web apps or desktop apps, disabled means there is something easy the user can do to make the control responsive, generally something in the current window. Getting one’s permissions changed by an admin does not count as easy. Therefore, use a plain-text look (black text on a neutral background, avoid using a frame) if the user doesn’t have rights to edit the field. In contrast, use disabled (gray text on a neutral background, include the frame) if the field becomes editable on record status change, especially if the user can do something in the same window to immediately change the status.

However, you need to be careful with disabling fields because the disabled look by design encourages users to skip over the control. Sometimes users will take disabled to mean “not applicable”; that is, not only is the field not currently editable, but value it shows is irrelevant and should be disregarded. Sometimes this is correct. For example, the Reasons for Disapproval field can be disabled if the user sets the Authorization to “Approved” –it doesn’t matter what’s in the Reasons for Disapproval field (if anything) because it’s irrelevant.

On the other hand, sometimes the non-editable field is very relevant. For example, suppose the user cannot change the Transfer Protocol field when a data connection is live, but you want process-control users to see and verify the Protocol is the correct value for the conditions. Disabling in that case should be avoided. If the value is relevant to the users’ task in its current state, use a plain-text look, and maybe provide some other hint that the field can be made editable. Generally, users ignoring a relevant field is worse than users not realizing it can become editable.

I’ve everything on disabling versus the alternatives at Controlling Your Controls.

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.