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.