Happy New Year, and greetings from Boston, where I’m attending the AMS/MAA Joint Meetings. This week’s blog posts will be a mix of reports from the meetings and thoughts I’ve been letting incubate over the holiday break.
One of the biggest things I learned this semester is: Everything in a class should revolve around learning objectives.
When I was preparing my transition-to-proof course (MTH 210, titled Communicating in Mathematics), I was struck by something my colleagues were doing. On assessments, preceding each problem there was a little blurb that said what learning objective the item was addressing. For example, an item on proof by contradiction might be preceded by the statement, “The purpose of this item is to assess your skill at proving conditional statements by contradiction”. So simple -- and very helpful for both instructor and student.
I started doing this myself in MTH 210 and in Calculus 2. For each chapter of the textbooks we use, I wrote out all the learning objectives I wanted students to master. Every lesson from a class meeting and every assignment or assessment was then designed to focus on some subset of those objectives. The students’ goal is to provide me with unambiguous proof that they have mastered those objectives.
This kind of thing is no secret to those who subscribe to standards-based grading. In SBG, the design of the course is predicated on having a carefully-tuned comprehensive list of objectives and then giving students multiple ways to show they have mastered them. I didn’t go whole-hog into SBG, but I thought the idea of having everything in a course coming back to a single set of goals had a remarkable clarifying power. So I took from SBG what I felt like I could manage.
I say it’s “simple” but it’s also hard. You can’t use fuzzy language like “Understand the chain rule” or “Write good proofs”. You have to follow through and design assessments that really measure mastery. And, hardest of all perhaps, you have to decide what your learning objectives actually are. It’s easy to have a vague feeling of what students should be able to do as the result of a course, but few of us have codified these things.
This semester I’m teaching Calculus 3 and a first-semester Discrete Structures course for computer science majors. The first thing I did when designing these courses was to sit down with the textbooks and past syllabi and list out every single task I felt students should be able to do fluently by the end of the semester. It took me about three hours for each class to get to a list I felt comfortable with.
You can see list for Calculus 3 here [RTF], and Discrete Structures here [RTF]. In those files, the top-level headings are the chapter/section numbers, and the blue items are the main instructional objectives. Underneath the blue items are different aspects of that objective. The blue items are the topics whose mastery I will measure, and roughly speaking, the items underneath each blue topic are how I will measure them.
Through a fun trick of my Mac software, I was also able to turn each of these lists into a concept map. The PDF of the concept map is here. The full-resolution PNG version is too large to upload! I got those maps by making up the lists in OmniOutliner, exporting the OmniOutliner file to OPML (an option under the File > Export... menu) and then just opening the OPML file in MindNode, a free concept map program for the Mac. MindNode does all the drawing and arranging automatically.
This was a good exercise for me. The process of mapping out all the course objectives gave me a familiarity with the content and how it fits together that I needed to design the course. And students will enter the course with the final exam study guide already made out, and every time they see an assessment item, they’ll also see where it fits in the big picture.
What about you? Have you tried (or are you about to try) something like this?