🎨 Rethink design system

[bennymi]

Essentially instead of using text-primary-500 we want to define higher level shortcuts such as text-primary, surface-primary, surface-secondary. This way we reduce the amount of variability while designing websites of always having to decide whether to use bg-surface-800 or bg-surface-900 for example, and instead just use surface-primary.

It would also be good to have extra variables where dark mode attributes are also defined. So surface-primary is based on different CSS classes in dark and light mode.

So instead of: css values-> classes we have css values -> theme -> shortcuts.

Design settings:

• surface-primary (surface-primary-light + surface-primary-dark): main background color
• surface-secondary (light + dark): Used for things like navbars and sidebars
• surface-card (light + dark): Used for modals, cards, etc, so elements that go on top of the other backgrounds.
• ...

Still have to figure out the best naming conventions for these. Since we have bg-surface and bg-primary it might be confusing to have surface-primary? Will have to ask others what they think about this.

Resources

• Figma: https://www.youtube.com/watch?v=1ONxxlJnvdM
• Realtime Colors: https://www.youtube.com/watch?v=YWVneCWIfoE
• Theme switcher: https://www.youtube.com/watch?v=3GpZkVBjXfE&t=87s

[bennymi]

Inside our theme css files we can define extra variables that reference other variables:

:root {
    --surface-primary: var(--color-surface-800);
}

Inside the designer page we can easily set it up so that these can be picked from a list of available options. For different themes it then becomes easier to adjust the look and feel by just changing the referenced variable.

We can then create a shortcut or a rule for these variables inside our preset.

['surface-primary', 'bg-[var(--surface-primary)]']

When designing our website we then no longer use things like bg-surface-500 but instead just reference our higher level variables surface-primary, etc.

Edit:
Instead of specifying some of these settings inside the CSS files, it would probably be best to define all these as settings that get passed to the preset inside the uno.config.ts file. This way all these settings are in one place. The question is then how does the designer page show these changes, since obviously we can't change the config file from there...

[Asp-Codes]

Hey, Bennymi I would love to resolve the issue mentioned. Being comfortable with Figma and material UI it would be easy for me to solve the issue perfectly.

[bennymi]

Hi @hemanth8819 thank you for your comment, but I'm thinking that this will probably require quite a lot of changes to the documentation, the themes, and the designer, so it would probably be better for me to take this one on. I'm open to ideas however, about how the design system could be improved or what features you think should be included in this update, so feel free to let me know.

[Asp-Codes]

Yeah definitely, I will look into that.Thanks for getting back!