Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input field error indicator #13

Closed
4 tasks done
ulde01 opened this issue Jan 14, 2019 · 24 comments
Closed
4 tasks done

Input field error indicator #13

ulde01 opened this issue Jan 14, 2019 · 24 comments
Labels
developing Component is being developed reviewed/answered DMT reviewed or answered

Comments

@ulde01
Copy link
Contributor

ulde01 commented Jan 14, 2019

The discussion about label text sizes (#2) is finished but many of you also wanted to discuss what the error indicator on an input field looks like. So please, have a look at #2 for reference but these are the questions I pick up:

  • Should the red/green line at the bottom be 2px or 4 px high?
  • How is the line attached to the input field? Straight, rounded, etc.

/Ulrika

@ulde01 ulde01 mentioned this issue Jan 14, 2019
4 tasks
@ulde01 ulde01 added the discussion Open for discussion label Jan 14, 2019
@axelgarciahenriksson
Copy link

Since @henrichoglundseb with user testing found out that 2px line is the best option, I would go with that.

However, I understood that this was when there was lot of fields, with many errors. Do we have any user test data with one/two fields with one error, and many fields with one error? (I would guess that the 4px line would only be needed in the last case?)

@henrikhoglundseb
Copy link

Since @henrichoglundseb with user testing found out that 2px line is the best option, I would go with that.

However, I understood that this was when there was lot of fields, with many errors. Do we have any user test data with one/two fields with one error, and many fields with one error? (I would guess that the 4px line would only be needed in the last case?)

It looks very intimidating and like an error with just a few fields aswell. But ofc not as much as when you have 6 fields.

Simplicity is best and not to mix 2 or 4px border on errorstates depending on how many fields there is.
I say lets go with 2 px for all fields.

@axelgarciahenriksson
Copy link

I agree we shouldn't mix 2 and 4px, that would be too cumbersome. I was merely wondering if there were any user testing results from only one error amongst many fields. If 2 px in that case would be too difficult for users to find, or if it works as well.

@henrikhoglundseb
Copy link

the short answer is: No. its not to difficult.

@ghost
Copy link

ghost commented Jan 15, 2019

I agree that the 2px line looks better. But not together with the 4 ratio on the input.
If we are making this change from 4 to 2px, I would really like to see that the bottom ratio on inputs are changed from 4 to 0 px. (4;4;0;0).
2vs4

@henrikhoglundseb
Copy link

henrikhoglundseb commented Jan 15, 2019 via email

@hjalmers
Copy link
Contributor

Just want to refer to this old comment #2 (comment). The only place where this has been implemented so far (that I know of) is in the bootstrap theme were we (Panos and I) started with 4 pixels an later changed it to 3 pixels when we saw it live on the new login page: https://id.seb.se/ccs/mbid (updated with new label size).

I agree with @JessiNygrenWalhed that the border radius looks a bit silly when the line is 2 pixels thick, but there's nothing preventing it from being 3 pixels right? I think 3 pixels is "lagom" not too thick and not too thin to create the weird border radius look. I don't mind removing the border radius altogether either like the initial design by kurppa and then 2 pixel thickness looks great but changing it to 4, 4, 0, 0 (border radius on the upper corners) looks a bit weird in my opinion. But perhaps you're just suggesting that the border radius is 0 when the field has been validated @JessiNygrenWalhed and @henrikhoglundseb? If that's the case wouldn't it look strange to flip from border radius to no border radius just because the field has been validated? It feels a bit inconsistent at least...

@henrikhoglundseb
Copy link

henrikhoglundseb commented Jan 16, 2019 via email

@ghost
Copy link

ghost commented Jan 16, 2019

Ok, i rest my case on the radius 👈🏽
The 4 px is too much, we all agree on that. 😄
Just a thought, part of next discussion, if we change it to 2 px and then changes the height of the inputs to 44. The 2 px suddenly seems to small. See attached image. @henrikhoglundseb How about holding on to the 3 px? Like Panos and @hjalmers agreed on?
screenshot 2019-01-16 at 09 30 36

@ghost
Copy link

ghost commented Jan 17, 2019

screenshot 2019-01-17 at 11 44 46

This is how it looks like here https://id.seb.se/ccs/mbid when added 4 px on the input, with 3 px erorline indicator. The red frame helps the user as well.

@henrikhoglundseb
Copy link

henrikhoglundseb commented Jan 17, 2019 via email

@ghost
Copy link

ghost commented Jan 17, 2019

Screenshots are great and all. But it’s very hard, when discussing details, without any context. Can the people in this thread 🧵 have a 15 min meeting and take a a 👀 in a actual developed project ?

Sent from my iPhone On 17 Jan 2019, at 12:02, JessiNygrenWalhed <notifications@github.commailto:notifications@github.com> wrote: [screenshot 2019-01-17 at 11 44 46]https://user-images.githubusercontent.com/45595414/51313439-d5021c00-1a4d-11e9-86d9-44276d5b41fd.png This is how it looks like here https://id.seb.se/ccs/mbid when added 4 px on the input, with 3 px erorline indicator. The red frame helps the user as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#13 (comment)>, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AscDj9NGOiQFFEGbohl5g5Lt18Tovbobks5vEFhHgaJpZM4Z-a7A.

Did you see the link? Thats a context. Right? 😍

@ulde01 ulde01 added this to Backlog in Design discussions Jan 17, 2019
@ulde01 ulde01 moved this from Backlog to Discussion in Design discussions Jan 17, 2019
@ghost
Copy link

ghost commented Jan 21, 2019

@henrikhoglundseb Do you have any example with a lot of fields indicating error at the same time?

@ghost
Copy link

ghost commented Jan 30, 2019

We have discussed this today in Design Working Group and decided to go with the 2 px line and the 1 px frame in red. (No shadow as in bootsrap).

Error line 2 px #D81A1A
Input field (44 px) frame 1 px #D81A1A

To try out and evaluate the outcome in a while. Discussion closed. 👋🏼
screenshot 2019-01-30 at 14 52 14

@ulde01 ulde01 added reviewed/answered DMT reviewed or answered designing labels Jan 30, 2019
@splashdust
Copy link
Contributor

Just a nugget of input regarding the focus outline: (late to the party, I know)
In PWS we added a focus outline to buttons, because otherwise it was too difficult to follow where the focus was on the page. We only use it on buttons, but I don't think it would hurt to have it on input fields as well.

Have a look at these gifs for comparision with/without: (i'm tabbing back and forth between two buttons)

No focus outline: (default behaviour in Design Library)
nooutline

With outline:
withoutline

The focused state is a little bit too suttle without the outline.

@ghost
Copy link

ghost commented Jan 31, 2019

@splashdust I agree! When tabing we should have a more clear focus!

@hjalmers
Copy link
Contributor

hjalmers commented Feb 3, 2019

We have discussed this today in Design Working Group and decided to go with the 2 px line and the 1 px frame in red. (No shadow as in bootsrap).

Error line 2 px #D81A1A
Input field (44 px) frame 1 px #D81A1A

To try out and evaluate the outcome in a while. Discussion closed. 👋🏼
screenshot 2019-01-30 at 14 52 14

Yeah, also a bit late to the party but I'm agreeing with @splashdust, we still need to indicate when the input has focus, that's where the outline/shadow comes into play. The bootstrap theme only adds the outline when the field has focus, without focus it's just like you suggested @JessiNygrenWalhed:)

If a form contains multiple input fields with errors however, there's no way for the user to know which input field has focus. The new login app for example will set to focus to the first input filed with an error just to simplify for the end user and minimise the amount of clicks required to fix an error, this might make it look they always have the "shadow":)

@ghost
Copy link

ghost commented Feb 4, 2019

For sure! We need to indicate when input has focus! Thought that was something to do more with availability and that it is a code-thing, and maybe depends on browser and so on. So nothing we explain in the design guidelines. But I might be wrong?! Have not seen any such descriptions on the components.

And, we will leave the red frame for now, on just the error. It will have the same as it has now. But I agree on the focus, thats how it should look!

@hjalmers
Copy link
Contributor

hjalmers commented Feb 4, 2019

Focus is a state on input fields (and other elements too with tab-key), most browser add an outline, often dotted or glowing border around elements that have focus by default but this can and be overridden. Like @splashdust mentioned we're not addressing this in Design Library at the moment, so perhaps we should create a separate ticket for it. The bootstrap theme uses the default behaviour defined by bootstrap except for the colors, were we use SEB:s colors instead. You can take a look at this page for an example and use the tab key to focus different elements:)

@hjalmers
Copy link
Contributor

hjalmers commented Feb 4, 2019

I'm going through the bootstrap theme now and implemented some new features introduced in the latest version of bootstrap core lib, one being the ability to display validation icons when the form has been validated. This feature can be toggled on or off, here's how it looks with our icons if we would turn it on:

image

What do you guys think @JessiNygrenWalhed and @henrikhoglundseb, I remember that we talked about this ages ago too @conandx?

@ghost
Copy link

ghost commented Feb 6, 2019

For now, we will not use the icons. We need to explore it some more. Me, @henrikhoglundseb, @conandx & @ulde01 talked about it. And, we agree that since the input field sometimes already contains an icon, the dropdown always has its arrow. It gets a bit crowded... Do we really need three ways to show the user something is wrong? We have the 2 px line and the error information text.

For things that is alright and green, we agreed on not using the information text under the input field.

For the highlight we agree on doing it like Bootstrap!

@hjalmers
Copy link
Contributor

hjalmers commented Feb 6, 2019

Icons are disabled now by default in the new version that I released yesterday although they can be turned on by adding $enable-validation-icons: true; before importing bootstrap sass file in a project (a bit technical but just as a note if someone happen to wonder how to show them).

For people with colour blindness icons are a nice addition I think and you can never be too clear in my opinion, but I agree that it might look a bit cluttered in input groups (inputs combined together with other inputs, icons or buttons).

@ulde01 ulde01 removed the reviewed/answered DMT reviewed or answered label Feb 6, 2019
@ulde01
Copy link
Contributor Author

ulde01 commented Feb 11, 2019

Here is a summary of the change in this thread, which I will also add to different repos, change log and Design Library.

Status update
This change was reviewed in Design Working Group (2019-01-30):

  • The error indicator for input fields have a 2 px line (#D81A1A) at the bottom
  • No frame or shadow (as in Bootstrap)
  • No icon in the text field

We try this for now and evaluate. Please give us feedback so we can learn in time for the next update.

/Ulrika,
Design Management

@ulde01 ulde01 added reviewed/answered DMT reviewed or answered developing Component is being developed and removed designing discussion Open for discussion labels Feb 11, 2019
@ulde01
Copy link
Contributor Author

ulde01 commented Feb 11, 2019

image

@ulde01 ulde01 moved this from Discussion (active) to Under development in Design discussions Feb 11, 2019
@ulde01 ulde01 moved this from Under development to Done in Design discussions Aug 27, 2019
@ulde01 ulde01 moved this from Done to React! in Design discussions Aug 27, 2019
@ulde01 ulde01 closed this as completed Mar 9, 2020
@ulde01 ulde01 moved this from React! to Done in Design discussions Mar 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developing Component is being developed reviewed/answered DMT reviewed or answered
Projects
None yet
Development

No branches or pull requests

5 participants