This contribution compliments a 2012 SAA contribution which I submitted in the workshop "Old Words, New Tools," led by Jennifer Roberts-Smith. I proposed an online editorial platform called "Marginalia" that would support collaborative editing. This year, I built a prototype of the interface, as well as the underlying structures to support it. (You can read last year's contribution here: http://bernini.us/marginalia.)
The basis for these changes is Open Source Shakespeare (OSS), which I built and is now maintained under the auspices of George Mason University. This is a working prototype, meaning that enough of its functions are present to demonstrate how it would work when it is fully constructed. There are some aesthetic changes introduced in these pages, and the rest of the site's design would have to be modified to harmonize the old and new elements. That does not have any effect on the functions, however.
Much of the labor involved was behind the scenes — specifically, in the database, where several new, interconnected tables had to be created to store the annotations and tie them to the texts. Each annotation allows for threaded discussions and user ratings, to facilitate an exchange of views after an annotation is proposed. Annotations can be plain text or marked-up HTML, and could also be cross-references to other texts, external sites, or multimedia objects such as videos, audio images, or images.
Some of the sample annotations are taken from Shakespeare: The Complete Works, edited by G.B. Harrison (Harcourt, Brace and Company, 1952), which uses the Globe Shakespeare as its text, just as OSS does. As far as I can determine, that edition has been out of print for at least three decades. In the annotation signatures, I used Harrison's name, and the names of two fictitious professors to give the impression of collaboration.
The video clip is from the BBC's 1978 television production of "Romeo and Juliet," and it was transferred from a DVD. Given that the text annotations and the video clip are not being publicly distributed, their inclusion should be well within the boundaries of fair use.
Primary objective and user stories
The primary objective of building an editorial platform would be to increase an audience's understanding and enjoyment of the texts. In many web development projects, high-level goals such as this are turned into "user stories," which are a more concrete way of imagining how users will interact with the site. The two user stories I was envisioning were these:
1. An instructor (at the secondary or university level) wants to give notes to a class, and have students ask questions or make comments on those notes. The instructor could add those notes as annotations, and send a link to the class where they could read them (either with or without other people's annotations).
2. A theater director (in a professional or educational setting) wants to give directions to the actors who are performing in a play or scene, and would like to attach not just notes, but also references to audio and video recordings.
Contributions and governance
The annotations in Marginalia would be either public or private.
Private annotations would not be displayed automatically when viewing the texts. Any user could create a private annotation, which would be part of a personal workspace where they could view their own annotations, and invite others to see them.
Public annotations would be visible by default when viewing the texts. They would have a presumptively higher level of quality and reliability.
Anyone who wished to contribute would have to create a user account. At the moment, there are three access levels:
Contributors could create private annotations and comment on other annotations. Their annotations would be invisible to the public, but sharable.
Editors would be granted a higher level of trust. They could create either public or private annotations at their discretion.
Publishers would have the powers of editors, but would also have the ability to raise contributors to the level of editors.
Keeping annotations private by default, and only allowing public annotations by trusted users, would prevent vandalism and (more importantly) low-quality contributions from deterring audience members from returning to the site.
The platform would need a governance structure to determine who would gain higher levels of trust. There are not many examples of this kind of collaboration in the digital humanities per se, but many online communities operate successfully this way. (It is possible to argue that Wikipedia is, in large part, a digital humanities project, but that would be outside the scope of this workshop.)
This approach would be different from crowdsourcing, which implies a more free-form contribution model. It could be led by the individuals who are living out the user stories described above, who number in the tens of thousands. We simply need to convince them that sharing their knowledge and observations in this venue is worthwhile — and that it would actually make their work easier.
Many considerations went into the prototype, but some of them are particularly noteworthy.
Reader-friendliness: The annotations should not intrude on the text, or distract from it. Word-level annotations are indicated with dotted lines underneath the annotated passages. The annotation threads are in boxes in the right column, and hovering over a speech brings its annotations to the front (you can see this on the two overlapping annotations starting at line 80). The completed version of the interface would make it possible to dismiss the annotations entirely, if the reader chooses.
Editor-friendliness: Adding an annotation is as easy as following a series of prompts.
Mobile-friendliness: The two-column layout looks as good on a tablet device as on a desktop, and should be readable on everything except the smallest screens. There are no pop-up windows or lightboxes. Users are not forced to do things that are difficult or impossible on touch screens. For example, when annotating a passage, users can either copy and paste if they are using a desktop computer, or type the passage if you are using a tablet or phone. In the future, when pages are rendered on smaller mobile devices such as phones, the right column would collapse and there would be indicators (such as icons) showing where annotations are, instead of showing the full boxes. This would allow the layout to accommodate practically any device's screen.
Multimedia incorporation: Any image, audio recording, or video could be used in an annotation. To see the video annotation function in action, click on the thread at line 101, where you will see the speech text on the left, and the video on the right. After the page loads, click the "Start the speech" link, and the speech should start at the 6:36 mark. (If it doesn't, wait a moment and try clicking again.)
Try your hand at annotating
Please go through the annotation process yourself by clicking on any speech you wish. (Keep in mind that the view you see is that of a logged-in user, and that unregistered users will not be allowed to annotate.) The annotation will not be stored in the database, so you can do this as many times as you like. The process should be largely self-explanatory, but here are instructions for each step:
1. If you choose a speech that already has annotations, you can view those annotations by clicking the "show" link.
2. Choose whether you would like to create a speech-level annotation or a word-level annotation.
3. If you chose a speech-level annotation, you will skip to step 5. If you chose a word-level annotation, you are asked to select the words you want to annotate. (For now, you can only annotate words that are on the same line of text.) Make sure you enter the words correctly, because there is no error checking yet.
4. You are asked to confirm the passage. If you select yes, then you will go to step 5. If no, then you will go back to 3.
5. Enter the text of your annotation and click the "Submit" button.
6. The confirmation page appears, and you can return to the text.