WordPress.org

Make WordPress Core

Opened 22 months ago

Closed 18 months ago

Last modified 17 months ago

#21206 closed task (blessed) (fixed)

Replace Farbtastic color picker

Reported by: lessbloat Owned by: nacin
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: UI Keywords: has-patch needs-docs needs-codex
Focuses: Cc:

Description

In our user testing thus far, 3 out of 3 users struggled with the current Farbtastic color picker. I took a stab at replacing it with miniColors.

Attachments (27)

colors.png (12.2 KB) - added by lessbloat 22 months ago.
Only image used in 21206.diff
21206.diff (33.0 KB) - added by lessbloat 22 months ago.
mini-colors-in-action.jpg (40.4 KB) - added by lessbloat 22 months ago.
Screen of what it looks like
iris-picker.diff (27.6 KB) - added by mattwiebe 20 months ago.
iris-picker.2.diff (27.6 KB) - added by mattwiebe 20 months ago.
twenty-eleven-page.png (45.2 KB) - added by downstairsdev 20 months ago.
Twenty Eleven Options page
iris-picker.3.diff (29.4 KB) - added by lessbloat 20 months ago.
iris-twentyeleven.diff (10.2 KB) - added by downstairsdev 20 months ago.
Patches the Twenty Eleven theme (and include Background iris-2.diff)
iris-picker-4.diff (40.9 KB) - added by lessbloat 20 months ago.
iris-picker-5.diff (17.8 KB) - added by mattwiebe 20 months ago.
iris-picker-6.diff (42.2 KB) - added by mattwiebe 20 months ago.
iris-picker-7.diff (42.2 KB) - added by lessbloat 20 months ago.
iris-picker-8.diff (43.4 KB) - added by mattwiebe 20 months ago.
iris-picker-9.diff (44.5 KB) - added by mattwiebe 19 months ago.
iris-picker-10.diff (45.8 KB) - added by mattwiebe 19 months ago.
iris-picker-11.diff (45.9 KB) - added by mattwiebe 19 months ago.
iris-picker-12.diff (37.8 KB) - added by mattwiebe 19 months ago.
customizer-layout.diff (1.5 KB) - added by mattwiebe 19 months ago.
Fix the color picker layout in the customizer. This was missed in r22030
iris-picker-13.diff (44.0 KB) - added by mattwiebe 19 months ago.
color-picker.js.patch (643 bytes) - added by dgwyer 18 months ago.
iris-picker-14.diff (44.5 KB) - added by dgwyer 18 months ago.
iris-picker-15.diff (44.8 KB) - added by lessbloat 18 months ago.
Screen Shot 2012-11-05 at 12.49.16 PM.png (38.8 KB) - added by ryan 18 months ago.
Where's my rainbow? With iris-picker-15.diff after clicking Default and then clicking around the left side of the picker.
iris-picker-16.diff (40.9 KB) - added by mattwiebe 18 months ago.
screenshot.iris-picker-16.png (32.2 KB) - added by ocean90 18 months ago.
iris-picker-17.diff (41.2 KB) - added by mattwiebe 18 months ago.
rainbow stripe in hue strip
iris-picker-18.diff (41.9 KB) - added by mattwiebe 18 months ago.

Download all attachments as: .zip

Change History (120)

lessbloat22 months ago

Only image used in 21206.diff

lessbloat22 months ago

lessbloat22 months ago

Screen of what it looks like

comment:1 scribu22 months ago

Shiny. Related: #19616

comment:2 Ipstenu22 months ago

Oh yes, that is way better. One click, it's in and it's done.

comment:3 saracannon22 months ago

  • Cc sararcannon@… added

+1

comment:4 follow-up: Bueltge22 months ago

  • Cc frank@… added

It is the miniColor the last word or give it an chance for the colopicker of wp.com, see http://en.blog.wordpress.com/2012/07/11/go-ahead-add-a-splash-of-color/
It's fine, when it use the in plugins or themes, that I used this onw for customer and us an lib form the core.

Last edited 22 months ago by Bueltge (previous) (diff)

comment:5 in reply to: ↑ 4 ; follow-up: lessbloat22 months ago

  • Summary changed from Replace Farbtastic color picker with miniColor to Replace Farbtastic color picker with ???...

Replying to Bueltge:

It is the miniColor the last word

Nope. It was simply a proposal (I've changed the title of this ticket to adjust accordingly). Ultimately, we should pick the solution that's best for users. In the end, I'd like to run some users through both miniColor and the new WP.com colors feature, and see which one performs best.

comment:6 in reply to: ↑ 5 helenyhou22 months ago

In addition to testing, whatever the choice is needs to be just as usable on the developer end and be a real tool. See IRC discussion with koopersmith.

Some of the various color pickers that are out there:

comment:7 mattwiebe21 months ago

  • Cc matt@… added

Howdy folks! When developing Custom Colors on WordPress.com, we built our own color picker because we basically hated every single one in existence. It's called Iris.

Three things about Iris that make it stand out:

  1. It uses CSS3 Gradients, so it looks awesome on a retina display. This also makes it infinitely flexible for sizing.
  2. The UI and color calculations are in separate libraries (but bundled together by default).
  3. The controls are all built on jQuery UI, so throwing jQuery UI Touch Punch gives us touch support for free.

See it: http://automattic.github.com/Iris/

The documentation is pretty much non-existent right now, but it's on the way. It also needs some UI iterations to provide, for example, a floating UI mode - it's inline only right now.

Are you interested? If so, I can make a patch that integrates it.

comment:8 matveb21 months ago

Regarding Iris, noting we went with HSL for our first version but it'd be great to test HSL vs HSV, and potentially see what is more usable for people.

comment:9 follow-up: nacin21 months ago

One note, we still support IE7, while Iris says 8+.

comment:10 in reply to: ↑ 9 mattwiebe21 months ago

Replying to nacin:

One note, we still support IE7, while Iris says 8+.

Ah, was hoping we'd be dropping IE7 by now. I'll look into IE7 support.

comment:11 kgjerstad21 months ago

We use ExColor because it supports transparency. Works well in IE7 from our tests. We adapted it to replace the input with a selected color square.

mattwiebe20 months ago

comment:12 mattwiebe20 months ago

Just uploaded a patch for adding Iris in a nice and unified style. Patch only addresses the Custom Background screen for now, but should be pretty easy to port to anywhere else that uses a color picker, as it now is a single JS widget. This also addresses #19616 while we're at it.

Notes:

  • Introduces a wpColorPicker jQuery method that will contruct a standard widget on top of any input field
  • This will allow us to seamlessly swap out Iris for another color picker in the future should that be desirable
  • Takes a progressive enhancement approach - unsupported browsers (IE < 8) will still have a perfectly usable text input
  • Does not remove Farbtastic to maintain back compat for other plugins/themes that use it.

wpColorPicker supports two callbacks, which are used like this on the Custom Backgrounds page:

$('#background-color').wpColorPicker({
	change: function( event, ui ) {
		$("#custom-background-image").css('background-color', ui.color.toString());
	},
	clear: function() {
		$("#custom-background-image").css('background-color', '');
	}
});

Closed state (default):

http://cl.ly/image/2r3x0H1g0K30/content

Open state:

http://cl.ly/image/0B00283G0d3o/content

UI notes:

  • This is follows pretty closely on the Customizer's color picker UI
  • the "Clear" button will change to a "Default" button when there's a default color
  • A default color can be passed directly on the wpColorPicker method, or picked up directly from a data-default-color attribute on the input element

mattwiebe20 months ago

comment:13 mattwiebe20 months ago

^ Fix for a button layout issue.

comment:14 follow-up: azaozz20 months ago

Looks very good. One question: Opera already supports HTML 5.0 <input type="color"> and the other browsers will eventually support it. Should the color picker detect that support and not overwrite it?

comment:15 in reply to: ↑ 14 mattwiebe20 months ago

Replying to azaozz:

Opera already supports HTML 5.0 <input type="color"> and the other browsers will eventually support it. Should the color picker detect that support and not overwrite it?

I like the idea on principle and considered it. CanIUse also indicates that Chrome supports <input type="color" />, which brings the conversation well past Opera's meagre adoption. But, after looking at their implementations, I'd avoid <input type="color" /> right now for 3 reasons:

  1. Opera and Chrome have different base implementations. Inconsistent UX.
  2. Both open the host OS's color pickers, providing divergent UX across platforms. Also, both Windows and OS X color pickers take a "more is more" approach, providing too many options for a simple UX.
  3. The change event is not fired in real-time - only after the OS picker is closed. This makes the instant responsiveness of the customizer impossible. This is the real deal-breaker to me.

The nice part about having a wrapper like wpColorPicker, however, is that we can revisit this in the future should native inputs match our needs.

comment:16 lessbloat20 months ago

Yep, iris-picker.2.diff looks good to me. Nice work mattwiebe!

comment:17 helenyhou20 months ago

Looking good. Got a couple things:

  • Accessibility - can't get to it via keyboard unless it's open
  • .wp-color-result needs background-clip: content-box, especially with darker colors

Also, agreed on not relying on HTML5 color input at the moment, for all of the reasons listed.

comment:18 meliko20 months ago

  • Cc melissachoyce@… added

comment:19 follow-up: dgwyer20 months ago

  • Type changed from defect (bug) to feature request

Whichever color picker is chosen it should really support transparency, or allow you to manually type in transparent in the color picker text box.

I have been testing out the theme customizer with our latest theme to alter several key colors. This is working really well except that the Farbtastic color picker has no clear(?) way of selecting a transparent color rather than a fixed hex color code.

Last edited 20 months ago by dgwyer (previous) (diff)

comment:20 in reply to: ↑ 19 ; follow-up: lessbloat20 months ago

Replying to dgwyer:

Whichever color picker is chosen it should really support transparency

Sounds like a good idea for a plugin. But, my guess is that the majority of users (80+%) could care less, and adding an extra option for transparency would only confuse them. At this point, pretty much anything we deploy will work better that the existing color picker (3 out of the 3 users we tested had trouble with it).

downstairsdev20 months ago

Twenty Eleven Options page

comment:21 downstairsdev20 months ago

Nice work on this Matt!

I updated the UI for the Twenty Eleven options page to test this out. The only thing I noticed is that the color picker doesn't stand out too well on its own, especially when the background color of the screen matches the the selected color picker color: http://core.trac.wordpress.org/attachment/ticket/21206/twenty-eleven-page.png.

I personally like having the textbox with the hex color next to the drop down option (e.g. what it looks like in the drop down state)- but most users probably have no idea what that #hex means. It's an extremely minor issue, but thought it might be worth mentioning...

Would you like any help converting /wp-admin/custom-header.php or the theme customizer? I'd need to clean up the Twenty Eleven diff a bit more, but I can attach that too.

comment:22 in reply to: ↑ 20 ; follow-up: dgwyer20 months ago

Replying to lessbloat:

IMHO any color option should be flexible enough to include transparency. For example, we find it very common that overlays on sliders and other elements are required to support transparency (i.e. to easily hide them). If I include a slew of color picker options in the theme customizer you can bet that at least a few of them would (highly) benefit from being able to set the color as transparent.

A simple compromise could be to just allow the color picker input box to support an additional valid CSS color rule. i.e. allow the keyword 'transparent' to be used as well as valid color hex codes. This would mean that the UI wouldn't need any extra controls that might confuse some users.

comment:23 in reply to: ↑ 22 ; follow-up: helenyhou20 months ago

  • Milestone changed from Awaiting Review to 3.5
  • Type changed from feature request to enhancement

Replying to downstairsdev:

I personally like having the textbox with the hex color next to the drop down option

I think I do, too, at least on admin screens. It does get kind of lost because it's small. This would also be a quick way to address the accessibility issue, since I suppose a non-mouse user can't really use the colorpicker anyway.

Replying to dgwyer:

IMHO any color option should be flexible enough to include transparency.

How do you imagine the output looking, both in terms of the input (that is user editable) and the CSS generated? rgba() plus a hex fallback?

comment:24 in reply to: ↑ 23 ; follow-up: dgwyer20 months ago

Replying to helenyhou:
For a transparent color the input box would display 'transparent' (no quotes), and the color block next to it could show a checkered pattern commonly used to represent transparency colors etc in a lot of applications.

Because 'transparency' is a valid CSS style rule it could just be used in the final rendered CSS just like a valid hex color code would be.

Last edited 20 months ago by dgwyer (previous) (diff)

comment:25 in reply to: ↑ 24 ; follow-up: helenyhou20 months ago

Replying to dgwyer:

Maybe I'm being dense, but a separate checkbox doesn't make much sense to me. I can imagine how it would work in the color picker itself - I'm asking about the output that goes into text inputs and how we validate it. Also, transparency in CSS is not the same as using rgba() for a background color. If you use transparency, that will apply to the entire element, including any text or images, etc.

comment:26 in reply to: ↑ 25 dgwyer20 months ago

Replying to helenyhou:
No, I mean a grey/white checkered pattern to represent the transparent color, not a UI 'checkbox'.

I'm talking about any element you can style with a color, should also support the CSS 'transparent' rule so you can effectively hide it, which is really useful for things like slider overlays.

In hex input text box, if 'transparent' is also allowed then this can be used as easily as a valid hex color.

comment:27 stephenh198820 months ago

  • Cc contact@… added

comment:28 helenyhou20 months ago

Replying to dgwyer:

Oh, I see what I confused - I took talk about "transparency" as meaning alpha channel/rgba support rather than just "transparent" as a color definition. Transparency as a CSS rule is also a completely different thing :)

Wouldn't it make sense for the theme/plugin processing the input to make it transparent if the input is empty and it's a sensible choice for that particular use? After all, a user probably shouldn't be able to set their text to transparent. To me, the effect for the end user is that there is "no" color, not that it's called transparent. Looks like it currently punts it back to #000 when it's empty, though. That seems like behavior that should be changed or at least alterable.

comment:29 follow-up: azaozz20 months ago

Yes, was thinking the same. "Transparent" for (foreground/text) color: doesn't make sense, and for background-color: is the default in all browsers. Leaving the input field empty should remove the color from the css so the default is used.

comment:30 in reply to: ↑ 29 scottopolis20 months ago

Replying to azaozz:

Yes, was thinking the same. "Transparent" for (foreground/text) color: doesn't make sense, and for background-color: is the default in all browsers. Leaving the input field empty should remove the color from the css so the default is used.

Right, it would only apply to background colors, so if a user entered "transparent" into a field for "color:", nothing would happen.

The problem is not the browser default, it's the theme color styles. Say you have a black navigation bar background in a theme, and the user has a page background image they want to show through. There is no way to do that without enabling transparent.

lessbloat20 months ago

comment:31 lessbloat20 months ago

In iris-picker.3.diff I introduced accessibility to Iris, and experimented with the button style (adding "Select Color" instead of the drop down arrow) to make the element stand out more.

Here's what it looks like:

http://f.cl.ly/items/0P3K143a2l1a2P3k0l2y/iris-mod.jpg

Thoughts?

downstairsdev20 months ago

Patches the Twenty Eleven theme (and include Background iris-2.diff)

comment:32 follow-up: downstairsdev20 months ago

@lessbloat I like that. It stands out a little bit more. Maybe keep the arrow too at the very end so users have an idea that it will drop down?

I attached a patch for TwentyEleven, built on top of iris-picker.2.diff. (And apologies if the patch is wonky, not used to svn, but I think it worked.)

Note @mattwiebe:

The colorpicker is set up with:
$('#link-color').wpColorPicker();

But to change the color, it's:
$("#link-color").iris("option", "color", newDefault )

Seems like that should be normalized to always use "wpColorPicker" or "iris".

lessbloat20 months ago

comment:33 lessbloat20 months ago

iris-picker-4.diff brings Iris to the rest of the admin (props @koopersmith for help with some customizer code).

comment:34 in reply to: ↑ 32 mattwiebe20 months ago

Great work on the improved UI @lessbloat - I'll look through your latest patch and see if there's anything more for me to contribute to it. I have some accessibility enhancements, but you may have beaten me to the punch. Definitely need to fix the bug in Iris where it doesn't really allow the text input to be blank.

Replying to downstairsdev:

Note @mattwiebe:

The colorpicker is set up with:
$('#link-color').wpColorPicker();

But to change the color, it's:
$("#link-color").iris("option", "color", newDefault )

Seems like that should be normalized to always use "wpColorPicker" or "iris".

Yeah. So, iris is the the more general picker component, whereas wpColorPicker is the WP-specific color control. One thing I noted earlier was that it would make sense to focus on wpColorPicker so that we could more seamlessly swap in something other than Iris in the future should it look to serve our needs better. Logic would then dictate that all interactions with Iris be abstracted through wpColorPicker. So, I guess I should make that work. :)

comment:35 downstairsdev20 months ago

Great patch @lessbloat. I tested all the screens and the theme customizer in Chrome. I also tested with JS off, and only using the keyboard (on the backend screens). Everything worked well for me.

Would you want to run a user test on this too? I'd be curious if actual users are able to select a color quicker with this than with Farbtastic or if there's anything else we should consider.


comment:36 mbijon20 months ago

  • Cc mike@… added

The patches 'iris-picker-4.diff' and 'iris-picker-3.diff' don't seem to work in Chrome 21 and with WP build 21589. I get as far as the customization screen and then the controls' accordion parts won't open (so I can't see or use Iris).

The only error that dev tools are showing is that all enqueue'd scripts are being served with MIME type text, instead of Javascript. With the build 21589 code that doesn't happen.

Last edited 20 months ago by mbijon (previous) (diff)

comment:37 mbijon20 months ago

Related #21690: It's a UX enhancement to Farbtastic, in case this one doesn't make it into 3.5.

+1 BTW, to the features & UX of Iris.

comment:38 follow-up: scribu20 months ago

In Firefox, using 'iris-picker-4.diff', when I press the Clear button, the hex value goes away, but the selected color is still there. This is a pretty glaring bug, since it means there's actually no way of resetting a color.

Last edited 20 months ago by scribu (previous) (diff)

comment:40 downstairsdev20 months ago

Nice catch @scribu. I'm seeing this in the theme customizer.

Do we actually want "clear" to be an option? The current implementation (in 3.4) does not give that ability.

Perhaps the only option we have is "default" (when a default it supplied), and otherwise don't have a button there?

---

Update:

@mbijon's Can you give a use case for clear?

Generally for a theme option, I'd check whether the default color was selected. If it is, I wouldn't output an inline style, otherwise I would.

But I could think that other folks might have always set up their options to output whatever value was returned from the colorpicker options (without checking if it was a default or blank)- so if a user suddenly now has the ability to clear that, it will break certain theme implementations.

Last edited 20 months ago by downstairsdev (previous) (diff)

mattwiebe20 months ago

mattwiebe20 months ago

comment:41 mattwiebe20 months ago

Use iris-picker-6.diff - ignore iris-picker-5.diff (forgot to svn add some stuff)

Did a lot of fine-tuning of Iris and the underlying Color.js library to get this in a good spot. Here's what's in now:

  • Allow blank values in the input box, and fire the 'clear' callback when this happens
  • Show error states on an unacceptable color (the underlying Color.js lib will understand any CSS color, but not CSS keywords)
  • wpColorPicker now has a get/set color method to provide the current color in other scripts. Eg $("#input").wpColorPicker('color'); // returns hex string and $("#input").wpColorPicker('color', newColor);
  • Mouse accessibility: the control will now open on both enter & space keypresses (was just space before)
  • The "Pick Color" string now gets pulled via content: attr( title ) in the CSS to make it i18n-able.

comment:42 in reply to: ↑ 38 mattwiebe20 months ago

Replying to scribu:

In Firefox, using 'iris-picker-4.diff', when I press the Clear button, the hex value goes away, but the selected color is still there. This is a pretty glaring bug, since it means there's actually no way of resetting a color.

Where are you seeing this? In the Customizer?

lessbloat20 months ago

comment:44 lessbloat20 months ago

iris-picker-7.diff fixes a small bug on line 83 of wp-color-picker.js where "e.keyCode === 32" was preventing spaces from being used in the customizer. related to: http://make.wordpress.org/ui/2012/08/27/now-that-weve-got-a-couple-of-rough/

comment:45 lessbloat20 months ago

RE: http://make.wordpress.org/ui/2012/08/27/now-that-weve-got-a-couple-of-rough/ we need to make sure when the right .iris-hue slider is clicked, that the hex text box is updated.

mattwiebe20 months ago

comment:46 mattwiebe20 months ago

Lotsa polish in this one:

  • Clearer "puck" styles (including hover/focus) for more usability
  • Make .wp-color-result the keyboard accessible anchor instead of .wp-color-wrap: anchors inside anchors are scary.
  • Consistent clear events fired from wpColorPicker
  • Finish Customizer integration
  • Clean up custom-header integration
  • Fix styles for "Pick Color" label so it's i18n-able (variable widths)

comment:47 mbijon19 months ago

  • Keywords needs-testing added

The last two versions of this patch report rejected patch hunks when applied to revision [21751], via TortoiseSVN's patching. Neither works after this as there are jQuery ref errors.

After applying 'iris-picker-8.diff' my console reports:
Uncaught ReferenceError: jQuery is not defined in theme-options.js, line 52

After applying 'iris-picker-7.diff' the console reports:
Uncaught ReferenceError: jQuery is not defined in theme-options.js, line 12

Is there a specific revision these can be tested with? If anyone knows I'd be happy to rev the patch for the current revision.

comment:48 follow-up: scribu19 months ago

iris-picker-8.diff applies cleanly for me as of r21825.

comment:49 in reply to: ↑ 48 mbijon19 months ago

Replying to scribu:

iris-picker-8.diff applies cleanly for me as of r21825.

Thanks @scribu, works great for me in r21825 too. The changes in JS filenames must have happened since r21751.

Testing feedback:
iris-picker-8.diff works as-expected in both Chrome 21 and IE9, 64-bit (nice job there). No JS bugs or errors reported in either browser.

comment:50 nacin19 months ago

  • Summary changed from Replace Farbtastic color picker with ???... to Replace Farbtastic color picker
  • Type changed from enhancement to task (blessed)

mattwiebe19 months ago

comment:51 mattwiebe19 months ago

This latest patch builds on everything previously and adds 3 things in the direction of usability:

  1. Change "Pick Color" label to "Current Color" when picker is open rather than removing the label altogether
  2. Add a tooltip on init pointing to the 2-axis "puck", also saying "Current Color." The tooltip vanishes as soon as you start interacting within the Saturation-Lightness square.
  3. Change the vertical hue slider to a pair of triangles so that it feels more like the calibration tool it is, rather than feeling like you're picking a color on that slider.

comment:52 nacin19 months ago

  • Component changed from General to UI

mattwiebe19 months ago

mattwiebe19 months ago

comment:53 mattwiebe19 months ago

Two patches added, one for each mode.

iris-picker-10.diff - same UI as before, but I've now made it so that the rainbow hue strip on the right updates its lightness + saturation to match the current color. It can leave that area without color for a time, but this way there's no surprises - both controls are an accurate representation of the current color. That means I ditched the tooltip as well.

iris-picker-11.diff - move the hue rainbow onto the horizontal axis of the square. I think the UX on this one turned out pretty awful, actually, but I'll let others make that call. It comes down to HSL vs HSV colorspaces - HSV would be better suited for this particular mode.

My own recommendation would be to ship beta 1 with iris-picker-10.diff and see how the new, both-controls-are-canonical approach works out in user testing. I'll see about introducing an HSV mode.

comment:54 nacin19 months ago

In [22030]:

New color picker, props mattwiebe. see #21206.

Replaces Farbtastic. May change further in response to user testing.

comment:55 nacin19 months ago

[22030] was .10.diff. Current plan of action is for an HSV version of 11.diff to be ready for user testing by early next week, to be compared to 10.diff and the existing HSL 11.diff.

I think the HSL 11.diff will win out. We'll see.

mattwiebe19 months ago

comment:56 nacin19 months ago

In [22033]:

Update underlying color picker library. props mattwiebe. see #21206.

comment:57 follow-up: ocean9019 months ago

Not sure which patch I had tested yesterday, but with this patch, the color picker in the Customizer had looked like this: http://cl.ly/Jjuc

But now in trunk: http://cl.ly/JkZk

comment:58 in reply to: ↑ 57 mattwiebe19 months ago

Replying to ocean90:

Not sure which patch I had tested yesterday, but with this patch, the color picker in the Customizer had looked like this: http://cl.ly/Jjuc

But now in trunk: http://cl.ly/JkZk

That's as expected - see my note above. You were testing -11.diff, but we landed -10.diff, as I recommended in that comment. -11.diff was mostly to demonstrate that that particular model of picker has a weird UX. Gonna try something similar, but with an HSV model rather than an HSL model for the next beta.

mattwiebe19 months ago

Fix the color picker layout in the customizer. This was missed in r22030

comment:59 nacin19 months ago

In [22063]:

Add missing color picker + customizer CSS. props mattwiebe. see #21206.

mattwiebe19 months ago

comment:60 mattwiebe19 months ago

Lucky -13.diff adds a new version of Iris that works with multiple possible models, including an HSV mode.

This patch:

  • uses an HSV model for wpColorPicker instances, with hue on the box's horizontal axis
  • addresses layout issues introduced by longer i18n button text
  • modifies the "Select Color" box's styles to match current .button styling
  • make the picker slightly larger to make maximum use of available Customizer space

comment:61 follow-up: lessbloat19 months ago

I really like iris-picker-13.diff. I tried thinking through a couple of user scenarios. Here are the two that stick out to me:

1) I think users may have trouble selecting pure black, or white. It's possible, but it requires that they click (and hold) in the color selector, and then drag the puck to the top or bottom edge. We can test this scenario on users, but my guess is that it may be hard for some to figure out.

2) When the default color is near white (i.e. #f1f1f1), or near black (i.e. # 010101), there aren't any good visual indicators that other color options are available.

http://f.cl.ly/items/3a2A1R30353L2C1B2v3V/default-colors.jpg

Most users will likely figure it out by just clicking around, but is there anything more we can do to improve this?

Just throwing an idea out there, what if we did something like this:

http://f.cl.ly/items/1j3o0q2f291a3z260b00/color-picker-with-swatches.jpg

Allowing users to quickly select white or black (with a single click), or hop directly to a specific color by clicking one of the color swatches below.

comment:62 Clorith19 months ago

  • Cc funman@… added

I fully agree with lessbloat, I just clicked around and I was utterly confused at first wondering why I wasn't given actual color options in the Customizer.
Since the transparency from the main picker carries over it's very hard to determine, wouldn't it make more sense to not throw transparency on the right hand slider used to pick the primary color?

I see this was mentioend by matt in Comment #53 that it carries over in diff-10 but I still feel strongly that it shouldn't carry over at all for the users sake.

comment:63 helenyhou19 months ago

#22137 was marked as a duplicate.

comment:64 in reply to: ↑ 61 mattwiebe19 months ago

Replying to lessbloat:

1) I think users may have trouble selecting pure black, or white. It's possible, but it requires that they click (and hold) in the color selector, and then drag the puck to the top or bottom edge. We can test this scenario on users, but my guess is that it may be hard for some to figure out.

Just throwing an idea out there, what if we did something like this:

http://f.cl.ly/items/1j3o0q2f291a3z260b00/color-picker-with-swatches.jpg

It's a fine idea, worth trying out. I doubt I'll be able to get to this for beta2.

dgwyer18 months ago

comment:65 follow-up: dgwyer18 months ago

The patch color-picker.js.patch (made against the latest WordPress trunk) adds a new wpColorPicker get/set method to provide the current default color in other scripts.

This is similar to the 'color' method added in iris-picker-6.diff but allows you to update the color picker default.

I'm afraid I didn't know how to add this patch to the latest diff: iris-picker-13.diff. If someone could point me in the right direction then I would be grateful.

comment:66 dgwyer18 months ago

  • Cc d.v.gwyer@… added

dgwyer18 months ago

comment:67 dgwyer18 months ago

Just managed to include my color-picker.js.patch into iris-picker-14.diff.

Last edited 18 months ago by dgwyer (previous) (diff)

comment:68 follow-up: helenyhou18 months ago

We appear to have lost keyboard accessibility :(

lessbloat18 months ago

comment:69 in reply to: ↑ 68 lessbloat18 months ago

Replying to helenyhou:

We appear to have lost keyboard accessibility :(

iris-picker-15.diff resurrects accessibility support.

comment:70 in reply to: ↑ 65 ; follow-up: mattwiebe18 months ago

Replying to dgwyer:

The patch color-picker.js.patch (made against the latest WordPress trunk) adds a new wpColorPicker get/set method to provide the current default color in other scripts.

Can you give a use case for needing that?

Replying to lessbloat:

iris-picker-15.diff resurrects accessibility support.

Thanks for doing that Dave.

comment:71 in reply to: ↑ 70 dgwyer18 months ago

Replying to mattwiebe:

Replying to dgwyer:

The patch color-picker.js.patch (made against the latest WordPress trunk) adds a new wpColorPicker get/set method to provide the current default color in other scripts.

Can you give a use case for needing that?

An example user case is for multiple color schemes/palettes, where you need access to each color picker default value as well as the current color value.

When the color scheme/palette changes (say via a dropdown) and 'Default' is clicked the color picker value should revert to the current color scheme default value (which has been updated).

Most themes these days include multiple color schemes and this core change makes it easier to integrate them with the customizer.

comment:72 prionkor18 months ago

  • Cc sisir@… added

comment:73 lessbloat18 months ago

Went back and retested the latest diff in Mac FF & Chrome, as well as Win FF, Chrome & IE7 (which falls back to a text field).

+1 to iris-picker-15.diff.

comment:74 lessbloat18 months ago

  • Keywords commit added; ux-feedback needs-testing removed

ryan18 months ago

Where's my rainbow? With iris-picker-15.diff after clicking Default and then clicking around the left side of the picker.

comment:75 ryan18 months ago

In 22385:

Restore keyboard accessibility to the color picker. Props lessbloat. see #21206

comment:76 helenyhou18 months ago

  • Keywords has-patch commit removed

Anything else?

comment:77 follow-up: nacin18 months ago

Where's my rainbow? With iris-picker-15.diff after clicking Default and then clicking around the left side of the picker.

Comments like this make me want to stop changing the square based on the slider. The big giant swatch of the current color was not present with Farbtastic, and should prevent issues of people changing one side without knowing why the color is changing. Still, I think that problem is better than people being trapped and unable to even find other colors.

comment:78 in reply to: ↑ 77 mattwiebe18 months ago

Replying to nacin:

Where's my rainbow? With iris-picker-15.diff after clicking Default and then clicking around the left side of the picker.

Comments like this make me want to stop changing the square based on the slider. The big giant swatch of the current color was not present with Farbtastic, and should prevent issues of people changing one side without knowing why the color is changing. Still, I think that problem is better than people being trapped and unable to even find other colors.

On a personal level, I agree, which is why the first iterations behaved that way. But they overwhelmingly failed in user testing, whereas this model has been surprisingly successful.

To reiterate some discussion that's been had on IRC for the benefit of all: there are two poles of usability in a color picker: 1) consistency (keeping the color model internally consistent) and 2) discoverability (ease of pointing to a desired color). As every color model has at least 3 factors, a square 2-axis control and a 1 axis slider is the smallest number of UI controls possible for a color picker. And, the major question of control canonicity maps to our usability poles:

  • Dual canonical controls favors consistency. No matter where you click in any control, that's the color you wind up with. The weakness here, as in ryan's comment, is that discoverability suffers in some color situations.
  • A single canonical control favors discoverability (there's always something to click on) over consistency (if you click on the non-canonical slider control, you are only adjusting that single aspect in the color model, but are not actually getting that color.)

Early versions of Iris (and Farbtastic currently) took a single canonical approach. And user testing revealed that this is a usability disaster. Users would click on pretty rainbow to get a blue, even thought the canonical square control still had the color situated in a black-ish area, resulting in an actually black-ish color (but with a blue hue that made no difference). See http://wp.me/p29g3i-bT under Step Six (one of several that played out similarly).

Once we moved to a dual canonical control model, users were initially off-put by the lowered discoverability, but after playing with it briefly intuited the color model and found the color they were looking for. See http://wp.me/p29g3i-c1 under Step Four and http://wp.me/p29g3i-c6

With these testing findings, I think that the obvious direction is to maintain dual canonical controls while making efforts to increase discoverability. I have an incoming patch that will implement a version of lessbloat's palette idea so that there will always be some clickable colors present.

mattwiebe18 months ago

comment:79 mattwiebe18 months ago

iris-picker-16.diff:

  • adds optional palettes to Iris, and turns them on by default in wpColorPicker in an effort to promote more discoverability when your current color is unsaturated
  • removes the extra controls at the edge of the square

comment:80 follow-ups: lessbloat18 months ago

I tested a new user with iris-picker-16.diff​. This is easily the fasted and least confusing approach I've seen so far.

My only concern now is that the default swatch colors are a bit garish. I can live with them, since they appear to do the job, but would it be possible to desaturated the defaults by 20%?

comment:81 in reply to: ↑ 80 saracannon18 months ago

Why not use the default color swatches to promote good design? (rather than eye bleed) +1

mattwiebe18 months ago

rainbow stripe in hue strip

comment:82 mattwiebe18 months ago

iris-picker-17.diff is a different experiment in color discoverability. For Iris configurations with hue in the right side strip, it adds a narrow stripe of the rainbow at full saturation. This is possibly a less intrusive UI than the palettes.

comment:83 in reply to: ↑ 80 ; follow-up: mattwiebe18 months ago

Replying to lessbloat:

I tested a new user with iris-picker-16.diff​. This is easily the fasted and least confusing approach I've seen so far.

:)

My only concern now is that the default swatch colors are a bit garish. I can live with them, since they appear to do the job, but would it be possible to desaturated the defaults by 20%?

Oh yes, they are ugly. Just took the full saturation primaries at 60 degree intervals. Happy to dial those down a bit :)

Also, helenyhou mentioned that it might be nice to make the palette selection configurable (think a theme providing a complementary color scheme), which I'm also open to if we stick with this UI.

Replying to saracannon:

Why not use the default color swatches to promote good design?

Which default color swatches? WordPress's? If that's what you mean, those are good colors, but not necessarily applicable to the contexts where the picker will be used.

comment:84 in reply to: ↑ 83 saracannon18 months ago

Replying to mattwiebe:

just referring to the default ones @lessbloat was talking about it and +1ing the saturation changes.. Also: I agree that making it configurable to where a theme can modify the default swatches to coordinate with their palette is key

Replying to saracannon:

Why not use the default color swatches to promote good design?

Which default color swatches? WordPress's? If that's what you mean, those are good colors, but not necessarily applicable to the contexts where the picker will be used.

comment:85 helenyhou18 months ago

  • Keywords has-patch added

Personal preference on testing is for the version with swatches - the other confuses me a bit with the multiple stripes and what chooses what exactly, even though conceptually I understand it. And yes, I think being able to custom define those swatches would be a big win :) I don't mind that they are bright, because they provide quick reference points to basic (pure?) screen colors users might be used to from other contexts/applications. Maybe just me, though.

mattwiebe18 months ago

comment:86 mattwiebe18 months ago

iris-picker-18.diff:

  • builds on iris-picker-16.diff
  • now has a nice, non-eye-searing ROYGBV default palette
  • you can use a custom palette when calling the .wpColorPicker' method by suppling a palettes` arg with an array of colors
  • renames the default_color method to defaultColor to maintain internally consistent naming styles

Based on user testing and feedback in #wordpress-ui, I think this is ready to land and fix.

comment:87 nacin18 months ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 22457:

Swatches for the color picker. Improves discoverability of colors especially when the picker is opened with a grayscale color. props mattwiebe. FIXES #21206.

comment:88 follow-up: johnbillion18 months ago

Any reason the picker appears inline (and pushes the 'Save Changes' button down when opened) instead of floating above the page content like the current (3.4) picker?

comment:89 in reply to: ↑ 88 mattwiebe17 months ago

Replying to johnbillion:

Any reason the picker appears inline (and pushes the 'Save Changes' button down when opened) instead of floating above the page content like the current (3.4) picker?

I guess you're looking at the Custom Background picker? Anyway, wpColorPicker follows on the inline style that we had for Farbtastic in the Customizer. We previously had multiple implementations of Farbtastic integration, now we have a single, unified one. Since the Customizer is going to be the residence of most color pickers going forward, that's the style to use.

Also: floating panels are a pain in the butt. Calculating positions, making sure you don't wind up offscreen, not obscuring needed content... Leave it to the browser.

comment:90 follow-up: prionkor17 months ago

Which colorpicker should i use if i want to add a colorpicker to theme.

comment:91 mbijon17 months ago

  • Keywords needs-docs needs-codex added

These workflow tags don't always get a ton of attention and may not be needed with this much core team involved, but this is a big enough change and seems ready for docs.

@prionkor, if you don't mind being one of the first the Iris picker makes sense to try. It's in core and not going anywhere after all. Do you mind letting this ticket know if there are any problems?

comment:92 in reply to: ↑ 90 mattwiebe17 months ago

Replying to prionkor:

Which colorpicker should i use if i want to add a colorpicker to theme.

Enqueue the wp-color-picker script and style, and then run the wpColorPicker method on a text input like jQuery('.my-text-input').wpColorPicker();

If you're working in the Customizer, just use the built-in color control, which now defaults to the new color picker.

More docs will come, but that should get you started.

comment:93 rachelbaker17 months ago

  • Cc rachelbaker added
Note: See TracTickets for help on using tickets.