Hi. I’m Chelsea Troy. I’m a computer science educator at the University of Chicago. I’m writing a series about designing my course, Mobile Software Development. You can see all the posts in the “Designing a Course” series right here!
In the last post on this subject, we talked about group work.
This post covers the adaptations I made this quarter to teach my class remotely.
This class is unique because it was born in a remote environment.
No one had taught this class before, so we didn’t have a collocated model to adapt. Instead, the content and format of the class took remoteness into account during planning.
The thing about remoteness, as we have discussed at length before, is that it doesn’t create problems for collaboration so much as it reveals problems with collaboration that already existed, that people in power weren’t noticing.
We have talked about how that impacts meetings and discussions before, and proposed solutions, and adapted those solutions to the classroom.
At the time that I started that work, I attributed the issues with remote meetings to under-investment in learning the tools and caucal collaborative degeneracy. In March of this year, engineering manager extraordinaire Marco Rogers shared another useful distinction:
Marco identifies a tension between people who want to collaborate through documents and people who want to collaborate through conversation.
People absorb information in different ways, and much of our work doesn’t account for all of those ways—so we generate misunderstandings, or lose contributions, by making critical decisions with one method of collaboration on teams where some members do better with another method. We usually don’t measure these losses: but, as we’ve discussed before, if we did measure them, we would realize that they are staggering.
These losses happen even on collocated teams. On remote teams that happens even more because teams can end up limiting themselves to explicitly sanctioned collaboration strategies for a given decision.
We see the same thing in classrooms: people learn differently.
It’s easy to lose folks by designing a lesson with only one learning style in mind. It’s even easier remotely, because students cannot stop the lesson and ask for changes the same way they can an in-person lecture.
But it’s also possible to leverage a remote system to create learning resources that make it possible for everybody to learn.
Tool #1: The Flipped Classroom Approach
In a traditional classroom, we do the lecturing during class and have students complete activities outside of class. This quarter, I recorded a lot of lecturing (especially coding demonstrations) before class and provided the students with videos that they could pause or replay as much as they wanted. Then I accepted questions via chat and reserved the additional time in class for group discussions about larger topics in software engineering.
This approach has a few advantages. First of all, it allows each student to approach the lecture at their own speed. They can pause, replay, or slow things down. They can also ask questions without feeling like they’re blocking or “slowing down” the rest of the class.
Second of all, conducting class this way gives students opportunities to collaborate without forcing them to find additional time to coordinate their schedules. They’re already together in class, so we can use that time for them to pair with each other, or talk about things, or work on projects in groups. This is especially salient because I teach adults, many of whom have full-time jobs and dependents outside of my class.
Worth noting: I didn’t do all of my lecturing outside of class. For some of the broader topics, I kept the lecture in-class. I had two reasons.
First of all, unlike coding demos where folks have individual questions like “My XCode won’t do ABC” that are likely to be just their individual project, student questions about broader topics like “How to approach debugging” tend to have answers that are applicable for everyone.
Second of all, my class fell from 17:30-20:30 Central Time—right on top of people’s dinner time in every U.S. time zone. So we’d assemble for some announcements, then write code for about 40 minutes, then take a 12 minute break to prepare food. After that, I would do some lecturing. This gave students an opportunity to sit back, watch, and eat their food. After that, we’d go into group discussions.
Tool #2: Sharing an Agenda for each Session of Class
I made detailed session notes in a Google doc and published those before each session, so students could look through the plan ahead of time.
Early on, I planned on posting session notes after class, so that if I had to change them on the fly, the students wouldn’t know I had “messed up” on my timing. But I spoke to Valerie Aurora about this choice when I took her workshop about teaching inclusive and engaging online classes. We decided that the benefit of the students having the session notes ahead of time and during class outweighed the drawbacks of them knowing if I had to change the plan in flight. Sure enough, a couple of students felt much less stress about class when they could see what we were going to do ahead of time. These were chiefly students who generally felt that they collaborate better through documents than conversation, as per Marco Rogers’ point above.
I enabled comments on the session notes. This allowed students to ask questions, add links to relevant materials, and (in some cases) correct my typos :). Although I am intrigued by the arguments from schools of thought that encourage students to take collaborative notes during a lecture, I did not end up graduating to allowing students to edit the notes. Here’s why: for every constructive comment, I got at least one accidental comment like “So-and-so replaced [extensive outline of a lecture portion] with “;”. These were pretty clearly just mistakes where a student had highlighted something (maybe to copy it or come back to it) and hit a key by accident. I could reject these changes easily. It would have been harder to notice that after it changed the document and dig through the history to change it back.
Tool #3: Focusing on Accessibility
I made sure that all pre-recorded lectures had captions. The school also hired a live captioner for my course. In addition to that, I recorded all sessions and published them with captions after the fact. This allowed folks to revisit concepts on their own time, even if I had presented them live.
I ensured that every lesson had some sort of written documentation and some sort of oral documentation for students to reference. Student video projects were also required to have captions so that other students could see what other students were saying. We treated accessibility in iOS and Android Development as first-class topics, with their own lectures, examples, and projects.
There’s still more to do here: I have some stuff I want to study about captions and image descriptions, and I need to get a better understanding of the accessibility tools built into IDEs for low-vision engineers. That said, the students in this class seemed pleased with the accessibility of this course’s material relative to other courses.
Tool #4: Enabling Synchronous and Asynchronous Participation
I had students scattered across all kinds of time zones, and some of them could not always participate in class discussions and projects. Though I originally planned on grading students on their participation in these activities, I changed the plan.
First, I made it so that all students could earn full participation points either by participating in in-class discussion and taking the allotted session time to fill out course surveys, or by typing their thoughts into an asynchronous discussion thread, or filling out the surveys, later.
This ended up requiring too much work of me; for example, I needed to notify students who could not attend of the location for their asynchronous participation. Basically all the problems stemmed from treating synchronicity as the default. So instead, I made asynchronous participation the default and gave students in-class time to do things synchronously. For example, students would have homework assignments where they needed to complete some features for an app, or draft a code of ethics for themselves, or fill out a survey about session techniques. I graded these like homework, but I allotted time in the class before they were due to watch the videos/ask questions/write code, or have discussions about engineering ethics, so students got synchronous opportunities to do their graded work.
One last thing: I spend very little time on slides.
Some teachers produce beautiful slide decks that make me green with envy because my slides look like this:
I’m not green enough with envy, though, to go back and spend time on slides. Slide beauty is the thing that I consciously dropped to make time for planning lectures, releasing lecture notes ahead of time, reviewing student feedback for each session, and planning interactive activities for them.
I only include this section in the post to emphasize: good courses take immense amounts of time and effort to plan and execute, especially remotely. As a teacher, your time is limited, and something probably has to give. It doesn’t mean you’re a shite teacher. (Maybe I am separately a shite teacher, but if I am this is not the reason 😂).
If you liked this piece, you might also like:
The debugging posts (a toolkit to help you respond to problems in software)
The Listening Series (Prepare to question much of what you know about how to be good at your job.)
Skills for working on distributed teams (including communication skills that will make your job easier)