J2: Blurring Boundaries with/in Online Archives: The Case of the Museum of Everyday Writing

Proceedings: Blurring Boundaries with/in Online Archives: The Case of the Museum of Everyday Writing

          At the 2016 Computers and Writing conference, Megan Keaton, Jennifer Enoch, and Amy Cicchino spoke about the process of creating and maintaining The Museum of Everyday Writing, ultimately using their experiences to offer a heuristic for conference participants to design their own online archives. The panelists began the session by explaining the two panel handouts:

  1. a 5” x 5” takeaway composed as a small scrapbook page that details the purpose and goals of the Museum, the Museum’s definition of everyday writing, and the instructions for submitting artifacts the Museum; and
  2. the heuristic for conference participants to consider when creating their own online archives. Though the panel was organized by different considerations of the museum – namely, the content management system, metadata, and user participation – many of the questions in the heuristic overlapped among these considerations; therefore, the heuristic was broken into questions about the archivist’s abilities and resources, the archive, and the users.

As an introduction to the panel, the panelists first described the history of the Museum as well as Keaton, Enoch, and Cicchino’s respective roles in the Museum. The Museum was inspired by a graduate course at Florida State University about everyday writing. Throughout the course, Kathleen Blake Yancey (the instructor for the course) and her students frequently discussed the artifacts they believed would be included in a museum of everyday writing. As students in the course, Keaton and Enoch, along with their colleague Sarah Marshall, decided to create the Museum for their final project. Keaton, Enoch, and Marshall founded the Museum with the following goals: (1) to bring focus to understudied texts (i.e. everyday writing); (2) to create a space for researchers, students, and teachers to observe and analyze everyday writing; and (3) to enable students and researchers to experiment with curation. After a year of identifying and revising metadata categories, selecting and working with a content management system, uploading artifacts, and receiving feedback from professors in the Rhetoric and Composition program, Keaton, Enoch, and Marshall started to increase their user participation. This took two forms. First, students in Kathleen Blake Yancey’s Digital Convergence course were given the option to compose exhibits for the Museum; Amy was one of the students who selected this option. Second, Keaton and Enoch began working with undergraduate interns to improve, expand, and promote the Museum. (By this time, Marshall had completed her degree and left Florida State. She remains on the advisory board, as will Enoch and Keaton when they complete their degrees.)

            After describing the history, the panelists explained the Museum’s understanding of everyday writing: Writing that is composed by ordinary (i.e. not famous) people for non-professional and non-academic purposes. This writing is mundane, discardable, and often invisible, in that most people would not pay much attention to this writing. Everyday writing texts may be important to their composers and/or receivers. For instance, a person may see his/her grandmother’s to-do lists as valuable. However, the general populace likely would not assign much value to everyday writing texts like this. Some examples of everyday writing include graffiti, letters, scrapbooks, recipe cards, and memes.

 

Panelist: Megan Keaton

Title: CMS Circus: Assessing and Choosing Content Management Systems

With this introduction, Keaton began her presentation, which focused on the ways in which the founders identified their content management system (CMS). Keaton, Enoch, and Marshall wanted to find a CMS that enabled uncomplicated navigation and participation in the Museum, allowed future curators to understand its structure and administration, and displayed artifacts effectively. These desires were complicated by the fact that the founders lacked coding experience, has little monetary funds, and were hesitant to draw boundaries between different types of everyday writing. After exploring a number of platforms, the founders ultimately needed to decide between Omeka and Wordpress for the CMS. From here, the founders needed to balance their desires and complications with the affordances and constraints of each website-building platform, which Keaton explained with the following table:

 

Omeka

Wordpress

  • Omeka is set up for archiving so the founders would need to code much less material, if any.
  • Omeka is set up for curating with exhibits and collections, which would help users draw connections among disparate artifacts. Again, because Omeka is set up for this curation, the founders would not have to code their archive for this option.
  • Omeka’s administrative interface is easy to navigate, which meant that future administrators could fairly easily work in the Museum.
  • Omeka’s user interface is easy to navigate, which meant that users could fairly easy find, contribute, and curate artifacts.
  • Wordpress is not set up for archiving, which meant that the founders would need to code much more of the Museum. This would influence the time at which the Museum would launch because the founders would need to learn to code. Moreover, the Museum would be more idiosyncratic, which may cause more difficulty for future administrators.
  • Wordpress’s administrative interface is more complicated than that of Omeka, which would mean a steeper learning curve for future administrators.
  • Omeka has less user support than Wordpress, meaning the founders and future administrators would have more trouble solving potential technological impasses.
  • Omeka is hierarchy and category-based, which would make connections among artifacts more difficult to make.
  • Because it has fewer templates, Omeka has limited ways to display artifacts and information. This would affect both how artifacts can be seen by users and the aesthetics of the Museum. The templates either effectively displayed artifacts or had a pleasing aesthetic; no templates offered both.
  • The item types (the categories into which artifacts are sorted) aren’t shown to viewers, which meant that users may have more difficulty finding and/or understanding the metadata requirements of the artifacts.
  • Omeka’s search engine is not very sophisticated, so users may have more difficulty find artifacts.
  • Wordpress has more user support than Omeka, meaning the founders and administrators may be able to more easily solve technological impasses.
  • Upgrades on Wordpress are less expensive than Omeka, meaning the founders would be able to more easily upgrade and improve the Museum.
  • Wordpress has several templates, so the founders would have more options for artifact display and aesthetics.

 

  • Users needs administrative access to upload artifacts and create exhibits, which allows more archivist control, but may limit user participation.
  • Wordpress does not offer varying levels of  administrative  access, meaning that users would either have complete control or no control over the Museum.

 

Keaton then explained that another consideration for choosing a CMS platform was whether to use .net/.com or .org. She offered the following benefits and limitations of each:

 

Omeka.net and Wordpress.com

Omeka.org and Wordpress.org

  • Omeka.net and Wordpress.com’s basic options are free and housed on the platform’s server. This means that the founders could design and launch the Museum without needing to find funds or server space.
  • Omeka.net and Worpress.com offer upgrades that allow the user more control, so the founders could begin designing a CMS for free and upgrade if necessary.
  • Omeka.org and Wordpress.org allow the user complete control over the HTML and CSS, so the founders could design the Museum to their full expectations.
  • Omeka.org and Wordpress.org are free, if the user has access to a server, meaning the founders could spend much less (if any) money on the Museum.
  • Omeka.org and Wordpress.org typically allow the user to start with a template and build from there, so the founders would not have to code from the ground up.
  • Omeka.org and Wordpress.org offer a lot of user support, so the founders could more easily find solutions to technological impasses.
  • Omeka.net and Wordpress.com require the use of templates unless the archivist upgrades; this means the founders would have less control over aesthetics.
  • Omeka.net and Wordpress.com have much less support than their .org counterparts; support that is offered is frequently difficult to find. This means that the founders would have more difficulty solving technological impasses.
  • Omeka.org and Wordpress.org require the archivist to provide a server, which costs money. This meant that the founders either needed to purchase server space or use the English department server space; using the English department server space may have offered the founders less control over the direction and size of the Museum.

 

In the end, Keaton stated, the founders of the Museum chose to use Omeka.net, meaning they ultimately chose functionality over aesthetics. They made this decision because they would not to use the time and labor to code the Museum, which was important because they would eventually complete their degrees and leave the Museum at Florida State. In the same vein, because Omeka is designed for archives, administrative transfer easer would like be easier. Also, though Omeka has less support, some faculty at Florida State have experience with Omeka and could become resources for technological impasses. Finally, though Omeka does create hard lined categories, the ease of creating exhibits and collection allows for connections among artifacts and categories.

In terms of conference participants creating their own digital archives, Keaton offered the following heuristic for choosing a CMS:

Archivist’s Abilities and Resources

  • How much coding experience do you have?
  • How much time and/or labor can/will you dedicate to the archive?
  • Do you have access to a stable server?
  • What (if any) monetary funds do you have? Are there restrictions on how you can use those funds?
  • Will archive administrators change?

Archive

  • Do you want to archive only or is curation important too?
  • How important are design and aesthetics?

Users

  • How do you want users to participate in your archive?
  • What are the abilities of the users?
  • What level of support would users need to navigate and/or use the CMS independently?

 

Panelist: Jennifer Enoch

Title: Designing Metadata: Meeting the Needs Of Audience and Artifact

Next, Enoch articulated the founders’ process of choosing and revising metadata for the Museum. She explained that metadata, or the data about the artifacts, is the backbone of the Museum because it determines the artifacts’ organization within the Museum, the ways in which artifacts can be searched, and the information to which researchers have access. Omeka allows archivists to use two kinds of metadata: Dublin Core, a standardized set of data fields, and item type metadata, which archivists design themselves. The Dublin Core is a standard data set for many libraries and archives on the web. Omeka requires that archivists use the Dublin Core metadata, though archivists may decide to leave fields blank. Archivists can then design their own categories and metadata for those categories; in Omeka, these categories are called item types.

In choosing how to utilize the Dublin Core and define item types for the Museum, Keaton, Enoch, and Marshall had to balance a variety of concerns. These concerns culminated in four primary questions, each of which Enoch discussed in turn. Though the questions were presented in somewhat chronological order, Enoch stressed that the founders and administrators frequently circled back to previous questions as new concerns arose.

  1. What are the types of artifacts that we want the museum to curate, and what kinds of metadata would researchers’ need for those artifacts?

As the founders identified the copious amounts of everyday writing texts that could be archived in the Museum, they tried to define each Dublin Core data field so that the field could account for all artifacts. This was relatively easy for data fields like “Title,” “Creator,” or “Date,” but proved much more difficult for fields that would greatly vary based on the specific artifact. For instance, the data written in a field about distribution and circulation differs widely between letters and signs. The circulation and distribution of a letter involves describing the envelop text, the addressee, the postmark’s visual and linguistic text, the postmark’s location on the envelope, and whether the letter was re-mailed to another person. Meanwhile, describing the circulation and distribution of a sign involves identifying the location of the sign, the way in which the sign was affixed, the amount of visibly the sign has, and the potential movement of the sign among multiple locations. This led the founders to question two.

  1. How do we honor the Museum’s capaciousness without the system of metadata becoming so complicated or idiosyncratic that it is impractical?

The difficulty in applying the Dublin Core metadata across all artifacts pushed the founders to create their own item type categories and metadata. Taking a cue from Omeka, the founders attempted to create item types by grouping artifacts that would need similar data fields. This was complicated, however, by the fact that many of the data fields were still the same across all artifacts; these common fields included genre, material, circulation, linguistic text, visual text, aural text, given text, and dimensions. That meant, then, that the founders ended up with three tiers of metadata: (1) the Dublin Core, (2) the data fields common to all item types, and (3) the metadata specific to individual item types. On top of this causing possible confusion, the founders worried that the item types suggested that the categories were clear cut, obscuring connections that could be made across item types and discounting multi-genred compositions. This potential confusion and the founders’ concerns led to question three.

  1. How do we organize the item types in a  way that works within Omeka but still acknowledges the sometimes blurry distinctions between genres?

The founders worked to lessen confusion and to allow for the possibility of more connections across item types by using stable vocabulary for subject terms, tags, and the common data fields listed above. First, the founders composed a style guide that defines and explains for users all of the item types and data fields. Second, they used stable vocabulary so users can search for an term or tag and see all artifacts under the search term, regardless of the artifacts’ item types. The founders also attempted to allow for fluidity of item types and potential search terms based on feedback and input from user-participants. For example, the vocabulary that cross item types is constantly expanding as users write their own tags to describe the artifacts they upload. Additionally, the terms and vocabulary used in the metadata and style guide are negotiated with Museum users, allowing the founders and other administrators to be sensitive to how users make connections. An example of this presented itself when a user submitted as artifacts many walls on which sororities and fraternities had painted information about their upcoming events. The administrators had input the genre of these artifacts as “graffiti,” defining graffiti as texts painted on a permanent public structure. The user, meanwhile, had associated the term graffiti with compositions that are painted without permission. This gave the administrators an opportunity to understand how users define the artifacts and to negotiate with the user how her artifacts should be named. With this in mind, the founder approached question four.

  1. How do we name the item types and data fields in a way that recognizes the rigorous scholarship in everyday writing and literacy that informs the museum but also works for a user who may not be versed in that scholarship?

As stated above, users have helped the founders renegotiate and rename some of the item types. For instance, in the original item types, the founders defined the item type, “social media,” as “texts that are written for an individual or group and intended for both a specific addressee/groups of addressees and a non-specific public audience. Examples: Facebook posts, open letters and emails, blogs, obituaries, zines, and Pinterest pin.” However, this definition is very idiosyncratic, as many users would not think of texts like obituaries as social media. After user feedback, the founders renegotiated some of the item type categories to be more user-friendly.

After walking conference participants through these questions and the ways in which the founders and administrators attempted to answer them, Enoch offered the following heuristic for conference participants interested in creating their own online archive:

Archivist’s Abilities and Resources

  • How do scholars in your field discuss your type of artifacts? What key terms do they use? 
  • What models do you have for your archive? How do those models structure their metadata?
  • Will users or administrators require supplementary texts?
  • How will the creation of your metadata incorporate feedback from users or other resources?
  • What are the constraints and affordances of your content management system?

Archive

  • What kinds of artifacts will you archive? What information will users need about the artifacts? How will they use the artifacts?
  • What are your archive’s goals?
  • How will the archive be administrated? Will there be multiple administrators?  How will administrative work be distributed?
  • Do you have physical copies of the artifacts?

Users

  • Who are the archive’s users?  What will the users want or need from the archive?
  • What kind of background will users have with archives and/or your type of artifacts?
  • How will users participate in the archive?
  • How do you imagine users working in the archive?
  • How will users search the archive? What search terms are they likely to use?

 

Panelist: Amy Cicchino

Title: The Museum of Everyday Writing: A User’s Experience

            Cicchino spoke from the user’s perspective, articulating the ways in which the Museum enables (or not) users to enact the identities of creator, curator, and/or consumer. She quotes Joy Palmer in emphasizing that neither the archivist nor the user has a neutral role in an archive and “that together the participants are more knowledgeable about the archival materials than an archivist alone can be” (Palmer). With this in mind, Cicchino discusses her experience with being a participant in the Museum. She discussed the style guide that Keaton, Enoch, and Marshall composed to help new users understand the item types and their metadata. While this resource helped to an extent, the founders were able to improve the style guide with feedback from Cicchino and her fellow graduate student users. The first draft of the style guide was composed as an 18 page Google document, organized first by the Dublin Core metadata, then the metadata common to all item types, then the metadata specific to each item type. The organization and lack of searchability proved difficult for Cicchino and her colleagues. Moreover, because the Museum did not have exhibits at the time, these new users had no models to follow; while this gave the users complete control over composing and organizing their exhibits, this also meant there was little consistency across the exhibits that users composed. The conversations between founders and this first round of users helped both parties in that users could ask for direction from the founders and offer important feedback about the Museum and the style guide to the founders.

            After the piloting with and feedback from the graduate student users, the founders – along with two undergraduate interns – revised the style guide, moving it from a Google document to a Wordpress site. Now, the style guide is organized by item type, so that each item type page is organized by the tabs users will encounter on Omeka while uploading an artifact: Dublin Core, Item Type Metadata, File and Tags. This means that users no longer need to scroll through the metadata of item types they don’t need. Also, adding hyperlinks at the top of each page allowed users to immediately jump to the part of the style guide they need. The variety of exhibits contributed by the graduate student users also enabled the founders to identify guidelines for creating exhibits, information that is now included in the style guide. All of this, Cicchino argues, makes the Museum more transparent and manageable for users. As the user base now includes graduate students, undergraduate students, faculty, and the family and friends of the founders and adminstrators, this transparency and manageability becomes even more important.

However, there are still two points of tension for users in terms of using the style guide: first, users must occasionally employ exact terminology so items can be effectively tagged and connected, and second, everyday writing is so capacious, the founders and administrators cannot list every potential genre and tag while still maintaining navigability and order for the style guide. This means that, though the founders provide direction and examples of tags, the user is left to write his/her own if the tag the user needs is not provided. Also, there is some ambiguity about the boundaries between artifacts. For instance, Cicchino struggled with choosing an item type for a recipe card. Given the the artifact is a card, it could be assigned to the item type category of “Letter, Message, and Announcement.” However, it could also be identified as a list of instructions and, therefore, fall under the item type category of “List.” In these moments, the user situates the artifact and the founders and administrators must decide if the situation calls for (a) more clarification in the style guide, (b) the creation of a new item type category, (c) the founders or administrators overriding and revising the user’s chosen tags for the artifact, and/or (d) some other course of action.

Using these experiences in trying to balance user participation and archivist control, Cicchino offers the following heuristic for participants to consider when designing their own online archives:

Archivist’s Abilities and Resources

  • How does technology support or disrupt the participation of the user in the archive?
  • How will provided resources ease this relationship?
  • How will a balance be created between a user’s need for extensive tagging options and a system’s need for a limited number of tagging categories?

Archive

  • How are the goals of the archive communicated to the user? Which goals are negotiable and which are fixed to the identity of the archive itself?
  • When coming to a point of conflict with a user’s contribution, how will the archivist move forward while still preserving the archive’s goal to distribute agency?

Users

  • Who are the people participating in this archive and what experiences and knowledge do they bring?
  • In allowing users to contribute to and curate the archive, how much control will the archivist retain and how much control will the user be given?
  • When users have to make uncertain tagging decisions, what resources will guide them?
  • How will resources consider all kinds of users and the various experiences (or lack thereof) that they bring?

 

Question and Answer Period

            The question and answer discussion time was preliminarily focused on the balance of user participation and archivist control in terms of metadata. Specifically, the panelists and conference participants discussed the ways in which folksonomies – user-generated and -vetted taxonomies – might already exist and could be incorporated more fully into the Museum. Folksonomies are already part of the Museum as users can select the item type that best fits an artifact and can include whichever tags they wish when uploading an artifact. At the same time, administrative access must be given to a user in order to upload and tag artifacts. In the future, it is possible that tagging will be opened to all Museum visits. This was an option that had been discussed by the founders early on, but they felt that the Museum needed to be more solidified prior to allowing all users to tag artifacts. The founders, as graduate students, will all be moving to different universities within the next year, while the Museum will continue to be administered and maintained by graduate students and undergraduate interns at Florida State. New administrators may choose to open tagging to all user and/or allow for more extensive user participation in other ways.

 

 

Works Cited

Palmer, Joy. “Archive 2.0: If We Build It, Will They Come?” Ariadne 60 (2009).

 

 

Session abstract or description: 

The Museum of Everyday Writing is designed to blur the boundaries between the academic and the everyday; however, we found that the technology accessible to us as non-coders favored categorization and hierarchical boundaries. Using a pilot version of our Museum, this panel will analyze the choice of Content Management System, construction of metatadata, and experience of user participation, demonstrating how we employ technology to balance these tensions and to generate multiple layers and levels of connectivity.

Session type: 
Panel
Session hashtag: 
j2
Session room: 
Pioch 117
Session time: 
Concurrent Session J
Proceedings participation: 
yes

Comments

Links to PDFs of the heuristic handout and the powerpoint slides can be found here.