css.php

Author Archives: Stephen Real

A Process Model for Design

I think that the chapter, “The Internet and It’s Users” by Charlie Edwards provides a valuable approach to Digital Humanities by considering the degree and quality of “user” engagement. The notion of a user in partnership with a coder/builder to create/design an object/system/application is crucial in the success of any digital project. However, when Edwards asks, “If we were to propose a design for DH, then, where might we look for a model?” she seems to suggest that there is one design that may apply to the entire panorama of DH projects. It only takes a quick glance at the sample projects on the CUNY Digital Humanities Resource Guide to realize that these projects all have different goals and therefore require different designs.

What does Edwards mean, then, by referring to a single a model of DH design? Perhaps what she wants is a template or a model for the process of design. She suggests elsewhere in the piece that the Open Source community offers a template for how that process should work. She emphasizes, rightly, that users have to feel that their voices have been heard in order to invest in what the builders are creating. The open source community of volunteer user/developers does a good job of fostering that environment.

However, perhaps paradoxically, corporate software development offers another worthwhile template or at least a vision of what is required for builders and users to work together productively. This vision is hard won over many years in the corporate world with thousands of projects (both successes and failures). Successful corporate software design has a number of crucial elements. First, corporations expect that business units specialize both via their expertise and through the work that they are asked to produce. In this light, the Marketing Department consists of individuals highly trained and experienced in marketing. They are not expected to know anything about programming or databases, which remain the purview of the IT department. A successful project requires a high degree of collaboration between the two groups, with a mutual respect for their diverse expertise. Most importantly, though, if the ultimate corporate users of the system are not given (or do not take) “ownership” of the final result, the project will likely fail. After all, it is the users who have defined the business problem that needs to be solved. Since they own the problem, they must also own the solution. Further, they must convey to the coders the day-to-day context in which the software will be used so that the design reflects all of the required use cases that might occur.

I think this corporate model could work in the Digital Humanities world. Like the Marketing Department, not every Humanities scholar wants to learn how to code. They would rather remain devoted to their research. However, if scholars abdicate the building of tools to the few members of their profession who do want to play with bits and bytes, they risk being left behind. Humanists can still participate in the Digital Humanities, in fact, by forming partnerships with coders (who may not be humanists at all) in the same way that corporate marketers partner with their IT departments. By recognizing the possibility that digital tools can enhance their academic work, Humanities scholars would provide the leadership necessary to instantiate a DH design process that gives them exactly what they want.

Living History

I read with avid interest Susan Hockey’s piece, “The History of Digital Humanities”. It turns out that this history closely parallels the arc of my life. By sheer coincidence, I was born in the year that Father Busa began work on his “index verborum” and I finished school about the time the concordance was first published in 1974. Like James Mason (https://dhpraxis14.commons.gc.cuny.edu/2014/08/29/digital-humanities-instilling-optimism-in-academia/) , I got my degree in English and could not do anything with it.

Finally, in 1978, I fell into a job as a mainframe computer operator. I had fun driving that big old machine, working with punch cards and huge reel-to-reel data tapes. My career led me to programming and then project management. Just as Hockey describes the advance of technology in the humanities, I lived through a similar evolution in the corporate IT world. The “invention” of word processing, the arrival of personal computers, the breakthrough of GUI (graphical user interface) and of course the history shaking impact of the Internet. I remember sending my first email. I remember working remotely on text-based terminal that operated over a telephone line at 300 bytes per second (it had no CRT; the I/O took place on spool of paper).

What is intriguing to me is that the tension between technologists and users of technology that seem to be taking place in the Digital Humanities is not a new phenomena. Techies have always been more interested in the tools than what can be done with them. I believe that Humanities has only lately been grappling with these issues because the technology is finally mature enough to deliver real value. It was much simpler to create systems that keep track of debits and credits, than to open up insights into the complex subjects that concern humanists. What seems to me to be unique to academia is the ongoing argument over the definition of Digital Humanities. Wouldn’t it be easier to simply do the work rather than agonize over what to label it?

Time will tell if this MALS program will lead me into a new way to study literature and theatre again or if it will open up a new arena for me leverage my technology career. Perhaps it will do both.