Implementation Focus: Nestoria

By YUI TeamNovember 7, 2007

The whole team at Nestoria HQ.

We've been reading about property-search-engine Nestoria on places like TechCrunch UK for awhile, and we'd heard this summer that they switched over to YUI. This week we tracked down Nestoria's co-founder Ed Freyfogle to check in on their project and progress and to see how their YUI implementation was going so far.

About Ed Freyfogle: Ed (on the left in the picture above) started his career in the heady days of internet 1.0 working as a developer for Yahoo! Europe. After 5 years of intense data slinging he left in 2003 to get an MBA from MIT. In 2006 he co-founded Nestoria, a start up focused on European vertical search. For fun he outsources things.

Tell us a little bit about Nestoria's product — what problems are you solving for your users?

We're a search engine for property in Spain and the UK (,

We focus on one thing and one thing only — helping people find property to buy or rent as quickly and easily as possible.

That has a couple of pieces: data quality, freshness, speed, and of course the usability. That's where YUI comes in — helping us build the interface that allows users to intuitively understand our site and find the content they are interested in.

We work hard to make things very simple for the users. It may sound counterintuitive, but creating simplicity can be exceedingly complex technically — you can imagine ranking algorithms, geocoding, etc.

The Nestoria site itself is a mashup of properties with maps and overlays of all kinds of relevant content like schools, tube lines, pubs, photos. We also make data available via an API, geoRSS, KML, all kinds of widgets and a Facebook app, so we're pretty busy.

Here are some examples:

We're a small start up of internet veterans. The company has been around since 2006, and the site is made with LAMP where the P is perl.

You transitioned the product recently to YUI. What factors led you to choose YUI for Nestoria?

As a small company (9 people — that's total, not just developers), it's very difficult for us to test on all OS/browser combinations, so we love the fact that YUI comes with A grade browser compatibility. In the past we spent days debugging keystroke event handling.

Other major factors were the well organized documentation and examples, the continual innovation, and the great community that supports YUI.

The icing on the cake was that we don't need to serve the libraries ourselves. This is good for two reasons: lower bandwidth costs for us, but also our pages are faster because users are more likely to have the libraries cached to begin with.

Finally, we appreciate the effort that goes into consistent namespacing — we're running other bits of javascript like mapstraction and Google maps on the page as well.

What parts of the library are you using today?

Right now we use four pieces:

a. the autocomplete for our search boxes — which is truly amazing in how customizable it is:

AutoComplete in action on the Nestoria website.

b. the sliders that allow users to set their search filters

Nestoria's interface allows you to use sliders to select a price range and features like the numbers of bedrooms and bathrooms.

c. we're testing the use of animations to hide more advanced features from users until they really need them

d. some of the CSS libraries for styling

How is YUI performing for you so far?

Beyond all expectations. The libraries do what they claim (which I can't say for other libraries we looked at), so that part has been great. What's been amazing though has been the support of the community. Questions to the support list get answered quickly, by absolute experts.

What's missing? What's been hard about using YUI so far?

I'd like to see the examples expanded — I think that would reduce the volume of basic questions on the support list.

One challenge I see for the YUI team going forward is the need to simultaneously serve both advanced power developers and also first time javascript users. Not easy. The sheer volume of questions and feature requests is rising.

I think the only sustainable solution is to give the community the tools to support itself. As an example, there are times we'd love to save time and just pay a YUI expert to spend an hour or two building a prototype showing us how to implement something. Perhaps Yahoo! could facilitate these sorts of things?

Another simple solution might be to divide into a newbies and advanced list.

In terms of technical specifics — I would love a dual slider — though we were able to find and extend a user created version.

Also, a tool to tell us which libraries we need - we want to load only the absolute minimum and not reference 10 javascript urls. Mootools does a good job in this respect.

In terms of rich-client work, what's next for your product? What are the hardest problems you're trying to solve on the UI side in upcoming versions?

We recently launched access to 'meta' data — things like average house prices. We're looking for some interesting ways to visualize this information.

Nevertheless, the focus for us is always simplicity and speed, so it's unlikely we'll be adding much heavy rich-client type stuff to our site. We focus on presenting highly relevant data as quickly and in as user friendly a manner as possible.

That being said, we do offer all of our data via our API. We'd love to see folks get their design freak on and do some crazy data visualisation stuff (*hint*, *hint*).