The Historian

More often than not, my days are bookended, start with, or end with my dissertation. Some of the work is digital — some spatial visualizations that I’m working on, some text analysis to do — but I’m otherwise writing or reading. The goal for the year is to have a full draft ready by December 31.

At the end of the day, I’m a historian and still bound to the obligations of our profession. As much as I hope to see born-digital work as a stand-alone outcome of one’s graduate education, the professional standards by which we’re judged are still tied — for better or worse — to a culture of print. That reality is not a bad one — I love books, and tend to think lately that the model going forward is companion DH projects that appear with print books.

But the digital components of my work are part and parcel of my historical methodology. Another tool used to understand the past. My hope is some day “digital history” becomes redundant — that this work fades into a collective understanding of how historians do what they do. To paraphrase my colleague Elijah Meeks, the visualizations, databases, interactive scholarly works, physical computing, and code written are not just mere tools. They are tools in the way monographs are tools: claims and arguments that address a research question. Getting to the point where such work is recognized professionally means a lot of things: from having the work recognized as scholarly output to having access to tools and people that make the creation of scholarly digital projects accessible to any historian who wants to investigate digital methodologies.

So, all of my various roles in DH — The Collaborative Historian, The Spatial Historian, The Programming Historian, this day, this week, this month, this year — are all a part of being a historian.

Back to work.

The Collaborative Historian

I’m a collaborator and consultant on a wide variety of projects at Stanford — the geography of post offices, visualizations of the Grand Canyon, digitizing colonial Senegalese archival records, Chinese grave relocations, Palladio plugins, Chinese railroad workers, the list goes on — and each of these have given me a chance to think creatively about approaches to solving problems. The variety is one of the best parts of my work, and, I suspect, a reflection of a growing area of the university: technology experts who are involved in collaborative research.

And collaboration takes many forms, even if they’re not extended interactions — just working in CESTA for the day has me involved in conversations about digital publishing, musing about the Stanford DH community,  shooting the breeze with the LitLab, overhearing the Humanities+Design fellows talking about their work, chatting about an idea for  a historical U.S. population visualization, and lamenting our too-often-missed goal of trying to jog every morning. 

One of the things I learned early in digital history — and most of us learn — is the work is necessarily collaborative. The work is complicated and often requires creative approaches to ask or solve significant research questions. Doing this work requires other people’s input. The success of projects don’t hinge on the single rock-star programmer or researcher, but rather on a team that joins together various ideas from various disciplines. And DH, I think, is well positioned to push forward the idea that this kind of collaborative teamwork is a form of scholarship.


Still mired in a code problem.

D3.js borked.
D3.js borked.

One of the challenges of Cameron’s project that I mentioned earlier is we’re trying to visualize a large number of points. There are around 12,000 post offices in his database, of which around 7,000-8,000 have coordinate data attached to them that we can then plot on a map.

Unfortunately, SVG (which is what we’re drawing everything in the browser) chokes when drawing too many points at one time. The problem comes when we try to zoom in on points with the mousewheel — it stutters badly as D3 tries to redraw the points. One way around this was to build in mouse event timers, which is now attached to brushing events. So, anytime a user brushes over the timeline to select a segment of time, the points all hide and waits to redraw until a few milliseconds after the user has completed the interaction.

To fix the zooming problem, I’m trying to create zoom in and zoom out buttons — not something natively supported by D3.js, but, theoretically, not too tricky to implement. Hopefully by the end of the day I’ll be closer.

The Spatial Historian

It’s a sunny California day (after a week of much needed rain). I’m variously spending time outside and in, drinking coffee, and, today, writing code. Welcome to my day.

I’m in what I believe are the final stages of a visualization project. In collaboration with Cameron Blevins, we are building a spatial history of the U.S. Post Office in the nineteenth century. Cameron is interested in the ways that the post office can be used as a proxy to understand the development of the American West over the century by plotting the location of thousands of post offices. The result of our work together has been a way for Cameron to ask new questions about settlement patterns in geographic and temporal detail.

Roughly a year ago Cameron had asked me about methods for visualizing a very large number of point data he had collected on the post offices. A variety of mapping solutions exist for this, but for me it was a chance to add another tool to my toolbox. Having been tossed into the viper’s nest of JavaScript and the data visualization library D3.js, I thought it prudent to see if D3 could handle what we wanted to get out of the visualizations.

I haven’t been disappointed. Sure, plenty of tools exist that easily allow Cameron to plot the data — Tableau or Google Earth Engine, for example, allows him to quickly draw coordinate data — but the *customization* of the research question has been key. The tools we use for humanities research, after all, should conform to the shape of the research question, not the other way around. Plugging in the post data gives Cameron one avenue for his research, but D3 has helped build in other ways to ask question. Cameron, for example, wanted to understand post offices in snapshots of time. Our solution has been the implementation of a timeline that allows users to drag, resize, and move spans of time in order to change the status of a post office for that particular time range (either closed, opened, active throughout the time period, and so on).

Geography of the Post
Sneak peak.

The project is nearly ready for a beta launch. Some of my morning time belongs to my dissertation, but my day will likely be spent on D3: tracking down a few bugs yet in Cameron’s code, and continuing work on a visualization plugin I’m working on for Palladio. More on that later.

Today, I’m going to try and write on the various things I do — giving you a snapshot more akin to a Week of DH — but things that make up my day-to-day work.

My day of DH

Skip to toolbar