After finding usable audio and creating a manifest, annotating such audio is the next step. I've found this step to be really simple and thought provoking as it offers the first part of a unique practice of listening, which the software offers. The only requirements for annotating with AVAnnotate is access to and minimal knowledge of Excel spreadsheets or Google Sheets. Since AVAnnotate doesn't offer a way to annotate within the software, annotation happens with other tools. This is similar to how GitHub repositories, Jekyll, and IIIF [International Image Interoperability Framework] are integrated; Clement and Brumfield Labs (Clement et al., 2022) referred to this as "glue code—code that sticks a bunch of things together to make something useful." Thus, instead of building in annotation as part of the software, AVAnnotate outsources, in a sense, this functionality. It's pretty simple, and it's much better than learning or downloading another spreadsheet software, as I already own and am familiar with both Excel and Google Sheets.

The spreadsheet is organized in five columns, with only three being mandatory. The first vertical column is the first time stamp, the first time in the audio where the annotation begins. That goes in column A in the format of hh:mm:ss. And the next column, column B, includes the time where that annotation stops, in the same hh:mm:ss format. If, for example, I wanted to annotate part of an audio recording of someone who speaks from minute 1 to minute 2, I would put in column A "00:01:00" and column B "00:02:00." Or, if I wanted to make a point annotation, I could put just the beginning of that speaker at "00:01:00" in column A and "00:01:00" in column B. This practice of making timestamps is really helpful for certain audio, as it creates a different process and purpose to listening. In just the time stamping, I've found that I'm more focused on what and where a sound is and focusing less on what that sound means. The time stamping required by AVAnnotate asks users to locate, but not define, certain moments in audio recordings. Such an act creates a conceptual break that is not often experienced in common practices of listening.

The next column, C, is designed for the annotation of the prior time stamps. This section is where I believe AVAnnotates offers the most valuable flexibility and engagement with access to information. This annotation can be almost anything. Column C can be a transcription, observation, image (using Markdown), symbols, or general thoughts—really, users can write anything in this section. I understand this to be extremely beneficial and important for how access is communicated in digital spaces. Indeed, transcription is helpful for quickly searching an audio file, assisting users with auditory disabilities, creating metadata, and more. However, having the opportunity to include ideas, thoughts, visuals, and links according to certain portions of the audio is a different practice of making meaning for sustainable access to information. In my personal experience of annotation, I've found two things: First, AVAnnotate becomes a unique tool for knowledge dissemination when the possibilities of digital annotation are exercised to their full potential. Being able to communicate with images and external data creates new ways to experience information according to goals of access. In other words, communicating for sustainable access through digital annotation develops new and different ways of knowing audio. And, second, to this same point, the act of listening for the use of sound is a unique experience offered by AVAnnotate. The software teaches users to engage with sound differently by emphasizing what sound can do for access, and how we, as annotators, participate in what this sound means.

Further, the last two columns, D and E, are for Layers and Index, respectively. The former is a form of categorization of the annotation, and that's column C. The Index column is, simply, for an index which can be added to the project. I've found these both to be helpful additions to the software, but only if the user knows what their annotations are doing or what they're for. In other words, having all of these columns requires up-front conceptual work by the user in that they need to decide the purpose of their project's annotations. Even if the sole purpose of an AVAnnotate exhibit is to promote sustainable access to an audio artifact, each annotation requires decisions about what is highlighted and what isn't. Is access to information about context important to this audio? A transcript of one or multiple speakers? The background noises or quality of the audio? Having layers and an index requires users to acknowledge how they are making meaning with the software—which is beneficial but difficult work.

The "difficult work" that I have just described in terms of organizing columns and annotations is supported by the separate pages that teach users the importance of publishing digital annotations. The purpose of this Create Page function is to offer space for contextual information, such as an essay and images. In sum, this function supports further engagement with any artifact as a knowledge and meaning making practice. I really enjoy the integration in these pages in AVAnnotate because it asks users to purposefully situate their goal of working with sound and audio. These pages teach users to ask, "Why these annotations?" and "Why this audio?" in creative and unique ways. This is especially helpful for students working with audio and sound as it exceeds mere listening and then annotating that experience; these pages require deeper engagement with the intersection of listening and annotating and what this means in the larger context of the project. Creating contextual pages is more than supplementary. In this sense, it prompts users to think, consider, and reflect in a meaningful way.

When users create and title a page, it gets published in their GitHub repository with the other published parts of the project, like the annotations and audio items which have been uploaded. Due to this, the pages must be written in GitHub, which means using Markdown. This requirement can be a learning curve for some users, and it also can hinder the productive benefits of the tool as a resource for teaching. Not all users may come to use AVAnnotate with coding experience or knowledge of Markdown. It's not the most difficult language, but it's a shift from using Word or Google Docs to write and integrate images and audio. So, unlike the other functions of the software, creating pages can be where users get stuck, and this can discourage their engagement with the annotations they've created. Missing out on this opportunity to make sense of their exhibit severely inhibits the purpose of the software as a tool for sustainable access. Because while audio and annotations together may be a type of intervention into accessibility issues, excluding contextual pages doesn't fully grasp the opportunities of the software. This is why I believe these pages are essential to AVAnnotate as a tool for teaching users how to thoughtfully engage with the sustainability and accessibility of their annotated artifact as a source of information and knowledge.

However, I also argue that the use of Markdown is essential to the conceptual framework of AVAnnotate. As a software for creating exhibits of annotations digitally, developing context in any other way would not be in accordance with AVAnnotate as a tool for teaching. The use of the Create Pages function—not alone but in combination with the rest of the software—develops the software as a mechanism for conceptualizing interventions in digital environments. In other words, the requirement of coding attunes users to their own role in sustaining an artifact in a digital space. It's not that a word processing software would be too easy; the point is, the added difficulty of Markdown teaches users to be hyper-aware of what constitutes the intervention that they're creating. In a sense, creating contextual pages is an ethic of accountability as users construct, piece by piece, the significance of what they are promoting, sustainably and accessibly too. While AVAnnotate's response to the degradation of audio artifacts is surely rhetorical, what the software asks of users is also part of this rhetorical intervention.

For such a reason, I believe that AVAnnotate is an essential tool for teaching rhetoric and writing, especially as these classrooms focus on sound, archival practices, and digital technologies. This software teaches users how to develop rhetorical interventions in digital and sonic spaces with a focus on how they, as individuals and a collective, are responsible for how they compose access. Pages, while they might seem like a small part of a project and the software as a whole, make AVAnnotate a tool for teaching students about the importance of rhetoric and writing.

Speaking to the pedagogical and technological aspects of AVAnnotate, the software's infrastructure encourages collaboration among learners interested in sustainable access to audio materials. Due to the software being built using Jekyll and GitHub pages—and also using IIIF [International Image Interoperability Framework]—users have the opportunity to fork any public project and edit it or add to it. Also, AVAnnotate allows for users to fork projects together, creating a larger exhibit out of smaller projects. Essentially, the software's infrastructure allows for projects to be infinitely collaborative.

Say, for instance, 10 students wanted to create an exhibit of 10 different audio materials, context pages, and total projects built with AVAnnotate. These are all separate, but public, GitHub repositories. These students could fork all of their repositories to a single GitHub account and create a larger exhibit which links to each single project. I've found this process to be relatively easy with minimal understanding of GitHub's functionality. The only issue is that once a project is forked, the original owner can't change their project. In other words, any updates won't translate to the forked repository in the larger exhibit. This would require forking, again, the updated repository of a larger project and repeating the process of integrating it into the larger exhibit. However, barring this issue, collaborating on a large, multi-user project is simple and fruitful. AVAnnotate's allowance of this type of communication creates an easy way for students to collaborate on topics of sustainability and access. Such a form of collaboration is truly innovative when working with this type of material.

Another opportunity for collaboration that AVAnnotate's infrastructure offers is collaboration on a single project via GitHub. GitHub allows for unlimited collaborators on a repository, which means that anyone with a GitHub account can be added to an exhibit someone has created with AVAnnotate. By pulling (viewing) and pushing (editing) an owner's repository, individuals can make changes to an AVAnnotate project in GitHub. Once a repository is shared, it becomes available in a user's AVAnnotate My Projects page, just under Shared Projects. This allows each collaborator to edit the GitHub repository via GitHub or AVAnnotate's interface. So, if there are two collaborators with separate annotation sets, each can upload their own set without having to send files to one another.

The last collaborative function of AVAnnotate that I think is critical is the use of IIIF manifests. As mentioned in an earlier section, AVAnnotate requires creation or integration of a IIIF manifest for each audio artifact being annotated. At the bottom of each page, and even this page, is the created IIIF manifest. This can be used by anyone with access to this page by copying and pasting the manifest into a view such as Universal Viewer or Aviary Viewer—both of which are tools for viewing IIIF manifests and are available for free. AVAnnotate's prioritization and requirement of IIIF manifests makes the software foremost a tool for collaboration. Any user with this manifest can not only listen to the associated artifact in a viewer but use the manifest to create their own AVAnnotate project with the same artifact. This is a really exciting function of AVAnnotate which is supported by IIIF. At the software's core, AVAnnotate is creating opportunities for collaboration on sustainability and accessibility of audio material. Its technological infrastructure supports the teaching and learning of where collaboration intersects with access.

Transcript

[32 minutes, 57 seconds of collaged shortwave radio transmissions]

Text

Integrating AVAnnotate into the classroom meets pedagogical objectives for instructors working with audio and visual material. In this section, I illustrate how AVAnnotate may be used for analysis—specifically, the goal being to develop an argument that considers if feedback and other qualities of shortwave radio are significant and meaningful features of this type of audio recording. Such an assignment requires students to consider the purpose and history of shortwave radio, how the quality of such recordings is a product but also an essential attribute of such recordings, how these waves travel, the reliability of this form of communication, and what transmission means.

The exhibit below breaks down this work in two ways: student groups and color-coded annotations. The student groups illustrate how annotation sets can be uploaded from multiple student groups into a single AVAnnotate project. Plus, the recording's annotations are two different colors, to represent being for (green) or against (red) the above argument. Green annotations argue that the sonic features of shortwave radio are significant, as they construct meaningful transmissions. Red annotations argue that the same sonic features are not significant and, in fact, are inhibitive to transmissions.

AVAnnotate functions best as a tool for teaching users how to use digital technologies for creation of rhetorical interventions into concerns about sustaining access to knowledge in audio artifacts at risk of obsolescence. At the software's infrastructural core, it is devoted to supporting engagement with these artifacts in a way that teaches users how to become better listeners who are attuned to how their own practices affect the communication of essential information. And while this does require a small learning curve for users and enhancements to the software on AVAnnotate's end, there are still many unique and fruitful opportunities that this tool provides for a variety of learning communities. In this conception of AVAnnotate, the software is not just a route to creating digital exhibits of audio annotations; AVAnnotate is an opportunity to become more responsible users of sound. By promoting collaborative listening devoted to the sustainable access of knowledge, AVAnnotate offers a rhetorical resource for artifactual degradation foregrounded by our digital age.

Thank you to editors Ashanka Kumari and Jonathan Marine for the helpful feedback and suggestions. Huge thanks to Ben and Sara Brumfield for the last-minute help with the Universal Viewer and for answering all of my endless questions! And thanks to Casey Boyle for looking over an early version of this review.