Visualize History

(I just turned something like this in, and the pdf is online.)

1 Overview

1.1 Goal of this document

This specification will outline the user interface of Visualize History at the conceptual level, one level above the actual code. Implementation details will be included only when relevant to the structure of the interface.

1.2 User Interface Pieces

The user interface will consist of two main panels, each of which will be broken up into several different logical (but not graphical) pieces. The rest of this spec will be easier to understand after looking at the breakdown in the image to the right.

2 Navigation Panel

2.1 New Session

When a user first arrives at the site, she will see the New Session mode, which will serve as the starting point for a user already familiar with the site as well as provide more detailed information for a first-time user. In the Navigation Panel, the New Session mode will include:

· Popular examples: A list of examples that best demonstrate Visualize History

· Recently Studied: A list of examples that this particular user has recently looked at

· Take a tour: A static link to a step-by-step tour, for first-time users

2.2 Browse

A user will be able to browse history by topic. The topics will be presented as a tree. Only one or two sub-levels will be shown, and the rest will be downloaded from the server as needed (asynchronously). Here is an example of the topic tree a user might see:

• Wars involving the United States
• U.S. Revolutionary Way
• U.S. Civil War
• U.S. Civil War Battles
• World War I
• World War II
• Vietnam War

2.3 Visualizing

The last possible mode, Visualizing Mode, occurs when the user has already started interacting with the application. During Visualizing Mode, the navigation panel will show:

• The topic that the user is currently viewing, including its name, blurb, start- and end-date.
• Topics related to the current topic, which, when clicked, will switch focus to the new topic

Note that the UI for this piece will mimic Browse mode closely, using the topic-tree again

3 Viewing Panel

3.1 New Session

When a first-time user first visits the site, her attention will be on the Viewing Panel as the biggest and centered item, and not on the Navigation Panel. For a New Session, the Viewing Panel will show:

• Intro paragraph: describing what Visualize History is and what it is for
• Getting Started: A few bullet points saying how to start using the application
• FAQ
• Popular examples: the same as previously mentioned

3.2 Visualizing

3.2.1 Map

The Viewing Panel is the core of the application. Once the user starts a topic, she will mostly be interacting with the Viewing Panel and not the Navigation Panel. The Viewing Panel will primarily be a geographic map, loaded at some initial location (say, the United States). It will be draggable in both directions, and you will be able to zoom in and out.

I plan to delegate the entirety of that implementation to the Google Maps API. The API allows for all of the necessary actions through a seemingly simple to use interface.

3.2.2 Nodes

The Nodes will be one of two types of historical data. The first, an event, is what you might think of as history; battles, deaths and proclamations are all events. The other type of node, a region, is again logically named; the area that a proclamation applies to would be a region.

For version 0.1, only one topic will be shown at one time. That topic will be reached by clicking a link, either in the browse window or in the popular examples. When a topic is being shown, all of its children will be loaded into memory. Then, when the topic is changed, the new nodes will be asynchronously loaded into memory.

A node will be displayed as a small icon. That icon will have a text label next to it. When the user mouses over the text, a box will appear, which will include the title of the node, and more detailed information about the node. Clicking on the node will make that node into the topic of focus, in effect “zooming in” on that event.

Eventually, nodes may be differentiated. For example, if 10 nodes belong to three categories, each category might have nodes of a different shape or color. Again, that is easily done through the Google maps API.

Regions will be represented similarly so nodes, except they will be assigned a background color and will be lower on an imaginary z-axis (below in depth) of the event nodes, to allow events to be shown on top of regions.

3.2.3 Time Slider

The crucial piece of the Visualize History user interface will be the piece that controls navigation through time. The dimension of time separated Visualize History from other applications and needs to invent the interface required.

There will be a time slider, as shown in the picture. In the middle of the bar, a smaller bar shows “now”. This now-bar determines which nodes are currently being shown. It can be dragged, stretched or shrunk to change which events are being shown.

The now-bar will have text labels, much like the labels for nodes. When moused over, the labels will show a border, and when clicked they will become editable. A label will show all the relevant parts of the now-bar. For instance, if it has been stretched, the endpoints will each have a label. If it has not been stretched, then only one label will be shown.

The endpoints of the time slider will be fixed for a given topic at the earliest and latest relevant date. They will not be draggable, but to accommodate future UI goals, they will be changeable.

There will also be a small button to “play” time. This will be deemphasized, to emphasize the ability to drag time at any speed and in direction desired. The now-bar will also move by 1/2s to allow for a decelerating effect.

I’ve recently been struggling with a lingering notion of a competitor to Visualize History.  Competitor is not exactly the word I’m looking for, but the point is that I’m not trying to rephrase or really in any duplicate this other concept.  That other concept is GIS.

GIS and HGIS

A GIS, or geographic information system, is a tool that allows for the manipulation of spatially related data.  It allows for fairly complex queries on these massive stores of geographic data, which in turn provide valuable tools to many fields of study. 

Historical GIS (HGIS) is, as you might expect, the application of GIS in the field of history.  A GIS specialist might tell you that the chief job of a GIS system is accumulating and presenting overlapping datasets.  An historical GIS accumulates historical data, but, in general, uses the same presentation as in all GIS applications.

These applications all tend to focus on this key idea of overlapping datasets.  ArcGIS and GRASS (the open source alternative) seem to be the industry standards for GIS applications.  For the more common of you, think of Google Earth as a very simple version of such an application.  These applications include a feature, usually called “layers” that allow you to show or hide many datasets all at once.  The idea is to be able to correlate a lot of historical data visually, thereby discovering new theories or at least new ways to teach old theories.

Issues with GIS

I disagree with the approach of these applications take for a number of reasons.  Assuming that the goal of the applications is to teach history, each one fails at a fundamental level.  Consider for a moment the layers.  What is a “layer” of history?  The first temptation is to consider a topic a layer, so, for example, the Civil War might be a layer.  Then you can compare the Civil War with other wars by hiding there own layers.  But if you want to examine a Civil War battle more carefully, you have no obvious way of doing that.  Does the battle belong in its own layer?  What if some event belongs to more than one layer?  What does showing both mean?  What about hiding one?  This inability to use the fundamental concept of GIS, these layers, makes it seem at best unlikely that GIS will help teach history.

The more fundamental problem with GIS for history, though, is that it does not allow for conceptual data.  All data must be georeferenced to allow it to be correlated with the digital maps.  That level of specificity prohibits the majority of what we might call history.  HGIS is well-suited for presenting, say, the percentage change in obesity over the past 100 years, but it is incapable of showing the Civil War as an entity in and of itself.

More Resources

If you are interested in HGIS, I recommend Past Time, Past Place by Anne Knowles, a collection of case studies that use GIS to do historical research on very specific subjects.  Also check out gisforhistory.org which looks at the visualization of census data.

Postscript

In writing this I realize that the two are in fact not nearly as overlapping as I feared.  But, I only realized that by writing this.  So it isn’t exactly a waste.  Thanks for listening.

I alluded to a problem I would have to face, and so, here it is.  I don’t know what to do about polygons.  A lot of history, properly visualized, will require drawing regions and not just points.  Picture teaching the Cold War without showing the spread of Communist or Democratic countries, or explaining the Divine Mandate without showing the spread of exploration across the western United States.

So, here’s a more formal definition.  I have an unsorted set of points, where each point has an x and y coordinate (or longitude and latitude).  I need to order those points so that, when I draw them in order, they look like a region.  I think that means that I need to order them such that none of the lines drawn overlap.  I can’t think of how to do this in a fast way, and, to be fair, I can’t figure out how to do it at all.

So, in the traditional Computer Science way, I will now be considering that problem a black box.  I’m so confident in my ability to solve it (i.e. to search the internet) so, soon, it will be solved, and for now, I’ll just assume it is. 

See?  Now I’m free to think about other, bigger things.

(This post will be on the technical side of things.  Feel free to skip it.  Or not.)

Now that I have history broken down into such well-defined conceptual pieces, I need to start translating that into computer-based storage. I did not pay enough attention in my Databases class here at Yale, so the best way I know how to address this problem is to list the queries that I’d to be particularly fast, and then set up my tables based on that.

Queries

Here is the list of queries in pseudo code.  I think the once I draft a feature list, I will be able to add, delete and edit these queries.

• select nodes related by {relation type}
• select children of a node, by detail
• select parents of a node, by detail
• select nodes of same type
• select nodes for a specific time period
• select region for set of nodes

SQL Tables

And here are the tables.  Underlining means I will have a key on that column.

• nodes: uid, title, type, blurb, description, start_date, end_date
• node_citations: uid, author, title, year, city, publisher, url
• node_relation: from_uid, to_uid, type
• node_region: uid, latitude , longitude

The regions are causing me a slight problem right now, which I will discuss later.

Before history can be properly visualized, it must first be clearly defined. There are a lot of definitions of history out there, and those definitions cover a lot of material. My hope is to fit that mass of data, or some reasonable subset, into a formal and simple structure. I’ve drafted a first version of that structure, for now only on the conceptual level.

Before I can get into that, I will need to define some of the language I use. I will often talk about History as a “graph”, by which I mean the traditional computer science definition. If you do not know what that is, it’s a very simple idea. There are objects (”nodes”), and two objects may be related to one another (or they have an “edge” between them). That is the whole graph, G = (V, E). Of course graph theory adds a lot to that definition, but the important concepts are nodes, and connections between nodes. I consider History as such a graph, albeit a very large one.

Nodes

First I will consider the nodes of the graph. I chose several historical topics and, by examining those, have tried to extrapolate potential types of nodes. Here are the fundamental pieces of History, according to my interpretation:

• Event (e.g. “The Civil War” or “The battle of Antietam”)
• Topic (e.g. “Wars” or “The Civil War”)
• Location (e.g. “Antietam Creek, Sharpsburg, MD”)
• Person (e.g. “Robert E. Lee”)

The idea of a “location” or a “person” seems pretty concrete, and pretty essential to history. I will not dwell on explaining those two. The more interesting types of nodes are the “Events” and the “Topics”. By “Event” I mean any happening that would be considered a single entity during study. Battles, proclamations, or treaties are all examples of Events. By “Topic” I mean any issue that has some sub-events. So a topic might be the Cold War, the Cholera Outbreak of 1854 in London, or American Independence.

Notice that “The Civil War” is both an event and a topic. That is, I may be studying conflicts that took place in America, in which case I will consider the Civil War as its own complete entity which should be compared with other entities, for example, the War of Independence. In this situation, the Civil War is an Event. I may instead be studying the Civil War in and of itself, in which case I will be interested in the battles, proclamations, secessions and elections that took place before, during, and possibly after the War. In this case, the Civil War is a Topic. But in both cases, the same things are true of the Civil War, such as its name, its start and its duration.

From now on, I will try not to distinguish between any types of node, and merely discuss nodes. Nodes, based on my research, have the following properties in common:

• title
• type - Event, Topic, Location or Person
• blurb - A short description of the node (one paragraph)
• description - A long description of the node (several paragraphs)
• start date and time
• end date and time
• citations or places for further research

Edges

Now that we have a more formal idea of what a single historical event might be, we can start to consider the truly interesting part of the graph: the edges. Historical events relate to one another in many ways, and even several types of ways. These relationships between nodes have to mesh with what an everyday person considers relevant data.

Many historical events are implicitly related. They may share a time period, a region or participants, even when there is no direct connection. For instance, Robert E. Lee participated in both the Civil War and the Texas Revolution, and those two wars are therefore implicitly connected through him. Another example might be the Great Revolt in Palestine in 1933, and the Great Depression in the United States during the 1930s. Although the two seem entirely unrelated, they do share a time period. Imagine studying the Great revolt, and wondering why the United States (and other powers) seem so conspicuously absent; just pan over to the United States and observe that they had other things on their mind.

Most of the history we teach, though, is about explicit relationships. We would like all of the battles of the Civil War to be somehow related to one another. If each node in our graph is a battle, then two related battles might be connected by an edge. Alternatively, though, all battles would be connected to the node for The Civil War. Either way, the battles now all belong to one grouping.

The majority of Visualize History will focus on these explicit edges, which I plan to input by hand, at least for now. The intuition is that by focusing more on the human-entered data, we can control which sub-section of history to focus at any given time.

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.

I’m having a bit of a week here. I’m in the middle of discussions with a potential employer about potential copyright and other legal concerns relating to VisualizeHistory right now. The good news, though, is that I’ve decided to keep everyone posted anyway. Let the lawyers be lawyers and figure it out later.

Hi there. Things are getting pretty serious over here at Visualize History. In fact, they are so serious that I felt compelled to blog about it.

VisualizeHistory.com is a placeholder right now. I am designing a web-based application for my senior project in Computer Science at Yale University, and I will use this site as a whiteboard for the app. If you stumble on it, check it out, do whatever.

It’s good to get things off the ground.