This is an idea spun out of conversation with Ben and Paul at last night’s LRUG – a physical device for alerting developers working in a continuous build environment as to how far they are from the trunk.

Because of the rate of change on an agile project, it’s important to keep your own personal codebase as close to the trunk as possible, otherwise you’ll spend a long while working on code that doesn’t fit with the current state of the system, or working around issues which may have been fixed. It’d be good to have some sort of physical display to alert you to this, rather than relying on typing svn up every five minutes.

Enter the continuous build barometer. It’s dead simple: it’s a dial you connect to your computer via a USB connection. The moment you do a checkout, the needle sets itself to 0. And then, as your codebase diverges from the trunk, the needle indicates how far (proportionally) your code diversifies from the original. And, of course, the moment you check in, the needle resets itself to zero.

Ideally, the continuous-build barometer needs to be made out of something reasonably heavy – I have this image of brass and wood, much like this example, if only to convey the weight that “checking in often” actually carries. In terms of making one… dial indicators seem to be quite pricey. It’d be easy to prototype with something like this ten-bar LED display, an Arduino board, and a short-ish script to compare the trunk with your local version, cronned to run regularly. Of course, I think the physical nature of the object is important, but it’d still be interesting to see what a working version in any form looked like.

That was one of my favourite things this month’s LRUG gave me, and it’s not really even code. Now: who wants one?

It’s been about two week since I went to FOWA2007 in London, and I’ve been meaning to write it up for a while. It was an… interesting experience, and I’ve been trying to find a way to frame why that is. Speeding on a train back from the provinces to London seemed a good way to concentrate my thoughts.

Last year’s FOWA was great: a one-day conference for

A straight-up announcement post here: I’m going to be at Future of Web Apps in Kensington for the next two days. I’m reasonably identifiable (redhead, sideburns, goatee) and I’ll probably have a neck-badge that says “Developer” on it.

I think it’ll be even better than last year’s, in part because it’s spread over two days, and there are more gaps for socialising. So if you don’t see me in the hall, grab me outside it. I won’t be around on the Tuesday night due to prior commitments (The Long Blondes at the Astoria, hurrah) but will definitely be up for much in-pub ranting on the Wednesday. So: do say hello if you’re going to be there, and maybe we can bat some ideas around.

I was, partly in jest, invited to join tourfilter by a friend today. What started as an elaborate social-networking joke turned into a really positive piece of user-experience I wanted to document.

What I wanted to share was the sign-up process. Normally, with social-networking sites, you have to endure some form of semi-elaborate sign-up before you’re allowed in… and then you start having to ram content in. Tourfilter neatly turns that on its head.

Tourfilter is a site that scrapes listings pages for information about your favourite bands, generating emails, RSS, or iCalendar files to keep you up-to-date. It’s a really simple, single-minded site that gives music fans personalised listings.

For a new user, there’s a form on the left of the homepage with a large textarea, in which you write the names of bands you like. I entered one band name… and via Ajax, a huge list appeared to the right of the field, of other bands I might like. Of course, I did, so I started clicking on some of them to add them to my form… and the process slowly became addictive. Pretty soon, I had a long list of bands I’d be potentially interested in seeing in London. The Ajax made it very compelling, and pretty quick. And, of course, the more bands I added, the more useful the fly-out Ajax list was, because it had better data to compare against.

Underneath the text box are three fields: username, password, and email address. Once you’ve filled them out, all you have to is click the submit button… and your brand new account is created, with all the information you’ve just filled out.

So tourfilter reverse the customary process: you add your initial data first, and only then create the account. Once you’ve done that, everything’s ready to go. I really enjoyed this experience: the Ajax element quickly showed the value of the site, which only increased the likelihood of me signing up.

I think tourfilter still has a little way to go – sometimes its scraping leaves something to be desired – but still felt its compelling sign-up process was worth commending.

Around a year or more ago, I had an interview for a job (which I was offered, and which for various reasons I had to turn down). There were two great questions in it:

“Give me an example of design you love,” and “Give me an example of design you hate“.

The first was tricky. I needed something I not only loved but that I could explain why loved it (and not sound too cliché at the same time). In the end, I went with the Nintendo Wavebird, for its use of technology (the wireless), texture and shape (both of which vary across all buttons).

It was much easier to find something I hated, though. I’ve always hated – with a real passion – the automatic loos on trains, such as those on Virgin. They drive me absolutely mad.

They have three buttons inside: open, close and lock. When you step inside one, the “close” button flashes, indicating you should press it. Fine. Once you press it, the door shuts, and the “lock” button flashes, indicating you should lock it. Again, fine; you push lock and hear a clunk. What frustrates me is that then the open button flashes and so, obviously, you push it, and the door wanders open, leaving you frantically hammering “close” to stop looking like a wally who can’t work the doors. It’s not just me, either; I’ve seen lots of people do it!

I was asked how I could improve this design.

I think the problem comes in the use of three buttons. Open and close as two seperate buttons I can take, but lock isn’t really a button – it’s a toggle; you need to be able to see both locked and unlocked states. So I suggested keeping two buttons for open and close, and implementing a lever for locked/unlocked. Ideally, the lever should be horizontal, to indicate the locking motion, and to distinguish itself from the two vertical buttons.

It’s a design problem I run into quite a lot, usually on the web, where a collection of radio buttons are used not to switch between several states of one condition, but to represent several unrelated ideas.

So imagine my surprise when, on the train home this morning, I found that the First Great Western toilets have been substantially modified (see left). At the top, open and close – and then a flick left/right switch for locking, with a red light for ‘lock’ and green for ‘unlocked’.

Much better. I didn’t make a mistake, and was confident that the door was locked (or unlocked) thanks to the visual indication of a lever. It makes me wonder if someone from FGW was sitting in on that job interview…

You might notice a new design and layout for this site flickering on and off for the next few days. I’m just bringing some final tweaks to bear, you see, and ironing out some wretched IE bugs. It’s all part of a way to encourage me to write a bit more. Again.

So for now, please bear with me. The del.icio.us links are now on the righthand side; if you’re really, really interested in them, it’s probably easiest to be subscribed to my feed, where you’ll get everything.

d.Construct 2006 was well over a month ago, now, but I’ve simply been so busy since then that I just haven’t had a moment to write up my experiences.

d.construct is a “grass-roots” web conference in Brighton, run by the nice chaps from Clearleft. It only lasts a day, and, at £75+VAT, it’s insanely good value. I don’t want that last fact to go unnoticed. It was also a great lineup of speakers, including Thomas Vanderwal, Jeremy Keith, Simon Willison, Paul Hammond, Jeff Barr, and Jeff Veen. £88 just to hear all of them speak is, any way you look at it, a very good deal. And then, of course, there’s the all the networking and the chat and the the pub, with four-hundred web-types who descended on Brighton, which is often the highlight of any conference.

When I filled in my feedback form, I realised I didn’t have time to write what I really wanted to say. So I put down the improvements that were the easiest to fix (and, it seems, the most universally agreed upon): more legroom, more power sockets.

Beyond that, what I had to say wasn’t so appropriate for a feedback form, as I’m not quite show how to improve upon my criticisms. But I still think it’s worth putting them down in writing.

At the heart of d.construct is a very good event. I enjoyed this year’s event a lot. But I think there are some areas that could perhaps be improved – or at least addressed – in future years.

First of all, the format. d.construct is much like the Carson Systems’ Future of Web Apps events – it’s a series of speakers talking, one at a time, one after another, in a big auditorium. It’s not stranded or streamed. At the same time… it’s a bit intimidating in that people tend not to want to break out of it. The moment you introduce two or more strands, attendees begin to realise that perhaps they don’t want to go to either talk, and so they decamp to the back room to mingle and chat. And d.construct had a great “back room”, with power, refreshments, and tons of space. As it was… everyone piled into the hall for every session, regardless of whether or not it interested them. Quite often, I saw a number of people ignoring the talk to concentrate on their iPhoto session, and then dumping their latest pictures onto Flickr. I’m sure they could have done that “out back”, or, more likely, found people to talk about things they were interested in. I cut Aral Balkan’s Flash talk – because, whilst I’m a client-side developer, I have zero interest in Flash – and was disappointed to only find about six people hanging around out back, and one or two in the pub around the corner. The chat I had during the session I skipped was great.

I also found the angle a little curious. d.construct, whilst pitching itself as a “web application and Web 2.0 conference”, is very much a web conference coming from the front end. I was disappointed when Jeremy came over very apologetic that he was even showing code at all during his presentation – and it wasn’t really very complex at all. In the end, no matter how many wireframes and PSDs are drawn, websites only exist in code, and I get frustrated when people have to shy away from that kind of expression.

Similarly, I was a bit frustrated that he managed to talk about REST without mentioning HTTP verbs (GET/POST/PUT/DELETE), as they’re as important to the RESTian concept as the URL structure. But I can understand – given what appeared to be the conference’s target audience – why this was the case. It also meant that Jeff Barr got a slightly raw deal – he was going first, and he was easily the most “corporate” of the speakers, but I thought his talk was a great balance of explaining some of the awesome work Amazon are currently doing, and demonstrating how real users have made use of it. But, if you don’t get the importance of S3 or especially EC2 (which is, in some ways, revolutionary), it just sounds like corporate buzzwordiness.

And I was also frustrated by this because the more general-purpose or front-end talks – Thomas Vanderwal’s IA session on tagging (a pretty complete history and explanation of tagging) and Jeff Veen’s phenomenal closing session – were both reasonably high-level (in terms of what they’re discussing) and well received. And for good reason – Veen was absolute dynamite.

Maybe it’s because Clearleft themselves are, primarily, a front-end consultancy, but I don’t want to trivialise things that far or make such bold assumptions. It might just be that it’s the best common ground over which to bring people in the UK together. But I think there’s interesting things about development to be expressed to general audiences, especially given that buzzword-of-the-moment AJAX is all about the point where the front- and back-ends join. And I’m concerned that whilst Web 2.0 (however you understand that phrase) advocates a more holistic, interconnected web, the design and build process is becoming ever-less holistic.

But I don’t want to be a complete downer. Like I said, it was a great-value conference, at which I met many interesting people, and the speakers were all excellent. Maybe next year it will move to multiple tracks; maybe it’ll broaden its scope. Either way, I’m still going to go; it’s a great mixer of an event, and it’s nice to go to something that’s not in London for once. My congratulations to Richard, Andy, and Jeremy on its success; I hope my comments aren’t taken too hard nor too negatively. And I hope you can see why I didn’t quite have time or space to condense them on the feedback form.

Update: One thing I forgot to mention, that’s surely worth a big plus point, is that the “female quota” at this conference was very high. I’m sure that sounds awfully patronising, but given the amount of coverage of “why women won’t go to conferences” (see Mike Kuniavsky on this), it was interesting to note a percentage well into the double figures – I’d say about 20%+, at least. Whether this is because of the front-end focus – or, rather, the less-threatening, less-technical focus – I don’t know, and again, don’t want to trivialise. But bonus marks for this, for sure.)

Recently, I was lucky enough to give a talk at Railsconf Europe, which I co-presented with my colleague Gavin Bell. Now, I’ve never presented a talk with anyone else before, so there was going to need to be a degree of co-operation between the two of us to make the talk and the presentation work out OK.

Fortunately, the division-of labour in the talk itself wasn’t a problem: we both had directions we wanted to take the talk in, and, after a few meetings over lunch, we had worked out a way of brining everything together under one roof. The content wasn’t going to be a problem. However, piecing together the presentation in Keynote was going to be a little more complex than usual, given that each of us was writing our parts of the talk seperately. However, I managed to devise a very simple way to rapidly prototype the presentation without wasting too much time in Keynote. Of course, when I say “devised”, I am aware that many other people might also do this; however, I hadn’t read anyone describe this technique, so I thought it’d be worth sharing.

All you need to do this is a notebook, some wide post-it notes, and a pen. Split the deck of post-it notes between you and your co-presenter. Each post-it note represents a slide. As you’re writing your talk, write the title of each slide (if you want, you can also add notes on what you’d like to appear on the slide) on a post-it note, and place it on one side. Then, once you’ve both got all the post-it notes done, you can sit down together with the notebook and start to place them in order – one post-it note on every other page.

“Every other page” is important to the success of this, because you’ll often find you want to rejig the presentation, or add extra slides, and by leaving a page blank between each slide, you’ve got one extra slide’s leeway before you have to re-jig too much.

I also put the opening/closing slides at the very front and very back of the book, as they were pretty much immutable. Once we’d got all the “slides” in the right order in the book, it was very easy to draw them up in Keynote on my own and be pretty confident that they wouldn’t need much changing. In the end, we altered a few lines of text and the order of one or two slides, but that was it.

That’s probably all best explained with a video, so Youtube here we come:
I’m probably going to go as far as using this technique for future talks on my own. With this process, instead of trying to write the talk, write the slides, and design them all at once, you can focus on the content first, and, once that’s finalised, concentrate on the design later. It certainly worked well for Gavin and I trying to write a talk together. And, whilst we’re on the subject of presentations, Tom Carden raises some good points about the tools you do them with.

Finally, as a sample of the finished product, this is one of my favourite slides that I’ve ever made:

So I’m only the umpteenth person to say that I’ve just ordered a whole bunch of MOO minicards. Having seen them from some friends already, I can tell you that the quality is great, the size is lovely, and the colour repro is spot on.

What I find really interesting about them, though, is that MOO describe them not as “business cards” but as “calling cards”. I really like that; it’s an important distinction, and a nice reminder of the origins of what we now call business cards. They’re tools of etiquette, ways of seeking permission to see someone and also permission to engage with them. They’re also a signifier; in the old-fashioned usage (seeking permission to see someone) the card with a name on is presented before the card’s owner is even permitted inside the house.

And, as Wikipedia points out, we exchange business cards to swap not only contact details, but business interests. When I look at the cards I have, even though many of them are from friends, it’s still a reminder of what they do rather than who they are. We all have so many ways to contact us now – mobile, email, IM, VOIP, MySpace – that it makes sense to resurrect the idea of cards precisely for personal usage. No business strings attached, no implicit sell; just me, my name, my number.

That’s why I really enjoyed reading the comments on this Techcrunch post about MOO, which Tom linked to.
“Handing out photographs as business cards is confusing, difficult to read and unprofessional,” writes one commenter – but he misses the point, because these aren’t really intended as “professional” tools. The fact they can be used as business cards is, in fact, a nice side effect, and several commenters in that thread point out the value of photographic cards for trade purposes. But really, they’re just ways to remember who people are, and perhaps how to contact them.

I love the revival of a simple, physical identifier in an age when we’re drowning in digital identifiers that we keep losing. I also love that it’s designed for constant, ongoing delight (rather than just an immediate “wow!”). I guess that comes from the certain satisfaction in pulling out a physical thing you’ve had a part in making. Chris remarks that “the best thing is that each picture has memories and stories attached”. He’s spot-on. Every time you give one away, you’re not only giving away an identifier – my name, my number – but also a descriptor – “here is a photograph I like, which I took, which in part describes me through my taste”.

I’m looking forward to receiving my free set, and then I’ll set about getting some more. Demand will no doubt be huge, but I’m sure Stef and the team will cope. More to the point, I can’t wait to see what else MOO are going to do in this field. There’s so much exciting content around the web (besides text), waiting to be dumped out – I commented on the value of hard copy at Reboot in June. As such, surely there’s never been a better time to be in the print business?

I recently did some consultancy for openTrust, the parent company of openDemocracy, and now that the project in question – chinadialogue – has gone live I wanted to mention it, mainly because I’m so impressed by how the final product turned out.

The best way to describe chinadialogue is as an entirely bilingual online publication about the Chinese environment, built on top of an entirely bilingual CMS.

By “entirely bilingual”, I mean that all content appears (eventually) in both English and Chinese on the site – not just links and headings, but the full text of every article, and of every comment. The site is designed so that whilst everything appears in both languages, the original source language is always highlighted. The translation between languages is performed by Mark 1 Human Beings, incidentally. I found a certain frisson to seeing English and Chinese standing side-by-side everywhere you look; it feels very subversive, given all the issues around Chinese state censorship.

My role in the project was admittedly very limited. I did some early-stages exploratory work around publishing platforms, considering whether to use a pre-existing, open source CMS/blogging tool and extend it either through plugin APIs, or a more major fork of the source code, or whether to build from scratch – and if so, in what. One of the major factors in this decision was the bilingual nature of the project: extending any existing system would require heavy use of the plugin API, but that would mean one language’s content would exist as the primary “content” for an entry, and the other would be banished to the meta-fields. Given that either could come “first” in the workflow of the site, and that both are of equal importance, I suggested that both should also be of equal importance in the database schema.

In the end, they went with the final option, and built the project from scratch in Ruby on Rails. We discussed this option at some length, as whilst there was a strong internal desire to build in Rails, the first thing that comes to mind when you say “Chinese” and “Ruby” in the same sentence is “holy Unicode support, Batman!”

But Unicode-in-Ruby can be stepped around if you know what you’re doing (and try nothing too fancy), so it’s great to see that they not only made Rails work for them – and, by all accounts, had a good time doing it – but also they managed to step around one of the more common Ruby gotchas.

Best of all, I note that they’re planning to release the CMS that runs chinadialogue as open source towards the end of the year. I’m really looking forward to seeing some of that code.

All in all, a pleasant experience, and very cheering to see the results. If you’re working on social publishing projects of any form, and want someone to throw ideas around with (for a reasonable rate) do get in touch.