NO BUG: Color picker allows multiple value types, reverts to hex

Bugs
1

Video: Bricks Color Picker Bug.mp4 - Google Drive

The color picker does not clear values from other types when setting a value. For example, if a hex code is already assigned, adding a variable value does not clear the hex value; it retains both. On subsequent page loads, re-opening the color picker clears the variable value and retains only the hex value.

Expected behavior is that values from other types are cleared when setting a value of another type.

3 Likes
2

Hi Allen,
Thanks so much for your report!

Then, assigning a color to a variable and saving it in the color palette would no longer be possible if one of the two fields is constantly cleared.

If you want to use a variable that is already defined, clear the RGB value and everything will be fine.

Best regards,
timmse

3

@timmse I would suggest another strong look at this functionality. The ability to set two mutually exclusive values for a single property does not align with expected UX.

Additionally, when applying a saved color from a palette, Bricks doesn’t even use its own variable in the builder. It sets the hex value (screenshot below). You can see the name of a variable there, but it’s grayed out and can be typed over.

Screenshot 2024-06-19 at 9.24.40 AM|407x499

Lastly, the behavior I’m suggesting already flows one way. If you select a color from the palette and then change the hex value, it removes the variable name from the “Raw” field. It would then make logical sense that if the value of the “Raw” field changes then it would clear the other value types.

It doesn’t make a lot of sense that the builder is dependent on a grayed out “value” being present in a user-editable field without some kind of validation/enforcement.

4

Hey Allen,
Let me try to address all the points:

It does 100% (see screenshot). The color palette allows you to define a color (as hex), assign a custom variable name, and save it to the color palette. If you don’t assign a custom variable name, the default one is used globally and can be updated globally.

CleanShot 2024-06-19 at 17.29.02@2x
CleanShot 2024-06-19 at 17.29.02@2x1920Ă—780 112 KB

This is the default color palette with the default variables:

CleanShot 2024-06-19 at 17.30.10@2x
CleanShot 2024-06-19 at 17.30.10@2x560Ă—584 70.5 KB

Of course you can change the default variable name, by switching to “list view” and then clicking on the “edit” icon of the corresponding color, entering the new variable name and then clicking on save.

CleanShot 2024-06-19 at 17.33.15@2x
CleanShot 2024-06-19 at 17.33.15@2x1252Ă—2094 346 KB

Doing so, you are defining a new color that is not yet saved in the color palette and therefore does not yet have a default (or custom) variable name. It only gets this when it has been saved to the palette. If it’s not saved to the palette, it’s a simple, individual color - not a variable.

As I said, it would then simply not be possible to assign a custom variable name if this would empty the value - and vice versa.

–
I hope that my explanations will help you to better understand the functionality and range of features of the color palette (which is relatively complex).

5

@timmse Thanks for taking the time to outline a detailed response. I definitely understand the complexity of the color picker. I think your explanation actually furthers my point.

First, using this field to set the variable name is unintuitive in several ways:

  1. The same field is used for setting the CSS property value AND for changing the variable name
  2. The only thing that determines the difference is whether the edit button was clicked first
  3. There is no clear visual indicator to show which “mode” the input field is in (the presence of the “save” button is not clear)
  4. The edit mode can only be accessed from list view and not from swatch view
  5. This violates separation of concerns principles by using the same input for both setting a CSS property value (default usage) and changing CSS variable settings (CSS variable modification). This is further convoluted because the HEX and RAW fields function differently when editing a variable. When setting a CSS property (default usage), both fields are setting the value of a CSS property. When editing a variable, the HEX field is editing the value while the RAW field is editing the property name. Nothing about this is intuitive from a UX perspective.

Additionally, since creating colors in a palette creates CSS variables, from a UX perspective it would be more logical to set the RAW value in the picker instead of the HEX value in the picker when selecting a color. Then the HEX value can be shown as grayed-out placeholder text (similar to how the default variable name is currently grayed out). The current method of populating the HEX value when choosing a color from the palette is an unintuitive abstraction because the variable is actually being used everywhere else except in the picker UI.

This approach of populating variables into the RAW field on color selection would also solve the issue I originally posted. Because then clearing the RAW field would clear both Bricks color palette selections and custom variable values.

I fully understand this is not currently possible due to the way the color picker is built. I’m suggesting that this particular aspect of color picker needs to be reconsidered and rebuilt. The fact that it’s not currently possible does not mean that it’s not possible at all. Poor UX is poor UX, and because something is currently built a certain way is not a valid reason to keep poor UX in place.