Many, many events have come and gone without comment in the last two months on this blog. Significantly, in January I went to both the AHA in New Orleans and to the Digital Humanities Winter Institute (DHWI) at the University of Maryland. On the former, there’s a post brewing particularly about a round table I was responsible for as Chair of the CLAH Teaching Committee. That, and the music and food in NOLA.
DHWI was as a very interesting experience. I took a class on large scale text analysis in R taught by UNL’s Matt Jockers. There was tons of code, and a learning curve for me in getting used to R’s data structures and syntax. I’ll admit I struggled a bit with visualizing in my head the various types of matrices that constitute much of R’s data structures. I have more to say about this class too, but in another post.
I drove each day to College Park from Baltimore together with Alex Galarza. Alex and I talked a lot sitting in traffic on I-95. At some point during the week we ended up in a discussion on something I’ve been thinking a lot about in the last year or so– frameworks for long form (historical) narrative online. We both share some misgivings about many of the platforms currently in use in Digital History projects, including WordPress, Drupal, Omeka, KORA, etc.
I’m not a designer, and I think that I lack a vocabulary to explain exactly what my misgivings are about the current platforms and how they affect the potential for presenting long form historical argument. In the case of the platforms I listed above, in each case the idea of constructing a long form narrative on the platforms always feels like a hack. WordPress is a great platform for writing blog posts. It doesn’t take much, though, for an individual post to get to the tldr level. The UI of a blog sets limits, at least of expectation, on the length one will spend reading an individual piece. That’s not, of course, the condition of an Omeka or Drupal, both of which might be used in a blog-like manner, but which are intended at a more fundamental level as expressions of modeled relationships between entities that exist in their databases. The way that the elementary entities of the various CMSs are conceived affects the organization and delivery of information using that platform. Raf Alvarado gave an excellent talk on this very thing a few years ago at THATCamp Prime. I put up my notes from that session a few years ago, which was the best presentation I’ve ever heard of the connection between the ontology of a CMS and its resulting product. I bring it up here because I think that Raf’s idea about the way platforms (CMSs) model content has direct bearing on my own discomfort with them as current options for long form historical narrative.
Let’s take Omeka as an example. In Raf’s presentation he noted that for Omeka, the elementary unit is the ITEM. Items belong to Collections, and have Dublin Core metadata, keywords, and tags associated with them. Combinations of items, organized by membership in collections or linked through metadata, keywords, or tags allow information to be accessed through Exhibits. Raf described this, borrowing a term from Landow’s Hypertext, as “Axial Hypertext,” or a “sequential content model.” On the face of it, it may seem that a sequential content model would be the best for historical presentation, encouraging the reader to go through a sequence curated by the scholar through the construction of exhibits. Reading that sentence, I imagine you imagining a museum, which is appropriate given the genealogy of Omeka. But, it highlights what remains an unspoken divide in historical scholarship– between what is traditionally called “public” vs. academic history. The narrative of a public history exhibit, and that of an Omeka site as well, is intimately tied to Item objects. This isn’t the case in the kind of history I and most of the History professoriate write.
Long form narrative is not object oriented, to butcher a phrase associated with philosophy and computer programming. While historical writing is certainly evidentiary, it’s not a sequential presentation of evidential objects. Omeka doesn’t force one to parade objects, but it is predisposed to organizing information in that manner. I’m not trying to pick on Omeka either, because I have problems with all of the major platforms and the models they impose on the information-knowledge complex. They can also all be hacked for the purpose of long form historical narrative.
Why does this matter, even? We have epubs for tablet reading. Isn’t that the electronic substitute for the book? It is I guess, but it falls short for me for two reasons. 1. Epubs truly do cede design elements to the platform. 2. Epubs do little to utilize the interactivity made possible by hypertext. They’re an ugly simulacrum of the book. I also don’t like the movement of more and more information to apps, as opposed to on the open web. There isn’t too much I can think of about the epub experience that can’t be replicated on a well designed website that is by intention responsive to screen size and computer type.
This discussion cropped up on twitter a couple of weeks ago. Alex storified it. It was started by a query about allowing users to create their own narratives from archival collections. It’s a cool question, and one that is really similar to the idea behind Scalar or Scholars Lab’s plugin Neatline for Omeka.
I’m really less interested in existing or new platforms that can be coerced into long form historical narrative, especially those where evidence objects are the central focus of the platform’s “data object.” I’m more interested in general design principles for presenting either wide-ranging or deeply analytical historical work online. Digital History has focused more on the object of evidence, in part because of its roots in public history and in part because really the Web provided for the first time the capacity to share sources ubiquitously. As a result of that orientation, and with exceptions of course, DH has not offered much to historians working in a more academic mode. And that’s a shame. And that’s a shame that has affected the perception of DH in the traditional academy. If you doubt that, read the Introduction to Allan Megill’s *Historical Knowledge, Historical Error, which is essentially a scathing review of Valley of the Shadow. The problem, if it is one, is the extent to which Digital History has turned it’s practitioners into curators or archivists to the neglect of long-form narrative and analysis.
It’s my contention that part of that is platform driven. I’d like to call, instead, for an html/css/js framework for historical narrative. The success of a css framework like Twitter’s bootstrap is in part its platform independence. There has been a backlash against bootstrap, in part because of its success. And its success is rooted in providing a set of icons, css layouts, javascript ui that makes it easy for people without design chops to prototype a site quickly. I don’t, though, find bootstrap to be particularly readable for the kinds of sustained interaction historians are looking for. We’re not talking about web applications here, as much as a newly imagined book.
What would a framework for historical narrative include?
- A minimalist interface.
- Good typography that conveys the seriousness and temporality of the narrative. With today’s screen resolutions, I think we can go with serif fonts and large type. We’re not selling SAAS or any commodity, so why take our typographic cues from that world?
- Navigation. Finding one’s place, and finding it again is important for scholarly reading. Together with navigation would be, I’d say, the ability to cite by paragraph. And, to be honest, I’m neither a fan of scrolling or pagination. But maybe that’s just me.
- Javascript popups for footnotes/endnotes, and maybe for evidence objects as well. One of the things that hypertext has done to sustained reading is present a huge array of interesting and distracting linked elements. But, every time I leave a page to look at something, finding my way back and refocusing can be difficult. Better embedding would help this.
- I’d really like some means to visualize embedded metadata/rdfa/microdata as well.
What else? What else would you want to see in such a framework? The upside of such a framework is it could be used with any platform, or by itself with book-length works written in Markdown. This isn’t exactly the direction the conversation on twitter was taking, but as Jeremy Boggs tweeted in the storified conversation:
@parezcoydigo @galarzaalex @anneperez @tjowens @wragge @miriamkp we’ve only scratched the surface of what we can do with good ol HTML & CSS
— Jeremy Boggs (@clioweb) January 23, 2013
With the ease of authoring with Markdown, I think he’s exactly right that there’s still much to explore with just HTML and CSS.
Associate Professor of Early Latin America Department of History University of Tennessee-Knoxville
parezco y digo 
Intriguing proposal, Chad.
A few thoughts about EPUB as a platform for this kind of narrative. First, the “ugly simulacrum of the book” is not inherent in the format itself. Apple’s iBooks displays EPUBs with the “chrome” of a book, and it’s a terrible design decision, but there’s no reason why other EPUB readers couldn’t be better designed. Second, there’s no reason why EPUB’s can’t take advantage of hypertext. It’s true that the vast majority of texts in the EPUB format don’t, but that’s a problem with the way texts are written. Third, there is one big advantage to using EPUB. Because an EPUB is just HTML glued together with a little XML in a ZIP file, it has the advantage of portability and storability. In other words, you can store and distribute an EPUB in a single file in a way that you can’t distribute a website.
I think I agree that a website should probably be the primary means of distribution. But if a website is created from Markdown files, as you suggest, then it’s easy enough to also create an EPUB from them using Pandoc. We could make some better defaults for Pandoc, such as improved stylesheets.
I completely agree that citation by paragraph (or by some other enumerable logical division, it doesn’t much matter), perhaps not unlike citations of classical texts, is something we need to figure out. For the JSR I tried to enumerate paragraphs using jQuery, but I couldn’t get it to work in the time I was willing to spend on it. Someone with better jQuery chops than me could probably do it easily. I wonder with a Javascript solution, though, is the best, since it divorces the enumeration from the markup, and thus could conceivably number the same thing different ways. Perhaps the best, most stable format is something in XML, like TEI or Docbook, but I don’t know much about either.
For popup footnotes, check out Footnotify, which you can see in action on any of the article pages at the JSR.
[…] Lots of great stuff in Chad Black’s A Long Form Historical Narrative Framework. […]
Thanks so much for this post, Chad. I’ve been talking about this (mostly in person and on Twitter) for a while now, and I’m glad issues of design are finally starting to come to the fore in digital scholarship because it’s been too long ignored, and often, as you note, at its peril. My response is mostly an affirmation of your position (as I am a web first person), but I guess I do have a few things to add.
I have a saying about WordPress: it’s really great for a lot of things, and I use it when I can, but it basically dares you to do anything other than make a blog out of it. I think the easiest way for digital humanists and their collaborators to transcend the problem of the CMS platform and other apps is to look to the amazing work being done in the web standards and design community. Even something as simple as adding A List Apart to one’s reading list would be a terrific start. I think this point about web standards is implicit in your argument, though I think we probably need to start making it more explicit. The database-driven publications we build through extended CMSes will always require attention and maintenance that, I think it can be argued, is completely unsustainable given most campus resources. And while I can’t predict the future, a well designed HTML/CSS/JS publication will stay operable and thus relevant long after something built in an old version of WordPress that has a dozen deprecated plugins powering it.
You also mention responsive design, something just about everyone who’s not a web designer is ignoring right now, but to which is utterly essential to good web publications. No matter the form, digital scholarship will be accessed on any number of screen sizes and resolutions, so we should be designing our publications with that in mind. Something online may be highly accessible (to those with a connection), but it takes more than a stable URL for something to truly accessible: it needs to be readable and customizable both for different devices but also different types of (human) readers.
Navigation, to me, is kind of the Holy Grail of this whole thing (I think everything else you enumerate is not only doable, but probably already being done) and I have no answers. All I know is that with long form narrative the user not only needs to know where they are, but where they’ve been and where it is they can go. Whether that’s decided for them in advance (linear, authorial design, etc.) or not (the Scalar “paths” approach or something even more radical) is almost beside the point, but we often get stuck on the point.
OK, enough rambling from me. Looking forward to what others have to say and examples of what’s already been done. Again, thanks for prompting the conversation, and I’d be happy to collaborate on this if needed.
Interesting Chad…
A couple years ago I had written a quick experiment with a Markdown-to-TEI preprocessor that could use Pandoc to generate whatever format you needed. Never took it too far as it was (at the time) a bit of a crazy idea that I had while struggling with my publisher’s requirement that I submit chapter drafts in Microsoft Word (a ghastly interface for someone who lives in vim and the terminal). Timelines got in the way of doing too much with it, so it never went to far in actual code.
One of the harder parts in designing these sorts of systems is that everyone has one particular thing in whatever editing interface they use that they HAVE to have that is essential to their workflow. You could pretty easily use something like EpicEditor or ACE to collect the actual text, but I think the more difficult (and interesting) part is actually providing some method of customizing the output. It needs to be robust to the things people put in to the editor in an attempt to “override” what the stylesheets are doing, but be flexible enough to allow people who know what they’re doing to implement custom designs.
As Josh pointed out, one of the other difficult things to figure out is navigation. We’ve been trained to write papers and long-form to be serialized to a piece of paper. This is kind of an amazing interactive environment in that any consumer can write notes, strike through, and mark their place as they seem fit. There’s no interactive space (unless you are using some of the cooler aspects of the stuff Amazon and Apple are putting in their publishing platforms), but it is a space that people understand and don’t have to spend much time figuring out.
The upshot of all of this is that I don’t think a system like you’re proposing is technically difficult. I think the harder bits are designing something that allows scholars to have control over how their work is viewed and consumed, while experimenting with new ways of interacting with the text are important, especially as the computer industry continues to move toward touch interfaces for more platforms…
[…] connection with my recent piece on <a href=”https://parezcoydigo.wordpress.com/2013/02/04/a-long-form-historical-narrative-framework/”>l… historical narrative</a>. The context of these comments comes with Landow’s admission […]
[…] Black at his blog Parezco Y Digo attempts in an intriguing post to articulate and work through the implications of developing a new platform for presenting long […]
[…] or interpretive? The CMS you choose might be different in each case (Chad Black has a thoughtful blog post exploring this issue). Do you have – or need – a long term preservation plan? Do you need a separate site or […]