I think it is silly that the triangle actually touches the circle at three places instead of just one (i.e., the place indicative of the selected hue).
Beats me why, but every picker I've seen use a ring-and-triangle UI does that. Maybe it's for the same reason that primary colors are always 120° apart on a color wheel?
I can't speak with authority about the origins of that kind of color picker, but I'm 100% sure that is not the reason. It's just for geometrical neatness. The adjacent colors at the "back" corners are not useful or relevant.
Some colour wheels do not put primaries at 120% angles. The "opponent" theory of colour perception from the early 20th C, which has been essentially validated, led to this example:
Those usually need to be bigger to get an accurate colour selection. Also depends on the change to a colour I wish to make, if multiple colour pickers are available I usually end up using them all once in a while.
It is really difficult to select a full black or white on that color wheel. I feel I would never want to use it in a drawing tool for that reason alone.
I did the same thing for a color app I built for adjusting CSS values using a color wheel.
Dealing with color is tricky, I'm sure I made a lot of mistakes..
One interesting bug I think I found is with NSColor/UIColor. If you set the hue for a color, and then proceed to drop the saturation/brightness to 100%/0%, it'll wipe out the hue when you change the saturation/brightness back to sensible values. It could just be something with color spaces that I don't understand, but it seems like a bug to me (data is destroyed).
I read a lot about color working on that app, and it is a pretty deep subject. You can read all about the science aspects of color, light spectrums etc. Then you read something else and realize that color is just a human sense, that is all about perception and not set in stone. All the color spaces and representations seem to have their flaws and certain adjustments don't match expectations.
To summarize I tried to learn and understand color, but in the end it all seems like a mess. I don't have an academic background, so maybe this is just a lack of understanding.
It's not a bug. HSB is just a particular way to represent RGB colors, but it's not how the colors are stored. If you create an NSColor/UIColor with HSB, you end up with an RGB color (typically in the sRGB color space), so if you create a color with a saturation of zero, the resulting RGB color has no hue at all, which means you've lost the hue component entirely (and in fact, with the way HSB is defined, you try to get HSB values back out of a grayscale RGB color, the hue value is undefined, though I believe NSColor/UIColor will just report it as zero). Or to put it another way, there's no one-to-one correspondence between all RGB and all HSB values.
So basically, if you're writing an application that exposes HSB colors to the user, you should be storing the HSB values yourself rather than relying on UIColor/NSColor to preserve them, because it won't.
Thanks for explaining that, it makes sense. I ended up writing my own Color struct to store the values in HSB like you suggest.
It's odd I couldn't find information about this anywhere. The NSColor/UIColor docs don't mention it, but there is a clue I guess. They note that NSColor/UIColor is stored as CGColor internally, and CGColor doesn't have an HSB init.
Thanks again, I searched everywhere for the answer to this.
More specifically, UIColor and NSColor store a reference to a colorspace and a set of components (plus alpha). The colorspace defines the number of components and their meaning. So all of the RGB colorspaces define 3 components, Red, Green, and Blue, which means UIColor and NSColor need to store the color using those 3 components (plus alpha) whenever they're using an RGB colorspace.
Many of these comments are about the colour wheel, when in fact the real discussion should be about whether or not it was correct to change the colour wheel to satisfy his wife.
I made an infinite runner recently to try out Phaser.js, and I let me wife try it. She loves infinite runners, plays them all day. Her comment? "I hate it." Why do you hate it?
"I don't know." Well try to find one thing you don't like and tell me that.
"It's too hard."
What's hard about it? "I don't know."
If I made the player jump father when you tap the screen, would that help? "I don't know."
What about if you got more coins as you went along? "I don't know."
I showed it to a group of kids in the family, and they went nuts for it. And their feedback was much more useful! After I saw how they played it and heard their complaints and tips to each other, I changed it up and presented it to my wife again and she loved it.
> Many of these comments are about the colour wheel, when in fact the real discussion should be about whether or not it was correct to change the colour wheel to satisfy his wife.
He didn't make the change to satisfy his wife. He felt that his wife's underlying point: the wheel didn't work the way she expected, was valid, and made an adjustment.
Subtlety isn't their strong suit but they have a sort-of point. Perhaps he should have just shown her how to use that generic UI element: "click the outer ring to select the colour, click the triangle to select the tone".
By fixing it instead his wife will now be frustrated with every other colour wheel that uses the de facto standard behaviour.
Also, it should only jump/slide to a higher saturation if the saturation is 0, otherwise moving around the colours with a fixed but non-zero saturation wouldn't be possible.
Let's say that, as you say, his wife is now frustrated with every other color wheel that uses the standard behavior. She now feels that his program is distinctly better, at least in regard to color picker behavior than other programs that use what is now considered the standard. This is what I would call a competitive advantage.
If enough users feel the same way as his wife, his competitive advantage will be so much bigger.
This is why some programs are considered easier to use, or even "better" than others. It's the sum of these tiny little behavior differences that add up to a better user experience.
Over time, some of them end up being standard. This is evolution at work.
Except unless most of those users are like his wife, they'll already be familiar with the standard colour wheel. And so if his works differently, they'll be annoyed by it, because goddamnit people we have standard widgets for a reason. And then by pandering to the few, you annoy the many.
Of course, if he can find an unobtrusive tweak (as it seems he did) which maintains the standard behaviour while eliminating a failure mode, then good on him and it deserves to become part of the standard.
I hear comments like that from a lot of people who aren't "computer nerds." I mean, you did just call a whole class of millions of people "special," and I am pretty sure you didn't mean it positively.
If you're developing a half-way complex web application, you largely don't want to depend on OS default dialogs. They can be buggy, detract from the UX of the rest of your application, require additional support as now you need to explain how to use the different dialogs on N different operating systems, and it's often the case that your application is the first time the user comes into contact with that dialog anyway - they're usually not nearly as commonly used as you'd think.
I'm trying to think of a cross-platform framework that didn't eventually do away with native widgets, at least optionally. Java went from AWT to Swing, wxWidgets has wxUniversal, even the <button> tag got custom skinning.
Is this becoming a pattern? "Cross Platform Requires Owner Drawn Widgets."
Sometimes it's good to have a sincere feedback from a user that won't refrain to use the exact words that crosses his/her/their mind when a problem arises, and you can trust that the normal user from your app would use the same words and then look for another app. (Or site, for what it matters).
Otherwise, how would you know that n users dropped off without telling you why?
I think the author handled it brilliantly. He only changes the saturation component to 1.0 only if it was zero and the user clicked on the outer wheel. His reasoning is that clicking on the outer wheel is a leading indicator that the user will end up changing the saturation in order to see the effective color.
This way he anticipates the needs of users. I think it is a nice usability tweak with minimal negative effects.
I think anything but zero should preserve the standard behavior. The reason is that it is fairly easy to make the saturation zero. It takes a dedicated effort to make the saturation almost zero.
I am not familiar with this particular color picker and the resolution on the saturation. I would imagine that setting the saturation to zero is easy by clicking on the triangle and dragging into the corner, in order to corral the picker into the point at which saturation is 0. Picking a close-to-zero saturation involves a dedicated effort.
His webpage certainly doesn't work with JavaScript disabled.
What an exciting world we live in, when I have to give a stranger execute access on my computers in order to read his words. If only there were some way for him to send me text instead of a program.
I agree 100%! This is probably one of the worst things I've learned the hard way. You begin to notice that many of the hardest things to "get just right" are completely skimmed over by nearly everyone. That fancy section you spent 3 days making perfect? Nobody even looks at it.
You get a good idea of how some people have been "conditioned" for how they search for things. Depending on the market - the only thing they are looking for us a phone number or a contact form. Even when the phone number is in the header, we see people scroll straight to the bottom of the site and look for a phone number in the footer!
I've seen casual users get confounded by that aspect of the color wheel more often than not. Basically every casual user who I've seen try a color wheel for the first time makes that same mistake and gets a little confused and frustrated.
I wonder if we can generalize a UI antipattern:
- A control that the user can change
- but which has no effect due to the setting of another control
- but does nothing to indicate that state
This is one of the top reasons audio synthesizers (real and virtual) can be frustrating for even very expert users. You get caught in a situation where you are adjusting a control over and over, trying to perceive the effect, only to realize that it is doing nothing unless you change some other control that may be located far away (visually/physically/menu-wise/tabs/categories/etc) from the thing you are changing.
My biggest pet peeve is greyed out buttons. No explanation as to why you can't push the button. Just the inactive control, sitting there, taunting you.
Macs are especially bad in this regard.
Would be nice if at least a mouse over would pop up an explanation for how to reactivate it...
Curiously enough, an attempted solution for this problem was one of Apple's flagship features in Macintosh System 7, way back in 1991. It all ended up being more work than it was worth.
Your comment made me think about how to improve a synthesizer design. Even with a modular synthesizer, where in the natural state every component is tweakable, but has no effect (before you make any connections), there could be a way to provide feedback: e.g. have a light bulb whose intensity is somehow proportional to the effect the module has on the main out. Or have lighted cables that would allow to trace the signal from oscillators to the output (e.g. with a lighted dot that runs the length of the path).
Another option would be draw the hue right using the currently selected saturation. That would mean that the color you click is the color you get, whatever the current saturation is. If the saturation is zero, then the entire ring becomes a uniform gray bar, making it clear that clicking anywhere isn't going to have an immediate effect.
But then the triangle shows only one hue. I wonder if some people wouldn't at this point decide that there is no visible way to choose other hue and give up without trying.
54 comments
[ 3.4 ms ] story [ 72.6 ms ] threadSome colour wheels do not put primaries at 120% angles. The "opponent" theory of colour perception from the early 20th C, which has been essentially validated, led to this example:
http://www.greynotgrey.com/blog/wp-content/uploads/2012/06/h...
[1] http://media.tumblr.com/tumblr_ls9s60OkvV1qz9jbw.jpg
That's not the old Paint, that's the new Paint!
But then again I'm not a designer...
Dealing with color is tricky, I'm sure I made a lot of mistakes..
One interesting bug I think I found is with NSColor/UIColor. If you set the hue for a color, and then proceed to drop the saturation/brightness to 100%/0%, it'll wipe out the hue when you change the saturation/brightness back to sensible values. It could just be something with color spaces that I don't understand, but it seems like a bug to me (data is destroyed).
I read a lot about color working on that app, and it is a pretty deep subject. You can read all about the science aspects of color, light spectrums etc. Then you read something else and realize that color is just a human sense, that is all about perception and not set in stone. All the color spaces and representations seem to have their flaws and certain adjustments don't match expectations.
To summarize I tried to learn and understand color, but in the end it all seems like a mess. I don't have an academic background, so maybe this is just a lack of understanding.
So basically, if you're writing an application that exposes HSB colors to the user, you should be storing the HSB values yourself rather than relying on UIColor/NSColor to preserve them, because it won't.
It's odd I couldn't find information about this anywhere. The NSColor/UIColor docs don't mention it, but there is a clue I guess. They note that NSColor/UIColor is stored as CGColor internally, and CGColor doesn't have an HSB init.
Thanks again, I searched everywhere for the answer to this.
"I don't know." Well try to find one thing you don't like and tell me that.
"It's too hard."
What's hard about it? "I don't know."
If I made the player jump father when you tap the screen, would that help? "I don't know."
What about if you got more coins as you went along? "I don't know."
I showed it to a group of kids in the family, and they went nuts for it. And their feedback was much more useful! After I saw how they played it and heard their complaints and tips to each other, I changed it up and presented it to my wife again and she loved it.
Still couldn't quantify why though.
https://your-comic-stop.wikispaces.com/file/view/SL010624.gi...
You're not married are you ...?
He didn't make the change to satisfy his wife. He felt that his wife's underlying point: the wheel didn't work the way she expected, was valid, and made an adjustment.
By fixing it instead his wife will now be frustrated with every other colour wheel that uses the de facto standard behaviour.
Also, it should only jump/slide to a higher saturation if the saturation is 0, otherwise moving around the colours with a fixed but non-zero saturation wouldn't be possible.
If enough users feel the same way as his wife, his competitive advantage will be so much bigger.
This is why some programs are considered easier to use, or even "better" than others. It's the sum of these tiny little behavior differences that add up to a better user experience.
Over time, some of them end up being standard. This is evolution at work.
Of course, if he can find an unobtrusive tweak (as it seems he did) which maintains the standard behaviour while eliminating a failure mode, then good on him and it deserves to become part of the standard.
[1] never use a big word where a diminutive one shall suffice!
HTML5 has the input type of 'color' which uses the OS's default color picker dialog.
Edit: Oops, it's dated 2010 isn't it.
Is this becoming a pattern? "Cross Platform Requires Owner Drawn Widgets."
Otherwise, how would you know that n users dropped off without telling you why?
I think the author handled it brilliantly. He only changes the saturation component to 1.0 only if it was zero and the user clicked on the outer wheel. His reasoning is that clicking on the outer wheel is a leading indicator that the user will end up changing the saturation in order to see the effective color.
This way he anticipates the needs of users. I think it is a nice usability tweak with minimal negative effects.
I don't have a better solution though.
I am not familiar with this particular color picker and the resolution on the saturation. I would imagine that setting the saturation to zero is easy by clicking on the triangle and dragging into the corner, in order to corral the picker into the point at which saturation is 0. Picking a close-to-zero saturation involves a dedicated effort.
What an exciting world we live in, when I have to give a stranger execute access on my computers in order to read his words. If only there were some way for him to send me text instead of a program.
I did this on one of my ecommerce sites and was surprised to see how many of my assumptions on how people use a website were wrong.
You get a good idea of how some people have been "conditioned" for how they search for things. Depending on the market - the only thing they are looking for us a phone number or a contact form. Even when the phone number is in the header, we see people scroll straight to the bottom of the site and look for a phone number in the footer!
"red widget for under $100 with free shipping" (which, of course, doesn't work...)
I wonder if we can generalize a UI antipattern:
- A control that the user can change
- but which has no effect due to the setting of another control
- but does nothing to indicate that state
This is one of the top reasons audio synthesizers (real and virtual) can be frustrating for even very expert users. You get caught in a situation where you are adjusting a control over and over, trying to perceive the effect, only to realize that it is doing nothing unless you change some other control that may be located far away (visually/physically/menu-wise/tabs/categories/etc) from the thing you are changing.
I find the whole discussion fascinating.
Macs are especially bad in this regard.
Would be nice if at least a mouse over would pop up an explanation for how to reactivate it...
https://en.wikipedia.org/wiki/Balloon_help