Tip:
Highlight text to annotate it
X
>> All right, Sasha. Can you give us a little introduction to your company and your products?
>> AICKIN: Sure. My name is Sasha Aickin. I'm the engineering manager of the search
team at Redfin. And Redfin is an online web Real Estate Agent. So the idea is you--we
pull together information from lots of different MLSs (ph), and we show that information on
map. We do make searching really easy. And we let people find the houses they want to
find. We help them get into those houses and tour those houses. And then when they want
to put an offer on them, they can come to us, and we have agents who will help them
make the offer, go to through (inaudible), do all the things you need to do to buy a
house. But we only charge half of what Traditional Real Estate Agents charge. Because of the
efficiencies we have on the web and, you know, because people are doing a lot of their own
search, that's people really want to do these days, our agents are able to be incredibly
much more efficient than Traditional Real Estate Agents. A Traditional Real Estate Agent
only does, you know, six or so deals a year. Our agents can do that many in a month. And
so, we use Google Maps and other APIs to make search as hopefully as easy as possible for
our customers. >> All right. So tell us a little bit about
your decision to use the Google Map for your product.
>> AICKIN: Sure. Our decision to use Google was interesting. We actually--when I started
we were work--we were using a proprietary Flash client. Redfin actually started doing
listings on a map before there were easily available maps APIs. And we had what I'd like
to call the parallel of the first mover, you know, that first mover disadvantage really
because, basically it was actually before I got there or sort of just happened. They
actually, it was a Seattle-only business and actually source to satellite imagery, created
the image pyramid tiles, created a proprietary Flash client, built the whole thing, and we're
showing listings on the map. And people in Seattle thought this is really cool. It was
popular in Seattle. But then Google Maps, API came out, and it was suddenly--it was
really easy to put listings on a map, and we are sort of at a disadvantage. After I
started, we actually switch to Virtual Earth API, and we run that for two years. But we
switch to Google in November or so, November-December, and the number one reason was speed. We, you
know, we put a lot of things on the map. We put up to 500 listings on the map at a time.
And we're very heavyweight Ajax site, and we know that speed is incredibly important.
So we had all along done test Virtual Earth versus Google. And eventually we found a way
to add pushpins or markers--pushpin is a deadly (ph) term, to add markers really fast to the
map at Google. We talked about it today at IO at the Performance Session. And when we
found that we could it much faster in Google, we called up the team and started talking
about doing it. >> Great. Was there any technical challenges
that you had using the platform? >> AICKIN: I mean, you know, no more than
you would know--so I wouldn't say there were tremendous technical problems. The biggest,
I think, insight we had to get was how to add a ton of things to the map (inaudible).
That's our single biggest--our single biggest technical challenge. But I actually--once
we figure that out in sort of researching kind of way, I actually spent a long weekend
where I supported our site from Virtual Earth to Google maps. And we had to spend another,
you know, two weeks or so polishing and getting all right, but it basically worked after the
end of the weeked of just being working on it. It was sort of--it's one of those, you
know, math (ph) fueled, you know, coding weekends of craziness, but it actually, you know, I
was surprised at how well--how quickly things went.
>> All right. All right. So you mentioned performance, talk to me about the performance
of the platform. >> AICKIN: Sure. I mean, I think it's you
know, Google puts a lot of, you know, of emphasis on performance, so that's something we really
value. The images are on CDN. The script is much smaller than some competitors. It's--and
I'm very heartened (ph) as well that V3 (ph) which was announced yesterday most of the
thing--most of the reason behind it, most of impetus is performance. So modular, I think,
in script. You know, putting up a static image before you can pull down the tile. These are
all great things. And, you know, it matters to me that they're thinking about performance
constantly. So, you know, overall, it's been really great.
>> Great. >> AICKIN: As I say, we didn't have trouble
adding tons of things to the map, but we were able to just sort of to do a custom overlay
and make that work much faster than we thought--we'd be able to.
>> Okay. So how did the maps improve your user experience?
>> AICKIN: How did the maps improve our user experience? It's an interesting question,
because in some ways, we're known for the map being our user experience. I mean, I said
this before, you know, the old, you know, the old thing in real estate is--the three
most important things are location, location, location. You've all heard this, right? But
we kind of took that as what our UI should be too. You know, we--our UI is very app like.
It's not a long page. It's--you know, it scales to the browser size, no scroll bars. And,
you know, it has this big map right in the center, and that's really how you define your
search. You can type in the neighborhood saying, you know, "The mission," for example, and
it will draw a polygon--it will go there and draw a polygon on the map, but you can refine
that, you can zoom in, zoom out. And every time you move the map or pin, we do another
search. We go back to the database and pull new records. I mean, it's almost the weird
question to say, "How does it help with the user interface?" because it really just is
the user interface. Now, I mean, there are--there's a thing on the side that shows you the details
of the house, and there's a list below. And we find it's really important to display them
spatially, but also have a list so that people can sort of scan in another way. But by in
large, we're known as the company that has--that uses the map as their main user interface.
>> Okay. So, what do you see in the future of mapping?
>> AICKIN: What I see in the future of mapping? I think there are a lot of interesting things
coming in the future. I think, you know, once again, performances, hopefully going to get
better. It's been interesting to hear all these people talk about HTML5, which I think
is great. I'm still wondering what we're going to do about IE6 and--I mean, I don't know.
I haven't heard--I haven't heard anybody give me a good story on that one yet. But--so I
think performance, being able to show more things. I think intelligent, smart, performant
and, you know, good feeling algorithms for clustering are going to be something that
hopefully is happening, you know, soon. I think a lot of people are working on that
in different--from different angles. It's actually--I've just working on it this week,
so it shockingly hard. It's shockingly hard to get a UI that really feels good in clustering
that you know it stays consistent and maps to the way the user thinks about how it should
work. I was just talking to somebody else from another company, and he saying that they
actually implemented the clustering UI two years ago, and I had to see they rid of it
because users so didn't like the way it worked. It's actually, it's one of those problems
that the more you think about it, I think, the harder it gets. So I think good clustering
and figuring out how to, you know, how to display a large amount of information is going
to be a really, a really interesting thing. And obviously, you know, rich media kinds
of things, you know, how much it's going to become more earthlike, and more flashy, and
more sort of HTML5, I think, it's probably one of the other good things for mapping.
>> All right Sasha, well, I want to thank you for your time today (inaudible).
>> AICKIN: Great. Thanks. And have a good time.