Journal tags: hackfarm

Every year at Clearleft, there’s a week where we step away from client work, go off the grid, and disappear into the countryside to work on something fun. We call it Hack Farm.

Hack Farm usually takes place around November, but due to various complexities, Hack Farm 2014 wound up getting pushed back to the start of 2015. Last week we formed a convoy, stocked up on the bare essentials (food, post-it notes, and booze), and drove west for four hours until we were in Herefordshire at a place called The Colloquy—a return to the site of the first ever Hack Farm.

I kept notes on each day.

Day Zero

We arrive in the late afternoon, settle into our respective rooms, and eat some wonderful home-cooked food. After dinner, even though everyone’s pretty knackered, we agree that it’s best to figure out what everyone will be working on for the next few days.

Everyone gets a chance to pitch their ideas, and then we all do some dot-voting to whittle down the options. In short order, we arrive at four different projects for four different teams.

One of my ideas is chosen. This is something I’ve been pitching every single year at Hack Farm, and every single year it ends up narrowly missing out. This year, it’s finally going to happen!

On my team I’ve got Rich, Batesy, Andy P, and Tessa.

Day One

We choose a room to use as our home base and begin.

We start by agreeing on a hypothesis—more of an assumption, really—that we’ll be basing everything upon:

People are more like to give blood if they are not alone.

We start writing down questions that people might ask related to giving blood. Some of these questions might well turn out to be out of scope for this project, or can already be better answered by an existing service like blood.co.uk e.g.:

• Can I give blood?
• How often can I give blood?
• Will it hurt?
• How long will it take?

Other questions are potentially open to us providing answers:

• Where can I give blood?
• When I can I give blood?
• Who else is giving blood?

That last one is a question that doesn’t seem to be answered anywhere else.

We brain-dump potential data sources that answered the “who”, “when”, and “where” questions? The data from blood.co.uk could potentially answer the “when” and “where” questions e.g. when and where is the next donation? Data from Twitter, Facebook, or your address book could answer the “who” questions e.g. who are you, and who are your friends?

We brainstorm potential outputs of the project. The obvious choices are a website or a native app, but there could also potentially be email, SMS, or even posters and postcards.

We think about potential incentives for the users of this service: peer pressure, gamification, bragging rights, reassurance, etc.

So there’s a lot of divergent thinking going on: at this stage, there are no bad ideas (no, really!).

We also establish the goals of the project—what we would like to see happen as a result of this service existing. The very minimum success criteria is:

Someone gives blood who hasn’t given blood before.

There’s a follow-on criteria for measuring longer-term success:

A group gives blood regularly.

We split into two groups to work on a propositional statement, then come together to merge what we came up with. Here it is:

For people who want to give blood, who need encouragement and motivation, Blood Buddies brings together people you know to make it a shared experience. That way, you’re more likely to give blood.

Unlike blood.co.uk, it frames giving blood as a shared, rewarding activity.

Blood Buddies is a codename for now. The final service might have a different name, like Bluddies maybe.

After lunch, we start to work on user stories and personas. After a while, we think we’ve got a pretty clear idea for the minimal viable user journey.

Now we take a little break and stretch our legs.

When we regroup, we start researching technical possibilities (like Twitter authentication, GMail address book, Facebook contacts, etc.), while also throwing ideas around to do with branding, tone of voice, etc. James Box comes in and helps us out with a handy branding exercise.

In an effort the name the thing, we create a page filled with relevant words that might be combined into a name. Eventually we reach the “just fucking end it!” moment. The service is called “Blood Buddies” after all. The tagline is …drumroll… “Get plastered together!”

Meanwhile, having investigated the technical possibilities, it looks like Twitter’s API will be the easiest (relatively) to start with.

We write out our epics and create a little kanban board. We have our tasks figured out:

• implement sign-in with Twitter,
• create a style guide,
• mock up the homepage,
• mock up a sign-up form,
• and more.

Tomorrow everyone can assign a task to themselves and get cracking (some people have started already).

Day Two

After a late Superbowl night, we arise and begin tackling the day’s tasks.

I managed to get a very rudimentary Twitter sign-in working (eventually!) so now my task is to do something with the data that Twitter is returning …namely, storing it in a database. And because this relies on signing in with Twitter to get any results, this needs to get on to an actual web server as soon as possible.

Cue a day of wrangling with PHP, MySQL, OAuth, Git, Apache, SSH keys, and DNS settings …with an intermittent internet connection that drops out at the most inconvenient of times.

Andy is storyboarding the promo video that will help sell the story of Blood Buddies.

Meanwhile James and Tessa are hammering out a visual language for Blood Buddies. So the work is being approached from two different ends: the server side (how it works behind the scenes) and the interface (how it looks to the end user). In the middle is the user flow, and that’s what Richard is working on, also looking ahead past the minimal viable product to include features that can be added later.

By late afternoon the most basic server-side functionality is done, and the site is live at bloodbuddies.co.uk. Of course, there’s very, very, very little to see there, but at least our team can start adding themselves to the database.

So now the task is to join up the back-end functionality with the visual design and copy. As these strands come together, it feels like we’re getting back to a more collaborative phase: whereas yesterday involved lots of group activity, today was more splintered. But that’s going to change now that we’re going to join up the individual pieces into a unified interface.

Today felt quite productive considering that three out of the five people on our team are on cooking duty.

Day Three

Today is a day of rest. It’s a beautiful day. We go for a drive through the countryside, pop into a pub for some grub, and go walking on the hills.

Day Four

We’re down to just three team members today. Tessa is working on a different project and Andy is spending the day sleeping, puking, and generally recovering from a heavy night. N00b.

We get cracking on with integrating the visual design with the back-end functionality. That means bashing out some CSS. After an hour or two, we’ve got something basic in place.

While James works on refining the visuals—including a kick-ass logo—Richard is writing lots and lots of copy, and figuring out user flows.

Meanwhile I’m trying to get server-side stuff in place, fiddling with DNS and email; not my favourite activity.

Once the DNS is pointed to the Digital Ocean server, and with the Twitter sign-in working okay, we realise that we’ve actually launched! Admittedly it’s very basic and it needs plenty of refinement, but it’s a start.

We head out for the evening meal together. Just one more day to go.

Day Five

James starts the day by finishing up his kick-ass Blood Buddies logo.

Richard is writing and editing lots of witty copy.

Andy is storyboarding a promotional video.

I’m trying to get emails working, so that when someone you know signs up to Blood Buddies, we can email you to let you know. By lunchtime, we’ve got it all working.

Lots of the details are in place now: the logo, web fonts, an error page, a favicon …it feels good to be iterating on a live site.

After lunch, James, Richard, and I work on expanding out the home page. Once everything is in pretty good shape, we all come together (with Andy and Tessa) to talk about what the next steps could be after this minimum viable product.

There’s consensus that the most important step would be adding more ways of signing into the site, instead of just Twitter. Also, there’s a lot of functionality we could add if we can scrape the data from blood.co.uk

But that’s for another day. Right now we’ve got a barebones site, but it’s working.

We shipped.

Towards the end of each year, we Clearlefties head off to a remote location in the countryside for a week of hacking on non-client work. It’s all good unclean fun.

It started two years ago when we made Map Tales. Then last year we worked on the Politmus project. A few months back, it was the turn of Hackfarm 2013.

This time it was bigger than ever. Rather than having everyone working on one big project all week, it made more sense to split into smaller teams and work on a few different smaller projects. Ant has written a detailed description of what went down.

By the middle of the week, I found myself on a team with James, other James, Graham, and an Andy. We started working on something that Boxman has wanted for a while now: a simple little app for adding steps to a list of things to do.

Here’s what differentiates it from the many other to-do list apps out there: you start by telling it what time you want to be finished by. Then, after you’ve added all your steps, it tells you what time you need to get started. An example use case would be preparing a Sunday roast. You know all the steps involved, and you know what time you want to sit down to eat, so what time do you need start your preparation?

We call it Tiny Planner. It’s not “done” in any meaningful sense of the word, and let’s face it, it probably never will be. What happens at hackdays, stays at hackdays …unfinished. Still, the code is public if anyone fancies doing something with it.

What made this project interesting from my perspective, was that it was one of them new-fangled single-page-app thingies. You know the kind: the ones that are made without progressive enhancement, and cease to exist in the absence of JavaScript. Exactly the kind of thing I would normally never work on, in other words.

It was …interesting. I though it would be a good opportunity to evaluate all the various JS-or-it-doesn’t-happen frameworks like Angular, Ember, and Backbone. So I started reading the documentation. I guess I hadn’t realised quite how stupid I am, because I couldn’t make any headway. It was quite dispiriting. So I left Graham to do all the hard JavaScript work and concentrated on the CSS instead. So much for investigating new technologies.

Partly because the internet connection at Hackfarm was so bad, we decided to reduce the server dependencies as much as possible. In the end, we didn’t need any server at all. All the data is stored in the browser in local storage. A handy side-effect of that is that we could offline everything—this may one of the few legitimate uses of appcache. Mind you, I never did get ‘round to actually adding the appcache component because, well, you know what it’s like with cache-invalidation and all that. (And like I said, the code’s public now so if it ever does get put into a presentable state, someone can add the offline stuff then.)

From a development perspective, it was an interesting experiment all ‘round; dabbling in client-side routing, client-side templating, client-side storage, client-side everything really. But it did feel …weird. There’s something uncanny about building something that doesn’t have proper URLs. It uses web technologies but it doesn’t really feel like it’s part of the web.

Anyway, feel free to play around with Tiny Planner, bearing in mind that it’s not a finished thing.

I should really put together a plan for finishing it. If only there were an app for that.

In November 2011 we at Clearleft hired out a farmhouse in the countryside and left client work behind for a week and just hacked on something for fun. The result was Map Tales, which I’m very proud of.

We knew straight away that we’d want to repeat the experience in 2012. A few weeks ago we all disappeared into the countryside once again. This time the location was in Dorset and it was less of a farm and more of a manor house. We still decided to call the outing a Hack Farm …although Hack Manor has a nice ring to it.

Before we went away, we got together for a meta-discussion on how to approach the week. We didn’t want to decide what we were going to build before we got there (that’s part of the fun) but there was some talk about doing things slightly differently this time. For example, what if we weren’t setting out to actually launch something? What if the final deliverables were less tangible and more conceptual than that?

My initial reaction was to bristle at the thought of not launching something at the end of the week. After all, I thought, that’s the whole point of a hack day/farm/athon. But I came around to the idea. I think it’s because we succeeded in building and launching Map Tales in one week last year that I was able to accept the idea of doing something a bit different this time ‘round.

We brought some friends of Clearleft along: Mike, Brian, Emil, Andy, Kyle, and Jessica. It was a pleasure spending a week in the country with them.

In total there were eighteen of us there. That’s quite a lot of cats to herd when you’re trying to reach consensus on what to spend a week working on, but after some fun design games and exercises, we agreed on what we wanted to do. Surprisingly the area we all gravitated towards was in the not-so-sexy field of politics.

We designed a service called Politmus. The basic idea was to take the best of the “quantified self” movement and apply it to politics in the UK. The elevator pitch was:

The only personal political opinion tracker that gathers your stance on issues, for disenfranchised voters in the UK who want to feel more connected in a time when we have increased participation in everything but government.

Here’s how we imagined it working. Let’s say your MP is going to be voting on a question in parliament very soon. We’ll ping you with that question and ask how you would vote. Then we can see how well your answer matches that of your MP. Over time, we can start comparing trends: you and your MP; you and your constituency; you and the rest of the country.

There was a lot of research to begin with (not helped by the crappy internet connection), looking at how the UK parliamentary system works. It’s complicated. They Work For You was, unsurprisingly, a huge help in figuring this stuff out.

I got very interested in the potential input mechanisms for voting. A website with a form is the obvious choice, but what about some more old-fashioned media? A postcard? An email? A phone call? SMS?

I did some hacking on the Tropo API to come up with a telephone interface. You can try it on 020 3051 6587. I put together a little video sketch to demonstrate some of these interactions.

Meanwhile a whole lot of work was being done on the voting interface, displaying the patterns of voting over time, and all that good stuff.

One of the areas that yielded the most benefit (and was a real eye-opener for me) was designing an API for the service before any interface decisions had been made. This “API First” approach meant that lots of tricky problems were solved early on, without getting distracted by the implementation issues of which kind of screens (if any) would be displaying the data. It also meant that visual design and development could be done in parallel.

(By the way, the food at Hack Farm was superb. Jessica cooked amazing meals for eighteen people each night!)

By the end of the week, we had some pretty solid deliverables: design principles, some prototypes, an API, branding. But it’s a shame we didn’t actually get a working website. It would have been very hard work, but I like to think that we could have got a minimal viable product out the door.

But we do have something to show. We’ve put together a nice little website that documents the process:

Hack Farm

You can skip straight ahead to the product or can follow along with the day-by-day account.

I hope that the site conveys something of the flavour of this year’s Hack Farm. It was a lot of fun, mostly because of the excellent people gathered together in one place.

I had a good productive Responsive Enhancement workshop in Düsseldorf and Marc was an excellent host. But alas, I couldn’t stick around for the rest of the Beyond Tellerrand conference which was, by all accounts, excellent.

I made my way back to the UK post-haste and started playing rail parkour to get across the country to Herefordshire. There lies The Colloquy—the rural but very comfy location for Clearleft’s week of hacking in the countryside.

Casing out the joint

We called it Hackfarm. The idea was pretty straightforward. For one week we would sequester ourselves in a farmhouse (admittedly it was a farmhouse with a jacuzzi), decide on A Thing to build and then …build it.

Max and Mike graciously agreed to join us with their considerable dev talents. Jessica also joined us, rising to the considerable challenge of catering for a dozen people.

Planning the heist

We didn’t know what we were going to build, ‘though some people had some ideas. We spent the first evening listening to those ideas, discussing them and voting on them until we came to an agreement and decided what the project would be. The next morning, Hackfarm began in earnest.

Part of Hackfarm’s raison d’être was to try out some new things. In that spirit, Andy introduced to the Kanban method and we gave it a whirl.

Everyone got involved in the design process, splitting into ad-hoc groups to figure out personas, generate user stories and sketch interface ideas. It was equal parts hard work and really good fun.

The caper

As the ideas solidified, we shifted to our laptops, firing up graphics programmes and text editors, ready to get down to some building. Again, collaboration was the key. Developers and designers sat down together, pushing pixels and cranking out code.

By the end of the week we had a working website.

The reveal

It’s called Map Tales. It’s a tool to help people tell stories illustrated with maps.

Now there are plenty of map-based narratives out there on the web but many of them suffer from what Schuyler Erle calls red dot fever: a bunch of points shown on a map all at once. One of the design principles that emerged early on at Hackfarm was that the map was secondary to narrative. When you’re reading a story in a book, you don’t know where the next chapter will take you.

Compare this Google Maps narrative with the corresponding Map Tale.

It’s a simple narrative device but it adapts well to stories of all sizes. Rich put together a Mediterranean-spanning Map Tale for The Odyssey while I documented the tale of recreating shots from The Matrix in their filming locations in downtown Sydney.

The site went live on the last full day of Hackfarm but we’ve kept it quiet ‘till now while we sorted out some of the rough edges. I’ve been tweaking the small screen styles a bit while Andy has been working like crazy to finesse the tale creation process.

I know I’m biased but I really, really like Map Tales. I like that it allows anyone to tell a story and then share it or embed it on their own website. I like that doesn’t require any kind of sign-up or log-in process (you get a secret URL for every tale you create that allows you to go back and edit it). I like that it isn’t trying to be another social network.

And I really, really, really like the people who made this. I count myself very fortunate indeed to work with such a great group of smart and talented friends.