Proposal: Add a ColorPickerButton Control

[robloo]

Proposal: Add a ColorPickerButton Control

The color picker is a big help when using WinUI. However, it takes a lot of space. A common design practice is to preview the color in a small button. Pressing the button will open the color picker in a flyout for editing. There are lots of different implementations for this and Microsoft even provides an example here: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/color-picker#save-the-chosen-color

This concept should be standardized and pulled into WinUI itself for use in all applications. Additional features should be added such as sliders for all color channels and a color palette to select from.

I've already added this control in a PR on the WindowsCommunityToolkit. Once stabilized, I would like to bring it over to WinUI 3.0.

• [Feature] Add a Reimagined Color Picker
  #3363
• Add ColorPickerButton #3379

Summary

Add a color picker drop-down button as shown below (example). The name of this control was decided to be 'ColorPickerButton' (technically it should be ColorPicker while the existing one should be ColorCanvas) but some ideas are:

• ColorSwatchPicker
• ColorBox
• ColorPickerButton
• ColorPickerDropDown
• ColorDropDownButton
• ColorPickerDropDownButton (long I know)

The drop down button could look as below:

The button will show a preview of the selected color which also supports transparency on a checkered background. When the drop-down is opened, a color picker is shown in a flyout to change the selected color.

Spectrum	Palette	Channels

Rationale

• Standardize the common 'ColorPickerButton' design principle
• Save application screen space when choosing a color
• Provides an input control to use in forms
• Adds ability to modify a color using channel sliders (with colored slider backgrounds)
• Adds ability to select a color from a palette

Scope

Capability	Priority
Create a new 'ColorPickerButton'	Must
Support all color picker properties in the button	Must
Support preview of transparent colors on a checkered background	Must

[StephenLPeters]

@robloo is this achievable using a DropDownButton with colorPicker in the flyout? Seems like it shouldn't be too involved.

[robloo]

@StephenLPeters, You would think it could be implemented with a DropDownButton and a ColorPicker in a flyout -- and this would work if the implementation is done inside the application itself. However, the ColorPicker properties and methods need to be exposed by the new control. Therefore, it's better to inherit from ColorPicker and create the new control. Then re-implement the dropdownbutton in the template of the new control.

Edit: I suppose an alternative would be just expose the color picker reference as a property itself. That's not as good of a design in my option though. Either implementation won't be very difficult though.

[ranjeshj]

I'm having trouble justifying creating a separate control for this. Would it make sense to have this as a sample/control in the community toolkit ? @michael-hawker ?

[robloo]

@ranjeshj I understand some of your apprehension about creating and maintaining a control for this; however, I find this type of color input is used in several different scenarios. It is definitely filling a gap in WinUI and is something that historically has only been done by 3rd parties -- like the NumberBox.

The net benefit for Microsoft is more from a design standpoint than a technical one. Standardizing the Windows 10 UI is important and this control would align with that goal. This control is also not technically prohibitive to implement -- it would be quite simple. Of course you would also be filling a gap in WinUI control library and making application development simpler.

Microsoft added the DropDownButton itself for similar reasons I would think. It's a relatively simple control to implement -- but it's one used in so many places it makes sense to standardize and pull into the framework.

[ranjeshj]

@robloo Thank you for elaborating. I can see the consistency argument. Thinking about this a bit more, this is likely more of a pattern where we have a picker (some input control that is relatively large layout wise) and we want to show the selected value after it has been picked. We have Date/Time/Calendar pickers for example. @chigy as FYI

[mdtauk]

This control of it is approved, would work well for a future WinUI ribbon control.

It could also be aligned with the horizontal mode issue, and the idea of a Swatch mode for the colour picker

[robloo]

It could also be aligned with the horizontal mode issue, and the idea of a Swatch mode for the colour picker

Yes, I agree and had that in mind as well. Inheriting from ColorPicker would keep all future changes to ColorPicker included in this control too.

It's also too bad the ColorPicker name is already used as this proposal more closely aligns with a picker. The existing ColorPicker is more like a ColorView or ColorPanel.

[mdtauk]

ColorSwatchDropDownPicker

ColorSwatchPicker

[robloo]

I like ColorSwatchPicker -- good idea

[niels9001]

Would be really nice to have this, either in the Community Toolkit or WinUI.

We have created something similar in the PowerToys settings app:

[robloo]

@ranjeshj @StephenLPeters @chigy Is there any merit to pursing this idea here in WinUI? The usability benefits speak for themselves I think. A lot of apps use a concept along these lines. It is also a standard 'picker' control now and conceptually fits in with the others such as DatePicker. I've never understood why the existing ColorPicker was named like it was unless there was always a plan to re-template it?

Here is the complete proposal:

[robloo]

Quick update: This is being released in the Windows Community Toolkit version 7.0. The hope is to gain plenty of feedback with the new designs and then to add the control to WinUI at a later date.

[FireCubeStudios]

@robloo have you thought about also including a onscreen (app) color picker like the eyedropper control from windows community toolkit?

[mdtauk]

I would like to see this control make its way to the WinUI kit, and see it as a layout option for the default control, as well as the flyout experience.

With WinUI 3 - all flyouts will need to be updated to support Compact Density IMO, so any pain points like text boxes, and new light dismiss behaviours, can be implemented then.

The Eyedropper could be a 4th Tab/Pivot, and could make use of the EyeDropper from the community toolkit to bring a consistent approach, code sharing, and a useful feature.

[michael-hawker]

@mdtauk the ColorPicker/Button control from @robloo should be in the latest Toolkit Preview if you want to check it out. Would love any feedback before we ship it.

[robloo]

@FireCubeStudios Yes, the thought crossed my mind to add the existing WCT Eyedropper. I decided against it mostly due to time constraints as well as:

• Some debate where the button should go. It seems most relevant in the spectrum tab. However, could be used anywhere so needs to be visible from all tabs. This means by the preview selected color at the bottom is best. However, adding it there throws off the symmetry and visual design a bit. I couldn't think of a better option but wasn't quite happy with it. (There would be an option to show/hide it as well)
• Could cause some issues with keeping the flyout open. As soon as the eyedropper control is used focus would go away and the colorpickerbutton flyout would close. Some tricks would be needed to get around this which is never as straightforward as I would like.

[mdtauk]

@FireCubeStudios Yes, the thought crossed my mind to add the existing WCT Eyedropper. I decided against it mostly due to time constraints as well as:

• Some debate where the button should go. It seems most relevant in the spectrum tab. However, could be used anywhere so needs to be visible from all tabs. This means by the preview selected color at the bottom is best. However, adding it there throws off the symmetry and visual design a bit. I couldn't think of a better option but wasn't quite happy with it. (There would be an option to show/hide it as well)
• Could cause some issues with keeping the flyout open. As soon as the eyedropper control is used focus would go away and the colorpickerbutton flyout would close. Some tricks would be needed to get around this which is never as straightforward as I would like.

You could add a 4th pivot, and show the most recent colours picked. Tapping the colour in this view, could populate the colour picker in the spectrum tab, to allow picking the shades/tones.

[robloo]

@mdtauk The future plan for a recent color palette is to keep it in the existing palette tab. Section headings would be introduced and then vertical scrolling if needed. So there would be a 'Standard Colors' heading then the existing palette and below/above it a 'Recent Colors' heading with N number of recent colors which could include an eyedropper button next to it. Recent colors would indroduce persistence and I havnt thought of a good way to do that yet.

Edit: I should add that an eyedropper can be applicable from any tab so assigning it to one may not be best. In addition each tab can be shown/hidden independently.

[michael-hawker]

@robloo if you check out the latest PowerToys update their recent color list is an interesting model to check out to compare against:

[robloo]

@michael-hawker Ah yes, I had forgotten about that and do like that design better. @niels9001 (author of the ColorPickerUX PowerToys control) was also the one who suggested the accent colors next to the preview color as well.

This type of design would work great below the preview color I think:

• Adds the recent colors list in a fixed-size way (scrolls as needed)
• Adds the Eyedropper in a good/logical location
• Keeps the recent colors and eyedropper visible for all tabs/views

@niels9001 Any concerns if we add your idea here to the ColorPickerButton? (You probably suggested it originally but it wasn't a priority for v1). I would probably only make it horizontal instead of vertical -- otherwise it looks great. Any lesson's learned though?

Separately, still not sure how to maintain a recent colors list in a framework control across app sessions. Maybe that isn't a priority and recent colors could be cleared when the app was closed (the list would look strange being empty though).

[robloo]

This control is in the community toolkit now (with a pending update PR that never got reviewed/merged...)

So closing it at there is no change Microsoft ever moves on it.