A3-BryanKlingner
From Visualization Sp06
Contents |
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 considered all of the visualization-specific toolkits suggested on the assignment page. I was very tempted by the full-featured kits like prefuse, but I ultimately decided to use pure HTML and Javascript, backed by the Google Maps API and using XML for data storage. The decision to avoid a specific toolkit was mostly motivated by bad experiences I've had in the past with abandoned or poorly updated toolkits. If you use a toolkit on top of Java/python/whatever, Java/python/whatever will keep moving because there is a critical mass of people using it. Toolkits have to be updated along with thier parent language, and often aren't because the developer loses interest or the toolkit falls out of popularity.
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
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.
Javascript
Javascript is the de-facto standard way of getting brains into the static world of HTML. Microsoft also offers ActiveX, but the whole point of the web-based program was cross-platform compatibility. Javascript provides easy parsing of XML data and the ability to create interactive GUI widgets like sliders that I'll need.
XML
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
Here is a new version of the block diagram, with implementation specific types and classes in red. The core GMap class from Google Maps supplies the map and handles mouse interaction with the markers that denote apartments. The InfoWindow class of the Google Maps API supplies detailed information on apartments when clicked. The rest of the UI is done in hand-written HTML, CSS, and Javascript. The apartment data is accessed as an XML file. I converted the tab-delimited data files supplied into XML with a python script.
Part III: Implementation
Application Overview
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.
Commentary
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.
However, I hit the "ceiling" of the toolkit almost immediately. Google provides only one kind of marker for the map, and I wanted to provide more information in the markers themselves than just location. Also, the API was not intended to handle hundreds of markers on a map, so I had to hack the API a bit using resources like this reverse-engineered API to access more features. It's impossible not to provide Javascript source code, but I was miffed to learn that Google does do a lot to obfuscate the non-published parts of the API.
Outside of the map, the toolkit provided no tools for UI elements or the like, so I was on my own finding Javascript sliders (I ultimately found a nice implementation here). In fact, the implementation of the sliders, the creation of the custom markers, and the management of the markers (getting them on and off the screen quickly) took about 80% of my development time.
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.
