2

I have a form and in the form, there is a field called ID - this field is a unique indicator and is never editable.

If I'm using Material Design principles to design my form, how am I supposed to show this to the user?

Looking at the MDC-Web's recommendations for Text fields, it looks like the only thing I can do is disable the field.

https://material.io/components/web/catalog/input-controls/text-field/ https://material-components-web.appspot.com/text-field.html

So according to their examples, my Id field should look something like below.

enter image description here

enter image description here

enter image description here

For me, these make it look like Id is something I might be able to edit, but for whatever reason it's been disabled. It doesn't seem appropriate for something like an ID field which is basically intended as information for the user only.

According to Material Design principles and preferably using the MDC-web framework, how should I display these fields?

Improve this question
2
  • Remember that the material design principles are recommendations; if you spot a problem with its use in your case, you should try and improve it so it works for you.
    – Wendy Wojenka
    Jan 24, 2018 at 11:20
  • @Wanda - true, however, this is what I would assume is a common use case. So I would like to see what the material design principles are for this before deciding to adopt my own.
    – RoboShop
    Jan 24, 2018 at 22:15

3 Answers 3

Reset to default
7

If it's a field that will always be disabled, why display it as a form field at all? Why not just display it as content, a header, or just plain-text at the top?

Improve this answer
7
  • 2
    For consistency purpose.
    – Ivan Venediktov
    Jan 24, 2018 at 11:05
  • How so? It's not something that can ever be interactable, therefore it should not appear as an input field because it isn't one. Having it be a label and a static text is far better at communicating the state than a disabled faux input field is. It makes it very clear that this is a pre-set value that cannot be altered. A disabled state makes it look like there is a way to change it and people might start looking to make that happen.
    – Wendy Wojenka
    Jan 24, 2018 at 11:18
  • 1
    I agree with @Wanda. Consistency doesn't mean forcing content that doesn't fit into the same styling if it doesn't correlate with the content.
    – Rick P
    Jan 24, 2018 at 13:13
  • 1
    Consistency is important but consistency for the sake of consistency leads to failing on "things that look the same should act the same". A static text should appear as such so the visual design reinforces that it is not editable.
    – Benjamin S
    Jan 24, 2018 at 15:12
  • It appears to be a list of user-editable fields, all of which are editable except the embedded "id" one - I see no reason it should be placed in a different position, if hierarchically it is on the same level as the other fields and has the same context
    – casraf
    Jan 24, 2018 at 15:44
0

In my projects I create span elements that resemble input elements in terms of styling and just use those. So, just copy/paste height, border, etc values in a new class and use that on the span.

Another solution would be to add readonly and disabled attributes on the input.

edit: I well deserved the negative vote. Elaborating a bit more.

It depends on the kind of the form and the result of the form. Probably, the 'correct' answer depends on multiple factors, but most importantly on the type of form you are rendering and for what purpose.

For example, if the form is rendered as an edit screen, it is highly likely that the input should be visible to give an indication that this was actually an input value. Showing it in any other way, might lead to the mistaken conclusion that the ID was generated. That is why the input should either be a disabled, readonly input field as I have mentioned before or use an element that resembles an input.

In the exact opposite case - aka where the ID was actually generated, I would use something other than input as suggested by other users, most like would use it as a header - given that in most cases the ID would be considered to be the key field in a form.

Improve this answer
4
  • This is information about how to build it, but the question is about the User Experience of it - what should be displayed to the user in a way the understand the functionality.
    – JonW ♦
    Jan 24, 2018 at 13:28
  • Well, I suppose it's self explanatory that the op wants to use input elements, I provided a solution that although it's more a UI solution, it also plays its role in UX.
    – scooterlord
    Jan 24, 2018 at 14:34
  • @scooterlord - you mind posting a screenshot of how your controls look as an example? I understand what you're saying - I just don't know how I'd show it and still make it fit in with the other material design controls. On a seperate note, yeah I wish that setting that MDC - for web would allow you to set readonly flag on and have it display differently to show that it's readonly. However, as far as I know, the readonly attribute just means it's not editable - it doesn't change the look of the control at all.
    – RoboShop
    Jan 24, 2018 at 22:22
  • @RoboShop It depends on which Material textfields you are using. Just pick the input type you prefer (I prefer the outlined one) and just disable/readonly it. You are right though, no way it could show it's readonly. If you feel it's necessary just add the helper text as well.
    – scooterlord
    Jan 24, 2018 at 23:36
0

it should not be a form element and it sounds like the state of the system.

Keep forms fit for purpose: editable data. Keep state of system as content around the form.

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.