Cameron Adams on Designing Google Wave

If you’re yet to be up to speed on Google’s next big thing, Wave, let me give you the elevator pitch:

We all know about protocols like HTTP, email, and instant messaging. Google have now developed a brand new protocol called Wave – and the applications that power it – which aims to weave a bunch of those protocols into a new, coherent whole.

In practical terms, this puts IM inside your email, Twitter inside your IM, maps inside your Twitter, and much more. It’s hard to overstate the ambition and scope of this project, but if you want to gain a clearer picture, I recommend listening to the full presentation Lars gave in late May.

Recently, I had a chat to Cameron about his life as a “G Man” and some of the ground he’ll be covering in his Web Directions South talk in October.

Take the Web Directions Quiz and you could win a ticket to see Cameron’s presentation at Web Directions South in Sydney later this year.

SitePoint: Hey Cam, thanks for giving us a little of your time. Google Wave certainly made a big splash (excuse the pun – I’m sure others have done it too!) at Google I/O in May, and web-types are pretty excited about the prospects of reinventing online communication. How do you go about defining interfaces for a form of communication that’s yet to exist?

Cameron Adams: Sure, Wave in its exact form didn’t exist yet (at that stage), but that doesn’t mean it hasn’t been influenced by prior technology. There are quite a few different communication models that map fairly well to Wave – forums, wikis, chat, document editing, email – so our starting point was to look at all of these models and figure out which parts would fit well into Wave’s structure.

The hardest part has been reconciling differences that seem to be diametrically opposed.

For example, the immediacy of chat versus the more lengthy, structured nature of document editing – how do you submit content after you’ve finished typing? The enter key? You would in chat, but people use the enter key in documents for line breaks.

Our solution was to appropriate shift-enter to submit, which works quite well (you can tell it does when you start using it everywhere else) but raises learnability issues.

That’s the other main challenge – knowing when to stick with convention and knowing when to forge ahead with a unique solution. Sometimes you get it right, sometimes you don’t. That’s what testing is for!

Yes, I guess it’s really easy to forget how many different uses the enter key has across different applications.

Google is obviously renowned for its testing. How did Wave’s user-testing program work? Are new functions and features user-tested as part of the process of implementing them? Or is it more useful to user-test the application as a whole at the end of each development phase?

We’re still very much in the midst of testing. It’s still a while away before we get this thing into the hands of consumers, so in between now and then we’ll be fine-tuning things frantically.

There are two types of testing that we undertake with the product, and they’re at very different levels.

For testing stuff hot off the presses, we basically walk around the office with a few prototypes, tackle people to the ground, and force them to use the application. This could either be in the form of static mockups or sketches, coupled with questions like: What do you think will happen if you click this? Or, the process that I find most valuable for an application like this is to create a simplified prototype of the behavior that we’re thinking of and let people have a go on at it.

It’s quite different to have an image that requires people to use their imagination than it is to present them with what the engineers will build after two months. So, I have a bunch of different interactive prototypes that focus on one area each – scrolling, typing, inserting, dragging, and so on. And we’ll tune these until we like what we have and users get the optimal experience. Then we hand it off to the engineers to build it properly.

The second set of testing that we perform is more longitudinal – it tracks people’s usage of the product across a series of weeks and months. This allows us to see which concepts are best communicated to users, whether people grow used to some of the application’s unique interactions after a while, and just the general usefulness of the product in day-to-day life. For the moment this is all done with internal participants, and at a place as big as Google we have no shortage of subjects.

Wave is a project of enormous scope. I suspect many techy people are really excited about it, but may have difficulty defining the benefits to their managers and cheque-signers.

Do you try to design it with simple pathways in and easy wins for early adopters? Or do you just create the tools and let people decide how and where they’ll use it?

We think that the product itself has easy wins for early adopters, so you can gain benefits out of Google Wave whether you use every feature or just one of them. But from a design perspective we’ve also tried to balance carefully between first-user experience and creating a more feature-rich product for people to explore … perhaps swaying every now and then in the direction of features.

Letting people understand the product and come to grips with it the first time they use it is definitely a strong priority, and probably something we haven’t quite finished yet.

I always advocate for simplicity over complexity (which is hard in a company of engineers!), but we also acknowledge that the interface is only one part of the
puzzle for first-time users.

So we’re also focusing on ways to engage people the first time they log in, ways to keep them motivated as they use the product, and also a lot on the messaging of the product outside of the application – creating marketing materials that not only interest people in Google Wave but also inform them of how it can be used. I think the iPhone has done a masterful job of this.

Obviously Google has an almost unfathomably broad cross section of users. Who did the Wave team collectively have in your mind when designing for a user-base like that? Is it just lowest common denominator or does Google have a set of user personas that they use, or do you just try to make it work for Lars and Jens’ mum?

Not only their mum but also their extended family.

Much like a lot of stuff at Google, Google Wave is mostly written to scratch our own itch. Are we missing something that we need? Are we building something that we don’t need? In that sense, we aim for a fairly decent level of technical competency, as they are the early adopters. But we aim for the basics of the interface to be simple enough for less competent users to pick up fairly easily.

I know that other projects within Google have used personas very heavily in order to define the targets of their application. However, for various reasons we haven’t adopted them on our team, despite the valiant attempts of our user researcher, Aaron Cheang.

At a broad level, though, we build for more consumer-oriented uses of the product. Enterprise is a lot harder to get into due to the inertia of legacy systems, so that’s something that we like to tackle after consumer adoption has made a product a success.

Having said that though, there’s been an astounding amount of interest in Google Wave from the enterprise sector and we have a strong enterprise story in the wings, so that might affect what happens right after our consumer release.

At the moment a lot of the standard communication formats – email, IM, and Twitter – are generally widely accessible. Does integrating them into a single, non-linear application potentially introduce accessibility issues?

I don’t think there are any inherent accessibility issues with integrating different forms of communication into a single product. There are definitely challenges in having them work together in a cross-format way (how do you handle an email user on a live chat?) but that’s more about different services working together rather than accessibility.

I think one of the great things about Google Wave is that the project isn’t just about our client – it’s also about the APIs and the protocol itself.

We definitely know that we can’t meet the needs of every user on the planet, so just like Twitter I can envision a world where there are dozens of different Wave clients that cater to a user’s specific needs – simple, complex, live, static, aggregating, mobile, big, small, web, desktop. Take your pick and build it how you see it.

Wave integrates with Twitter really nicely but refers to these events as “Twaves.” Did you make a stand against the adoption of this term?

I would have made a stand if I’d known about it!

The extension/API side of things is probably Wave’s equivalent of the wild west. Developers go off and build things, and I see them when they’re demoed. So, the interface could be a bit … unpolished, as is the nomenclature.

There are great advantages to doing it this way – someone with a bit of programming knowledge can quickly build an idea and see if it works, without having to go through hoops to get an interface done. Then, if it turns out to be useful we can then start refining the experience.

The downside is that if you build it, you get to name it!

Ah, and in a piece of segueing genius, I’m led to believe that’s the kind of topic you’ll be talking about in your WD09 talk?

Exactly. At Web Directions I’ll be talking about innovation: how it can work inside a large company, how we approached it, how to design (with it in mind), and (more) broadly about designing for the next generation of web applications.

Okay Cam, thanks for spending some time with us, and we look forward to catching up with you in Sydney in October.

Cheers Alex.

Remember to take the Web Directions Quiz to possibly score yourself a ticket to Web Directions South in Sydney this October.

Image credit: Web Directions