A new colour picker on Firefox for Android

alam

4

Choosing colours is always a fun part of any work that you do. You could be picking a single colour for a font family, or multiple colours for a site wide navigation bar, but the right colour can change a lot about the final outcome of whatever it is that you’re working on.

Our task was to design a colour picker that would be used on Firefox for Android and triggered through the HTML5 property, < input type=”color”/ >. While this seemed like a fairly straight forward request at first, the number of mock ups, revisions, and considerations quickly piled up. Knowing that this would exist on a touch device really helped narrow some design decisions down, but the wide range of use cases still added to the complexity of the task.

Android - Colour Picker sketch

We thought the best way to handle this would be to divide the experience into two parts. The first part would be targeted at the quick and simple use cases by providing a set of harmonious colour presets derived from our “Design Values” booklet. The second part (or “Advanced” tab) would be focused on the ability to fine tune and even create a custom palette of colours so that you could see how all the colours worked together as a whole. Here’s what we came up with.

Android - Colour Picker

The noticeable colour wheel that rests on the top will be loaded with the same presets as the first tab and you can cycle through them while adjusting them to match your specific needs. Being on a touch device also means that it might be a bit frustrating at times to work a slider with great finesse and so we also have input boxes below that are designed to provide a level of specificity that some may want. As an added option, you can also switch to enter in RGB values rather than HSB/V ones by tapping the label “HSB” next to the three input boxes.

While the “Advanced” tab is anticipated for the Firefox 29 release on Android, the first step of this colour picker is available now. Stay tuned!

4 responses

Post a comment

  1. Delapouite wrote on ::

    Great job guys.

    Will an alpha slider be available in a next iteration of this picker ?

    Reply

    1. alam wrote on :

      Thanks Delapouite!

      Alpha sliders won’t be available in this first iteration as you noticed but I’ve got some ideas for improvements in the works. In regards to picking a specific “colour” though, I think HSB/RGB will cover the spectrum pretty well.

      Reply

  2. Valentin Tsatskin wrote on :

    This looks really awesome.

    I was wondering about the saliency of switching between the different input types (HSB/RBG) of your design. Is pressing a text field label an action that Android users are used to? I ask this as I think the ability to toggle the different values may be missed. Perhaps some help text that indicates how to switch value types would be useful?

    I’d like to hear your thoughts about this issue.

    Reply

    1. alam wrote on :

      Thanks for the feedback and for pointing that out, Valentin. I’m glad you did!

      Originally, I had concerns with whether or not this would be obvious enough as well. As I was designing this, I really tried to focus on the goal of this “advanced” panel, the context in which it would be triggered, the types of users that would look to access it, and even what complimentary tools would be at the disposal of said users.

      While I agree with you that it isn’t obvious how the user can switch back and forth between RGB/HSB values, the trade off here was for better overall spacing/ tap-ability of all elements. Since the goal of this “advanced” panel was to allow the user to create, compare, and tweak multiple colours (in that order) in an innovative way, I felt it justified.

      In addition to this, I think that the specificity of a numerical value would be demanded by users that would more likely have access to tools that could give them the RGB/HSB equivalent, even if they couldn’t discover the ability to switch. On the other hand, users that didn’t demand that level of specificity were both less likely to have use for such an input type and could also have an easier time tweaking the colours of their palette with larger sliders and dials.

      Finally, the mobile context in which this UI/UX lives in plays a large part in weighing the trade offs. Due to the smaller screen, higher possibility for mistaps, and general nature of most large scale design work not happening on a small mobile device, I thought it best to first prioritize according to the goals of the project and iterate/ improve as feedback comes in.

      Reply

Post Your Comment