-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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 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. |
the short answer is: No. its not to difficult. |
Im totaly fine with changing the roundness to 4;4;0;0 it looks better. But it’s not a problem as is for the user.
My main “issue” with that change is that our “rule” that everything should have a 4px rounding everywhere is bypassed.
With that said am I totally fine with bypassing that rule.
…Sent from my iPhone
On 15 Jan 2019, at 12:47, JessiNygrenWalhed <notifications@github.com<mailto:notifications@github.com>> wrote:
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).
[4px]<https://user-images.githubusercontent.com/45595414/51178693-b5d78300-18c3-11e9-895e-934c4199e460.png>
[2px]<https://user-images.githubusercontent.com/45595414/51178696-b839dd00-18c3-11e9-8d7a-036cee675e7d.png>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#13 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AscDj1EzNwJJz_-eJ-hzTMOLwH9XlVXBks5vDb_ZgaJpZM4Z-a7A>.
|
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... |
I agree with robert that the radios will look wierd when flickering between error and normal states.
My only strong opinion in this about the 2px
🚁
…Sent from my iPhone
On 15 Jan 2019, at 17:55, Robert Hjalmers <notifications@github.com<mailto:notifications@github.com>> wrote:
Just want to refer to this old comment #2 (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<https://github.com/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<https://github.com/JessiNygrenWalhed> and @henrikhoglundseb<https://github.com/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...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#13 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AscDjzXb29IIoPvpwunTMFRd39DtzKdeks5vDggWgaJpZM4Z-a7A>.
|
Ok, i rest my case on the radius 👈🏽 |
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. |
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.com<mailto: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 thread<https://github.com/notifications/unsubscribe-auth/AscDj9NGOiQFFEGbohl5g5Lt18Tovbobks5vEFhHgaJpZM4Z-a7A>.
|
Did you see the link? Thats a context. Right? 😍 |
@henrikhoglundseb Do you have any example with a lot of fields indicating error at the same time? |
@splashdust I agree! When tabing we should have a more clear focus! |
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":) |
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! |
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:) |
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: What do you guys think @JessiNygrenWalhed and @henrikhoglundseb, I remember that we talked about this ages ago too @conandx? |
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! |
Icons are disabled now by default in the new version that I released yesterday although they can be turned on by adding 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). |
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
We try this for now and evaluate. Please give us feedback so we can learn in time for the next update. /Ulrika, |
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:
/Ulrika
The text was updated successfully, but these errors were encountered: