I was delighted to be asked to give the GNOME community keynote at the recent Desktop Summit in Berlin. It was entitled “Iteration’s what you need” and talked about getting better at making software. GNOME of course was one of the early pioneers of time based releases. They allowed things to get better, six months at a time and started to decouple features from releases. This is a process that has been taken on and intensified by the major browser makers and of course, websites.

This is especially relevant to GNOME given the recent release of 3.0, a slightly divisive major version which provides a whole new base to iterate on top of. I argued that we can use the new extensions framework in 3.0 to deliver a more personalised and adaptive interface to users which allows the community to target more users and helps to ease the pathway for new contributors into the project.

I was particularly keen to stress the importance of the existing design and goals led approach which has created such distinctive software, whilst trying to balance it with a slightly more anarchic playfulness. A lot of this shouldn’t exactly be news to those who follow a number of today’s leading software thinkers, or who’ve looked at how top open organisations such as Mozilla deliver software platforms but hopefully it was brought together in an interesting way.

The talk was given in (and partly about) Pinpoint, a tool for making hackers give excellent presentations, and as such a plain look at the slides won’t help very much as I won’t be there to witter on over the top. But they are available if you’re interested,

In a great example of potential iteration within the tool the PDF export doesn’t include the rather voluminous speaker notes which would be a good feature to add and if we do I’ll update the post. Sadly, although the session was recorded on video there was an issue with the storage and it appears to have been lost. As such, I’ve taken a little while to try and transform my notes into something a little more literary. Obviously, it’s worth reading along with the pictures as the jokes will hopefully be funnier, and you’ll get to enjoy many more of Pippin’s beards. Anyway, and without further ado:

GNOME: Iteration’s what you need

Despite working on GNOME it appears that I’m the face of a recent release of KDE, so, welcome all to the ecumenical desktop summit. I work for Intel’s OTC in London. Which is cool as according to MATHS we write a lot of Linux.

I am a designer. As a designer, my job is to try and meet people’s needs and solve problems. As we know, GNOME is people so this talk should be full of overlap.

Or, to put it another way, my job is to work out how can you make people happy. Not by doing everything they say they want. At the same time people aren’t (all) toddlers, you can’t look or talk down to them. You’ve got to get onto their level and often, humbly, admit they know more than you do about how to solve their problems.

This is one of the great strengths of open source, harnessing the energy of users and turning them into contributors, so for the future of your project you want to say yes as often as you can. So, this talk is going to be about ways that we can say “yes, but” more often rather than just plain no.

GNOME 2 was great (but it got there over 9 years). A few other things happened 9 years ago: The Euro, Water on Mars and Attack of the Clones. Not all of these have aged as well as GNOME 2. GNOME 3 is great (and it’ll get better), 6 months at a time, on the same time based cycle that 2 did. But how do we get to awesome? And more quickly this time because we really need to be getting better at software after all this time.

Do we listen to the hackers, who want to launch lots of terminals? (turns out their workload looks uncannily like normal people wanting to launch lots of web browsers.) Or do we listen to this guy?

Maybe we already did. The latest versions of GNOME and OS X are uncannily similar in visual and interaction terms, so maybe we should just follow the word of Steve Jobs. I reckon we say no, it is possible to do better than OS X, as anyone whose seen people use it for the first time will atest. But Apple’s actually a really good case of iteration, both visual and interaction. They’ve refeshed their experience, whilst staying pretty close to their core goals which is a success in my book.

How do designers iterate? Badly, and often on paper. Our tools suck for this currently, we need things which have the power of a dvcs to experiment and play with (example, I really need multiple pages in Inkscape).

Often we work by sketching a complete redesign, usually missing key features. Developers, do not be alarmed by this. It’s just a way of finding out by feel what the key parts of the application are and can be a good way to remove cruft. We usually make sure we add all the stuff back in afterwards unless the point of an iteration is to remove a feature.

Here’s a cool thing, it’s an adaptation of the GIMP to add version control. This is exactly the kind of awesome, ground breaking feature we need in open source to enable the kind of open collaboration that developers currently enjoy to work more easily for people who code less.

There is currently a surfeit of design wanted, compared to designers available in GNOME, which is great but sadly I’m here to tell you that designers don’t scale very well. There are quick wins available for improving software, but not as much as all that, as you need deep domain knowledge to create really cool stuff. So please, come and work with us. The great advantage of GNOME for designers who want to get into an open source community is that there are already some of us here, so you’ve got people to chat to and that the developers are keen to collaborate, work with you and make great stuff together.

Iteration isn’t a rewrite from scratch, you have to have the solid base existing to iterate on top of. But still, no sacred cows. GNOME is defined by the design goals, not specific instantiations of them. If the data leads you to do something drastic, then do something drastic. To me, these design principles are the most important document in the project. short enough to understand, opinionated enough to create a flavourful experience. This is the core around which iteration takes place, a guide to future goals and a quick test if something’s ‘gnomey’.

Extensions lead to the possibility of cobranding. How would we feel about a Twitter enhanced GNOME product? How would we feel about a Kernel endorsed gnome product. Fedora has been ahead of the curve here with their spins and at intel we’ve got a really cool thing called yocto which could be really interesting to manage a bundle of these extensions. Also we like automator. if we really embrace this kind of mass customisation, then we need a way to move users from mastery to ownership. Tools to build your own are a big theme for me and a big hole in our current setup.

Creating iteration should be a structured process of play: Structured in that you need a current benchmark to ensure you get no worse; Playful in that you should explore the problem space in unusual and interesting ways. Test before; test after, then you’ll have some ammunition for going through a review process. We need design and code review. On this, I’m very excited by the ui-review keyword in bugzilla it’s very important conceptually to stop bad things happening but of course, the maintainter still owns their code so you’re in an advisory position as a standard designer.

Feedback is the hard bit. As a company I would give you the standard designer answers (test with users, test with users, also, test with users). But as GNOME, the situation is different. After a bit of thought I feel that most bits of functionality should be tried as extensions first, and made available for installation and review. You then rely on the extension installer being a thing for normal people like it is on firefox. This will take investment.

Now, an example of iteration. I’ll tell a story about pinpoint, which is a tool started by my friend Pippin. In many ways this is a very standard open source story.

A person has a problem, in this case giving a presentation, so they write some software to fix that problem. And because they’re a talented hacker, just turning out a new one isn’t a problem, so they write it again and again, slightly different each time.

I’m going to talk to you about Monty Panesar, he plays cricket for England. He started very well, but tailed off badly. And Shane Warne (another cricketer) said something very perceptive. He hasn’t played 30 tests, he’s played the same test 30 times. This is not iteration. So this was the most amazing and exciting thing, that rather than writing a new tool for every presentation. He started adding features to an existing tool. And why?

Because it rocked. Pinpoint has a view. it hates powerpoint, it hates most presentations that hackers give at conferences like this and it wants to make it so easy to give better presentations that you’d be stupid not to. Its self defintion says it all, it’s “a tool for making hackers do excellent presentations”.

He got some friends who wanted to use it too and who agreed with the plan. And they added a load of features. Hopefully you saw (or caught later) a couple of the awesome talks that my colleagues, Damien, Neil, Emmanuele and former colleague Chris put on to see some of the crazy features we have in pinpoint now such as webcam backgrounds, an embedded terminal and live update ad view of file changes.

But still, it’s remained simple. Pinpoint a simple presentation tool that hopes to avoid audience death by bullet point and instead encourage presentations containing beautiful images and small amounts of concise text in slides.

And why? It’s simple because features have to meet the opinionated design in order to get in. You’re not allowed to make it any worse at its core, or add needlessly to the ‘format’ but other than that – go for it!

So, we’re coming in to land:
☃ Have a strong identity
☃ Adapt around that core
☃ Share those changes
Thanks.

I read this on the internet today. It’s pretty good and made me think I should probably share some of the work I did for Moblin Netbook the year before last. Note: this does not apply to MeeGo.

Moblin is different. This is what you always need to remember when translating it into another language. Moblin is not OS X, GNOME, Windows or a phone.

Moblin is not you, we do not use ‘My’ anywhere. As Moblin is your friend we use ‘Your’ this should be an informal you if your language has differences in status.

Moblin is your friend. She’s one of our design personas – a single woman approx 30 years of age with a teenage son. She speaks informally and demotically to you, but not disrespectfully. You are treated as a partner throughout.

Moblin is not creepy. It doesn’t remember embarassing things. It is always polite.

Moblin is funny, but not too funny. As an extension of the informality occasionally the interface will make a culturally specific pun or joke. This is intentional and should be replicated to your translation. Not specifically in the same place and not the same joke. Consider the many translations of the excellent Asterix comic book series where the jokes are culturally specific, everyone feels like they’ve been told the same joke – but they actually share a joke space where everyone feels included despite having a seperate experience.

We aim only to use humour as a double indicator, where the user has another way of finding out the correct context. A great example is the volume control where the user can see their position on the slider and use the slider to control the volume. In English the descriptions of the slider positions are jokes based on Music and audio that is understood by the target market e.g. ‘Turned up to 11′. We aim for a maximum of 20% humorous labels in a multiple choice box. Be thoughtful.

Moblin is a symbiosis between hardware and software, collectively referred to as the ‘computer’. Moblin takes responsibility for successes and failures across the system.

Have fun writing for Moblin and it’s quite likely that your users will have fun using it.

New today, part of the last few months work. MeeGo 1.0 for Netbooks. Hope you like it.

Being stuck in another country certainly does allow you to spend more time doing things that you like to do, but which the urgency of proximity based interaction usually displaces. In this case it’s spending some time putting things onto here. Not much, but a little. In this case, here’s some things I’ve highlighted on my Kindle.

Heretics (G. K. Chesterton) – Loc. 292-93

“Posting a letter and getting married are among the few things left that are entirely romantic; for to be entirely romantic a thing must be irrevocable.”

Heretics (G. K. Chesterton) – Loc. 1001-2

“He is in a perpetual state of temporary honesty.”

Changing My Mind (Zadie Smith) – Loc. 1394-96

“Do our childhoods often return to us in the form of coherent, lyrical reveries? Is this how time feels? Do the things of the world really come to us like this, embroidered in the verbal fancy of times past? Is this really realism?”

God’s Fury, England’s Fire (Michael Braddick) – Loc. 5063

“Overall, the King’s position was not bad, which meant that his opponents” position was not good”

BT said it was “delighted to help Rutland Telecom” although it added that it hoped it would allow other service providers access to its new network. “Otherwise there is the risk of a local monopoly developing, which is never good for consumers,” said BT Group Strategy Director Olivia Garfield.

A strong contender for the Irony Prize 2010.

I’ve given a couple of presentations about designing Moblin in the last few months. Since they’re now public on the internets I can talk about them here. This is quite difficult to do since they contain a lot of video, attempting to show how we create (with our lovely hackers) the compelling motion that Clutter can deliver. So you’ll miss all that ‘behind the scenes’ excitement. The two presentations are quite similar in many ways, you’ll certainly see repeated motifs, but that’s just because we’re trying to create a family of design around Moblin (and I’m a bit lazy).

So, designing Moblin for netbooks:

And designing Moblin for MIDs:

Both presentations have versions with speaker notes linked inside them, although, as ever they were only a very rough guide to what I actually said. If you want to know the real truth, you had to be there.

We designed an operating system for phones too. Another awesome job from everyone in design and implementation. As ever, I’m proud to work with you all.