Subject and Object Required

Despite the title, this won’t be about objects and coding. It’s about the subject behind the requirements we gather, the people we gather those objectives from. For the past couple weeks, we’ve been bogged down in some of the practical instruction we’re getting as part of the Praxis program, so I had forgotten about some of the project planning and management instruction we got a few weeks ago. When introducing us to requirements gathering, Jeremy and Bethany modeled the methods we might use as project planners when meeting with a client for whom we’re building a tool. Jeremy asked specific questions and redirected Bethany to the issues he wanted to cover. As I wrote a few weeks ago, perhaps over-critically, this is how some of Prism’s history, and what I took to be its existing expectations, were revealed to the Praxis team. Now I want to step away from the content of that discussion and look at the form — what methods and approaches it modeled rather than what particular information it revealed. If we were to extend this model of client-focused project planning into project management and evaluation later on, we might continue to check back with our “client” Bethany to make sure the tool we build for her is coming along as she would like. It would be her goals as a user that would become our end goals as tool-builders. But this instruction on how requirements gathering works is at odds with the “Prism is whatever you want it to be” message of the Praxis program. Is our job to learn the many skills necessary in DH by building a tool for a given client’s needs, or is our job to create a tool for the broadest possible audience, being cautious not to assume too much about how it will be used? I wonder if this question is similar to a question about what kind of role in the DH community we want, or what role Praxis is preparing us to take. Are we collaborating on scholarship or are we in a support role, providing a technical service that shores up someone else’s scholarly project? If we’re creating a tool for a very wide audience, how does this activity fit into our own scholarship? Are we academics or “alternative academics”?

Now I realize that I was wrong to point to the specifics of Bethany’s history of Prism as the source of my confusion over just how much Prism comes with particular expectations and how much it’s really ours to create. I came into that meeting with the expectation that we could make Prism however we wanted, so I was surprised to see that we might be gathering requirements from outside the Praxis fellows. So now I’m interested in the higher level question of where we’re gathering requirements from and to whom we’ll be accountable throughout the process. Are we acting like Bethany is our client who has a scholarly project in mind but needs a technical team to help think it through and make it happen? Or do we get requirements from the entire Praxis team, with all our individual hopes and expectations but a potential user population so wide we have to somehow build for uses we will never anticipate? If it’s the latter, we would do well to take Sarah’s advice on our requirements document to heart: “we want to be careful about pigeonholing Prism” because it could have uses beyond the primary pedagogical and second-level interpretive ones we’ve talked about so much.

I’m not trying to disparage either framework, but I am hoping we can talk about which one applies to the Praxis program since this seems to cut right to the point of it all. This dichotomy makes a lot of sense to me, helps me orient Praxis in relation to the solitary academic scholar I’m so familiar with, but I realize that it’s a dichotomy that Bethany’s most recent post and some of the people whose work she cites all seek to break down. We all want to be visionaries and risk-takers, but sometimes I react quite critically to new things and, much like Kathleen Fitzpatrick‘s grad student questioner, I might be a little too worried about the current academic “ecology” to feel confident in disrupting it. But it has only been a month.

I am a 2011-12 Praxis Fellow, a PhD candidate in the UVa Department of English, and a former AmeriCorps member, campus civic engagement coordinator, and criminal defense investigator. My dissertation uses theories of waste and excess to examine American literary responses to disaster from the 1927 Mississippi flood to the present.


  1. I think Jeremy’s response is spot on. We had two goals in the first session we spent together on Prism, and probably should have worked harder to make sure everybody understood what we were attempting before launching in.

    First, we were trying, in very compressed format, to get a set of possibilities and concepts in front of the entire team. This was so that we would all share the same background and have had an opportunity to start from a common straw-man, rather than spend too many weeks floundering in a sea of infinite possibility. Before the program began, those of us who have been involved in planning decided that we should present something that did four things: that could cohere as an actual tool; that was (as much as possible) uniquely “UVa” in its approach to the interpretive digital humanities; and that provided opportunities for our newer team members to build skills in a variety of areas; as well as opportunities for all of us to wrestle, together, with a couple of current theoretical and practical concerns in DH.

    So we settled on Prism as the over-arching concept. The wrinkle was that we decided to try to make this moment do double-duty in the program. This was by having Jeremy and me model the kind of gentle and pointed questioning that digital humanists do of each other to elicit project designs and shared understandings. Alex is right that this is also what we do when somebody new to DH comes in with a project idea — we ask questions and, in the earliest phases, mostly listen. But I want to be clear that I see little fundamental connection here to a service relationship, in which one person is a “client” and the others are in service to the project. There’s a lot of listening that happens (in the healthiest collaborative relationships!) among peers, whether these peers are scholars in student or tenured/tenure-track roles, or research or non-tenure-track faculty, or digital humanities staff positions. In fact, in the moment of collaboration on really great projects, it is my experience that these distinctions erode completely. It’s probably why I’m in this business.

    I think the Praxis Program holds great possibility for troubling the class distinctions that linger — sometimes for no good economic or cultural reason, and occasionally to the detriment of humanities scholarship — between 21st-century knowledge workers employed in a variety of roles in the academy. That’s why I’ve cringed a couple of times to see you draw a line between the digital humanities and what you’ve called the “non-alternative academy,” or pose questions like the one in this post: “Are we academics or ‘alternative academics?'” I suppose this is a healthy cringe, because it indicates an almost visceral desire on my part to understand your point of view better and discuss these issues more.

    I felt a milder version of this concern about the reification of service relationships, too, when noticing that the draft Praxis charter contains a good bit of language referring to the faculty and staff of the SLab as “staff,” and noting the value of “having staff nearby to troubleshoot.” I get where that’s coming from — I do! And I think in cases it was meant to signal an egalitarian approach. But my impulse would be to do that by talking about us as a team, rather than as factions within a team. As Jeremy says, our fundamental assumption has been that the entire Praxis group — that is, every employee of the Library attached to this project (whether that person is also a student, a faculty member, or a member of the University’s staff) would be discussing and agreeing on the terms of our joint venture.

  2. Our using the interview approach for this was, in retrospect, not the best way to go about this for Prism, even though as Alex mentions, it is often one of the ways Scholars’ Lab works with other scholars.

    They dynamics of requirements-gathering could be different from project to project, and from place to place, so I sympathize with your concerns about how we’ve discussed it as part of Praxis. Here are what I think the broader lessons for requirements gathering, as far as Praxis and Prism goes, should be:

    Projects have requirements, regardless of whether its a collaborative venture among colleagues, or a more formal client/development relationship. I would prefer to call this the scope of a project rather than the requirements, but the gist is the same.
    Project requirements should be discussed and agreed-upon by everyone involved in the project. In other words, the message of the Praxis program isn’t really “Prism can be whatever you want it to be”; it’s “Prism can be whatever we all agree it should be.”

    As for your higher-level question:

    So now I’m interested in the higher level question of where we’re gathering requirements from and to whom we’ll be accountable throughout the process.

    In short, each of us involved in the Praxis program, and eventually (hopefully!) people who start using Prism once it’s available.

  3. I think we are the subject and the object in this case. Bethany and Jeremy were just doing a mock of what requirement gathering looks like when those two are separate, as they usually are in practice. The cliche scenario is of a so-called traditional scholar trying to communicate to a digital humanist. Since there are two sides to that scenario, chances are you will be in one of them. For us, we are blurring the boundaries: we are gathering our own requirements. I also like to separate things conceptually before I blend them together, so for me the mock worked.

    The assignment is also asking us to be as specific as possible because we will be using line-items to actually test our code during implementation. It is there in those details where Prism is ours. Yes, we were handed down a general model. It would have been a nightmare to have to come up with one of our own. Trust me. Not cool. This general model is still flexible enough for us to add the juicy details where it matters: design, functionality and outreach. Our details.

  4. You might want to check out Woolgar’s Configuring the User and DiSalvo’s Design and the Construction of Publics while you wrestle with these issues.