top of page
  • Casey Wolf

F23: Week 9—Internal and External Encoding

Following Week 8, a significant challenge lay in presenting information in a way that is approachable to users. It must strike a balance between providing enough information while preventing information overload, inevitably overwhelming teams of encoders. This became a more significant issue when the description of data regarding Alt Names, Mentions, and Relationships necessitated the use of Excel as another encoding element.


From the project’s outset, tagging Mentioned individuals has been a large part of the encoding process. The original process for capturing this information as metadata was to encode it in EndNote’s Keywords field which contained all individuals and places associated with the document. Occasionally, letters also contain data about the places and dates associated with the Mentioned person’s presence or context within the letter. After noticing a few of these instances, I then began associating these elements with the individual’s name using curly brackets. Following an approach of “gathering as much data as possible while I’m here looking at the document,” this data encoding “solution” was only meant to capture data in a cursory way, with the intention for it to be described at a later part of the project’s progress. (Figure 1)


Figure 1 shows how encoding Mentions in EndNote is insufficient to describe data to a machine-readable standard

At this point in the project’s timeline, it is now necessary to conceptualize and outline how Mentioned data is to be encoded. The “curly bracket” approach to data encoding exposes a limitation to EndNote’s data description capability. As the EndNote library is currently the ideal method for creating, storing, and querying data, it is not an issue with the program but rather the incorrect application of a digital tool. Whereas EndNote associates metadata with one record and authority list, a more relational approach is required to describe elements across records and, eventually, across projects. This is the reason for the requirement that encoding takes place across several programs and mediums: a view of the document being encoded, EndNote, and Excel. These are merely the “working” parts of the process. Encoders will also reference two protocol documents—one in Word, another in PowerPoint—to ensure adherence to the standards.


Certainly a potential usability issue, it is also another example of how the application of a variety of approaches and digital tools to make digital history projects work. Despite juggling programs presenting complications to user experience, each was chosen with the user in mind. The two reference guides are split between Word and PowerPoint as each program presents an ideal presentation of information—depending on the program in which the encoding process is taking place. The Word document structure prioritizes “quick reference” through implementation of the Heading styles and Navigation bar, and is intended for use when encoding in EndNote. (Figure 2) The complexity of Excel encoding necessitates more illustrative examples, better displayed on a PowerPoint slide format. Splitting the reference materials in this way allows users to confine their program use to two if splitting up the encoding process. Providing encoders with strategies to juggle the programs and encoding processes—such as printing out reference documents or splitting up the encoding process elements—can help alleviate usability issues as well.


Figure 2 shows how the Word reference document prioritizes quick reference navigability.

bottom of page