Curating Community Voices: Presenting Oral Histories in Digital Format

Written By: Greg Lord

This toolkit provides a path to curating oral histories digitally with specific features such as selected quotes, an index to the interview, and other features. It has grown from building a sandbox website that curates oral histories from four distinct projects with specific digital platforms and tools. The toolkit also gives more general steps for preparing for interviewing and for curating of the interviews for digital presentation. Finally, it gives the pros and cons of using a range of specific tools.

1. Planning for Presentation Goals

Photograph of a brainstorming session from Dr. Poiger's class, highlighting the features of a new oral history project.

When planning a new oral history website, it is helpful to begin by thinking about the particulars that will go into presenting your project and content. Some background questions might include:

  • What kinds of oral history content does your project include?
  • What particular or unique goals do you have for presenting your project?
  • What unique challenges does your content pose?

The answers to these questions will help you to define and shape your data structures–the data types you will choose, which metadata fields best match that data, and what relationships will exist between the different parts of your data.

Thinking about your content in terms of both how your data is structured will also play an important role in shaping how it will be best presented, making sure the most important parts of your interviews are not only visible to the reader, but well-organized and accessible as well.

2. Tools & Software

Reckonings makes use of a number of digital tools, platforms, and software in creating our oral history materials, ranging from installed computer software to mobile apps to subscription software services. Below is a list of the services we would recommend based on our own experiences:

Audio Recording/Editing

  • Audacity is a simple audio editing software that lets you both record and edit audio from your computer. Audacity is free and open source, and is downloaded and installed on a desktop or laptop computer. Recording with Audacity requires a microphone, which can be either your built-in computer microphone (although this is not recommended for best audio), or plugged into your computer via USB or auxiliary cables.
  • Alternatives to Audacity include:
    • Desktop/Laptop: Adobe Audition, a paid subscription software as part of the Adobe Creative Cloud service. Audition is essentially the same type of software as Audacity, although it offers a number of powerful features for advanced audio editing.
    • iPhone: Apple Voice Memo offers basic audio recording, which can be used as a simple recording setup.
    • Android: Easy Voice Recorder is a similar app to Apple Voice Memo for Android users

Cloud Storage

  • Google Drive/Workspace
  • Microsoft OneDrive
  • Cloud storage is an essential tool for storing, sharing, and backing up your project’s data. While video and audio recording projects often use large amounts of data, storing these only on physical media invites a dangerous point of failure as hard drives age and begin to fail. Storing these files on the cloud with services like Google Drive or Microsoft OneDrive offers a far more reliable backup solution, and also gives you and your team a convenient way to share and access files.

Transcription

  • OtterAI is a subscription service that lets you upload and automatically transcribe audio recordings, turning them into text transcripts that can be reviewed, edited, and downloaded. Transcription can be one of the most time-intensive tasks in working with oral histories, and automated services–even though they require close review and correction–can be one of the most useful time-saving tools in a project cycle. Once a transcription has finished, Otter’s user interface lets you play back through the audio recording with a synchronized interface that highlights words as you listen, and lets you click on words in the transcript to jump back and forth in the audio. This can be extremely helpful in reviewing/correcting particular sections, as you can jump right to the words in question quickly and easily.
  • One important note:
    • While OtterAI does a great job of transcribing overall, it still absolutely requires close human review. Not only are there frequent general errors that need to be corrected, but Otter also cannot reasonably understand nuanced or subject-specific information–things like acronyms, proper nouns, locations, etc. Reviewing and correcting these transcripts should always be budgeted for in terms of project development time!

Data Collection

  • While storing files in cloud storage is a great backup and access solution, it does not always simplify the task of cataloging and organizing your content. For this, we recommend a metadata spreadsheet, which can be made using things as simple as Google Sheets or MIcrosoft Excel.
  • In the resources section of this toolkit, you will find our general metadata spreadsheet used as the basis of each of our Reckonings projects. You can use and adapt this to catalogue your own items for your oral history project.

Web Platform

  • For the most part, Reckonings uses Omeka S as the backend web platform for our oral histories work.
  • Omeka S is a free and open source content management system software, installable on any web hosting environment (see more on web hosting below). Once installed and set up, Omeka S lets you create sites, items, and pages that can be displayed in a number of different contexts on your website, as well as making them easily accessible to, and shared with, other scholarly collections if desired.
  • See the “Working with Omeka S” section below for more information about our Reckonings workflows.

Webhosting

  • When building a website, the service that provides the software, storage, and internet accessibility for your website is called a web hosting provider. These services offer you (private and secure) space on a shared hosting server where you can install software, configure settings, and host your website.
  • At Reckonings, we use Reclaim Hosting (www.reclaimhosting.com) as our service of choice, although the tools and workflows we describe here would be compatible with most hosting services.
  • While web hosting runs the gamut in terms of hosting fees, fees for an average Reclaim web hosting configuration and domain name are reasonably affordable, often costing less than $100 per year.

3. Metadata Spreadsheet

An example metadata spreadsheet

In both the planning and development of a project, a metadata spreadsheet serves as an important basis for tracking your collection’s items and their related metadata. This spreadsheet should be treated as the project’s authoritative record–what items the project holds, what metadata values and media files those items contain–where the web platform itself is the visual representation of that data. In this paradigm, all edits or additions should happen in the spreadsheet first, and then be added to the web platform environment as a reflection of those changes.

The format of this spreadsheet uses metadata vocabulary terms for each of its column labels. This naming convention not only makes it obvious which fields refer to which metadata properties, but it also allows the data to be used by automated data-ingest processes in various platforms.

In the case of our Omeka S projects, each column’s header matches our Omeka S items’ metadata fields, allowing us to import the entire spreadsheet into our site in a single operation. (Note: this functionality is not available in Omeka S by default, but can be added via a free Omeka S module called “Bulk Import.”)

4. Data Modeling Principles

The first step in developing a project is deciding what data you want to store and display, how that data is structured, and how that data interrelates. This process is called data modeling, and is the basis of how everything will be built and displayed in our web presentation.

Interview example from the Curating Oral Histories website

As our example project (see “Curating Oral Histories: An Example Project” below for more detail), a website displaying multiple interviews belonging to multiple projects might define the following as the basic Item types:

Person

We can define a Person separately from an interview, as that person may potentially appear in multiple roles across multiple interviews, and defining them individually allows us to refer to this single record each time they appear across the site.

A basic definition of a Person might include their name, title, institution, biography, photograph, and so on.

Project

A Project, like a Person, is defined in advance so that each of our Interviews can potentially tag that project as the parent project they belong to. This item definition might include the name, description, project URL, and an image logo.

Oral History

This Oral History item is the central workflow of our example project, where all of the fields that make up our Interview items can be defined in advance, ensuring that each Interview shares the same fields. This shared data structure also lets us know what data we will have when designing our project’s interface, letting us reliably structure a single visual design that will work for all of our interviews.

As a specific example, our Reckonings Project Oral History data model includes the following metadata properties–the fields used to most accurately capture each part of our oral histories’ data.

  • Title
    • Dublin Core, dcterms:title
  • Description (Summary)
    • Dublin Core, dcterms:description
  • Date
    • Dublin Core, dcterms:date
  • Subject (Tags)
    • Dublin Core, dcterms:subject
  • Spatial Coverage (Interview Location)
    • Dublin Core, dcterms:spatial
  • Rights
    • Dublin Core, dcterms:rights
  • Rights Holder
    • Dublin Core, dcterms:rightsHolder
  • Interviewee
    • Bibliographic Ontology, bibo:interviewee
  • Interviewer
    • Bibliographic Ontology, bibo:interviewer
  • Relation (Related Oral Histories)
    • Dublin Core, dcterms:relation
  • References (Related Links)
    • Dublin Core, dcterms:references
  • Abstract (Selected Quotes)
    • Dublin Core, dcterms:abstract
  • Table of Contents (Time-coded Index)
    • Dublin Core, dcterms:tableOfContents
  • Is Part Of (Related Project)
    • Dublin Core, dcterms:isPartOf
  • Contributor (Curated by)
    • Dublin Core, dcterms:contributor

As you can see above, we use the universal Dublin Core metadata for almost all of our fields, extending into other vocabularies only where necessary for very particular fields (in our case, Bibliographic Ontology’s terms interviewee and interviewer).

We make use of the most semantically-appropriate metadata properties for each of these fields, but can then make use of custom “labels” for those properties to provide more meaningful human-readable names as well. For example, the time-coded index feature uses the Dublin Core “Table of Contents” property, as this is functionally equivalent to how the time-coded index is used on the interface. The “Is Part Of” property functions in a similar way, giving us a chance to define what Project the interview belongs to, if any.

Once your data model is defined, the next decisions include which web platform to use in building the website, and what workflow you will use in creating the interviews and then adding and ultimately visualizing them on live project pages.

5. Process Overview

The following is the start-to-finish process used by the Reckonings team in creating a new oral history for display in our web platform:

1. Planning the interview

This step includes all of the coordination and logistics involved in setting up an interview for inclusion in the project. This might mean coordinating the time and place with the interviewee, coordinating and preparing the location of the interview, finding and preparing any needed equipment, and preparing the goals, topics, and questions.

2. Permissions for archiving and exhibiting an interview

It is important to plan for the release of any needed permissions from the interviewee that relate to the archiving and exhibition of the interview. This includes sharing the audio on the website, sharing video (if any) on YouTube (with or without “listing” the video as publicly discoverable), and sharing the interview transcript. These permissions should be discussed and made transparent, and then documented with the appropriate signed consent and release forms. These documents should also be carefully stored and archived with the project materials.

3. Recording the interview

Upon conducting the interview, it is important to make sure that all technical factors are accounted for, and that all of the equipment is adequately prepared, powered, and tested. Other factors to consider include:

  • Adequate storage space on the recording device
  • Any equipment limits (such as recording duration limits on audio software or camera video recordings) accounted for and tracked during the recording
  • All recorded files immediately transferred from the devices’ storage to cloud-based storage and any external physical storage.

4. Transcribing the interview

Transcribing audio files can be one of the most time- and labor-intensive parts of preparing an oral history for a web presentation. In Reckonings’ case, we make use of a commercial service called OtterAI to automate the first pass of the transcription process. While this can be a powerful time-saving process, it is important to note that AI-generated transcripts require close human review and correction. In addition to the normal glitches that occur in automated transcription, tools like Otter also lack the context for transcribing content that is very particular to the interview itself–things like proper nouns, acronyms, locations, organizations, etc. All of these should be carefully reviewed by people familiar with the subject matter, and edited for both accuracy and clarification.

After reviewing and correcting the transcript, we save the final text as both a PDF (for easiest reading in the site’s PDF viewer) and plain text (for easy searching and indexing the web platform). These two files are stored alongside the recorded audio as the other central media items.

5. Creating metadata for the interview items

Once the transcript and audio files are prepared, the media files are ready for upload to our web platform. But before doing this, we must create the Oral History items that they will be associated with. These Oral History items include a number of metadata fields that describe the details and related people and projects for the interview.

To help track all of the files, fields, and relationships for our items, we make use of a metadata spreadsheet, which acts as a central authoritative resource for all of the contents of our project.

The fields in this spreadsheet mirror our data model and our web platform’s data structure, ensuring both stay in alignment.

See the “Metadata Spreadsheet” section of this toolkit to find a shared copy of our metadata spreadsheet that you can use as a starting point for your own.

6. Adding items to the web platform

Once the metadata spreadsheet is prepared, we can begin adding the items and their related media items to our web platform (in our case, Omeka S). This process involves either manually or automatically (via a data ingest process) creating a database item for each of our interviews and their related items (related projects or people), and adding each of our metadata fields and any related media to each of those items.

7. Tagging related materials for the interview

Finally, once all items are added, the last piece of our overall data structure involves building the links between items themselves. In our case, this means going back through any Oral History items that we would like to link to one another, and add them as “Related Oral History” links in one another’s item definitions. We can also ensure that the Oral History items properly refer to the right Project items as their parent project, as well as referring to the right Person objects for the Interviewee, Interviewer(s), and Curator(s).

6. Media Formats

Transcript (PDF)

Perhaps the most important part of the interview content is the text transcription of the interview itself. As part of the process of creating our interviews, these transcripts are created and edited as Google Docs, where our team can collectively edit and review them. Once finalized and approved, we export them as PDFdocuments for use on the website.

Importantly, the plain text version of these transcripts serves an important purpose in our web presentation as well, giving us an alternative transcript format that is both searchable and indexable by our web platform. (See the “Curating Oral Histories: An Example Website” section below for more information about how this is used.)

Audio Player

Interviews are recorded in a high-quality lossless format (WAV) for editing and preservation purposes. Once any required audio editing (such as adjusting volumes or removing background noise, etc.) is finished, these interview audio files are exported as MP3 formats, which greatly reduce the file size for use on the website.

YouTube Player

To ease the burden of working with large video files, our project team made the decision to support only YouTube videos, given that this lets us store the videos externally in YouTube’s own storage, and can then embed the video on our project website directly as a YouTube video player. This both alleviates the need to store and load large files, and gives us a video player that is reliable across all browsers and devices. (See the “Curating Oral Histories: An Example Website” section below for more information about how this is used.)

If our interviews include any recorded or existing video, these videos are cleared for permissions and, once authorized, uploaded to YouTube either as public or “unlisted” videos, both of which allow us to embed the video player directly on our own website.

7. Choosing a Platform

While our specific project examples use Omeka S, there are other viable alternatives depending on your project’s goals. Within the Reckonings Project team, we often make use of Omeka S and WordPress for these types of web development projects. The pros and cons of each of these tools are detailed below.

A number of other tools exist as well, including:

  • CollectiveAccess, a free and open source software for cataloguing and publishing museum and archival collections.
  • Islandora, a free and open source Digital Assets Management environment

Omeka S Pros

  • Omeka S allows you to create Items that have archival metadata, ensuring that the data about your data is preserved along with the objects themselves.
  • Simple web pages can be set up quickly/easily
  • Multiple “sites” can exist in one Omeka S, letting you share and reuse items across, for example, multiple projects, multiple courses, etc. These items can also be shared between users
  • Free and open source

Omeka S Cons

  • Omeka S is visually relatively plain and simple. Custom designs and layouts/interfaces are possible, but hard to develop
  • Multimedia support (video, audio) is relatively basic, limited to basic formats and built-in players
  • As a much a smaller platform than alternative such as WordPress, there is a much smaller community of development and discussion around Omeka S. This can make it harder to find answers to questions, or examples of workflows.

WordPress Pros

  • Also free and open source
  • In design and layout terms, WordPress is incredibly flexible. It allows for more easily creating traditional site content (pages, image galleries, etc.) than Omeka S
  • Theming (customizing the web design of a site) is easier and the large WordPress community offers a much greater variety of premade visual themes than Omeka S
  • There is a much broader range of third-party tools (plugins) for WordPress, to add and customize features for the site
  • WordPress has a much larger community, which means more documentation and searchable answers

WordPress Cons

  • WordPress does not offer any of the scholarly collection features or metadata offered by Omeka S. With no built-in concept of structured metadata, linked entities, or metadata vocabularies, WordPress does not directly support the type of scholarly data structures that Omeka S uses as part of its central design.
  • WordPress is a very deep tool to learn, and can be considered as “beginner-unfriendly” as Omeka S

8. Working with Omeka S

Our Reckonings team chose Omeka S as the best mix of the essential parts of our projects’ development–specifically, a strong focus on the scholarly collection-focused metadata structure, and the flexibility of offering custom theme development to let us work around the limited display capabilities by developing our own visual frontend.

  • Omeka S is a web publishing platform for items, exhibits, and collections.
  • As a content management system (CMS), Omeka S helps you organize and display your website’s content.
  • Omeka S is free and open source, meaning it is developed under a free public license and anyone can freely download, share, or contribute to the source code.
  • Omeka S is a server software and must be run on a web hosting server, rather than one’s own computer.
  • Omeka S lets you develop your own visual “theme,” offering you the chance to program your own interface and layout using traditional frontend web development practices (specifically via HTML, PHP, Javascript, and CSS development). While this requires a deeper technical understanding and investment in the project, it offers a chance to develop one’s own best solution to any visual design goals.

9. Omeka S Resource Templates

When adding Items to Omeka S, we can apply our data model (see “Data Modeling Principles” above) by defining types of items using the particular metadata fields we have chosen. To do this, we make use of what Omeka S calls “Resource Templates.”

Resource templates act like a blueprint for our items, allowing us to customize a data structure that will provide all the fields we require whenever we add new items. The fields used a resource template are chosen in advance and define all of the metadata terms and properties that we use to define our collection.

Per our data model, in the case of our Curating Oral Histories site we define the following item types in our Resource Template things:

Person

We can define a Person Resource Template to add all of the related People to our items, in fields that define their role as either Interviewee, Interviewer, or Curator. Editing a “Person” item will automatically update it across the website in any place that Person is displayed.

Project

The Project Resource Template defines the name, description, and URL for a project, along with an image of its logo if provided. Like “Person,” this gives us a single place to define a project that can then be updated across the entire site.

Oral History

The Oral History Resource Template is the central workflow of our project, including all of the fields that make up our Interview items. Using this Resource Template also ensures that we can create a custom Omeka S theme that knows what fields to look for, by name, and then knows how to display them based on the theme’s code.

See “Data Modeling Principles” above for the specific fields that go into our Oral History Resource Template.

Relationships Between Items

In terms of the relationship between these three Resource Templates, we can define our structure as:

  • A Project item can own multiple Oral History items. (In functional terms, this is created by choosing the Project item in the “Related Project” field of the Interview item itself.)
  • An Oral History item can tag multiple Person items in different contexts. (The “Interviewee,” “Interviewer,” and “Curator” fields all let us choose “Person” items as their value, letting us tag those people as those roles.)

Given these relationships between our Resource Templates, we can prepare our custom Omeka S theme to do the work of including the details about any related items when displaying our Interview items on the page. This means:

  • The “Project” item will display its name, description, and logo on our interview page. (And our theme even allows for things like defining per-project theme colors based on which project is tagged.)
  • The “Interviewee” item will display a full biography block for the interviewee on the interview page
  • The “Interviewer” and “Curator” blocks will display a similar biography block on the interview page.

10. Curating Oral Histories: An Example Omeka S Website

As an example of a scholarly collection website, Reckonings developed “Curating Oral Histories” in Spring 2026, centering around a collection of interviews belonging to four different research projects. This site made use of Omeka S as the website platform.

In designing the web interface for these projects, Reckonings Co-PI Dr. Uta Poiger worked with course students to identify a number of central display features designed to make the oral histories both accessible and easy to explore. In the following section we explore each of these features by their utility and implementation.

1. Project Identity

As discussed above (see “Data Modeling Principles” above), one of our first efforts involves modeling the structure of a Project, to be used as an item that our Oral Histories can belong to.

In Omeka S terms, this involves creating a “Resource Template” called Project, that records basic information about a project that can be included whenever a viewer navigates to one of that project’s interviews.

This also allows us to group interviews together by their larger project in a variety of ways:

  • A color-coded header is added to each interview page, allowing for an easy at-a-glance visual association with the project
  • An information block about the larger project is automatically added to the page footer
  • A “Part of project” link is added to the interview page, linking out to that project’s website
  • The data structure lets us easily create a list view of all oral histories that are part of that project

2. Summary Block

The next data model is the Oral History item itself, which provides a list of fields that describe all of the data our team wished to include about each interview–things like the title, description, selected quotes, subject tags, etc. The “description” field is used as a Summary block, a short paragraph of text shown at the top of each of our interview pages, giving the curator a chance to offer a brief overview of the interview, giving readers an upfront context about the subjects or people involved.

In Omeka S website, we implement this data structure by way of another “Resource Template” called Oral History,with the fields above as the structure.

3. Interviewee (Biography Block), and

4. Interviewers/Curators (Biography Blocks)

As a final data structure our project defines a Person by a number of fields, allowing us to then associate a single person to potentially many different roles or interviews, while only needing to add them to our site once.

The data model we defined for our Oral History items offers three different places to choose any “Person” as a field value: the “Interviewee” field, where we can add the biographical information about the interviewee on an interview page, and the “Interviewer” and “Curator” fields, where similar information will be shown about the people in each of these roles.

In our Omeka S Oral History Resource Template, we associate this Person item as the value of each of those three fields, letting Omeka S keep track of the relationships between our Oral History and Person items, and letting our Omeka S theme automatically display the information about each of the tagged people when the interviews are displayed.

5. Selected Quotes

Similar to the Summary block, a “Selection from Interview” field gives site curators the chance to choose up a number of quotes that they feel best capture the tone or content of the interview. These quotes can then be displayed on the page above the interview content as an additional bit of upfront context, this time in the interviewee’s own words.

In Omeka S, we build this as a metadata field (Dublin Core “Abstract”, acting as an excerpt) that allows multiple values.

6. Time-coded Index

Long oral history interviews present a difficult navigation challenge for readers who want to find a specific topic or section of an interview. Offering users a time-coded index (essentially a table of contents including the time codes of each section) provides a quick and easy way to navigate through the interview with as much context as possible

As part of our usability goals, we developed a custom Omeka S theme that automatically processes these timecodes to create Javascript links between the timecode and the audio player component, letting readers click these codes to jump the playhead of the audio player directly to that section of the interview.

7. Multimedia Presentation Tools

While Omeka S excels at capturing items and metadata, its multimedia affordances are relatively simplistic and offer little in the way of customization or layout options. To improve upon this, our custom Omeka S theme adds a number of multimedia elements to the website which are included automatically when curators add the relevant types of media to their interview pages. These are:

  • Transcript (PDF)
    Perhaps the most important part of the interview content is the text transcription of the interview itself. As part of the process of creating our interviews, these transcripts are exported as PDF for use on the website.For the most reliable reading experience between desktop and mobile web browsers, our Omeka S theme automatically turns an interview’s PDF documents into an embedded PDF viewer. This includes usability features such as: paged views, zoom in/out, page rotation, download, and print options.
  • Audio Player
    For best reliability between browsers, our Omeka S theme turns an interview’s audio files into a native HTML audio player, allowing for basic controls including play/pause, playhead with seeking, volume controls, and download.
  • YouTube Player
    Handling video files is often one of the most challenging parts of a website’s multimedia content considerations. To avoid these issues, our team decided to support only videos that are available on YouTube, which then lets us display videos both with YouTube’s accessible video player interface, and without needing to host large files on our own website. Importantly, this works equally well for YouTube videos that are published as “unlisted,” offering a useful middle-ground between public and private content where a video can be available to the website but not directly discoverable through YouTube itself.Importantly, this does still require that any videos used in this project are suitable for upload to YouTube, both in terms of content and rights permitted by any owners or concerned parties.

8. Metadata

While many of the fields in our data model have specific single-purpose blocks on the web layout, we also provide a general block called “Metadata” that lets us collect all of the remaining metadata fields that we want to display as additional information about the interview.

In our Omeka S theme, we use this space to show:

  • Subject
    Subject tagging gives readers a way to browse across a collection by topic, allowing for easier exploration of related research materials. In our case, we show each “Subject” field in a list of “tags” presented as link buttons, where clicking any of the tags brings a reader to a page that shows all other interviews that have been tagged the same.
  • Date
    The date of the original interview
  • Place
    The location of the original interview
  • Rights Holder
    The owner of this interview content, if any

9. Full-text Transcript

While the above PDF transcript offers the best reading experience across devices, the PDF format itself can be limited in certain ways–for instance, not being easily searchable on the page, not being indexable across the website, and not easily highlighted for copying sections of the content.

To add those abilities back to this site, our Omeka S theme also includes a “Full-text transcript” block which shows the transcript again in a scrollable window, this time as plain text. Searching for text on this page will work as expected, and, similarly, Omeka S can easily index and search this field so that it returns as a result when a user searches for keywords that might appear in the interview transcript.

10. Associated Oral Histories

Where relevant, a curator can use this field to identify other interviews in this project that have similar content, allowing them to be listed here for readers to find if interested.

11. Links and Resources

Similar to the “Associated Oral Histories” field above, this field offers the curator a place to link to anything else on the web that they feel would be usefully related–perhaps other websites, projects, or related organizations.

11. Visual Design and Omeka S Theming

The visual composition of an interview page should match the priority of the particular details that make up your oral history content. The pages that show your oral history interviews may be the only thing a reader ever sees about those interviews, so any important content, media files, and metadata must be considered and accounted for in the theme files that ultimately display the interview itself.

In the case of our Curating Oral Histories website, our Reckonings team worked together with Dr. Poiger’s students to determine the particular fields we wanted to use, and these fields were then discussed with and approved by the project partners.

From there, the class conducted a whiteboard design exercise, iterating upon layouts that arranged the various elements in the most useful configuration on the screen. The final version of this design was then used as a web design “wireframe,” the basis of the custom Omeka S theme that would produce that layout in code.

(And, as an added bonus, this visual design step also provided the basis for a custom poster design that was used to produce poster-sized print adaptations of the interview pages, which was produced as a template in Canva and shared by the class.)

12. Learning Resources

Resources

Toolkits