Skip to content
This repository has been archived by the owner on Aug 12, 2021. It is now read-only.

Form input visuals #737

Closed
joseegm opened this issue Jun 19, 2017 · 18 comments
Closed

Form input visuals #737

joseegm opened this issue Jun 19, 2017 · 18 comments

Comments

@joseegm
Copy link
Contributor

joseegm commented Jun 19, 2017

Goals

  1. Create visual styles for all form input fields listed on Form Input inventory #733
  2. Create visual styles for all status from Define form input status #736
  3. Create visual styles for all help elements Define form input Help elements #738

Current pain points to address:

  1. Label font is very small in relation to the input line.
  2. Colors of the labels are not contrasting enough.
  3. Input lines looks too big in relation to the labels.
  4. Faux 3d emboss effect on the input lines - not needed.

Prior art as v1.5.x

screen shot 2017-06-19 at 11 34 32

@joseegm
Copy link
Contributor Author

joseegm commented Jun 19, 2017

Complete UX Design Spect at: https://github.com/SAP/techne/wiki/Form-Inputs
The above is a compilation of #733, #735 and #736

@LeoT7508
It is all yours!

On the specs there are defined, the different types of form inputs and also the common elements with their usage.

@joseegm
Copy link
Contributor Author

joseegm commented Jun 22, 2017

@LeoT7508
You haven't post the visuals you show yesterday. So I cannot take a detailed look at it.

We can agree to post any progress as it is available. That will speed up things and make the improvements based on the feedback visible.

From what I saw yesterday:

Labels

  1. They are still small compared with the font inside the input. Ideally they will have the same font-size with the font inside the input having slightly more visual weight than the label.
  2. Color is not contrasting enough

Inputs

  1. The current border looks very rigid we can "soft" it a bit if we try rounding the corners. Like
    form input elements
  2. The extra elements: actions, sping box have their own border. Let's try having a contrasting background and using spacing to separate it from the input.

@LeoT7508
Copy link

@joseegm

I have not posted the visuals as those are not ready yet. I have to make them pixel perfect, and they aren't at that point yet.

To your other questions:

Labels:

  1. In general the labels and the text in the fields should not carry the same weight or size, there needs to be a contrast in size and weight to show hierarchy and priority. That being said labels aren't the primary action in forms, its the information the user puts in the field. With all that taken into consideration the labels will be 13px bold. And the text inside the box will be our normal body copy, 16px regular.

The colors I'm using pass accessibility standards, so we should be good there.

Inputs

  1. Im going to stay away from rounding corners on fields to keep things consistent with other elements we will need to add later, like buttons, tool and action bars. Buttons that live in the tool bar are squared. Id rather not have variations in style per component. Keeping them square will allow us more flexibility.

  2. The extra elements like actions, and spring box will not have their own border, this hints at a button or action that needs to be clicked, when in reality they aren't. Visually I would like to keep the info in the fields without separation. We will create the space you are asking for using color with icons or a solid background for buttons when needed. This all will reduce confusion and makes it very clear whats happening.

Im close to being done with these visual tasks. Its taking more time because I have to start accounting for buttons and icons, so I'm designing these 3 at the same time. I have to make sure everything is pixel perfect or it will come back to bite us later on.

Thanks for the patience.

@LeoT7508
Copy link

@joseegm

techne_2 0_inputfields

@joseegm
Copy link
Contributor Author

joseegm commented Jun 22, 2017

Regarding points on #737 (comment)

Labels

  1. I understand the points and agree with them. But the final result look disproportionated. Visually the input is way "heavier" than the label.
    27450154-527670ae-5750-11e7-9f62-eaf6fa5789a1 1
    It is probably the padding on the input.

    Looking other libraries:
    Fabric: Have bigger label font size than input font size.
    Blueprint: Have the same size.

    We need to test this to be 100% sure, testing will be done at Test Labels font sizes #752 -I'll ping you over there to see the details
    Just to be completely impartial and see what the wild user understands better.

    Since that test involves only one variable (font-size) that we can change later. We can move on with this font size.

Inputs

  1. Okay.
  2. Got it.

Status

Cropping the image for context
27450154-527670ae-5750-11e7-9f62-eaf6fa5789a1

  1. Still missing the Valid Status
  2. Still missing Mandatory. Defined on https://github.com/SAP/techne/wiki/Form-Inputs#form-inputs-status-763 mandatory's description. The mandatory field should have a bigger contrast than the rest.
    So the user recognizes immediately that field is important. Not only for the * on the label.

@jeannewalters
Copy link

jeannewalters commented Jun 23, 2017

@joseegm @LeoT7508 Can you please add Hana to this ticket as well? For Valid Status, can you add more context around how this would be used? I was talking to Leo about this today and I would ask that you clarify in this ticket, what you are considering to be the use case for a "valid" field. I was trying to help him from the UX side but we aren't expecting teams to do inline validation or validation of focus for every field - sometimes, there would be the case where data in fields aren't validated until the primary button is clicked. In order to better guide him from a UX perspective, here the information that he needs:

  • when would this be used - I am assuming not on every field where a valid data entry is made? Can you add more specific cases?
  • what are the best practices around this from a ux perspective?
  • what would you expect to happen when a currency label or weight (or any data label) is also in that field?
    These are the questions that come to mind.
    For any upcoming issues you are working on, you can also submit a research request ticket through the survey monkey link Hana sent out a couple weeks ago so that she can give you the best practice before any design is started. In this case, we don't have this case in the prototype I sent you from Irla.

On a separate note, this pull process does not work for me unless I was dedicated to this team - otherwise, it's super easy to miss a ton of things because I work on a Push basis for all my other teams and believe me, there is a ton pushed so that they and I can help them meet their deadlines. Plus, finding things in Github is more difficult than Jira and I didn't think that was possible. Jira has a Recently Viewed option - or perhaps I am missing that here. Pls advise.

@LeoT7508
Copy link

LeoT7508 commented Jun 23, 2017

@joseegm

I reached out to Jeanne and Irla about UX feedback and research that was done with fields in SmartEdit.

  1. I will wait to see about Validation per Jeanne's comments above.

  2. I had to make a cross between SmartEdit & Techne to update the field labels. In Techne the field label weight is regular, in SmartEdit they are bold. So for normal field labels I used Semibold and for mandatory fields I used Bold.

  3. I also updated the Error state per the user feedback from SmartEdit.

techne_2 0_inputfields

@joseegm joseegm modified the milestones: KW 26, KW 25 Jun 26, 2017
@joseegm
Copy link
Contributor Author

joseegm commented Jun 26, 2017

@jeannewalters
I'm gonna try to make sense of your post since I guess you mixing things here.

Test: Test was already requested to Hanna is already, see #752. If you need something else tested please open an issue with the test details like #757. And post the results as soon as you have it. Tests and test results have to be visible.

Valid State: That was defined on #736 and is part of the Form Inputs Design Spec at https://github.com/SAP/techne/wiki/Form-Inputs#form-inputs-status-763

Focus and Validation: Don't understand what you are trying to say. Maybe rephrase that in a more clear language.

Can now incorporate that case if you want. The valid states is already described as optional.
Have all the information now.

You cannot be assigned you to issues because you still have to accept the invitation I sent days ago.

Don't expect you to jump on every issue here, it is easy to see what's going on in design if you look at https://github.com/SAP/techne/projects/4 the columns To do and UX.

Even more simple all Design and UX tasks are labeled with To Do
https://github.com/SAP/techne/issues?q=is%3Aissue+is%3Aopen+label%3A%22to+do%22

@joseegm
Copy link
Contributor Author

joseegm commented Jun 26, 2017

@LeoT7508

  1. No need to wait. The Valid status only highlight the Form Input element. Most used method is a green border. It is the opposite to the Invalid Status.
  2. Semibold is okay of design, but it will not be much noticeable in the browser. We can go for Regular for normal and Bold for mandatory.
  3. That design makes more clear that the errors belong to the input field.

Only thing missing is the Valid status.

@joseegm joseegm added the UX label Jun 26, 2017
@LeoT7508
Copy link

@joseegm

  1. I have a green color we can use for "Valid" states once Jeanne's concerns are addressed.

  2. I updated the labels.

@joseegm
Copy link
Contributor Author

joseegm commented Jun 26, 2017

@LeoT7508

  1. Jeanne's concerns where answered on Form input visuals #737 (comment). If she want to do some extra tests, it will be posted here.
    I think we have enough elements here to move on with the Valid status.

  2. Very good. Can you please post the updated visuals here? To have more context. Thank you.

@jeannewalters
Copy link

jeannewalters commented Jun 26, 2017

@joseegm - I am asking you to be clear on what you are asking for this field type. Is this only the case for forms where a person is logging and and validation is done immediately for this field?
You are not explaining the use case for these before asking Leo to design it visually - only adding labels. It needs more from requirements from UX before visual should get this issue. Hopefully that is clear now.
Jose said:
Focus and Validation: Don't understand what you are trying to say. Maybe rephrase that in a more clear language.

@joseegm
Copy link
Contributor Author

joseegm commented Jun 26, 2017

@jeannewalters
Thanks for rephrasing your comment. It is more clear now.

The Valid state can be used also for validating emails and other fields in realtime. As I already mentioned in #737 (comment)

I think that clarifies all questions, right?

@LeoT7508
Copy link

@joseegm

techne_2 0_inputfields
techne_2 0_inputs types with common elements

@joseegm
Copy link
Contributor Author

joseegm commented Jun 29, 2017

@LeoT7508
Can you update the visuals again?
To finish this task.

Changes missing:

  1. Valid state: green frame
  2. Read only field with the line at the bottom (on second screenshot)
  3. Action Button with same color as the action icons

Also please update the file on Box.

Thank you

@LeoT7508
Copy link

LeoT7508 commented Jun 29, 2017

@joseegm

techne_2 0_inputfields
techne_2 0_inputs types with common elements

@joseegm
Copy link
Contributor Author

joseegm commented Jun 30, 2017

@LeoT7508 Thanks
Still missing point 3.
Or there is a reason that's not been changed

@joseegm joseegm added this to the KW 27 milestone Jul 4, 2017
@joseegm joseegm removed this from the KW 26 milestone Jul 4, 2017
@LeoT7508
Copy link

LeoT7508 commented Jul 5, 2017

@joseegm

I updated the JPEG about with the colored button you asked for.

@joseegm joseegm closed this as completed Jul 7, 2017
@joseegm joseegm mentioned this issue Jul 13, 2017
3 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants