March 27th, 2009

8 Crucial Factors for Home Buyers

By Scott Petronis, Senior Director of Product Management

I know what drove my last two home buying decisions.  And I’ve asked everyone I’ve met for the past few months about what’s driving their decisions. But I wanted to get a broader perspective. So I went out and ordered the National Association of Realtors® Profile of Home Buyers and Sellers 2008.  It was well worth the price.  I have to say, NAR has some great researchers!  I’d highly recommend getting a copy of this if you want to understand who’s buying and what motivates them.

I’d like to share some excerpts from the research and give some examples of how Onboard Informatics’ Lifestyle Listings Engine can be put into action.

I’m going to pause one more time to note that this research was conducted by the National Association of Realtors Research Division.  I’ve tried not to misrepresent the information, misconstrue the results or take credit in any way for their fine work.

Facts and Findings

According to the report, 62% of all home buyers indicated that “quality of the neighborhood” was an important factor in their purchase decision.  There are obviously many factors that influence “quality” including both physical characteristics and overall reputation.  I’d like to dig a bit deeper into people’s heads to turn up how they define “quality.”  I imagine it means a lot of things to a lot of people.  But I am pretty certain that there are lots of variables involved in coming up with the quality judgement.

Sure enough, the NAR research team do drill into many angles and show that criteria vary by age group (young, first-time buyer vs. older, repeat buyer), location type (suburban vs. rural vs. urban), household composition (married couple vs. single female vs. unmarried couple) and other characteristics.  We all know that one “size” does not fit all but this report shows the extent to which that statement is true.

Included here are a swath of factors that influence the purchase decision, in rank order.  I haven’t included all of them in here, just the one that our Lifestyle Listings Engine helps to address (currently).  But trust me when I say that this report goes into MUCH greater detail.

Survey says…

1. “Convenient to job” was ranked as important by just over half of respondents overall, and nearly 2/3 in urban areas. With Lifestyle Listings Engine, a search can be conducted based on an address (i.e., work address) and a distance (i.e., 30 miles). Coming in the next release will be the ability to enter a desired commute time (i.e. 45 minutes or less) or drive distance (i.e., <30 miles).  When gas prices hit $5+ per gallon again, we’ll see just HOW important this one is.  Oh, and sorry to all my friends around the world who already pay nearly double that
2. “Convenient to family and friends” was ranked important by over 1/3 of overall respondents and two in five in small towns.  Similar to above, an address or set of addresses may be entered to determine nearby properties.  I also know from personally talking to many retirees that this one ranks very high on their list.
3. “Convenient to shopping” is important to just over 1/4 of respondents while this inches a bit higher in urban areas. So one of the new capabilities we’ve put into the Lifestyle Listings Engine is the ability to search for listings based on the distance to shopping.  For example, I only want places within 5 miles of a supermarket or pharmacy.
4. “Quality of the school district” is, no surprise, a crucial factor for over 1/4 of buyers and nearly 1/3 for those looking in the suburbs.  This is directly in line with the fact that roughly 38% of all home buyers have 1 or more child under the age of 18 in the household according to NAR.  So we’ve introduced the ability to search based on school performance using ratings from GreatSchools.  “Find me homes where there’s a GreatSchools rating of 7 or better.”
5. “Convenient to schools” was important to just over 20% of home buyers.  So just like convenient to shopping, a search can be conducted to find listings within a desired distance to a school.
6. “Convenient to entertainment/leisure activities” and “convenient to parks/recreational facilities” rank high. Nearly 1/5 of buyers overall want entertainment nearby while this number jumps to 29% in urban areas and over 1/3 in resort areas.  While nearly 1/5 care about parks, especially in urban and resort areas.  So we’ve made it possible to search for listings based on such items as golf courses, swimming pools, parks & playgrounds, cafes, bookstores and libraries.  And we’ll continue to add more amenities.
7. “Convenient to health facilities” ranks quite a bit lower overall but is important to 2/5 of those looking in resort areas.  So we’ve enabled search based on distance to hospitals as well.
8. “Convenient to airport” is important to just under 10%, especially in urban areas.  So we’ve also made it possible to find listings within a desired distance to an airport.  For the rest, they can make sure they’re far way from an airport so there’s a double benefit.

There are a number of other crucial factors that go into the search and decision process that we’re working out solutions for.  But I’ll hold off talking about those until the next release.

If you’re interested in the mean time, details about the first two releases of Lifestyle Listings Engine and other posts regarding lifestyle search can be found out Lifestyle Listings Engine and property Search - Related Posts.

We’ve also been doing some of our own research that we’ll begin sharing very soon.  I will say that our direct focus groups mirror what NAR’s research already confirms–there are many factors that influence the home buying decision that have nothing to do with the home itself.  But we’re also taking it a but further to understand how people go about searching.  We got some very interesting insights into how frustrating it is to conduct a home search.  And we can’t wait to share those insights and come up with solutions where we can.

As always, I appreciate your feedback, comments, criticisms and ideas.  Feel free to email me me at spetronis@onboardinformatics.com.

Tags: data, IDX, Lifestyle, Lifestyle Listings Engine, LLE, MLS, NAR Profile of Home Buyers and sellers 2008, Onboard Informatics, property search, Real Estate.

March 25th, 2009

Lifestyle Listings Engine Web Service - New Property Search Version 0.9 Delivered

By Megan Murphy, Marketing Manager

 Onboard Informatics launched the second version of Lifestyle Listings Engine - Version 0.9 today.

Lifestyle Listings Engine, the first ever enterprise-class property search based on consumer lifestyle, was first announced earlier this year at Inman News Real Estate Connect in New York.  Since then we have been working diligently to launch the  Listings Web Service enabling consumers to search for a home based on school system ratings, amenities, neighborhoods, commute time, and more all at the same time.

The first Listings Web Service delivery in mid February, Version 0.8, focused on two primary search mechanisms - geographic and parametric. Scott Petronis, our Sr. Dri. Product Management, goes into the specific details of Geographic Search, and Lookup capabilities in the Listings Web Service, in his previous post, Lifestyle Listings Engine Web Serivce - New Property Search Version 0.8 Delivered.

In this release, Version 0.9,  there are three new keycapabilities :

1) Search based on school performance:

One of the most significant search criteria for one of the largest home buyer segments is school performance. To this end, we’re enabling search based on proximity to GreatSchools rated schools of a specific value. For example, “I want to find listings that have 3+ beds and 2+ baths for no more than $500,000 that are near a highly rated school.”

2) Search based on distance to amenities:

The next set of crucial criterion are the local amenities such as parks, restaurants, supermarkets and hospitals. We’re enabling search based on a pretty long list of amenities so a user can ask for “Homes within 5 miles of a golf course,” for example.

3) “Get content”:

Once a search is conducted, the next logical step is for the searcher to want to know more. So we’re introducing new calls to pull back specific content based on a specific listing or the geographic container the listing falls within. The first such call allows a developer to pull back all the amenity details associated to a listing so they may present this, for example, on a listing detail page.

Scott goes into much greater detail regarding Version 0.9 in his post from last week.

A few cool new things we’re just completing put the “lifestyle” in lifestyle search. And believe me, this is just the start. To start we’ve focused on exposing some key new search criteria and also added a new content retrieval concept into the Listings Web Service. The concept is simple: there are criteria people will use to “drive” their search and then there’s additional content one wishes to see to help better educate herself/himself on the area surrounding the listing. So we’re exposing easily understood and highly relevant criteria in the search web service. Then we’re exposing more detailed content that may be pulled for presentation on the listing detail page.

What’s Next?

Lifestyle Listings Version 0.9.1 & Version 0.10 — Currently in development and testing. Targeted for release early/mid-April

• Get School District Content:  This will allow the developer to pull back all the school district content associated with a specific listing. Using this, the developer can fill out additional content pages to go along with the listing details.
• Search by commute time / distance: This will allow a user to input a starting address, such as their work address, and a desired time (i.e., 45 minutes) or distance (i.e., 30 miles). The search will then determine the listings that fall within the drivable area. We’re already looking at ways to get public transit as well as to determine neighborhoods and other geos that fall within the commute time / distance.

Lifestyle Listings Engine  Version 0.11 &  Version 0.12 — Currently in planning and design.

• Lead profiling: We’ll be capturing the various search criteria used in order to enable presentation of search preferences for lead forms, analytics reports, CRM applications or other uses.
• Search by community demographics: We’re working on a set of key demographics including age focus, socioeconomic status and household status.
• Criteria weighting and ranking: Providing the ability to weight the importance of individual criteria in each search to ensure the most appropriate results are returned.
• Additional Get Content calls: Enabling the retrieval of additional content to help provide greater details and insight into the community surrounding a listing.

Lifestyle Listinges Engine Software Development Kit — Currently in planning and design.

• We’ll be providing a set of UI widgets, helper code and documentation to enable developers to more quickly integrate our search into their sites and to do so with much more confidence than writing code from scratch. Our goal is to help developers get these capabilities up and running in days or weeks vs. months.

Please contact our sales support team at 646.747.4273 or info@onboardinformatics.com with any enquires regarding Lifestyle Listings Engine.

Also, don’t forget to subscribe to Onblog to get the latest news and deliveries regarding Lifestyle Listings Engine and Onboard’s other products.

Tags: amenities, data, home sale records, IDX, inman, Inman Connect, Lifestyle, Lifestyle Listings Engine, lifestyle search, listings, LLE, MLS, neighborhoods, Onboard Informatics, Products, property search, Real Estate, schools, SEO.

March 23rd, 2009

Form & Function: Continuing the Debate of UI vs. Functionality

By Robert Hahn - VP, Marketing

It is the pervading law of all things organic and inorganic,
Of all things physical and metaphysical,
Of all things human and all things super-human,
Of all true manifestations of the head,
Of the heart, of the soul,
That the life is recognizable in its expression,
That form ever follows function. This is the law.

-Louis Sullivan

At a panel discussion I moderated recently at RE Tech South on “The Future of Real Estate Search”, a very interesting point was made by the assembled panelists.  (And it was a rockstar-filled panel: Corey Kozlowski of Diverse Solutions, Rudy Bachraty of Trulia, Andrew Tillman of Center for Realtor Technology, Greg Tracy of Blueroof.com, Dan Woolley of Dwellicious, and David Carroll or softRealty.com)

The question was whether UI (user interface/design) is more important than Functionality (the actual search logic/behavior).  The panelists were nearly unanimous in saying that UI > Functionality.

Greg Robertson of Dwellicious followed up on Twitter with an excellent observation:

@robhahn asks at #RETS would you tell agents to spend more money on a web designer(UI) or a programmer to improve search. Panel says UI.  If panelist agree UI is more important than search then it doesn’t bode well for @robhahn (OnBoard) lifestyle neighborhood search.

Because we were so limited on time (30 minutes to get a discussion with six panelists?) I really didn’t have the chance to get that discussion going.  But that’s what blogs are for, right?

I made a semi-serious point to Greg via Twitter that it wasn’t whether panelists agreed that UI > Functionality that bodes ill for our Lifestyle Listings Engine, but whether they were right or not.  I’m going to argue (surprise!) that actually, functionality trumps user interface when it comes to foundational enabling technology.

Form Follows Function!

Form Follows Function: We All Agree!

The principle that form follows function has been a cornerstone of modern architecture and design for over a hundred years (Sullivan wrote his manifesto in 1896).  And it has been adapted in large part into the art and science of user interface design.

In fact, the entire notion of “user interface design” is premised upon using visual, audio, and textual cues to help a user accomplish something.  Otherwise, it would simply be called “graphic design”.

And I think Greg Robertson would agree with that.  Design is not how something looks, but how it works.

The real question then, is not whether UI/design should be divorced from functionality for the sake of satisfying some designer’s creative urge, (and to be fair, none of the panelists were making this claim) but which takes priority for the real estate web: user interface design or functionality.

On Priority: Argument for Why UI > Function

The strongest argument that UI trumps functionality is that the greatest functionality in the world doesn’t mean jack if it’s hidden behind crappy UI.  If folks can’t figure out how to use a thing, then it don’t much matter what that thing can do.

For example, take a look at this:

Powerful! If you know how to use it...

This is a tool for building and executing SQL queries.  Given any set of real estate data — including listings data — the functionality of a tool like this is enormous.  You can probably find whatever property you may be looking for, narrow down results quickly, and so on.

But it is safe to say that a real estate search site that simply puts a SQL query front-end as its “Find a Property” interface will fail miserably.  Unless you have a specialized practice catering only to database administrators.  In which case you’re probably going to be out of business soon enough.

In today’s real estate world, what determines success or failure is user interface design.  Companies like Trulia, Blueroof, Diverse Solutions, and softRealty spend thousands of manhours and millions of dollars creating compelling user experience for search.  That these websites hold a competitive advantage over a poorly designed site is readily demonstrated by traffic analysis or simply by putting a consumer in front of a computer.

(It should also be mentioned that far too few brokerages and agents pay enough attention to UI design.  Greg Tracy said, after reviewing a circa-1997 website, that it looked a lot like most realtor websites in 2009.)

Functionality vs. Enabling Technology

On the other hand, there is a distinction to be drawn between “functionality” and “enabling technology” — what one might call a foundational functionality.

For example, Adobe Flash is enabling technology.  It enables all manner of other functionality.  Things that could only be dreamt of before that technology is introduced are now made possible.

Google Maps is also arguably foundational functionality, because it expands the universe of what is possible.  It seems to me that the introduction of Housingmaps.com by Paul Rademacher in 2005 was the seminal breakthrough for real estate web.  (In fact, Housingmaps.com may have been the spark that lit the Web 2.0 fire.)

The Original: Housingmaps.com, which triggered Real Estate Web 2.0

After Google Maps (and Housingmaps.com), it seemed that you could not design a real estate website without incorporating listings with a map display.  All of the second-generation real estate websites of today owe a huge debt to the original Housingmaps.com and to Google Maps.

The key point here is that design, and user interface, naturally followed these foundational functionalities.  Once the enabling technology made it possible to put listings information right on top of a graphical map, the user interface had to adapt to make that possible.  Search boxes shrank in size, moved to the margins, etc. in order to accommodate the screen real estate of a map.  Designers began to put links into the pop-up bubbles, and map-based search began to make an appearance.

At the same time, however, as Dan Woolley of Dwellicious mentioned on the panel itself, while visualization of search results took a giant leap forward with the introduction of mapping, the property search itself hasn’t changed very much since the earliest days of the real estate web.  We are still living in the Zip/Bed/Bath world for the most part — map-based search is the sole exception.

Whether it is Realtor.com of 1996 or Trulia of 2009, the paradigm of search itself has not changed much: property features/characteristics within a geographical boundary.

That paradigm is what we have set out to change with Lifestyle Listings Engine (LLE).

Enabling Functionality

Our view is that if we are successful with LLE, we will enable a range of new functionality that is currently unavailable on the real estate web.  And that this new set of functionality is something that consumers are hungry for.

The theory — which we are testing, by the way — is that when people go to perform a property search online, they are actually not looking for a “3BR, 2BA house in 07054 under $700K”.  Our theory is that what people are actually looking for is something like: “Someplace with enough space for the kids, with good schools, that we can afford on my husband’s salary… and boy, it’d be nice if there were some decent restaurants nearby.”

In conversation after conversation — and now, in focus group session after focus group session — we are finding that consumers have a picture in their head of what they want.  Usually, these pictures are very hazy.  It takes time and a good deal of research to go from hazy desires to defined set of criteria like “3BR, 2BA, $700K in 07054″.  The process is filled with frustration, dead-ends in research, and a real sense of powerlessness on the part of consumers.

We think that consumers would use a tool that can more directly translate what is in their heads to results on a webpage.  We believe that this functionality will drive a new period of real innovation in the real estate web.  We think that talented developers and designers within real estate can’t wait to get their hands on a new toolset that will help them deliver new ways to answer consumer questions.  LLE is not, in my opinion, “lifestyle search”; rather, it makes “lifestyle search” possible.

That will require excellent user interface design.  Just as the introduction of mapping (and related GIS concepts) to real estate brought forth a new generation of user interface design, I believe that “lifestyle search” will change the user interface in fundamental ways.

I don’t know what that UI will be.  Is it a single-field natural language search, like Google’s?  Is it a set of dials and levers and sliders, similar to Kayak?  Who knows?  But I do know this:

That UI will follow function.

This is the law.

-rsh

Tags: Google Maps, housingmaps.com, Lifestyle Listings Engine, property search, real estate web, search, user interface design, web 2.0.

March 16th, 2009

Lifestyle Listings Engine…Another Step

By Scott Petronis, Senior Director of Product Management

In my last post I described the current capabilities in the Lifestyle Listing Engine Web Service and also mentioned some of the new things in the works. Well, we’ve been diligently at work and I’m happy to report we have some new stuff nearly ready for debut. In about a week we’ll have our next release ready for review. So I’m going to concentrate this post on what’s new and talk a bit more about what’s on the way.

A few cool new things we’re just completing put the “lifestyle” in lifestyle search. And believe me, this is just the start. To start we’ve focused on exposing some key new search criteria and also added a new content retrieval concept into the web service.

The concept is simple: there are criteria people will use to “drive” their search and then there’s additional content one wishes to see to help better educate herself/himself on the area surrounding the listing. So we’re exposing easily understood and highly relevant criteria in the search web service. Then we’re exposing more detailed content that may be pulled for presentation on the listing detail page.

School Performance
The first new search criteria is one of the most crucial for the largest demographic of homebuyers nationwide—families with school age children.  In fact, school performance can be THE driving force.  So we’ve focused our initial efforts on enabling searches based on school ratings from GreatSchools.   Now, within the Listings Web Service a desired GreatSchools rating (such as 8 or greater) can be identified and the search will return listings nearby those schools.  This way, a user can get an understanding of school performance up front rather than having to dig through a whole bunch of information after the search.  This may also be combined with other criteria so the user may search for listings within a specified distance of an address (i.e., their workplace), select a desired number of beds and baths, and input a price range.  The search will take into account all the criteria to execute the search.

The search can be initiated to just show counts of listings that meet the criteria.   Or it may pull back the listings themselves so they may be presented in tabular or map form.  Records returned may be pre-sorted based on any of the criteria submitted.  For example, you may choose to sort on the GreatSchools rating from greatest to least if that’s the criterion the user indicated is most crucial.

In addition to the search capability, a new call has been added to pull back the details of the school district.  This is especially useful when presenting the listing detail.  The way this works is that once a specific listing is pulled back, another request may be made (“GetContentSchoolDistrict”) for the detailed information on that specific school district.  This pulls back information such as number of students, student teacher ratios, enrollment by grade, expenditures, and more.  Once retrieved, this content might then be presented in another tab within the listing details page or however your design dictates.  So users don’t have to go searching for this information on their own, nor do you have to link off to another site to provide it.   It keeps the user engaged on your site and  provides the added benefit of improving SEO by adding locally relevant content into your pages.

Nearby Amenities
Another common way people search is by nearby amenities such as golf courses, parks or playgrounds, cafes and a wide variety of other “points of interest.”  We have loads of this data that we’re integrating into the search and have started with over a dozen key categories including: schools, parks and playgrounds, golf courses, grocery stores, cafes, public swimming pools, hospitals, airports, libraries, bookstores, veterinarians, pharmacies, health clubs, and universities.   Depending on the individual’s lifestyle and what stage of life they’re in, one or more of these may be crucial in their home search.

Using these criteria a search may be conducted to determine the listing located within a certain distance of a desired amenity.  Likewise, they may wish to ensure that they are NOT near one of these as well.  For example, someone may want to be near a golf course but NOT near a school.  Or they may wish to be near a school, park or playground and library, but further away from an airport.  There are numerous ways these criteria may be used to enhance the search experience and drive the relevance of the results.

Just like with the school district content, the details of each nearby amenity may also be retrieved for display.   So if there’s a golf course, nearby, the listing web service will return the name, address and other pertinent details.  The same holds true for any of the amenities.  This way, a list of nearby amenities may be displayed on the listing details page or in its own tab to help give a solid impression of the area and all it has to offer.

Other Search Criteria
We’re in the process of fleshing out a host of additional criteria for use in the search.  These decisions are being driven by ongoing research with both sides of the equation—home buyers and searchers as well as real estate brokers and agents.  We’re gaining great insight into how people search, what information they feel they need, where they tend to find this information today and what role the broker or agent plays in this laborious process.  As more of this information is collected, I’m looking forward to sharing the results to help drive more thoughtful design and better user experiences.

One criteria that’ made to the top of the list (I mentioned it in my last post) is the ability to search based on a desired “commute time or distance.”  This is well underway and we’re very close to getting out a first cut.  With this new capability, a user will be able to input their work location and either a desired commute time or a maximum commute distance.  The system will then calculate the potential areas and will retrieve the listings that are within those areas.  As we all know, there can be a significant difference between the straight line distances most searches use and the actual road distance.  Case in point, New Jersey is just across the Hudson River from New York and if you could kayak across, you’d be golden.  But for those of us not in the kayaking mood, we have to cross a pesky bridge.  So our commute time calculations will take this sort of situation into account.  Of course this will have maximum value when we can incorporate transit which we’re diligently working towards.

Other criteria on the docket right now are:

• Area demographics (i.e., average age, household income, family type, etc.)
• Cost of Living (i.e., total cost of living, cost of living per category, COL vs. the national average and vs. the general area, etc.)
• Safety (i.e., area crime, health, air quality, weather, natural disaster and other factors that impact safety and security) Note to self…see if Earth, Wind & Fire is available for launch party.
• Fun (i.e., bars, clubs, museums, arts and entertainment, and other places and events that give an area a “fun factor”)
• Employment Statistics (i.e., white collar vs. blue collar, does the area have more professionals or laborers, etc.)
• Educational Achievement (i.e., does the area have mostly college educated people or high school attainment?)

Again, depending on the lifestyle and stage of life the searcher is in, one or more of these items may be paramount.  As a young family just starting out, I may want to find places with other young families that tend to hold similar professions but also an area where the cost of living is reasonable compared to the national average.  An “empty nest” couple may also be looking for a lower cost of living but wish to be near others in a similar age group and might not care so much about the employment statistics.  So these different criteria may be used by different groups to identify the best fit for their needs.

Smoothing out the edges
As I mentioned in my last post, what we’re providing right now is purely an  that can be accessed via SOAP or using RESTful HTTP requests.  So one area we’re about to start diving into is the creation of some SDKs to “smooth out the edges.”  Many of the people I’ve talked to so far develop primarily in C#, are using .Net Framework 2.0 and primarily work in Microsoft VisualStudio .Net. So this is our likely starting point.  I’ve also spoken with quite a few PHP developers who work primarily on a LAMP (Linux, Apache, MySQL, PHP) technology stack.  So this appears to be the next logical environment.  But I’d like to hear more about what environments your working in, tools you use, and the extent to which you’d like to see UI widgets vs. pure .

I realize time is a precious commodity none of us have enough of, so I want to be sure we’re delivering enough to get you well on your way but not so much that we take away the very benefits of a flexible web service.  So what’s “enough” in your mind?

Please keep the comments coming and pipe in with your ideas as well as your critiques!

Feel free to reach out to me at spetronis@onboardinformatics.com until my next post.

Tags: API, geocode search, geocoding, Lifestyle, lifestyle search, listings, LLE, onboardinformatics, Products, property search.

February 20th, 2009

Lifestyle Listings Engine Web Service - New Property Search Version 0.8 Delivered

By Scott Petronis, Senior Director of Product Management

This week we launched the first version of our Lifestyle Listings Engine– version 0.8. The Listings Web Service has been in process for some time and has been in use by a number of early beta testers who have provided a lot of great feedback.  Over the coming weeks and months we’ll continue our work on improving what’s there, adding in additional search capabilities and filling in more details in terms of documentation, samples and so forth.  So there’s still a lot more to come.

What we have readily available through the web service are two primary search mechanisms—geographic and parametric. The web service is accessible using WSDL and conforms to SOAP 1.1 or 1.2.  You may also use REST over HTTP.   I’d like to provide a brief overview of the capabilities to give a sense of what’s possible. Then I’ll give a little insight into what’s next.

Geographic Search 

There are a number of geographic search capabilities built directly into the Listings Web Service so there’s no need to use another service unless you want to.   For example, you may geocode addresses directly through the web service without needing to make a separate call to Microsoft Virtual Earth or other service. For all search requests, there’s the option to bring back just the listings counts (e.g., 62 listings met the search criteria) or the listings themselves (listing summaries in XML). The specific geographic search capabilities in the web service include:

• GeoCode – Allows for address input and return either a <latitude> <longitude> (coordinate) pair or a string to be used in proximity searches.
• GeoCodeSearch – Allows for entry of a latitude/longitude pair and distance, and returns the records that meet the criteria. This can be used in concert with the GeoCode call or by passing lat/long values obtained from other services.
• GeoPointSearch – Allows for the entry of an already geocoded point and distance (radius) and returns the records that meet the criteria.
• AddressSearch – Allows for input of an Address and Search Distance and returns the records that meet the criteria.
• Poly and PolyPointSearch – Allows for entry of a set of geographic points (polygon) as either an array or from a file and returns the records that fall within the corresponding polygon (area). This is particularly useful when the UX includes a map interface where the user may select a custom, highly-refined geographic area to search within.
• CitySearch – Allows for the input of City/State and returns the records that meet the criteria.
• ZipSearch – Allows for entry of specific ZIP Code and returns the records that meet the criteria.
• HoodIdSearch – Allows for entry of an Onboard Neighborhood ID and returns the records that meet the criteria.

Geographic Lookup

In addition to geographic search functionality, we provide a robust and pre-defined geographic model upon which all other relationships are built. The web service exposes this in a way that lets you interact with various levels of geography for both searching and presentation to the user.  For example, you might want to present a series of selection lists, each of which is predicated on the one before it such as: select the state you which to search in, then select the county(ies), then select the neighborhood(s). The web service provides the following geographic “lookup” capabilities to enable this:

• LookupStates – Returns a list of all State covered based on the Account ID.
• LookupCountyByState – Allows for entry of a specific State and returns all Counties that fall within the specified State.
• LookupCityByState – Allows for entry of a specific State and returns all Cities/Places that fall within the specified State.
• LookupZipsByState – Allows for entry of a specific State and returns all ZIP Codes that fall within the specified State.
• LookupCityByCounty – Allows for entry of a specific State/County and returns all Cities/Places that fall within the specified County.
• LookupHoodMarket – Allows for entry of a specific Market and returns all Neighborhoods that fall within the specified Market.
• LookupHoodState – Allows for entry of a specific State and returns all Neighborhoods that fall within the specified State.
• LookupHoodAll – Enables retrieval of a list of all Neighborhoods that are available based on the Account ID.

Listings Lookup and Detail

The last area I’m going to cover is some of the capabilities specific to the feeds and the listings themselves. Again, some of these calls may be used on their own or in concert with the other calls depending on the UX you’re going for. Some of these calls are purely for “utility” purposes such as just understanding what content you have access to.  Most are pretty self-explanatory and very straight-forward.

• GetListingDetail – Allows for input of a specific Property ID in order to retrieve the detailed attributes of that specific listing. In the calls above, you’ve gotten back the listings that meet the search parameters. Now with this you pull back all the details on the individual listing.
• GetListingsFeedSearchByMlsIds – Allows for MLS ID input and returns the specific MLS property record.
  
• GetListingsFeedSearch – Allows for input of a Feed ID and returns all listings within that feed.
• LookupAgentsByFeed – Allows for entry of a specific Feed ID and returns all Agents associated to the specified Feed.
• LookupAllFeeds – Enables retrieval of a list of all Feeds that are available based on the Account ID submitted.
• LookupCurrentCitiesByFeed – Allows for entry of a specific Feed ID and returns all Cities covered by the specified Feed. This can be used, for example, to display a coverage list.
• LookupCurrentZipsByFeed – Allows for entry of a specific Feed ID and returns all ZIP Codes covered by the specified Feed.
• LookupPropertyTypes – Returns a list of all property types associated to the property (listings) records.
• LookupRecordRules – Returns a list of all display rules associated to the Account ID. Specific rules may apply based on licensing terms or other legal restrictions.
• LookupSearchableFeatures – Returns a list of all searchable features associated to the property (listings) records.
  

Of course, in addition to all the functionality described above, the standard parametric search capabilities you’d expect are also included.  These search parameters may be set to filter results in any of the other searches:

• PropertyType
• MinPrice
• MaxPrice
• MinSize
• MaxSize
• Bedrooms
• Bathrooms
• MinYearBuilt
• MaxYearBuilt
• SearchDistance
• FeatureProfile
• DOM (Days On Market)
• FeedID
• AgentID
• OfficeID
• AgentName
• OfficeName
• RecordLimit (Max number of records to return)
• Sort (specific value to sort by)

There’s one additional capability worth special note.   A “SpecialFormat” flag allows you to set a priority to be placed on Agent or Office criteria to move any listings for the specified agent or office to the top of the list. It requires that either an Agentname or Officename filter be submitted and then takes precedent over the Sort value and order. Any values in the Sort parameter would be acted on next.

What’s Next?

As I mentioned at the top, this is just the beginning. We’re diligently working on enhancements around the clock. Major items in the works include: search based on school performance (e.g., show me only listings with 4+ bedrooms, 2.5+ baths for between $300,000 and $350,000 in areas that have great schools); search based on commute time (show me only listings that are within a 30 minute drive to work); and, search based on distance to one or more amenities (I want to see places that are within 5 miles of a golf course).

Beyond this, I’m looking for feedback on:

• Web service usability – we have a fleshed out foundation here, but what would make it more useable to fit within your design patterns? I’d love to get some additional Beta testers.
• Development environments – what development environments are you working with? .Net, PHP, Java/JSP, Adobe ColdFusion, Adobe Flex?
• Helpers and samples – beyond the API, what would help to reduce your development time and speed deployment? Sample PHP code? JavaScript helpers? AJAX widgets?
• Output formats – beyond XML, what would make your life easier? JSON output?
• Search functionality – we have loads of additional lifestyle characteristics we can make available but the key is prioritizing the most important ones first. Your feedback is always welcome to help shape those priorities!

Until next time…

-sap

Tags: API, geocode search, geocoding, Lifestyle, lifestyle search, listings, LLE, onboardinformatics, Products, property search.