[Read this along with Cameron Blevins’s companion post.] After more than a year of work, Geography of the Post is live. I wanted to take a moment at the project’s launch to reflect back on the design decisions we made with the project and to document these changes.1 The design of the project went through several iterations as we sought to solve two problems: The first, the most efficient way of presenting the material. Since we are dealing with such a large amount of information (our total dataset approaches 100,000 post offices), we ran into problems very early on with the performance of the map. Dragging, panning, and zooming the map became frustratingly slow – a user experience you always hope to avoid. We built in manual zooming features to work around that problem. Second, our bigger question revolved around how to present the information. We wanted to determine what sort of views we could present to users in order to ask interesting research questions. Our early design iterations focused on Oregon. We started by loading our data onto a Google map: We experimented with alternative views, such as hex binning visually understand geographic concentrations of post offices through histograms: These were useful views, but we had considerations that we wanted to take into account with the offices that simply plotting points doesn’t let us get at. It’s interesting, in one sense, to see the concentrations of post offices. But these points don’t represent much else. If we are using the post to understand something about the movement of people into the American West, we needed more interaction with the points in order for us to query the information with more granularity. With the assistance of some amazing undergraduate research assistants – Jocelyn Hickock and Tara Balakrishnan – we created methods for determining the status of a post office at any point in time. Users are presented with two views. The first is what we called “Duration View,” which uses transparency of the points in order to convey the “age” of a post office. These “ages” update according to the span of time that you draw on the timeline, or you can view the map as a whole and see areas of the West that have had the oldest (or youngest) post offices. A second view of the post offices we built into the project is what we’ve called “Status View.” This view shows us one of four statuses that a post office can be in during a given span of time: closed, opened, open throughout, or open and closed. The view gives us a chance to look for large areas of closings or openings in the context of surrounding post offices and raise questions about why those changes are occurring. Why document our design decisions? Part of my own goal in digital humanities generally is the reusability of approaches, methods, tools, code, and design in projects that may be far afield from my own work. But I also believe that we can make our work more methodologically transparent by presenting the artifacts and iterations of our design process. Not only because designs have implied and explicit arguments, but because sharing the process helps others in their design process. Furthermore, exposing our design and thought process has helped us to think more deeply about our own design decisions.2 In other words, I am trying to answer Trevor Owens’ call that we take “a few moments at the end of a project to reflect on what you wanted to accomplish, what actually happened, and what you learned from the process.”3 Our goal at the outset was to determine what we could about the relationship between the U.S. Post and population growth in the American West. By and large, I think the project goes a long way in giving us an overall picture of population growth at specific areas in the West, a more granular view of populations than we can see in choropleth maps because of the West’s county problem. Since counties are so large in the West, a choropleth fails to really give us a sense of where people are at in space. But the choice of using post office points to surmise about the growth of population centers gives us a greater sense of where people are going in the West. To make that process more clear than a static map could convey, we designed a timeline feature that allows users to drag a span of time – from a single year to the entire span of time contained in the dataset – and visualize how these changes occur over the course of the century. You have a specific interest in the West during the Civil War? You can draw the timespan and see those offices between 1860 and 1865. More interested in the late nineteenth century? Select those years. Want to watch year-by-year how post offices grow in the West? Select a year, and drag across the timeline to watch places in the West expand. There are elements of the map that I wish we had designed in from the beginning. I’d like to see this same information on a terrain map rather than a flat map – to see how the landscape might have determined where post offices located. I would love to add layers to the map – railroads, major roads, postal routes. Other quanifiable information might also be overlaid on the map – population figures, salaries of postmasters, perhaps even voting patterns. We may have even built in more conceptual and experimental visualizations that could have allowed us to distort time and space (think cartograms) to speculate on the ways that the post shaped how people thought about space. In these ways, we could add more layers of information that may cause us to ask new kinds of questions. Visualizations are provocations for interpretation. For those who approach the project – researchers, teachers, students, the public – my hope is that the visualization provokes questions and ideas. The sheer scale of the office network is arresting, but interacting with that network provides a chance to view it from different perspectives. The interactions with the research, I hope, give users a chance to ask different kinds of questions that a static map simply couldn’t prompt because it lacks the ability to reshape the information easily. As an interactive scholarly work, Geography of the Post lets users explore the space of the Post and the growth of the American West.
- I have also talked about the project and some of our design decisions on The First Draft Podcast, episode 6. ↑
- The code for this project is available on Github. I also have a desire to make this code cleaner and open to wider use by others. Parts of the code are fairly specific to Cameron’s dataset, but I’d like the map to be able to handle any data dropped into it. ↑
- Trevor Owens, “Please Write it Down: Design and Research in Digital Humanities,” Journal of Digital Humanities 1 (Winter 2011). ↑
I am spending the week at the University of Victoria for this year’s [Digital Humanities Summer Institute]() (DHSI). I was here last year and had the chance to make a lot of new friends – indeed, I think one of the most powerful experiences of attending DHSI is the engagement with the people and the community. The people here are awesome. I’m in the physical computing course with Jentery Sayers, Bill Turkel, and Devon Elliott. We’re getting introduced to a variety of technologies – 3D printing, Arduino boards, Raspberry Pi, Max, and Makey Makey. One of the projects a group of us are working on is reviving a 1983 gaming desk that originally played Missile Command. Missile Command was a 1980 game published by Atari where the game player had to aim three anti-missile batteries at incoming missiles and bombs. (Want to play? It’s online.) The one question that I keep returning to: why build this? Well, if you are an historian of technology, or game culture, or want to understand something about the design decision that went into the production of Missile Command, or you’re thinking about the historical preservation of video games and the devices they were originally played on, then engaging with physical computing makes good sense. After all, the process of of recreating the system may lead to understanding the decisions that went into the circuit design, wiring, and programming of the game itself in ways that reading primary sources may not. It strikes me how often we’ve had to think about certain design decisions for our own technological limitations. For example, the Raspberry Pi only had fifteen pins open that we could interact with, but the controls and other features we were adding on required more than what was available. Our solution was to pair Makey Makey to handle the controls, and feed that into the Raspberry Pi. That left enough pins to control coin detection, audio, a way to escape the emulator, and a way to select the number of players. If we’re running into design and technology considerations with modern computing devices, what sort of things did the original game designers run in to? And how do their decisions reflect something about the technological history of the 1980s? But I don’t study those questions. Maybe they’re obvious questions to those who do. So why am I interested in creating a game emulator within a 1983 gaming desk? As a teaching tool, I find physical computing immensely compelling. I could envision a course on the history of computing or the history of electronics that asks undergraduates to re-create historical objects using modern-day technology. But our technology today – like any technology – carries limitations of function, energy, availability, affordability, and so on. Design decisions are made throughout the process. As they ask questions about their current technology, that opens up an opportunity to ask questions about historical technology. With those questions in mind, plus their physical interaction with the device, we could turn students towards primary sources to understand the historical limitations of technology. We come to understand the past through a material engagement with the present. And as a public history tool, physical computing likewise holds promise. I could envision an opportunity to use such devices to prompt users to think about the historical preservation of electronics, electronic media, and games. Or, to completely repurpose something like a gaming cabinet as an alternative interaction device. You could, for example, set up the cabinet to run Google Earth and allow the game controls to be a method of guiding yourself through historically-recreated virtual worlds. Or replace the cabinet with a physical globe that controls Google Earth. What other perspectives could physical computing lend to the ways that we appreciate electronics or interact with explanatory devices? Anyway, some initial thoughts about the intersection of physical computing with digital history. We’re doing a lot more in the courses and I have many more ideas swirling about – 3D printing, historical reconstruction of electronics and devices, and so on – but those will come later.