How To Make Maps The Center Of Your UI (And How Not To)

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Sasha Aickin, Engineering Manager at Redfin.

The oldest saw in real estate is that the three most important things about a house are location, location, and location, and at Redfin we took that as our user interface mantra as well. We made a decision early on that we were going to build a dynamic AJAX web app where the Google Map wasn't just a feature of the application but was the main driver of user interaction. The map is how users tell us where they want to search and what houses they are interested in buying, and our users tell us time and again that the map is what keeps them coming back.

That being said, we've made a lot of mistakes along the way, and I thought it might be helpful if I shared a few of the lessons we've learned over the last few years about building a map-driven UI:


#1 Always Be Thinking About Speed

Rich web apps that mash up many different APIs can be incredibly powerful, but after a while you'll start to look with a gimlet eye at every new API that comes down the pike. Why? Because every new API you add makes your site vulnerable to slowdowns, and your users will punish you for slowness.

Some of these slowdowns are inevitable, but many can be avoided by clever use of code loading techniques and HTTP caching. My best advice to people who ask me what they need to know before building a fast AJAX site? Follow everything that Steve Souders does. Read his book ("High Performance Web Sites"), follow his blog, and go to every talk of his you have a chance to. You'll learn how to defend your site's speed and delight your users.

#2 Carefully Consider The Full Screen Map

One early design decision you have to make with a map-driven site is whether your site is more like an app or more like a web page. Apps don't have scroll bars, and they resize all their controls when the browser resizes. Google Docs, 280slides, and Redfin are all examples of app-like sites, as is the main Google Maps site. Web pages, on the other hand, feel like documents. You can scroll through them, they often don't resize in a dynamic way, and they remind you more of a Word document than Word the application.

The full screen app style makes a lot of sense for sites like ours that use maps as their main navigation, but you can end up with a lot of user interface issues if you don't think the interaction through carefully. Before you make a full screen map UI, realize that your screen real estate is going to be severely limited, especially on laptops. Know that browser resize code can be buggy and difficult, especially if you have to support IE6. Understand that you will have to cut information you think should be in the interface for lack of space. If you have the time, create some prototypes of both app-style maps and web page-style maps and test them with users before going all-in.

#3 Make It Bookmarkable

This tip goes for all AJAX apps, but it is especially important for map-driven sites. Traditionally, AJAX apps have not been truly bookmarkable, and that has hindered both their shareability and utility. You want your users to share links to your site, and you want those links to always represent the same view on the map. If your users twitter or IM a link to your map-based site and it doesn't show their friends the same results that they are seeing, they're going to be confused at best and angry at worst. Furthermore, their friends aren't going to be exposed to your site, and you're going to miss an opportunity to create new users.

I won't lie, bookmarkability does add complexity to your app, but it's worth it. Pick up any of the many bookmarkability or back button JavaScript libraries and integrate it into your app. Your users will reward you for it.

#4 Decide How To Show Large Result Sets

If you're displaying results on a map, at some point you're going to come up against the problem of displaying many, many results on a map, and you're going to have to consider the problem of pagination vs. regionation.

Let's say you've built the ultimate map-based cafe finder, and someone searches the whole of San Francisco. San Francisco's a city that loves its hipster cafes, so you have 1000 results, but you can't possibly show those all on the map because you will confuse your users. Now you're faced with a choice: paginate or regionate?

Pagination would have you break down the results into groups of, say, 50 and show them one set at a time on the map, much the way that Google Search paginates your results. This is usually relatively easy to implement, but in my opinion it often misleads users. The typical response we've seen to paginated results on a map is that users think that they are seeing everything at once, and they get confused when a result that should show up isn't there.

Regionation, on the other hand, is the process of showing all the results on the map, but clustering them into groups so that the user can get a feel for where the results appear and zoom in to see more detail. Regionation usually provides a better user experience for large result sets but can be more work to implement. Search for "google maps clustering" to get some suggestions on how to start.

These are just a few of things we've learned over the years, and we'd love to discuss more of them with you either at the Google I/O Developer Sandbox or at the Performance Tips for Geo API Mashups session, where we'll be giving a short demo.

P.S. We've talked about Google Maps' speed previously on our developer blog, if you're interested in a little more detail.

Guest Post by Sasha Aickin, Redfin