What does a code-focused digital dissertation look like when it's done? And without chapters to divide the work ahead of you, how do you keep your doctoral research on track? I'm sharing the list of deliverables I'm creating for my dissertation, as well as some practices that have helped me keep being excited about my project and eager to continue my research.

Digital deliverables

My dissertation is currently divided into three major coding projects: "Infinite Ulysses", "Choose Your Own Edition", and "Material Editions" (Note: I successfully defended my digital humanities doctoral dissertation in Spring 2015. The now-available Infinite Ulysses site is part of that project.). The coding and design in this dissertation is scholarly work exploring how digital interfaces effect our use of textual editions, so I will not be doubling this critical effort by creating the traditional monograph-length written work alongside these scholarly digital objects. There will be lots of blogging arising naturally out of the process, though, and I'll be polishing these blogs into three articles aimed at scholarly journals.

Since there are few if any examples of delineated digital dissertation workloads out there, I'm sharing mine both as a guide for other dissertators and as an example to show your advisor or department when attempting something similar (as this workload does come with the approval of my advisor, committee, and department as adequately fulfilling the requirements of a dissertation). My completed dissertation should consist of the following components:

  1. A written introduction to the entire dissertation’s methodology, research questions, theoretical grounding, and goals. Length estimated at 20 pages, with much of the theoretical discussion specific to each of the three projects held over to those projects’ individual introductions/about text on their websites. (Most of this written foundation was completed through my 18-page prospectus and early dissertation blogging, but I'll need to rework portions of that writing after all the work is done.)

  2. For each of the three coding projects, a scholarly, article-length (30-60 page) write-up aimed at future publication, drawn largely from blogging during the code, design, and testing work on each project. Each article will include:

    1. a literature review situating the coding project as building on a tradition of editing and literary theory

    2. a history of specific scholarly precedents in both print and digital space

    3. research questions for the project

    4. a rationale for any technical choices

    5. curated selections from academic blogging completed during the building process (to record scholarly considerations as the code progresses)

    6. results of a short quantitative and qualitative user study matching real scholars and students with the tool, plus next steps suggested by these results

  3. A link to a public repository containing the code for the finished projects, as well as a sandbox website(s) where the tools can be explored in either working or prototyped form

  4. A written conclusion on the theoretical and practical successes, failures, and next steps for the overall dissertation project (length estimated at 15-30 pages)

Blogging!

Blogging twice a month splits the brunt of content generation up over the entire course of the dissertation; this regular writing also helps me generate some interest in my work, get feedback and feature requests during the initial design phase, and feel accountable to my self-imposed schedule.

In terms of getting writing done by typing small amounts regularly throughout my coding work, not having a huge stretch of writing waiting for me at the end of each project is nice, but even better, capturing what I've been thinking about during each stage of the process will render my final record more accurate (and useful to other dissertators) than trying to remember what the process felt like, where I got stuck, and when I was struck with new ideas. Because the process of critical building is as important as the product, using the blogs to set down and recognize how things are going before a final debriefing helps the entire process truly be a critical one.

Pseudo-agility

While working on a Braille translation plugin for Making the Digital Humanities More Open, MITH's Software Architect Jim Smith taught me some elements of a work process drawn from agile software development that have been a great help in organizing my dissertation work and keeping the dissertation from (thusfar) being a stressful process. One of the techniques Jim shared was a way of scheduling work that kept priorities on the top of the work pile, while also allowing breathing room, preventing late-nighters, and otherwise recognizing human limits. With my dissertation, I've applied this technique by

  • setting monthly milestones (what tasks could reasonably be done by the end of the month?);
  • prioritizing tasks by several degrees of importance (helping me identify what things I should expend extra energy to finish if they're not complete at the milestone, and what tasks might end up being out of the project's scope—a real help with a project that has so many possible features!); and
  • breaking work into sprint-like microtasks by assessing the difficulty of each task, estimating the time it will take to complete (and then often multiplying that by two), and making sure each task fits into at most four hours of work (if something sounds like it will take longer than four hours, it needs to be broken into smaller tasks).

This process helps me have a sense of what needs to be complete by the end of the month for the project to move on, and what things would only be nice to have finished by that time (and if they're not, they get dropped, not pushed into next month's task list and making it even bigger and less manageable). I'm sure there are other great ways to organize your dissertation tech work (true agile development, for example)—but these three steps help me regularly reassess my work as well as regularly reward myself for my work through free time: if I finish all my assigned tasks in a week, I stop working on the dissertation and do something else until the next week starts (well, that only happens sometimes—I'm also a fan of frontloading a month's work and then taking a bigger chunk of time off at the end of each month, but I only do that when I'm really enjoying the work and don't need the break).

Don't plan ahead too minutely: take your work a month at a time

You can create major monthly milestones for your entire project by setting a few very top-level goals, but don't spend time elaborating on the sub-tasks of later milestones; these will have changed by several months into your project and aren't worth spending time on right now.

While finalizing my prospectus, I did lay out a month-by-month schedule of tasks to make sure everything seemed to fit: could I time a beta release of my site to coincide with my MLA presentation/demo? was there enough time at the end of each project to not only conduct user testing, but do further code and design work in response to the tests' results? I was able to arrange the three projects so that I could spend one year on the first one (Infinite Ulysses, both the most ambitious project and the project that should be most polished by my defense), with half a year on each of the other projects allowing me to create prototypes, but not necessarily stand-alone unbreakable final products. After that initial check as to the reasonableness of my ambitions, I've focused my planning time just on that first project. At the start of each month, I plan what I want to have completed by the end of the month, adjust the monthly task list accordingly, and label my tasks by difficulty and priority. (Using TaskPaper for my private dissertation timeline is great because I can tag tasks in a variety of ways and pull them up accordingly. Just enough time for an easy task? Command-F "@easy".)

Public versus private timelines

I haven't announced a public timeline for release of my work yet, and don't plan to until I can see the end of the tunnel in terms of pushing the Infinite Ulysses site live. Digital work forces additional variables into the already mutable timeline of dissertating: I want to advance my technical skills with this research, so I'll be doing some things code-wise that I haven't done before and don't know how long they'll take; the time it takes to recruit site testers, run user testing, and respond to the results is unclear; and I might have so much more I want to do by the end of this first project that I decide extend it into the second year of my dissertation. One of the nuggets of tech-planning wisdom Patrick Murray-John gave the One Week | One Tool team was to give the public some indication of your plans for a project, but make that timeline much more high-level than the internal schedule by which the work actually gets done. Once the Infinite Ulysses site goes live, I'll post my plans in terms of taking feedback and adding requested features, but before then I'm reserving the right to take as much time as is needed to do a fantastic job. (Release hint, though: it'd be awful nice to have a beta site live when I present on the Infinite Ulysses project at MLA 2014...)

Keep your mentors in the loop

I've shared a GoogleDoc containing my monthly timeline (created while polishing the dissertation prospectus (A prospectus is a dissertator's written plan and rationale for her dissertation, submitted to both committee and department at the start of her work: both a roadmap and a promise)) with my advisors. While I was was out of state over the summer, it was a way to give them a sense of what I'm doing in a given month, since instead of the traditional "writing/editing a chapter" I might be messing with a local server, writing new code, designing a site, writing and running user tests, blogging... and since I leave tasks on the timeline but strike them out when they've been completed, it's a nice way for me to look back and see what I was doing at a given point (and feel a little proud for everything I've already done towards the dissertation). The shared timeline also gives me just enough of an accountability reminder that I think very hard about putting off tasks assigned for the given month.

I successfully defended my digital humanities doctoral dissertation in Spring 2015. The Infinite Ulysses social+digital reading platform that was part of that project has been retired into an archival form: a static site with a slideshow tour of past interactive features.