I did a twenty-five minute presentation for Apple's Summer Semester followed by two shorter tutorials. ("Analytic Geometry" and "Mathematical Storytelling.") If you and I didn't run into each other at one of my talks this summer, please consider this a good, quick summary of my recent work. Questions? Comments? Please let me know.
Archive for the 'presentation' Category
After the third day at NCTM I wrote:
It struck me several times throughout both conferences that we need to counter-program a session across from the "Newcomer's Orientation." I'm not talking about "Rolling Your Own Backchannel with Twitter." Scale that back. Way back. Something more like, "How to Make National Presentations a Lot Less of a Chore for Presenters," featuring URL shorteners, Delicious, PDFs, basic FTP. maybe drop.io. You name it.
I wrote that, largely, on behalf of these two presenters, both of whom seemed stymied by the task of distributing resources (links, in Leinwand's case; PDFs in Becker's) to a large group.
Note the "virtual handout" solution from Leinwand:
And the paper-chair-piles from Becker:
I just finished facilitating "WCYDWT: The Workshop" over four days in Kannapolis, North Carolina. Maybe this should've been easy. I had three years of posts and a handful of presentations to draw upon for material. I had to condense the former resource, though, and expand the latter while adapting both formats for a workshop. The preparation lasted the first half of 2010 and was — hands down — the hardest work of my professional year. The facilitation was the most fun.
I learned a pile, both about facilitating workshops and about a model for instructional design I thought I had pretty well figured out. This is my usual debrief, then: notes that are useful to me, posted on the offhand chance they're useful to you.
How We Used Our Time
- 1.5 days — towards better conceptual problems
- .5 days — towards useful tools for creating better conceptual problems
- 1.5 days — towards better skill development problems
- .5 days — towards lab work, as you like it.
I can clarify that schedule and save myself some bandwidth at the same time by directing you to the session sites, which include more detail.
If we did nothing else right, we opened our time together well with some highly combustible mathematics. Per Brian Lawler's suggestion, we began with the ticket roll and the water tank (which, for the record, I had never attempted to solve until last Tuesday with those teachers in Kannapolis).
I tried to lead them through those problems as the best version of myself, by:
- asking them what questions interested them about the multimedia,
- soliciting their intuitive guesses towards those questions and encouraging a competition around those guesses,
- asking them to describe an answer they'd reject as too low or too high (ie. "give me a wrong answer.") in order to set their parameters for an upcoming error check,
- asking them to tell me the information they'd need to solve their question,
- checking in with groups as they worked, bringing student work beneath the document camera, asking them a lot of questions that began with "why,"
- asking them to check their obtained mathematical answer against their error parameters from ,
- comparing our mathematical answers to our intuitive answers and then to the actual, no-joke real-life answer,
- discussing possible sources of error, since nobody's answer was exactly correct,
- extending the problem and differentiating between learners by offering what we came to call "sequels," (eg. "what would the ticket roll's diameter measure if it had 1,000,000 tickets?" or "how long would it take to release all the water from the tank?", a problem which every group missed by a margin well above 200% but corrected quickly, which was awesome to witness. (Thanks, Steve.)
The moment of combustion came when I asked them to create the comparable problems they might assign out of a textbook. It's always been true for me that I grow most as a teacher when I try to reconcile the exhilaration I often experience, personally, as a learner, with the tedium I often inflict upon my students, professionally, as a teacher.
The product of the first day was a sturdy rubric describing the beginning, middle, and end of "great application problems," a rubric that arose naturally from those opening activities, a rubric by which we navigated the rest of the workshop.
What I Learned About WCYDWT
- In terms of technical skills relevant to this kind of instructional design, a black rectangle and the pause button will take you 70% of the way. Exemplar forthcoming.
- Storytelling is the technique by which one problem can be made simultaneously more engaging and more challenging than another problem that assesses the exact same content standard. For instance, consider the difference between "What is the area of the circular lawn?" and "How long would it take you to mow this circular lawn?" The difference between the two is an instructional bonanza. You're getting so much for so little. (Thanks, Kyle.)
- Graphing Stories is really boring, again, except for storytelling. Consider a fixed shot of a math teacher walking down two flights of stairs over fifteen seconds. That's boring. But attach to that boring video the framing device "graph height against time" and suddenly we're throwing pencils at each other, arguing over the effect of the curb at the thirteen second mark, etc.
- Send along a list of required software in advance. Day two slowed down quite a bit when we couldn't install Handbrake, QuickTime, or Geogebra due to access restrictions on the teacher laptops. I should have made that list known to my liaisons a lot sooner. (Any experienced facilitators have a tip for me here?)
- Lecture less. I initially tried to lecture my way into the rubric for great application problems and into the connection between storytelling and teaching. Clearly, I should have packaged that material as fodder for table discussions and then share-outs.
- Stick tighter to the rubric. We had a good list. By the last day, we were evaluating every product against it, even ones I brought to the workshop. That should have been our m.o. all the way through.
- Develop a rubric for great skill development problems. Those techniques are more abstract. The rubric would have been much shorter. It would have been a useful exercise, though.
- Do more math. Do more teaching. During our lab time, I should have insisted that we actually teach each other and actually solve the math because a) that's the fuel, teachers exhilarated by learning in a way that their students should be also, and b) merely describing a lesson or describing a solution allows you all kinds of fictions that only become obvious once you try them out.
- Clarify misconceptions about my own WCYDWT workflow sooner. Unless you correct them explicitly, your workshop participants will assume you do all the awesome stuff you're describing every period of every day. One participant called that effect "demoralizing." I need to put it out there as soon as possible that this is a model for instructional design that I only aspire to every day.
- Find an opening for Google Reader and Delicious. That's the Swiss Army Knife right there. I couldn't find the right moment, though.
- What do you do about error? I reckon this question is worth half a day on its own, and I'm nowhere near qualified to answer it. What do you do when you see a student in the middle of an error in reasoning or computation? The answer to that question is somewhere central to this WCYDWT thing, but we didn't address that one directly at all.
Paula, a workshop participant:
I don't know if I'm creative enough for this. I think it probably just takes practice, though.
Dr. Tom Sallee, not in attendance:
A good problem announces its constraints quickly and clearly.
Also: Why WCYDWT?
On the first night of Foo Camp, 250 attendees introduced themselves by name, affiliation, and three hashtags, and then descended on a gridded wall-tall conference schedule, scribbling down session titles, selecting venues, folding similar sessions into one another, scheduling roundtable discussions with people they had only met thirty minutes earlier over food.
The crowd was thick so I commandeered a Segway and steered it full-bore into the scrum, scattering people long enough to slide a session onto the closing day's schedule: The Programming Principle That Will Save Math Education.
That's three opportunities in three months (counting the webinar I'm conducting in October) that my patrons at O'Reilly have given me to throw a half-baked idea casserole at a bunch of really, really smart people and walk away with something quite a bit tastier.
The debate at an earlier session on the future of education was idealistic and high-minded with participants from all sectors trying to reach consensus (in sixty minutes) on merit pay, standardized testing, class size, unschooling, home schooling, charter schooling, public schooling, and probably several other intractable issues I'm now forgetting. I tried to approach my session, then, from two more assailable angles:
- math curriculum, which, for whatever it does right, doesn't a) put students in any kind of place to apply mathematical reasoning to the world around them, or b) do anything to encourage patience with problems with complicated inputs and messy outputs, which is to say, most problems worth solving. Math curriculum, speaking generally, does the opposite of those two things.
- after we develop a model for good math curriculum, we don't know how to share it.
The outcomes of merit pay and standardized testing will be decided in protracted, gruesome battles between various unions, legislators, and chancellors. The challenge of sharing good math curriculum, however, is one that the people attending my session — an intimidating array of talent, knowledge, and funding — could solve over lunch.
O'Reilly gave a blank notebook to the weekend's participants. Not lined. Not quad-ruled. Blank. We talked about how you'd only give out lined or quad-ruled paper if you were sure the average attendee wouldn't want to doodle.
I showed the participants how the Muji chronotebook shuns calendars and hour-blocks, opting instead for the least constrained approach to scheduling possible, a small clock in the middle of the page. This is the rule of least power, the programming principle that can save math education.
I won't waste space here recapping my session notes. I drew heavily from these six posts:
- The Rule of Least Power: An Initial Approach
- Why I Don't Use Your Textbook
- WCYDWT: Glassware
- WCYDWT: 2008 World Series of Poker
- Flight Control / Lesson Plan
- BetterLesson Reviewed
But I realized this: I flog WCYDWT media from whatever forum I'm offered not because I think WCYDWT media is the evolutionary pinnacle of math instruction. I do think WCYDWT is leagues better than the curricular norm, particularly compared to the kind of curriculum offered by the largest textbook publishers. More crucially, though, WCYDWT is the best model I know for classroom math instruction that can also leverage Internet distribution. I can use global publishing tools to infect other math teachers with these videos and photos. I can't do the same thing with netbooks. I can't do the same thing with physical manipulatives. I don't know a better model of math instruction that I can also aerosolize so easily.