Harvard MOOC story - Part 2.
Week 1 Take-aways:
First, a point to be clarified: The MOOC runs from October to April. I’m not sure why it’s split into 8 “weeks,” but I’ll just go with it. I did find out that having a Week 0, which I thought was a great idea for getting the feet wet, is actually just how programmers talk. They count 0-7, rather than 1-8, for this 8-“week” course. I could see potential problems when a student in “Week” 7 puts off a project, thinking he/she has more time to do it, but by that time, if you don’t understand how programmers communicate, you probably haven’t been paying enough attention to the course. Now may the tips commence…
- Make sure your students know the depth of understanding that is necessary to prepare themselves for the lesson. They shouldn’t have to ask, “Do we need to know this?” because you’ve already outlined the learning outcomes and objectives. As I started watching the first lecture video of the week, I felt like I didn’t know what I needed to learn. I was paying attention to the information, and I understood the explanations of coding, but I felt like I was being given a bunch of stuff to hold, which may or may not be useful later. “Should I be taking detailed notes over this, or will just watching the video and using the online transcript be enough to accomplish this week’s task?”
- Help your students by always making the lesson’s problem – the reason for doing the lesson – the first item they see. As I worked through the week’s problem set, I realized that there were many tiny things that I hadn’t paid enough attention to, because I didn’t realize their relevance. It was VERY difficult to track down these pieces of information in order to make my program work. This is probably a dropping off point for many students enrolled in a MOOC, who realize that they may have gotten in over their heads. The setup of each week’s materials is: Lecture 1, Lecture 2, Walk-Through (recitation), Problem Set, Shorts. Being linear-minded, I worked in that order, and that was my problem. I didn’t know what I was solving until I was on step 4 for the week, which is bad course design.
- If you post class lecture videos for online students, edit out the unnecessary parts. A contributing factor for my difficulty was that the video included a lot of extraneous information that added to the appreciation of the topic (a longer-than-necessary video about a NASA rocket exploding because of some bad code), or that didn’t apply to me as an online student (announcements about on-campus activities). My “Does it matter?” filter had to be switched on and off so many times that it ended up being stuck somewhere in the “Maybe” zone. Online material is, perhaps unreasonably, expected to be streamlined and focused. Once the students start tuning out part of a video, this becomes more and more likely for the rest of the information.
- Make sure online students don’t feel like second class students. Especially from the announcements about things like the lunch-time pizza programming sessions on campus, I felt a bit left out and forgotten. I realized that throughout the 6 hours of lecture and recitation videos from Week 0 and Week 1, the 100,000+ online students had never been addressed directly. Although it is completely accurate to say that we are piggy-backing onto this “real” course and are in no way entitled to any special favors from Harvard for gracing them with our unpaid enrollment, that’s not the case with most online courses. So if you teach an online course that uses lecture video from a face-to-face class, make sure you are aware of your online viewers while you lecture, and let them know that you are making considerations for them and their learning.
- Don’t skimp on the second helpings. The “Walk-Through” recitation lecture seemed disjointed from the main lecture. Or, rather, it’s like the recitation wasn’t aware of what information was covered in the lecture, so it was being covered again, rather identically. It took me awhile to decide that this was good. I was getting a double dose of the most important aspects, so it was probably better for retention in the long-run. What I remembered from the lecture was reinforced. What I didn’t remember from the lecture stood out as a gaping hole, which I needed to make sure I fixed this time around. I don’t think this would be as effective if the same person gave the lecture and the recitation, though, because then the experience is likely to be 100% identical and would seem too redundant to students. The second dose needs to be a slightly different flavor.
- Short videos for “just-in-time learning” – Another way that CS50 achieves this extra helping (that may be a pun), is to have “Shorts” videos, which are quicker explanations of specific topics. They are basically the same as what was said in lecture, but by a different person. They are probably accessed by students who realize that they just need help on this one idea and don’t want to find it in the big lecture video. If, quite understandably, it is too much work to create separate videos for each part of a lecture, at least provide an outline of the lecture video with time-codes noted, so that students can more easily find what they need.
- Giving students enough information to get started, then augmenting it as they need more help, makes the lecture video a much more active learning process. The repetition of the material in recitation let me work slightly ahead of the walk-through lecture. I already knew how to solve many of the programming issues posed, but when I got stuck, along came the recitation to give me a nudge, and then I was off and running again. Students who want a challenge get to work ahead with a safety net. Students who aren’t there yet can take smaller steps with the video.
- Bad examples are good. When writing programming code, the visual setup is important. Instructors showed several examples of a “bad style,” which made the perfectly functional code difficult to read and understand. Don’t assume that students will pick up on subtleties; show them the difference between good and bad, and help them prevent common mistakes.
- Man your boards. The big selling point of a MOOC is that students can learn from each other, which means that students are teaching each other, which leads to better learning. With CS50, students are encouraged to post “pseudocode” to help their peers understand the coding logic, but to discourage any temptation of copying someone’s code outright. As a result, if students have specific enough question, we need to post directly to an instructor. I posted a question that I felt would only need a quick look, and a, “Oh, this is what’s wrong,” reply, but never got a response. My quick question turned into hours of searching online and back through the video lectures. This was pretty disheartening. If you have 100,000+ students, you’d better have a way to support them all.
- Ask for feedback. Along with the submission form at the end of the week’s lesson, was a survey to get feedback about the course. It asked for information about the types of students in the course, interest level, time commitment, enjoyment… It also asked specifics about how the lectures and walk-through videos were conducted, about whether the discussion boards were helpful, etc. Especially when trying something new, like Harvard is doing with this brand new MOOC, student feedback is important. All instructors should work a few surveys into their semester plans. Equally important, is showing the students how you use it. Instructors should specifically address particular survey items with their students, identifying things that will be changed and explaining why some things are the way they are and will not be changed. Knowing that they are heard, even when not agreed with, helps students feel like an integral part of the course.
That’s it for Week 1 of 7, or Week 2 of 8 (depending on whether or not you are a programmer). Keep an eye out for the next round of sage wisdom gleaned from the dark recesses of Harvard’s CS50x MOOC.