Thesis

Introduction

In consultation with my thesis advisor, Matt Carrano, we decided to study one aspect of displaying community information: the intersection of time and space. My original thesis had included displaying time and space as a minor aspect of a larger digital community event map. Matt and I decided to make it my central topic of research because it was smaller in scope, singular in focus, and a less studied issue than digital communitites as a whole.

The Problem

We decided to study how to display location-based data (markers on a map) in the same interface with their relative time data. In other words, how can we show that one action presented by a marker occured before, after, or roughly at the same time as another action? If we could do this, how could we show the time relationships between multiple markers? And, if we could, would it be interesting or meaningful data for users? We were also interested in what kinds of data users would want to see to displayed by their location in time and space.

We chose this interface problem because it was narrow enough in scope that I could adequately study it in the time allotted; it posed a single problem that could be studied and discussed as such; and because it had not been studied much before. Google searchs for display time and space in user interface and mapping time and space in user interface revealed two different tools for looking at temporal and location data in the same interface. The Tempest tool, created by Robert Edsall and Donna Peuquet at Penn State University, uses a three-pronged model to display space, time and object data. This three-dimensional approach shows data via three widgets on the screen at once, one for each dimension. In the same fashion, the Controversy Space Explorer, a collaborative project among several European universities, maps the dimensions of controversies. It also uses the same approach as Tempest of separating each dimension into a different graphical tool and showing all three tools on the same screen.

Proposed Solution (Hypothesis)

Unlike the one widget for one dimension approach others had taken, I am interested in displaying mulitiple dimensions in one display. I am interested in this technique for several reasons:

  1. It allows the designer to display more data for a given screen size
  2. Each dimension is anchored, and therefore understood, in relation to the other dimensions
  3. It allows users to find relationships between the dimensions
  4. Users need not move their eyes back and forth between the various dimension displays to try and grasp all the data

However, there are many problems with this approach:

  1. Showing mulitple dimensions in one display multiplies the density of the data, increasing the user's cognitive load
  2. There are no conventions for showing time on a map, so color or iconography must include explanations and labels
  3. The time scale must be overlayed on the map at the granularity (minutes, hours, months, years) that makes sense for the particular data you are plotting
  4. Time and place and descriptive data must all be visible without covering up related elements so that trends can be seen

Some of these considerations I understood before I built the prototype, but I learned most of them by having people test my prototype.

Matt and I together came up with the ideas for a prototype map with time interface. It contains the following elements:

  • A Slider for moving through time: I felt strongly that a slider, where sliding right goes forward in time and sliding left goes backwards in time, would be intuitive for the users.
  • Color to signify the time element of each marker: We chose color to convey the relative time, with darker colors being more recent and lighter being older. We choose years for the granularity, basically so we could aggregate or bucket the colors in a way that would show the time element.
  • A layer metaphor: Because we want to give the users a sense of layering, the markers are both lighter and smaller the older they are, so that they appear to recede into the background.
  • A swipe animation: We added a swipe animation to help reinforce the layer metaphor.
  • A faceted search to show different types of data on the same map.

Using this design, I hoped to be able to learn the following:

  1. Could one show time and space on the same display?
  2. Would people want to see community data displayed by time and space?

Building the Interface

I chose Drupal 7 as the framework within which I would build my prototype space and time interface because:

  1. I have used Drupal and I thought it would work for this project.
  2. I like using Drupal for projects because I want to learn it better.
  3. Because Drupal is a Content Management System, it had the concepts of users, authorizations, content workflow, aggregating content into complex reports, etc.
  4. I knew it had mapping tools.

I used the following tools to build the interface:

  1. Drupal 7, for the above reasons
  2. The OpenLayers mapping API
  3. The Google maps API
  4. The Geofield Drupal Module
  5. The OpenLayers Drupal Module
  6. The book, Mapping with Drupal by Alan Palazzolo and Thomas Turnbull
  7. Adobe Photoshop to create the custom markers

After reading Mapping with Drupal, I chose to use the Geofield module approach to Drupal mapping, versus the simpler and older Location module approach because Geofield supports areas and layers as well as points. I stuck with this decision even though it created a few extra coding requirements later on in the project.

Originally I started mapping withe OpenLayers API, which is a very extensive open source JavaScript library for mapping. I started out by bulding the map totally within the OpenLayers Views interface. By doing so I was able to learn how to create Drupal content with Geofield address fields and plot those on a map. Once I had the map working I realized that I could not customize OpenLayers Views to the extent I needed to create the interface described in the Proposed Solution section above.

My second step was to get Drupal View data into JavaScript so that I could create and manipulate an OpenLayer's map myseful. By creating a custom Drupal page template, I was able to pipe the standard Drupal "$view->results" array into a JavaScript array of map points, like this (There is a better, more standard way to move Drupal data into JavaScript. To make the application production ready this code should be refactored to use the standard method.):

<?php
foreach ($view->result as $point) {
    if ( isset($point->field_field_historical_date[0]['raw']['db']['value']) ) {
        $date = $point->field_field_historical_date[0]['raw']['db']['value']->format("m/d/Y");
    } else {
        $date = "No Date Set";
    }
    if(isset($point->field_body[0]['raw']['safe_value'])) {
        $body = $point->field_body[0]['raw']['safe_value'];
    } else {
        $body = "No description given.";
    }
    if (!isset($point->field_field_historical_geo[0]['raw']['wkt'])) {
        print "error.push(".$point->nid.")";
    }
    print 'var foo={title:'.json_encode($point->node_title).',wkt:'.json_encode($point->field_field_historical_geo[0]['raw']['wkt']).',body:'.json_encode($body).',date:'.json_encode($date).'};';
    print "wwwRozzie.mapPoints.push(foo);";
}
?>

Once I had all the information in JavaScript, I created an OpenLayers Map and plotted the points onto it. This took a while to learn how to do in OpenLayers, because the API is very extensive. OpenLayers has the concept of an array of markers attached to a layer and each marker can be shown and hidden, so it should have been relatively easy to show markers every time the user moved the slider. It was not. I spent some time trying to work with it and then I quit.

I rebuilt the map using the Google Maps API, which was not difficult. It did require me to create a separate array of markers and iterate through them each time the user moved the slider. Based on whether the date of the marker fell between a given set of dates, the marker would be given a different-colored icon. Like this:

function addPoints() {
    for (i=0;i < wwwRozzie.mapPoints.length; i++) {//
        var point = convertWKTtoGoogle(wwwRozzie.mapPoints[i].wkt);
        var id = new Date(wwwRozzie.mapPoints[i].date).valueOf();
        var idDate = new Date(wwwRozzie.mapPoints[i].date);
        var marker;
        var position = wwwRozzie.markers.length;
        var markIndex = jQuery("ul.bef-tree input[type='checkbox']:checked").val();
        var type = wwwRozzie.iconsType[markIndex];
        //make a 5 layer histogram of the markers
        if  (wwwRozzie.buckets[1] > idDate && idDate > wwwRozzie.buckets[0]) {
            marker = createMarker(0,i,point,id,idDate,type);
            wwwRozzie.markers.push(marker);
            addInfoWin(marker);
        } else if (wwwRozzie.buckets[2] > idDate && idDate > wwwRozzie.buckets[1]) {
            marker = createMarker(1,i,point,id,idDate,type);
            wwwRozzie.markers.splice(position,0,marker);
            addInfoWin(marker);
        } else if (wwwRozzie.buckets[3] > idDate && idDate > wwwRozzie.buckets[2] ) {
            marker = createMarker(2,i,point,id,idDate,type);
            wwwRozzie.markers.splice(position,0,marker);
            addInfoWin(marker);
        } else if (wwwRozzie.buckets[4] > idDate  && idDate > wwwRozzie.buckets[3]) {
            marker = createMarker(3,i,point,id,idDate,type);
            wwwRozzie.markers.splice(position,0,marker);
            addInfoWin(marker);
        } else if (wwwRozzie.buckets[5] > idDate  && idDate > wwwRozzie.buckets[4]) {
            marker = createMarker(4,i,point,id,idDate,type);
            wwwRozzie.markers.splice(position,0,marker);
            addInfoWin(marker);
        }
    }
    wwwRozzie.borderRect = addDiv();
}

Then it came time to create the layer swiping animation. I started by trying to animate a drawing lawer right on the map. I was not able to do this successfully. The animations were very slow and choppy. Instead, I tried copying the div that the map sat in, giving it a background color when the user moved the slider, and then animating the div's movement. This sort of worked, however its z-index either ended up behind the map, making it invisible, or in front of the map, making the map invisible. This is another issue that would need more work to turn from prototype to production quality.

Finding Data

I am interested in my own community, the neighborhood of Roslindale in the South West of Boston. I chose this area to map because I knew it and because doing the research would be interesting to me. As for the when, the easiest data to find and the most richly detailed, was recent data. In order to make a testable prototype, Matt and I agreed that I needed to show examples of the kinds of data that would be interesting to explore via time and space.

We had to balance this desire against the availability of data. By scraping several excellent online news sources, Universal Hub, the Roslindale Transcript, and the Boston Globe, I was able to find the past five years of murder and shooting information about Roslindale and hand-enter them. From the City of Boston's web site, I was able to find Certificates of Occupancy in Roslindale for the past four years. I wanted to show only new buildings, but was not able to figure out how to separate new buildings from renovations. I had to spend four to six hours cleaning and preparing the data to make it ready for importing. The Boston Police Department's Bureau of Public Information quickly gave me car accident data for Roslindale for the past four years. However, several of the columns I did not understand and the address information was missing. I did not plan ahead enough to get the information corrected. Since I did not have car accident data with location information, I was not able to plot it in time to use it in the prototype. If had the data, I would have listed it with another icon. The point was to find data to prototype that the testers would reasonate with.

Testing the Interface

Once I had input the data into the prototype interface, I needed to test it with real users. I wrote an initial usability script and tested three users with it. Their results were pretty conclusive, in that they all had very similar problems and suggestions about the interface:

  1. Make the symbols different for each type of data.
  2. Add the symbols as a key or label to each type of data.
  3. Change the title of the page to be more clear.

I made these three changes to the interface and retested it with four more people. I also removed the System Usability Scale questions and spent more time talking with the testers about how to display time on a map and what kind of data would be interesting to display time and space.

From the seven testers, I learned that the time and space interface could be further improved to make it more usable and more understandable. Here are the specific fixes they suggested:

  1. Add a second slider or other interface tool to allow users to limit the time period to specific year (several users suggested a second slider, one user suggested a clickable year label).
  2. Add non-labeled monthly or quarterly "stops" in the slider to show people more specific date information.
  3. Show summary data for each visible set each time the user moved the slider (at least show the number of markers in the set) to allow users to compare sets and spot trends
  4. Fix the popup handling. Currently each popup stays open until another one is chosen or the user clicks the close button, but most users wanted the popups to close on mouse out or via a double click.
  5. Add the ability to plot more than one type of data on the map at a time. Most of the data does not correlate, but the only way to find correlations is to plot them.
  6. Some of the users had problems seeing the slider until I pointed it out. Matt suggested that making the slider handle a more vibrant color or graphic might make it stand out more.

I also wonder if I could improve the usability of the time element by making the slider vertical. Then by moving the slider up a user travels up through the "layers" of time to more recent events and moving the slider down takes the user into the past.

Further Areas of Study

In addition to the fixes above, the testers came up with ideas for what kind of data might be useful to show via time and space, and also other ways to show time and space besides the one I prototyped and are worthy of further study. Data that might be interesting to see in the current interface:

  1. Which roads were not plowed during snowstorms. By viewing these by location and time, it would be easy to see if the same roads or different roads are missed during each storm.
  2. More crime data, such as break-ins and thefts, to determine if there are location patterns.
  3. Car accidents by location and time were interesting to people. They thought they could spot some trend information through this interface.
  4. New building and house sales and prices were interesting.
  5. I also thought that if the time scale was compressed to days or hours, this technique might be used to explain movements of people and things in battles or disasters or rescues.

The testers also thought of other ways to display location and time data. Most of these ideas were variations of the Tempest and the Controversy Space Explorer method in that they combined two different displays, the map plus some sort of chart or graph, to visualize the time element. One of these that I mentioned was a census map I had seen where the demographic data within a map location is plotted like a pie chart.  Each area on the map is colored proportionally to the census data in that area. Then by moving the slider, each area changes its proportion over time so users can see how a block, area or neighborhood changed its demographics over time.

Another idea one user suggested was to be able to choose a type of data to plot on the map, click on the map, and have a chart pop up showing the user-chosen data charted over time. It would look something like this:

View of map with popup charts at different locations.

Conclusions

My testers agreed on many things. Some things that stood out are:

  1. All of my testers instantly understood the map.
  2. All of my testers were very interested in the crime data I had collected, especially as it relates to where they lived.
  3. All of my testers were interested in trends, especially in crime.

From these findings I conclude that time is very important as it helps explain what is going on now. People want to know if things are getting better or worse around them. An interface that can tell them that will be very useful.

I also conclude that a map is a great way to tell compelling stories with information. People want to know what is around them and they think that maps can tell them that.

I think that the interface paradigm I came up, where time and space are plotted together, is not very useful in most cases because it does not tell people whether things are getting better or worse. As one of my testers said, "Time is not best represented on a map, in my head. Real data is best shown on a map, but time is not really a factor."

As I said in the proposed solution stage, I was hoping to learn the following:

  1. Could one show time and space on the same display?
  2. Would people want to see community data displayed by time and space?

Based on the information my testers provided, the answers to my questions are:

  1. Yes, and with some improvements, my version would work for this use.
  2. Yes, but in most cases not the way I had displayed it. Instead, people would want to see location data on a map and time-based trend data in some other way.

People were interested in seeing trend data in context of the location where they occurred. I think more development and testing is needed to devise the optimum method for displaying this information. I want to thank my testers and Matt for helping me take this exploration through time and space interfaces.