Do you like the CTL’s Teaching Online Course Prep Guide, and want to know more about how we made it? Here we document both the technical and human work processes it took to build this guide. We started work on it in April 2020, roughly one month into the stay-at-home order that forced all classes at CUNY to shift to distance learning. This guide is based off of a hybrid course prep guide some of us had created a few years ago, and it is currently in its 3rd edition.
We made this ‘Recipe Book’ to pull back the curtain on some of our own pedagogical design choices. We account for the tools that we’ve used (and why we used them), but also the harder-to-see decisions that we made as a team and that impact how the guide looks, feels, and operates. We hope that learning about how we made this will help you understand the planning, time commitment, technologies, and physical limits you may encounter as you design your own course or other pedagogical projects.
Below, you’ll find a list of the tools that we used to make this guide, along with an explanation of what it was like to use them and why we selected them. We’ve also added some ‘accessibility notes’ for each tool. An accessible pedagogy calls for keeping access centered in the design process, whether we are designing teaching and learning guides like this, or classroom courses. As authors and designers of this guide, we are committed to accessibility (more here), and we want to be transparent about the accessibility features and limitations of these tools.
The guide is hosted on Blogs@Baruch: Baruch’s own open-source platform, which is managed by our CTL colleague, Christopher Silsby. We love this platform because it gives us a lot of flexibility in controlling how the guide looks and functions. We can embed videos, we can add cute buttons, and we can do a lot more customizing than we could if it were hosted on Blackboard. Using Blogs@Baruch also allowed us to keep this guide public and accessible to everyone with an internet connection, with no sign-in or enrollment required. We also wanted the guide to be aesthetically pleasing to use rather than a big old block of text, and Blogs@Baruch allows for this.
Accessibility note: Blogs@Baruch is a WordPress install. According to the WordPress Accessibility page, WordPress aims to make the WordPress Admin and bundled themes fully WCAG 2.0 AA compliant where possible. So while the base WordPress installation attempts to be accessible, not all plugins and themes follow these guidelines and therefore require manual configuration. Additionally, Blogs@Baruch is running the WP-Accessibility plugin by Joe Dolson that adds additional options that may not be included in a theme. All sites, including WordPress sites can be tested on the web accessibility evaluation tool (WAVE) for additional access-testing, and we did so for each page linked on this guide.
These buttons and video were designed with a freemium graphic design program called Canva. While you have to pay to use some features in Canva, you can also design things relatively easily for free.
Accessibility note: We could not find any information on Canva’s compliance with WCAG 2.0 standards. This post on the Canva product site spells out some best practices when designing with accessibility in mind. However, there is some debate amongst Canva users about how much the app highlights and centers tools that make designs more accessible. In our case, we used Canva to design images which we made more accessible by adding alternative-text on the Blogs@Baruch pages. We also designed a (non-speaking) video that compares Blogs@Baruch with Blackboard, and then added an accessible pdf of the script next to it.
After storyboarding out the sound, visuals, and narration for our videos, we first recorded our audio for them. We used a MOVO VXR-10 microphone, which runs about $40 retail and is one of the lower-budget options for a microphone that plugs directly into a cell phone or recording device. However, some of our audio is also recorded directly into an iPhone, and smartphones tend to record decent audio (and video) at a much higher quality than computers.
After recording our audio, we produced the video’s visuals with freemium video-making software called Animoto. While you have to pay to use some features in Animoto, you can design simple videos with images, GIFs (moving images), and transitions relatively easily for free, and you can upload and include your own material, including images and audio (though, as noted below, we were not particularly satisfied with the quality of the audio once it was uploaded—so we used it for reference then re-inserted the audio in iMovie). Users determine how many seconds a slide stays up in an Animoto project before it transitions to the next one, so producing our video involved listening to our audio with a stopwatch and marking the number of seconds each slide should last.
Video Screen Recordings
We took video screen recordings of the Four-Week Guide using Screencast-O-Matic, a freemium screen recorder and video editor. We inserted these screenshots into our Animoto videos.
We were dissatisfied with the volume levels of the audio when we dropped it into Animoto, so we did end up using another software, iMovie (built-in software for Mac devices), to better combine visuals and sound.
Video Hosting/Uploading for Online Streaming
Finally, we uploaded our videos to a shared YouTube account. This was free to do, and within 24 hours of uploading our videos YouTube produces an automated caption.
Accessibility note: Animoto does not include a captioning service, so we relied upon YouTube’s automated captioning software. We have some concerns about the accessibility of Animoto’s interface, and may in the future move to full production on iMovie, which offers more accessibility options integrated with the MacOS.
The Virginia Woolf Teaches Online timeline was created with the tool Timeline JS from Knight Lab at Northwestern University–an innovative technology laboratory that specializes in creating easy-to-use open-source digital tools that usually focus on a single aspect of a presentation and strive to make it as visually appealing as possible–in this case, chronology. We entered the timeline data in a Google Spreadsheet with minimal HTML markup directions, and then uploaded the timeline to our website using the Blogs@Baruch Timeline JS plugin. Images and video were culled from websites that Timeline lists as those it “pulls in” from: Youtube, Flickr, Vimeo and Wikipedia Commons. A couple of the images came from Baruch CTL’s media library and had to be converted to a .jpg format to upload (Timeline only takes .jpg and .png formats). The text is a narrative take, or a case study, of our Four-Week Guide, meant to provide a relatable example of how one professor would go about applying our advice to prep her course.
Accessibility note: Timelines from Timeline JS combine visual and text-based information in a scrollable chronological sequence. Knight Lab is aware of color contrast issues on the front-end of the timeline, and is working on resolving that. We recommend toggling the color contrast tool provided by the WP-Accessibility plugin on the page that the timeline is embedded in to resolve some of the color-contrast issues.
As an office, we use a messaging platform called Slack to communicate with each other. Since some of our team was working on videos, and others were working on the guide text, Slack has been a good way to let our teammates know when something is ready for feedback.
Accessibility note: According to their website, Slack has a multi-year accessibility plan to meet the requirements under the Accessibility for Ontarians with Disabilities Act, which also means that they are actively working to comply with WCAG 2.0 standards. Independent evaluations by accessibility experts confirm this, and some have given a good rating to Slack’s commitment to accessibility.
Before we put the guide on Blogs@Baruch, we work on the text using the word processor tool Google Docs. This tool allows us to give and receive feedback, to make comments, and to suggest changes without needing to send each other multiple drafts. It allows us to work collaboratively on a document at different times and to keep all of the feedback in one place.
Accessibility note: According to Google, the Google Docs editors are designed to work with screen readers, braille devices, screen magnification, and more. This Google Docs support page shows how to use various access devices for editing Google Docs, and this support page shows how to make Google Docs more accessible for your readers.
Production Process and Team
With the exception of our director, all of the people who designed this guide are part-time employees at the Center for Teaching and Learning. We come from different academic disciplines (English, Library Science, Management, Media Studies, Psychology, Sociology, History, and Theatre). We are all teachers. Many of us hold other jobs (or several other jobs). Some of us are currently graduate students. Three of us are parents. This is to say that we do not share the same work schedule. Working on this totally synchronously would have not been possible.
This meant that the production of this guide was, well, complex!
A few things really helped us to find a good rhythm (and have, incidentally, influenced some of us to think about how we can bring the good vibes from this project into our own classrooms, especially since our recent student survey and lots of other data suggests that group projects are hard to pull off in the distance learning context.)
Here are some of the lessons we learned in the process.
When we first began the process of putting this together, we had too many ideas. We wanted to show you alllllllll of the tools. We wanted to link to allllll of the research. We wanted to make a video and a podcast and a timeline and an online guide and run 80 workshops and do one-to-one consultations. Faculty inquiry groups! Glossaries! Interviews with teachers! Oh, and we wanted to do it all before the start of the first summer session. And then we realized that this would be really overwhelming for you, and also for us. So we decided to slow down.
Whether we’re teaching a class, a faculty workshop, a seminar, or making an asynchronous guide, we have to start by determining what we want participants to be able to know and do. This can be hard for us, because we love talking about cool techniques and technologies! Learning goals seem comparatively boring. But when we start with cool content or tools, we always end up creating too much unusable stuff.
Once we slowed down, we decided to take our own advice and determine some concrete goals for this guide. We asked ourselves:
- What do we want people to be able to do?
- If someone is totally new to teaching online, what are the basic things that they must be able to know and do by the end of the 4 weeks?
- If someone is an online teaching expert, how could this guide still challenge them to examine and expand their teaching practice?
- How would we engage learners in multiple ways?
Defining some learning goals and designing our materials to scaffold toward them helped us narrow our scope and made our workload more manageable.
We began to conceptualize the release of this guide like we would scaffold an assignment in a class: we would do the best that we could in the “rough draft” first version, and then improve it each time. So far, we have “released” it three times. This means that we didn’t add polished videos until we released this guide for the third time (the first phase didn’t include them, and the second phase included a really simple one with low audio quality). It means that we still have ideas that we want to incorporate. It means that we are still thinking about how to make this guide more accessible, though this will be part of our process each time we revise. Thinking of the creation of this guide as an iterative process that will continue to improve over time has been a helpful way to keep our expectations in check.
We developed something that we called a “parking lot”: a place to capture ideas that we didn’t have time to incorporate in a particular phase. Before each revision, we review the parking lot items and use them to generate a new to-do list. Then, different members of the team sign up for different items on the list and make self-imposed deadlines for when the work will get done.
Like everyone else, we started experiencing major Zoom fatigue by April. So we decided to mostly work on this guide asynchronously. Our weekly Zoom meetings were reserved for resolving comments and feedback that the team had left between meetings. If there’s a way for two of us to meet about something on the phone, we’ll often opt for that instead of Zoom.
After several members of our team started to experience health consequences from being on the computer for too much of the day (i.e. eye strain, neck and shoulder pain, back spasms, fatigue), we decided to pay more attention to our bodies. One way that we did this was by mandating breaks during our synchronous meetings. For every 25 minutes that we work, we take a 5 minute break where most of us turn off our camera and sound and stretch. Not only does this force us to move around a bit, it can also force us to not get too hung up on details.
In our design process, we had to consider a lot of things. First, we work at a school where classes look really different from one another. We wanted to make something that was flexible enough to speak to everyone without being so general that it wasn’t very useful.
Secondly, we knew that people who are looking at this would have different experiences with teaching online. We wanted to design something that could work for beginners, but also offer something to people who have been teaching online for years.
In many ways, our design process mirrors what many instructors face. Students come to our classes with different experiences with the content that we’re teaching. Some students don’t have the foundational knowledge to start at the same place as others. Some students are excited by our content, others are fearful, and others are taking our course because it is required. Some students want more, and others feel overwhelmed.
To design a guide that appeals to a lot of people, we used Universal Design for Learning (UDL): a framework for instruction that is rooted in disability justice, and so maximizes flexibility so that learners with and from diverse access levels, backgrounds, experiences, interest levels, and knowledges are able to find an entry point that makes sense for them.
Here’s what we did.
We considered perception, language and symbols, and comprehension when thinking about incorporating multiple means of representation. We started with a heavily text-based guide, but then started incorporating closed captioned videos, graphics, and links to a variety of media-rich resources that provided background information when appropriate. The platform the guide is hosted on has the WP Accessibility plugin that allows users to toggle font size and color contrast. Some of us are also writing experts and used that expertise to clarify vocabulary, syntax, and structure, as well as simplify complex pedagogical concepts. We also came to value the principle to highlight big ideas, show relationships, and guide information processing. This led us to present information in ‘bite-sized’ pieces, and keep the sectional structure of the guide consistent, with the same visual markers (icons) guiding information processing. Adding video overviews for each week and for the whole guide also helped us to present the same information in a different way and to reiterate the guide’s goals.
We considered recruiting interest, sustaining effort and persistence, and self-regulation when thinking about providing multiple means of engagement. Throughout the design process we valued and optimized a spirit of ‘self-paced’ engagement with the materials in the guide. We recommend a timeline and a particular path – hence, the 4-week structure to the guide. However, we also designed the home-page of the guide to include all of the weeks at once, including alternative engagement modalities like a timeline, so learners can skip some material or go in an order appropriate for their learning needs. We made sure to design all of the pages in the guide to optimize clarity, reduce unnecessary images, colors, or other media not relevant to the content. Where possible, we invited learners to join workshops, set up consultations, and join an ongoing community of colleagues on Slack.
We considered physical action, expression and communication, and executive functions when thinking about providing multiple means of action and expression. We continue to test all of the pages of the guide through the web accessibility evaluation tool (WAVE) and fix problems as needed. We use closed-captioned videos, timelines, graphics, slide-decks, and other varied media-rich resources wherever appropriate, and not distracting. We think that our approach of ‘bite-sized’ content with consistent signposts, and the 4-week structure (with options for self-pacing) is helpful in goal-setting and managing learning new pedagogical methods and frameworks.
The above enumeration of how we considered UDL principles into our design and work processes does not mean that the guide is fully accessible by all types of learners. Far from it. We acknowledge that this guide may not be the right tool for folks whose learning preferences may not be represented in our design, and that accessibility is an evolving process rather than a “destination.” There will always be more to fix, and competing access needs to work through. As designers and authors of this guide we are committed to making it more accessible. We will continue to identify the UDL areas where we fall short, and work on that. If you have concerns, feedback, and/or want to help us make this guide more accessible, please reach out to us at firstname.lastname@example.org. We thank you in advance for your work.