Paige Morgan

June 5, 2014
by Paige Morgan
1 Comment

How to get a digital humanities project off the ground

At DHSI 2014, participants requested an unconference session on how to turn a digital humanities project from an idea into a reality, and I offered to lead it. Here, roughly, are the steps that I recommended. A few are relevant chiefly to graduate students; most are applicable to academics at nearly any level. Some of these are applicable for large projects, more than smaller ones, but many apply to both. My experience comes from my work with two ongoing projects, Visible Prices (VP) (a database development project that I imagined in autumn 2009), and Demystifying Digital Humanities (DMDH) (a DH curriculum development project that I began with my colleague Sarah Kremen-Hicks in 2012).

When I began VP, I was told that it wasn’t possible; this year, I received a small project grant from the European Association for Digital Humanities to keep developing it. DMDH has just been renewed by the UW Simpson Center for the Humanities for a third year, and Sarah and I have been joined by a third collaborator, Brian Gutierrez. (I could hardly ask for better team members to work with.) Everything below I have learned through working on both of these projects.

1. Don’t be too quick to make your project part of your dissertation. There are a number of reasons for this, and factors to consider when you’re deciding. I’ve written about these previously over at Demystifying Digital Humanities. Perhaps most important are the following:

  • It’s risky to set up completing a project (or even a prototype) as a requirement for graduation if you are new to working with computing technology and/or if you don’t have an absolutely clear path to acquiring the skills you need.
  • A digital project can be very useful because it’s something different from your dissertation, and an activity in which you can mess around — but making it an official part of your degree often turns it into something serious; one more thing to feel bad about because it’s on your to-do list.
  • Having a second project to talk about on your research agenda (and in interviews) as something that you’ll be working on in the future is a positive thing: a feature, not a bug.
  • Is there a compelling reason that your project must be a major part of your dissertation? A reason that it needs to be? If so, then you have things to think about; if not, don’t make your life more complicated than it already is.

Continue Reading →

June 3, 2014
by Paige Morgan
Comments Off on How do you solve a problem like doctoral education in the humanities? (Part 1)

How do you solve a problem like doctoral education in the humanities? (Part 1)

Last week, the MLA Task Force on Doctoral Study in Modern Language and Literature released its first report of its findings. I have been looking forward to this report since I knew that it was in the making — it is good that it exists. However, I am conflicted about its content, which I find great and problematic in equal measure. Before I explain why, I should say a little bit about my credentials in critiquing the report.

Next week I will defend my doctoral dissertation and graduate with a Ph.D. in English from the University of Washington. It will be the end of my tenth year of graduate school (including the M.A.). I am very proud of the dissertation, which is quite traditional, rather than being digital or even digitally-inflected. However, the dissertation is one of three current major projects that I expect and hope to continue working on throughout my career.

The first of those projects is Visible Prices, a digital humanities database project that I have been working on since autumn 2009. My main project website is here, at http://www.visibleprices.org; but for a useful précis and demo, I recommend a version of the project that I built in USC’s Scalar platform.

The second is Demystifying Digital Humanities (DMDH), a series of workshops that provide an introduction to DH practices and methodology. The workshops are primarily for graduate students at the University of Washington, though we have had faculty and staff participants as well in the past two years. DMDH is funded by the Simpson Center for the Humanities, and supported by invaluable encouragement from UW-IT, UW Libraries, and faculty and staff from several offices. I developed the workshops with my colleague Sarah Kremen-Hicks, also in the English Department; and this year we have been joined by a third team member, Brian Gutierrez, also of English. Yesterday, we learned that the workshops have been renewed for a third year. Together, we help our workshop participants start learning, or often, start discovering how to learn about the digital humanities (from scholarship that incorporates technology in a minor way to projects that are fundamentally digital, and would be impossible without computing techniques.)

I mention these two side projects in order to explain that I am, as I understand it, the sort of graduate student who might well be very excited by the MLA Report, were I embarking on my dissertation, rather than newly finished with it; and also because I have experience with precisely the sorts of projects that the Task Force is recommending be considered as alternatives to the dissertation.

I saw two problems with the report: one is a matter of framing; the other is a matter of logistics. While separate, they do intersect, as I will explain. This post is primarily about framing; I hope to have to post about logistics up later this week, though I am currently at DHSI and prepping for my defense, so it may appear shortly after June 10th. I have been reading and annotating the report, and in the interest of transparency of interpretation, I am making my annotations available via DropBox for anyone who might like to examine them.

Continue Reading →

May 30, 2014
by Paige Morgan
1 Comment

Thoughts on the factors that contribute to a lengthy dissertation process, and on impulses to reform by changing the diss.

I wrote the essay below on October 22, 2013 after attending a workshop on Impostor Syndrome and Assertiveness at the Seattle Attic feminist makerspace. The discussions during that workshop helped me realize some of the reasons that contribute to the length of time it takes to complete a dissertation; and made me think that reforming/dramatically changing the format of the dissertation was not necessarily an effective way of shortening/solving the “problem” of time to completion. It is important to say, I think, that I wrote this happily, rather than out of anger; and I wrote it because I like thinking about infrastructure systems, and how people navigate them. I hope that in whatever sort of career I end up in, I am able to do more of that sort of thinking.

I’m posting the essay here and now because it’s related to another essay that I’m working on, responding to the MLA Task Force Report on Doctoral Study in Modern Language and Literature. In many ways, I think that what I have to say complements what the Task Force is recommending, especially regarding the acknowledgement of multiple forms of scholarship, and what I interpret as the need for more opportunities for graduate students to present their work.  My approach tends to be more one of systems/ecology analysis than that of the task force; or in other words, I see the question of emotional energy as central to the problem of time to degree. I interpret the Task Force’s approach as focusing on the (in)compatibilities of the dissertation with the current careers available. Those (in)compatibilities are an excellent set of issues to explore; however, I think that they (and the issue of time to degree) are more complex than simply changing the format of the dissertation.

Disclaimer: These are my thoughts, based on my experiences, and conversations that I’ve had with other graduate students, and things that I’ve read. Some of them (like point #4), are not new, or unique to me. My experience and perception is necessarily limited, and it’s important to me that I avoid positioning my perceptions as more valid or important than anyone else’s (especially other graduate students). Posting this essay led to a long discussion between several of my readers; I may publish those comments, because I think they’re smart and useful, but I need to check with the authors about whether they would prefer for them to be kept anonymous.

——-

1. Conversations that I have seen about reforming the dissertation only occasionally seem to involve input from graduate students about what makes the experience and completion difficult. That lack of dialogue renders all such discussions (that lack dialogue with graduate students) about reforming the dissertation at least partially suspect. Avoiding graduate student input/dialogue is not just infantilizing towards the graduate students, it is terrible problem solving.

2. The problem of the dissertation is a problem that involves the relationship between graduate students and their professors. This relationship is not auxiliary to thinking about the dissertation; it is central.

3. The questions of “why does it take graduate students a long time to finish the diss?” and “is a dissertation still valuable within the structure of academia today?” are two separate questions.

These two questions can be related, that is, you can hypothesize that one factor contributing to time to completion is anxiety about whether the dissertation will have value within the structure of academia today — and you might well be correct. However, too often, these questions are treated as inseparably linked — and to treat them as inseparably linked disappears several other factors that are involved.

4. Anxiety about the utility of the dissertation is not merely about graduate students and time to completion, or about the academic publishing industry, and the “fitness” of the dissertation genre within that industry. It is also about graduate faculty’s sense (and uncertainty) of their own responsibilities and capabilities in the wake of changes in the academic environment and in regards to shifts in print/electronic culture and media.

5. Hypothesis: the problem is not so much the genre of the dissertation as uncertainty about what it is supposed to accomplish. It is caught between the goal of meeting the requirements for graduation (and foreshadowing meeting requirements for tenure); and demonstrating competence within a discipline.

Continue Reading →

May 27, 2014
by Paige Morgan
Comments Off on Useful information if you’re attending DHSI

Useful information if you’re attending DHSI

Roger has put up a great post about his standard DHSI kit, and I wanted to make my own contribution of practical info if you’re coming this year. The following are all things that I wish I’d known in advance, or discoveries that have made my life at DHSI easier. I have a wheat/gluten allergy, so some of the information below may be useful if you, too, are dealing with food allergies.

Keeping track of impromptu events

Even if you don’t use Twitter much, following the #dhsi2014 hashtag is a great way to see what’s going on, and you don’t even need a Twitter account to do it. Just go here, and select “All”, rather than “Top” to see the most recent tweets. People talk about what they’re learning in their workshops and in events, but they also make plans to grab lunch or dinner in groups, or visit yarn shops (or shops pertaining to whatever particular interest you might have).

Likewise, if you want to start an impromptu event (last year I organized a yarn store trip), Twitter’s a good place to do it — and if you don’t have a Twitter account, and really don’t want one, get someone else to start it for you.

Getting downtown

There are several buses that go between downtown and UVic, and the ride takes about 15-25 minutes depending on the route. Bus fare is $2.50, and I find that one of the easiest ways of avoiding needing exact change is to pay for a friend with a fiver, and have them pay on the way back. For reasons I’ll get into below, you’ll definitely want to go downtown.

Useful supplies

If you’re staying in the cluster apartments and haven’t paid extra for them to be stocked with kitchen supplies, then you may want to bring a few vital essentials from home (last year I brought a pour-over coffee set-up; this year, I’m bringing a bottle of coldbrew coffee concentrate). Plastic food containers can be very useful too, if you’re planning on packing your lunch; so can an insulated lunchbox and icepack (or ziploc baggies to make simple icepacks using soda machine ice). Lunch lines can be very long indeed; thus the value of the insulated lunchbox and icepack (which can allow you to grab something during a workshop break and store it for later).

Food (places to get it, etc., food allergies, etc.)

There’s a small grocery store (Peppers Grocery) down at Cadboro Bay (i.e., within walking distance from campus), as well a Starbucks Coffee –the grocery is open till 9 on weeknights, but closes early (7:30) on Sunday evening.

My experience with the UVic campus dining options at lunch has been generally good: they have several gluten-free options both for entrees and snacks; however, the on-campus dinner options are less good (or were last year) — the on-campus pub doesn’t have a dedicated GF fryer. You’re better off seeking out your evening meals downtown. Really, this is true for almost anyone: Victoria has really nice restaurants! If you’re looking for vegan restaurants, try this listing (The Victoria Vegan); if you’re gluten-free, try this one (The Celiac Scene). My personal favorite GF/vegan venue is Origin Bakery, which is a 10-15 minute ride, depending on which bus you take (the 4, 11, and 14 are all good bets). It has delicious baguettes, eclairs, and tarts, all GF — and mostly vegan — and they’re delicious. Sadly, it’s closed on Sunday and Monday, but you can bet that I’ll be making an early trip on Tuesday morning.

Do all the things! Or don’t.

It is so tempting to try and do everything, but truthfully, unless you have the energy level of a 7-year old, I don’t think it’s possible, and come Wednesday or Thursday night, I usually feel too exhausted to make intelligent conversation. So: pace yourself. (I say this even while encouraging you to suggest an unconference session over at the Google doc.)

See you in Victoria!

May 27, 2014
by Paige Morgan
Comments Off on What I learned while finishing my dissertation

What I learned while finishing my dissertation

Now that I’ve turned in the dissertation, and while I’m prepping for the defense, I think I need to spend some time actually processing it — publicly, as well as privately. This is the first of what I anticipate will be a few posts doing so.

My dissertation director’s most common response to my work at this point is to say that my writing is highly condensed. At the beginning, hearing that was very confusing, because I didn’t feel like I knew how to unpack, or uncondense, without becoming unclear. Now I’m more able to do that — which is to say that I hope to say more about all of the following topics at greater length in the coming months, and identifying them here is the first step.

A minor, but important disclaimer: the following are true for me. I strongly suspect that they are true for some other people as well, but probably not true for everyone, and I don’t want to imply otherwise. (There are way too many articles generalizing from a single person’s experience to many, and they cause more trouble than they’re worth.)

1. Laying the groundwork to help readers understand an argument is just as important as presenting the new/flashy/sexy content. It took me a long time to grasp this — and then, having grasped it, to understand what it meant I needed to write. And the dissertation really is about groundwork for a future book, or for future articles. Without explaining the groundwork, it wasn’t merely difficult for my chair to grasp my argument’s significance; it was also difficult for me to feel confident enough to be assertive — not to mention that my discussions tended to be so tightly focused on a single work that I couldn’t telescope between the single work and a bigger picture.

A friend in the department thinks that this is because grad students are often trained to tear down structures to find a single kernel of knowledge, and close read with such intense focus that they have trouble putting information together to build a larger structure, i.e., a dissertation. I suspect she’s right. I also think that the practice of writing conference papers/abstracts and even seminar papers often leads students to always strive to be exciting, when in fact, a dissertation’s content is hardly meant to be one flashbulb of excitement after another. It can’t be — and if it were, it probably wouldn’t be good preparation for a book.

 

2. I feel more confident as a writer when I’m writing in a semi-public/public space. As a result, one of the most important components of figuring out chapter narratives was talking about them on Facebook to anyone who cared to listen. Usually, this took the form of me posting a status update like this one: “I’m going to natter on about William Shenstone and merit in the comments below; feel free to interject or ignore as you like.” Sometimes people would join in and ask questions or say that things sounded interesting as soon as I started; other times, I was essentially talking to myself. The fact that I knew that people might be following along was incredibly useful for helping me think about how my information needed to be arranged — and that was singularly important as I figured out the genre of the 50-page chapter, as opposed to the 8-10 page conference paper or the 15-20 page seminar paper. I also think it helped me remember that even academic writing is still meant to communicate with other humans, and to find a balance between dry-as-dust and, well, writing any of the highly emotional internet dialects. Marshall Brown was an excellent mentor to have in terms of writing voice, because he’s so good at it — and I spent plenty of time looking at his signposts and asides — but being able to post on Facebook was how I really started to find my own voice.
 I think that this is why no writing group ever really gelled for me — my few brushes with them involved reading each other’s writing, and for me, talking things out live was almost more important. And indeed, it helped that Facebook allowed me to extemporize, but to do so in a way that left a record behind.

 

3. Agency matters. I’ve spoken about this elsewhere, and I’m planning to say even more before too long. I doubt I would have ever finished this dissertation had it not been for my involvement with the Demystifying Digital Humanities project, which gave me a considerable amount of agency. Even though the dissertation and DMDH are completely separate subjects. Early on in the dissertation, I didn’t really understand that I lacked agency — mainly, I knew that I was terrified. Specifically, I had a hard time imagining myself as making a meaningful contribution to academic knowledge. That fear wasn’t simply about my grasp of eighteenth-century poetry. It also grew out of the visible general anxieties about academic publishing, the job market, and uncertainties about departmental responsibilities.
Put simply (because I know I have more to say on this!): The worse the job climate and the more confusion about the role of the university, the more fear; the more fear, the less agency; and the less agency, the harder it is to write.

 

4. Academics can be harder on themselves than is helpful. One of the most reassuring pieces of writing advice that I received from a committee member was that the format of a chapter could be, essentially: “I’m going to explore topic x from three perspectives; 1; 2; 3; by doing this, I have learned/shown that …” In this format, being overly simple is absolutely essential. And it’s a great format, not only for collecting and laying groundwork, but also, for helping graduate students become comfortable with the genre of a chapter. Being told that I could keep things simple and easy helped reassure me — and the end result was that I was able to delve into some fairly complex material.
My graduate program doesn’t currently have written guidelines for what a dissertation chapter looks like. I’m fairly certain that if we did, then nowhere in them would be advice that graduate students keep any aspect of the diss simple and easy. But rigor can be counterproductive. That’s not only true for departmental guidelines, but for individual writers as well, and learning how to articulate what will make you happy, rather than simply setting astronomical expectations, is an important skill.

5. I am able write my way out of seemingly impossible situations in my research. There have been several points in the last few years — some in the last few months! — where my arguments and data have seemed to be in an impossible tangle that I feared would never resolve itself. I have felt as though all my efforts to break up information into manageable portions that would be clear to readers were useless, and only making things worse. Those moments (those small eternities) are utterly horrid. And I have discovered that I can get through them. I don’t usually get through via sudden egress or a Eureka! moment — at least, not right at first. Instead, I find one small point to focus on, and then another, and another, and so on. Sometimes there’s eventually a lovely flash of sudden insight — but it might come a few weeks — or months — after I trudged through the horrid part.

As strange as it might seem, I’ve come to appreciate — to treasure! — those small eternities, because they have become my adamantine certainty that I am able to handle challenging subjects. I know that now in a way that transcends merely typing the words in the previous sentence. It is part of my identity — as much a part as any of the specific knowledge that I’ve gained about eighteenth century poetry and economics.

A while ago — I’m not quite sure when, or where — I heard an anecdote that culminated in the phrase “Commit, and the rest will follow.” When I heard it, my first thought was “yes, but how do I commit? I’m already writing daily, and I’m not sure I’m getting anywhere.” Now, having finally finished the dissertation, I think that being able to reflect on the most rotten parts of the process was what made that commitment possible. I suspect that my memories of the rotten parts might even be more important than the praise.

 

6. Write things down. Keep records.  I don’t mean back up your research in six different places (though you should!). Instead, this is a convenient way of ending this post, because in a few months, in a year, in ten years, I may well need to be reminded of any and all of these things, whether because I’m working on difficult tasks, or mentoring people who are. More immediately, though, identifying these insights is a way of choosing what I want to write more about. There are so many topics — but I can’t commit to them all, and rather than letting them swirl around me like gnats on a warm evening, I have to choose. And knowing what I have chosen allows me to move forward, and choose more.

March 27, 2014
by Paige Morgan
Comments Off on Where you can find my posts

Where you can find my posts

My dissertation defense date has been set, and I am busily making final revisions. As a result, my online activity is fairly light, and will continue to be light until mid-June.

You can find more information about what I’m currently up to at the website for Demystifying Digital Humanities, or at my site documenting my ongoing progress with my Visible Prices project.

November 20, 2013
by Paige Morgan
Comments Off on On training undergraduates for work in the digital humanities

On training undergraduates for work in the digital humanities

This morning I visited Walter Andrews and Stacy Waters, who run two digital humanities projects at UW — the Svoboda Diaries Project, and the NewBook Digital Text project. I knew I was coming for their team’s weekly meeting, but I wasn’t really sure what to expect; and I was kind of stunned to find teams of undergraduates (with a few graduate students) conducting a highly professional runthrough of the work that had been done on each project: the rate of transcription; what problems were being encountered; how Autotagger (an application that they had built in collaboration with a computational linguistics grad student) was working; etc. I’d had no idea that the project was in place, or that it had grown to have a staff of 15-20 student interns who were having the ongoing DH experience that, frankly, I think many graduate students in DH only *dream* of having.

One of the undergraduates is a sophomore history major, and considering double-majoring in history and computer science; and a number of the interns are interested in doing DH work. Walter had asked me whether I had any thoughts on whether a CS major was necessary — and I did. But I also wanted to ask Twitter; and as you might expect, the answers I got were better than the ones I came up with on my own. My view is that a CS major certainly isn’t vital for undergraduates who want to do DH. It’s not that it doesn’t provide useful knowledge — but not all of the knowledge that it provides will be directly applicable to work in the digital humanities. Thus, it’s an investment with a high cost, and a smaller return — at least in terms of doing DH. It’s really hard to know what kind of programming skills you’ll need if you don’t know what kind of DH work you want to do — so my advice would be to take 1-2 introductory programming classes. That would provide you with an intro to what working with code is like — and with that, you would be better equipped to make decisions about what you needed to learn. I suspect that for a lot of DHers, you only start figuring out what you need to know when you have or join a project — so potentially, that might become clearer in graduate school — if you’re planning to go. But really, so much depends on the individual DH student, and their interests, and their particular learning style. I learn better face to face, but my Intro to Java class has helped me make progress with online coding tutorials.

Scott Weingart’s suggestion of which classes to take seemed very sensible — to me, and to numerous other people — so I passed that on to the interns.

 

I also emphasized that CS wouldn’t necessarily help them develop interesting humanities research questions — though I think that there’s a sweet spot between having enough humanities knowledge to develop good questions, and having enough programming knowledge to be able to envision how one might use computing to answer those questions.

I also told them that they were already doing perfectly valid DH work — that in some ways, their CVs would probably look stronger than mine. I can’t claim to have whole years of experience doing coding and transcription within a larger project, after all.

I was curious about how they would respond. “I guess I’m a little bit uncertain about what DH is,” said one student. “Is it using computing to analyze and critique texts and projects, and making texts available online?” I replied that yes, broadly, those are two major areas of DH — though that within those areas, there’s a great deal of variation. And also, that people are constantly coming up with new angles and new areas. I didn’t mention pedagogy — though I should have, and I will next time I visit.

It makes sense to me that undergraduates would feel this uncertainty about the field, and how they fit into it. Even graduate students experience that sense of confusion — and graduate students are (in most cases) better equipped to see themselves as producing new work, and new projects, than undergraduates are. Both Walter and I emphasized the importance of articulating what you’re interested in doing, and why; and figuring out what you need to learn to do that. That type of DIY approach to learning seems to feel foreign to a number of humanities graduate students. (Will a CS major help you develop that approach? It might; but so might many things.)

The interns’ other main response to my Twitter feed’s collective advice was to wonder whether a graduate degree was necessary to do DH. I don’t think it is, and I said so, and was able to cite at least a couple of job listings I’d seen recently that didn’t require a graduate degree; and places where DH skills (meaning a mix of tech & humanities knowledge) would be applicable. On the other hand, for a lot of people, doing DH means getting project experience — and it can be hard to do that without being enrolled in a graduate program.

I find both of their responses fascinating — and I hope to write more about them, and my thoughts, later on — but my schedule is packed enough this week that it seemed important just to get them out here for the larger community to see.

If you’re reading this, then please feel free to comment — what do you think would constitute good preparation for undergrads interested in DH work? And how might we effectively teach them about the variety of DH projects, and teach them without suggesting, either explicitly or tacitly, that the only way to do DH is to go to graduate school?

 

 

 

 

 

October 15, 2013
by Paige Morgan
5 Comments

RMMLA Panel on Digital Humanities Microclimates: Demystifying Digital Humanities

I was fortunate enough to be invited to speak on a panel at the annual RMMLA meeting in Vancouver, WA, last weekend, along with Dene Grigar, Roger Whitson, Daniel Powell, and a cameo by Ray Siemens.  This is a slightly cleaned-up version of that talk. If you’d like to hear more related to the panel, then I recommend Daniel’s write-up at his own site.

On Demystifying Digital Humanities, at the University of Washington

I teach the Demystifying Digital Humanities (DMDH) workshop series at the University of Washington. This series includes six 3-hour workshops over the course of the school year, providing an introduction to digital humanities and multimodal scholarship, and some of the activities associated with digital humanities (DH) — professionalisation through social media, working with code, and project development. They take place on Saturday mornings, over breakfast. This is important, for reasons that I think will become clearer as I continue.

Our target audience is humanities graduate students, but we’ve also had attendees who are faculty and staff, and our participants are from at least 14 different programs at UW. We’re in our second year, and things are going great.

However, this program isn’t accredited, because I founded it with my colleague, Sarah Kremen-Hicks, and we’re PhD students. This year, we’ve added another PhD student, Brian Gutierrez, so we’re a team of three. We started the program with funding from the UW Simpson Center for the Humanities, and the Textual Studies program, because the UW doesn’t yet have an official course, certificate, or program in digital humanities. And 1), we wanted to do digital humanities, and make it a significant part of our careers; and 2), from our perspective, what it would take to get a digital humanities program started would be for more people at UW to do DH, and demonstrate that it was a real and tangible thing, and not just a bunch of headlines in the Chronicle.

So, we had a tiny little microclimate, in the form of the Simpson Center’s interest in DH, and some encouraging faculty sponsors from several different departments. That was enough to get us started, and we’re currently still working on cultivating the landscape to support DH growth.  That has several implications, which I’ll explain:

First, it means that one of our primary goals is working to develop our students’ agency to pursue DH studies on their own. With 6 hours per quarter, we don’t have space to teach a traditional seminar length curriculum. Instead, we focus on providing material that will help them understand some of the activities and motivations that drive digital humanities practice and scholarship, so that they can create their own training plan. It turns out that this is useful as scaffolding, and in no way a waste of time. There are lots of PhD students who don’t instinctively turn to what I call the Google firehose to get started in doing digital humanities. I don’t blame them, either — in fact, I think that there’s a sense in which they’re arguably smart not to just go searching on their own, especially if they aren’t overly familiar with information literacy. The problem isn’t that they wouldn’t be able to develop an idea of what digital humanities is — it’s that it could take a long time to do so; and I don’t blame them for being wary of that investment. Our job is to give them incremental building blocks that they can take, and transform, as needed, for their own studies. Many of these building blocks are assumptions that people who are active in the digital humanities are already highly familiar with — and so the assumptions tend to be less visible in everyday discussions. One way that we’ve tried to make those assumptions more visible is through a set of twelve values, which, together, describe the ethos behind digital humanities.

Second, it means that we have certain constraints. We avoid assigning readings, because the majority of our students are already carrying a full course load, and teaching. We can’t make this a stealth 5-credit seminar for which they don’t actually get credit. Instead, we send out email teasers, in which we often highlight one paragraph, or even one sentence, from an essay or website, and we teach using that. I’m the one who sends these teasers, and I really try to avoid anything that looks like homework. If I give people homework, then there’s a good chance that at least some people won’t have a chance to do it. The last thing that I want them to think is “Oh, I didn’t find time to do x, so I can’t participate in the workshop on Saturday.” I don’t want to set up a barrier where doing homework, or reading a critical essay, is the only way to get something out of the workshops. One of our major points is that so-called “traditional” humanities students already have knowledge that is applicable and useful within the “digital” humanities.

And third, it means that doing DH is about creating opportunities for our participants to be active, but that don’t require a huge commitment, such as, for example, a digital dissertation. (While I appreciate the interest in digital dissertations that I’m hearing about from departments, a digital dissertation is a huge project — and shouldn’t be anyone’s first DH project.) While we certainly teach aspects of project development and ideation, our goals tend to be more about creating opportunities that build towards larger endeavours, and that allow participants to see that learning about working with the digital is granular, as opposed to a monolithic info dump of instantaneously grasping everything about the Internet. In many ways, this is the most challenging part of running DMDH, because we have to do it on a shoestring budget, and in our <sarcasm>copious</sarcasm> spare time.

However — for me, this has become one of the most exciting parts of running the Demystifying workshops. It means that what we accomplish, we accomplish through collaboration with the already existing resources at UW — both UW Libraries, and UW-Information and Learning Technologies, mainly, but in coordination with departmental faculty, as well. The result is that working with the DH microclimate at UW is emphatically social, and human-centred; and it’s foregrounded as a collaborative endeavour between traditional and not so traditionally academic entities. In other words, the collaboration is the project. So, for that matter, is the awareness of how people work with technology, and learn about it — the things that help and hinder their ability and choice to learn, or their choice to not use digital tools for their research.

I think that one of the things we’re learning in the process is how much we can do with just one quote, or just one idea, and a group of engaged people. And also, how little people know about DH, and how easy it is for them to assume, not “I don’t want to do that”, but “I can’t do that.” I’m also becoming aware of how antisocial much of the professional work of the humanities has become, no matter how many works are cited in bibliographies. Intertextuality is not, in fact, the same as sociability, or social engagement with other individuals who are involved in the academic infrastructure of the humanities, and departments where publishing an essay or monograph is not the default means of communication. A lot of the work involved in the humanities really focuses on criticism, and critiques delivered through a traditional written format. I would say that one of the results of our experiment in developing the DMDH series is learning how critique can be enriched when it’s blended with interaction– how criticism itself can be collaborative, and productive because it’s something that happens in the context of an activity. I don’t think Sarah and I fully understood this when we started out last year. We knew that we wanted to be welcoming — but engendering a sensibility & sensitivity within human interaction has become something that I think about constantly at nearly every step of the way in planning these workshops — from including breakfast, to planning teasers and group activities that will allow people to learn from each other. I don’t think we would have made the progress that we’ve made in a single year if we weren’t paying attention to the human side of learning.

Running DMDH is changing the way that I see the University of Washington, from a place where I am simply bound to finish my dissertation, to a sizeable collection of people and offices that can be brought together to create events, resources…scholarship. I look at the campus and see all this energy that can be combined, in ways that I couldn’t see when I was simply focusing on my dissertation. And let me be clear: this takes work. I am not interested in merely throwing together a string of events — instead, the work, and the joy, is in figuring out how to organise events and projects that are designed to take root in the existing UW infrastructure, so that the connections between departments will have a chance to last.

The work that we’re doing– and here, I mean my colleagues Brian and Sarah, and a long list of other people, including Brian Reed, who is one of the best mentors that someone doing digital humanities, and DH infrastructure, could ever hope for, is imperfect, and incomplete, and oh, so tiny in the larger environment of digital humanities work taking place in academic and non-academic organisations all over the world. We’re in a microclimate. We’re doing things, and making mistakes, and correcting them in later iterations. But all this work is opening up questions, and practices, that I think are transferable to the larger climate zones in the humanities, whether they’re digital, or what people think of as traditional. Before our panel, Ray Siemens gave one of the RMMLA keynote speeches, a talk titled “Digital humanities? Digital literary studies: framing a response to (inter)disciplinary change;” and began by reminding us that what happens in English departments has always developed and changed, just as digital humanities develops and changes. Building a program from the ground up, with the constraints that I’ve mentioned above, has given me a great opportunity to see that change from a different angle — and to feel energized by it, rather than merely overwhelmed. And I’m incredibly excited to keep working in that territory in the future — at UW, and elsewhere.

April 8, 2013
by Paige Morgan
Comments Off on Today’s adventures in yak shaving: gritty realities of working with code for PhD students

Today’s adventures in yak shaving: gritty realities of working with code for PhD students

(Cross-posted to my Day of DH site)

I wrote this almost a year ago — and published it — and then unpublished it, terrified that I would seem as though I was kvetching without good reason. I don’t think that’s the case anymore — and both this post, by Julie Platt, and this post, by David Golumbia have convinced me that this stuff needs to be talked about.

Plus, I’m feeling braver now than I did then — so! I’m publishing it again, both here, and at my Day of DH blog.

So: here’s my original post, originally from April 19, 2012. I’ll update with another post later tonight, discussing what I’ve learned since then.

***

Earlier this week, via Twitter, I discovered Tara L. Andrew’s post on the realities of coding and collaboration for digital humanists. It’s brilliant. You should go read it, probably before you continue reading this post.

I’m resisting the urge to pontificate, so here’s the particular yak I’m shaving this week — but you can also skip ahead to my recommendations, if you like.

It seemed like a perfect solution!

I realized on Sunday night, while I was working on a Simile Timelines page for my students (an assignment I yoinked from Brian Croxall), that if I could modify the source code for units of time, that I could make Timeline into an ideal visual interface for my own project, Visible Prices. One of the challenges of helping people read prices is that pre-1971 British currency isn’t a base 10 system — instead, you have twelve pennies in a shilling, twenty shillings in a pound, and back in the 18th century, 21 shillings to a guinea. It’s not intuitive. But if I could mod Timeline’s date units to show units of money, rather than units of time; and adjust the multiplication formulas, then people would be able to scroll up and down the various amounts — and use facets to filter to a particular set of dates, or geographical region, or a type of object. I realized, too, that this interface would be that people could see other prices that were close to the same price — not just £4, 10s., but £4, 12s., too.

It would be PERFECT, I thought, and in a visual interface that I hadn’t conceived of before. I could use Simile Timeline as a platform to create a stable prototype that would easily demonstrate proof-of-concept. And this is hugely important, because platform decisions are epic. Almost certainly, especially if you’re approaching tool/project development from the humanities side rather than the programming side, when you first come up with your Big Idea, you won’t know enough about the limitations and capabilities of particular platforms in order to make a good decision.

I’ve actually taken a class in Java, and worked my way through textbook chapters beyond the class. I’ve taught myself HTML and CSS and Javascript and even some PHP using the W3schools tutorials, textbooks, and just studying code syntax. You can figure out a lot on your own if you’re comfortable looking at code, and if you understand the basic principles of variables, parameters, calls, methods, etc. In fact, at the workshop where I started learning HTML as a college freshman, back in 1995, we were encouraged to look at source code, see what it was doing, copy and paste, and debug till things worked. In some ways, I like this method of learning better than more systematic textbook progressions from “Hello, world!” to methods, to arrays, because it prompts me to see details better. (Your mileage may vary, but for an excellent discussion of this elsewhere, see Chapter 4 of William J. Turkel and Alan MacEachern’s The Programming Historian.)

In short: I understand enough to think that altering the source code of Timeline to change the units would be well within my capabilities. And there were even two sets of instructions at the Simile wiki for customizing dates that I could follow along with. Everything sounded doable. There would be bugs, but I was confident that I could fix them.

Or maybe not…

Last night, after turning in a grant application, I decided to have a go at it. I knew I would need to host Timeline locally, per instructions like these — and they were duplicated in enough places on the web that I thought they were probably fairly stable.

What I discovered is that hosting Timeline locally is probably the most difficult part of this mod — at least, for my own skill set. I thought I could host Timeline without hosting the rest of Exhibit locally, but I’m finding it challenging to do that. And I’m making use of the Simile Widgets Google Group, where at least I’m not the only person having trouble, but of course, I’m trying to avoid asking questions that are really just signs of my own lack of experience, and that would be solved if only I had learned to code more systematically, or hired a dev to help.

Hosting Exhibit 3.0 locally will require me to install, and implicitly, learn my way around Backstage, which, as the Exhibit 3.0 documentation says, may not be the project to start the learning curve for Java development. I’d like to do it. It seems like a great thing to learn. I have no problems learning, and part of me is saying “don’t mess with this blog post; find the instructions and start installing Git, SVN, Java 6, Maven 2, and Ant!”

But: transparency and the idea of instructive failure really obligate me to be up front about what I’m dealing with. And I think that we need more discussions about the gritty reality and challenges involved in working with code, so I’m offering up my own specifics, in the hopes that being open about them will be useful in some way. So–

Recommendations

1. Find out what your campus offers in terms of support. There’s an IT department: do they offer tech support that goes beyond working with email and installing virus protections? Do they offer introductory classes in things like HTML, CSS, and PHP? If they do, take them — especially if you’re one of those people who feels most secure and able to learn when there’s an expert nearby. I’m lucky — UW offers a really full set of workshops. There’s also the UW Libraries Digital Initiatives Project.

2. Be aware of the support limits: lack of funds, and a lack of grant availability:

Most grants for project development (including the NEH start-up grants) are open to people with PhDs, rather than people working towards them. At my local humanities center, these grants are for faculty. I understand this — at least sort of. It’s the way that things have always been done; funding faculty projects makes sense, since faculty (especially T-T) are ostensibly going to be around for longer than graduate students. And traditionally, graduate students are supposed to be intent upon finishing their dissertations, not building large-scale digital projects. Anything you build from scratch will probably need technical support at some point, whether because of a change in browsers, or some other cause.

The first of those specifics is that there’s never just one language you need to learn: you can know several, and not be savvy about working with GitHub, etc.  I took my Java class because it was the one that was open to students who hadn’t taken prereqs, and I loved it. Object-oriented programming is great, and it’s been useful. But it’s not enough, in and of itself (and happily, I knew that when I started learning it.) Coding in any particular language is one skill; integration skills are also necessary. Learn your way around the Linux operating system — and/or bash scripting — though these are languages, they serve a different purpose than HTML/CSS/JavaScript, etc. You’ll use them if you’re doing custom installs of tools on your system, according to your preferences — or if you’re installing a particular tool on your website.

Learn to be okay with making mistakes.

Here’s the rest of my take on what the gritty reality of learning to work with code like specifically from my perspective as a PhD student:

1. Program timeline issues:

The average time that it takes to complete a Ph.D. in the humanities is…”more than nine years?” Other results say 8.5 years, 9.5 years…it’s hard to say. I’m in my 9th year, and I’m revising, and will be done soon, and on the market this fall. I’ve had support the full time, first through guaranteed funding, and then through annually renewed funding as a TA in UW’s Interdisciplinary Writing Program. Because the UW is an R1 school that relies on graduate student instructors for most of its lower-division writing classes, and because the UW’s general ed. requirements include a mandatory composition requirement for everyone  (including transfers), and don’t allow students to test out of it, I knew that I could be relatively sure of getting funding. Not all schools have that kind of infrastructure. If you’re thinking about learning to code, and starting a large scale DH project, then you need to think about what the possibilities are for students who don’t finish within 5-7 years. Are there opportunities for you to keep teaching? Is teaching what you want, as opposed to taking a leave of absence?

2. Support issues for digital projects, vs. digital dissertations:

You wouldn’t know from reading my dissertation that I’m a digital humanist. I think it’s arguably still a digital humanities-influenced dissertation, because frankly, the research wouldn’t have been possible if not for resources like ECCO, EEBO, Google Books, and the various newspaper databases around, and my understanding of creative ways to search within them. Though it’s about literature and economics, like Visible Prices, VP isn’t involved. I could certainly write a dissertation on it — but in itself, that wouldn’t get it built, and the discussions in the dissertation wouldn’t be as rich or useful if they didn’t address the challenges of actually building it. Most of the discussions of digital dissertations and theses that I’ve run across have been about the value of a traditional diss with 4 long chapters vs. a diss with 10-12 microchapters — or about the issue of preserving a digital dissertation as formats change. Those are definitely valid issues — but what I haven’t seen discussed is the funding that would be required to get a digital dissertation (assuming that it were something other than an Omeka-based exhibit) developed and supported in the first place.

I could, of course, put off working on VP until I have a tenure-track job….and then put it off until I get tenure…and then … — in short, no. That doesn’t feel like a good option. Visible Prices might be really exciting, but I have a strong sense that it needs to be firmly in progress before I get a traditional job — not something to be started after that.

3. The ethics of seeking collaborators, for graduate students:

I’ll start by quoting Tara Andrews here, on the two main answers about whether you need to learn to code as a digital humanist:

  1. No, as long as you can think systematically and understand the possibilities that digital methods open to humanities research, who cares if you know how to run a compiler? That’s what collaboration is for.
  2. Of course you have to learn to code, because otherwise you will never fully understand the possibilities, and anyway you will simply not get anywhere if you sit around waiting for others to provide the tools for your specific problems.

I’m pretty strongly inclined towards the second answer — not just for understanding possibilities, but also for understanding limitations, and generally, to be able to appreciate what devs do, and to be a *good* collaborator. In terms of seeking collaborators, I’ve felt a bit limited by a couple of tensions. The major one is time: VP isn’t my job; and it’s only recently that it’s been formally recognized by my university as an important part of my work. (This is not to say that my dissertation director hasn’t been encouraging; he has.) But the time I have to work on it is limited by the pressures of both dissertating and teaching; and I’m not sure that those make *me* a good collaborator, or that there’s an obvious way to become a better one. My prospective collaborators, many of whom would be undergraduate and graduate students, have schedules that are no less fraught. And they see themselves as needing money, more than intellectual credibility or CV lines. Nor do I want to contribute to the whole Eternal September phenomenon.

I also don’t quite know what will happen to the project. Certainly, I hope that it will become a workable reality; my committee hopes that it will help get me a job, very possibly at an institution that is interested in developing it further. What exactly happens to my collaborator(s) at that point? — especially if they happen to come from non-academic institutions? I can’t help but think that it would be unethical to solicit help when I’m hoping that I’ll be hired somewhere with more official/local institutional support. To quote Andrews again, “a properly equal partnership of this form does usually indicate a truly innovative project, since it implies that there is something there that is academically interesting to multiple fields” — but I’m not really sure that I’m in a position right now to offer a “properly equal partnership.” And as Bethany Nowviskie has said previously, “consciously ignoring disparities in the institutional status of your collaborators is just as bad as being unthinkingly complicit in the problems these disparities create.” I’m hoping to make VP a major part of my job application, meaning that where I move, it moves. Frankly, at this stage in my career, I don’t think I can afford not to do that. And this puts me back into the realm of looking for “consultants,” i.e., staff, rather than collaborators, and offering to pay them in my limited cashflow, or in knitting. Or salted butter caramels, and other gluten-free treats.

I’m certainly not giving upon the possibility of modifying Simile’s Timeline. Obstacles happen; so does failure, and this isn’t a failure — just a big, hairy yak, from my perspective.

Last week, in a slightly different context, I was asked about my future career plans — whether they were more about a traditional faculty position, or an alt-ac position. I said at the time that I didn’t know — that I thought I would be happy in either, and that my experience thus far had taught me that it was much better to be flexible than rigid. That’s still true, but I realize that the other reason for hedging, which I couldn’t articulate at the time, was that I’m not sure which one will be more effective, in terms of improving the gritty realities of working with code as a digital humanist. I think that graduate students will need strong advocates with experience of those gritty realities on both sides of that divide, as long as it exists. And that if there are going to be digital dissertations, or projects, or projects-as-dissertations, then there will need to be traditional faculty to direct and support them.

I’m really looking forward to seeing how the constraints of collaboration will be affected by DHCommons — and hoping that they’ll be lessened. I wish I had a more upbeat ending for this post, rather than a yak, but this won’t be the first yak I’ve shaved; nor, I’m sure, will it be the last.