Let’s begin with a tour of the functionality. When you start the app, it loads some resources while displaying the title screen, and then you have the chance to view an introduction or skip ahead to the map screen.

Because the project centers around the White River near Indianapolis, we only assembled hydrological data for the area around Marion County for the application (I’ll go into more detail later). On the map screen, a prompt appears to inform you that tapping on the map will simulate a rain event. When the map is tapped, the app displays the series of streams, storm drains, and/or sanitary lines that would carry a raindrop from that location to the White River. It also displays the area (known as a drainage basin or watershed) from which other raindrops would follow the same path. Another prompt then appears to let you know that tapping on the raincloud icon allows for selection of storm intensity. As little as a quarter inch of rain can cause sewers to overflow into streams in this area, so when this option is selected, the path displayed will change to reflect this so you can see where you don’t want to go fishing. You can also toggle the display of the 100-year floodplain, which shows you where you can keep your feet dry during a big flood event. In addition to selecting a location on the map, pressing the compass icon locates your device via GPS, and typing in the address bar uses the Google Maps address look-up feature. Tapping on a question mark icon provides some information about pollutants that threaten the path upstream, as reported by the Indiana Department of Environmental Management.

Pressing the “i” icon at the top opens the informational menu. From here, you can learn more about the app, check current weather alerts and conditions, find out how weather differs from climate, get some tips on how to improve water quality, and visit the project website.

Now we can get into some behind the scenes stuff. We wanted to try to reach a broad audience with Raindrop, so we decided to put the time that we had into developing a cross-platform mobile application. These are known as web apps, in contrast to native apps. If we only had an iPhone native app in the App Store, people using Android phones wouldn’t be able to use it, and vice-versa. To handle cross-platform compatibility, we decided to build Raindrop using a framework called jqMobile, which was in a very early stage when we started. It hasn’t quite had an official release yet (it’s in its third beta release at the moment), but has become increasingly robust with each version.

As for the map, you might wonder how we figured out the path that raindrops take to get to the river. Our collaborator at Williams Creek combined information based on digital elevation models, which can be used to derive the boundaries of natural watersheds, with data from the city that indicates where all of the storm drains and sanitary systems are and which areas drain into them.

We then wrote Python scripts to read the scientific data and generate KML geometry files and look-up tables. The application uses a spatial grid look-up to figure out which basin is tapped (so it’s not perfectly accurate, but not too slow either), and then loads the appropriate file with the graphics to display for the path and the basin. It also reads information from another table that has all the details about pollutants.

Along the way, we’ve combined this technology with graphical elements and design guidance provided by Mary’s team, and scientific guidance and content from Butler. The multi-disciplinary process has really embodied the nature of Mary’s City as A Living Laboratory concept. And just as the aim is to lead curious folks from Mary’s eye-catching mirrors and markers along the river to the website and the web app to learn more, hopefully those who discover the project online will follow the raindrop and find their way down to experience the river as well.

The iTunes visualizer

I’m pretty sure that how one visualizes a song varies from person to person and song to song. My best evidence for this comes from my experience as part of Sounds and Visions, a computer music and graphics concert put on by the UIUC chapter of the Association for Computing Machinery (ACM). Unfortunately, the web was young back then and we didn’t put much material online. But you can think of it as a zanily creative iTunes visualizer. My contribution was a dancing solar system with a sun that pulsed to the beat and planets excited by notes of various frequencies. Others showcased flocks of birds, a carpet of tiles bouncing little cubes into the air, only to be eaten by alligator-like creatures, and quivering leaf-like fractals.

I just realized that I have no idea where I’m going with this post… maybe I’ll just end it with a question… what other visual expressions of music have you seen?

First, a quick overview of some technical bits. The user can select a range of dates from the map interface, and a new set of markers is rendered after an AJAX query to the backend PHP code, which requests the data from our database and aggregates it at the zip code and state level. The decision to do this two level aggregation was based on the performance hit that would be taken in trying to render on the order of 7000 icons for a year’s worth of data on a nationwide map. The MarkerManager class (which used to be part of the core Google Maps API) is used to display one set of icons when zoomed inside of what might be called “state level” and another set when zoomed out further. This adds a bit of extra complexity to our colormap choice.

There are a number of ways that this data could have been mapped into visual symbols. The size or shape of the glyphs could be related to the number of admissions, for example. The method that we are using maps the number of admissions to color (when this mapping is stored, it is called a colormap). The particular mapping that we use is important, because some mappings are better than others for certain tasks. For the markers on the map, we use a colormap that smoothly transitions from a blue at the low end to a red at the high end. The particular choice of blue to red leverages our cultural understanding of blue as “cold” and red as “hot” (note that sometimes colormap choice depends on cultural interpretation), a metaphor which works well as a representation of low vs. high admission rates. The combination of these two choices allows us to understand the general trends in the data without needing to refer back to the legend frequently. The drawback is that it is a bit more difficult to compare the value of two individual markers than it would be if we had picked a colormap of more distinct hues such as {red, orange, yellow, green, blue, purple}. We tried to make it easier for the viewer to make comparisons by limiting the number of colors in our legend.

The next important choice is how exactly to map the number of admissions to a particular color. To do this well, an understanding of the distribution of the data is necessary. Intuitively, we would expect that there will be high admissions numbers for the zip codes closest to the museum, and the trend will be toward increasingly lower admissions from more distant zip codes, and likely there will be many zip codes with very low, but non-zero admissions numbers. The best way to look at this objectively is with a histogram. I will take a number of approaches with the data from the year 2008, for which the highest raw admission count for a zip code was 12,375 (during the aggregation, 9 digit zip codes are merged into 5 digit zip codes, resulting in slightly higher numbers in some instances), out of 6806 zip codes.

This first histogram segments the zip codes into buckets in a linear fashion, with each bucket representing 10% of 12,375. As you can see, the vast majority of the zip codes end up in the first bucket. If we used 10 colors with this linear mapping, almost all of the glyphs would be blue. It would be great for identifying and comparing the few zip codes that have very high admission, but a lot of subtlety in the big picture would be lost.

This histogram also uses a linear segmentation, but with an upper limit (or clamp). Any zip code with 10 admissions or more are put into the red bucket. This would be fine for comparing admissions from distant zip codes, but we wouldn’t be able to distinguish visually between admissions from zip codes around Indianapolis.

This is where the beauty of logarithms comes to the rescue. Let’s use our example to walk through the process. First we determine the logarithm of our maximum number, 12375, in base 2 (working in base 2 is very efficient for computers). The result is 13.59. The highest bucket represents 12375 in the real world, and 13.59 in exponent-land. Each bucket represents a tenth of 13.57 in exponent-land, just as in our first histogram each bucket represented a tenth of 12375. We then simply derive the numbers that each bucket represents in the real world; 2 to the 1.359th power equals 3 (when represented as a whole number), for example. These whole numbers in the real world are then used to put the zip codes in the proper bins.

The result is that we have teased out more meaning to bestow upon our colors. There are still thousands of zip codes in those blue buckets, but they are the ones that are scattered across the nation on our map, so here we are aided by spatial distribution. In the red zone, there are dozens of zip codes in each bucket, and this is just what we want to be able to analyze the subtleties around Indianapolis where the icons are more spatially dense. It also turns out that this trend is pretty much independent of the date range, and the colormap still works out well at the state level.

On the actual map we use eight icons rather than ten to reduce clutter in the legend, but the algorithm is the same.

You might notice that we use a different type of colormap in the demographic windows. We actually tried using a smooth colormap for this data for the more linear demographics (Income, Age, etc.). The problem was that it was then very difficult to visually relate a particular shade of blue or green to a particular age or income level, which would almost certainly lead to eye strain and headaches. So here we used a more rainbow-like colormap to make that analysis easier.

In summary, colormap selection is a complex process involving aspects of mathematics, design, and the nature of the dataset. It’s one of those areas where art and science come together and the best practices of each can lead to successful communication of concepts and beautiful representations of data.

You can click on any of the graphs to get a larger view.  The points in the graph are all ArtBabble users.  The lines between the points represent an invite that was sent.  The top point in this graph represents a fake user, “ArtBabble”, that has “invited” all the first tier of users.  The blue lines represent these pseudo-invites.  The red lines represent an invite that was sent and has not yet been accepted.  Finally, the green lines represent an invite that was sent and accepted.  This graph also lets us easily see that the longest invite chain included six people.

This graph shows the same information as before, but is layed out a little different.  Finally, it was interesting to drop the fake ArtBabble user to get another perspective.  It’s fairly easy to pick out who our power-inviters are.

Thanks to all those who have spread the love, and drop us a line if you would like an invite.  Once we can announce a few of the partners, we will retire the invites and allow ArtBabble to go public.