Visualize History

Visualize History
Computer Science 490
Sam Strasser
September 28, 2007

1 Introduction

Visualize History aims to provide a new way of presenting and understanding history. The application will provide an intuitive, interactive way to navigate the complex relationships within history.

Historical events are often restricted to the pages of books, newspapers and magazines, and from a very young age, people learn to approach history only textually. When images are used, they often supplement or summarize the prose; only rarely does visual data stand on its own.
Yet no intrinsic property of the historical data enforces the convention that words should trump images. In fact, much of history is naturally presented visually. Any interesting history will consist of various parts, interlinked and roughly ordered. Students must reconstruct the multi-dimensional story from the linear prose they read in order to understand the complete picture.

Visualize History will attack the general problem by presenting that multi-dimensional story in multiple dimensions. For example, many key events are directly linked to a specific geographic location and all are linked to a specific time or time period. The application will therefore provide a way to navigate through both time and space. However, the logical relationships are just as important as the temporal or spatial ones, and the application will also provide a way to navigate from an event to other related events.

2 Research

The problem of visualizing historical data is in no way new. David Staley predicts that computers will change the way history is taught (Staley, 2003). In his book, he gives philosophical arguments and predictions for the evolution of historians and historiography, as well as examples of new ways to present data. Edward Tufte, perhaps the most famous person to visualize data, gives example after example of historical data that was properly presented, and of some that was not (Tufte, 1997). He tells of the cholera outbreak in 1854 near the Broad Street pump, and the role of the diagram in evaluating the cause of the outbreak. The list of examples, even as given only by these two authors, goes on and on.

The problem has not, however, been addressed in general. Each of the example diagrams had its own special considerations that factored into the final product. Each case was to be considered separately, and often yielded vastly different diagrams. My research will focus on the characteristics that can be abstracted out of this long list of examples to characterize the more general problem, and those characteristics that are truly specific to the individual case. Specifically, the research will aim to define history in the abstract case, and especially try to narrowly define the relationships between and among historical events. For example, to visualize wars in which the United States has participated, the Civil war might be represented as one blob that spans 1860-1864. To visualize the end of slavery, though, the civil war would need to be broken into smaller pieces, such as the emancipation proclamation or Southern secession. By examining many such examples, I hope to be able to abstract a loose but formal structure for historical data in the general case.

While looking at these specific solutions, one quickly sees the problem become unmanageable. That is, more events are related than one might want to show at any time. Another main goal of my research therefore will be to define the application’s domain in such a way that the data remains manageable and comprehensible. That domain must allow at least for the most important types of history, and should allow for as much flexibility as possible.

3 Design

The design process will be to formalize that loose structure into a formal structure that can be efficiently implemented. The design will consist of three pieces: data storage, abstract historical objects and the user interface. I expect to produce a diagram documenting the flow of data within the application, both between abstract objects and also between the user interface and those objects. It will label all inputs and all outputs, and map those inputs can follow through the application. I will write the design in loosely object-oriented terms, demonstrating the objects and the relationships between them.
Part of that design will include large portions that will not be implemented due to the large scope of the project. Where possible, I will note what I intend to implement. The implemented pieces will assume that the designed (but not implemented) features will eventually be implemented.

4 Implementation

The implementation will depend heavily on the design that I come up with. I will have to make several high level implementation decisions, along with the more mundane ones.

I expect to use one of three general platforms. The Google Maps API provides a lot of core functionality, such as converting natural language locations to latitude and longitude pairs or doing the actual display of the graphical data. The second potential platform would be Microsoft Silverlight and the third would be a Java applet. In either case, Visualize History will be easily embedded in a web site. The decision between the three depends almost entirely on what tools they provide in this specific area, namely for geographic translation and display.

The language will be implied by the platform. For example, Google Maps require JavaScript, for which I know syntax but am relatively inexperienced. Silverlight would allow for any .NET language, and I am very familiar with C#. A Java applet would imply Java, which I am also fairly familiar with.

Because so much of the design will not be implemented this semester, the implementation will allow for the addition of the documented features, even if they will not yet be added.