Contribution: Add yellow warning state to Select

[beareye]

Explanation: As a Front end developer, I would like to warn users sometimes on the Select component. The red warning bar exists, but unfortunately, using it may sometimes be the wrong choice because the red color implies an error. Therefore, I believe that Carbon should include a yellow warning bar as an alternative option to the the red error bar if the selected value is invalid.

Research: The DUX (developer user experience) squad at IBM needs to inform an IBM Cloud user on the free plan when they have exceeded the alloted number of Lite plan services used. Consider a user who is creating the "Watson Assistant With Discovery - Serverless" starter kit. The starter kit generates 2 IBM Cloud services, "Discovery" and "Watson Assistant". Unfortunately, the user is already using the "Watson Assistant" service on a different project so the user cannot generate this starter kit.

When the user changes "Lite" to "Standard" under Watson Assistant, the warning above it disappears because now no violations occur.

This is the current way we broadcast the warning to the user.

Our problem right now is that the warning notification is displayed twice rather unnecessarily. Therefore our solution is to contribute to carbon and add a new option for warning purposes.

Our proposed solution will look the following:

To see more of our discussion: see https://github.ibm.com/arf/planning-devux/issues/2751

Developer: Jeffrey Wang (jeffreyw@ibm.com)

[stale[bot]]

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.

[keithkade]

bump

[stale[bot]]

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.

[keithkade]

bump

[stale[bot]]

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.

[keithkade]

bump

[asudoh]

CC @carbon-design-system/design - In browser world, form controls have only binary choices for valid or invalid. So I guess the team needs an alternate way wrt how to tell user that a specific choice in select may not be a good choice.

[stale[bot]]

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.

[keithkade]

bump

[aagonzales]

Hello, sorry for the extremely delayed response. This is not a feature we want to add into Carbon at the moment. We think 'warning' is too vague for form validation. It should either be a clear error or a success. If the user cannot move forward and submit the data with this configuration then it should be an error and the error inline message containing the same information.

The yellow warning text would also fail accessibility contrast.

[janhassel]

I'd like to open up this discussion again since we're running into the same issue (and seem to not be alone). Sometimes, form inputs are technically ok and the user is able to proceed but we need to inform the user about potential side effects their action might bring in.

Surely we can use a warning inline notification to the page but when there are a few inputs, the user should be immediately be able to tell which input field needs attention, so we need to mark that input field.

Our problem is that if Carbon doesn't support this (and won't in the future), we need to make custom overrides to enable that behaviour on our side. That carries two big issues:

1. Every override can break the interface when updating even just to another path version
2. With this particular behaviour, overrides are not really feasible due to the inconsistencies of where we can inject styling (see carbon-design-system/carbon#5853).

Regarding the accessibility problem of the text: I believe the warning message for an input field could just use $text-01.

[mjabbink]

@janhassel I agree with @aagonzales if a user is allowed to proceed but there can be ramifications to it later then you might want to not let them proceed

The design solution above can not work as yellow type is not legible. I recommend redesigning the solution and proposing back to Carbon. We’ll investigate and see if there is another solution we can come up with as well. @aagonzales can think this over. If we still land on same conclusion that is ok too but let’s consider above statement.

[janhassel]

@mjabbink Thanks for the response.

Let's take a specific example use case. The user uploads some file in a process and can choose a filename under which it should be stored in his service. If the filename is already taken the user can proceed but the system will add a suffix to the chosen name. Now we have the following situation: the user did not make any mistake and it is safe to proceed, but we need to inform the user about the action the system will take so that the user can either change the filename to something unique or they accept that a suffix will be added and continue.

Visual design wise, I would've thought about something like this (displayed in g10 theme):

Basically what we struggle with is that the user technically has a correct setup and there is nothing particularly wrong that should prevent the user from proceeding but we need to tell the user if the system will take any extra actions (like adding a suffix to a name) or if we want to make sure the user didn't make a mistake by accident (when we detect that an input is highly uncommon).

[mjabbink]

@janhassel this is helpful. @aagonzales and @jeanservaas get back to you.

[chrisconnors-ibm]

Does that event - name adjusted to avoid namespace collision warrant that level of alarm? Also why wouldn't the system just display the name it was going to use (with the suffix) and the explanation text?

[janhassel]

@chrisconnors-ibm The use case described above is an example. I agree, it ~could~ should show the actual new name instead of just saying there will be a suffix.

Another use case that might help illustrate the problem is when the software notices that the user behaviour is very uncommon and it wants to make sure that it is actually the user's intention and not an accidental mistake.

For example, let's say the user is working on an AI model and the system detects that their input might lead to overfitting. The user definitely shouldn't be blocked to proceed with their actions, but the system should be able to warn them that what they will get as a result might not be what they want.

Another example might be a shipping/billing address. When the user enters an address that the system can't find in the USPS database, a warning could suggest them a similar address from the database just to make sure the user didn't accidentally include a typo. Obviously, a database could be incomplete though and you wouldn't want to block the user's process.

I could also think of a digital tax system that warns the user when a certain claimed amount seems to be too high in context to the other submitted data. Maybe the number is right and the user falls into an edge-case category but maybe they also just used the wrong decimal character (like a comma instead of a period because they're used to other systems).

[aagonzales]

I'm confused why you wouldn't just use an inline notification for these scenarios. I feel like putting the warning on the field itself makes it feel like there's something wrong with it but actually it might not be wrong the system just thinks it's wrong.

I think maybe if it wasn't so loud it would be ok, so it felt more like a "hey double check this" vs "there's something wrong with this!" Without the outline it will still read as valid but with caution.

I think a lot of people could misuse this which is why I hesitate to add it to main Carbon.

[mjabbink]

it’s nicer without the full yellow outline. I think that is a good solution @aagonzales

[janhassel]

@aagonzales I like it without the outline. You're right, otherwise it seems pretty "loud".

Regarding the inline notification: That may work in some cases but can become very frustrating for the user when they don't see it right away. If you think of the last example (digital tax claiming), you're often filling out very long forms and it would be a hassle for the user to find the input field causing the warning on a whole page whereas when the input field is highlighted (even slightly like in the design you posted), they can find and verify their input much faster.

[aagonzales]

Side note: I always forget Carbon actually uses the red warning icon and not the error icon for invalid with form inputs.

So this new warning would need to use the triangle symbol to different itself more which is unfortunate because the circle one does look better/

[janhassel]

I think that works. Alternatively the red warning icon could be swapped with the error icon maybe? Although that might seem a bit too "aggressive".

[tw15egan]

Ref https://github.com/carbon-design-system/carbon/pull/5918