Visualize History

When creating a project, deciding whether and which partners you should take on can be difficult.  You want to depend on external organizations as little as possible, obviously, but at the same time, in some cases you can get a lot for a little.  Microsoft does it with the Windows API, just as Google does it with their APIs, and for both, developers flock to the APIs, creating free content for the big companies, without being asked.  Partners are kind of like that.  Sometimes they can scratch your back without you putting in any energy.  For that reason, I’ve always been on the lookout for sites to partner Visualize History with, whether officially or unofficially.

Partners in Content

Visualize History always aimed at synthesizing a large amount of information, but doing so necessarily limits the detail of that information.  Luckily, it’s an interconnected web we live in these days, and there are many sites that provide great historical content.  Those are good partners to link to and to pull content from.

For instance, a whole bunch of sites exhibit historical photographs, including Life, Time, National Geographic, Nasa, the National Archives, and the University of Pennsylvania.  New sites have sprung up, devoted to historical images, like this one, this one and this one.

You can of course find more than pictures online.  There are historical documents from Yale, maps from the Library of Congress, and newspapers from Google.  I could spend hours in any of these collections.

And if unguided exploration is not your thing, you can find classes online, whether it is history classes from the Ivy leagues or a survey course from George Mason.

Partners in Function

Some of the fun of history for me has always been linking my story or the story of my family into whatever I was learning about.  More generally, people love to participate in history.  Maybe Visualize History could help you plan a trip to historical sites, like up-and-coming website Pastigo does.  Maybe it could map your location over some time period, and put that on a map with other data, using your iPhone’s location.  Maybe it could provide the data for an exhibit in your museum or classroom, with the help of Omeka.

As you can see, I have grand ideas, and others do to.  Mixing and matching those ideas is what the web is all about.

No comments

For the past year and half, every time I’ve seen anything that could possibly relate to Visualize History, I’ve carefully noted it down.  I have now accumulated so many things that I think I need to share them with you.

GIS (Geographic Information Systems)

When I started working on the project, I did not have a clear idea about the distinction between what I was trying to build and a standard GIS system.  I worried that I was merely recreating something well established.  I no longer think that, but nonetheless have encountered several relevant GIS exhibits and projects. 

Two stuck out in my bookmarks.  I like the first, StatPlanet, because the UI is pretty intuitive.  You can explore some common indicators, like the AIDS epidemic or education training by country.  There is a time element, but it’s not easy to go between times.

The other GIS-related example that stuck out to me was WorldMapper, which skews a map so that each country reflects its relative size for a given indicator.  For example, in the world population map, China and India look large because of their dense population.

Specific Historical Examples

From the very beginning of my research I recognized that many specific examples of my project existed already.  That is, people had found great ways to visualize specific historical events.  At one time, I had a long, long list, which included the Peabody museum in New Haven, CT, but that list seems to be gone now.  I have found several since.

• Google shows where our oil comes from
• The New York Times presents an interactive timeline about Israel and the Gaza Strip (via)
• The Sunlight Foundation presents a history of transparency in the US government
• Google creates an exhibit on voting in the US since 1980

I found that the highly customized exhibits were compelling, but not easily applicable to other situations.  Some, like the Israel/Gaza timeline, were pretty general and yet maintained the necessary content and interface.

Genealogy

When I first dreamt of making Visualize History a real business, I thought that genealogy might be my ticket in.  People love exploring their family history, and many people will pay to do so.  Many sites have started to spring up, and I have even started seeing ads for genealogy sites on TV.  Clearly at least one company thinks regular old TV-watching people will pay to find out about their family history.  I still haven’t seen a great visualizer for genealogy, but I think we will very soon.

Timelines

For some reason, timelines have been around forever.  It could be because they are static, and can therefore be printed.  It could be that writing code that shows a timeline is pretty easy (since every operating system in the last 15 years has included a scrollbar, the key to the timeline).  I’m not sure why, but they’ve been around.  Still, I think recently people have decided to use them interactively, and on the web.

Of the two that stick out, timerime is closest to Visualize History, at least in purpose.  They have the exact Time Slider that I tried to build (and mostly succeeded at, by the way).  They even have a timeline for the Civil War, my canonical example.  I would certainly create a timeline on this site if I had an occasion to.

Capzles, the other timeline-type site, is less like Visualize History but still kind of cool.  They allow you to add media, which is mostly audio and pictures, to your timeline, and then play through it, exploring the media piece by piece.  Pretty cool.

Close, but no cigar

A few projects I came across actually gave me pause, since they resembled my goal fairly closely.  I already discussed the first such project, called Gapminder.  Hans Rosling presents data in a fantastic way, and recently I’ve started seeing a lot of people reference his work.  Google, which bought Gapminder, added the ability to create such maps with your own data, as Sasha Dichter explains.

The other project, another that I found early in my research, was produced at MIT.  The Exhibit part of the Simile project out of MIT takes a slightly different approach.  It is meant to be a widget that you put on your own website, using your own data.  They merely provide the interface.  It looks pretty cool, though it was different enough that I think Visualize History solves a slightly different and more complex problem.

So that’s my list.  There is one more big example that I hope to share with you soon, but it’s not quite ready for public viewing yet.  Soon.  But not yet.

No comments

Commenter Darrin asks “what are the benefits/drawbacks of Python (or Django in this case) vs. PHP?” 

There are two separate issues at hand here, which language to use and which framework to use, given the language.  I choose Python over PHP for two main reasons which are really historically the same reason. 

Why not PHP

PHP rapidly spread across the web after its creation.  One reason it developed so quickly was its ease of use.  In those days, a file on the server corresponded to a file that the user saw.  If I went to http://strassdesign.com/pictures.php, the web server would load /strassdesign.com/public_html/pictures.php and parse it, displaying the result of the PHP code.  Any code outside the PHP tags (<?php and ?>)would be output as HTML.  Page design closely modeled the imperative style of programming familiar to any C programmer, and since most programmers knew C in those days, people understood the metaphor.

People did not however, want a version of C for the web, since C is so impossibly complex for new or amateur programmers.  PHP adopted a more JavaScript-like attitude of forgiveness.  For instance, for a long time, the default settings allowed direct reference to variables passed in via GET, which meant any user could get a variable set in your script simply by appending ?name=value to your .php url.  Of course “it just works” is fine until it doesn’t, and then finding a bug is nearly impossible.  Ask anyone who has done JavaScript development.  Still, for a while, “it just works” was all people needed.  In those days, web software could easily be modeled as

1. make a request to the server
2. process input data and return html
3. view html

As web software became more complex, key concepts in modern programming became important, with the most important being object oriented coding.  For those not familiar with the distinction, object oriented programming allows for encapsulation and modularity, among other things.  That’s a fancy way of saying the code I write for my user logins shouldn’t have easy access to the code I write for the poll, or for my archives, or for any other discrete piece of my site.  PHP of course added object orientedness to the language, starting in PHP3 and more completely in PHP5.  As an old and well adopted language, though, a lot of tutorials and example code relied on the imperative nature of the language.  More importantly, though, the language wasn’t designed to be object oriented, so basic concepts of objects require a fairly complex and non-intuitive syntax and implementation.  I don’t usually like to talk about the “feel” of a language, but in this case, PHP couldn’t feel less object oriented.

Why Python

In school I took a parallel programming course in which we used Python, and I loved it.  The concepts made sense to me, and after a while I used Python for all my scripting needs.  I like its GUI interpreter IDLE, and the ability not to have look up every function online by using the dir( ) command.

Python’s most important advantage is that it was designed to be object oriented.  Modules are fundamental to Python, and almost no fancy functionality exists outside a module.  For example, PHP uses built in functions like xml_parse for XML but Python uses modules, which means I can switch or add formats without needing to find the correct function in the core language.  I’m not sure I could explain the advantages of object oriented programming without adding another 500 words, but if you are interested, I will gladly chat about pros and cons. 

For web development, there are really 3 popular non-Microsoft scripting languages: PHP, Python and Ruby.  Having eliminated PHP, I had to choose from the other two.  Since I was already fairly expert in Python, I chose to explore that as an option.  It already solved my biggest problem with PHP, namely the proper use of objects.

Why Django

Python may be the coolest thing since sliced bread, but it was not designed for the internet.  I had to make sure that I could map web concepts like 404 pages, dynamic urls and GET/POST requests to Python.  Django does exactly that.  I thought Django might be difficult to learn at first, but it uses the feel of Python well.  Its modules follow common practices in Python, and it took me 45 minutes to learn the necessary parts of the framework. 

So I knew it could work, but I had to make sure it solved my other problem with PHP, namely the separation of code and presentation. Programmers don’t often make good designers, as Joel, Jeff, and Joel and Jeff all explain.  These days it is unusual for a designer and a coder to be the same person.  I am both in my little project, of course, but even then I don’t wear both hats at the same time.  When I’m in the zone coding, I don’t want to think about <div> or styles.  When I’m designing, I tolerate thinking about those things, as well as colors and such nonsense.  So for me, that separation is absolutely key.  Django provides a simple templating system that supports inheritance in a way that makes perfect sense for the web.  All my pages will have the same meta info, the same header and footer, and some other stuff, and I certainly don’t want to write those more than once.

Django provides some added benefit that I didn’t know I needed at the time, but now love.  The first is its database access, which abstracts away SQL and instead uses Python objects to represent data.  I hate writing and debugging SQL, and for the most part, I don’t need the power and complexity that relational databases provide.  All I ever do is add objects, read objects, and find related objects.  Once you write one JOIN statement, you don’t need to write any more, ever again.  So I don’t. 

The second feature surprise was the URLConfs, which map logical URLs to code.  I can now have a page like http://www.visualizehistory.com/exhibits/featured map to a function, which is completely transparent to the user.  If I ever want to change the functionality, it is trivial to do so.  It also lets me manage the URLs of the site in the same way a human thinks of them, that is conceptually and not as pieces of the filesystem I happen to have.

The last feature of Django I rely on heavily is the built in web server.  It lets me develop offline, make a lot of changes quickly and generally speeds up development time a lot.  The server is simple enough that I can use it and complicated enough that it mirrors my actual set up in the cloud.

4 comments