20

I have a form showing properties of an entity in a web app: some of the fields in the form are read-only and some are editable. Within the editable fields, some are required to be filled with a value an some are optional.

How would you mark this distinction?

The obvious answer would be to use an asterisk to mark the required fields, yet it seems problematic to me since the read-only fields are also kind of required - they cannot have an empty value, only the user is not the one doing the editing but the application assigns the value automatically...

I thought about doing the reverse - mark the optional editable fields instead with the text 'optional'...Anyone knows an example of this? Or has a better solution?

0

7 Answers 7

16

The best way here is to remove all read-only fields from the form. You have to find some other way to show this info. But if there is no way to remove them, so make sure that they don't look like input field.

For fields with default value you just have to put some value in them; with black input font color. (grey color will confuse them, because a lot of forms use it as a label to field)

For required fields just use asterisk symbol near label.

enter image description here

4
  • 4
    +1 Quite right - read-only values should not look like fields :-) Jul 20, 2011 at 11:48
  • +1, and one more for the asterix symbol (which, I guess, is the depiction of a small man with big mustaches and a winged hat) ^_^ Jul 20, 2011 at 15:15
  • @Dmitry Semenov. No offense intended :), it was just amusing (even I if i usually commit much grosser mistakes with the English language). Jul 21, 2011 at 6:49
  • 1
    I completely agree - read only fields should look like text only - without any input field. What I was concerned about was that this would not be clear enough to the users in terms of whether they whole mandatory/optional distinction even applies to them (it doesn't). From all the answers here it seems like it should be appropriate to use the regular markings for mandatory (asterisk) and optional. If I come across some relevant results on user testing on this I'll post it...Thanks again!
    – Olgaarsh
    Jul 24, 2011 at 6:47
25

IMO read only fields shouldn't be fields at all. This would look something like that:

enter image description here

6
  • +1 Quite right - I knew something was wrong with mine - thanks for pointing this out. Jul 20, 2011 at 11:11
  • Hey, I was first :) Jul 20, 2011 at 11:41
  • @Dmitry: No you weren't - we probably wrote it at the same time but I published first :P But I'll give you my upvote for compensation ;)
    – Phil
    Jul 20, 2011 at 12:22
  • 3
    Yes, the "Read only value" in this example could (and perhaps should) be marked up as <input readonly disabled>. Then style it so it looks different from a field. Jul 20, 2011 at 22:47
  • 1
    @Bennett: Exactly. Just because ist doesn't look like an input filed doesn't mean it can't be one :)
    – Phil
    Jul 21, 2011 at 6:43
9

I agree with Phil, read only should not be fields. It is considered better practice now to say up front 'All fields are required unless stated otherwise' or similar and clearly mark optional fields. If you don't need to ask something then you really shouldn't ask it.

Once again, I refer to you exhaustive research carried out by Luke Wroblewski http://static.lukew.com/webforms_lukew.pdf (this is a link to a PDF). Here is some related reading by Luke W: Marking Required vs. Optional form fields - Luke Wroblewski

3
  • I always default to Luke, but this is one recommendation that I was surprised that our users disagreed with. We had a lot of comments during testing asking why we didn't mark required fields with an asterisk. Which was silly on some of our forms as all fields were required. ;)
    – DA01
    Jul 20, 2011 at 14:25
  • I also considered using the 'optional' instead of the asterisk for mandatory, but it's also important to be consistent across different forms in the application: for some forms, the optional was the exception and for other it was half-half..so for the sake of consistency (and familiarity), I went with the asterisk approach. Since these are not sign up but property forms, even of some information is optional it should still be there for users who want to fill it.
    – Olgaarsh
    Jul 24, 2011 at 6:52
  • I suggested/added a link through an edit to your post to update the outdated link.
    – Adriaan
    Jul 10, 2012 at 11:50
6

Optional values that are going to be assigned a value by the system could usefully show what that default value is going to be.

Something like the following image comes to mind where the top item is read-only, the middle one is editable and shows the default value (in light grey) should it not get changed by the user, and the bottom one is editable, required, and has no default value. As soon as the middle item gets focus or is edited then the grey default value is replaced by whatever the user enters.

[edit] I changed the top field to not looking like a field at all

enter image description here

4
  • 1
    I previously had the top field as a field with grey background but realised that it shouldn't look like a field at all (I knew something was wrong with it... :-) Jul 20, 2011 at 11:07
  • 1
    Is grey text a good choice for a default value? Why not just auto-fill the field, but let users click and change the data? When I've seen grey text in fields before, it's either been a prescription (like 'password'), or it has meant the data can't be edited. Either way, I'd suggest that grey text hints something cannot be edited. Jul 20, 2011 at 16:22
  • I considered this & wondered about the following scenario: The middle item looks as above; user clicks in the field, the grey default value is removed; user enters a value which appears in normal black; user then deletes the entry so the field is empty. Once focus goes out (tabbed out or clicked out), the default value is shown again in grey. This could not work if the default value was in normal black - the default value would have to be distinguishable and discrete. Now I've not seen any forms that go this extra mile - does that make it a bad thing? Would be interesting to try it out. Jul 21, 2011 at 8:05
  • I'd say that fields which appear to reset themselves look uneditable - as though the value is applied, but unchangeable. And again, I still think grey things look 'un-usable' by default. In your case, I wonder if it'd be better just to rely on the standard practice of mandatory asterisks and on-the-fly validation popups / flags. Not as neat, but I think it would be less ambiguous. Could be worth an A/B test, actually. Jul 21, 2011 at 19:45
1

While I agree that the non-editable fields shouldn't LOOK like fields, there are arguments to keep them fields for accessibility purposes. Form fields do have disabled and readOnly attributes you can leverage. Sometimes it makes sense to use these in various situations. The key is that they look different and appear to not be editable by default.

As for marking required vs. optional, I like to mark whichever is the exception. If only a few are required, I add (required) to the label. If only a few are optional, I add (optional) to those. That said, from research I've been a part of, a lot of users comment if they don't see the 'standard' asterisks marking required fields. I find it an example of familiarity trumping best practice (there's a UX term for that that completely escapes my mind...someone help me with that...)

7
  • Why would keeping them as fields aid accessibility? Also, totally agree on conforming to expectation - even if it's technically worse practice. Jul 20, 2011 at 16:23
  • If it's a form, a screen reader is likely reading the label then the input as pairs. For really large forms, keeping them form inputs might make it easier for the screen reader. But as always with screen readers, there's an exception to every rule.
    – DA01
    Jul 20, 2011 at 16:38
  • Is there any way to mark that 'pairing' through other ways, though? Jul 20, 2011 at 17:35
  • @jbreckmckye Why not simply mark them up as disabled readonly fields? How they are marked up has nothing to do with how they look. Jul 20, 2011 at 21:58
  • @Bennett There are some limitations to styling form elements across browsers. Even the newest ones. That said, you can do quite a bit.
    – DA01
    Jul 21, 2011 at 2:03
0

I wouldn't make read-only data part of a field in the first place, but if you really must, there is an existing pattern of greying read-only fields out. This used to be common in Microsoft products, especially Windows 9x. Consider the 'target' field below:

enter image description here

I don't like this pattern. It's frustrating (it appears to offer edit functionality to unfamiliar users, only to fail them), it's harder to read (because of the morass of grey), and it usually hints that the text is editable sometimes (which in your case, it isn't). Still, it is an existing and familiar-ish pattern that does what you need.

Also, I have to ask: why are you showing the read-only data at the same time as asking for edits? Depending on the use case, your workflow might make this unnecessary (especially if the people performing the edits and reading the data aren't actually the same).

1
  • I'm showing read only as well as editable data because they are all properties of the entity, all related to each other (content-wise), and are all part of the same task flow of problem solving (it's difficult to predict when the users will need which piece of information). Also some of the editable fields are not always edited - sometimes the user will just want to read the information and not necessarily edit it.
    – Olgaarsh
    Jul 24, 2011 at 6:57
0

A simple Google search of this will yield pretty consistent results. There’s a growing consensus that on most forms, the majority of fields are required, and only a few are optional, and that only optional (not required) fields should be indicated as such.

According to the research I found, this seems to come from back-in-the-day when we used to use paper forms. (Paper was a very thin and flexible material made from the wood of trees, and was used for recording and transmitting information due to its light weight and ability to store ink.) During this time, it was assumed that every question was required unless indicated otherwise.

Therefore, the research concludes it is best to leave required fields unmarked, while providing a text indicator, such as the word "Optional", for the fields that are not required. Textual indicators are more accessible than symbols or icons, which cannot be translated, and whose meanings are not immediately apparent.

It seems that the reason you might typically see the exact opposite in the wild is due to HTML code. <input/> elements are optional by default; it’s only until you add the required attribute that they become required. In the world of HTML forms, “requiredness” is opt-in. This coding convention seems to have carried over into design. Maybe because CSS allows you to do this:

input[required]::after { content: '*'; color: red; }

Maybe that’s not always a good thing.

Here is some reading material:

Your Answer

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

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