Iterating on the color picker

[karmatosed]

As part of the work that's been going on with both the new editor styling #18667 and also global styles #19255 #19611, the idea of iterating the color picker has come about. I thought it might be good to pull out that element and bring some ideas to the table to iterate.

Why change it?

Our color picker takes up a lot of interface space right now. This can really produce visual density if we have more than one. Another problem with our current implementation is browseability, it's harder than should be to see what is the default colour. As things grow, it could be great to explore whether what we have today works or we can review.

I have been observing some explorations in the block interface work that really can be brought back into the color picker throughout, so decided to explore just that.

It's worth saying these are just initial sketches and ideas over final mocks, let's have a discussion first before diving into that.

Pill pickers

The start of the color interface in my latest mocks for #19255 show this pill brought in from explorations over the new interface.

Above you can see a few states, with text and with an accordion.

Color picker

The actual color picker activates on clicking the color and by default shows the theme colors in my explorations:

If you click custom, then you get to explore deeper.

Notes

This assumes some new visual language and is based heavily on the PR work in #19344 so please view that with it in mind. The underlying patterns can be iterated on should that be needed as styling comes in.

At this point, I would love feedback as to if this feels good to explore and go further? I would also love to know what technical limits we have if any.

[ZebulanStanphill]

When a theme/palette color is selected, the color title should be shown in the pill-thing rather than a hex value. Of course, this will likely require the pill to become longer to contain the color title.

Also, I think the Theme/Custom tabs should be shown next to each other, rather split apart with a lot of space between.

Also, how would this look in context with the gradient/solid tabs?

[karmatosed]

@ZebulanStanphill I haven't explored gradients yet and totally will once get a pattern going here feels right. Just as a note hex is where you'd pick in custom right now, so yes once we prototype that would update in the color view.

[jasmussen]

Really dig those visuals, nice work.

The term "Pill picker" confuses me :D I think of something with very rounded edges as being pill-shaped.

The actual color picker activates on clicking the color

I think this one is important to keep in mind. It's an extra click, but it's an obvious one, and it keeps the UI simple instead of permanently showing a slew of swatches in the sidebar.

I wonder if there's a different approach we can take than the tabbed window. Because it's a popover, we've already reduced the UI to be fully contextual, so if we could save another tab click that might be nice. And in the case of color pickers, there's a great deal of prior art we can take inspiration from. Here's Figma:

While the swatches box at the bottom is not a 1:1 with Theme Colors (you can't modify theme colors), it's nice to see those two options for picking colors in one window. Is there a way we can adopt the general principle here?

[youknowriad]

What about gradients. What happen in situation where we have to choose a color or a gradient. (backgrounds)?

[jasmussen]

Gradients would presumably not work in all cases, like for borders. But Figma lets you choose the type in the top left corner of the picker window, as a dropdown. We could perhaps let that type be more visual, but it does make hierarchy sense to have it be the first choice / title.

[karmatosed]

Thanks for the great feedback @jasmussen and @youknowriad. I took a bit of a dive back into this and wanted to take inspiration from your insights into pushing it further. I first took the picker along the great nudge towards Figma. I'll also note that pill felt the best word but yes it's problematic, let's go with color indicator?

Side color picker with larger indicators

This has the same indicators but a side color picker. You can switch between solid and gradient at the top, and hex or others to the side. Similarly, this could extend beyond showing 'theme' colors but it might be good enough to just show those. Perhaps in future personal saved colors could be a thing.

Here is the picker in isolation.

Side colo picker with thin indicators

I took direct inspiration from Figma here, what if we had even smaller indicators and what if '-' is a way to remove those custom colors back to default? This is a pure experiment just to see a visual.

[youknowriad]

Say, I choose a gradient over a solid color, what would the input next to the small preview show?

[karmatosed]

Here is the solid and then the gradient to compare. I'll note these are just some super rough explorations but hopefully show how this could adapt.

I am not totally sure if we want 'hex' selection on gradient, to be honest, whatever we can do to simplify the better. I also added a 'close' to the mock as we likely want that also.

[youknowriad]

yeah I'm asking more about the value shown in the input when the popover is closed.

[karmatosed]

Ah, sorry about that I was going along a different path. There are a number of ways so showing them all to iterate:

If we have a smaller shape the same would apply.

[karmatosed]

I have done a few more iterations springing off from the above direction went in today.

Adding options

This could be where we add things like 'linear' and different types of gradients. We could even add patterns, image (combining that) and end up having it also be extendable.

Here I also iterated a no border around the gradient builder to maybe visually ease a bit.

Adding saved

This is a future feature but the bottom drop-down could include theme, suggestions and saved. Here is just showing with suggestions and saved if a theme has no gradients suggested.

[jasmussen]

Some quick and fast suggestions here!

I see potential in https://user-images.githubusercontent.com/253067/72979484-519da800-3dd0-11ea-9002-ad5a481986ed.png and https://user-images.githubusercontent.com/253067/72981159-05ecfd80-3dd4-11ea-8a60-cbbd18814ac5.png and I wonder if we could mash them together?

Something like this:

The theme color swatches and gradient presets would both be there at the bottom, always. If you pick a solid color, it switches the dropdown to "solid". If you pick a gradient, it switches the dropdown to .. radial or linear or whatever we end up with.

It's an idea, I think it could use more refinement. The figma inspiration is good but a little complex still.

[ZebulanStanphill]

I think the theme palette colors should be shown above/before the custom color picker, since it's generally a good idea to stick to colors already in use when building websites.

[richtabor]

While the swatches box at the bottom is not a 1:1 with Theme Colors (you can't modify theme colors),

Now it'd be interesting if you could modify and save a theme-preferred color that's applied throughout the site upon saving it (based on it's color class).

[ZebulanStanphill]

@richtabor I think the system proposed in #19611 might actually allow for that, assuming I understand it correctly.

[ItsJonQ]

Heya @karmatosed + all!

I started working on this component, taking the same approach I did for the RangeControl update.

Below is a quick demo:

Note on design. I've added a "focus" border around the ColorControl. We don't have to go with this design. Although, I suggest we do something to visualize focus.

Still very early! I've just rendered the ColorPicker (as it is today), within the current Popover system. Positioning the ColorPicker like the renders in the mocks will most likely involve substantial work in the current Popover/Positioning system.

I'm not opposed to it! Just giving a heads up :).

[jasmussen]

Y'all are amazing. Digging that focus style, Q — question, should it be around the swatch only? Or to phrase it differently, what does the focus style look like if you set focus only in the input field to manually type in the value?

[gziolo]

Nice, I like that it's consolidated into one popover. The current implementation is very difficult to use when using the keyboard only so having only one space makes it all simpler. The same applies to the sighted users, as you can control everything from one place, use one of the preselected options and customize further. I really like it.

For the colors that come from the theme/site, we should change the internal HTML code used. As of today, those color buttons are implemented with buttons. It isn't the best experience for those who use screen readers because they aren't grouped. In addition, arrow key navigation isn't implemented so it might only confuse users. In the Navigation block, when I try to use arrow keys to change the color, the popover closes ...

Reakit has Radio group implemented: https://reakit.io/docs/radio/ It follows the WAI-ARIA practices: https://www.w3.org/TR/wai-aria-practices/#radiobutton

You can also explore some custom implementations but it might be more work.

[ItsJonQ]

@jasmussen Thanks for feedback :D

question, should it be around the swatch only? Or to phrase it differently, what does the focus style look like if you set focus only in the input field to manually type in the value

I'm not sure! I think that's something we need to design (cc'ing @karmatosed ) 🙌

The current implementation is very difficult to use when using the keyboard only so having only one space makes it all simpler

@gziolo Thanks for your thoughts as well! Yes, the current UI is quite difficult to use. Not only that... the code is quite difficult to work with. I feel like quite a bit of refactoring will need to be done to achieve the new experience

You can also explore some custom implementations but it might be more work

Yes! I'd love to :D

[ItsJonQ]

@karmatosed Update! I continued looking at this component today. I was breaking apart the pieces, seeing how they fit together to accommodate these new designs. I think the biggest challenge would maybe be the combined Solid/Gradient switching.

At the moment, the Gradient picker works "outside" the ColorPicker, triggering it when customizing a "Control Point". The code is written as such as well.

We may need to "invert" some of that "code" logic, to bring it inside, to create a Gradient color picker experience similar to that of, say, Figma:

Not blockers of course! Just observations from my digging ✌️

[ItsJonQ]

Update!! The initial Color picker I had showcased (above) may be included as part of this:

https://github.com/WordPress/gutenberg/pull/20061

[jasmussen]

The G2 branch is close now. Two separate branches have been merged into it, and the experience is just about ready for the first merge (of course with a bunch of followups to happen after that): https://github.com/WordPress/gutenberg/pull/19344

As I worked on that branch in the past few days, I realized that although there is something incredibly elegant in the unified Figma-esque color-picker (which I brought up myself), it does also lose a little bit of simplicity in what we have now. Observe:

Specifically, the new color picker prioritizes advanced control over picking between preset color and gradient swatches and seeing the impact. In this picker, hex codes and custom colors are primary, and swatches are secondary (inside the dialog).

I wonder if we can flip this on its head, and bring the benefits of the new design to the custom color picker dialog, while keeping the benefit of being able to quickly pick a spot color (which may be even more important so as to pick from the color palette provided by a theme in the global style system!):

Here's a mockup that restores the swatches as the first interaction:

Click "Custom", and you'd get the color picker you designed above. I wonder if it would be better for trying out a bunch of colors and gradients quickly, and delineating more clearly which colors the theme is born with, and which colors you manually type in.

[enriquesanchez]

There has been some additional color picker exploratory work done in https://github.com/WordPress/gutenberg/issues/18678, and @karmatosed kindly pointed out that we should merge our efforts.

I'm going to close that issue in favor of this one.

While separate issues, I'm glad to see what our intentions are very aligned. I'd like to highlight some explorations from @shaunandrews in https://github.com/WordPress/gutenberg/issues/18678#issuecomment-574735031m which I think are excellent.

Was just thinking about this yesterday and spent some time on a few variations. Here's one of my fav's:

I also explored having the hex/rgb/hsl input outside of the color picker:

Checkout the Figma to see a bunch of options: https://www.figma.com/file/O7epVG8iWfNiNzdSm5RNyd/Component-Color-Picker?node-id=0%3A1

And an attempt to bring what we currently have together with these awesome ideas, by yours truly:

And I very much agree with @jasmussen:

I wonder if we can flip this on its head, and bring the benefits of the new design to the custom color picker dialog, while keeping the benefit of being able to quickly pick a spot color

On https://github.com/WordPress/gutenberg/issues/18678#issuecomment-588566770 I suggested something similar:

I still think that the color palette should be just one-click away, instead of hidden inside the color picker. I expect that to be useful for the majority of users, who might not know what those color formats are.

[richtabor]

Couldn't we keep it simple within the sidebar, instead of surfacing the values/formats that are extraneous to apply color?

Super similar to Figma:

[jasmussen]

Love the treatment. But my realization was specifically around leveraging the theme defined swatches, and as soon as I see a hex code I think "one-off". Which there should be room for, but it feels like reusing swatches should be what to optimize for.

[ZebulanStanphill]

@jasmussen When a palette color is selected, the name of the color could be shown instead of a hex code.

[jasmussen]

When a palette color is selected, the name of the color could be shown instead of a hex code.

Could work! But is this enough to mentally form a connection in a users mind that this is a swatch that comes from the theme vs. this is a custom color I pick? I could see the circle treatment being good for swatches, and then using Tammie's rather nice square box treatment as a good interface for the custom picker treatment.

[mtias]

I like this direction. Figma is a great tool, but it's optimized for professionals that work with color regularly and systematically so we should use it as inspiration with caution.

[youknowriad]

What I liked about the original ideas here is that the current inspector controls are too crowded and having simple single "Background" "Text" controls make it very light. I also like the fact that "colors" and "gradients" are considered basically as the same thing;

So maybe, we could have a simple single input and when we click it we open a popover with the theme colors and gradients as first interaction with a "Custom" link to unfold the custom pickers?

[brentjett]

I would tend to agree that the original palette picker is nice...until you see two of them right next to each other. I like the "Pill" style or some version of a simple swatch in the sidebar and then opening up into a picker via a popover. MacOS follows this pattern system wide where there is only one system color picker panel, and when you switch between one "color well" to another, the same system panel simply switches to reflect the new value. I don't think that's an overly "Pro" kind of pattern.

MacOS System Color Picker

One of the issues with choosing colors is that depending on what you're starting with, and trying to get to, there's no perfect picker. Sometimes you want to take a base color and darken it without changing the hue/saturation. Sometimes you want to do a hue shift. Sometimes you're just scrubbing around until you find something good. And sometimes you just want that color you used before. Depending on your task, different picker layouts are better, hence why practically all modern design tools have multiple options. I'm pretty fond of Procreate's(iPad) color picker setup.

Procreate for Ipad Color Pickers

One of the things I'm liking in this discussion is the difference between selecting a Color and selecting a Fill. A property like border may only support color values but something like background can accept colors, linear gradients, radial gradients, images and multiples of those - a "Fill" (not svg fill). It might be helpful to distinguish between Color and Fill and pursue them as separate components. The simple picker has value, but so do the more precise expressions.

The other place my mind goes is how would you want a 3rd party to "Upgrade" the picker? Ultimately a 3rd party plugin is going to implement more advanced color picker scenarios, the question is will they do them well and in a way that doesn't hamper the experience for the simpler cases. If the component is too simple for every situation, they'll just replace it with their own, which won't be as accessible and won't be helpful to every user. Rather than that scenario, why not design a picker system that has a simple expression by default, but can accommodate multiple pickers being registered into it, so that there's a way for a 3rd party to upgrade the picker if they want without obliterating the good, simple option in the process.

Here's a sketch of mine. A simple menu would provide a place for multiple pickers to be accessed.

[ItsJonQ]

Hallooo!

Following up on this one real quick. I started revisiting the ColorPicker component today (not necessarily the design, but the internal code). This was driven mostly with my recent work on the Cover block and the Gradient tools.

For example, it would be great if the RGB input values weren't cut off in this UI:

😅

[ItsJonQ]

Updates! Continuing to refactor + improve the UI of the existing ColorPicker

I've consolidated the mode + controls. Mode switching use to be a button toggle (which I feel isn't very intuitive due to it's opaqueness). It is now a Select.

The value controls (RGBA) UI has been improved with grouping.

They are also powered by NumberControl, which gives them improved label rendering and drag controls.

Last bit of detail! The A (Alpha) value display is enhanced so that it maps to values like 50% rather than 0.5. Interfacing with % appears to be common amongst color tools.

[ItsJonQ]

Also improving a11y labels for the individual values. For example, the R input is labelled as red

[paaljoachim]

It seems like we can remove the "Needs Design Feedback" label here. As it feels like Jon @ItsJonQ is doing a lot of great work here. Is it ready for the "Needs Dev" label?

[ItsJonQ]

Haiii!

I jumped back into this space again to support the new Component System effort

After some tinkering, I've put together a prototype for gradient controls (both linear and radial):

I recorded a brief walkthrough here: https://www.loom.com/share/efdde62b184544fdaa19143f60e01b15

Link to prototype: https://magic-box.itsjonq.vercel.app/background-tools

These interactions extend the functionality we have in Gutenberg today. The best way I can put it is... they work like how you'd expect them to from tools like Photoshop, Illustrator, or Figma (which is what I used as inspiration).

---

Stop List

One new UI addition would be the collapsible "Stop" list:

This provides additional detail and control for each gradient stop (works for both linear and radial). The list is sorted based on "stop" value. So adjusting them would re-order the items

(Adjustments can be made in the list inputs or from the gradient bar the top)

Radial Position

Other new UI addition would be radial (x/y) position values:

This allows you to adjust where the radial circle would be positioned in the background.

---

ColorPicker

There's also been a lot of interaction enhancements to the ColorPicker - mostly focused on making it easier to see + adjust values.

---

None of these components/ideas are 100% complete. They're built with the G2 Components, which are currently being integrated into Gutenberg.

If you're curious about the source code, you can find it in this playground repo I have: https://github.com/ItsJonQ/magic-box

Note: It's very messy. It's just a prototyping area where I can throw things together and try things really quickly. If something viable emerges, I'm going to be bringing into the G2 Components / Gutenberg repo.

[mtias]

We've deployed many of these improvements already. Closing as done.