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
