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.