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:

  1. 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…
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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 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 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.

Comments are closed for this entry

Please send your feedback via Twitter to @jmk.