Digital humanities holds the promise of increasing the means by which scholars are able to analyze and present data. Though some sentiments about the significance of digital humanities might be overblown, there is no doubt that the more ways we have to analyze sources the better. Learning a variety of the tools that make up the rather nebulous universe of digital humanities is like learning a new language. It opens up new possibilities that were previously closed or necessitated the expertise of others. This frames digital humanities as a collection of skills rather than a means to a predetermined end. I have adopted this perspective in learning about the possibilities opened by digital humanities and working on a digital humanities project. I am hardly the first person to take these steps, but I hope that by explaining my thought process I can set a basis for future posts on digital humanities.
If there has been one guiding force in my approach to digital humanities, it is to learn skills and tools in the process of production. In a way, this is simply the application of critical thinking to how I create my scholarly work. Instead of doing things in what seems the de facto manner, I have sought to question if there is either a more efficient way or a way in which I could gain or improve my competency. The goal of efficiency was particularly significant in thinking about how to organize my research and writing (DH 1.0), while learning new skills has been more important in the production of digital humanities projects (DH 2.0). This may not be the easiest way to complete a project in the short run, but by doing things the hard way, I am looking to open up new opportunities for future projects. With this theoretical approach in mind, let me now discuss a few concrete principles of my digital humanities practices concerning text, applications, and producing digital humanities projects.
At the basis of all my research is the use of plain text, which I usually write in Markdown. All of my research notes are in plain text, and I wrote drafts for over half of my dissertation in plain text. Writing in plain text has a number of advantages — which I will discuss in a future post — but an unexpected benefit is that writing Markdown changed my approach to text in a way that gave me a solid basis to tackle HTML, CSS, and even coding.1 In addition, Markdown is ubiquitous on the web. This blog post is written in Markdown, and I have made interactive visualizations with R Markdown, an extension of Markdown for R.
Of course, plain text by itself only gets you so far. The power of text has to be harnessed by applications. A major turning point for me in the efficiency and power of my research workflow was the realization that investment in apps, in terms of both money and time, could provide long-term benefits. Using free apps is definitely nice, but if you consider how many hours you spend in an app that plays a significant role in your workflow, the investment is usually worth it. I have come to have real enjoyment in using certain apps. I also think that is is worth while to take some time to learn how to use each app efficiently and even to learn some history about them. There is nothing worse than adapting to a new app only to learn that it is no longer under development. Though there are exceptions, many of my most essential apps have long histories and a solid base of users that points towards continued development.2
In terms of the tools and choices I have made in the production of digital humanities projects, I have almost always chosen in favor of more control and customization over plug-and-play options. This goal is often in parallel with choosing to use open standards — with plain text being the ultimate open standard — and open-source software, which for me has come to include the use of programming languages such as R. Complete control and knowledge is certainly not possible, at least not for me, but more control goes along with my goal of learning by doing. This website is a simple example of this approach. I was never going to be able to make this website by hand, but instead of using perfectly good ready-made solutions such as Squarespace or Wordpress, I decided to make a static website using Hugo. Plug-and-play approaches may satisfy the visualization aspect of digital humanities, but they often do little to improve your skills, or at least they are not extendable in the same way that coding skills are. When faced with a decision about how do something for a digital humanities project, I often see an easy way and a more complex route. My approach has been to choose the more complex route. This way is often not overly difficult if you know what to do, but I usually do not have that knowledge, and so the process is slow and arduous. However, the goal is that in completing the task I learn a new set of skills or improve those I already had, making it possible for me to use them in future contexts.
Markdown is essentially a simpler way to write HTML. It is very approachable, but it still has the basic structure of all markup languages or code in the need to properly structure the markup. If something goes wrong, it is almost always because you mistyped something. ↩︎