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

Theme Refresh #1553

Merged
merged 10 commits into from
Oct 16, 2024
Merged

Theme Refresh #1553

merged 10 commits into from
Oct 16, 2024

Conversation

CarsonF
Copy link
Member

@CarsonF CarsonF commented Jun 25, 2024

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.

I reverted this - can reconsider separately.

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)

I reverted this per design request.

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

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

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

https://seed-company-squad.monday.com/boards/3451697530/pulses/7550535438

@AmyRickwartz
Copy link

AmyRickwartz commented Jul 2, 2024

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
Copy link
Member Author

CarsonF commented Jul 2, 2024

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
Copy link

AmyRickwartz commented Jul 2, 2024

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
Copy link
Member Author

CarsonF commented Jul 2, 2024

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.

@CarsonF CarsonF mentioned this pull request Oct 1, 2024
@CarsonF CarsonF force-pushed the theme-refresh branch 2 times, most recently from 2824242 to eb1b80c Compare October 1, 2024 18:51
Copy link
Member Author

@CarsonF CarsonF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rdonigian @atGit2021 Would you guys play around with this and see if you can spot anything that looks weird?

src/theme/palette.ts Outdated Show resolved Hide resolved
CarsonF and others added 10 commits October 16, 2024 09:51
MUI components will inherit typography variants,
but use a different action color.

For example, FormLabel defaults to `text.secondary` & `typography.body1`
So we probably want to respect that color.
Using opacity for gray renders better than solid colors,
esp on colored backgrounds.
MUI default is 87%, which I think looks good.
75% matches close to what we had before.
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 input,
which have a gray background.
Moved the bolder label weight to shrink class,
so it doesn't apply if/when allow labels to act as placeholders.
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.
It is weird to have that floating surface lower than surfaces on page.
@CarsonF CarsonF merged commit e9b72ea into develop Oct 16, 2024
3 checks passed
@CarsonF CarsonF deleted the theme-refresh branch October 16, 2024 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants