Mac Brush Editor

[ermau]

Depends on #97

• [x] Core
• Editor:
  • [x] Design
    • [x] Material color selector
  • [ ] Localized
  • Behavior:
    • [ ] Keyboard control
    • [ ] Accessibility
    • [ ] Selection
  • Theming:
    • [ ] Light themed
    • [ ] Dark themed
    • [ ] High contrast
  • States:
    • [ ] Error state
    • [ ] Bound state
    • [ ] Conflict state
    • [ ] Pending state

[vancura]

Simple color picker

Simple color picker is used only when no special features are needed, i.e., for quick selection of colors.

It would be good to have a few new features:

• bottom row with recently used colors,
• (...) icon to show the system color picker.

These features are also used in the more advanced color picker below.

Color menu

A similar approach to Xcode has:

Here we show a list of named colors, and a list of recently used colors, similar to the simple color picker above. The Other... menu item opens the system color picker.

Android Material Design color picker

Grouped colors color picker

No properties selected

This is the usual state of the property pad – no properties are selected, hence the color picker is visible but disabled. Optionally we can hide it until there's a need for it. This is the disabled/semitransparent state (opacity = 33%).

A color property is selected

The advanced color picker gets enabled, and it's possible to pick the color. The currently selected property row is blue (or gray, depending on system control tint), with white text and icons (standard Apple treatment). The rest of color properties from the group are slightly blue (#D8E2F3) or gray in graphite system control tint (#f2f2f2), to show that they belong to the same group as the currently selected property.

Color picker toolbar contains two primary view buttons:

• Editor (color picker),
• Color Resources (a list of color resources).

The secondary toolbar contains brush switches:

• none,
• solid,
• gradient,
• image,
• resource.

These brushes are apparently not used on iOS (this mockup displays iOS Designer properties), but they need to be designed. Gradient, image and resource pickers will be designed later in this issue.

List of color resources

Here we display a list of color resources (or resources in general), if available.

[ermau]

@vancura a few questions:

1. Are the recent colors/most used meant to be in the current session or over multiple sessions?
2. The Material picker doesn't seem integrated, just off on its own. Does it make sense to have this as one of the brush switches?
3. The drop down when not in a grouped state is just a list of color names, how do we get to the brush switcher from this point?

This is the usual state of the property pad – no properties are selected, hence the color picker is visible but disabled. Optionally we can hide it until there's a need for it. This is the disabled/semitransparent state (opacity = 33%).

A third option is to just always have a property in the group selected so it never has a reason to hide/go transparent. It seems unlikely that people will unselect the property once they're done with it. This or going semitransparent is fine with me.

[bleroy]

@ermau Material is not so much a separate brush type as it is a different way to pick a color. Maybe we should have a way in the editor API to specify preferences in input methods (and potentially not just for colors). I would expect that when working on an Android project, I would be presented with Material front and foremost, with the current color picker as an "advanced" option, whereas a WPF project would put the current one first. We could get a coarse way of doing that with different types coming into the editor, but that could make for a confusing API, or we could have a more generic configuration API. That's probably a separate discussion to have.

@vancura one thing that is relatively hidden in the Windows solid color editor is the drop-down when you click on one of the color component labels, that gives you access to HSL, HSB, CYMK spaces in addition to the RGB one. On the mac, we have the opportunity to give that a better and more discoverable UI.

Another thing that's missing in the above design is the color space UI.

[ermau]

Material is not so much a separate brush type as it is a different way to pick a color.

True, but that's not the only way to look at it. The selectors are simply different ways of manipulating the brush, Material is just another way. As presented above it's as though it's an entirely different property type, which shouldn't be the case.

Maybe we should have a way in the editor API to specify preferences in input methods (and potentially not just for colors). I would expect that when working on an Android project, I would be presented with Material front and foremost, with the current color picker as an "advanced" option, whereas a WPF project would put the current one first. We could get a coarse way of doing that with different types coming into the editor, but that could make for a confusing API, or we could have a more generic configuration API.

This is all tangential; We will show the material picker only on android and in an appropriate place. We only need to figure out where that is.

[bleroy]

And we also need to figure out how the client code is going to tell the property panel that it is Android, but yes, tangential.

[vancura]

Are the recent colors/most used meant to be in the current session or over multiple sessions?

Good question, @ermau. It needs to be saved, that's for sure. But is it meant to be a system-wide recent list, across all projects, or let's say a color palette per a project? It's more a thing of implementation, and both ways would be good. But we definitely need to save it for the next launch. There would be no reason for the recent list if it were wiped on every VSMac/VS/whatever launch.

The Material picker doesn't seem integrated, just off on its own. Does it make sense to have this as one of the brush switches?

Android Designer has these three buttons:

1. the (...) button is the Resource Browser,
2. the square is a standard color picker,
3. the palette button shows this Android Material palette popover.

So basically you have two ways of selecting the color (not talking about Resource Browser which is pretty standard).

I thought we could use a similar principle, a color box similar to what iOS has and a secondary button for the Material palette popover. I'll design both now.

The inline Material palette, similar to the inline color picker, makes total sense and I'll draw it too.

The drop down when not in a grouped state is just a list of color names, how do we get to the brush switcher from this point?

I thought you'd click the Editor toolbar button. Then you'd get back to the toolbar without filter textfield, but with the secondary switcher. That would work for solid colors only, but is there a chance we'd display a list of images, gradients and resources in the list too (where it's possible, UWP/WPF)?

A third option is to just always have a property in the group selected so it never has a reason to hide/go transparent. It seems unlikely that people will unselect the property once they're done with it. This or going semitransparent is fine with me.

That would be confusing, I am afraid. I thought the selected row/property is selected only when the user navigates there (via mouse or keyboard). An auto-selected property on start would be misleading.

One thing that is relatively hidden in the Windows solid color editor is the drop-down when you click on one of the color component labels, that gives you access to HSL, HSB, CYMK spaces in addition to the RGB one. On the mac, we have the opportunity to give that a better and more discoverable UI. Another thing that's missing in the above design is the color space UI.

I'll design all of them now.

[vancura]

Update on inactive inline color picker (no color property from the grouped list is selected):

Selected rings are hidden, that's the only change. There's no reason to show them since they can't be selected or moved.

[vancura]

So basically you have two ways of selecting the color (not talking about Resource Browser which is pretty standard). I thought we could use a similar principle, a color box similar to what iOS has and a secondary button for the Material palette popover. I'll design both now.

[ermau]

Good question, @ermau. It needs to be saved, that's for sure. But is it meant to be a system-wide recent list, across all projects, or let's say a color palette per a project? It's more a thing of implementation, and both ways would be good. But we definitely need to save it for the next launch. There would be no reason for the recent list if it were wiped on every VSMac/VS/whatever launch.

Ok, this sounds good, we're just going to have to punt on it for now. We can add it later.

I thought you'd click the Editor toolbar button. Then you'd get back to the toolbar without filter textfield, but with the secondary switcher. That would work for solid colors only, but is there a chance we'd display a list of images, gradients and resources in the list too (where it's possible, UWP/WPF)?

The grouped version of the color property editor really shouldn't differ from the inline element. If the grouped shows access to images, gradients and resources, why wouldn't the inline one? WPF, Forms (via Inspector) and Android would all make use of this.

That would be confusing, I am afraid. I thought the selected row/property is selected only when the user navigates there (via mouse or keyboard). An auto-selected property on start would be misleading.

Keep in mind that the groups of selectable properties aren't actually specific to colors, it's meant to be a reusable component (see #97 and "Group editor" in the doc). Can you elaborate on how this would be misleading?

[vancura]

The grouped version of the color property editor really shouldn't differ from the inline element. If the grouped shows access to images, gradients and resources, why wouldn't the inline one? WPF, Forms (via Inspector) and Android would all make use of this.

You mean the popover version, right? :)

I am just afraid we shouldn't overuse the popover version. It's always bad when popovers are overflowing with features, it's a tricky widget, and difficult to control. That's my primary reason why I designed it slim.

Can you elaborate on how this would be misleading?

Imagine you open Designer, select a widget on canvas and the immediatelly active property would be one of the colors. I think it's better to let the user select what they want to change, so we'd start with no property selected (while a widget from canvas is selected).

[ermau]

You mean the popover version, right? :) I am just afraid we shouldn't overuse the popover version. It's always bad when popovers are overflowing with features, it's a tricky widget, and difficult to control. That's my primary reason why I designed it slim.

The choice isn't up to us though, that's why it's important that they not differ. The inline/popup version appears when we're in arrange by name mode. The grouped appears when they are in arrange by category.

[vancura]

The inline Material palette, similar to the inline color picker, makes total sense and I'll draw it too.

Unselected state:

Standard picker selected (see the changed toolbar, too):

Inline Material color palette:

That also means the Material color palette could be unselected too:

[vancura]

One thing that is relatively hidden in the Windows solid color editor is the drop-down when you click on one of the color component labels, that gives you access to HSL, HSB, CYMK spaces in addition to the RGB one. On the mac, we have the opportunity to give that a better and more discoverable UI.

What about this?

I don't want to hide it behind a menu of any sort since this whole picker needs to work in a popover too. Imagine showing a contextual menu out of a popover, that would be a massive UX fail, not talking about problems what popover/menu is active and how to handle them.

[ermau]

What about this?

Perfect.

[bleroy]

The HSB/HSL/RGB/CMYK is great, thanks.

I don't want to hide it behind a menu of any sort since this whole picker needs to work in a popover too. Imagine showing a contextual menu out of a popover, that would be a massive UX fail, not talking about problems what popover/menu is active and how to handle them.

And yet that is exactly what we have in Windows (although it doesn't have any more problems than your garden variety hierarchical menu). Should we consider improving on the VS design when it's clearly wrong?

[vancura]

And yet that is exactly what we have in Windows (although it doesn't have any more problems than your garden variety hierarchical menu). Should we consider improving on the VS design when it's clearly wrong?

Yes, please. But case by case, to be honest, there's nearly everything that's bad in terms of UX in VS :)

[vancura]

Inline No Brush Editor

Inline Gradient Brush Editor

[ermau]

@vancura we can probably just hide editor/color resources on "no brush", but 👍

[vancura]

@ermau Updated: https://github.com/xamarin/Xamarin.PropertyEditing/issues/137#issuecomment-361321486

[vancura]

Dark themes of what makes sense to design:

[lewing]

@vancura remind me where I can get the icon assets and possibly the paths for the gradient tabs

[vancura]

@lewing The icons are at https://github.com/xamarin/icons/tree/master/property-pad (Figma source if you need it). But what paths do you mean?

[lewing]

@vancura I was thinking of when I asked. Not exactly complicated to reproduce just checking if I could extract them.

[vancura]

You'll need to extract that from Figma, or I can render two images for you: one for masking the color, and the second one with a stroke to overlay over it. Although I think it would be safer to render that with code, I might be wrong. So, images?