Read only form controls

shixiedesign commented 5 years ago

A read only variant of Text input is suggested here: https://github.com/carbon-design-system/carbon-contribution/issues/13#issue-421692303

The “Disabled” option is not viable, as the label and entered data is not accessible. Proposal is to simply remove the line at the base of the "Filled" version of the component, so that it closely matches with the Disabled component, but passes accessibility.

Overview of component (updated May 13)

Read-only variant will be keeping underline and dropping the background of the field. We need the underline for low-vision users to recognize this as a text field. Also loosing the underline makes the element a button-style, which would be confusing.
Not moving the text position after all. Keeping text 16px away from left of border helps with preserving the form structure.
Regular text cursor and allows text selecting
Add not-editable icon, icon in PR https://github.com/carbon-design-system/carbon/pull/2710
Optional tooltip when hovering not-editable icon, to provide reason for the field being read-only
Overflow text in the field will show in tooltip on hover
Should be considered a state, possible readonly attribute
Follow the standard readonly attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-readonly

Design spec (updated May 13)

In context explorations:

chrisconnors-ibm commented 5 years ago

awaiting specification.

lovemecomputer commented 5 years ago

i have a couple of questions for implementation:

semantic: if this is a unique state, should we think of it as being labelled read-only/readOnly?
design: have we decided on design spec for this?

elizabethsjudd commented 5 years ago

From my understanding the implementations should follow the standard readonly attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-readonly

shixiedesign commented 5 years ago

Thanks everyone for the thoughts and discussion. I've updated the original issue description with spec, and summarized all the comments here. This issue is now ready for development!

shixiedesign commented 5 years ago

Note

Moving issue back to visual design stage to figure out the following potential changes:

Potentially removing not-allowed cursor. Waiting on feedback.
Lock icon with tooltip containing reason why field is read-only

lovemecomputer commented 5 years ago

should we afford for any kind of status messages/icon/tooltip/etc as part of the pattern for readonly input fields? (typically on forms, if i can't edit something, i want to know why and where i need to go to be able to do so).

i can see the case for product teams being responsible for this, but if we have a particular suggested pattern for how to handle that hinting, we could build it in. (e.g. a lock icon in in the field that can launch a tooltip)

shixiedesign commented 5 years ago

Lock icon is a good idea @lovemecomputer ! Lemme try it out...

shixiedesign commented 5 years ago

Thoughts everyone?

lovemecomputer commented 5 years ago

@shixiedesign yeah that makes sense! especially nice that it fits in the spot we already have for show/hide password :)

shixiedesign commented 5 years ago

Talking to Anna and Lauren, the lock icon has potential confusion with the idea of security. I tried making a not-editable icon too. See below...

Do you guys have more context on which is better? @JordanWSmith15 @werdnanoslen

Changes below include:

ditching not-allowed cursor. It's a bit too aggressive
icon & icon hover tooltip for showing reasons why this field is not editable
not-editable icon or lock icon?

JordanWSmith15 commented 5 years ago

@shixiedesign I think the edit with the cross-out is better for my use cases. Locks might make the user think that they can click to unlock, or that there is somewhere they can go to unlock, which is not the use-case (in my product anyway).

shixiedesign commented 5 years ago

Finalized design spec. Ready for dev 🤖 updated May 23

Read-only 1

Light variant spec

Only difference from default is changing field background to $field-01 so it is the same as background color.

Read-only 2

JordanWSmith15 commented 5 years ago

🎉

emyarod commented 5 years ago

@carbon-design-system/design do we want to apply this to number inputs and textareas as well?

also, is there a light version for this variant?

chrisconnors-ibm commented 5 years ago

(@emyarod please tag @shixiedesign directly for questions like this.)

shixiedesign commented 5 years ago

Yep there's always a light variant. I will provide spec in a minute. And yes to number input. I'd say no text area at the moment until we see a need arises. 👍

JordanWSmith15 commented 5 years ago

@shixiedesign I didn't want to get into it, as the text input is my immediate need, but numeric input becoming read-only is also a use case for me, including just about every other component for user input: Check box, date picker, radio button, slider and toggle (to name the most common). These could still be represented the same way though... a line with text shown as non-editable. You did this with "expiration date" in your in-context example, whith the date picker component. Seems to work well enough.

shixiedesign commented 5 years ago

Team agreed to adding Read-only state to

[x] Text input
[x] Number input
[x] Date picker

Slider and toggle should be following disabled state in these situations, or a number input at read-only state. Waiting on text area component until need arises.

emyarod commented 5 years ago

@shixiedesign for the number input and date picker, do we still want the tooltip with the input field value?

also is there a mockup for read-only mobile number input?

emyarod commented 5 years ago

on a side note, this may depend on https://github.com/carbon-design-system/carbon/pull/2781 due to the tooltip usage for read only inputs

shixiedesign commented 5 years ago

@emyarod Tooltip with input field value should only show up where there's an overflow of content. This should apply to both number, text, and date input.

The tooltip on Edit--off icon should however be always available. On mobile devices, icon tooltip should trigger on tap (do we have that?)

Structurally, the spec should be similar to text input, where icon is 16px away from both edge of field and content of the field. See https://github.com/carbon-design-system/carbon/issues/2177#issuecomment-492047569

Number input read-only variant

Date & time picker read-only variant

DatePicker ready-only

emyarod commented 5 years ago

going to label this as an epic and track the read only versions of text input, date picker, and number input separately

stale[bot] commented 5 years ago

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

JordanWSmith15 commented 5 years ago

@shixiedesign This one is marked as stale, which is OK I guess, but has the read-only states for text entry or anything made it into the sketch kits or component demos?

jeanservaas commented 5 years ago

Hi @JordanWSmith15

@shixiedesign is on vacay for the next week and a half so I'm trying to get up to speed on some of this stuff. So sorry for all the confusion!

According to our process ( @laurenmrice correct me if i'm wrong) our components don't go into the kit if they haven't been developed. I know the read only form has a design spec from shixie that's been passed off to dev and is here in this PR:

https://github.com/carbon-design-system/carbon/issues/3018

Apparently Shixie's already signed off on it, but @emyarod is waiting on a dev response for some code tweaks that were requested.

There's also number input and date picker read only versions but they haven't been built yet!

stale[bot] commented 5 years ago

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

shixiedesign commented 5 years ago

not stale

stale[bot] commented 5 years ago

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

stale[bot] commented 5 years ago

As there's been no activity since this issue was marked as stale, we are auto-closing it.

JordanWSmith15 commented 5 years ago

@shixiedesign Is there any progress on this, or should we re-open it?

stale[bot] commented 5 years ago

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

laurenmrice commented 5 years ago

not stale

asudoh commented 5 years ago

Just for a reference to https://github.com/carbon-design-system/carbon/issues/3018#issuecomment-544746261 - Discussion on tooltip usage (read-only with overflow text) is blocking it from making progress.

One idea, as I stated there, is going without such "overflow text" spec. @laurenmrice @aagonzales Is it something we can do?

tomlroach commented 4 years ago

+1 to this issue.

We have all sorts of user permissions in our product now, and would like to be able to show those users with viewer permissions the values of various fields without having to use disabled styling (and thereby making them hard to read).

One option would be we just design a read only version of every page which uses text elements instead of input fields, but replacing input fields with read-only versions would be much less work and would allow us to have the read only and editable versions of the pages match up.

lukefirth commented 4 years ago

Maybe I'm missing part of the point here, but so far the requirements listed and the design exploration seems to be:

"We want an editable field where edit is disabled for some reason (eg permissions). We want to make it clear it can sometimes be editable, but that time is not now and communicate why it isn't. We don't want to use the disabled state for this because the visual styling is too heavy"

Which to me, sounds like the purpose of the disabled state, and sounds like we should be taking a look at the visual design of the disabled states if we are essentially exploring what seems to be a 'softer' alternative rather than another state for achieving/communicating almost the same thing (you can't edit this) slightly differently?

The reason this struck me, is that in some of the exploration our teams are doing is that many resources are by default in a 'read only' state, irrespective of the users ability to edit because they are just taking a look at something, I don't want to mess with it, just know what it is. - Eg my machine is running, here are the specs I have listed for it. They then would hit an edit button to turn that page/container/single field into an edit state, where the inputs all live.

I mocked a quick example:

Artboard

The 'date activated' is disabled in the first case (and I stole the no-edit icon/tooltip from here to see how that would work), because there is something stopping me from being able to edit it, even though its in an editable context. However, the whole right panel to me is 'read only' these things have been saved and are in a 'read only' state, unless you choose to enter/reenter an edit state.

Am I losing my mind or are these 2 different things?

emyarod commented 4 years ago

some differences between disabled and read only inputs include: the value of a disabled input will not be submitted in an HTML form, and disabled inputs will also be unfocusable and unnavigable via keyboard. read only inputs will send their values in a form and also be focusable and keyboard navigable (just not editable)

tomlroach commented 4 years ago

I suppose conceptually there doesn't have to be any visual difference between an editable input and a read only input. They could be the same but editing is unavailable in a read only version.

For example this URL field in Typeform is not disabled, I can click into it, select the text etc. But I cannot edit it - it simply does nothing if I try to interact.. That's potentially an approach.

Luke shows another where he converts input fields into a similarly sized/shaped text component, although it's limited to text inputs/dropdown, and I don't quite see how it would be applied to radio buttons, checkboxes or other forms of input.

I would summarise the request as:

A point of view on how to represent settings which are not currently editable because they are in a read only state, in an easily legible format - i.e. without using disabled fields - which are extremely hard to read due to their styling.

janhassel commented 4 years ago

Just stumbled across this when using readonly prop with NumberInput. From the examples I see in this issues and out in the wild (for example shared link on box) the visual design currently implemented does not seem to match the intention of this input. Rather, it looks almost identical to disabled state due to its low contrast and the disallow-cursor. Is the visual design still being worked?

readonly:

disabled:

sstrubberg commented 2 years ago

[ ] Final design specs from Devin
[ ] Pattern from them. Convert the pattern to markdown - Devin
[ ] Image work that needs to be done on the pattern - us

Adding it to the components

[ ] All the components.
[ ] Add a prop for read-only, styles for that prop,
[ ] Storybook controls for each state
[ ] Read-only story for copy and pastability
[ ] Tests for the read-only class on the prop
[ ] A new state for each of the form components.
[ ] Add docs for the website, usage and style tabs.
[ ] Add to the Figma kit
[ ] Add to Sketch(?) kit

Checkbox Date picker Dropdown Number input Radio button Slider Text area Text input Toggle

Read-only textinput has the work done. Use it as a reference. Make sure the visuals line up.

quarryboy commented 2 years ago

@sstrubberg here's the pattern info: https://ibm.ent.box.com/notes/948323199814 and i'm attaching the Sketch spec doc here as well. Mike Eacker and myself will be your point people for it.

Carbon - Read-only input components - HIFI v01.06.sketch.zip

lee-chase commented 2 years ago

NOTE: You might be looking for aria-readonly and aria-disabled which come with none of the functionality of the readonly and disabled attributes (semantic only).

NOTE 2: Microsoft would appear to consider disabled and readonly harmful https://medium.com/@izzmo/anti-pattern-using-disabled-or-read-only-for-form-input-e2c24c669f5b

quarryboy commented 2 years ago

@lee-chase - for note 2, the problem we would run into if we used the author's recommendations is that all disabled states for carbon would be invalidated based on legibility alone. this was the original reasoning for attempting a new read-only state. the good news is that after working alongside michael gower from the a11y team for several months on this, we are in a safe place in how we are going about designing the new read-only state. i'm guessing the way it is coded will definitely need to keep aspects of the article you mentioned in check however.

mbgower commented 2 years ago

@lee-chase

Microsoft would appear to consider disabled and readonly harmful

I don't think we should assume that someone writing a personal blog is speaking for MS. There are a few challengeable things said in the article (see its comments for examples) that support this skepticism.

There are some common use cases for read-only content (I'll leave @quarryboy to point to the research). An underlying challenge is: how do you convey visually that the content is not editable when there is no established convention for displaying a read-only state? The article suggests adding more textual context. That is certainly an approach, but there are obvious advantages to having the text reinforce visual cues.

There are also some common use cases for disabled content. An underlying challenge there is: how do you convey to users who cannot see disabled content (either well or entirely) the potential of further interaction that a sighted user can infer from seeing a disabled control? It's important to emphasize that disabling already non-interactive text (ie. stuff that is not part of an input or other control) neither makes sense, nor passes text contrast requirements (the exception is only for "part of an inactive user interface component").

That's not to say there are no dangers in creating non-navigable or non-editable inputs. I think the Carbon team has a pretty good handle on those as well. Like any newly introduced feature, prepare to iterate!

NOTE: You might be looking for aria-readonly and aria-disabled which come with none of the functionality of the readonly and disabled attributes (semantic only).

There is definitely some advantage to adding the aria attributes, such as where a screenreader may not get sufficient info from the construct about its read-only state. But putting aria-readonly on something and yet letting it be functionally editable obviously creates its own problems. Clearly, the functional state and aria semantic information need to align.

Hope that helps!

lee-chase commented 2 years ago

@lee-chase

Microsoft would appear to consider disabled and readonly harmful

I don't think we should assume that someone writing a personal blog is speaking for MS. There a few challengeable things said in the article (see its comments for a few) that support this skepticism.

There are some common use cases for read-only content (I'll leave @quarryboy to point to the research). An underlying challenge is: how do you convey visually that the content is not editable when there is no established convention for displaying a read-only state? The article suggests adding more textual context. That is certainly an approach, but there are obvious advantages to having the text reinforce visual cues.

There are also some common use cases for disabled content. An underlying challenge there is: how do you convey to users who cannot see disabled content (either well or entirely) the potential of further interaction that a sighted user can infer from seeing a disabled control? It's important to emphasize that disabling already non-interactive text (ie. stuff that is not part of an input or other control) neither makes sense, nor passes text contrast requirements (the exception is only for "part of an inactive user interface component").

That's not to say there are no dangers in creating non-navigable or non-editable inputs. I think the Carbon team has a pretty good handle on those as well. Like any newly introduced feature, prepare to iterate!

NOTE: You might be looking for aria-readonly and aria-disabled which come with none of the functionality of the readonly and disabled attributes (semantic only).

There is definitely some advantage to adding the aria attributes, such as where a screenreader may not get sufficient info from the construct about its read-only state. But putting aria-readonly on something and yet letting it be functionality editable obviously creates its own problems. Clearly, the functional state and aria semantic information need to align.

Hope that helps!

A fair point well explained @mbgower

lee-chase commented 2 years ago

@lee-chase - for note 2, the problem we would run into if we used the author's recommendations is that all disabled states for carbon would be invalidated based on legibility alone. this was the original reasoning for attempting a new read-only state. the good news is that after working alongside michael gower from the a11y team for several months on this, we are in a safe place in how we are going about designing the new read-only state. i'm guessing the way it is coded will definitely need to keep aspects of the article you mentioned in check however.

I do not have a Sketch license at the moment, so I cannot currently review the latest shared design. However, I have seen a PDF, which may be out of date, that shows an effect very similar to the "light" version of a number of form elements. While the "light" option does not appear in all form components here https://carbondesignsystem.com/components/search/usage/ and it is not functional in some places it does, it does appear as part of the implementation https://react.carbondesignsystem.com/?path=/story/components-textinput--playground&args=light:true appearing as a property on 16 components in @carbon/react v11.

quarryboy commented 2 years ago

@lee-chase very true. the new read-only designs do take that into consideration and also has supporting cursor states that give an additional hint to the user around what is and isn't mutable. one big difference between the light option and read-only is that the light option simply alters the background color to the next value step up (lighter or darker according to the theme - as it is not functionally intended to be seen on the same colored background as the form item), whereas the read-only component has no background color at all.

lee-chase commented 2 years ago

@lee-chase very true. the new read-only designs do take that into consideration and also has supporting cursor states that give an additional hint to the user around what is and isn't mutable. one big difference between the light option and read-only is that the light option simply alters the background color to the next value step up (lighter or darker according to the theme - as it is not functionally intended to be seen on the same colored background as the form item), whereas the read-only component has no background color at all.

I might be missing something, but from a visual point of view, I'm not sure I see a distinction between having no background and a background that matches the default background.

quarryboy commented 2 years ago

@lee-chase ah i see where the confusion is. this is a practical UX problem. the "light" background is not intended to match the default background. the intended use of the "light" setting is an alternate setting for when the form item is on a background that is not the default.

meaning: if the white theme is used, then a gray10 background will be applied to the component by default. however, there are times where the component is placed on a gray10 background (rather than white) and contrast is still required to differentiate the background color of the component from its surroundings. the alternate "light" version will instead have a white background to create the appropriate contrast.

does that make sense?

lee-chase commented 2 years ago

Makes sense @quarryboy, although I suspect as a result that 'light' will have been misused in places.

quarryboy commented 2 years ago

@lee-chase i feel like we could’ve put money on the line. 😉 It’s almost a guarantee that bit has been misused!

carbon-design-system / carbon