81

Should I use labels for read-only information, or should I use read-only text boxes to maintain the look of the fields?

It seems to me that if something is in a textbox it implies there is some way to edit it, whereas plain text is explicitly read-only.

Update: While my question is similar to Locking input form fields, does it make sense?, mine is different in that I'm referring to fields that are never editable by anyone. It's not based on the user's rights or role.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Improve this question
8
  • 2
    possible duplicate of Locking input form fields, does it make sense?
    – Dave Haigh
    Sep 18, 2015 at 14:34
  • 7
    @Dave, I don't think this is a duplicate. That linked question is about the situation where the disabled fields would be editable if the user had different permissions. This question appears to be about the situation where the fields are always read-only.
    – Graham Herrli
    Sep 18, 2015 at 16:17
  • 1
    @DaveHaigh, thanks for the link to that question. I appreciate the information there but I think my example is different because the data is not user supplied information. Access isn't based on the user role. It is never editable; it's merely informative.
    – Homer
    Sep 18, 2015 at 18:27
  • 2
    @Homer thanks for the clarification. I've retracted the close vote.
    – Dave Haigh
    Sep 21, 2015 at 7:45
  • 1
    What I wonder is: Why would you show and ID anyway?
    – Verena Haunschmid
    Sep 21, 2015 at 10:02

12 Answers 12

Reset to default
73

If it's uneditable, show it as plain text, no text field.

Putting uneditable text in a text field can cause confusion. The user might wonder (and with good cause) why they can't edit the value.

Improve this answer
4
  • 27
    In the case of forms that aren't on a webpage: if the user might benefit from copying and pasting the value, remember to make the labels selectable (like in browsers)
    – LS97
    Sep 19, 2015 at 8:05
  • 5
    There are commonly known design patterns to visually indicate some field is read-only, even if it's a text field. On a certain platform text fields are the only way for non-web applications to allow for copying text without the hassle of a contextual sub-menu.
    – user67653
    Sep 19, 2015 at 9:29
  • 3
    Not sure I agree with this. If the UI technology doesn't allow selecting of labels a read only text box allows a user to highlight the text and copy it to the clipboard.
    – Andy
    Sep 19, 2015 at 14:53
  • 6
    I strongly disagree in case of business apps except the use of web UI. Mixing data in labels and text fields creates visual chaos and problems with usability. The only acceptable case is web page, where read-only controls might look confusing e.g. because of browser support. Of course, if creating media player or computer game with three text fields... do whatever you want. But not in data-oriented app.
    – miroxlav
    Sep 20, 2015 at 12:18
33

In terms of UX, copying into clipboard should be taken into account.

I'll borrow your mock-up. From what you indicate, your application is rather a business one than entertainment one. In business apps, possibility of copying data into clipboard is crucial for the UX – even for read-only data.

On Web page

you can create selection and copy data into clipboard even if they are presented as text. No problem with fields Id and Stock Number here:

enter image description here

  • ...and what about drop-down boxes?

    • You can display them as text fields or labels when read-only

In application

what is not in edit box, is inaccessible and also looks incoherent

enter image description here

  • ...and what about drop-down boxes?

    • You can display them as text fields when read-only
    • When they are editable, you can modify them so Ctrl+C on focused drop-down box copies its displayed text into clipboard
Improve this answer
8
  • Can't you display the text as a simple text, not a label or as a disabled input?
    – A.L
    Sep 21, 2015 at 9:16
  • @A.L Labels are typically the control used for 'simple text', did you have something else in mind?
    – Jacob Raihle
    Sep 21, 2015 at 12:05
  • I was wondering if you used the same type of widget for displaying the first and second ID. If the first one is a label, does it select the second ID? (that's how an HTML <label> works)
    – A.L
    Sep 21, 2015 at 13:50
  • @A.L: The first is a STATIC widget (there is no "label" widget in Win32) the second is an EDIT with style WS_DISABLED (or programmatically, EnableWindow(hWnd, FALSE)), the third is an EDIT with style ES_READONLY
    – Ben Voigt
    Sep 21, 2015 at 15:51
  • 1
    @A.L: I believe that the annotations reflect that fact that the helper class used in WinForms to create a STATIC widget is System.Windows.Forms.Label. But there's no relationship at all to the HTML <label> tag.
    – Ben Voigt
    Sep 21, 2015 at 18:28
27

  • If users can't edit the input, prefer using a label to avoid user confusion.

  • If users can edit the input in some cases, prefer using readonly textboxes.

Improve this answer
14

This answer is for desktop UI-s with distinct control types, not for in-browser forms where most content can be selected anyway, regardless if it's in an editable control or not.

This is my personal preference as a user (and this is what I do when I develop UI-s): I always use locked textboxes with black (not dimmed) text and a grey background for non-editable information. (I do this even if a particular field is never editable.)

The reason is because this way the user can still select and copy such information from the UI without having to type it in somewhere else. I usually remove the border from the textbox so it doesn't stand out but if the user double-clicks / right-clicks the textbox, they can select Select All and Copy.

I use this approach for some form labels, too (mostly the longer ones), since long UI instructions may need to be copied into emails or other documents sometimes and it's easier for users to copy & paste than to type up long sentences correctly.

Improve this answer
7

If the field doesn't actually provide useful information to the user, it should be a hidden field (as in display: none;). In some cases, this information needs to be in the form to be sent to the server (like the ID of the transaction), but it doesn't help the user make any sort of decision. In such cases, there's no reason to actually display the field and it should be hidden.

This suggestion obviously doesn't apply to information that is relevant to the users' decisions, in which case the data should be plain text, not in any sort of text field.

Improve this answer
3
  • 2
    I agree. In the example, it looks like 47 is the row number of this product in the database. Generally, this is not useful data for users of the system.
    – Dan
    Sep 18, 2015 at 22:24
  • 5
    Note: Disabled inputs (which appear similar to, and are easily mistaken for read-only inputs) are not submitted with the form.
    – Martin
    Sep 18, 2015 at 22:25
  • 3
    This is good advice for web apps, though it's not clear the OP is referring specifically to those. @Dan - Agreed, though only because we have a human readable 'ID', the stock code. If the number were the only available UID, it might be very beneficial to leave it visible to the user, so in case the textual fields are liable to change, a user could always remember the UID to quote to colleagues/devs/etc. Speaking from my own experience, at least!
    – underscore_d
    Sep 18, 2015 at 22:47
3

My preference is to shade the background to indicate a field whose contents are not editable, but can be selected and copied to the clipboard. Dim foreground text on an editable-color background would to me suggest a "watermark" that is not part of the field contents (e.g. a date field which dimly shows "MM/YY" would to me indicate not that the field contains those characters, but rather that the field wanted to convey the message "MM/YY" to the user). In general, I would expect text not in boxes to be used for labels, rather than data.

Improve this answer
5
  • 1
    What…no. Just make your labels selectable and copiable. I hate it when websites don't allow me to copy text for whatever reason…
    – Blacklight Shining
    Sep 18, 2015 at 20:13
  • 1
    Even if label text is copyable via mouse, labels can't generally get focus, so many techniques that could be used to select all the text in a box won't work on a label.
    – supercat
    Sep 18, 2015 at 21:52
  • 1
    @BlacklightShining Not everything is about webapps. Neither the question nor this answer were specified as such.
    – underscore_d
    Sep 18, 2015 at 22:51
  • @supercat I've found that I can select all of the text in most labels by triple-clicking or by dragging from the beginning to the end of the text.
    – Blacklight Shining
    Sep 19, 2015 at 1:05
  • @underscore_d …right. I meant to say…uh…“things”? Something not webapp-specific.
    – Blacklight Shining
    Sep 19, 2015 at 1:05
1

I'd say the rule of thumb is, if in the context:

  • the text is never editable, use a label
  • the text is sometimes editable based on other variables in the context, use a read-only text box (which will of course switch to editable when applicable)

This will instill in the user the potential differences based on their choices.

Improve this answer
1

My suggestion would be a combination of most other answers.

  • If the field is not important to the user (like the field id in this case very probably is), don't show it to the user.
  • If the user may want to copy the input (RSA Key, URL, ...) a read-only textbox will make it easier to do so (ideally with a select-all on focus).
  • If the user can theoretically edit the fields value, but not now (i.e. an email only editable in the profile settings)* and/or it's in a table with a lot of textboxes, a read-only textbox may still be the way to go in order to indicate user given input and/or keep the row in the same style as the other input field rows. In the example, the ID clearly breaks the styling of the over rows and looks less consistent.
  • In any other case, you should probably use a label.

* If this is the case, you should hint this to the user, i.e. "to change your email, please go to profile settings".

Improve this answer
1

There are certain circumstances where there are advantages to styling a field that is never directly editable as having a 'disabled' state: e.g. the field is part of a form submission, and/or the user is expected to verify that the information is correct.

For instance:

  • if a value is populated based on some other combination of user-editable values on the form
  • if the user is seeing the fields only in order to confirm or reject their content (for instance, signing off an invoice), typically because the data comes from another source (and your application may never have a form in which those fields are editable).

The value of this would be to distinguish between contextual information that a user is not required to process (an ID) and information contained in the form submission (even if the form submission itself is strictly just a transaction id, the effect of the form submission is to authorise those values to be used).

Improve this answer
0

I agree with the other answers, that you should use a label to avoid confusion if the field is uneditable, but sometimes it is very useful to use a read-only text box so the user can copy from it. Although it depends on what you're using to run the program, labels can not usually be copied from.

Improve this answer
0

It would be better to separate this information out from the form altogether, so that your users don't have to think about what this information means and why they can't edit it. If it's separate, they can just focus on filling out the form on its own.

Improve this answer
0

if you are constrained with some framework and these are the only two options then
Leaf's and Doddy's answers are the best solutions to your dilemma.

However if you are not constrained and you can really design to optimize user experience I would suggest the following states:

Editable

For editing the inputs must be slightly 3D, to give some depth, and the user will know that they are editable

Non Editable

Having the data belong to the same model and also have such a distinct look and feel, either be in a textbox or either look like a label is not consistent and pleasing to the eye.
One solution is that they non-editable fields have a different color and a contrasting background color and these are completely flat. Flat is like printed out, end of story, nothing more to be done here.

For desktop with a cursor situations:
Don't forget to set the cursor to a hand cursor. The action is that when the user clicks on this flat field you get a copy of the text in the clipboard. Also make sure that there is tooltip that informs the user of the copying-to-clipboard action in order to avoid losing already existing clipboard data.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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