From Visualization Sp06
Part I: Architecture
Above is a block-diagram of the basic setup of the apartment finder. The data (in this case, apartment listings) is stored in some ready format. Some subset of the listings are displayed on a map. When an apartment on the map is selected, detailed information about it is revealed, probably close to it on the map.
A filter on the data determines which of the apartments are shown. In its simplest form, the filter is controlled by two pieces of data: the minimum number of bedrooms and maximum rent. These data are input on the display using controls (probably sliders).
Part II: Toolkit
I chose a web-based approach for several reasons. First, I always appreciate cross-platform software since I have used minority operating systems for many years, and web applications lend themselves well to platform independence. Second, I thought it would make it easier to show to people for comments without having them download and compile any source code. Finally, I've been wanting to know what the big deal is with all these buzzwords like "AJAX" and "Web 2.0," so I thought I'd just go ahead and teach myself how it all works (spoiler: AJAX and Web 2.0 are just an assemblage of years-old technologies that are finally being used competently).
HTML is a venerable markup language used as the standard content delivery mechanism for the world wide web. I decided to use static HTML instead of a dynamic markup language such as PHP so that people could copy my program entirely from their browser and make modifications without needing a database backend.
XML is description of a standard way to organize data in a hierarchy, sort of the ultimate flat-text file data format. I chose to use it for my data storage since it is so easily accessible using standard web technologies.
Google Maps API
Since this project is all about looking at apartments on a map, I decided I would use the Google Maps API for display of geographic information. That way, I get panning and zooming for free, as well as accurate geographic placement. The Google Maps API is still very limited, so I anticipate having to hack it up quite a bit to get something useable.
Annotated Block Diagram
Part III: Implementation
Above is a screenshot from the finished program. The two main user interface elements are the sliders at the bottom that filter the displayed apartments by the minimum number of bedrooms and the maximum monthly rent. Since the application is implemented with the Google Maps API, the user can interact with the map by dragging it and zooming in and out, or changing to a satellite view. A link at the top switches between viewing East Bay and San Francisco apartments.
The legend at the lower left explains the markers. The number indicates the number of bedrooms in the apartment, and the color indicates whether the apartment is above or below the average rent for that number of bedrooms.
When the user clicks on a marker, details of the apartment are shown along with a link to the craigslist ad (these links are all of course dead now, but you get the idea).
Link and Source Code
The application can be accessed live at http://overt.org/maps/a3.html. This webpage works in Firefox on Windows, Linux, and Mac OS X, but not in Internet Explorer (it's a bit antiquated). A tarball of the source code is available here. If you download it and try to open it it won't work, since Google requires a key specific to each website that accesses Google Maps. If you want, get one here and change line 43 of a3.html to include your key.
Overall, I was happy with the way the apartment finder turned out. The Google Maps API is an example of a toolkit with a very low threshold but also a very low ceiling. I was able to get the basics of the application working in a couple of hours, including time spent learning the API. Google prodives excellent example source code that compliments good documentation.
I thought of adding proximity circles as in the original apartment finder, but was affected by my choice of Google Maps and a desire of simplicity that led me to avoid them (though if you're interested a library implementing them in GMaps is available here).
In general, I think this was a fine API for the task, especially considering the fact that the data displayed was scraped from a website and would be constantly changing. I certainly suffered from having such a low ceiling, and it greatly affected my design choices, but never threw me totally off track. I was willing to give up a lot to get the app on the web, since I think the major barrier to software distribution in general is the need to download or install it. I can't remember ever working in a toolkit that didn't profoundly affect my software design; in this case, the task and the API matched well, so not much of my original intent was lost.