August 2006 Archive

Design Inside Yahoo!: Kevin Cheng

Yahoo! Maps Beta burst onto the scene last year with a Flash-based mapping application that blew other maps out of the water. Meanwhile, Yahoo! Local has been continually innovating the meaning of local content and services.

This is the third interview of Design Inside Yahoo! This time, I interviewed Kevin Cheng, Senior Interaction Designer at Yahoo! Maps and Local. Kevin told me about how Maps Beta came about, rationalizing Flash vs. AJAX, how Local content is sourced, and what’s next for Yahoo Maps and Local.

Joshua Kaufman: Yahoo! Maps Beta is possibly one of the most complex Flash applications created for public use. What can you tell us about the design process behind its creation?

Kevin Cheng: We don’t employ any strict step-by-step design process in our team. It’s very much about what the project needs and who’s involved. Sometimes, we have a visual designer, an interaction designer, a researcher and a prototyper, all dedicated to a project, and that kind of team would dictate a different process from another project where one person is assigned to do all of the design work with little time available for research.

With Maps, it was a major redesign effort which started well before I joined the team. I don’t think you’ll find anything revolutionary in terms of general approach. We have a legacy mapping tool which is still one of the most used so that provides us with a lot of data about usage patterns and needs. Obviously, we keep tabs and drew inspiration from our competitors but not just from the big players - it seems like every day I receive something in my inbox pointing me to an interesting mashup or a mapping tool in Europe or Asia.

Outside of looking at the past and at others, it was also important for us not to focus on those so much that we’re not able to innovate. The team works in a very collaborative manner with ideas coming from all sides. Much like any software company, we have product managers who work with the team to figure out which of the great ideas stay and which won’t make it (yet).

After that, it’s a really standard wireframe/mockup/test/visual design/production cycle. It honestly strikes me as odd that so much press and attention is given to design process when it seems most case studies show the best ideas and products can come from the least amount of process. We incorporate as much process as necessary to make the team’s delivery sane but do our best to be fluid - which also means trying different approaches to process.

JK: What were the key drivers behind its design?

KC: The timing of when I joined the team meant I was in a position to look at the product with fresh eyes, but also one where I was asking questions that had been addressed previously. The interesting thing about design is that at times, it seems like something is obviously flawed in its design until you delve deep enough to understand all the issues.

As you said, mapping applications are some of the most complex apps, not just in Flash but probably on the web. There’s looking up where a location is and getting driving directions. Then there’s printing a useful map or set of directions. As we progressed, most online maps now have business lookup, some of us have multi-point driving directions, satellite imagery, live traffic - and this is before we even talk about mashups.

Our design consideration can be boiled down to one thing: use case prioritization. Unlike Google Maps, who have the luxury of inventing a mapping application without an established user base and interface, we were designing with an understanding of what our current mapping users do and what they do is get driving directions. That’s the majority case by a long long shot.

The entire design is geared around this knowledge. We design with driving directions as the number one use case in mind. We could probably still serve even that use case better. If you check out the Q&A of Seth Godin’s presentation at Google, he brings up a similar point about Google maps utility. The product is innovative and very attractive to people in our demographic, pushes the entire industry to do better and influenced our design, but it doesn’t really solve any perceived problem that MapQuest didn’t already do.

JK: Why did you go with Flash opposed to the more widely used AJAX?

KC: Why not? I mentioned this in a blog entry when we released the beta. When I joined and found out we were using Flash, my gut reaction was, “why?” as well. I asked the typical questions and in all cases, got satisfactory answers. So let’s run through them:

AJAX takes a lot of work. If you try hard enough, you can do almost anything with AJAX that Flash can do but the key phrase is “try hard enough”. Part of the reason that Google Maps was such a surprise was not so much its interface (that’s been done for years by MapPoint and other client based mapping tools) but the fact that they managed to accomplish this in a web browser. I think we were all just amazed that it was even possible. Except it wasn’t - not in Linux, not in Safari. Not only do you have to hack a lot to even get some things to work, you then have to hack some more to make it compatible with everything. Flash just works so long as you have Flash. Which brings me to my next point…
Depending on what numbers you listen to, the Flash install base is about the same, if not more, than the base of net users who have browsers capable of running JavaScript applications at the complexity of most AJAX mapping applications.
The design/geek community has a tendency to worship implementing something because it is hard to do. For example, you’ll see articles about how somebody managed to do something with just CSS. Nevermind that it took twice the amount of code, numerous cross browser hacks and offers no additional accessibility, it’s in CSS and validates! I feel like AJAX has that kind of community sometimes. “Look, I created this thing in AJAX - sure it’s been done a gazillion times in Flash before but it’s in AJAX!” Aside from the cross platform ease I mentioned, there are some effects that are just plain easier in Flash. The prime example is of course the pirate map and radar map Justin Everett-Church did soon after Beta launched (Flash 8 required).
Developers have the option of not only using Flex but also our AJAX library. I think people don’t recognize that we also have an AJAX version. So even if you’re not comfortable with the Flash version, we have an alternative which, from everything I’ve heard from the developer community, is one of the best API libraries in the market. A lot of Yahoo!’s own properties use the AJAX library like Yahoo! Travel’s TripPlanner and our slightly updated Local front page.
As a designer, I appreciate the feeling that the sky is the limit now when it comes to what kinds of interaction we could or should have. Of course that has to be tempered. Just because we can animate a gif doesn’t mean we should.
Finally, there’s the question of back button/address bar support. How will people send a link or bookmark a set of directions in Flash? The solution we have in place is what I feel to be the most underrated features we have. Every move, every plot, every zoom automatically updates the address bar so when you bookmark or want to send the map, you do what you would with any website - save or copy the address bar. Ironically, we kept getting asked where the permalink button was.

Don’t get me wrong, AJAX has created a lot of options for us as designers and Flash isn’t something I’d recommend for everything but I think people who dismiss Flash on principle are missing out on a lot. We certainly to run into problems, in particular with performance, but I’d say that so far, it’s a pretty nice package.

JK: Yahoo! Local, the Maps sister site, is a complex mix of content including maps, events, businesses and user-reviews. What was the process the Local/Maps team used to determine these key content groups and how they were presented?

KC: To be honest, I think we’re still trying to work that out. I think most people focus on Maps and don’t recognize how much it is tied to Local. There’s a reason that Google, for example, renamed it so both their products are aligned. They are two sides of the same coin and so far, I haven’t seen anyone, including us, do an elegant job of marrying the two.

Local is an underrated space in my opinion. Everything we do is potentially Local related: where something is, what to do on a given day, what’s been happening, where to buy something, places to visit on a trip, any business you’re looking for - this all involves a local space. Think of it this way, if you have to enter a zip/postal code/address, it’s probably Local related.

But we can’t include _everything_ into the Local product because it doesn’t make sense. One of the strengths of a place like Yahoo! is that there’s a lot of stuff you get for free. News, movies, classified, personals, weather, events from Upcoming.org and local experts from Yahoo! Answers to name just a few of the services already there. Instead of reinventing the wheel or competing for ownership, the trick is much more one of integration.

For the moment, we’re focusing on the local businesses. Helping people find businesses and services and helping them make a decision on which business to go to is what we do best. Still, we’re already seeing some areas where we’re trying to make more use of other properties. We have local weather, Yahoo! Answers integration in Local while Upcoming.org has more events now because they’re partly fed by Local.

JK: A big part of Yahoo! Local are user reviews. How does Local solicit users for this content?

KC: We try to provide as low a barrier as possible to them while still maintaining a minimum level of quality. Recently, we added what we call “QuickRate” to businesses letting you rate a business with a single click and then giving you an immediate way to enter some thoughts. This process is a vast improvement over the rather long forms we required users to go through before (though those are still valuable for more detailed feedback).

There have been some marketing campaigns such as the Best Of Yahoo! to help solicit reviews but as far as design, the focus is on making the site valuable to the users and helping them see the value of reviews. We’re not there yet, though.

JK: What’s next for Yahoo! Maps and Local?

KC: Well we’ve been quietly, and sometimes not so quietly, putting out new features as well as interface and performance tweaks to both products. For example, Local now has an AJAX map which displays recommendations to you depending on where you’re looking. Maps has tweaked its interface based on some user research data and also continually improved on its performance.

I can’t go into specifics but from both Local and Maps point of view, I think you’ll be seeing more and more efforts to make it worthwhile and valuable for our users to both consume and contribute. We know where the problem areas are with our products and I’d like to think they’re in line with what our users and would-be users perceive to be the biggest problem areas.

Since there seems to be a lot of questions around process and how we decide things, I will also mention that we’re trying some changes with both our development process and design process. Part of that is already in the press about our use of the Scrum process in various project teams.

In short, Yahoo! Local, Yahoo! Maps and its designers will be better, faster, stronger and more powerful than ever before.

Kevin Cheng is a Senior Interaction Designer at Yahoo! Maps and Local and artist/co-writer of the design webcomic OK/Cancel.

Email organization with one folder

LifeClever’s recent post about emptying your inbox reminded me that I’ve long wanted to say something about my own email organization strategy. It closely follows LifeClever’s initial advice, but unlike many other email organization strategies, it doesn’t involve keeping an empty inbox and it only takes one folder. Before you gasp in fear, just read on. You might be surprised how well it can work. Here’s how to get started:

Create an archive folder.
Move everything in your inbox to the archive folder. Go to your inbox, select all the email messages and move them into the folder you just created.

Now whenever you receive new messages, do one of two things:

If you can act on it, read it or delete it immediately (within one minute), do so. Then move to the the archive folder if you haven’t deleted it.
If you can’t act on it, read it or delete immediately, keep it in your inbox and act on it when you have time. This can be 30 minutes later, a day later or a week later - it’s up to you.

One of the ideas behind this system is that the inbox acts like a tickler file, reminding you about things you have to do. This can potentially result in an inbox that’s overflowing, but as a general rule I try to keep less than ten or so messages in my inbox. So once there’s more than ten emails sitting there, it’s like my inbox is telling me to get off my lazy butt and do something about it.

Some common questions

Q: How will I find messages without sorting them into folders?
A: The power of modern desktop search makes using folders for organization seem so last year. On Macs, I use Spotlight though I don’t particularly like the interface; on PCs I recommend the powerful Google Desktop Search for its simple and effective interface.

Q: Why don’t you recommend at least a few basic folders defined by the action that is required?
A: With every folder you create, you’re giving yourself one more choice every time an email arrives in your inbox. Do you really need to decide if you should put an email in a “Hold” or a “Waiting” folder? Using the one folder system, either you can action an item or you can’t. It’s that simple.

Q: Not even the Trusted Trio?
A: The Trusted Trio uses two additional folders: “Action” and “Hold.” My inbox doubles as my action folder, and I archive email that would otherwise be moved to a “Hold” folder. If I need to find a FedEx confirmation number or a message from a co-worker saying, “I’ll get back to you Tuesday re: The Big Project,” I’ll just search for it. And if I really need quick access to it, I’ll flag it for easier findability.

Q: But aren’t you mixing your apples and oranges in your inbox?
A: Yes, but I can easily tell them apart because new messages are bold and older messages aren’t.

Q: I like the idea in theory, but I get way too much email to keep my inbox in the single digits all the time.
A: You shouldn’t expect complete efficiency all the time; keeping up with email can be hard work.

Q: But there are just so many emails!
A: If you get so much email that keeping all those messages in your inbox seems unbearable then this system is probably not for you.

Any other questions? Please include them in the comments and I’ll try to answer them as soon as I can.

Design Inside Yahoo!: George Oates

Flickr, acquired by Yahoo! in 2005, is one of the most popular photo sharing sites on the web. It recently took on Gamma status with a new navigation, a redesigned AJAX-based organization tool and new search features.

This is the second interview of Design Inside Yahoo! This time, I interviewed George Oates, the UI designer at Flickr. I talked to George about Flickr’s beginnings at Ludicorp, its place in Yahoo!’s social media strategy and the Flickr design process.

Joshua Kaufman: Ludicorp preceded Flickr with the online multiplayer game, Game Neverending. How did the design of an online multiplayer game influence the design of a photo sharing site?

George Oates: Game Neverending (GNE) was designed to be a playful space where people could socialise. While there were certainly game elements (like exploring the world, buying and making things, exchange and such) essentially it was about interaction; having social connections in the game like friends or acquaintances, even enemies.

In terms of the UI, it was a Flash-based app, where you moved around the series of nodes that formed the world. Anywhere you went you could see who was there and open up a chat window with them. You could drag and drop items to collaborate and share, help people, or make new items.

When we came up with the idea of starting a photo-sharing project — you know, actually sharing as opposed to straightforward storage — the elements of interaction we had in place in GNE just seemed to fit.

So, we basically translated the game objects themselves into photos on top of the existing game architecture. Like, dropping a photo from your shoebox on to someone’s name to share it with them.

It was a lot of fun in those early days to see the way people would use a photo as the subject for discussion, and even use images within conversations to make a point, or a joke. The “social infrastructure” we created for GNE turned out to be really handy :)

JK: Tom Chi talked about how MyWeb fits into Yahoo!’s growing social media network. What is Flickr’s role in this network and how does it compare to Yahoo! Photos?

GO: I think Flickr’s role in the network is as a sort of figurehead… You know those ladies that were carved onto the prow of huge pirate ships? ;)

As well as that, the content that our members are producing can and is being used throughout the Yahoo! Network in really cool ways. Photos are being displayed on Yahoo! Travel, and in the new Trip Planner, and being showcased on the new Yahoo! home page as part of the Yahoo! Pulse.

The bigger Flickr gets, the more we’re seeing it as a huge, huge archive of our lives (produced within a fertile, surprising, collaborative space). With such a vast resource at everyone’s fingertips and our open API, who knows what the future will bring?

JK: When faced with a new interface requirement for Flickr, what is the design process you (or the Flickr team) typically use?

GO: We don’t follow any formal design process here at Flickr HQ, although I guess if you had to put our process in a box, you could call it something like RAD or XP. The whole team enjoys iterative development, and frankly, I think the best results come out of that sort of process anyway, in terms of personal creativity and input as well as the end result.

That said, there are a number of different ways that new features make their way on to our to-do list. I’ve been thinking of them as either Blue Sky New Bits, Things We Should Just Do, or Improvements to Existing Features.

Let’s pick the fun one, shall we? Blue Sky.

One of us comes up with a crazy idea.
We share the idea.
We talk about it.
We sketch out some requirements or a flow or something like that to frame the feature.
I sketch out some potential UI or visual design, usually in OmniGraffle or Photoshop initially.
We share our ideas.
We talk about it and start putting stuff on the Wiki.
The devs start coding stuff and working through changes we might need to make to the infrastructure of the system (a new database table or two, impact on existing data, that sort of thing).
I keep working on the design: visuals, interaction, copy etc.
Rinse, repeat.

Also, we always consider how the community might respond, and where we think they’ll need assistance. This is Really Important. :)

JK: Following that last question, how do you involve users in the design of Flickr?

GO: After we release something new, most of us hang out on the site, listening and gathering feedback from people, good and bad. Often we’ll stay tuned to a new release for sometime after go-live, making tweaks or improvements to it based squarely on what The People think.

I’m not sure we would say that we involve our members in the design of Blue Sky New Bits per se, but their feedback is essential when it comes to improving on stuff that’s already out there.

JK: Finally, I have to ask: Flickr recently dropped the beta status and took on gamma status. What exactly was the point of that?

GO: The point? Well, FUN of course.

We just didn’t see the point in shooting for a huge “1.0” release, because Flickr is always changing, and we want everyone to be aware of that, and find comfort in it. :)

I mean, the idea that a web application out there can label itself as “in flux” is exciting! For too long, software developers have toiled in development cycles of months or years, slaving over their specs with no release in sight. Of course we don’t want to release buggy code, but the added weight of having x features pass through y gates before we can deploy is, well, yucky.

That said, the release we did that we labeled GAMMA was a fairly significant change to the site — we redesigned the navigation system, the experience for new members, and wrote a new version of the Organizr. It seemed like a good idea to bundle all of them together.

JK: What’s next for Flickr?

GO: As if! You’ll just have to watch and see.

George Oates is the UI Designer at Flickr.

Backup more often

Hot on the heels of the internet is going to be switched off tomorrow; what five things will you print out? meme, my laptop was stolen last week. Why is this related to the internet being shut off? Well it isn’t, at least not directly. But print outs are kind of like backups, and if I knew my laptop was going to be stolen, I would have backed up my home folder more recently than two months ago.

The lesson: backup more often, even if you think backing up is overrated, it will never happen to you or [insert your excuse here]. You just never know.

I’m working from a spare vanilla laptop from work, but since I don’t - and probably won’t - have internet at home, and I can’t install anything on this laptop, my connected life has quickly slowed to a crawl. Not to fear, dear reader, more interviews with Yahoo! designers are on their way soon. Next up is George Oates, interaction designer for Flickr.

← July 2006 | Archives | September 2006 →