Theme Colors vs Button Colors

Forum rules
Please note that response time for technical support is within 3-5 business days.
Post Reply
kbagoy
Posts: 2
Joined: 12 Jan 2023, 17:35

17 Jan 2023, 23:01

Our team is considering moving to PrimeVue from Vuetify so I've purchased the UI kit to review and determine what we'd need to do to retrofit an existing product or to use for future new products. I'm confused as how styles are being used/not used:
  • There are theme colors {theme/primaryColor}, but they are not applied across components - instead the components are created with their own colors (i.e. Lara/Button/buttonBg). Is there a reason you've split out the colors styles this way? It seems a better way would be to use the theme colors so that if those change, the relevant styles would change. Likewise, there is something like 200 individual colors styles making it very unwieldy (like, why do we have infoMessageIconColor, infoMessageTextColor & infoMessageBorder as separate styles when they are the same color, and why is that color not related to the theme?)
  • Likewise, text styles exist for h1> h6, but many of the components are not linked to styles (ex: Advanced card does not have a header or body style, messages are not attached to text styles)
It seems like it would make more sense if the Figma styles reflected the styles used in theme designer so they are consistent with development. Example would be instead of using the style "body/regular-400/line-height-1.5," message cards would use "p-message-text". This would also allow us to use Figma Tokens better - as of now, adding the existing styles to tokens creates a hot mess of duplicate, disconnected tokens.

Do you have plans to update the component set to align with actual production styles? if not we'll need to do a lot of refactoring of this library to properly reflect the theme, which means adding any newly released components/updates will be a nightmare.

Also, do you have plans to utilize component properties in the future? In this version, there are over 1000 button variants, which could be easily resolved using component properties. I can do that for our files, but again, that means any future updates will be a nightmare to consolidate so I'm trying to figure out the best path forward.

Please advise.

User avatar
w00f
Posts: 307
Joined: 27 Apr 2016, 13:27
Contact:

23 Jan 2023, 16:05

Hi,
There are theme colors {theme/primaryColor}, but they are not applied across components - instead the components are created with their own colors (i.e. Lara/Button/buttonBg). Is there a reason you've split out the colors styles this way? It seems a better way would be to use the theme colors so that if those change, the relevant styles would change. Likewise, there is something like 200 individual colors styles making it very unwieldy (like, why do we have infoMessageIconColor, infoMessageTextColor & infoMessageBorder as separate styles when they are the same color, and why is that color not related to the theme?)
The reason for using individual colors in our UI Kit is to ensure as much consistency as possible with the variables used in our Theme Designer.
Likewise, text styles exist for h1> h6, but many of the components are not linked to styles (ex: Advanced card does not have a header or body style, messages are not attached to text styles)
I agree, some text styles may not be linked at the moment, as there may not be a corresponding variable in the Theme Designer.
It seems like it would make more sense if the Figma styles reflected the styles used in theme designer so they are consistent with development. Example would be instead of using the style "body/regular-400/line-height-1.5," message cards would use "p-message-text". This would also allow us to use Figma Tokens better - as of now, adding the existing styles to tokens creates a hot mess of duplicate, disconnected tokens.
We are currently preparing the Kit for adaptation with Tokens Studio (formerly known as Figma Tokens), so this feedback will be useful. We appreciate your input.
Do you have plans to update the component set to align with actual production styles? if not we'll need to do a lot of refactoring of this library to properly reflect the theme, which means adding any newly released components/updates will be a nightmare.
We will update the Kit with actual production styles. However, please keep in mind that these updates may not always align with framework releases. UI Kit updates occur less frequently, so you may need to wait for complete alignment.
Also, do you have plans to utilize component properties in the future? In this version, there are over 1000 button variants, which could be easily resolved using component properties. I can do that for our files, but again, that means any future updates will be a nightmare to consolidate so I'm trying to figure out the best path forward.
We have already made some overall improvements about component properties and will be releasing these changes soon.

Sorry for the delayed response,
Best regards,

kbagoy
Posts: 2
Joined: 12 Jan 2023, 17:35

24 Jan 2023, 20:18

Thank you - do you have an estimated release date for those updates? I'm trying to determine if we can wait for that to start prepping or if we need to just move forward and update the kit to suit our needs

User avatar
w00f
Posts: 307
Joined: 27 Apr 2016, 13:27
Contact:

06 Feb 2023, 10:44

kbagoy wrote:
24 Jan 2023, 20:18
Thank you - do you have an estimated release date for those updates? I'm trying to determine if we can wait for that to start prepping or if we need to just move forward and update the kit to suit our needs
Hi,

We plan to release version 2.0 this month. Please note that this is not the Token Studio update. The Token Studio update, version 3.0, does not have an estimated release date at this time.

Best regards.

Post Reply

Return to “Figma”

  • Information
  • Who is online

    Users browsing this forum: No registered users and 3 guests