My origins story with flipped learning
As I've mentioned before, I'm currently working on a book for Stylus Publishing called Flipped Learning in the University: A Users' Guide. Periodically I am going to post excerpts from the book, both to drum up interest in it (which forces me not to quit working on it) and to get ideas for changes. Today, I'm posting (most of) the Preface to the book, which describes how I got into flipped learning in the first place and sets the stage for the rest of the book.
This book began to take shape almost a decade ago, after a tremendous failure on my part when I first tried to implement the pedagogical method that this book is about.
The year was 2008. I was on the Mathematics faculty at a small liberal arts college. As is the case in small colleges, I also did a lot of administrative and service work. One of those administrative jobs was to manage our college's "3+2" engineering program. Like other similar programs at small colleges throughout the US, students in the 3+2 program attended my college for their first three years to complete the basic science, math, and general education courses needed for an engineering degree; then they transfered to a partner institution, a larger university with an engineering program to take their specialized engineering courses. After five years they received two degrees, one in Applied Mathematics from my college and one in Engineering from our partner.
This was a great program, but tricky to manage because (among other things) of the omnipresent scheduling constraints in small colleges. For example, we could only offer one section of Calculus 2 per year. If there were any schedule conflicts between my college's courses and our partners', it was a serious problem. So to help ameliorate this problem, I proposed a course on computer programming for Mathematics majors, using the software MATLAB, that would satisfy a basic course requirement at our partner university.
To ensure that the course had sufficient enrollment each time it was offered, it was made into a required course for all math majors, not only the engineering students but also students who don't normally take scientific computing courses, like pre-service primary and secondary education majors. The audience therefore included many students who weren't typically very interested in --- or comfortable with --- the idea of computer programming. To give the full range of students the time and space to learn the subject, I proposed that the course would be 3 credits meeting three times a week for 50 minutes each time.
By the time the course was debated and modified by our Dean, it had been whittled down to a one-credit course --- meeting once a week for 75 minutes.
This was a serious, if not crippling problem because I had just one concept in my mind about how a college course should be designed and managed. That concept is the one that I encountered exclusively in college as well as for most of my basic courses in graduate school, and it goes like this:
- During class meetings, the students in the class get their first contact with the material through a (hopefully well-constructed and logically sequenced) lecture that includes lots of instructor examples, and maybe if there is time, there will be some practice time made available.
- After class is over, the students are tasked with going back to their dorms, homes, and apartments to work on bigger and better things --- things like homework, projects, programming and assignments, and so on.
But immediately I realized that this model simply won't work for a first course on computer programming, aimed at a general audience, done once a week for 75 minutes. First, computer programming is a skill that cannot be learned by listening to a lecture --- one has to do programming, make mistakes, fix the mistakes, and reflect on those mistakes in order to really learn the subject. I knew this from my own computer programming courses in the past, which had been taught exclusively via lecture. But since I was a skilled learner back in those days and loved technology and had a technical background, it was no problem for me to make the time outside of class for the real learning experiences. That brings up the second issue: The students in my class were not like I was. They weren't dumb by any means, but they were not expert learners and did not in many cases possess even a basic level of comfort with technology, much less skill. Third, even if I were to lecture flat-out with no breaks for 75 minutes once a week, and even if the students in the course could absorb all that lecture and put it to good use in their own time, we still wouldn't be able to learn everything we needed to learn in the course.
I needed a different model.
So I did some research, and I eventually came across a paper called "The inverted classroom in software engineering" by three professors in the Computer Science department at Miami University of Ohio. Reading their paper and how their software engineering course was set up, I knew this was an immediate fit, and I modeled my course after theirs.
These professors at Miami had devised something called the "inverted classroom" (which I later came to realize had been truly invented by some of their colleagues in the Economics Department, eight years earlier). In the inverted classroom, the direct transmission of information that one normally associates with a classroom lecture still happened, but it happened in a different context: outside, actually before, the class meeting in the form of pre-recorded video and readings. Then, because this activity was relocated outside the class meeting, the meeting was wide open to be spent on active learning activities. Not only this, but having the lectures pre-recorded allowed students to pause and replay as often as they needed without having to lose themselves in note-taking.
After one reading of this paper, I knew that this was the model I was looking for. So I designed my course after theirs. Students would watch videos about certain feature sets of the software prior to the weekly class meeting. (MATLAB maintains a collection of professional-quality instructional videos for this purpose, so I didn't need to make any video content, just link to what had already been made and add some viewing notes.) Then, I created weekly programming labs in which students would partner and apply the basic feature set of the week --- which they learned through watching the videos --- to solve an applied problem using MATLAB. Students were assessed on the quality of their solutions, as well as on a handful of timed assessments.
This seemed very promising. Students would get to know the software on a basic level before class, thereby liberating tons of time in class to do creative application work. This was the flipped learning idea implemented solidly in my course. This was going to be awesome!
Except as it turned out, it was not so awesome. In fact it was a resounding failure on a number of fronts.
- I gave students well-crafted video resources, but that's all I did -- give them to students with the instructions, "watch this video before class". It turns out that this is not enough. Students tried to watch the videos but quickly got lost, did not learn what they needed to learn to be ready for class, and did not retain what they had learned from previous weeks.
- Because students weren't learning from the video pre-class assignments, they were showing up to class unready to work on applications of the basic material. Those labs that I so painstakingly constructed for class time? They were non-starters for the students.
- Students asked me to re-teach the material from the videos because they didn't understand the videos. I refused --- maybe I should say "declined" --- because I assumed that the reason students were asking was because they had simply refused to watch the videos out of laziness. Perhaps some students were lazy; but it's more likely that many of them simply didn't know how to watch a video in the sense of learning something from it. Things got tense in the class as a result.
- Students became frustrated that I "wasn't teaching the material". I was mad at the students because, in my mind, they weren't working on their preparatory material hard or well enough. The community atmosphere of the class collapsed in week 2 of the semester and never recovered. There was no trust, no sense of mutual help, and honestly very little got learned that semester by anybody.
In short, it was one of the worst experiences in my 20-year teaching career, and it was mostly my fault, and by all rights I should have dropped this model then and there, and never looked back.
However, I remained convinced that, while going back to the traditional model of instruction might make students (and myself) happier, it would not result in improved learning, because again: One cannot learn computer programming by listening to someone talk about computer programming. One has to try to program, and have the time and space to make and repair mistakes while working on an interesting problem that requires basic skills. And those basic skills can, and therefore should, be acquired independently prior to class time; while reserving precious class time for me to help students as they do the hard and frustrating work of getting computer code to behave correctly.
In other words, I faced a choice after that initial disaster of a semester: Either try to figure out what was missing from my teaching in the class and then try again, or abandon the idea of altogether. I chose the former, and it was one of the best decisions of my career.
The model that I described above, which was called the "inverted classroom" by the professors at Miami (and which still often goes by that name), is the pedagogical model we will call flipped learning throughout this book. It is called "flipped" because of the reversal or flipping of the contexts of what students do in their own time versus their time with the entire class.
My first use of flipped learning was an unqualified disaster. But in the subsequent semesters when I tried again, I did learn, somehow, from my mistakes. I learned about flipped learning designs that work for students and empower them to become better and more effective thinkers. I learned how to work with students on a personal level to support them not only intellectually but also emotionally and psychologically, as they are faced with the prospect --- possibly for the first time --- of being in control of their learning. I learned how to challenge without antagonizing. And I learned how to help students, Deans, parents, etc. get on board and learn to accept that what we were doing in a flipped learning environment was worthwhile. Today, all my classes --- even my online classes --- use the flipped learning model, and my students have come to "get it" and even prefer it over traditional pedagogical models.
This book, to a great degree, is an extended message to you about what I have figured out in the decade-or-so since that first attempt, in hopes that you can learn from my mistakes without actually making those same mistakes.
This book is also a strongly-worded love letter to higher education that it must change how it approaches pedagogy, or else face permanent obsolescence --- if not extinction. The world that gave birth to the great intellectual traditions of higher education is not the same world that college students face today. As recently as two or three decades ago, a college graduate could earn a degree in a subject and have a reasonable expectation of being employed in some career related to that subject, and then work on the same sorts of problems every day in her career. That is no longer the case. College graduates today will be forced to confront major issues and crises facing the world that are notoriously ill-defined and require a nimble intellect and constant learning and re-training. In fact many of these problems that current college freshmen will have to face may not even exist at the time of their matriculation, but will be at the forefront of the world's consciousness by the time they graduate. A conception of pedagogy that relies on a scarcity model of information, that conducts its teaching like a broadcast, that doesn't make time to develop the broad intellectual skills that will outlive the final exam, cannot survive in this world. And the clients of traditional higher education --- which include private sector employers, governments that hold the purse strings, and parents who make the decision to send their children to college --- are keenly aware of this and are watching closely.
We need a different model. And I believe that flipped learning is that model.