How upset would you be if could no longer access your Color Palette in Settings > General when we release Color variables in Styles > Style Variables?
Color variables are like the recently introduced Font variable in that they allow you to set global color variables that can be used throughout your app (ex in a style for the background color or in a text box for the font color). If a color variable value is updated, any element with that variable attached to it will also update.
As we near the release of Color variables into the editor, the Color palette will be obsolete in that your color variables will now appear in the color picker instead of any colors originally set in the color palette.
Ideally, we would simply remove the Color palette when we release Color variables, but want to ensure that users wouldn’t be relying on the colors set in the color palette. If this is too much of a breaking change, we have options to mitigate any disruptions as well.
A bit hard to answer without seeing what it would look like exactly. Would we still be limited to only 7 colors? I use the color palette a ton, especially with conditionals, which are often specific to the page/element and can’t be made into global styles. For example, “if [parent group] is hovered or [parent group’s state] is yes, background color = X.” Would we still be able to do stuff like that? If not, this is a HUGE no from me.
I’ve also seen some reports of the global font feature not working for some apps only on production/live versions, so I’ve been hesitant to try out the new global variables because I’ve also seen a few other small things with our app that work fine in testing but don’t in the live version.
@nick.carroll I’m excited about this update. Can you expand on how this would impact existing projects? For instance instance “users wouldn’t be relying on the colors set in the color palette.” With colors being set in styles and inline on the element … these would be still set, correct?
Can you share a screenshot of the replacement? As far as I’m understanding this, the 7 colours will be prepopulated in the replacement UI and there won’t be any affect on current apps? All conditionals using colours will still work. Can you release as an experimental version first?
Global color variables that sync up sounds amazing.
I’m down but wonder the same as everyone, what’s the UX? If I want to set some color to something, would I have to click,click,click into the styles view to set it? Would colors only be able to be set as a style?
(1) The color variables will certainly be available for use in conditional statements, and if a color token is assigned in a normal state, a conditional statement could override that selection with another variable or another color.
(2) Will follow up on these reports of app font not working properly in Live.
(3) This will not impact any existing projects. It is totally up to the bubble developer to set their color variables and attach them to any elements or styles.
(4) As far as the UX, a user can set 8 color variables to start. These variables are available for selection as a shortcut in the color picker. Variables (or any color) can be set on an element property or on a style, completely up to you.
Until now I think CSS style sheet was faster much faster than Bubble Style system setting/ I felt like coding in CSS was easier than using the style tab. I think the introduction of these variables would greatly help in defining the theme. I find no real use of the color palette for someone heavily relying on style unless they don’t.
I think it is a great idea as color variables will help make it easy to change the system design for an app.
What would the transition look like in your opinion? The ability to copy and paste colors from the color palette into the new color variables? One option here could be to just leave the color palette in settings for a few weeks and then phase it out.
@nick.carroll Could you auto populate those colors from our palette to the application’s colors? If I was doing that upgrade on my own platform, I think that is what I would do personally. Maybe that is too difficult to do?
I’d suggest 3 simple NEWS Warning or maybe email to all users would suffice. I would opt for this rather than Bubble spending precious time programming something that will only effect us once. As for keeping it, I wouldn’t. The new variables is a nice improvment.
I agree. In fact, being constrained to predefined / fixed color names is not particularly useful for my needs. @nick.carroll, why not take the time to implement user-defined style variables for ultimate flexibility?
Or are those color style variables editable (both name and value) and simply pre-populated as examples for each app?
8colors is a bit limiting specially for color tones (hovered, pressed, disabled) background (lowest surface, middle, highest surface), etc. Please make it customisable depending on each user’s needs.
Being able to create and name our own custom color variables. The ones listed are great for nudging people without a design background towards creating their palette, but it’s still very limited for most apps. I’d like to be able to create multiple shades of my primary and grey colours, for instance. For chart-heavy apps more colours again are needed.
I know you guys probably want to keep a hard limit on the amount of variables someone can create, but a hard limit of 30-40 would be more useful.
Exposing the ability to set color in HSL would be another big win, as we can more easily adjust shades in our palette natively in Bubble
Can’t agree more. Locking in variables and making assumptions is a dead-end street. In the example posted, there would be one single “Text” color, which just isn’t true because only in this forum, I see at least four different text colors, and I would be using several shades of gray for things like borders etc - all which I want to keep consistent and at hand, and so would use a style variable set for.
(I am however all in favor of having some nice presets added when starting a new application)
Maybe that is too difficult to do?