After reviewing the Field component yesterday during our Engineering/Design sync and presenting the proposals today with the designers where I collected important feedback, we've decided the following for the MVP task:

Required/Optional:

• Asterisk can not be used to indicate the required label since its not enough translatable to other languages. If we decide to indicate the required one, it should be indicated with the whole word (not with asterisk). Also, asterisk shouldn’t be indicated within the field since it’s not applicable to Selects or Comboboxes.
• Since all form fields are required by default, we could indicate just the optional ones in order to avoid too many asterisks across the form page.
• @KieranMcCann will finish to define this in T330419

Tooltip:

It will be added next to the label (also when label text wraps into more than one line) so the tooltip is always connected with the label.

Helper text Vs. Inline message:

For this MVP task, we will implement the same as we have in production to avoid possible problems. So inline message will appear bellow the helper text and both texts will be visible in the Field in some cases.
Since both helper and inline message will be visible at the same time, what if we redesign the Inline Message from Bold to Regular and we use a 16px icon instead (Op.2 B)? cc: @KieranMcCann

Characters counter:

It will not be implemented as part of this MVP task and we will implement it in this separate task T331000.

Label + Description:

The description will be implemented as part of the MVP and we will provide guidelines to indicate when the designers should use the description text and when should they use other field elements such as helper text or a tooltip.

Field action:

Inline or stacked action could be displayed as part of the Field component. So we will implement them as properties.

Stacked fields vs. FieldSet:

We will implement both the Field component (in this task) and the FieldSet (a combination of different Field components, this one will be implemented in another task).

Thanks @bmartinezcalvo. Following on from my comments in the Figma file I can confirm all looks good to me now.

In T309239#8725059, @KieranMcCann wrote:

Thanks @bmartinezcalvo. Following on from my comments in the Figma file I can confirm all looks good to me now.

@KieranMcCann great thanks. @RHo for visibility in case you want to do a last check before moving the task to Ready for development.

In T309239#8728125, @bmartinezcalvo wrote:

In T309239#8725059, @KieranMcCann wrote:

Thanks @bmartinezcalvo. Following on from my comments in the Figma file I can confirm all looks good to me now.

@KieranMcCann great thanks. @RHo for visibility in case you want to do a last check before moving the task to Ready for development.

Thanks, LGTM too

Change 893011 abandoned by Anne Tomasevich:

[design/codex@main] [proof of concept] Demo Field functionality within input components

Reason:

https://gerrit.wikimedia.org/r/893011

Change 893010 abandoned by Anne Tomasevich:

[design/codex@main] [proof of concept] Demonstrate experimental Field component

Reason:

https://gerrit.wikimedia.org/r/893010

Change 923428 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [wip do not merge] Field and Label

https://gerrit.wikimedia.org/r/923428

Change 927265 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Field: Add Field component and enable use with input components

https://gerrit.wikimedia.org/r/927265

Change 927266 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Field et al: Add demos for supported components

https://gerrit.wikimedia.org/r/927266

@AnneT I'm checking the Field last patch and it seems there is an error to fix with the error state. The helper text should also reflect the error state so it should be content-error color. There was an error in the spec so I've updated it. Could we also update it in the demo? These are the styles we should use in the error. Thank you!

Change 923428 abandoned by Anne Tomasevich:

[design/codex@main] [wip do not merge] Field and Label

Reason:

Real patches have been opened

https://gerrit.wikimedia.org/r/923428

@bmartinezcalvo Thanks for checking out the demos! You can also see a real-world demo for each component on the demo site for the last patch - e.g. Checkbox.

We're still allowing people to add both helper text and a validation message, right? If so, I would recommend we not change the helper text to red when there is an error. If the helper text turns red when there's an error, that would mean that the helper text must be related to the error, and I think there are many other things people might want to include in the helper text besides information on exactly how to fill out the field to avoid an error. Is the red error validation message enough here?

In T309239#8906332, @bmartinezcalvo wrote:

@AnneT I'm checking the Field last patch and it seems there is an error to fix with the error state. The helper text should also reflect the error state so it should be content-error color. There was an error in the spec so I've updated it. Could we also update it in the demo? These are the styles we should use in the error. Thank you!

In T309239#8907936, @AnneT wrote:

@bmartinezcalvo Thanks for checking out the demos! You can also see a real-world demo for each component on the demo site for the last patch - e.g. Checkbox.

We're still allowing people to add both helper text and a validation message, right? If so, I would recommend we not change the helper text to red when there is an error. If the helper text turns red when there's an error, that would mean that the helper text must be related to the error, and I think there are many other things people might want to include in the helper text besides information on exactly how to fill out the field to avoid an error. Is the red error validation message enough here?

Hi @bmartinezcalvo - my understanding is the same as @AnneT in that that validation/error text would be separated out from Helper text, as captured in T330419

In T309239#8907936, @AnneT wrote:

@bmartinezcalvo Thanks for checking out the demos! You can also see a real-world demo for each component on the demo site for the last patch - e.g. Checkbox.

We're still allowing people to add both helper text and a validation message, right? If so, I would recommend we not change the helper text to red when there is an error. If the helper text turns red when there's an error, that would mean that the helper text must be related to the error, and I think there are many other things people might want to include in the helper text besides information on exactly how to fill out the field to avoid an error. Is the red error validation message enough here?

@AnneT oh yes, I forgot about the validation message when the error. So in this case, if the helper text will be the same when error, we should display the error validation message always we have an error state. This should be the error validation behavior:

Change 927265 merged by jenkins-bot:

[design/codex@main] Field: Add WIP Field component and enable use with input components

https://gerrit.wikimedia.org/r/927265

Status update: The WIP component has been merged and can be viewed here.

It will need design review before it can come out of WIP. I've opened tasks for things that I believe do not need to block taking this component out of WIP. We can determine priority for each task and tackle any of them now, if we think they are critical for an MVP release of Field. See the "future work" section at the bottom of the task description.

cc @CCiufo-WMF @bmartinezcalvo

@AnneT design sign-off done and adding small things to review:

1. Helper text should be 16/22 so it means the line height should be @line-height-small.
2. When error, an error inline validation message should appear below the helper text. I think this should appear always since the user needs the reason and instructions to fix the error. So I would include it as default in the configurable demo too.
3. Complex field with two inputs: the toggle switch is too closed to the fields, could we add more padding? Maybe 40px or 48px.
4. Error validation message should disappear when focus, since error state disappears when focus.
5. The keyboard navigation for the links within the helper text and descriptions seems not work. When clicking enter or space, it should navigate to the link.

@AnneT since we are adding the FieldSet with nested fields in the same Field component's demo, I should add it in Figma too. How many Fields could we add in a FieldSet row? The same for the Complex field with two inputs, could this complex fields be more than 2 inputs?

Change 929412 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Field: Set help text line height and improve demos

https://gerrit.wikimedia.org/r/929412

Thanks for the feedback, @bmartinezcalvo!

In T309239#8924203, @bmartinezcalvo wrote:

1. Helper text should be 16/22 so it means the line height should be @line-height-small.

Done!

2. When error, an error inline validation message should appear below the helper text. I think this should appear always since the user needs the reason and instructions to fix the error. So I would include it as default in the configurable demo too.

Good call; I added an error message to the configurable demo which will display when you select the "error" status. We still don't support object-type props in the configurable demos, which means we can't include the messages prop since this is an object. However, I added a note above the configurable demo pointing to the demo with a validation message and status, which will show people exactly how to add an error message.

3. Complex field with two inputs: the toggle switch is too closed to the fields, could we add more padding? Maybe 40px or 48px.

I changed this to 40px, let me know what you think (demo here)!

4. Error validation message should disappear when focus, since error state disappears when focus.

I worry that this would result in 2 issues:

1. People might want to read the error message text as they're updating the field to fix the error
2. The error message would disappear and reappear if the user clicked in and out of the input

With the status and error message, we are requiring developer users to determine what the status is at all times and when to show a message. So, a user could set this up so that the status resets to "default" when the input is focused. But I think this will need to be handled differently across use cases, so I would recommend we keep things the way they are and just allow designer and developer users to choose when to show the error message.

5. The keyboard navigation for the links within the helper text and descriptions seems not work. When clicking enter or space, it should navigate to the link.

This was because they weren't real links, just a link to the current page - I thought this would be better because I'm guessing users won't want to be navigated away to a new page, but it really just makes the demos less realistic. I've changed them to be real link so that they work as expected.

In Chrome and Firefox at least, these links can now be visited with the Enter key, but not space - these browsers always do a page down on space, not activating a link.

@AnneT since we are adding the FieldSet with nested fields in the same Field component's demo, I should add it in Figma too. How many Fields could we add in a FieldSet row? The same for the Complex field with two inputs, could this complex fields be more than 2 inputs?

Technically, people can add as many inputs as they want in a fieldset, and the layout is up to them. We have not implemented any kind of fieldset layout styles in the Field component - all the layout styles you're seeing in those two demos are written specifically for those demos.

Maybe a good future task would be to support a set of layouts, e.g. 2 adjacent inputs with no space between then, 2 columns (like for an address field), etc.? Until then, perhaps we should just add some examples of acceptable layouts in Figma and provide guidelines for how to style fieldsets?

Change 929412 merged by jenkins-bot:

[design/codex@main] Field: Set help text line height and improve demos

https://gerrit.wikimedia.org/r/929412

In T309239#8924935, @AnneT wrote:

Thanks for the feedback, @bmartinezcalvo!

In T309239#8924203, @bmartinezcalvo wrote:

1. Helper text should be 16/22 so it means the line height should be @line-height-small.

Done!

@AnneT it still appears with 16/25.6. It should be 16/22 instead.

2. When error, an error inline validation message should appear below the helper text. I think this should appear always since the user needs the reason and instructions to fix the error. So I would include it as default in the configurable demo too.

Good call; I added an error message to the configurable demo which will display when you select the "error" status. We still don't support object-type props in the configurable demos, which means we can't include the messages prop since this is an object. However, I added a note above the configurable demo pointing to the demo with a validation message and status, which will show people exactly how to add an error message.

Great, thank you!

3. Complex field with two inputs: the toggle switch is too closed to the fields, could we add more padding? Maybe 40px or 48px.

I changed this to 40px, let me know what you think (demo here)!

It looks perfect now.

4. Error validation message should disappear when focus, since error state disappears when focus.

I worry that this would result in 2 issues:

1. People might want to read the error message text as they're updating the field to fix the error
2. The error message would disappear and reappear if the user clicked in and out of the input

With the status and error message, we are requiring developer users to determine what the status is at all times and when to show a message. So, a user could set this up so that the status resets to "default" when the input is focused. But I think this will need to be handled differently across use cases, so I would recommend we keep things the way they are and just allow designer and developer users to choose when to show the error message.

Ok, so I've also included the error inline message in the focus state in the Figma spec.

5. The keyboard navigation for the links within the helper text and descriptions seems not work. When clicking enter or space, it should navigate to the link.

This was because they weren't real links, just a link to the current page - I thought this would be better because I'm guessing users won't want to be navigated away to a new page, but it really just makes the demos less realistic. I've changed them to be real link so that they work as expected.

In Chrome and Firefox at least, these links can now be visited with the Enter key, but not space - these browsers always do a page down on space, not activating a link.

So this means the space just activates the links in Safari browser?

@AnneT since we are adding the FieldSet with nested fields in the same Field component's demo, I should add it in Figma too. How many Fields could we add in a FieldSet row? The same for the Complex field with two inputs, could this complex fields be more than 2 inputs?

Technically, people can add as many inputs as they want in a fieldset, and the layout is up to them. We have not implemented any kind of fieldset layout styles in the Field component - all the layout styles you're seeing in those two demos are written specifically for those demos.

Maybe a good future task would be to support a set of layouts, e.g. 2 adjacent inputs with no space between then, 2 columns (like for an address field), etc.? Until then, perhaps we should just add some examples of acceptable layouts in Figma and provide guidelines for how to style fieldsets?

Ok, I will create a task for these FieldSet layouts and I will add some examples in Figma as we have in the Codex demo.

In T309239#8923236, @AnneT wrote:

Status update: The WIP component has been merged and can be viewed here.

It will need design review before it can come out of WIP. I've opened tasks for things that I believe do not need to block taking this component out of WIP. We can determine priority for each task and tackle any of them now, if we think they are critical for an MVP release of Field. See the "future work" section at the bottom of the task description.

cc @CCiufo-WMF @bmartinezcalvo

@AnneT I wonder if we should create another task to include the loading state once Skeleton T311874 is implemented.

Change 929722 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Field, Label: Set smaller line height

https://gerrit.wikimedia.org/r/929722

So this means the space just activates the links in Safari browser?

I think it depends on your personal settings for Safari? The space key doesn't click links in my local version.

@AnneT I wonder if we should create another task to include the loading state once Skeleton T311874 is implemented.

Creating a task for this sounds good to me!

@AnneT I'm checking the last patch and the text line height is the right one now @line-height-xx-small. All looks good now so moving this task to Pending Release.

I will create a new task for the Loading state and I'm removing the space from the keyboard navigation table in the Figma spec to avoid confusions.

Regarding Fieldset, I've added some examples of Fieldset in the Figma spec. And, since we already have some examples of Fieldset in the current Field demo, I guess we will not need to create a new task for it.

Change 929722 merged by jenkins-bot:

[design/codex@main] Field, Label: Set smaller line height

https://gerrit.wikimedia.org/r/929722

Change 929794 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Field, Label: Move from WIP components to lib

https://gerrit.wikimedia.org/r/929794

Change 929794 merged by jenkins-bot:

[design/codex@main] Field, Label: Move from WIP components to lib

https://gerrit.wikimedia.org/r/929794

Change 927266 merged by jenkins-bot:

[design/codex@main] Field et al: Add demos for supported components

https://gerrit.wikimedia.org/r/927266

Change 931666 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/core@master] Update Codex from v0.12.0 to v0.13.0

https://gerrit.wikimedia.org/r/931666

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/2c8b23bc31/w

Change 931666 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.12.0 to v0.13.0

https://gerrit.wikimedia.org/r/931666

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/2c8b23bc31/w/