MOOCs are a victim of the rhetoric peddled by their boosters. The far-fetched claim that MOOCs will eliminate higher education has prompted an enormous amount of backlash. This is unfortunate because the tension between MOOCs and contemporary college classrooms is a false dichotomy.
This posting describes my experience with a web design course that used MOOC-like technologies and "badges" to nurture students in a process of self-directed learning.
Course Overview
At least once a year, I teach a course titled "Interactive Multimedia: Web Design." As with most courses offered in the Department of Communication, this class combines hands-on practice with a healthy dose of communication theory. Students are asked to read essays on a wide range of topics, including: the importance of programming literacy (Douglas Rushkoff), the importance of usability (Donald Norman and Steven Anderson), programming as cultural practice (Ellen Ullman), threats posed by the rapid acceleration of technology (Bill Joy, Ted "Unabomber" Kaczynski), the rise of symbolic labor (Robert Reich), and maker culture (Cory Doctorow).
Students are sometimes disappointed when they are asked to read essays about technology criticism, cultural studies, and metacognition in a web design class. "Can't we just learn CSS and HTML?" they ask. My stock answer is that the process of learning will not end after they graduate from Trinity. If we were to devote all of our time in the classroom to mastering the tools of web production, without any discussion of the broader context in which these technologies are situated, it would be an enormous disservice to the students. In the short run, they might be happy, but in the long run -- when CSS and HTML have evolved into something entirely unrecognizable -- they would realize that they squandered their tuition dollars on a short-lived set of concepts.
It's cliched to point this out, but the rate of technological change is accelerating. It's not just that things are changing quickly; the rate of change is speeding up. How do we prepare our students to function in such a landscape? Two years ago, in an attempt to adapt to the changing landscape, I completely overhauled the web design course and folded in MOOC-like resources along with a badge component.
Course Structure
During the first half of the semester, we cover basic HTML, cascading stylesheets, and basic JavaScript. All of the students are asked to create three miniature web sites -- each site slightly more complicated than the one that came before it. Along the way, we focus on theoretical concepts (e.g. interface design, typography, tools for usability engineering) that cut across specific programming skills.
For example, the empowered user category included badges about Flash Animation, Garageband, Adobe Illustrator, the pesky Pen Tool, Photoshop masks, UNIX, and web server configuration. |
During the second half of the semester, student work outside the classroom is focused primarily on the completion of specialization badges. Students are encouraged to forge their own path through the course material by completing badges from the following categories: coding, industry analysis, graphic design, user experience, power user skills, and entrepreneurship. In order to earn an A grade on the badge component, students must master at least eight specialization badges. To ensure breadth, all students must complete at least one badge in each category in order to pass the course. (Note: Students were also allowed to pitch their own badges if they could make the case for the badge's connection to course themes.)
Each badge requires students to explore a topic on their own, using technical manuals and relevant on-line trainings from Lynda.Com. After working through the tutorials, students demonstrate their mastery of the concepts by applying the skills in their own work. Last, but not least, students earn the badge by documenting the experience in a blog posting that reflects on their own learning style, analyses the utility of the skill/tool mastered, and explains how these things came together in their creative work. It is not enough to simply work through the tutorial and create something with the tool. The students' critical self reflection is the most important part of the process.
Outcomes
The semester culminates in student presentations during the final examination period. As with our Capstone course, the presentation component is important. Students are asked to dress up (business casual) and to deliver rehearsed presentations about the work they accomplished during the semester. During the final presentations, I quietly listen for the presence of two factors that help me assess whether or not the course was a success: 1) the confidence that students display in their own technical abilities and 2) an ability to reflect on how their own learning style intersected with their work on the badges.
I'm not a neutral observer; we see what we want to see. However, by the end of the semester, most of the students seem genuinely excited about what they've accomplished, they seem confident about their ability to master unfamiliar material, and they are eager to tackle new technology-related topics on their own long after their time at Trinity has come to an end.
Links to MOOCs
As they work on the badges, students dip into an educational ecosystem that includes many MOOC-like ingredients. The tutorial videos on Lynda.Com are, in essence, miniature courses that teach students how to master creative tools and programming languages. Though these resources don't mimic the flow of an academic semester, and though they don't have quizzes or tests, they have much in common with MOOCs. These are massive, online, self-paced courses. Since Trinity underwrites the subscription to Lynda.Com, these tutorials are also "open."
As an instructor, this approach makes it possible for me to cover a wide range of topics while still using the traditional framework (discussions and class meetings) in a meaningful way that intersects with the badge work. Each student chooses a unique, personally meaningful path through the world of web design, but there are also shared, collective elements there are common to all students in the class.
These badges are non transferable
So far, the badge approach seems to have worked, and I plan to continue this experiment in future versions of the course. Now that I have written the descriptions for 33 badges (no small task), it will be relatively easy to add and subtract badges as the landscape changes.
However, based on this experience, I am deeply skeptical of those who argue that higher education should replace (or at least supplement) grades with a badge-like system that certifies the acquisition of certain skills. I have been particularly troubled by those who envision our education world as a universal MOOC with badges used to certify our accomplishments.
It was hard enough for me, as a single instructor, to flesh out a workable badge framework within the context of this web course. Luckily, I was protected by academic freedom and the widely shared belief that instructors have the right to decide what happens in their own courses.
If these badges were suddenly treated as transferable commodities -- if they started to show up on student transcripts as a way of certifying mastery of certain technical concepts -- it would be necessary for some sort of standards setting body to flesh out what constitutes sufficient accomplishment. Suddenly, an approach that I incorporated in the hopes of fueling student creativity and my own pedagogical experimentation would turn into something much less exciting. Before too long, the badge approach would become just another strategy for "teaching to the test." I have no interest in being part of such a world.
As for those educators who argue that students need badges to certify their accomplishments, I would tell them the same thing that I tell my students: The proof is in the pudding. And the pudding is the student's portfolio.
Certifications, grades, and badges are extremely rough indicators of an individual's capabilities and accomplishments. More than once, I have been involved in hiring processes in which we offered programming jobs to candidates based on the alphabet soup of certifications at the bottom of their resume. More than once, those have turned out to be "Very Bad Hires." They looked good on paper, but were a disaster in the workplace.
More than once, I have hired individuals based entirely on what I have seen in their creative and technical portfolios. Did they comment their code? Did they know how to write meaningful and humane error messages? Could they explain the rationale behind their creative work? These individuals lacked certifications, and I never saw their transcripts, but they were great employees and excellent colleagues. The proof was in their portfolios.