Builder.io Ideas
We want to make it easy for our CMS users to follow their own design system - which exists in both outside and inside the scope of Builder - but without completely constraining them to it.
Our clients have complex design systems with needs that are not currently supported in Builder. They need better color and spacing support in the editor solved in a built-in manner.
Regarding colors, our clients have normally 30-60 colors that need to be made available inside the CMS (many of these are slightly different shades of the same color palette). It is currently possible to register swatches inside the editor, where then users will see thumbnails of them with a title attribute showing the HEX code while hovering over it.
With the complexity our clients have, maintaining colors this way would be a very difficult, bug-prone and manual task. Registering color via a plugin is not an option for them.
We have therefore written the following description of our wishes for managing colors with the built-in editor:
It should be possible to define colors via an API or via the builder-settings file, so they can be transferred from the design system in an automated manner and don't need to be manually added and maintained in the editor.
It should be possible to pick colors via the built-in color swatch picker in the editor (and not via a plugin).
It should be possible to register multiple fields for a single color. Our preference is name and value, e.g. `color-primary: #bada55`.
It should be possible to configure which fields can be seen in the editor (of thumbnail, name and value).
It should be possible to rearrange already registered colors - either via the editor or via the builder-settings file.
Updating colors (via calling the API again, updating color definitions in the builder-settings file or directly in the editor) should keep the link between colors and blocks. So if a color's unique id is unchanged (the unique id could be the color name or a hidden field Builder maintains), the link should not be broken. This is important, as we expect there will be updates to the design system regarding colors, which also means those updates need to be implemented in Builder.
Example of how the color definition in builder-settings could look like:
Builder.register('insertColors', {
items: [
{
name: 'Color Background/Neutral',
color: '#ffffff',
},
{
name: 'Color Background/Primary',
color: '#62e577',
},
{
name: 'Color Border/Neutral',
color: '#ffffff',
},
{
name: 'Color Text/Default',
color: '#000000',
},
],
});
Spacing is the other area, where our clients have a need for constraining CMS users to the design system. It is currently possible to type any value in the Margin & Padding picker of the Style tab.
We would like to be able to make a list of values available to the built-in editor from the design system (instead of the the default option of 20px). Wishes for managing spacing:
It should be possible to define spacing via an API or via the builder-settings file, so they can be transferred from the design system in an automated manner and don't need to be manually added and maintained in the editor.
It should be possible to pick spacing via the built-in Margin & Padding picker in the editor (and not via a plugin).
It should be possible to register multiple fields for a single spacing variable. Our preference is name and value, e.g. spacing-md: 16px.
It should be possible to configure which fields can be seen in the Margin & Padding selector (of name and value).
Example of how the spacing definition in builder-settings could look like:
Builder.register('insertSpacing', {
items: [
{
name: 'Spacing/md',
value: '16px',
},
{
name: 'Spacing/sm',
value: '12px',
},
{
name: 'Spacing/xs',
value: '8px',
},
],
}); 
@steve thanks for your replies. Here's some further feedback from me.
It makes good sense to solve the issue regarding the background-image property by using the Image block instead for the time being.
The keyboard shortcut update to margin/padding selector sounds awesome, i'll look forward to trying it.
And thanks for adding values in the dropdown, that's really nice. Is there any way though to show the calculated value instead? Cause when working with CSS variables, the value will still just show the variable name, which doesn't give the user more info. See the screenshots attached for an example of spacing.
I also have another question regarding roles/permissions. Could it be made possible to configure editor.settings differently for different roles? I have demoed the design tokens feature to our biggest customer, and they would like to use this in a way, where they'd like some users to only have access to design tokens and use strict mode, while a few more experienced, power users would need permissions to all properties, e.g. CSS properties to be able to create more advanced layouts.
Thanks in advance :-)
also @krisztina one other note - we don't have current plans to support a
property: truesyntax just yet, but the workaround would be to just set any properties you don't want to false. if that doesn't solve your need let us know a bit more about your use case and we can see if another solution is worth proposinggreat point on nesting sections @jason - definitely something we can consider in the future. another approach to your needs too would be just to break apart text colors vs background colors etc and set those explicitly. e.g. they can override the base
colors, so you can doand incredible feedback @krisztina - the doc is really helpful. couple questions/callouts
what other types would you want other than enums?
this is a good point, I had thought we supported this already but realized we maybe don't. this is something we could/should ultimately make a special plugin hook for
unfortunately the built-in margin/padding editor doesn't have enough space, but i made an update to at least make the token version feel a bit more similar and hopefully more intuitive
good point on manually enabling specific styles. given this feedback and those from jason we're taking a look at how to make this more flexible (e.g. design tokens optional, too). we have some ideas we're starting to explore
bugs mentioned (like layout and z-index) should now be fixed internally (will deploy soon), thank you for reporting!
re: design tokens per space, absolutely. since this is in your code, its completely in your control. your code should already be aware of the space you are in because that is the api key that will be used, so you can do any conditional logic you like. we also provide the space ID as a query param in the URL if needed too. so you can do like
if (space = '...') {Builder.register(...)
} else if (space === '...') {
Builder.register(...)
}
if i missed anything here just let me know!
(Sorry, this link should work: https://hedalkrusebrohus-my.sharepoint.com/:w:/g/personal/krry_hesehus_dk/EVQ_rHQ7vp5DuwXlDAJTUsIBsmElCYQfLENWZwhPeCQ9QQ?e=skR6su)
First thoughts: it is awesome, flexible and pretty much what we have been hoping for. Really excited about it 🎉
After a bit more thorough testing, we have found a couple of things, that we think could be even better. Here are some of our thoughts.
Regarding property editors:
Option types currently always seem to be enums. Could other types be supported?
Could overridden style properties use the built-in editor for that type, and/or a custom one via plugins?
E.g. could backgroundImage support using the Bizzkit DAM plugin?
Spacing tokens: could it use the built-in margin/padding property editor – which is more intuitive?
Our bottom line: the custom property editors using design tokens should not have worse UX than the built-in ones
Regarding style strict mode:
Awesome, we love the flexibility this feature gives 🙌🏽
Regarding this, could we also have a reverse approach to disabling/enabling property editors?
So, supporting using strict mode and opting in to specific default property editors with e.g. `boxShadow: true`, rather than not using strict mode and opting out with e.g. `boxShadow: false`?
Regarding multi-space customers:
Is it possible to define a set of designTokens per space in a project that uses the same codebase for all spaces? (We think yes.) In that case, how would recommend initiating these various sets of configs - that are importing each space's own design tokens?
Some smaller bugs:
Design tokens in the layout section breaks the UI – e.g. there is not enough space to display maxWidth tokens correctly. The dropdown also has some z-index issues
We have issues disabling built-in property editors. We write e.g. `fontFamily: false`, but the editor doesn’t get removed from the UI.
(To see screenshots for these bugs, please see this doc: https://hedalkrusebrohus-my.sharepoint.com/:w:/g/personal/krry_hesehus_dk/EVQ_rHQ7vp5DuwXlDAJTUsIBfORZExeC1oiiKw1p5VmMZA?e=cuoMrF)
One more quick comment from me @steve, Is there any possibility in the future of "nesting" sections? For instance, we have a bunch of colors that are specifically only for text. Now obviously, I can name the tokens "Text - Unselected" or something like that, but it'd be really cool if there was a way to make it more obvious that these "text" colors are grouped together and these "brand" colors are grouped together, etc.
I'm thinking something along the lines of this:
great point @jason - I wondered if some would feel this way, we'll look into addressing this
Playing with this today and I love the early version, except for one product decision: exclusivity of forcing the use of tokens, even not in strict mode if you provide design tokens. My ideal world would be providing the list of design tokens for colors with the ability to choose "Other" if not
strictMode: true. That way, I could do a staged implementation of Design Tokens and also allow for those times when our designers get a little "creative" and want to use non-standard colors for one-off landing pages.Awesome - we are testing it out and will provide you with feedback ?
Best
Charlotte
This is now live in beta, we would love your feedback! https://www.builder.io/c/docs/design-tokens