One of the annoying things about Twitter is that sometimes I want to tweet something, but I don’t want to actually read anything from my feed (because I’ll surely get distracted). So I wrote this trivial, minimal piece of python code to tweet from the command line.

This continues the set of notes I started on the previous post.

At this point, VisWeek 2012 is just about halfway done, and there’s tons to write about, but I’ll try to keep these short by sticking to one day at a time. VisWeek now runs four parallel tracks for the best part of a week, so there’s no way I can tell you about everything that is happening out here in (today, surprisingly sunny!) Seattle. But I will tell you about what I think is cool. The usual caveats follow: omissions and mischaracterizations are all my fault.

This series of posts is a tour of the design space of graph visualization. I’ve written about graphs and their properties, and how the encoding of data into a visual representation is crucial. In this post, I will use those ideas to justify the choices behind a classic algorithm for laying out directed, mostly-acyclic graphs.

Here’s a Javascript-specific software engineering problem I’m considering within Facet. I’m trying to decide how (or even whether) to approach type-checking in the API, and I’m looking for input.

This series of posts is a thorough examination of the design space of graph visualization (Intro, part 1). In the previous post, we talked about graphs and their properties. We will now talk about constraints arising from the process of transforming our data into a visualization.

I’ve been playing around with the HCL color space. HCL, if you’ve never heard of it before, is a color space that tries to combine the advantages of perceptual uniformity of Luv, and the simplicity of specification of HSV and HSL. HCL is an improvement over HSV and HSL, but it is not exactly ideal: there is a nasty discontinuity at some bits of the transformation! I have been trying to find a way around this, but I’m stumped. Let me explain, and maybe you can help me.

This series of posts is a tour through of the design space of graph visualization. As I promised, I will do my best to objectively justify as many visualization decisions as I can. This means we will have to go slow; I won’t even draw anything today! In this post, I will only take the very first step: all we will do is think about graphs, and what might be interesting about them.

Say you are given a graph and are told: "Tell me everything that is interesting about this graph". What do you do? We visualization folks like to believe that good pictures show much of what is interesting about data; this series of posts will carve a path from graph data to good graph plots. The path will take us mostly through well-known research results and techniques; the trick here is I will try to motivate the choices from first principles, or at least as close to it as I can manage.