Relocation is a bear. My lastest mashup desire comes in the way of a simple consumer interest to buy a nice house in a good school district. So, the mashup becomes “Available real estate” + “Good schools.”
What do these two images below have in common?
Yep, Google Maps. Now, I’m no programmer and API means “Associated Press International” to me, so the likelihood of me figuring out how to get at the data and display it easily approaches zero. Nonetheless, it can be done, yes?
My simple mashup fantasy is similar to what Dion Hinchcliffe is writing about lately. Clearly, I am living proof of his call for ease of use as a “key issue for successful mashup creation tools.”
Ease of use: Being usable by virtually anyone with any skill level using any browser in any language without any training will be essential for mashup tools to succeed with the general public.
So what’s a simple-minded home-buyer to do? Call a local realtor?
Maybe, but not yet. I emailed contacts at IBM (QEDwiki) and Teqlo over the weekend and asked if they could figure it out. The good news is they both said yes, but not just yet. It occurred to me what a tremendous market opportunity these mashups would be for the data sources of this information. Take GreatSchools.net, for instance, a site I refer to often. There is an enormous amount of public and user-generated information on that site for anyone interested in researching schools and school districts. This simple mashup would drive a tremendous amount of traffic to their site. You can see how the network effects from this simple application would create value for the site’s users; thereby increasing its value in the market.
In addition to the market expansion benefits for the content sources, the benefits to users are limitless. It’s a simple matter of knowing what you want.
It’s like Dion is saying here:
But what is clear is the vision, ingenuity, and widespread interest and potential benefit that really good DIY Web tools could bring to literally hundreds of millions of users around the world.
7 thoughts on “Mashup Fantasies con’t.”
I was wondering if this mashup is still available somewhere? I was looking for exactly the same tool and was very excited to find this post but unfortunately didn’t see any links to the actual mashup.
Hello, I just bought a house in Austin (near downtown) and used a guy by the name of Charles Owens with Turnquist Partners. ([email protected]). I highly recommend him especially if you want to live fairly close to downtown – which you should :).
Checkout Public Schools Review. It is a good statistics source as well as a map of area schools all driven by a basic zipcode search.
The issue with GreatSchools and the National Center for Educational Statistics is that these sites build content that is state specific. While this is good for the information seeker (Jane Relocator), it is not helpful for content generators such as Dapper and Kapow.
For example, in order for us to build a data service for school ratings for the GreatSchools website, we must be able to provide the content generator a few sample states and zipcodes so that the tool can analyze patterns in the resulting query pages as well as the REST URLs required for these queries. When attempting this exercise with Dapper we find that the tool is unable to draw conclusive pattern decisions. This is not a technical issue with Dapper, yet instead it demonstrates a basic limitation in reverse engineering a data model from presentation markup. If you compare schools in CA, NY, TX and NC these states offer a variety of statistical facts. The problem is that column 3 (for example in TX) in the Overview tab is not the same as column 3 for CA and NY.
While these are just examples, we can begin to draw some general observations.
1. It may be helpful to begin to classify mashups across a spectrum of time (ranging from situational to purpose specific).
2. While Trulia, Zillow, Public Schools Review and others are mashup applications, they took a fair to great deal of coding to develop them. Whereas, the situational needs of Jane Relocator require a mashup that is timely and less formal. In fairness to our situational scenario, we could conclude that the seeker only needs a tool like Dapper to create a Service for the state of Texas which would work just fine. Which implies that the mashup enabler must decide which end of the development-time spectrum they are enabling.
3. While Content Generators like Dapper and Kapow will improve the availability of timely information, there are limits.
4. The adoption of Web 2.0 standards like OpenSearch and Atom will dramatically expand the range of situational applications that can be built in a timely manner. Adoption here means that Content Providers such as GreatSearch and Public Schools Review need to consider raw data access as well as their website specific rendering of the content. The catalyst here may be a business model justification, but until the tides change and content providers consider an API just as important as a website, mashup assemblers will spend great amounts of time decoupling data from presentation markup.
5. A possible best practice out of this may be that website developers should consider first their Content API then build their website as the first consumer of that API. Such an approach would ensure every website has a proven content API.
If you are interested in seeing this scenario evolve, checkout a work-in-progress here.
Thank you for the time you put into this. I’m going to give it a try… in the meantime–
Anyone know a realtor in Austin? 🙂
Susan as we have discussed, several obstacles exist. These issues are not due to technology shortcomings, instead more of a statement of the level of maturity of the websites that populate the Internet. Allow me to elaborate using your relocation example.
Let’s assume the scenario you desire requires the following components:
1. Search Form: User enters a zipcode
2. Local Schools: Application presents school details for this location
3. Homes for Sale: Application presents MLS listings for the location
Data harvesting is a key starting point for such a mashup. First lets analyze the MLS systems. If we look at Zillow and Trulia, two leading Web 2.0 Real Estate firms which tend to make their data available for access by local broker websites. From a business model perspective this is an extension of the advertising model. As content providers, these companies need to consider the network effect you mention and how they can leverage the long tail to get their content and brand on applications they may not have considered. In the spirit of this exercise I have made such a suggestion to Trulia to consider mashup makers like QEDWiki as a content channel.
In an attempt to focus on the core data, MLS listings, I then spent time exploring ways on how I could aggregate the data I desired. This is where tools like Dapper Dapps, Yahoo Pipes and Kapow Robots become very handy. I was able to identify a pattern in the construction of Trulia URLs so I created myself a Yahoo Pipe for the Trulia Real Estate Search. The result of this pipe meant that I could now render in my mashup an RSS feed for MLS data by zipcode.
As you requested I then focused on the GreatSchools website. I also considered content from the National Center for Educational Statistics . As you stated the GreatSchools website has a wealth of information. While they have not yet embraced Web 2.0 enablers like RSS and Atom, tools like Kapow and Dapper can be used here to extract data. I am actually toying with a Dapp to generate an RSS feed based on a zipcode query for GreatSchools.
A perfect example of a data relationship issue is demonstrated by the form used by the National Center for Educational Statistics to query Public School Districts. In this form, required search elements are contained in a drop down (such as State name). Unfortunately, the state selected is then correlated to a numberic identifier which is then used in the REST calls used to obtain the search results. This behavior makes the harvesting of these REST URLs for mashups very difficult.
While mashups via content syndication (data aggregation) are nice, a visual rendering of the content with added behaviors like bubbles and map navigation is of greater desire as you have eluded too. This is why the ability to access HTML snippets as the result of a REST call would be very elegant for mashup enablers.
As I investigated your scenario, I really wanted to use as a widget in my mashup but I am not allowed access to it as I am not a broker. So in the spirit of situational applications, I created a just-in-time solution that solved my needs (as a compromise) until I can improve the richness of my content dependencies.
I have included below the code for a basic mashup that uses two Yahoo Pipes to address the basic concepts of your mashup scenario. While it lacks visual pizazz, it does demonstrate the speed at which content can be mashed.
To use the code, create yourself a QEDWiki account and then import the HomeSchoolSearch workspace.
Comments are closed.