Is it good to limit the user to a set number of selectable font / background colors?

Question

I asked a question here to make a recommendation on an upgrade on color palette selection.

We have a dashboard that has many boxes displaying text. You can change the color of the boxes and the text as you want.

One of my suggestions was to replace the color palette from a full RGB selector to a smaller selection of colors, as the user least likely is going to differentiate between something like:

^{download bmml source – Wireframes created with Balsamiq Mockups}

...if they're not close enough (Yes, those are two different shades of red).

Another idea was to limit the text/background combinations to ensure good contrast happen

^{download bmml source}

My colleague told me that "the user should be able to pick black background on black text if that's what he wanted", I replied that I didn't agree. Specifically having the cradle example given in this TED video from minute 6:00 to minute 9:00.

The video says:

You want to make it hard to use wrong. You want to make the right way to use it the easiest way to do it.

So my question is:

Is it better to Limit the user in the color choices they can make in order to ensure a better user experience? (For a reason I cannot stop thinking of Steve Jobs right now).

BONUS: Citing Hick's Law would really make me happy (if applicable). I want to see what's the impact on hick's law on a 32 bit color palette :)

Answer 1

Allowing end-users to modify the UI colors leads to people using the Hot Dog theme in Windows 3 or whatever that polka dot theme is in SharePoint.

It's a 'ooh neat!' feature that provides little to no value and, often, is a huge detriment to every person that has to use the site.

I could see offering a few well-curated and designed options, but letting people randomly do as they wish in most cases will lead to eye-bleeding results.

Answer 2

It depends what's the point of different colors: is it only for personalization, eg. the dashboard colors are not designed for a public audience, but rather for yourself?

In case it's a personalization, the next question is about amount of dashboard boxes: what's the likely amount you'll have?

It can be that if you have a hundred boxes, you want to have similar background, different foreground to have a sub-grouping, while if there are only about a dozen or two, it's enough to have groups based on a single colorscheme.

In case the former, you better give fine-grained access, albeit it's enough to do it with "crayons": OS X gives you the ability to choose from a pre-defined palette in an intuitive way:

Do this for both colors.

In case the latter, it's better if you provide some pre-built schemes, a "theme-chooser": show an example widget in each colorset with a name.

two themes in a theme chooser: I'm pretty sure MS Word has some better examples...

In case it's for a public audience, it's better to let users have fine-grained control. That means, a full color palette chooser for both colors...

Answer 3

Let them choose the background easily with a limited initial set of colors, expanding to unlimited - and auto-toggle (based on color math) the foreground color between a light and dark to give good contrast.

Balsamiq does this automatically. Below I created two buttons - when I changed the right button background to red, it automatically toggled the foreground text to white. An ambitious user could change the text color to fuchsia, but most users will likely care most about the background color.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 4

I think you're on the right track -- a limited set of options is probably what I'd go with. (Unless your application is some kind of color picker or design thing.) In my mind, the main reason you'd use a color picker is when the user needs to put in an exact color. This is probably not your situation, so I'd go discrete.

Assuming you're not making the next Photoshop, I would make enough discrete options to cover your uses. That is, if the average user needs to use ~10 different colors, give them somewhere between 20 and 30 and see how it goes in user testing.

Use a paper prototype to explicitly test some key scenarios that require a lot of colors. See how users react.

And, I'd probably stay away from black on black. Making options like that just doesn't seem to make a lot of sense. (Unless your users explicitly want to hide things or make them confusing for others. Could be interesting for a game, but probably not what you're after.)

Answer 5

If you limit the options, you have to cover all use cases or you'll fail some of your users. How confident are you that your options cover all use cases?

Some use cases you might not have considered:

• photo-sensitive: black/white and white/black are actually terrible for some users; it's too high-contrast/bright. Those users will need shades of gray or brown/beige instead. If you hard-wire your text choices to black/white and offer, say, 16 background colors (half light, half dark), that won't be good enough.

• color-blind: are your reds, greens, and yellows really as distinctive as you think?

• categorization: as pointed out by Aadaam, users might be attaching semantics to similar-but-not-identical colors, and if you take away the similar colors that won't work.

• consistency with other applications: your application is not the only software the user uses; if you provide similar functionality to some other application that he also uses, he may try to customize the two applications in the same way for easier transference.

Given that you already have the more-permissive color scheme, the question should not be "why should I keep it?" but "why should I remove it?". If the user cannot harm anyone else and can potentially benefit himself with more color options, why not let him do that?