SitePoint Design View

Introduction

Welcome to Design View #61.

Let me set the scene: Google has a BIG idea and they're putting together a web dream team to make it happen. It'll be headed up by the Rasmussen boys of Google Maps fame.

And now they want YOU to join the Scooby gang.

That was exactly the scenario presented to SitePoint author and all-round web superhero Cameron Adams last year. Reminds me of an ubergeeky The Italian Job recast in Sydney.

This month I had a chance to ask Cam what life's like as a "G Man", and some hints on what he has cooking for us at this year's Web Directions South conference.

Speaking of which, Design View readers can win a ticket to Web Directions South by taking a short quiz -- you'll need to make your own way to Sydney, but for 30 seconds of your time to potentially save $995, it's certainly an attractive proposition, wherever you're based.

Finally, we'll take a quick peek at Aviary's new visual markup tool: Falcon.

Enjoy.

Alex Walker
Editor
SitePoint Design View

High Quality Designs at a Low Cost!

Are you a designer seeking amazing layouts and looking to put some extra money in your pocket?

• Over 1000-plus designs for ONLY $49.
• The best selection of Web, Flash, Flash-enabled, Newsletter, and Logo templates on the Web.
• Complete web sites (HTML or Flash) for only $29 extra.
• A FREE year of dedicated server hosting with a platinum membership.

To start making professional designs and earning extra money, click here!

Summary

• Introduction
• Cameron Adams Rides the Wave
• Falcon Grabs Screens with Talon
• Latest Tutorials
• Hot Discussions
• New Blogs

Cameron Adams Rides the Wild 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.

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!

SP: 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?

CA: 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.

SP: 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?

CA: 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.

SP: 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?

CA: 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.

SP: 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?

CA: 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's 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.

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

CA: 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!

SP: 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?

CA: 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.

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

CA: Cheers Alex.

Falcon Grabs Screens with Talon

Aviary have expanded their offering of nifty AIR-powered, bird-themed graphics tools with the recent release of Falcon -- a simple visual markup tool.

So what exactly IS a visual markup tool? Falcon is basically just a really neat tool for selecting, cropping, and marking up screen content. Bloggers, writers, and general forum junkies take note!

Like Aviary's other tools, Falcon is free and runs live in your browser via the magic of Adobe AIR. However, the bit that makes Falcon TRULY useful is its integration with Firefox via the Talon Firefox Extension.

So, here's the 30-second tour:

1) After installing Talon, you'll find a new button on your Firefox toolbar, and a new right-click/CTRL-click option on your mouse. Activate this control and you'll be able choose between capturing areas, whole pages, or the entire application window.

2) Once captured, your screen image is auto-loaded into the Falcon application inside your browser, complete with a small but useful suite of editing tools.

3) The toolbox allows you to add attractive, stretchable arrows, lines, squares, and circles with a simple drag and drop. As these are vectors, they remain fully editable at all times.

4) The Text tool lets you annotate your image. I must admit, I found the lack of text-size controls a little disconcerting at first. However, once you've become accustomed to the idea of using the scaling tool to control the size of ALL elements, -- even the text -- it's all good.

5) When you're happy with your image, you can then choose from two options: save to desktop or create an account with Aviary. The latter allows you to upload the image directly to their image hosting servers.

Though I confess I'm partly loath to add yet another image hosting service to my list, it's hard to beat the sheer click-and-forget joy of the Falcon/Talon system. The transfer process is completely invisible, and it also autogenerates ready-to-eat markup for Twitter, BBcode, Facebook, and WordPress. Slick stuff.

I've been using Falcon for a couple of weeks now and it has quickly become a fave. True, the editing tools are relatively modest but are good enough to make your point in 95% of situations. In the other 5% of cases, jumping out to more sophisticated tools (including Aviary's own Phoenix editor) is simple enough when required.

Most importantly, Falcon is superfast -- even on modest systems -- and clean, and positions itself exactly where you need it, when you need it.

Check it out and let me know what you think.

Who Said Web Design Wasn't Sexy?

• Design amazing web interfaces from scratch.
• Master key web interface design principles.
• Create beautiful, yet functional, web sites.
• Unleash your own artistic talents.

Free Preview

That's all for this issue -- thanks for reading! I'll see you in a few weeks.

Alex Walker
design@sitepoint.com
Editor, SitePoint Design View

You are subscribed as:
[email]

• Unsubscribe from this list.
• Manage your subscriptions.
• View the newsletter archives.

Mailing Address:
48 Cambridge St, Collingwood, VIC, 3066 Australia

Phone: +61 3 9090 8200