Android Wireframe Templates

January 12, 2010

Here’s a little something for all you people making lovely apps for Android. If you use a pencil before you start to take your app to the digital realm, then we’ve made some templates to help you design for some of the Android handsets out there.

There are a whole variety of devices to choose from, with different screen resolutions, and hard or virtual keyboards. We find these help give our sketches a little context when we’re presenting them internally or to clients.

The PDF is Letter size (8.5 inches by 11 inches) and the handsets are to scale, so you can use these quite happily for paper prototyping and get a realistic sense of scale. There’s a subtle 10×10 grid on the screens to help you with your pencil based needs. If you’re short on Letter paper, you can get away with printing them on A4.

If you have any suggestions, comments or improvements, feel free to suggest them here.

All that’s left is to snack down on cupcake, donut or eclair, or if you’re feeling greedy – all three. Enjoy – and click here for the templates.

These templates were designed and lavishly tooled by Ali Driver, Senior Designer at Future Platforms.

Guardian Anywhere

September 14, 2009

We’re launching a little side-project today. It’s an app for Android phones that lets you read The Guardian, anywhere. We’ve imaginatively called it “Guardian Anywhere”.

Guardian Anywhere: article viewIt’s designed to meet a simple use case: you want the news on your phone to read on your commute into work. You can tell the app to download your newspaper whenever you like, perhaps early in the morning before you wake up. You can also tell it to only grab the news over Wi-fi; there’s a surprising amount of stuff in the Guardian each day, and we don’t want you running your battery down grabbing it all over 3G.

Once it’s downloaded, the content lives on your phone – perfect if you’re travelling on the tube or through some of the more radio-challenged parts of the countryside (like, coincidentally, the Brighton-to-London line). As well as news stories, you get a pile of photographic imagery which the Guardian publishes every day. We’ve also tried to retain a little bit of the Guardian look and feel throughout, though this isn’t an official Guardian product.

If you play with it a while, you’ll discover a few other nifty features tucked away, like:

  • Saving some of the fine photography to your phone as wallpapers;
  • Choosing which sections of the paper to subscribe to (or which to avoid);
  • Clipping articles or photos into a “Saved Articles” folder, to help you skim for interesting stuff and then peruse it at your leisure;
  • Browsing through articles by section, author or tag. This makes it easy to find, say, all the articles in todays paper relating to executive pay and bonuses; and if you’re really interested in a tag (or author), you can subscribe to it;

Guardian Anywhere is the brainchild of James Hugman, who kicked the project off during his gold card time and has been demonstrating it to us ever since at our fortnightly reviews. We’ve been testing and revising the app internally, and launched it onto the Android Marketplace after putting it in for the Android Developer Challenge.

All feedback is, as always, warmly welcome – please do try the app out and leave us some comments in the Market. The little 2D barcode you can see to the right of this paragraph is quite handy for getting hold of the app. Scan it with the barcode scanner on your Android phone to be taken to the right place in the Android Market, click the link if you’re reading this with an Android phone, or just search the Market for “Guardian”.

Two-team retrospective

March 25, 2009

Today was our first review and planning day with the new two-team Future Platforms, and to give ourselves a bit more space to stretch out, we tried holding the morning session at The Skiff – a coworking space run by the Inuda folks a couple of streets away from our offices.

RetrospectiveThe facilities there were excellent. As well as more space we had walls to stick postits onto with (and lots of visibility, room to walk around, etc.), a projector, and beanbags galore. All of this – plus being in an unusual space away from the usual workplace – made a big difference.

The review went well, with our two teams (Anjuna and Tonberry) demonstrating projects they’ve been working on for Microsoft and the BBC respectively. Compared to the limited visibility you get by passing a couple of handsets around a room, having 5 foot tall on-screen demos felt like heaven… and the demonstrations themselves seemed to “flow” a little more than in previous reviews. If only I could talk a little more about their content; as usual, NDAs have my lips sewn shut. Unusually, our design team weren’t presenting their work this time around – much of it has involved supporting the development teams (and was therefore visible in the dev team demos), and South by Southwest had taken its toll on our design resource over the last fortnight….

I was really looking forward to the retrospective, and wasn’t disappointed. The near-unanimous view from both teams was that splitting the company into two had been a success. Each team felt more focussed on their respective projects, had been less affected by context switching, and found stand-ups both quicker and more useful. Even better, we could see measurable and significant improvement in the productivity of the company split into two teams (vs all being in one team).

One issue which was surfaced by 4 different people was that of planning and testing time. We have a persistent experience where testing effort bunches up towards the end of sprints – so that at the start of each fortnight there’s sometimes not enough for our dedicated testers to do, and at the end of the fortnights too much.

Sprint 34 burndown (Anjuna)My own tendency is to attack this problem by trying to spread the load of testing more evenly throughout the sprint (encouraging units of work – user stories in our case – to be taken through development and testing to done before starting on others) and having other team members help out with some of the testing work when there’s too much (whilst some of it demands the eager eye and magic software-breaking fingers of a good QA specialist, I feel there are areas where the rest of us can usefully pitch in). We had a fairly lively debate on this one, and didn’t reach a useful conclusion. In particular I had hoped to bring in some of the limiting-in-phases techniques Karl Scotland covered in his recent Kanban presentation (also held at the Skiff), but we didn’t reach consensus on adopting this – so I’ll give it another go next time around.

Burndown charts also stimulated a bit of conversation. I’d experienced a worrying few days with Anjuna mid-sprint, when progress on getting stories to completion was minimal even as the team frantically worked on a core section of the product… and I’d found myself noting a problem but stuck on what to usefully do about it. In the end the team pulled through and delivered, but I’m left feeling slightly worried; we’ve had sprints in the (thankfully distant) past where a flat-lined burndown continued right to the end, thanks to my ignoring the signs. Putting a positive spin on it, the worst that we’ll ever do is experience a single unproductive fortnight, but even that would feel like a huge opportunity wasted. More thought required.

Finally, on design; last sprint we opted out of planning it formally, this time around we’re officially embedding the design team with Anjuna, where they can crack on with pushing that particular product forward together (and without distractions from other projects).

Dr Evil RetrospectsA solid day; we saw the juicy fruits of our work, had some productive discussions on how to get better, persuaded a sizable chunk of the company to come out for gyoza etc, planned in two teams’ worth of work for a fortnight, and still managed to finish dead on 6pm. Considering that a year ago planning days were regularly overrunning and leaving us all half-dead, with a smaller team, it’s great to see how we’re improving. On that particular point, it’s amazing what benefit an hour or so of working up a sprint backlog for each team the day before planning can deliver…

Thanks as usual to Joh for her facilitation of the retrospective, and to the Skiffers for hosting us!

Splitting Teams

March 15, 2009

It’s a while since I last wrote about how we’re getting on with Scrum, and we’ve had an eventual few weeks… so here goes.

We’re doing This Thing, right, and I can’t tell you anything about it at all, except that 9 of the Future Platforms team flew into Hong Kong a few weeks back and spent a fortnight working on-site for Microsoft in China, to kick off the project we’re doing with them…

FP/MS Teams, End of Sprint ReviewIt’s been quite an experience in many ways: travelling abroad as a team, working across cultural and linguistic divisions, and fitting our processes in with those of the worlds largest software company. We wanted to colocate ourselves for all the classic reasons: tackle risky elements of the project together, put faces to names, and build relationships which can weather the inevitable highs and lows of a collaborative project. And of course, we’re running things in the way we always do – I hope I’ll be able to write more about this in time, I think we’re going to be learning a *lot*.

For those of us lucky enough to go, it was definitely an adventure: hard work, thanks in the main to the sheer dedication of the FP team who were heads down for a full working day and frequently carrying on back at the hotel… but we had a lot of fun, too – as our various Flickr feeds will attest – and our hosts took great pains to make us feel welcome.

We landed back into Heathrow at 4:30am on Monday, and have been collectively fighting jetlag ever since – at the same time reuniting with the crew who remained in the UK whilst we travelled abroad, and our newest hire, James Hugman – who I’m maxi-chuffed to have working with us.

One thing we’ve been conscious of in recent months is that our team size is starting to become a bit cumbersome. Stand-up meetings feel less relevant when there’s 10 people working on a few projects, retrospectives become harder to run with so many opinions to bring out and discuss, and it’s easier to lose focus when planning. And personally I have always cherished the times when I worked in a small (3-5 person) team – it’s when I’ve had the most fun as a developer.

So before we flew to China, we’d held an end-of-sprint retrospective where we agreed that now might be a good time to split the company into two teams – and on Wednesday we did just that. It was quite involved, and in the course of the retrospective we covered:

  • Make-up of the two teams, ensuring they were balanced from a skills perspective and that they allow for continuity. We want to keep folks who’d just built relationships with Microsoft carrying on the good work, for instance;
  • Office space, making sure the teams are colocated and have control over their own environment (they’ve already chosen radically different desk layouts), and that both have space to meet around a task board daily;
  • Running planning days; I was keen to bring the whole company together for reviews so that we all get to see what we’re collectively up to, but we eventually decided to do the same for retrospectives (with a view to learning as much as we can from our experiences even across teams), whilst separating planning out into two per-team 90-minute sessions in the afternoon of planning day, and running separate daily stand-ups.
  • Naming the teams πŸ™‚ Anjuna and Tonberry it is!

Tamuji Throwing ShapesThe day went surprisingly smoothly and was unusually calm. Mary, our Product Owner, has been doing an excellent job of pre-planning preparation (grooming the product backlogs of our various clients into sprint backlogs efficiently), which pays dividends, and we were finished by 6:30pm tonight even after office rearrangement and a 90-minute lunch break, in which we introduced Mr Hugman to the delights of E-kagen.

The main problem we’ve had is that of accurately predicting a velocity for the two teams. In China our productivity was unusually high (greater than it’s ever been, in fact), which we ascribe to working long hours with an unusual level of focus on a single project. Some of this (the focus) we can try to carry forward – in fact, the two-team split should assist us in doing so. But with the company split, we’re not in a position to accurately estimate what one of the new teams can get through, until the end of this sprint.

So we now have 2 development teams, each comprising 3 developers and a full-time QA – plus a design team of 3 supporting them. We’re running design separately for the moment: we have a couple of large design projects, one of which involves no development at all, and will be bringing designers into daily standups for any sprint in which they’re doing any work with the dev team.

Next steps: we’ll bring in another Product Owner (we need to give our clients more love, and this will help – watch this space!); and see how well the team structure we’ve chosen works over the coming weeks.

Go read this article, “There is more than one mobile context“.

For some time now I’ve been becoming gradually uncomfortable with the notion that mobile content is purely about snacking on small chunks of content or limited to snatched moments of time – though I’ll hold my hand up and admit this is a view I’ve held, and frequently espoused, for years.

A few observations have drawn me away from this view:

  1. Watching Trutap become a primary means of connecting to web services for a couple of hundred thousand folks in Asia, and learning that there’s a huge middle class who are leap-frogging ADSL in favour of 3G;
  2. Noticing that peak times for a casual gaming service we run are after 11pm, when I’ll bet most folks are at home near their PCs or games consoles, not on the bus; and
  3. Slowly finding that around the home, my iPhone is replacing my laptop as my means of quick web access. It’s not as fast, as large, or as flexible, but it’s always there. Walking 10 feet and opening a zip-bag and case may only take 10 seconds, but as the Googlers know, when reduce the time between wanting X and getting X, you sell more X;

I think that, in the UK at least, this is still unusual behaviour. But when you see this happening in a tiny corner of one territory and already starting to play out in others, there’s not much conceptual hopscotch to be played: it’s not if this happens, but when.

A quarter of iPhone users say it’s displacing a notebook computer. 28% of iPhone users surveyed said strongly that they often carry their iPhone instead of a notebook computer.

My gut instinct is that this isn’t purely an iPhone phenomenon, and that there’s something more happening here – an acceptance that availability trumps screen size? An across-the-board improvement in access speeds and UI?

There is more than one mobile context. Decide which you’re interested in.

I think this article is lovely, but the author has left out one context: the mobile as your primary means of getting online, not because you’re away from home, but because it’s yours, it’s nearby, and it’s how you choose to be online in general.

Trutap retrospective

November 28, 2008

271120081731Yesterday afternoon we invited the Trutap team down to Brighton, for a post-project retrospective. It’s the first time we’ve done one of these with a client – normally we run them every fortnight with the whole FP team. On top of learning what we could from our largest Scrum project to date, we wanted to lift a bit more of the veil.

I won’t go into the full details of how we ran the day; aside from anything else, the festivities afterwards have blurred much of my memory, but I do have a good set of notes regarding our learnings. As is traditional for us, we split these into things that went well, things that didn’t go so well, and things we’d do next time. There was also an opportunity for us to call out individuals for particular appreciation, which I liked.

So, here’s some of what we got out of it:

What went well

  1. Porting has been extremely smooth this time around. Within 10 days of completing a reference version of the product, we’ve fully QAd and released the new Trutap for around 150 handsets, with more following as I write. Most of the credit for this rests with our fine development team, who’ve been leading us away from the industry-wide nightmare of maintaining hundreds of different versions of the product, and towards a rosy future of fewer SKUs. There’s another post about this on its way, and I mentioned how we’ve done this in my Future of Mobile presentation. Suffice to say TT version 1 had more than 30 SKUs, all built from a single code-base but targeting different devices. TT version 2 has a single binary, and comes in 4 flavours for different screen sizes.
  2. Shared documentation and tools, in particular the product backlog (all work remaining to do) and our bug tracking system, really helped. We were operating very transparently; I do wonder whether a less technically capable client would be as interested, but for those who want it, we’ll do this again.
  3. The relationship between the development teams at Trutap and FP was strong: we like each other and we got on well. ‘Nuff said.
  4. Weekly meetings were very useful, though we only started holding them a couple of months into the project.
  5. Change was handled smoothly; we were able to accept change, addition of scope and iterate aspects of the product as necessary throughout.
  6. We worked at a sustainable pace; we week before launch there was an eery calm at both Trutap and FP. Tthe product was there, the bug count was close to zero, and we hadn’t had to work evenings and weekends to get to this stage. Compared to the period before previous launches I’ve known (even for Trutap), this was incredibly calm. I don’t think our adoption of Scrum can take all the credit for this – the project involved a skilled team at FP and TT who’d worked together before, for one thing – but I certainly think it’s helped.

271120081736What could have gone better

  1. Wireframes were a poor means of specifying the product, requiring a lot of clerical maintenance and attention from both sides and offering an ambiguous level of detail: too much in some areas (e.g. screen layouts), too little in others (e.g. error states and flows).
  2. We started the project haphazardly at both sides, and had to act to bring it back on track a couple of months in.
  3. The design process had “too many cooks” and could have been more focused.
  4. We should have spent more time explaining our approach, from both a project management and a technical perspective. We never actually sat down with Trutap and said “this is how we’re going to work”, instead keeping the details of our process to ourselves. With a large successful Scrum project under our belts and a bit more self-confidence, we’ll do this next time. Equally, from a technical perspective we had a clear idea of how we broke down the work (into screens and UI components) which we could have shared earlier on.
  5. Using version 1 of the product as a catch-all default was a mistake; where not otherwise specified, the product was to “work like version 1” which led to some scope being missed off planning at the FP end, and some confusion where new features didn’t dovetail with old behaviour.
  6. We had many means of communicating: Google docs, Basecamp, Fogbugz, a Jabber chat-room, email, face-to-face meetings, etc. This sometimes led to a lack of clarity and nervousness: when a chat-room had been set up but our dev team weren’t available in it (because they were getting on with work!), the client worried. Next time around we should clarify communications methods: different tools seemed good for different jobs.
  7. Early in the project, we weren’t as good at making collective decisions as we were later on. A looming deadline always helps focus the mind πŸ˜‰ but we’d try to get this focus earlier on future projects.

Next time around…

  1. We’ll prototype more and wireframe less. We may invest time into tools to support this. Wireframes don’t cut it.
  2. We’ll plan to iterate from the beginning, allowing contingency in timescales and commercials (in fact the latter was planned for, as it turned out ;))
  3. We’ll introduce any change at fortnightly sprint boundaries. A couple of times we had mid-sprint changes which led to the dev team at FP thrashing and progress slowing. Lesson learned: we should be more disciplined here.

    The Retrospective Squid

  4. Towards the end of the project, we had a day we called the “UI Sweep”, where the TT product team sat with our developers and worked through final bits of polish. This made a difference to the product quality disproportionate to the amount of time spent. It’s quite gruelling for the developers, and relies on good tools and practices that let you make changes there-and-then, but was ultimately very worthwhile. The idea of an on-site customer is classic XP.
  5. We’ll have weekly meetings from the beginning, with everyone engaged and involved.
  6. We’ll get everyone to the pub more often πŸ™‚

And the role of honour: called out for particular thanks were Ali, Tobias, Luke and Rob @ Trutap of Trutap, and Thom, Doug and Serge at FP. Thanks again guys, we built something fantastic πŸ™‚

None of this would’ve been possible without the able and entertaining facilitation provided, as ever, by Joh Hunt – cheers Joh πŸ™‚

Twitter on the iPhone

November 23, 2008

I often check Twitter on my iPhone. But instead of using one of the numerous Twitter clients from the app store, I’ll just load up mobile Twitter in Safari. Why don’t I use an app?

There are problems in every option available right now. In this post I’m going to comment on three iPhone Twitter experiences: mobile Twitter (, and two popular apps, Tweetsville and Twitterrific.

Mobile Twitter (

Mobile Twitter, located at, is the official mobile version of It works fairly well as a mobile website, but it’s not iPhone optimized. The design doesn’t follow the iPhone human interface guidelines published by Apple. A few changes would improve things for iPhone users:

  1. Tappable areas should be bigger. The “Older” and “Newer” links should be at least 44 x 44 (recommended by Apple).
  2. The text entry box should be bigger. Falls into the above suggestion, but I think it’s so important it deserves its own mention. A bigger entry box would benefit all mobile users (the box should be a certain percentage of the screen). Right now it looks ridiculously small on iPhone, and it’s awkward to type an update into. Editing what you’ve written is a frustrating experience. This experience is so poor that I find I use to read updates, but to actually send an update to Twitter, I use SMS.
  3. It’d be nice to have a character counter. It’s essential, really: Twitter users need to know how much of their 140-character budget they’ve used and how much they’ve got left.

Third-party Twitter applications for iPhone: Twitterrific and Tweetsville

I’m going to compare Tweetsville and Twitterrific, which isn’t really fair, as I’m comparing the free edition of Twitterrific with a premium app, Tweetsville. But as far as I know, the user experience is the same; except the premium version doesn’t have ads, and it has the option to toggle a light background. Twitterrific is by Iconfactory, and has a free and premium version. Tweetsville is by Ed Voas, who sold the application to Tapulous. It’s a premium app with no free version.

Appearance. I’m not a fan of Twitterrific’s default appearance. The gradient background behind every single update is just something extra the app has to load, along with the text content. I don’t think it looks nice, either. Which, of course, is the real issue here. ; )

Seriously speaking, one of the things I like about Twitter is its simplicity, both in concept and visual design. Any extra graphic embellishment takes away from the simplicity and transparency. It’s worth noting that the desktop version of Twitter doesn’t even allow users to customise a background colour (the default is white). Any Twitter app should aim to load as quickly as possible, so being spare in appearance is a good thing.

Tweetsville’s appearance is simpler. It offers two display options (bubbles or no bubbles). I think it fits better with the appearance of core iPhone apps, in both its visual design and interaction design.

Content concentration. How many updates can you cram into a single screen and is cramming content into the screen a good thing to aim for? Content in context is something designers should definitely take into consideration. Twiterrific appears to be able to fit more updates in a single screen when compared with Tweetsville, which would have the benefit of not having to scroll as much. Given the little work involved in scrolling, and how much you need to scroll anyway, perhaps it doesn’t make much of a difference. It also depends on how many people you’re following, and how much content you need to catch up on.

Tweetsville: (1) plain, (2) speech bubbles.

User experience. Tweetsville looks better than Twitterrific. Additionally, its user experience is better: it is more user-friendly, and more compliant with Apple’s human interface guidelines for iPhone, and this is shown best on the settings screens below.

Tweetsville’s settings vs. Twitterrific’s settings.

Tweetsville’s settings fills a single screen. Twitterrific’s settings fills roughly three screens. The latter offers too many options, and not all are necessary. Is the ‘Light Background’ button totally necessary in the free edition? It mainly serves as an ad for the premium edition. How come Tweetsville gets away with so few settings options?

User control: tab bar. Another good thing about the design of Tweetsville is the presence of the tab bar. The tab bar on the bottom of the screen acts like a useful frame, giving the user more freedom over where they can move within the application.

The tab bar is a great asset. Even better is the ability to edit them (which you can do, surprise surprise, by hitting “edit” on the “more” screen). This works like the tabs in the iPhone’s iPod, which draws on an established affordance (good).

Tweetsville’s custom tab bar

Progress/status bars vs spinners. When I refresh the app I want to know how quickly I’ll be able to read new updates. So I want to see a visual indication of progress.

The spinner (circled in red) doesn’t indicate its progress visually. It just tells me it’s working. Great, but how soon will I get to see my updates?!

The browser bar (also circled in red) fills up as it downloads data. It tells me that not only is something happening, it’s completing a task, and is at least a percentage through completing it.

I really like this and would love to see an app that could show this, even if it’s not accurate. Psychologically, it eases my pain by giving me the impression that something’s getting done!

While none of these experiences are perfect, the good thing about multiple options is that the designers behind them will learn from each other’s merits and mistakes and improve iteratively. Twitterrific was one of the first clients out there for iPhone and iPod touch, and Tweetsville is a fairly recent release, so the latter had more time to learn from existing apps on the market.

I hope that Twitter will make an iPhone optimized site according to Apple’s human interface guidelines, because I’d be happy to use the website. Twitter itself is extremely lightweight, so does it really need an app? Any app should reflect the lightweight nature of Twitter, and aim to keep loading time as low as possible.

Looking back at Trutap

November 20, 2008

Trutap home screenAt the Future of Mobile this last Monday we launched a new version of Trutap, one of the projects that’s been keeping FP busy over the last 6 months. It’s been a large project, involving 11 our our folks at various points through its lifecycle and a similar number of people at Trutap.

The brief was to rework and adapt the user interface of the original product, reusing the existing storage and communications components which we had developed in 2007 as part of version 1. Trutap wanted the new UI to support searching of their customer-base, increased emphasis on user profiles, and the addition of large numbers of third-party service providers. We wanted to push J2ME and our Cactus framework a little bit further, and experiment with a new approaches to addressing the problem of porting J2ME applications – but more on that another time.

The project started with a 1-month design effort, where we worked on some of the conceptual side of the UI (such as left-to-right navigation and a breadcrumb-trail like use of tabs) and started thinking about what components would be required to support this.

The former gave us the “big picture” which was bounced back and forth between FP and TT, iterating gently in the breeze. The latter allowed us to start making visible and worthwhile progress early. We started with a completely separate harness for UI components which let us develop and exercise them outside of the main MIDlet, testing them fully (even with edge conditions, e.g. “how does this contact look when their name is too long to show on-screen?”), before plugging them into our automated tests. As a side-effect, this enforced some good design principles: components are properly encapsulated, and we ended up reusing quite a few of them across the app.

This was the first large project which has started, run and finished since we adopted Scrum for project management at FP a year ago. It’s been both a learning process, and confirmation (for us and our clients) that Scrum works “in the real world” on large complex projects… on the subject of which, if you were at my talk at the Werks a month or so back, you would have seen a diagram that looked something like this:

Release burndown

It’s the burndown chart that we used internally to track the progress of this project. The blue bars above the X axis show the initial scope measured in estimated hours of work, whilst the red bars beneath the axis show scope added mid-project – and the black line shows the rough path of the original project plan. Each bar represents work remaining at the start of a two-week sprint. So you can see the project was originally scheduled as 12 weeks effort (sprints 17-22), the initial scope was completed in just under 14 weeks, and scope added – particularly towards the end as we iterated over the messaging section – added 6-8 weeks onto the overall timescales.

You can see that clearly some sprints went better than others (resulting in better progress); internally we tracked specific activities against these sprints, and it’s no surprise that riskier activities (more technically complex ones, or those relying on third parties) tender to go slower than well-understood ones.

Only towards the end did we start sharing this chart with Trutap. I’d previously felt a bit self-conscious about filling status meetings with graphs and charts – it feels a bit geeky – but I learned a lesson here: I wished we’d done this earlier, they found it a really helpful way to represent and understand the progress we were making.

Most of the project proceeded on an incremental basis, as we gradually migrated sets of features over from the version 1 interface to the new look and feel. This proceeded section-by-section: signup and login first, then contact management, messaging, profile management, search, services, and so on. At the end of each iteration (i.e. once a fortnight), we released a version of the product to their QA team for formal testing, though we were conducting QA as part of our development too; I was pleased to hear that Trutap felt quality of releases had noticeably improved since the first version of the product last year. In the final sprints we were releasing more frequently: their QA staff had direct access to our build system and could pull off new binaries as and when they were ready.

We iterated a little on messaging, spending a sprint returning and reworking the interface once our customer had had a chance to see how the wireframes we’d all theorised about worked on a real phone; and in the final sprint of the project we had another run-through, with the Trutappers coming down to sit alongside our development team and get last-minute pre-launch changes made.

Design tended to be done “just-in-time”; sometimes we deliberately anticipated components that would be needed for the next sprints work and undertook design for them in the preceeding sprint (in a classic “design-one-sprint-ahead” model), but sometimes we were able to work a story or two ahead and keep design and development tasks in the same sprint.

I’m deliberately not writing much about lessons learned in this post; we’re having a half-day retrospective with the FP and TT teams getting together next week. I’ll follow up this meeting with a post here summarising the day; and there’ll be another piece coming soon on our approach to porting, which I touched on at the Future of Mobile.

In the meantime: congratulations to everyone at Trutap and Future Platforms (past and present) who worked on this. I love launching πŸ™‚

Last month Aleks Krotoski spoke at dConstruct on Playing the web: how gaming makes the internet (and the world) a better place (listen to the podcast, or see a write up of the talk here).

Two main things I got out of this talk: (1) carrot: good games should reward people for contributing more, with points, levels, collectable items. (2) goals: good games should have an end goal.

Casting my mind back to various games I’ve played, I’ve never been so hooked on a game as Ultima Online. I played this game compulsively for about a year – quitting only when I really needed to focus on schoolwork (and when I finally switched to a Mac).

Rewards and goals are everywhere in Ultima Online. The gameplay is rich on hundreds of different levels: across the macrocosm of the game down to the tiny little details. I loved that spell ingredients, known as ‘reagents’, spawned across the land – which could be picked up and used, or sold. I could also harvest cotton from cotton fields and sell it to tailors in the town. If you’re like me, you’ll find both of these ideas hopelessly novel.

Another thing I liked about the game: killing monsters gives a character an amount of “fame”. And with enough “fame”, you gain a title. This brings a compelling social aspect to the game: you have something to show other players for your participation in the game. Your title also reflects your skill level, ranging from “novice” to “legendary” (they might have introduced more levels since).

Building a character within a system, within a world, is satisfying, compelling, and addictive. A character can take one of hundreds of possibilities. The game is not just about “killing stuff” within a contrived “level”. In addition to being a mage or a warrior, you can make a living as a tailor, a chef, a bard, a thief, and even a beggar. Skill increases as you practise it: so, to build your bard character, you’d need to first raise enough gold to buy an instrument, then walk around playing said instrument.

This does get a little dull. In some professions, raising skill is much too mechanical and technical for sustained interest, so you could macro or automate it to rise. (If you get caught, though, you put your account at risk.) On the whole, I think the game manages this well: although it can get boring, it is more likely that you will invest the time to build your character than it is for you to give up or quit the game.

How does Ultima Online manage this? You can clearly see the structure and process for raising a skill. In other words, you can see the journey ahead, and know what you need to do in order to reach the end. You can see the rewards in the future: e.g., a tailor with 100.00% skill can make better quality leather armour for your mage. An animal tamer with 100.00% skill has a much better chance at successfully taming a dragon. Getting to 100.00% skill is difficult, but fun: the rewards are both in the journey and in the destination.

I think Ultima Online is the perfect game. Sadly, its membership is dwindling: possibly because World of Warcraft is the new MMORPG vogue, and possibly because gamers aren’t known for their lengthy attention spans.

So, some basic principles which are useful to interaction and experience designers, or anyone planning a social website:

  • Reward your users for participation.
  • Allow them to build something, and allow them to see the end-goal.

Another principle:

  • Give your users a structure: give them limitations

From ‘Rules of Play’:

The idea that players subordinate their behaviors to the restrictions of rules in order to experience play – and its pleasures – is a fundamental aspect of games. The restrictions of rules facilitate play, and in doing so, generate pleasure for players.

From L. S. Vyogotsky:

To observe the rules of the play structure promises much greater pleasure from the game than the gratification of an immediate impulse.

Now: how to bring these principles to social websites?