Tuesday, January 31, 2012

A checklist for writers

Technology both shapes and reflects our values. What do we value in scholarly writing, and how well do our technological choices match those values?

I look for software that supports four necessary or possible qualities of good scholarly writing:

  1. expository writing should be explicit and unambiguous
  2. the writing process is iterative: good writing only comes from rewriting
  3. academic writing in the natural sciences is often collaborative; this is becoming less rare in the humanities (although not necessarily in the cargo-cult humanities )
  4. born-digital writing should be reusable

In a digital enviroment, to write explicitly and unambiguously means more than choosing our words well: it also means expressing the structure and contents of our writing explicitly and unambiguously. Our writing should embody the fundamental principle of separating concerns in our digital work: our first goal is to express our ideas clearly, not to exercise our typesetting skills, so we need a format that that can explicitly and unambiguously express structure. We might choose an XML-based semantic markup system, or some semantically classed “markdown” system such as markdown or textile. What we should not choose is a “word processor.” Even if you can approximate a semantic structure using a carefully chosen set of “styles” (a tell-tale term!), you will be planting your semantic hints in a thick forest of code focused on the particulars of displaying your text visually. Note that it’s perfectly possible to express this irrelevant information using XML formats like OpenDocument. Our question is not “is this an XML format?” but “does this format express the semantics of my document?”

In considering how to support the remaining items in our list, we should look for examples beyond the humanities, since expository prose is not the only form of writing that shares these qualities. In particular, each is characteristic of good composition in computer programming, and computer programmers routinely use software that directly takes account of each of these qualities.

Programmers use version control systems to work with the entire history of a document to update, restore or compare versions. Version control systems also simplify collaboration, and allow mulitiple contributors to work simultaneously on a document. Changes can be silently integrated and shared; if two authors simultaneously make conflicting changes, version control systems can recognize that, and offer authors options to reconcile conflicts manually. There are many good, freely available version control systems. One reason that humanists are less familiar with them than they should be is that version control systems work best with textual data: the binary formats that word processors produce are a major obstacle to integrating our writing in version control, but once we have adopted a text-based semantic format, that obstacle vanishes, and we have a writer’s desktop that lets us write iteratively and collaboratively.

Programmers also provide a model for reusing our writing. Units of code are often packaged in libraries that other programs use. Programmers working on large projects manage the potentially complex interrelations and dependencies of of different libraries and programs using build systems. We are not yet accustomed to thinking about automating the reuse of our writing, but there is no technical obstacle to doing so. We could use build systems to assemble chapters into a book, incorporate common navigational headers into all the pages on a web site, or automatically update an index if one section of a text changes, to name just a few obvious examples.

So our checklist of required tools for writers includes:

  • an editor that works comfortably with semantically structured text
  • a version control system
  • a build system

I plan to add a series of posts with the tag writing to look at how we can work with tools like these to write more effectively in a digital setting. Meanwhile, take the checklist to your college or university IT department, and ask what specific software they support for semantic editors, version control systems and build systems. I would love to learn of an academic institution that is not just pressing commercial word processing software on its students and faculty, but I don’t know of one.

Monday, January 30, 2012

The recursive arithmetic of tenure

The long career path from college student to a tenured academic job is designed to be conservative. A student in the humanities who discovers a passion for an academic subject in his or her first year of college can expect that four years of college will be followed by, say, six years of graduate school that not only provide training in a discipline, but initiate the student in its culture. The (increasingly rare) PhD who then immediately walks into a tenure-track job typically faces seven years of scrutiny before a tenure decision. Newly tenured professors have proven that their work meets the professional standards of their colleagues — seventeen years after entering college.

Like many professors, I hope that a college education is a formative experience in the lives of my students. Imagine that the newly tenured professor was inspired, seventeen years ago, by an exciting teacher and scholar. That person of course would have climbed the rungs of the same professional ladder, so the youngest tenured professor who could have inspired today’s youngest tenured professor might in turn have first been inspired as a new college student … 34 years ago.

In 1977, the late Steve Jobs was just starting a company he had formed the previous year to sell the computers he and Steve Wozniak were building in his father’s garage.

We’re trying to cross an ocean by standing at the shore and waiting for continental drift to carry us to the other side.

The humanities-that-must-not-be-named

I’m not thrilled with the term “digital humanities.” When people refer to the “humanities,” I think I know what they mean: those disciplines that are concerned with human activity and everything it produces, and take as their task both to preserve and transmit that culture on the one hand, and to understand and interpret it on the other. But what is the sense of qualifying that noun with the adjective “digital”?

In the twenty-first century, the phrase can’t really stand in opposition to an implied “analog humanities”: no such thing exists. (When was the last time anyone submitted a hand-written or manually typed manuscript to be edited with grease pencil before being manually typeset with hot lead?) “Digital humanities” refers instead to scholarship in the humanities that consciously takes account of the fact that we all work digitally now.

What troubles me is that our use of the marked term “digital humanities” implies that the unmarked term, “humanities,” is being used to refer to scholarship that does not reflect on the media we all work in (a usage that is sadly accurate in the academy today). I am particularly disturbed because I would like to imagine that an education in the humanities encourages the kind of critical self-awareness that would enable us to think more meaningfully about our relation to the environment we live and work in, including our technological environment and the ways it is interwoven with our institutions and values.

By using “digital humanities,” we’re allowing the term “humanities” to stand for an uncritical scholarly practice that is at odds with the goals of a humanistic education.

cargo cult planeI can understand why there is not a spontaneous groundswell of support in academic departments around the world for a term meaning “work that unthinkingly perpetuates obsolete forms of scholarly practice,” or “scholarship that is oblivious to the media we use today,” but rather than accept without reservation the marginalizing label “digital humanities,” I’ll offer my own suggestion. We could extend Richard Feynman’s “cargo-cult science” to “cargo-cult scholarship” more generally, and refer to the “cargo-cult humanities.”

Sunday, January 29, 2012

“Digital natives”

I recently attended a workshop at my home institution where I heard teachers confidently assert that today’s students are so adept at technological tasks that we can rely on them to help their older teachers develop important technological skills.


For more than 15 years, I’ve introduced Classics students at Holy Cross to XML markup. To build on any prior experience they might have, I routinely begin by asking who has ever peeked behind a web page to view its HTML source. Fifteen years ago, I would usually find anywhere from a quarter to a half of the students would say yes. Today, if I ask a group of 20–25 students, I will get one or two “yes” answers.

I do not know if my students were telling me the truth fifteen years ago (or today), but that doesn’t much matter for my present point. Fifteen years ago, far more students either had seen HTML or felt some kind of pressure to pretend that they had.

What does it mean? I suspect that the “digital natives” I teach have indeed grown up so familiar with information technology that they are more oblivious to it than their elders. I worry that they are also incurious, or at least need to learn to be curious about it.

My personal experience makes up only a limited sample, of students in Classics at a small liberal-arts college, but the trend among those students is very clear. Unless someone can show me better evidence, I’ll remain very sceptical about a priori assertions concerning the skills that “digital natives” will confer on their teachers.

Note: new tags

I’m using a couple of new tags on this post: “sceptical” (for obvious reasons), and “yam” [yet another meeting] to help me find posts responding to ideas I’ve gathered from yammering at meetings. I hope to post soon on a couple of additional “sceptical” topics, and several “yam” topics (since January is a big month for meetings in the academic world).