Source: The influence of the interface in building online projects
With digital applications, metaphors are ubiquitous, helping to translate complex computer processes into terms that human users can understand. One of the most prevalent such metaphors is the notion of the “desktop,” which goes back to some of the earliest examples of Graphical User Interfaces (GUIs) for personal computers. This ‘home’ screen presents the user with equivalents of a office desk: documents laid out in a more or less organized way, an array of tools frequently used, and a ‘recycling bin’ to discard all of the files we no longer need. Beneath this layer, the office oriented metaphor continues, with documents stored in folders reminiscent of file cabinets. This interface is a metaphor, giving the user a way to understand and interact with this digital tool; however, the metaphor also orients the user towards a particular way of interacting, in this case suggesting that the computer is a tool for work and productivity—a virtual office space.
As computers have become more pervasive and put to use for essentially every kind of task, the once dominant desktop/office metaphor has given way to a plethora of other interface metaphors. While this topic has been investigated in several contexts,1 I want to focus specifically on how interfaces might influence the production and development of digital humanities projects. DH scholars have an increasing number of tools at their disposal to build digital projects, both online and beyond the screen; many scholars go a step further to code and design their projects from ground up.2 Regardless of the approach, the DH project will inevitably utilize a metaphor via the interface through which both the creator and user of the project will interact with the data. Although many of the side effects of the chosen interface will be innocuous, the interface can also exert a profound influence on the kinds of projects that can be created with a given tool or the kinds of interactions possible for users of DH project.
I ran head on into this as I experimented with two digital tools over the past week: Scalar and Omeka. My goal was to build a simple but attractive online exhibition, which both of these tools make possible. Although both allow for a huge range of potential outputs—both Omeka and Scalar projects can take a variety of forms, and many can look and feel quite distinct from one another—I found that the overriding metaphors for the interface of each significantly influenced how I was able to think about and build my online project. Scalar frames its projects as ‘books,’ and the user is encouraged to think of every individual component of the project as a ‘page’. Omeka, on the other hand, employs an interface metaphor more closely resembling that of a museum. Here, each individual component is an ‘item,’ which can in turn be organized into any number of ‘collections.’
When I first started getting familiar with both of the tools, the similarities seemed to be more pronounced that the differences. I was able to upload (or pull in from various online repositories) many different kinds of files, including still images, text documents, moving image clips, sound files, etc. Both tools allowed me to add a significant amount of metadata for any object that I uploaded, drawing on several possible standardized metadata schemas.
I began by adding items to my collections, using both Omeka and Scalar. For adding materials, both of these programs seemed to be equally capable and ‘user-friendly.’ While it seemed that Omeka’s more museum-oriented interface, with its attention on the ‘item,’ would more readily facilitate collection development, I actually quickly gained an affinity for Scalar. I at first thought that Scalar’s overriding ‘page’ metaphor might be a difficult obstacle in developing a varied collection. Instead of oversimplifying the collection development process by trying to fit many different kinds of materials into one template, I actually found this interface remarkably flexible. For every item I went to add in Omeka, I was faced with numerous blank metadata fields spread across several tabs (description for the item, description for the file, etc.), many of which were only applicable for some kinds of items. However, adding an item in Scalar was as easy as uploading a file or pulling an item from a URL; I could then add metadata from the ground up for each item, selecting only the fields I thought relevant for the particular item.
I also found Scalar to be much more flexible when building an exhibition out of these items from my collection. Again, the overriding ‘page’ metaphor actually made it quite easy for me to conceptualize and build my exhibition. I could think of both the media items as well as the prose I had written as equal units that could be arranged and linked together in any number of ways. Although these projects are presented as ‘books,’ I think the Scalar interface makes it possible to create projects that are also very un-monograph-like, resembling guided online exhibitions, interactive workbooks, or spaces for collaborative research. The ‘page’ metaphor facilitates this flexibility: what constitutes a ‘page’ in Scalar can be just about anything, from a sound file to a long, discursive text; but then these pages can all equally be changed, adapted, and expanded upon, as well as put in many different kinds of relations to all the other ‘pages’ in the ‘book.’ Omeka, on the other hand, seems to limit the kind of end-products, gearing itself more specifically to online exhibitions. While these exhibitions, as I said earlier, can be quite diverse in their content and presentation, I feel like Scalar opens itself up to much more flexibility in how it is used as a tool.
While the effects the interfaces of these two digital tools may seem fairly marginal—I do think I could create an end-product in Omeka that would suit many potential projects as well as Scalar—these considerations should certainly enter into the development of any DH project. Even as the specifics of the platform might affect the end-product of the project, it is also helpful to be able to think about the project at a level of abstraction above the interface that is being used to develop and build the project. As Paige Morgan suggests in her exceedingly helpful blog post providing advice on how to create, manage, and sustain digital projects, “know that the platform or tool which which you build your project may change. Don’t commit to one right away. Experiment.”3 As part of this process, it is useful to critically examine the limitations and strengths of the platform being used: how does this particular platform work with the goals and trajectory of the project? might the platform impede the desired goals simply because it’s designed to produce another kind of work? Although my experimentation with both Scalar and Omeka was limited for this particular project, I will certainly integrate this period of trial and error with many possible platforms into future DH endeavors.
PS: Here’s a link to the project I built in Scalar, selections from the history of 20th century visual poetry
 See for instance, Lori Emerson’s Reading Writing Interfaces, a recent book in which Emerson looks at how poets and artists have radicalized the interface in many different strands of digital art making.
 An example of this, which I’ve mentioned previously on this blog, is Tim Sherratt’s Invisible Australians project. Drawing on data, images, and documents made available by the Australian national archives, Sherratt constructed a new interface to re-present information about marginalized peoples from Australia’s past. As a method for critiquing the interface employed by the government archives, Sherratt gives users a new interface, foregrounding the integrity and humanity of these individuals.
 Paige Morgan. “How to Get your Digital Humanities Project off the Ground.” http://www.paigemorgan.net/how-to-get-a-digital-humanities-project-off-the-ground/