Making usability part of the development process

For the first year and a half in Canonical I worked with the amazing Launchpad team, with the ambitious goal of building a new user interface, introducing AJAX in an established code base and rolling it all out on time. While all of that was overwhelming in itself, what was more important to me was making sure the UI remained consistent across time.
Long story short, it was a success and it’s been 8 months since I’ve left the team and the established process is still on-going.

I wrote a paper on the whole experience and presented it at the agile conference XP2010 in Norway.

Here’s the introduction:

When I started working with the Launchpad team I was tasked with designing and rolling out a new interface using cutting-edge technology on a well established product and team. The existing processes and team structure made it very hard to roll out big changes while also ensuring consistency as time went by.
While the general designs and work ow changes were being eshed out, I started to drive some change to the existing processes, enabling me to be successful at an objective that would take a year to accomplish, and unexpectedly, beyond that.
The project was 4 years old and had over 500 dynamic pages with different templates and layouts that had been left untouched at different points in time. The goal for the next year was to make the application easier to use, even enjoyable. I also had to make the UI consistent across the board, take the project from static HTML pages into the wonderful world of in-line editing, streamlined work-flows and predictable interactions. In parallel, fundamental features that had been developed were going completely unused and we needed to turn that around. A re-usable AJAX infrastructure had to be developed from the ground up, new features needed to be designed and delivered, and general navigation issues needed to be addressed.
However, this story isn’t about the success of the roll out of a new interface, but rather the success in the process changes that evolved during that year and how the project went from nobody feeling ownership over the user interface, to the developers taking strong ownership.

I feel very passionate about this subject, and hope this experience can help other projects and teams.

Here’s the paper for download: xp2010_paper.pdf

Moving to Ubuntu One

After a year and a half in the User Experience team at Canonical, I’ve decided to move to the Ubuntu One team. It’s been an amazing experience to be part of that team but I’ve been missing doing development on a regular basis a lot lately, so I’ve decided to move into a role where I can get my hands dirty more often.

I will start by taking on anything on the web interface together with an amazing team, we will deliver a great experience and a higher level of polish for Lucid. There are some exciting new features coming to Ubuntu One, so it’s a great time to be part of the team, especially with John Lenton and Elliot Murphy as managers.

This does mean I will be moving away from the work I’ve been doing on Launchpad which makes me sad, it’s a fantastic and ambitious project filled with the smartest and most passionate engineers I’ve known.

If in the next few months you don’t start feeling like life is getting better for you on the Ubuntu One web UI, please come and find me and point me and hold me up to my promise of wonderful webby things.

Why test driven development rocks

All projects in Canonical have a strong focus on testing. From all of them, I think Bazaar ranks the highest on obsesiveness on testing. As a drive-by contributor, it always felt like a very high entry barrier, and deterred me from getting into complicated changes. It was only after I bit the bullet and got into more complicated changes (in Launchpad, actually) that I understood that tests where my best friends ever. It’s a safety net against myself, and actually lowers the barrier, because I don’t need to know about the rest of the code base to make a change, tests will tell me if I break something (seemingly) unrelated.

On the more extreme side, there is test driven development (TDD). You write the tests first, watch them fail, and then start producing the code that will get them to pass. Having co-authored bzr-upload with the TDD-obsessed bzr developer, Vincent Ladeuil, I thought that if I was going to add a new feature, I may just as well try it (again).

It rocked.

I set up the test, my carrot, and the task went from “start poking around code” to “fix this problem”. With the test written, it became very clear what parts of the code I needed to change, and how the feature had to work.

The results?  in one hour, I implemented a feature that lets you ignore specific files on upload. With tests.

Research results on Launchpad icons

Following up on our survey on icons in Launchpad, Charline Poirier provides us with the outcome:

Edit edit:  High level of understanding, but a strong association with “attention”, “warning”, and “danger”.  Might be worth modifying colour or shape to distance the icon from that interpretation.

Merge merge-proposal-icon:  Reasonable understanding of “merge”.  However, participants were not entirely sure if the icon referred to the state ‘merged’ or the branches themselves.

Remove remove:  Icon strongly associated with “do not enter” and “delete”.  The interpretation “remove” comes only in third place.  The icon is strongly evocative and might be better used to designate a more consequential or prohibitive action.

Remote bug bug-remote:  A reasonable percentage of  respondents understood the “remote bug” icon.  Many, however, did not.  It appears that the key for interpreting this icon is the representation of the bug itself.  Various potential states of a bug were suggested as interpretations.  This icon could be made more explicit.

External link link:  Relatively well understood.  It is worth noting that the icon has powerful suggestion of globality and reach (associated with translation, languages, internationalization, etc).   It is a very evocative icon that could be more fully exploited perhaps in another context.

What next?  We’ll attempt to create new versions of the icons, run another session of user-testing, and if understanding improves, Launchpad gets new icons  \0/

Improving Launchpad icons, round 2

Following up on my last post about user testing icons, it has been incredibly successful!  We’ve had over 100 responses, and are now going through the data to put together a summary. I will post information on our findings as soon as we finish the work.

In the mean time, Charline Poirier, who is in charge of user testing in our team, has created another survey with 5 more icons to help us get more data. If everyone could give this survey another spin, and create some networking effects to help spread the survey to non-Launchpad users, it would be tremendously helpful to us. Here’s the link: http://www.surveymonkey.com/s.aspx?sm=6iwthaIT4FwPCsMPa1EDEA_3d_3d

Help Launchpad get better icons

We’re trying to improve the icons we have in Launchpad so they’re more usable across different cultures and types of users, and our first step is to do some user testing on our current icons.

The Canonical User Experience team has set up a survey to gather information on how users see our icons, so if you have a few spare minutes (it’s very quick!), please take the survey and pass it on to other people, especially if they don’t use Launchpad, as they will be less biased.

Survey is available at: http://www.surveymonkey.com/s.aspx?sm=8hXmjrmFS7TmQCjh7jJB_2bQ_3d_3d

Launchpad is now fully open source

As promised, Launchpad has been fully open sourced (as opposed to the initial idea, nothing has been held back). Get it now, fix your favorite pet bug, and improve tens thousands of people’s experience.

Mark Shuttleworth really deserves a lot of praise for this bold and brave move, open sourcing not only the code, but all  it’s history. It’s a fantastic day today.

Update: yes, fully means including soyuz and codehosting, Mark has decided to release everything. The whole history is there.

See the loggerhead page:

launchpad-open-source

Working at Canonical, 5 months later

A week ago I started going through my blog’s logs, and realized that I’d had a jump in visits from Google. Digging a little bit deeper into it, I realized that a lot of people seem to be searching for “working at canonical” phrased in different ways. From what I can gather, it’s split up into two groups: people who want to find a job in Canonical, and people who are considering a specific role and want to know what it’s like.

So, I thought it would be useful to provide information for the dozen of people who land here every day  🙂

If you want to work for Canonical, check out the employment page, it always has the latest job offers: http://webapps.ubuntu.com/employment/
Among many other things, my team is currently looking for awesome people to join the User Experience Team, the coolest place to be today  😉

As for what it’s like to work at Canonical, here’s my take on it:
At this point, it’s been a little over five months since I started working full time, although I was doing some contracting work before that, and I’ve been around the Ubuntu and bzr community for ages, so I already knew a lot of the people before joining.
One of the coolest things for me is that the way most of the company works, is basically the same as your typical open source project: mailing lists, irc, distributed, and filled with passionate people. If you have an open source background, the transition should be pretty seamless. Coming from other companies may take a little bit of getting used, but you know how it is, “your mileage may vary“.
The Ubuntu-like atmosphere where everybody is extremely nice and respectful seems to span across the whole company as well. This was especially surprising to me considering that everyone is astonishingly smart, and have done amazing things I had read (and still do!) on news sites for years. My experience is that when too many smart people are together, it’s a much more cut-throat competitive environment. Here, it is not. You could sit down and have a fantastic and interesting dinner with anyone in the company (I’ve shared meals with dozens of different people, and it’s held up true every single time).
On the technical side, all the teams are constantly revising and improving work flows and tools, pushing towards the cutting edge by adopting all kinds of lean and agile development strategies, while still being very much test-driven. What can be more appealing to a developer than that?
Finally, there are so many interesting projects being worked on at the same time, it’s often very hard to keep up with what’s happening. Personally, I believe that the balance between open source development and projects developed in-house as services or for third parties, plays a very big part in making everything happen so fast a two-hundred-and-something people size the company. It’s amazing how so many people are payed to work full time on directly on free software, directly interleaved with the community.

So, as you can guess, my recommendation is that if you ever get the chance to work for Canonical, take it, it will almost certainly be a fulfilling experience.