[photopress:shackprices_1.gif,full,alignright]
Really, in the world of the web, slow speed kills. And most people only think about the length of time it takes a website to load when it is taking eons to show up. For static sites, meeting the magic four second page load time isn’t too hard, but for sites with lots of “dynamic content” (fancy menus and whatnot) and maps, it becomes sort of a trick.
Many (most?) fancy real estate search sites are plagued by slow load times – see the real estate 2.x person’s site reviews to see scathing analyses of how long it takes to for many sites to load. In light of this, we took great pains to make our site both feel and be speedy and, if I don’t say so, I think we’ve been pretty successful. On my old-ish computer, the Seattle real estate page typically loads in under 10 seconds (we could still do better on this!) and house detail and nearby pages typically load in under 3 seconds.
One of the tricks we employ is we don’t actually shuffle visitors from a complete page to a completely new page, which means we don’t have to reload the time-consuming Google Map or any of the stuff on the sidebar. Instead, we load little subpages within the site using AJAX (which is, I believe, a dumb acronym). When you click to see the details for a house, we only load up those details and leave the side and top of the site alone and intact. When you click back to the map tab, it’s already there waiting for you because it was just hiding behind the house information.
There are some other tricks that are much more technical: before we launched in December we did a bunch of optimization to cut down the time it takes our database (with over 30,000 western Washington properties currently for sale) to find and spit out the houses that match each search. Currently it it returns the ‘shacks’ that match your search within a second of you dragging the map around – the rest of your wait is the time it takes to actually send and display that information on your screen.
The dynamic updating introduces a can of worms of it’s own, including longer development time, but we think the tradeoffs were entirely worth it.
This is the first in a series of “Behind the Shack” themed posts. If you are especially interested in one aspect of ShackPrices.com, let me know and I’ll try to write about it!
Random questions….
Why did you pick the platform / software tools you did? Did you consider something other than Ruby, Postgres, Google Maps, etc. when you started? Using any Javascript libraries, or other packages?
What would you say were the most challenging feature(s) to implement were?
What parts of the site are you most proud of?
Good questions Robbie. The platform choice was pretty easy – we needed open source for both preference and cost. Ruby on Rails is a great open-source MVC framework that automates a lot of things programmers do over an over, which means we could develop the site extremely quickly and efficiently.
For our database, the choice was between Mysql and Postgresql. Postgresql has a great system for storing and analyzing spatial data, and we are a map-based site after all.
We’re using the Prototype library, primarily because it’s good, but also because it’s the default javascript library that comes with Ruby on Rails.
I’ll address the challenging features and proudest moments in a future post…
I guess the question I have regarding the platform choice is why Ruby over some Java based variant (Tapestry, Struts, etc)? I’ve heard Tapestry is a pretty good MVC framework and I suspect (although I don’t know), that the dev tools are more mature and the community is larger.
I assume when you started you were equally comfortable / unfamiliar with both?
I’ve heard good things about Prototype (so many AJAX frameworks, so little time)…
As a house surfer, the biggest difference I see among these map-based MLS apps is the house plotting algorithm. What made you choose the “show (random? first?) 50” algorithm?
I like your site, but I have to say that’s the one thing I would change.
Hey there anon,
We do limit the number or results shown at any given time to 50, but they are sortable by price, beds, sqft or days on ShackPrices – just click those headers to change the sorting.
We’re going to add a feature to let you change the number of properties shown at a time. Soon! I promise!
Robbie, we didn’t really look into Tapestry. However, Rails is a famously quick framework to get started using – “convention over configuration” is the mantra and it’s one I subscribe to.
Prototype does the job – I haven’t explored many other javascript libraries either.
Robbie, if you want to see the super-nerdy side of ShackPrices, we’re blogging about code at StartupsOnRails.com.
Thanks for the response, Galen.
An increase over 50 would be nice, but having some sort of icon for all homes in the displayed area would be ideal.
If I can’t see them, I don’t know they’re there. 😉
So anon, most (all!) of our competitors flat out won’t show you homes when there are “too many,” which leads to a blank, uninformative map. I was going to address this in a future post, but we want to let you quickly browse all the homes for sale at any zoom level.
When we were building the map component, Google maps was actually much slower at adding the points to the map, so we compromised quantity for speed. They’ve dramatically improved the loading speed, so we’ll be upping our default display number soon. Given the choice between “over 400 homes match your search, please zoom in to see any” and “1,000 homes match your search, showing the first 400, I’m still going to go for the second option.
At some point in the future, we’ll obviously display more general neighborhood and city information when you’re zoomed out and house-specific information when you’re zoomed in, but that’s an entirely new can of user interface worms we’re not opening right now.
Yeah, this is why I thought a discussion of plotting algorithms would be interesting.
I’ve used one that required you to zoom in until the number of plots was under 300. What a poor user experience, especially when I’m at a zoom level with, say, 301 homes in view.
How about this? Auto-zoom to whatever level is required to fit whatever your plot limit is. If I zoom out past that, give me some indication that homes are in the list box that can’t be displayed, but just leave the newly exposed map unplotted.
Hmmm – I think it would be really disconcerting if the map started zooming in and out on you (what if you panned from a rural area to Bellevue and suddenly the map jumped in!), but I’ll definitely consider that as an option.
What Zearch does, is that it plots the 200 properties closest to the center of the map and less than 2 miles away. I also like what ShackPrices does here (I think you plot the 50 newest that fit in the map).
I hate implementations that plot nothing if you have too many results. I think you made the right trade off.
Robbie, Zearch is my favorite plotting implementation so far! Quick, simple, and intuitive.
My only complaint with Zearch plotting is that you lose my zoom level whenever I click on a listing
Oh, and it’s a little weird in that it’s “modal.” I start browsing with a list (similar to shackprices), but as soon as I click on a listing, I’m in individual-listing mode and generally stay there as I click on more homes.
In any case, thanks for all the choices you guys are bringing to market. I hope you both become billionaires. 🙂
Anon,
Thanks for the complement. When I get ready to do Zearch 2.0, I’m going to be less model, have more AJAX/DHTML goodness and be more like ShackPrices, etc…
Until then, I’m just going to work on being fast, because speed never goes out of style. 😉
Galen,
What do you use for database stored proc debugging, schema/data comparing & synchronization and profiling? Does Postgress or MySQL have any of the database development goodies that MS SQL has available? EMS SQL Studio seems pretty decent, but I’ve never tried it (I use Red Gate for whatever MS doesn’t put in the SQL box). I’ve yet to find a profiler or debugger for an OSS DBMS. I assume they exist? (or at least I’d hope they do).
Robbie, we have no stored procs, therefore we have no stored proc debugging. Our code is reasonably (but not sufficiently) well tested using Ruby on Rails’ built in testing suite. Right now we’re migrating to rspec.
We have one database box and we use rails migrations any time we change the database, so we just run the migrations on the deployment server when we deploy a new release. Slick!
We haven’t had the need to do serious profiling yet, but there are tools for it when we hit that point. We also plan on having a dedicated database person when we start seriously profiling.
Hey anon, ShackPrices now defaults to showing 100 houses at a time. You can increase the default to up to 600 houses at a time on the account information page.
Thanks for the feedback. More to come soon!
Great site — I love shackprices.com. Nice work. I have read that you originally started coding shackprices in php and then moved to ruby on rails. What were the main reasons that you decided to move from php to rails?
I’m about to start on a real estate 2.0 site in southern cal and am trying to decide between using the 2 technologies. I know php and don’t know rails, but I’m very intrigued by it — especially the “MVC framework” part, in that the development is very organized (and separation of logic & presentation is done etc.) Two questions for you:
1. What made you switch from php?
2. Are you still happy that you made the switch? Are there any shortcomings that you realize now (that you didn’t see before)?
thanks very much for a great site and your inspiration.