Blog-o! Notes from latte.ca

Mon, 07 Jul 2014

People love heatmaps.

They’re a great way to show how much various UI elements are used in relation to each other, and are much easier to read at a glance than a table of click- counts would be. They can also reveal hidden patterns of usage based on the locations of elements, let us know if we’re focusing our efforts on the correct elements, and tell us how effective our communication about new features is. Because they’re so useful, one of the things I am doing in my new role is setting up the framework to provide our UX team with automatically updating heatmaps for both Desktop and Android Firefox.

Unfortunately, we can’t just wave our wands and have a heatmap magically appear. Creating them takes work, and one of the most tedious processes is figuring out where each element starts and stops. Even worse, we need to repeat the process for each platform we’re planning on displaying. This is one of the primary reasons we haven’t run a heatmap study since 2012.

In order to not spend all my time generating the heatmaps, I had to reduce the effort involved in producing these visualizations.

Being a programmer, my first inclination was to write a program to calculate them, and that sort of worked for the first version of the heatmap, but there were some difficulties. To collect locations for all the elements, we had to display all the elements.

Firefox in the process of being customized

Customize mode (as shown above) was an obvious choice since it shows everything you could click on almost by definition, but it led people to think that we weren’t showing which elements were being clicked the most, but instead which elements people customized the most. So that was out.

Next we tried putting everything in the toolbar, or the menu, but those were a little too cluttered even without leaving room for labels, and too wide (or too tall, in the case of the menu).

A shockingly busy toolbar

Similarly, I couldn’t fit everything into the menu panel either. The only solution was to resort to some Photoshop-trickery to fit all the buttons in, but that ended up breaking the script I was using to locate the various elements in the UI.

A surprisingly tall menu panel

Since I couldn’t automatically figure out where everything was, I figured we might as well use a nicely-laid out, partially generated image, and calculate the positions (mostly-)manually.

The current version of the heatmap (Note: This is not the real data.)

I had foreseen the need for different positions for the widgets when the project started, and so I put the widget locations in their own file from the start. This meant that I could update them without changing the code, which made it a little nicer to see what’s changed between versions, but still required me to reload the whole page every time I changed a position or size, which would just have taken way too long. I needed something that could give me much more immediate feedback.

Fortunately, I had recently finished watching a series of videos from Ian Johnson (@enjalot on twitter) where he used a tool he made called Tributary to do some rapid prototyping of data visualization code. It seemed like a good fit for the quick moving around of elements I was trying to do, and so I copied a bunch of the code and data in, and got to work moving things around.

I did encounter a few problems: Tributary wasn’t functional in Firefox Nightly (but I could use Chrome as a workaround) and occasionally sometimes trying to move the cursor would change the value slider instead. Even with these glitches it only took me an hour or two to get from set-up to having all the numbers for the final result! And the best part is that since it's all open source, you can take a look at the final result, or fork it yourself!

[Posted at 11:53 by Blake Winton] link
Fri, 28 Jun 2013

In my previous blog post, I mentioned a tool I’m writing to make it easy for designers to link mockups to live bugs. But I didn’t mention that I had a reasonably-working version of the tool written in Backbone which I’ve decided to port to Angular. The reasons why are largely beside the point of this blog post, but I’ll try to sum them up by saying that I reached a point where Backbone seemed to be confusing me more than helping me, and Angular got a lot of good press at FluentConf this year.

So this morning’s task in the re-write was to re-hook up the Persona integration. I had read recently that when you had a lot of dom-manipulation functions, you should probably put that code in a directive, and since I hadn’t written an Angular directive yet, I figured this would be a great time to learn how. Writing the html was pretty easy, of course, and most of the code from the existing implementation (which was largely based on the code from the express-persona readme) could be ported over fairly quickly. The only tricky part I ran into was figuring out that I needed to include restrict: 'E' in the Directive Definition Object. After I was done, I noticed that there really wasn’t that much in the code that had anything to do with the tool I’m writing, and thus I pulled it out into a separate repo so that other people can use it.

And with that, I announce Angular-Tools, a repo containing one or more tools which you might find useful if you build Angular apps. As always, pull requests and bug reports welcome!

[Posted at 15:16 by Blake Winton] link
Fri, 14 Jun 2013

One of the things I’m working on as part of my job1 at Mozilla is a tool to make it easy for designers to create mockups that are linked to live bugs, similar to the ones at Are We Pretty Yet. Now, I’ve got the background showing up, and the bugs overlayed on top of it, but as it stands, I’m requiring the designers to draw the lines connecting the bugs to the various areas in the mockup right on the mockup itself! This is obviously a fairly terrible idea, since it makes it much harder than it should to move stuff around after the fact, and requires a ton of up-front planning when creating the initial image. But what are my other options?

I thought for a while about layering a canvas element over the mockup; it would let me draw whatever shapes I wanted to, but passing the click events through to the mockup seemed like it would be fairly annoying, and I don’t think the connecting lines should appear in front of the boxes showing the bug details, which adds another wrinkle. Then, over lunch, I started to wonder what it would look like if a 1px by 1px black square got stretched and rotated with CSS… So I took some time after lunch, and played around a little, and it seems like it just might work! Give it a try, let me know if you have any ideas to make it better, and feel free to take the idea anywhere you think it might be useful!

Update: In the comments, Andrew points out that I could use a 1px by 1px span instead, which would make it much easier to change the colour of the line, so I’ve linked to his jsfiddle instead. :)


  1. Sometimes I still can’t believe how lucky I am to get to do this stuff all day, and get paid for it!  

[Posted at 14:57 by Blake Winton] link