SeedCompany / cord-field

CORD UI
MIT License
7 stars 3 forks source link

Theme Refresh #1553

Open CarsonF opened 2 months ago

CarsonF commented 2 months ago

Mostly trying to get back to MUI defaults in a lot of places. Driven by filters in tables which I bring up half way down.

Stop coupling color to typography

MUI components will inherit typography variants, but use a different action color. For example, <FormLabel> defaults to secondary text color and body1 typography. So we probably want to respect that color.

Primary text color #3c444e -> 75% black

Using opacity for gray renders better than solid colors, esp on colored backgrounds. For context, MUI defaults is 87%. 75% matches close to what we had before.

Before Screenshot 2024-06-25 at 5 02 08 PM After Screenshot 2024-06-25 at 5 01 50 PM

Secondary text color #8f928b -> 60% black (MUI default)

Following suit of primary. Opacity has to drop all the way to 45% to be close to what we had before. For context, the disabled text color is only slightly lower than that at 38%.

The contrast just wasn't enough at 45% esp on labels of filled inputs, which have a gray background.

Before Screenshot 2024-06-25 at 5 05 13 PM After Screenshot 2024-06-25 at 5 04 44 PM

Re-allow input labels to act as placeholders that shrink & remove all caps

Placeholders seem to still be desired by design, and MUI's default of the label acting as the placeholder and then shrinking to the label looks nice IMO. Better than having both a label & a placeholder. I kept the slightly bolder weight when label is shrunk, but I would be down to remove that too.

Before Screenshot 2024-06-25 at 5 08 04 PM Screenshot 2024-06-25 at 5 08 27 PM After Screenshot 2024-06-25 at 5 08 50 PM Screenshot 2024-06-25 at 5 09 00 PM

Header filters in Tables

Those screenshots seem like subtle changes. All of the changes so far (other than primary color) are to make the table header filters look better.

Before Screenshot 2024-06-25 at 5 15 43 PM After Screenshot 2024-06-25 at 5 16 10 PM

The less opaque & non caps help the text to be so in your face. Esp comparing to the column title, which is smaller.

IconButton default size large -> medium (MUI/MD default)

48px -> 40px. Seems fine to me, and it sounds like in general we want to shrink our UI elements more.

Before Screenshot 2024-06-25 at 5 22 45 PM After Screenshot 2024-06-25 at 5 23 08 PM

Background color #fafafa -> #ffffff (MUI/MD default)

Pics below. Idk I could revert this. Just trying to follow defaults for this iteration.

Card elevation 8 -> 2 / Paper 1 -> 2

1 is default for MUI. To me, there is just not enough shadow on 1, to make the surface distinct from the background. Paper is basically the same thing, so bumping to be consistent with Cards.

Before Screenshot 2024-06-25 at 5 26 28 PM After Screenshot 2024-06-25 at 5 26 04 PM

Before Screenshot 2024-06-25 at 5 29 58 PM After Screenshot 2024-06-25 at 5 30 26 PM

AmyRickwartz commented 2 months ago

Great! A lot of these things I have been wanting to change as well.

Stop coupling color to typography

MUI components will inherit typography variants, but use a different action color. For example, <FormLabel> defaults to secondary text color and body1 typography. So we probably want to respect that color.

This one seems ok to change to in general, but I'm not sure how some of the things we did in the past will look once we change back to the theme, Is there a way to preview. I'd also like the ability to override if I needed to.

Primary text color #3c444e -> 75% black

Using opacity for gray renders better than solid colors, esp on colored backgrounds. For context, MUI defaults is 87%. 75% matches close to what we had before.

I studied this quite a bit when I first started on CF on the Material site. I liked how Material did it. Can we change the primary and secondary color to be just black and the opacities are what make it primary, secondary, ect? Before I think we were using different values of black on the spectrum to render this affect and that does make it harder to read and be less flexible to change the overall colors in the future....

Secondary text color #8f928b -> 60% black (MUI default)

Following suit of primary. Opacity has to drop all the way to 45% to be close to what we had before. For context, the disabled text color is only slightly lower than that at 38%.

Same thing here.

Re-allow input labels to act as placeholders that shrink & remove all caps

Placeholders seem to still be desired by design, and MUI's default of the label acting as the placeholder and then shrinking to the label looks nice IMO. Better than having both a label & a placeholder. I kept the slightly bolder weight when label is shrunk, but I would be down to remove that too.

This is another one that I have done some reading on as well. So I agree the labels that are big then move and get small are cleaner, however they work better on simple forms. We have many places in CF that have more complex forms and keeping the label stationary is better for scanning and some other things. I agree that we don't need place holder text for everything because it can be redundant and looks cluttered. I have often wondered if the text field needs a place holder for instruction and clarity, we use the helper text area with a secondary (lighter color). But then if there is an error, will it be replaced by the error text, which shows up in the helper text area? We would need to work that out.

The all caps has not been my favorite so I would agree with making it Title Case (maybe sentence case, I'd have to see what that looked like, but go with Title case for now).

Header filters in Tables

Those screenshots seem like subtle changes. All of the changes so far (other than primary color) are to make the table header filters look better.

Looks good. I agree.

The less opaque & non caps help the text to be so in your face. Esp comparing to the column title, which is smaller.

IconButton default size large -> medium (MUI/MD default)

48px -> 40px. Seems fine to me, and it sounds like in general we want to shrink our UI elements more.

Agreed. The medium buttons are good. Somewhere the tabs got changed to all caps. If you can magically make those go back to Title case that would be great as well.

Background color #fafafa -> #ffffff (MUI/MD default)

Pics below. Idk I could revert this. Just trying to follow defaults for this iteration.

This one is a little trickier because a lot of the designs have started with a slightly tinted screen. Also, the bright white is harder on the eyes. So lets stay with the #fafafa for now.

Card elevation 8 -> 2 / Paper 1 -> 2

1 is default for MUI. To me, there is just not enough shadow on 1, to make the surface distinct from the background. Paper is basically the same thing, so bumping to be consistent with Cards.

Yes agreed. We have talked about this one. Moving to 2 for default is great with me.

  • AppBar elevation 1 -> 2 It is weird to have that floating surface lower than surfaces on page.

Yes, agree on this one as well.

CarsonF commented 2 months ago

This one seems ok to change to in general, but I'm not sure how some of the things we did in the past will look once we change back to the theme, Is there a way to preview. I'd also like the ability to override if I needed to.

We can preview in dev for a bit. We can always make a different decision in the future.

Can we change the primary and secondary color to be just black and the opacities are what make it primary, secondary, ect? Before I think we were using different values of black on the spectrum to render this affect and that does make it harder to read and be flexible to change the overall colors in the future....

That's exactly what I changed here.

This is another one that I have done some reading on as well. So I agree the labels that are big then move and get small are cleaner, however they work better on simple forms. We have many places in CF that have more complex forms and keeping the label stationary is better for scanning and some other things. I agree that we don't need place holder text for everything because it can be redundant and looks cluttered. I have often wondered if the text field needs helper text, then that's exactly where we place it, in the helper text line at a secondary (lighter color). But then if there is an error, will it be replaced by the error text, which shows up in the helper text area? We would need to work that out.

Not sure I agree on being better for "simple" forms. I think in general the thought is we don't like complex forms, separate from the label position. As far as the different components: Labels are short identifiers. Placeholders should help give an example value when values are not immediately obvious. Helper text gives extra info not yet provided. I rarely see the need for these. Here is only of the only places I can think of that we use them: Screenshot 2024-07-02 at 1 50 39 PM

Maybe we can try out this change and the title case change for a couple days?

This one is a little trickier because a lot of the designs have started with a slightly tinted screen. Also, the bright white is harder on the eyes. So lets stay with the #fafafa for now.

Roger, I'll revert.

AmyRickwartz commented 2 months ago

This is another one that I have done some reading on as well. So I agree the labels that are big then move and get small are cleaner, however they work better on simple forms. We have many places in CF that have more complex forms and keeping the label stationary is better for scanning and some other things. I agree that we don't need place holder text for everything because it can be redundant and looks cluttered. I have often wondered if the text field needs helper text, then that's exactly where we place it, in the helper text line at a secondary (lighter color). But then if there is an error, will it be replaced by the error text, which shows up in the helper text area? We would need to work that out.

Not sure I agree on being better for "simple" forms. I think in general the thought is we don't like complex forms, separate from the label position. As far as the different components: Labels are short identifiers. Placeholders should help give an example value when values are not immediately obvious. Helper text gives extra info not yet provided. I rarely see the need for these. Here is only of the only places I can think of that we use them: Screenshot 2024-07-02 at 1 50 39 PM

Maybe we can try out this change and the title case change for a couple days?

I'm remembering now that the issue has been for fields that later need to be edited. There were so many disscusions about editing in place vs going to another page to edit. But I think that is what got weird. The labels were jumping around when we then went to edit the information. It's even made me think about moving the label outside the box. Vonshel has made some new designs like this. So it might be something we move to in the future.

For sure undo the caps and make the helper text less bold. We can start there.

CarsonF commented 2 months ago

I'm remembering now that the issue has been for fields that later need to be edited. There were so many disscusions about editing in place vs going to another page to edit. But I think that is what got weird. The labels were jumping around when we then went to edit the information. It's even made me think about moving the label outside the box. Vonshel has made some new designs like this. So it might be something we move to in the future.

For sure undo the caps and make the helper text less bold. We can start there.

I don't think this has anything to do with editing in place vs dialog. This also only affects the empty state. I'm not really sure what you mean by "jumping around when we then went to the edit in the information."

Sure, we can undo the caps, and circle back to re-enabling the floating label/placeholder behavior.