Microsoft-ui-xaml: Proposal: ColorPicker horizontal mode

[chingucoding]

AP spec proposal: https://github.com/microsoft/microsoft-ui-xaml-specs/pull/53

Proposal: ColorPicker horizontal mode

Summary

The current layout of the ColorPicker is mainly designed to grow in height. However in some cases, it may be better to have the ColorPicker to be wide, not high.

Rationale

• In cases were height is limited, the ColorPicker is problematic to use
• Retemplating the whole control would not be that simple, since we need to completely reorganize the layout
• A horizontal ColorPicker may be easier to integrate due to the fact, that most content and screens are wide

Scope

| Capability | Priority |
| :---------- | :------- |
| Developers have the possibilities to use ColorPickers where height is very limited, but width is not | Must |
| The ColorPicker has a display mode, similiar to NavigationView where the developer can specify wether it should layout vertically or horizontally | Should |

Important Notes

Open Questions

Examples

A standard ColorPicker using Orientation "Vertical"

<muxc:ColorPicker IsAlphaEnabled="True" Orientation="Vertical"/>

Standard ColorPicker using Orientation "Horizontal"

<muxc:ColorPicker IsAlphaEnabled="True" Orientation="Horizontal"/>

Remarks

API Notes

Orientation: The orientation determining wether to display horizontally or vertically.

API Details

c# [webhosthidden] unsealed runtimeclass ColorPicker { /// Gets or sets the DisplayMode of the ColorPicker Windows.UI.Xaml.Controls.Orientation Orientation = Windows.UI.Xaml.Controls.Orientation.Vertical; }

[mdtauk]

Maybe the control should be made responsive, so it can re-arrange to fit the space available to it?

Win32:

UWP:

Adobe:

[chingucoding]

Yes that would definitely be an improvement. Maybe this could also be a setting, just like the NavigationView handles it.

[robloo]

It would also be great if we could re-arrange the RGB/HSV entry text boxes themselves into a horizontal layout. A layout like what is shown below would be ideal to reduce space. That said, I'm pretty sure this was done due to localized text taking up a lot more space -- would be great to have it as an option though.

[jevansaks]

@chingucoding (or anyone else) this seems reasonable to us. The next step would be to propose an API for it and go through the API spec process. In this case it should be as simple as making a markdown file from this template and putting out a PR. Once that's approved then we can greenlight this for implementation.

[mdtauk]

Does something like this make any sense @chingucoding ?

NavigationView.Arrangement = Arrangement.Vertical

• Arrangement.Vertical
• Arrangement.VerticalCompact
• Arrangement.Horizontal
• Arrangement.HorizontalCompact

[chingucoding]

Does something like this make any sense @chingucoding ?

NavigationView.Arrangement = Arrangement.Vertical

• Arrangement.Vertical
• Arrangement.VerticalCompact
• Arrangement.Horizontal
• Arrangement.HorizontalCompact

Something like this would make sense. However what is "Compact" in this case? There is already a way to achieve compact sizing. Also there should be an "Auto" mode shouldn't it?

[mdtauk]

I would say @robloo 's layout could be compact, maybe "inline" may be better to avoid confusion with the Compact Density.

[chingucoding]

I think this "inline" mode won't work as some color translations can get lengthy and might overflow. For example: "Xanh dương" is blue in vietnamese. How should this be handled? Should the ColorPicker get wider even though our intent is to save space?

[mdtauk]

I think this "inline" mode won't work as some color translations can get lengthy and might overflow. For example: "Xanh dương" is blue in vietnamese. How should this be handled? Should the ColorPicker get wider even though our intent is to save space?

Inline does not necessarily equate to less space. It is more a declaration of how the constituent parts of the control arrange themselves.

[chingucoding]

Inline does not necessarily equate to less space. It is more a declaration of how the constituent parts of the control arrange themselves.

Maybe having this as separate option, such as "UseInlineLabels" would be better than having that built into the DisplayMode. If this would be something that you would think that would be a useful addition, I will be happy to add that to the API spec :)

I have also created an API spec PR over at microsoft/microsoft-ui-xaml-specs, FYI @jevansaks

[mdtauk]

Here is my thinking for both the Orientation and the Mode of the colour picker

[shaheedmalik]

Here is my thinking for both the Orientation and the Mode of the colour picker

Maybe instead of having different ones just have one that you can resize and is fluid.
A horizontal one might be better in landscape mode and a vertical might be better in portrait mode.
Maybe you can set the initial orientation and then it can fluidly adapt to the screen positioning.

That way there would be some consistency.

[chingucoding]

Here is my thinking for both the Orientation and the Mode of the colour picker

Maybe instead of having different ones just have one that you can resize and is fluid.
A horizontal one might be better in landscape mode and a vertical might be better in portrait mode.
Maybe you can set the initial orientation and then it can fluidly adapt to the screen positioning.

That way there would be some consistency.

I can see why that may be useful however this "Auto" may a quite complicated: Which orientation is preferred? What if there is not enough space in either orientation?

In addition to this, the easiest way would be to let developers choose which orientation is appropriate for their use case.

[Felix-Dev]

I would leave that up to the developer. With adaptive triggers, for example, the developer can easily change the Orientation depending on the window size whenever they want to.

[shaheedmalik]

I can see why that may be useful however this "Auto" may a quite complicated: Which orientation is preferred? What if there is not enough space in either orientation?

In addition to this, the easiest way would be to let developers choose which orientation is appropriate for their use case.

I was thinking the developer sets the size and have the control wrap around based on the dimensions.
500x240 might be horizontal while 240x500 would be vertical for example. Then the user can freely resize it based on preference.

Maybe have an initial orientation set like horizontal or vertical but then have it still fluid?

[robloo]

Concerning putting all components on the same horizontal line:

I thought of three possibilities to fix the potential localized text length issue:

1. The text could have trimming...
2. The control could resize itself (I realize that's not ideal at all)
3. Just use color component abbreviations like Photoshop(r) has: just 'R', 'G', 'B'

I like #3 the best and would argue if the user is editing the components directly they already know what they are doing.

[chingucoding]

I thought of three possibilities to fix the potential localized text length issue:

1. The text could have trimming...
2. The control could resize itself (I realize that's not ideal at all)
3. Just use color component abbreviations like Photoshop(r) has: just 'R', 'G', 'B'

I like #3 the best and would argue if the user is editing the components directly they already know what they are doing.

I agree, that the second option is not optimal. Maybe #3 is the best solution. I think this should be an option for the developer to choose, what is suitable for them.

[mdtauk]

I thought of three possibilities to fix the potential localized text length issue:

1. The text could have trimming...
2. The control could resize itself (I realize that's not ideal at all)
3. Just use color component abbreviations like Photoshop(r) has: just 'R', 'G', 'B'

I like #3 the best and would argue if the user is editing the components directly they already know what they are doing.

I agree, that the second option is not optimal. Maybe #3 is the best solution. I think this should be an option for the developer to choose, what is suitable for them.

Things like HSV or HSB, and even CMYK - could use the Initials, but if this is the case, could the full word still appear with a Tooltip when hovering over the TextBox or the Header?

And is there any thought about using NumberBoxes for these controls?

[chingucoding]

And is there any thought about using NumberBoxes for these controls?

Yes, that is a brilliant idea! The R,G,B and Opacity textbox should be replaced with NumberBoxes.

[robloo]

@mdtauk, @chingucoding Using the NumberBox in the ColorPicker was one of the original design goals.

https://github.com/microsoft/microsoft-ui-xaml/issues/483#issuecomment-500140203

one example is WinUI's own ColorPicker control. It includes a hexadecimal input box. It also includes a number of other number entry TextBoxes. It might be worth looking into the possibility of updating ColorPicker to use the new NumberBox control as a way of validating the new control. If NumberBox can simplify the current implementation of ColorPicker, that would be a win.

I know @SavoySchuler discussed this at Microsoft internally:

https://github.com/microsoft/microsoft-ui-xaml/issues/483#issuecomment-500618794

As you mentioned at the water cooler this morning, being able to removed a lot of code behind from ColorPicker by replacing its instances of TextBox + local validation logic with NumberBox could be a win in its own right.

[mdtauk]

Good memory recall @robloo

If the Suffix/Prefix feature for the TextBox is accepted #784 They could be used to further minify the ColorPicker

[robloo]

@mdtauk I really, really like that design. I was also thinking of putting the abbreviations next to the text boxes but adding as a prefix like (especially if TextBox gets that implemented) would take it to a whole new level!

As you stated earlier, that could be the VerticalCompact display mode as well. We could theoretically keep the standard Vertical option if people wanted it.

[chingucoding]

@kikisaints @ranjeshj What would be the next steps for this proposal? 😅
Is this good to go and can be implemented? If so I would be happy to do that.

[ranjeshj]

Thanks for the great discussion. @chingucoding can you update the proposal text at the top with the proposed API (and some mock screenshots)? @kikisaints @chigy If this design is good with you, we can start a spec PR.

[chingucoding]

I've updated the proposal and also added a link the currently running API review PR which you can find here: https://github.com/microsoft/microsoft-ui-xaml-specs/pull/53

[chigy]

@chingucoding , to be clear, you are only proposing the horizontal layout not the swatches that was mentioned in the middle of the discussion? In other words, what I see in the proposal up top is what you are proposing, right?

[mdtauk]

@chingucoding , to be clear, you are only proposing the horizontal layout not the swatches that was mentioned in the middle of the discussion? In other words, what I see in the proposal up top is what you are proposing, right?

I think it was decided to separate the swatches as a separate proposal. So only an option to layout the ColorPicker control in the current Vertical layout, or a new Horizontal layout.

[chingucoding]

@chigy Yes exactly, only the horizontal mode is in this proposal. The swatches live in another proposal: https://github.com/microsoft/microsoft-ui-xaml/issues/1659

[niels9001]

Not sure if this is the right issue since there are a couple around the ColorPicker control.

In the PowerToys settings application the use is able to set 3 different colors. We now have 3 colorpickers, which take a LOT of space and it's actually not really glanceable to see what color is selected.

We came up with the following solution, using a dropdown button with a colorpicker in the flyout:

Works really well! Saves space and the selected colors are very easy to identify.

My proposal would be for this issue: can we have a minimized/compact/selected color state that will open up the colorpicker?

[chingucoding]

I am not sure if I understand your request correctly @niels9001 .

So you want a compact state which shows a color or a very small layout that upon invoking opens the full color picker?

In that case I think someone already asked about this (or even create a proposal for this), but the WinUI team decided that it currently is not really "worth" it, since it is fairly easy to integrate a colorpicker with a DropDownButton or SplitButton.

[robloo]

@niels9001 This is a duplicate of https://github.com/microsoft/microsoft-ui-xaml/issues/2309 "Add a ColorSwatchPicker" control. Could you please duplicate your comment on that issue? I also think this is an important control to add to WinUI.

[niels9001]

@chingucoding Exactly. I can imagine this might beyond the control.

@robloo Ah yes, I see now that there was already a concept that does the exact same thing. Duplicate :)

[niels9001]

With iOS 14, Apple released a new inline ColorPicker flyout:

More info here: https://developer.apple.com/videos/play/wwdc2020/10205/
I like how everyone is laid out: spectrum, grid view, sliders and the swatches.

[mdtauk]

With iOS 14, Apple released a new inline ColorPicker flyout:

More info here: https://developer.apple.com/videos/play/wwdc2020/10205/
I like how everyone is laid out: spectrum, grid view, sliders and the swatches.

It is good to look at how others approach the same design problem - the inline/flyout ColorPicker is a different proposal though #2309 , and this seems more like a rethink of how to design the entire ColorPicker, rather than adding Horizontal arrangements for the control.

[niels9001]

Is it though? The iOS colorpicker shows how they are handling different modes and stuff like swatches.

To me it's confusing how we are tracking UX/layout improvements in two separate topics. Adding swatches will have (major) impact on decisions made on the layout and this issue. And vice versa.

In my opinion it would be good to come up with 1 proposal/spec where we tackle both horizontal mode and the swatches (basically redesigning the entire thing). Discuss and design the layout/UX first (taking into consideration stuff like color swatches) and then break out into issues to add the actions. If we'd list all the things we think should be added or improved to the ColorPicker control, we can design a proposal to validate against that.

[mdtauk]

Is it though? The iOS colorpicker shows how they are handling different modes and stuff like swatches.

To me it's confusing how we are tracking UX/layout improvements in two separate topics. Adding swatches will have (major) impact on decisions made on the layout and this issue. And vice versa.

In my opinion it would be good to come up with 1 proposal/spec where we tackle both horizontal mode and the swatches (basically redesigning the entire thing). Discuss and design the layout/UX first (taking into consideration stuff like color swatches) and then break out into issues to add the actions. If we'd list all the things we think should be added or improved to the ColorPicker control, we can design a proposal to validate against that.

Well it did start as a more all encompassing topic, but it was suggested that the asks be broken out into separate issues.

I am impatient, and I would like to see the whole control re-thought, with support for adaptive layouts to fit the panel its placed in, as well as flyout modes, and the additional swatches, and colour lists. The PowerToys color picker could benefit from this, and there is still a disparity with the "better" layouts used by Fluent UI.

But Microsoft moves at its own pace it seems, especially with UI changes.

[robloo]

First, there is another good idea in the Apple control. We could separate numerical input entirely into a 3rd tab and add sliders. The tabs would be:

1. Spectrum to visually select a color
2. Swatches to select a pre-defined color
3. Components to create a color using numerical component values

This design would also make the control relatively 'square-shaped' so there may be little need for adaptive layouts like horizontal/vertical -- it wold also be perfect to place in a flyout.

@mdtauk, I have an idea that has been used for other controls such as the TabView. How about we implement all of these changes in the Windows Community Toolkit? We could conceivably make a brand new control there very quickly. Once everything has been worked out it would allow Microsoft to accept these changes in WinUI more quickly.

I would be willing to write the control in C# for the Community Toolkit. I need something like this for my existing apps. Long term I would like to bring this to Avalonia as well and that would be a great first step.

Main improvements:

1. Adding the 3 tabs including swatches (With any adaptive layout still needed (horizontal, vertical))
2. Changing numerical component values can be done with a slider as well as NumberBox
3. Implement the control as a flyout button

Strategy:

1. Get the go-ahead from michael-hawker, I'll file an issue over there shortly
2. Work on changes in the Windows Community Toolkip repo (robloo develops, mdtauk supports designs)
3. A few rounds of community feedback and bugfixes to stabilize the new control
4. Create a very clear WinUI proposal based on everything learned in the toolkit -- get it accepted
5. Port the control over to WinUI (chingucoding could probably do that although I don't want to volunteer him)
6. Done! (I will probably port to Avalonia as well)

[robloo]

I created the issue on the Community Toolkit tracker: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3363. Would like everyone's comments.