Posts tagged as firle

Weeknotes for Week 41 will be brief, I think, if only because they’re late.

Lots of little bits this week. My main work for myself this week was pushing ahead on Sore; by the end of the week, I had an end-to-end demo video to send to my collaborator and producer. I like video for this simply because it’s a hardware project; ultimately, there should be no visible computation, so being able to show it working end-to-end without manual intervention is exciting progress. Really satisfying work.

I did a short internal talk on Wednesday evening for a company, so a few days were spent rejigging it for the specific new audience. That seemed to go down well.

There was a short piece of work to slowly decommission Concert Club, which has reached the end of its prototype period. It was nice to take the time to wind something down properly: disabling long-running processes, scaling back server resources, leaving it up as an archive. Nothing’s worse than removing a site you worked on from the face of the world, and having to rely on archive.org to recover it.

I had another mentoring session with Michael, the film producer I’m working with through CreateInnovate. Good to catch up, and to see how last month’s session had percolated and come to fruition.

And, on Tuesday, I spent a day with PAN, working over some of the snaglist on Hello Lamppost and thinking a little about the future.

I have one of this weeks every couple of months: lots of little fragments, winding some things down, building others up; it feels bitty at the time, but lots of things move on as a result. It’s the kind of week that makes weeknotes really valuable.

Just before Week 40 began, we’d launched Hello Lampppost. The first week after a project launch is always a hard time to schedule: what problems are going to emerge in production – what are the issues of scale you might not have predicted.

By and large, though, it was a quiet week on Muncaster: a few minor fixes here and there, some performance tweaks, but, touch wood, no crises, which gave me some space to take it easy after Week 39’s exertions.

Not too easy, though – the thoughts at the back of my head that had been pushed to the back because of project-launch were now demanding their own space. That led to pushing several ideas forward:

• noticeable progress on Sore: rigging up all the hardware and proving the CPU doesn’t fall over; building a little “power distribution” board so I can power high current devices and a Raspberry Pi off a single PSU; getting all the necessary libraries in place. This felt like a big leap forward for a single afternoon
• Hacking together a very early prototype of Watchcroft, a game I’m tinkering with for my own sake. A few hours’ work led to a prototype controller (built out of a Freescale FRDM board pretending to be a HID joystick) and a prototype of the game mechanic in Unity. It’s very much not a game yet, but the thing I hoped would be entertaining is, and I think there’s a game to be made out of it. Not for a while though – I think I’m putting this on hold until late September, when a lot more client work is out of the way.
• A small piece of maintenance work on Firle: fixing outdate libraries, adding a piece of functionality that’d been needed for a while, and restoring functionality the broke in library updates. This ended up necessitating some time in Browerstack, which is becoing pretty indispensible (and saves me filling up my SSD with VMs).

So, despite intending to have a quiet, cooling-down week, I ended up doing quite a bit; not as easy to turn my brain off as I’d perhaps hoped, but moved lots of little things forward, and nice to think about other project alongside Hello Lamp Post again. Next week moves into more concerted prototyping/alpha on Sore, and a talk for a client.

A busy week, entirely spent working on Dundry.

Dundry is an interaction prototype for BBC Knowledge & Learning. The goal is to bring something to life in just enough fidelity to get a feel for how it works – to feel the material of the product in our hands, to see what works and what doesn’t, and to leave it in a state that product owners and stakeholders can play with for a while once I’m done.

To that end, I worked on some wireframes and interaction design to understand the scope of the project – and now I’m both bringing those to life, and tweaking the design as I go, based on the understanding I get from using it.

I’ve made good progress, I think, though it’s a very intense process. I go on deep dives into tangled knots of D3, emerging a few hours later with marked progress, and a sore head from callbacks and closures. Needless to say, it’s really satisfying: full of the best kind of fiero. It’s also been heartening to already see some of the interactions I hoped would be satisfying turn out to be exactly that.

There’s also a degree of material understanding going on. There’s a lightweight Rails back-end, but most of these interactions are within the browser, and written in Javascript. To that end, I’ve been wrestling with the DOM event model.

For instance: one interaction involves highlighting an element when the mouse moves over it. This was working reasonably well, but would occasionally flicker as the mouse moved vertically. It turned out that whenever the mouse crossed a “cursor” line I was drawing (representing the X-position of the mouse), it would fire mouseout on the hovered element – because in the browser’s model, it had moved out of the hovered element and over the cursor. I could have left the flicker in, but this is a really central piece of the work, that someone’s going to interact with a lot. So I rewrote the code, checking to see which element the mouse’s co-ordinates resided within… rather than which element was firing mousemove events. Was that more work? Absolutely. Was it the right thing to do here? I think so. Even in a prototype, certain elements need more polish than others, to show that they’re what we’re looking at – and in this case, the hover interaction needed to be solid.

And then, having done some work like that, I zoom back out to the high level to see how the whole thing is fitting together, before diving back down to some fine-grained Javascript.

Like I said, most of the time, hugely satisfying.

In other project news, given that Steve Bowbrick has announced my involvement, it’s probably worth decloaking Firle as Radio 3’s Musical Map of Britain. A nice tight project, and I’m really glad the Breakfast Show team are so happy with it.

Next week: more deep hacking on Dundry, with a short detour to Cambridge to speak at Culture Hack East 2013 about Spirits Melted Into Air.

Everything’s getting busy. I kicked off the week pushing through a bit further on Crowborough: getting to an end-to-end demo, checking everything works out.

I met a few people for various lunches to see what they’re up to, including some of the Makeshift crew.

In the middle of the week, I kicked off work on Dundry: lots of wireframing and thinking. Though the wireframes and interaction work were sent off on Friday, there’s a lot of detritus – felt-pen sketches all over my desk, exploring other avenues, seeing how things felt, before I committed them to vectors. Dundry is going to be occupying me for the remainder of the month, and the first week in March; it should be an exciting, busy project, with some really tangible outputs – once we’re happy with the sketches, the rest of the sketching will happen in code.

On Friday, Firle launched, and seems to have been well-appreciated by both the client and it’s users; always good to have a successful launch.

And at the end of Friday, I took Crowborough down to Berg, where I showed it at their Friday demos. I’ll write more about it soon: it’s a Little Printer publication, which takes a fairly obvious product – the to-do list – and re-interprets it in somewhat unusual ways. Playing with the various materials involved (paper, Bergcloud, SMS, and Little Printer publications) was entertaining and illuminating. And: a lovely platform to write code for.

Things are ramping up, then. Week 19 is primarily going to be solid, head-down work on Dundry.