Mappiness development

In the previous post I wrote about the chart for analysing Mappiness app data I made. In this post I’ll write about the process of making it. It’s like a director’s commentary!

As I wrote, I started this as another way to get better at using D3.js but it turned out that the bulk of the work was nothing to do with D3. I don’t know how long I spent on the whole thing, from initial idea to launch, but I’m guessing it would add up to maybe six full-time weeks? Eight? Wild guesses. But, looking at the thing it seems like way too long.

Balance

Near the beginning I remember thinking, “Ah, I see: when doing some kind of data visualisation, a large chunk of the work is in preparing the data, rather than working on the display of it.” That thought made sense early on because, even though the data was in decent shape I did spent what seemed like a long time working out what to do with it and how best to use it with D3.

But from this end of the project, with it finished, that data-wrangling seems like a small proportion of the overall project. Even displaying the data on a chart doesn’t seem like a major part of the work. Designing and developing everything around the chart — the descriptions of the lines beneath, the controls to show/delete/edit/duplicate them, and the editing process — must have taken at least half of the time. Which is annoying. Given I was aiming to improve my D3 skills, I’ve spent an awful lot of time laying out forms, processing submitted data, updating HTML, tweaking the interface design, etc.

D3

On the plus side, I am definitely more comfortable with D3 than I was last time around. Admittedly, another line chart isn’t stretching my skills hugely after the previous one, but there were a number of tricky (for me) issues I managed to figure out without resorting to asking on Stack Overflow. This is definitely progress.

One of the nicest things about the chart is the small “brush” chart that lets you select a focus area for the large chart. I can’t claim much credit for this because it’s a built-in D3 component, but it does highlight one of the things I find odd about D3. If I’d wanted to build something like that from scratch I’d barely know where to begin. But because the component existed I could follow the example, read a couple of blog posts, tweak a few things, and there we go! There’s a big gap between being able to adapt an existing example and creating an element, or an entire form of visualisation, from scratch.

Similarly, because examples and tutorials are usually simple in order to explain a single idea they rarely take account of issues that crop up in real world usage. Even if you’re able to adapt an existing example, working out how to handle edge cases is another matter.

For example, although I got the brush to work fine initially, changing the data displayed (i.e., if the user adds or removes a line, or edits the criteria used to generate one) caused problems: the top chart would ignore the selected focus and redraw the whole chart; and if the new data changed the range of the x-axis, the selected area would no longer be in the right place or the selected area might move off the end of the small chart. All of this was solvable but there’s a huge difference between being able to adapt a D3 example and understanding enough to handle your real world usage. I’m getting better at the latter — I don’t feel entirely lost — but I have a long way to go.

Time

It seems crazy to me that I spent so long on this thing that is going to be of use to a very small number of people. If any. If it was purely for my own use I could have made something that was Good Enough much, much quicker. But there’s something satisfying, to me, about trying to make something of a higher quality, that’s more presentable and useful. (This is the same reason I spent way, way too long on the unused Twelescreen.)

I’m always frustrated with how long graphic/UI design (as opposed to technical/code design) takes, and it’s no different if you’re doing the design with code rather than, say, Photoshop. For example, figuring out exactly how the show/delete/edit/duplicate controls should function and present themselves, and managing that nicely in the code, took many iterations and corrections beyond the point at which I had some rough, uglier controls “working”. But that polish, working out the UI logic (both visible and behind-the-scenes), is enormously satisfying, even while it’s frustratingly time-consuming.

And then there are entirely unplanned chunks of work that only seem necessary as the project goes on. It was only when I’d nearly finished that I realised only Mappiness users would be able to even see this thing I’d spent weeks on. So I decided to provide an option to have a go with random data. This ended up being a couple of days fiddling with code to generate data that, while random, was mostly believable. It’s a persona, a fake individual who is less happy at work than at home, who enjoys being with their partner and kids, who is a little more tired early and late in the day, who eats at meal times… this unexpected bit of work was good fun, a nice thing to crop up near the end of the project.

Tinkering

But there were many points where I wondered, “Why on Earth am I plodding on with this very work-like project when I could be sitting outside in the sun?” But I concluded that this is what many hobbies are like. A man in his shed making a cathedral out of matchsticks isn’t solving any important problems, and only a few people will ever see the thing, but while the process is sometimes tedious, overall it’s satisfying.

Similarly, I enjoy the doing of programming, improving skills, doing a good job, making a thing, even if it’s of little actual use. If this had been a client project it would have been finished more quickly, with more compromises. But with no client, no budget, and no deadlines, I could take as long as I wanted and get pleasure from the process of deciding how best to do everything, to keep trying things until I was satisfied, and to simply enjoy the process.

Having said that, this was very much a “work” project as opposed to a “fun” one. The initial aim was to improve my D3 skills and I only worked on it during conventional working hours. There are other projects I’d prefer to be working on which somehow seem “less worky” and so I feel guilty spending time on them unless it’s evenings and weekends.

I’m not sure I’ve got this right. I don’t subscribe to the “Just do what you love!” mantra as a recipe for life or career success but I sometimes wonder if I’ve got the balance wrong. Sometimes there’s too much time-consuming frustration compared to satisfaction. Maybe I’m trying too much? Maybe I need to know when to stop something sooner (or at all)? Maybe next time.

24 Jul 2014 at Twitter

24 Jul 2014 in Writing

Mappiness chart
I made a tool for close analysis of data generated by the Mappiness iPhone app.

24 Jul 2014 in Links

On this day I was reading