Three things I learned at ScreencastCamp

Last week, I had the chance to attend ScreencastCamp, a weekend event put on by Techsmith, Inc. just down M-6 in Okemos, Michigan. What a great experience! Techsmith develops Camtasia, my go-to software for all screencasting needs, as well as several other great products like Jing and SnagIt. I’ve been a fan of their products for a long time, and it was great to spend time getting to know the people behind them.

ScreencastCamp was an unconference, where there is no set agenda beforehand. Participants just come with an idea of what they want to learn, and then either put on a session or request one. There were about 40 of us participating, mostly from education but with a healthy contingent from the corporate (training) world as well. Amazingly, although this is a relatively small number of participants, all the session slots for Saturday and Sunday filled up almost immediately as people pencilled themselves in to give sessions. It was busy. Some of the sessions were like regular conference talks, while others ended up as discussions among four or five like-minded people sitting around on the sofas in a back area of Techsmith headquarters. The hosts were generous, the food (and the beer!) amazing, and the atmosphere of enthusiasm infectious.

I came away with a lot of great ideas about screencasting, but here are the three that stood out the most.

1. Write careful and complete scripts for your screencasts. Back in my series of “How I Do Screencasting” posts, I wrote that a rough script was the way to go. Now I’m a believer in complete, careful, tightly-written and -edited scripts. What’s so great about a complete script? First of all, I have a tendency to talk fast and speed up as I get going in a screencast. Scripting out what I’m going to say not only helps me to edit my thoughts down to just the essential ideas, it also provides a way to talk at a normal, relaxed pace. Second, having a script printed out in front of me will make it easier to caption my videos, which is something that I want to start doing and indeed may eventually have to do. If I have a script, I can copy and paste the text of my screencast into Camtasia for the captions. It’s a little more complicated than that sounds, but at least I wouldn’t have to transcribe the audio.

Techsmith gave us a copy of the template (MS Word, 66 Kb with a bunch of my own stuff on it) they use for their own screencast scripts. I’ve used this simple form for a series of Maple 15 screencasts I’m working on right now, and it’s really made things go a lot more smoothly than when I was reading from a text file, or making it up as I go.

2. Record your audio first, then your video. This was the most radical idea I heard. I had always recorded the audio and the video simultaneously using Camtasia, but that’s not how Techsmith themselves do it. After writing the script, Techsmith screencasters will read the script and record the audio using Audacity. Then the audio file gets exported into Camtasia as an audio track, and the video part is recorded on top of the audio separately. At first I was very skeptical of this (wouldn’t it be a lot more work?) but after trying it myself, I’m a convert. Recording the audio separately reduces cognitive load — you don’t have to worry about getting both the audio and the video right at the same time — and so both pieces turn out better. Audio is much easier to edit when it’s not attached at the hip to video, I think. And you can focus on the quality of the audio as well. As one Techsmith employee put it, viewers will put up with crappy video as long as the audio is good, but not vice versa.

The way I’ve made this work for me is with the following workflow. First, write a good script using the Techsmith template. Then, read the script into Audacity, putting plenty of “white space” in between each box in the template — this gives viewers a little breathing room while they are watching. Next, go back and edit out any mistakes in the audio, either in Audacity or in Camtasia after the audio has been exported. Then, to record the video, turn off all audio inputs (because you’ve already done the audio), start recording the screen, then start the playback of the audio track and just click along with whatever it is you’re saying from the script. After all, this is what your viewers are going to have to do. Once you’re finished, it’s relatively simple to sync up the audio and video (especially if you keep the whole thing short) by just moving the tracks up and down the Camtasia timeline until it looks like they work. Then trim off the beginning and end of the video to make the video and audio the same length.

3. Get a real microphone. I’ve mentioned before that I’m too cheap to buy a USB microphone when the built-in mic on my Macbook works passably well. But after trying some of the higher-end equipment at Techsmith and hearing what it sounds like on playback, I think I might have to be, well, less cheap. When I recorded my practice screencast in the Techsmith studio, the mic captured the full range of my voice without sounding like I was at the bottom of a well, and no other sound made it into the audio. Part of that is because I was in a studio, as opposed to my office, but part of it is the microphone. It really does make a difference.

I also picked up a ton of little tricks and tips from participants — for example, buy a dog clicker to use when you make a mistake on the audio; the spike it makes in the audio waveform is really clear and it makes it easy to find where you need to edit.

ScreencastCamp was a great experience — amazingly, it was totally free too — and I learned a great deal about how to be a better screencaster. Thanks Techsmith!

Advertisement

How I make screencasts: The whiteboard screencast

In this post, the fifth in a series of posts on how I make screencasts, I’m going to focus on what I call the “whiteboard” screencast. This is a screencast where I am demoing some sort of concept or calculation by writing things down, rather than clicking through a Keynote presentation or typing something on the screen. It’s intended to mimic the live presentation of content on a whiteboard, hence my name for it.

Of course the most well-known examples of “whiteboard” screencasts are the videos at Khan Academy. In the unlikely event you haven’t seen a Khan Academy video before, here’s one:

I do whiteboard screencasts fairly often. I use them sometimes for presenting hand calculations for students to watch and work through before class, and sometimes (probably more frequently) I use them to create additional examples for things I’ve covered in class. This is a really powerful use of screencasts — students often want more examples than there is time for in a class meeting, and whiteboard screencasts give me a way to give students as many examples as they can dream up.

The basic principles of whiteboard screencasts are the same as for other screencasts. You first have to engage in basic planning, which involves defining a tight and coherent scope for your screencast and writing out a script. For whiteboard screencasting, which is more free-form than lecture capture using Keynote or PowerPoint, the scripting process has to be a little more rigorous. Because it’s easy for me to get carried away when talking about something that matters to me, I find it very helpful to work out in advance everything that I am going to do in the screencast, in the order and position on the screen that I intend to do it. I don’t always read words from a script, but in order to make the screencast logical and coherent, I do storyboard what I am going to do and practice with the drawings, erasures, and such. Very little of what I do in a whiteboard screencast is ad-libbed. (If I were better at ad-libbing, that might be different.)

So I will start a whiteboard screencast with something like a mind-map of the topic or topics I intend to address and one, maybe two, examples of that topic. Additional topics go into additional screencasts. I work those examples all the way through to ensure that there are no math or other mistakes and that I don’t get stuck in one of my own calculations. If you think about it, this is just the same kind of planning that goes into a successful whiteboard lecture, so this process is not entirely alien to instructors.

Once the screencast is properly planned, it’s time to put it together. This is where it gets technically somewhat complicated. But a lot of people ask me about the tools I use to make whiteboard screencasts, so hopefully this will be worth it. I use four main tools for doing whiteboard screencasts:

• Keynote; I’ll explain in a minute.
• Camtasia, which we saw in the last post in this series.
• FlySketch, a software app from Flying Meat (they also make the popular personal wiki software VoodooPad). FlySketch puts a transparent overlay on top of any existing objects on your computer screen and allows you to draw freehand, draw geometric shapes, or type text on the overlay. See the link for screenshots and a more detailed description.
• A Wacom pen tablet. I currently a Wacom Graphire tablet purchased with a grant a few years ago. With my upcoming job change, I have to hand that in when I leave, so I plan on picking up a Bamboo Pen & Touch this fall.

With those tools, here is the workflow I follow for making a whiteboard screencast.

First, open up Keynote and make a single, blank white slide. This is going to be the “whiteboard” itself. Of course you could also use a blank MS Word document, or any other blank white window or screen. Keynote is just for convenience’s sake.

Next, open up FlySketch and lay it completely over the blank window so that the controls are showing above the top of the window:

Then, open Camtasia and create a custom region that encompasses the “whiteboard”. When the video rolls, it will record what is happening on the whiteboard:

And finally — start the video, and start writing on the FlySketch overlay using the Wacom tablet. Before you start recording, make sure to select the pen color and size you want. If you need to change color, size, or pen type during the screencast — say, you want to switch from freehand writing to typing, or drawing a straight line for an axis — you can tap on the appropriate FlySketch control and Camtasia won’t record it because it’s off-screen.

Then you simply record what you need, then stop, and process the video as was described in the previous post in this series. This includes editing out any mistakes and splicing together multiple video clips for the same screencast.

Here’s an example of the finished product:

Although Sal Khan has been my inspiration for doing screencasts, I’ve made some conscious decisions here to do things differently than Khan does. First, I prefer the white background to the black; it’s more familiar to learners and seems cleaner. I also tend to use thicker pen “tips” than Khan does; I tend to think his pens look a little spidery. Also, the Wacom tablet pen is pressure-sensitive, and that feature works better if the pen tip is thicker. Finally, from a planning perspective, my whiteboard screencasts are a lot less conversational than Khan’s videos. Khan tends to shoot from the hip in terms of presentation; this is part of what makes his videos so charming, but I think it also tends to make his videos go longer than they need to. I prefer to make things a bit more efficient and focused and take less time. It also cuts down on mistakes.

I think the hardest part of this process, for me, was mastering the art of writing on the Wacom tablet in one place and having the writing appear on the screen. This is harder than it sounds! At first my handwriting was horrible (I think at the time I likened it to somebody with a brain injury) but eventually I got my act together. I suspect people learning to play the drums or the piano have to go through the same process before it sounds any good.

Another challenge is managing the relatively small amount of physical space you are working with. A Keynote slide is just not a very large place, and it’s easy to run out of room when writing. If this happens, it can be dealt with by just starting another slide and creating a new video clip. But it’s better for the learner to see one example per slide if possible, and making sure this happens is part of that all-important planning process. I find it helpful to practice the presentation not on the screen or a piece of paper but on a 3 x 5 inch notecard, which has something much closer the same proportions for writing as the Keynote slide on the screen. But note that it does take practice — if you just sit down and try to bang out a whiteboard screencast, it’s likely not to be as good or as instructional as possible, and it could end up taking more time in terms of edits and re-takes than it would if you just planned and practiced in the first place.

I’d be interested in hearing any alternative approaches for making these kinds of screencasts. I once wrote Sal Khan and asked him what his tools were, but never got a response, so I just reverse-engineered what he was doing. There may be a better way. Let me know!

Next up will be the final installment in this series, touching on what I called a “demo” screencast. It’s probably what I do the most. Stay tuned!

Targeting the inverted classroom approach

Image via Wikipedia

A while back I wondered out loud whether it was possible to implement the inverted or “flipped” classroom in a targeted way. Can you invert the classroom for some portions of a course and keep it “normal” for others? Or does inverting the classroom have to be all-or-nothing if it is to work at all? After reading the comments on that piece, I began to think that the targeted approach could work if you handled it right. So I gave it a shot in my linear algebra class (that is coming to a close this week).

The grades in the class come primarily from in-class assessments and take-home assessments. The former are like regular tests and the latter are more like take-home tests with limited collaboration. We had online homework through WeBWorK but otherwise I assigned practice exercises from the book but didn’t take them up. The mix of timed and untimed assessments worked well enough, but the lack of collected homework was not giving us good results. I think the students tended to see the take-home assessments as being the homework, and the WeBWorK and practice problems were just something to look at.

What seemed true to me was that, in order for a targeted inverted classroom approach to work, it has to be packaged differently and carry the weight of significant credit or points in the class. I’ve tried this approach before in other classes but just giving students reading or videos to watch and telling them we’d be doing activities in class rather than a lecture — even assigning  minor credit value to the in-class activity — and you can guess what happened: nobody watched the videos or read the material. The inverted approach didn’t seem different enough to the students to warrant any change in their behaviors toward the class.

So in the linear algebra class, I looked ahead at the course schedule and saw there were at least three points in the class where we were dealing with material that seemed very well-suited to an inverted approach: determinants, eigenvalues and eigenvectors, and inner products. These work well because they start very algorithmically but lead to fairly deep conceptual ideas once the algorithms are over. The out-of-class portions of the inverted approach, where the ball is in the students’ court, can focus on getting the algorithm figured out and getting a taste of the bigger ideas; then the in-class portion can focus on the big ideas. This seems to put the different pieces of the material in the right context — algorithmic stuff in the hands of students, where it plays to their strengths (doing calculations) and conceptual stuff neither in a lecture nor in isolated homework experiences but rather in collaborative work guided by the professor.

To solve the problem of making this approach seem different enough to students, I just stole a page from the sciences and called them “workshops“. In preparation for these three workshops, students needed to watch some videos or read portions of their textbooks and then work through several guided practice exercises to help them meet some baseline competencies they will need before the class meeting. Then, in the class meeting, there would be a five-point quiz taken using clickers over the basic competencies, followed by a set of in-class problems that were done in pairs. A rough draft of work on each of the in-class problems was required at the end of the class meeting, and students were given a couple of days to finish off the final drafts outside of class. The whole package — guided practice, quiz, rough draft, and final draft — counted as a fairly large in-class assessment.

Of course this is precisely what I did every week in the MATLAB course. The only difference is that this is the only way we did things in the MATLAB course. In linear algebra this accounted for three days of class total.

Here are the materials for the workshops we did. The “overview” for each contains a synopsis of the workshop, a list of videos and reading to be done before class, and the guided practice exercises.

• Determinants: Here’s the overview and here are the in-class problems.
• Eigenvalues and eigenvectors: Overview, in-class problems.
• Inner products: Overview, in-class problems.

The results were really positive. Students really enjoyed doing things this way — it’s way more engaging than a lecture and there is a lot more support than just turning the students out of class to do homework on their own. As you can see, many of the guided practice exercises were just exercises from the textbook — the things I had assigned before but not taken up, only to have them not done at all. Performance on the in-class and take-home assessments went up significantly after introducing workshops.

Additionally, we have three mastery exams that students have to pass with 100% during the course — one on row-reduction, another on matrix operations, and another on determinants. Although determinants form the newest and in some ways the most complex material of these exams, right now that exam has the highest passing rate of the three, and I credit a lot of that to the workshop experience.

So I think the answer to the question “Can the inverted classroom be done in a targeted way?” is YES, provided that:

• The inverted approach is used in distinct graded assignments that are made to look and feel very distinct from other elements of the course.
• Teachers make the expectations for out-of-class student work clear by giving an unambiguous list of competencies prior to the out-of-class work.
• Quality video or reading material is found and used, and not too much of it is assigned. Here, the importance of choosing a textbook — if you must do so — is very important. You have to be able to trust that students can read their books for comprehension on their own outside of class. If not, don’t get the book. I used David Lay’s excellent textbook, plus a mix of Khan Academy videos and my own screencasts.
• Guided practice exercises are selected so that students experience early success when grappling with the material out of class. Again, textbook selection should be made along those lines.
• In-class problems are interesting, tied directly to the competency lists and the guided practice, and are doable within a reasonable time frame.

These would serve as guidelines for any inverted classroom approach, but they are especially important for making sure that student learning is as great or greater than the traditional approach — and again, the idea of distinctness seems to be the key for doing this in a targeted way.

What are your suggestions or experiences about using the inverted or “flipped” classroom in a targeted way like this?

Speaking of the inverted classroom

On Wednesday, I gave a talk at Indiana University – Purdue Universty – Indianapolis (IUPUI, for short) to the teaching seminar for math graduate students on the inverted classroom. It was sort of a generalization of the talk I gave on the inverted linear algebra classroom back at the Joint Mathematics Meetings in January. Carl Cowen was in attendance at that talk and invited me to make the 20-minute drive from my house to IUPUI to do something like it, and I was happy to oblige.

Since putting the talk up on Slideshare yesterday morning, it’s gotten over 200 views, 2 favorites, a handful of retweets/Facebook likes, and is currently being highlighted on Slideshare’s Education page. So I thought I would share it here as well. Enjoy and ask questions!

Salman Khan on the inverted classroom

Salman Khan, of the Khan Academy, sounds off on the potential of pre-recorded video lectures to change education in the video below. He calls it “flipping” the classroom, but around here we call it the inverted classroom.

I like especially that Salman made the point that the main effect of inverting the classroom is to humanize it. Rather than delivering a one-size-fits-all lecture, the lecture is put where it will be of the most use to the greatest number of students — namely, online and outside of class — leaving the teacher free to focus on individual students during class. This was the point I made in this article — that the purpose of technology ought to be to enhance rather than replace human relationships.

I hope somewhere that he, or somebody, spends a bit more time discussing exactly how the teachers in the one school district he mentions in the talk actually implemented the inverted classroom, and what kinds of issues they ran up against. Ironically, the greatest resistance I get with the inverted classroom is from students themselves, namely a small but vocal group who believe that this sort of thing isn’t “real teaching”. I wonder if the K-12 teachers who use this model encounter that, or if it’s just a phenomenon among college-aged students.

How I make screencasts: Lecture capture, part 1

Image via Wikipedia

Sorry for the time in between posts lately. It’s been an odd mix of attending conferences, getting ready to attend conferences, and spending time in the hospital being treated for skin infections picked up at those conferences for the last couple of weeks. Long story. Let’s talk about something more pleasant than cellulitis, namely screencasting.

So far I’ve posted about the general idea of screencasting and what I do with screencasts, and I’ve posted about the all-important planning phase of screencasating. Now I’m ready to start getting to the nuts and bolts. Of the three kinds of screencasts I do, probably the simplest is the lecture capture. In a lecture capture I am simply recording a slide presentation or a Prezi with a voiceover. Here’s an example, which is an overview of the first test being given to a freshman calculus class:

All this screencast is, is a Keynote slide deck that I prepared with a voiceover. Sometimes this is all you need for the task you want to accomplish. For those non-Mac people out there, Keynote is Apple’s version of PowerPoint — a presentation software tool that comes with the iWork office suite. If you have a Mac and don’t use iWork, it’s well worth looking into. Many people find Keynote to be much better designed and easier to use than PowerPoint or any of the other presentation tools out there.

The basic gist behind a lecture capture is that you are just using a presentation tool to give a normal presentation, and capturing the audio and the video that goes with it. This does not include any sort of writing on the board; I’ll deal with that in the next post in this series on “whiteboard” screencasts. But everyone should note well that the lecture capture approach is often part of my screencasts but rarely the entire thing. Many of my MATLAB screencasts are set up by brief, 1- to 2-minute long lecture captures before cutting away to a live screencast straight out of MATLAB. So even if lecture capture doesn’t sound like your thing, it’s worth thinking about.

With Keynote, doing a lecture capture screencasts is very easy. After planning it out, you just make the slide deck exactly as you would if you were to present it live. Then, instead of clicking the “Play” button to do the slideshow, click on Play > Record Slideshow:

This put the slideshow into presentation mode on your screen but also record audio from the microphone at the same time. From here, you just go through your slideshow as you would normally, and whatever goes into the mic gets recorded. When you’re done recording, go to Share > Export…:

There’s an option on the screen that comes up next to export to Quicktime, and that’s what to select. (I use the default video/audio options; you can tweak these.) And presto — you have a nice, high-quality Quicktime movie of your lecture that’s suitable for sharing online or burning to a disc.

PowerPoint (at least the version I have, which is PowerPoint 2008 for the Mac) has all of these capabilities as well. In PowerPoint, you would make up your slide deck as usual and then go to Slide Show > Record Narration…:

What happens next is a bit different from Keynote. PowerPoint does what it says: It attaches an audio narration to each slide as you click through it in presentation mode. There is the option — but not a requirement — to record the timing of the slide transitions as well. In Keynote, the transitions are automatically timed. To turn this voiceover-plus-presentation into a movie, just go to File > Save as Movie… and there are plenty of options to choose from.

I should mention that as for a microphone, I just use the built-in microphone on my Macbook Pro. I have used a USB headset microphone before and I think it did improve the audio quality noticeably, but to be honest with you: I’m really cheap. If I can get good audio quality that nobody complains about using the built-in mic, why spend $50 to get very good audio quality with a USB mic? One of these days I’ll break down and buy one, I’m sure. Until then I pinch my pennies.

There are a couple of issues to think about at this point regarding lecture captures.

• What if you want to use some other presentation tool besides Keynote or PowerPoint, for example the Beamer package for , or Prezi?
• What if you wanted to record portions of a lecture at a time and stitch them all together later, or conversely what if you wanted/needed to edit out or enhance portions of a lecture capture you created with Keynote or PowerPoint?

For those kinds of tasks, I would turn to my #1, go-to tool for almost all my screencasting needs: Camtasia for Mac. Camtasia is an all-purpose video and screencasting tool that does an outstanding job with just about anything I could possibly want to do with a basic screencast. There’s so much to Camtasia, and we are going to need to refer to it so much in later posts about whiteboard and demo screencasts, that I’m going to deal with Camtasia (and its alternatives) in a separate post.

Meanwhile, if you have other tricks and tips about lecture capture screencasting, please share in the comments.

How I make screencasts: The planning phase.

Image via Wikipedia

So I said in the first post in this series that I would start in with the workflow and tool set I use for making the different kinds of screencasts I do. But there’s a “square one” to the workflow that is common to all of these and needs to be discussed first: Planning. If you dive into any project without careful planning, you might end up with a roaring success — but more likely you will come up with nothing worth sharing. Screencasts, being a kind of project, are no different. Careful work on the front end greatly simplifies the work on the back end and improves the overall results.

The planning stage of a screencast for me has five distinct parts.

1. Settle on a small number of coherent main ideas to discuss. I set a limit on the length of all my screencasts at 10 minutes. This is because my main inspiration for screencasting, Salman Khan, does this, and because there’s a 10-minute limit on YouTube uploads. But also, it’s well-known that audience attention to presentations drops off a cliff after about 10 minutes of sustained effort. Within that limit, you can only hope to address so much. So within the main body of material I am trying to teach through screencasting, I try to cluster together small clumps of topics that mutually support each other and stick ONLY to those topics. For example, this MATLAB screencast covers three MATLAB commands that are thematically related:

There was going to be a fourth topic, the FPRINTF command, included with that screencast, but it’s considerably more complicated than the other three and so I made a separate screencast just for it. My rule of thumb is to cover no more than four main ideas in a single 10-minute screencast. If you have more than that to cover, break things up into multiple screencasts of shorter length. Your audience’s attention spans will thank you, and it’ll make it easier for users to find that one part of that one video that they really need.

2. Decide on a minimal number of things to say about each main idea. By the same token, stick to just the most important things that your audience needs to know about each main idea and plan an outline accordingly. For example, in making the Input/Output Commands screencasts I linked above, I talked about three commands — INPUT, MENU, and DISP. The outline for this looked like:

INPUT: Lets users enter input; stores input as a variable; default variable type is DOUBLE; pass an option ‘s’ for string.

MENU: Creates GUI menu with title and buttons for choices; pass it string arguments for the title and button labels; returns integer values depending on the button clicked.

DISP: Displays contents of a variable; nontrivial formatting is tricky or impossible; simple but limited.

There’s more I could say about each of those commands, but these are the most important things that users should know right now. When there’s much more to say, I give suggestions for places to look for more info.

3. Try to come up with a single unifying example that connects the main ideas. This doesn’t always work, but if you choose your screencast topics so they are coherent main ideas, you should be able to find a good instantiation of those ideas that shows all of them in action and in comparison to each other. The Input/Output screencast above does this by using INPUT to gather numerical data on tests scores and then DISP to spit out the average of those scores. A single unifying example makes the main ideas easier to remember because it shows how they fit into an overall framework, rather than presenting them as discrete and disconnected topics.

4. Plan out a rough script to follow. There are differing opinions about scripts when screencasting. Some folks say you should script out every word and just read off the script. Others clearly come in with nothing more than a general idea of what they want to do and then just wing it. The former approach usually ends up with a polished, professional screencast but which can come off as cold and impersonal. The latter approach is more fun to follow but can contain false starts, dead ends, and speech artifacts (“Um… er… ah…”) that can frustrate some people.

I used to be on the “script it all out” end of the spectrum, and my earliest screencasts show it. They are tight, precise, and rarely a word out of place. But I found I was spending an hour scripting out a 5-minute screencast, and I just don’t have the time for that when I am cranking out 50 minutes of screencasts a week. So lately I’ve moved more toward a “detailed outline” model. I will take the rough outline (with a minimal number of essential things to say about a small number of main ideas) like I made above and flesh it out with specific examples that are written out and tested for correctness in advance, and maybe a few important turns of phrase I want to use — then follow the outline, but make up the words as I go. This is what I mean by a “rough script”. I will usually write up the rough script by hand on a piece of paper and have it sitting in front of me when I record. For tough passages, I will still script things completely out. For instance, in the FPRINTF screencast I am going almost entirely word-for-word off a prepared, fully written-up script because when I tried a rough script on that stuff it was coming out garbled and wrong.

I would suggest that new screencasters should still script things out completely until you are comfortable with the recording process, which we have not even started discussing yet. It’ll build your confidence because you don’t have to worry if the words are coming out right.

5. Prepare your space. Finally, before recording, prepare the space you are going to use. I usually make my screencasts in my office at work, and my ritual is:

• Quit all noise-making computer programs, like anything that makes an alert sound — email clients especially. Your audience doesn’t want to hear you get new mail while they’re learning from you.
• Clear off the desk in front of me so that there’s room for my rough script and mouse. Also a clean desk will give you a clear head.
• Go fill up my water bottle, because inevitably when I screencast I will start coughing or get something caught in my throat.
• Close the office door and hang out my special sign that says, in bright green Sharpie, DO NOT DISTURB — VIDEO RECORDING IN PROGRESS.
• Turn the iPhone on silent mode and turn the ringer off on the office phone.
• Get out and plug in any gear I need to use and make sure it works.
• Set up the computer desktop — remove all unwanted stuff just as I would my physical desktop and prepare any software “props” — presentations, graphics items, etc. — I will need.

Then, when everything’s in place, you’re good to go! You have a rough script that gives you just enough scaffolding to give a human-sounding but professional screencast on the essential need-to-know items relating to a minimal number of big ideas, and all the pieces are in place. So now we record — but how? We’ll get to that next time.

How I make screencasts: Chapter 0

Photo: http://www.flickr.com/photos/olaerik/

Since I started to put serious amounts of time and effort into screencasting last summer, I’ve gotten a lot of requests to blog about how I go about making these things. Starting with this post, I’m going to do a multi-part series here about making screencasts — or at least how I make screencasts, which is a long way from perfect or canonical, but it’s what people asked for! I hope it’s useful for people who are interested in this kind of thing and need some pointers; and I hope too that those with more experience and better ideas than I have can share.

First, let’s start with a few FAQ’s.

Q: What is a screencast?

A: A screencast is a video of stuff that is happening on your computer screen. There is often, but not always, some kind of voiceover happening in the background as well. So a screencast can be a lot of different things: A recorded Prezi or PowerPoint slide presentation; a demo of computer software; a “whiteboard” lecture with audio capture; a video of you playing Angry Birds; or any linear combination of these.

Q: What’s the point of a screencast?

A: I suppose you could do just about anything with a screencast, but mainly the point is to instruct. Some people make short screencasts to show a remote collaborator or student how to do some little task on their computer, like this one I made on the fly in Linear Algebra class last Thursday morning to show students how to get MATLAB to produce code. Or you can record partial or entire lectures (like many of the ones I did for my department’s YouTube channel) for students to watch outside of class. Or you can record lengthy demos of software usage like I have done in my ongoing series of MATLAB screencasts. Or you can record every level of Angry Birds you play. Suit yourself.

The screencast is just a means of conveying some process or stream of information that can be represented on the screen and therefore captured using software and disseminated on the web. It’s a pretty much wide-open medium.

Q: So what kinds of software and hardware and other stuff do you use?

This is a good question, but at this point I have to stop the FAQ’s and explain why there are going to be multiple posts in this series. I have a toolbox of software and hardware items that I use, but the exact combination that I use depends on the kind of screencast that I am trying to make. Basically, there are three different kinds of screencasts that I make:

• Lecture capture screencasts, where I am going through a Prezi or slide deck and giving audio narration;
• Whiteboard screencasts, where I am using an input device to hand-write things on the screen so that it looks like a typical whiteboard presentation; and
• Demo screencasts, where I am doing a straight-up screen capture of something happening on my computer (as opposed to a presentation or “whiteboard” work) in real time.

Each of these kinds of screencasts requires a different set of software and hardware tools, as well as a different set of approaches for actually making them. So I’m going to spend at least one post on each. Actually, most of my screencasts are really combinations of these; for example a lot of the MATLAB screencasts start and end with a lecture capture and have MATLAB demos in the middle.

In the next post, I’ll start things off by focusing on lecture capture screencasts and how I work with those. They’re probably the simplest of the three kinds I make.

Do you have any specific question or topic you’d like me to address as part of this series?

The inverted classroom and student self-image

Image via Wikipedia

This week I’ve been immersed in the inverted classroom idea. First, I gave this talk about an inverted linear algebra classroom at the Joint Meetings in New Orleans and had a number of really good conversations afterwards about it. Then, this really nice writeup of an interview I gave for MIT News came out, highlighting the relationship between my MATLAB course and the MIT OpenCourseware Project. And this week, I’ve been planning out the second iteration of that MATLAB course that’s starting in a few weeks, hopefully with the benefit of a year’s worth of experience and reflection on using the inverted classroom to teach technical computing to novices.

One thing that I didn’t talk much about at the Joint Meetings or in the MIT interview was perhaps the most prominent thing about using the inverted classroom model on a day-to-day basis: how students react to it and change as a result of it. I was actually quite surprised that nobody at my Joint Meetings talk asked me a question about this, because honestly, the inverted classroom sounds great on paper, but when you start to imagine the average college student walking in on the first day of class and having this method of instruction described to him, it becomes clear that a significant amount of work is going to have to be done in order to get students — who are already resistant to any change from their accustomed modes of instruction — on board with the plan.

Students do tend to resist the inverted classroom at first. Some forms of resistance are more benign than others. On the benign end of the spectrum there are students with little experience with the course material or its prerequisites who get bogged down on the basic podcast viewing (which takes the place of in-class lectures in this model) or the accompanying guided practice, and instead of actively seeking a resolution to their question will wait for the instructor to clear it up — in class. On the other end is the student who simply doesn’t believe I’m serious when I say there won’t be any lecturing, who then doesn’t do the work, assuming I’ll bail him out somehow — in class. But in the inverted model, students are held responsible for acquiring basic competencies before class so that the hard stuff — what we refer to as assimilation — is the primary focus of the class time.

I break this distinction down for students, but not everybody buys into it. Those who don’t will have to undergo a learning process that usually looks like shock — shock that I won’t reteach them the material they were supposed to have viewed and worked on, while the lab assignment based on that material is going on. This can get very ugly in ways I probably don’t need to describe. Let’s just say that you had better not use the inverted classroom model if you aren’t prepared to put out a constant P.R. effort to convince students of the positive benefits of the model and constantly to assuage student concerns.

I’ve often wondered why students sometimes react so negatively to the inverted classroom model. I’ve come to believe it’s the result of a invasive, false belief that can arise in students about their ability to learn things independently of others — namely, that they simply cannot do so. I have had students tell me this to my face — “I can’t learn [insert topic] unless you lecture to me about it in class first.” Clearly this is not true. Toddlers learn their native language without formal instruction, just by assimilating (there’s that word again) the language going on naturally in their background. We all learn things every day without sitting in a classroom; we may seek out training data first through printed instructions, worked-out examples, YouTube videos, etc., but it’s almost never in a classroom setting. Learning new things on our own initiative and without formal instruction in a classroom setting is as natural to humans as breathing. Indeed you could say that it’s the capacity to learn in this way that makes us human. But somehow many students think otherwise.

Where does this belief come from? I think that it comes from its own instance of assimilation, namely the assimilation of a culture of programmed classroom instruction that takes place from roughly the first grade through the twelfth grade in this country. Students have so few experiences where they pursue and construct their own knowledge that they simply come to believe that they are incapable of doing so. And this belief is propagated most rapidly in mathematics. I’ve been reading in Seymour Papert‘s book Mindstorms: Children, Computers, and Powerful Ideas, and this quote hits this issue right on the head:

Difficulty with school math is often the first step of an invasive intellectual process that leads us all to define ourselves as bundles of aptitudes and ineptitudes, as being “mathematical” or “not mathematical”, “artistic” or “not artistic”, “musical” or “not musical”, “profound” or “superficial”, “intelligent” or “dumb”. Thus deficiency becomes identity and learning is transformed from the early child’s free exploration of the world to a chore beset by insecurities and self-imposed restrictions.

That last sentence (emphasis added) sums it up, doesn’t it? Deficiency becomes identity. Eventually, if a student is robbed of experiences of self-motivated learning, the student eventually adopts a self-image in which she is incapable of self-motivated learning. It is a false self-image that is ultimately dehumanizing.

Which is why I put such stock in the inverted classroom model. I think this method of teaching, along with other learner-centered modes of instruction like problem-based learning, is on the front lines in reversing students’ negative ways of thinking about how they learn. Students may (will?) chafe at the inversion at first. But in the MATLAB course at least, something really cool happened at the end of the semester. I made up a slideshow for students called “Five myths about how you think you learn that CMP 150 has busted”. Among the myths were “I can’t learn unless a professor lectures to me” and “I can’t learn on my own initiative”, and I gave concrete examples of work that the students had done in the class that contradicted these messages. In the end I showed them that through this inverted classroom process they had taken majors strides toward being confident, independent, skill learners and problem-solvers rather than just people who can play the classroom game well. And even the most skeptical students were nodding in agreement. And I think that makes it all worthwhile for everyone.

This week in screencasting: Optimization-palooza

My calculus class hit optimization problems this week — or it might be better to say the class got hit by optimization problems. These are tough problems because of all their many moving parts, especially the fact that one of those parts is to build the model you plan to optimize. Most of my students have had calculus in high school, but too many calculus courses in high school as well as college focus almost primarily on algorithms for computation and spend little to no time with how to create a model in the first place. Classes that are so structured are doing massive harm to students in a number of ways, but that’s for another post or two.

Careful study of worked-out examples is an essential part of understanding optimization problems (though not the only part, and this alone isn’t sufficient). The textbook has a few of these. The professor can provide more, but class time really isn’t best spent just by having the professor put examples on the board. Class time should also be spent working on optimization problems with the professor there to provide guidance. And since I can’t spend 8-10 class days both working examples and giving students time to work themselves, screencasts on optimization problems have been the obvious solution.

This week I did screencasts for four problems. Here they are (one problem needed two screencasts):

To my students’ great credit, they have embraced YouTube as a great source of help in calculus. They’ve utilized not only these screencasts but many other ones, most of them excellently produced, and now doing a search on YouTube is an essential component of studying for many of them. I think that’s a great approach, obviously.