Monday, 25 February 2008

Thoughts on FOSDEM

We've just spent the weekend in Brussels attending the FOSDEM (Free and Open Source Software Developers' European Meeting) conference. It was a slightly unnerving experience for me; the first time I'd been in an open source development environment other than TiddlyWiki, and made stranger yet by the fact I was probably the only non-developer out of 3,000+ attendees!

For a free event (well, run on donations), it was very well organised. The Université Libre de Bruxelles donated their facilities, and a veritable swarm of organisers gave up their time and energy to keep things moving. The event had a shoestring feel to it, with signs printed on cheap paper and held up with gaffer tape, but more than adequate for our needs - and in sharp contrast to the glossy presentation at Le Web...

And the good organisation was reflected in many of the projects on display. Popular open source organisations such as Mozilla, FreeBSD, SUSE, Gnome and KDE were all present and showing off their wares. The Mozilla track in particular was very interesting; they're just about to release version 3 of Firefox, and the level of organisation in the Mozilla community is impressive. Here's the overview slide.

I've kind of given up trying to discern between the different Linux distributions. Listening to the earnest and passionate developers argue their preferences helped me understand that the main differences are under the hood. I know I'm in a minority of one here.

We were obviously thinking about how TiddlyWiki could or should be represented at a future event. It certainly wouldn't look out of place if it had a stall (note: a TiddlyWiki stall rather than an Osmosoft stall, of course), and there were plenty of people there who had heard of the project. Maybe some developer sessions there next year then.

Brussels itself was very nice, by the way, and a world away from the drab, grey EU-focused town I was expecting. We gorged ourselves on waffles, Belgian beer, mussels, chocolates and other Belgian goodness. Nightlife was lively, and the main square was charming. I've uploaded a set of photos to Flickr.

RippleRap Update

Here's a quick RippleRap update!

February has been a slow month, partly due to several Osmosoftonians taking holidays (including me), but also other commitments have taken precedent. However we are still on track to present RippleRap at BlogTalk (3-4 March 2008), and we're already close to having a version ready to go based on the version used at Le Web.

The main development in the last week or so has been the creation of an agenda-builder by Paul Downey. There are two parts to this; scraping agendas from conference websites, and creating them in RippleRap. The former has turned out to be pretty difficult, because very few conference organisers are using standard formats (such as microformats) yet. So Paul's focus has been on creating a form that allows people to manually create an agenda item complete with microformat-goodness. First efforts can be seen here. This week we'll be focusing on getting the agenda into the BlogTalk edition.

Secondly, Phil Hawksworth has created a Twitter client that allows users to send updates straight from the RippleRap, as well as viewing their own twitter timeline in RippleRap. The main benefit here is that conference wi-fi goes up and down, but your latest history will always be visible. This tool will be integrated into the BlogTalk edition when Phil returns from holiday on Wednesday.

Finally, we're starting to look at the dashboard view, a.k.a. the event stream, this week. There's a photo of the paper prototype here. Jon Lister will be amending his RSS feed compiler for this.

So all activity now is focused on BlogTalk, including cross browser compatibility and other testing. All code commits can be seen in subversion, and work to make all this stuff easier to consume (including an overhaul of RippleRap.com) will take place when we get back...!

UPDATE 25/2: One thing I forgot to mention is that we haven't yet conducted any user testing on the paper prototype. That is scheduled for sometime in March; I'll keep you posted.

Friday, 15 February 2008

The Serendipity of Open Source Innovation

As you'd expect from a team which has BT's Head of Open Source Innovation at it's helm, we often find ourselves in challenging debates about how best to innovate with open source, and expose these benefits to the business. It's a fascinating subject, and to some extent we're blazing a new trail here.

We're deliberately positioned at the edge of the network (some distance from core business operations), partly so we have the freedom to experiment without threatening said core. But, while we have this freedom, we also have to justify our existence as a group to those in the business who will ask for evidence of our innovation, and ask us to demonstrate how our efforts are helping BT.

What's unique about our situation isn't that we're using open source in the enterprise. There are plenty of enterprises doing that already. What's unique is that from the start we were directly plugged into an existing open source project which is both relatively young and has such high potential for growth, expansion and innovation. Also we're plugged into BT at a senior level, which means we have a high profile in certain parts of BT.

The net result is that expectations from both the community and the company are probably much greater than if we were just plugged into e.g. a Linux distro project. And the pressure to delivery quality and value quickly through innovation is higher as a result. These expectations and the pressure are entirely justified.

So how do we go about reconciling these expectations and pressures with the noble and valuable notion that we behave like external open source developers? As covered in a previous post, this means all team members assuming whatever role they wish in the community, and this is arguably the most effective route to innovation. But we ought to consider whether some compromise is in order; that we should seek consensus on our priorities and be willing to use internal authority* to get unpleasant-but-necessary work done.

In my view this reduces the chances of the team producing innovative output. Prescribed work by it's nature is anticipated, and innovation is generally more serendipitous in nature. That isn't to say that innovation can't emerge under these forced circumstances; of course it can. An open minded approach to a well known problem may result in a new idea. But it's surely less likely.

For a team such as ours, and for other similar teams attempting similar approaches, I believe the correct approach to be one where authority* is used as sparingly as possible. Sometimes work needs doing that no-one would do voluntarily, for the greater good (and the nature of these building blocks sometimes means that innovation can follow in it's wake) - and this is the time to use authority. But the more limited these occasions arise, the more we improve the innovation potential of the team overall.

* I use the term "authority" loosely here; in this context it means anyone doing something that they wouldn't otherwise do, given complete freedom of choice.

Thursday, 7 February 2008

Paper prototyping

Following on from the development of personas (to help us define the types of users we're developing RippleRap for, and what their goals will be), we're now trying to develop the application that meets these goals.

I have two objectives here; not only developing a great user interface, but also exploring techniques that can be adopted by an open source developer (e.g. potentially someone who doesn't have access to the same resources or money as BT). The technique I've used is therefore a basic version of Paper Prototyping.

Paper Prototyping is the process of sketching out potential interfaces using paper and pencil, to be tested on users, in the hope of finding areas of the user interface that either need improvement or just plain don't work. Doing this in rough sketch format has big benefits:
  • The more polished the interface, the less likely that the user being tested will offer helpful criticism (if it looks finished, he or she will behave as though it is)
  • It's a great way of getting feedback before coding begins, which is one of the number one causes of poor user interfaces
  • Because the sketches are done in pencil, they can be changed quickly at almost no cost and re-tested almost straight away
In fact, as it turns out, the simple act of creating the paper prototype for RippleRap has lead to numerous improvements in the user interface. And it's been a great way of sharing our vision and understanding between the team. We haven't even conducted testing yet, but the benefits are already significant.

For those interested in the direction which RippleRap is taking, we're developing an "event stream" service that sits alongside the note taking / note sharing functionality. This event stream will contain Twitter comments, Flickr photos, blog posts and shared notes specific to that event. All this content will be stored locally and searchable - which is great where flaky conference wi-fi is concerned.

We're also adding a Twitter client, so people can tweet from their browser at the same time as writing their session notes and / or following the event stream. All optional and configurable, for the user and the event organiser.

I've laid out our paper prototype in three configurations so you can see how this might look (the view where you're taking notes will be the same as before, so I haven't included that). There are many other configurations not shown! Click the thumbnails for a larger view.

This is the first dashboard view, where you can see the event stream coming through. Tweets, Photos, Blog posts and shared notes are all shown in chronological order, the agenda can be seen alongside the event stream.

RippleRap - Dashboard (Timeline) view

This is the second dashboard view, where you can see Tweets, Photos, Blog posts and shared notes in each category.

RippleRap - Dashboard (Split View)

This view shows the Twitter client. Note we give users the option to add "#EventName" automatically to their tweet, which in turn means their message joins the event stream. We're adding a hashtag to the event name to promote good practice, but we'll actually pull tweets into the event stream using a terraminds search (the best and quickest Twitter search tool we've come across so far).

RippleRap - Twitter client

Having run through the user journeys using these paper prototypes, we're now ready to test on real users. Large companies would normally go through a costly and time consuming recruitment process, but we're not going to take advantage of that luxury (see objectives, above). So, the next visitors to Osmosoft Towers will get more than they bargained for!

Conducting user research using paper prototypes is a subtle art. I'll talk about this in a near future post. In the meantime, if you're interested in learning more, I can recommend the book "Paper Prototyping" by Caroline Snyder (the companion website at http://www.paperprototyping.com has been down for the last week or so, but if the book is anything to go by the site should be very helpful).

PS Thanks to Jon Lister and Phil Hawksworth for helping with the prototype, user journeys and general support!