David Mauro - Designer

canvas:

Drawcast is a rambunctious fun bundle of writers and artists who collaborate on Ustream to create drawings and stories. You can see some of their efforts in this podcast, playing around with Canvas shortly after we launched the private beta.  

They’re back hanging out on Canvas today at 3PM EDT, drawing and remixing in the Drawcast group. Come by and say hello! 

This is happening in an hour, come join in!

If you’re trying to log into OS X Lion and the login prompt doesn’t seem to be working, don’t keep trying to enter your password because you’re probably just posting it to the Skype chat that you’re in.

Yeah this happened. Everything was hidden behind the login prompt, the password input even had the blue outline indicating that it was taking the input and it appeared that my keyboard was just simply not working. What was actually happening was that Skype had focus somehow and I was posting my password, several times, into a chat room I was in.

I guess it was time for a new password anyways… ( -_-)

Recently I took on the challenging task of designing a color picker for the Canvas remix editor. The pre-fab color picker we had been using was clearly not working out (most users did not stray from the default #F00 red). The problem is that many of the people who are using the remix editor have never even touched a photo editing program before, while others are professional graphic designers. We needed to design for both novice and advanced users, and we needed to do it in a small enough space to fit into our remix editor’s toolbar.

To define any color in the full range of over 16 million colors your computer can reproduce, you need three values: either red/green/blue or hue/saturation/value. So while we can offer novices a color palette to choose from, the advanced users need fine control over at least three values to create any color they need.

Above is the default color picker in Photoshop. It’s a good example because it allows definition by HSV (also called HSB) and RGB, and it allows the values to be manipulated by entering values in a text field, or by dragging sliders.

Seeing as there are three vectors that need to be manipulated when selecting a color, you can give each it’s own slider, or you can combine two of the three to reduce the amount of clicks required by the user.

Photoshop allows you to adjust which two you combine, but the default as shown above is to combine saturation and value with hue off to the side. This is the best solution because saturation and value map at a much closer ratio. Here’s what MS Paint’s color picker looks like with hue combined with saturation and value pulled out:

The problem is that when selecting your color, you’re often left trying to drag carefully in one direction without deviating in the other. Hue packs a lot of information into it’s single vector, so ideally the user would have more precise control over hue than he has over saturation and value.

So if we combine saturation and value and separate out hue, we need to make the hue slider larger, but without taking up much more space. Deviant Art’s Muro image editor has an interesting solution to the problem:

Here they’ve given the hue selector as much space as the saturation and value combined. The problems with this approach is that now we’ve doubled the space the color picker is taking up, and we’re dragging in a circular motion, which is more cumbersome than a vertical or horizontal drag. They’ve significantly increased the space being taken up, but we’re not seeing a significant enough increase in precision of hue selection.

The solution I arrived at is similar in that the hue is being wrapped around in a loop, but it’s been wrapped around the saturation and value slider so that when dragging the hue slider you are simply making vertical and horizontal drags.

So now we have a color picker that satisfies all our needs. The color palette is immediately available for novice users. Advanced users can either type a hexadecimal RGB color into the text input (which doubles as the color preview), or click on it to open and use the advanced color picker which gives appropriately precise controls over hue, saturation and value. And it all sizes down to 150 pixels reasonably.

It could still stand to be prettied up, but I’m pretty happy to have created a color picker that I enjoy using more than Adobe’s.

Anonymous asked: dmauro, I love you. You're one of my favorite canvians. Question mark.

Love you too, Anonymous. Exclamation mark.

The conversation around metrics and design seems a little silly. As a designer my job is to make something that people will use. If something can give me a yes/no answer to the question of “does this design work better?” then why would I not be psyched to have that answer?

If we’re talking about a question as precise as “which shade of blue do users prefer,” then the problem is that you need to A/B a new design that gets results that dwarf any gains made from changing a single hue.

I have been sort of skeptical of CoffeeScript based on my limited knowledge of it for a few simple reasons: I don’t particularly care for the indented block style; the “human readable” style, while easy to read, is not as easy to scan; and I don’t feel like I need a layer of abstraction on top of JavaScript.

But there are enough CoffeeScript headlines popping up on HackerNews that it’s clear I needed to read a little bit about it, so that’s what I did today. So first with the bad:

• Debugging: Tracing errors back from the compiled JavaScript to your CoffeeScript is going to be a pain in the ass until there are add-ons or direct support from the browsers to handle debugging.
• Var as a reserved word: This seems like a minor issue weighed against the benefits of CoffeeScript handling your var declarations for you, but you can’t shadow outer variables. It would be nice to be able to explicitly gain control of the var keyword.
• [edit: forgot to add this] Comparison conversion: CoffeeScript automatically makes == become === so coercion comparison just isn’t an option as far as I can tell.

So other than the fact that I prefer all those brackets, braces and semicolons, that’s really the worst of it. And here are some of the things that make me want to give CoffeeScript a try:

• Default arg values: This simple addition will help clean up my code quite a bit.
• Using reserved words as properties: JS has too many reserved words, and it would be really nice to be able to use them without having to worry about quoting them.
• Until and Unless loops: I think these will make code easier to scan and have often found myself wishing I had this option in JS.
• Chained comparisons: This reads much better and is much more intuitive to write.
• Classes: Classical inheritance is just messy in JS. CoffeeScript cleans it up nicely.

There’s enough there that I’m going to give it a try to see how I like it. I have a small project I recently started and I’m curious to see how much smaller it will get in CoffeeScript. There’s also the claim of “tends to run as fast or faster than the equivalent handwritten JavaScript,” so I’ll have to check performance before and after as well.