Teach me to teach
January 24, 2014 11:24 AM Subscribe
Lately, I've been teaching a lot of semi-formal training classes at work. I haven't had much experience with this kind of thing, and I'm looking for tips.
The topics are generally technical, at an introductory level, for an audience without a ton of prior technical experience. Group size is anywhere from four to twelve. For example, my latest thing is a weekly one-hour class to teach beginner-level HTML and CSS to four people.
Any general advice or recommended reading for novice instructors is welcome, but I'm wondering about a few things in particular:
1. The role of notes: I tend to write up a couple of pages of fairly detailed notes for myself before the class, and then follow those notes pretty closely. This way, I can be sure that I'm touching on all the points I want to, and that I'm introducing concepts in a sensible order (with each new idea building on established ones).
Sometimes, though, I feel like I'm spending too much time with my nose in my notes, and that I'm losing the students' interest because of it. Obviously, if I were presenting the same material multiple times (or had more time to rehearse), there would be less need to rely on notes—but that's not the situation I'm in. Any ideas for addressing this?
2. Off-topic questions: I encourage students to ask questions, but sometimes they ask things that would be better addressed later down the road, or which would take us too far off-course to get into at present. What's the best way to handle these questions? Give a brief summary answer in general terms, with a promise that we'll explore them more fully later?
3. Finding the right balance between "me talking" and "them doing stuff". I don't want to just drone on forever, so I'm trying to punctuate the HTML class with little hands-on exercises that let them apply some of the stuff I've just taught. Is there any general rule about the rhythm and balance of this, or does it really just depend on the students?
The topics are generally technical, at an introductory level, for an audience without a ton of prior technical experience. Group size is anywhere from four to twelve. For example, my latest thing is a weekly one-hour class to teach beginner-level HTML and CSS to four people.
Any general advice or recommended reading for novice instructors is welcome, but I'm wondering about a few things in particular:
1. The role of notes: I tend to write up a couple of pages of fairly detailed notes for myself before the class, and then follow those notes pretty closely. This way, I can be sure that I'm touching on all the points I want to, and that I'm introducing concepts in a sensible order (with each new idea building on established ones).
Sometimes, though, I feel like I'm spending too much time with my nose in my notes, and that I'm losing the students' interest because of it. Obviously, if I were presenting the same material multiple times (or had more time to rehearse), there would be less need to rely on notes—but that's not the situation I'm in. Any ideas for addressing this?
2. Off-topic questions: I encourage students to ask questions, but sometimes they ask things that would be better addressed later down the road, or which would take us too far off-course to get into at present. What's the best way to handle these questions? Give a brief summary answer in general terms, with a promise that we'll explore them more fully later?
3. Finding the right balance between "me talking" and "them doing stuff". I don't want to just drone on forever, so I'm trying to punctuate the HTML class with little hands-on exercises that let them apply some of the stuff I've just taught. Is there any general rule about the rhythm and balance of this, or does it really just depend on the students?
You want the 7-20 rule. Every seven minutes you should do something different. Every twenty minutes your students should do something different.
posted by SyraCarol at 12:12 PM on January 24, 2014 [2 favorites]
posted by SyraCarol at 12:12 PM on January 24, 2014 [2 favorites]
I've taught a couple very small classes (usually no more than 3 or 4 people at a time) a number of years ago with HTML, and the following things come to mind.
Be careful with analogies to explain systems - they can be amazingly helpful if judiciously used, but can get out of hand easily and end up just confusing the situation more. If you decide to go with one, think it through so the analogy that makes sense over the whole session.
HTML is fairly straightforward, but I think one of the most important things I've learned in situations like this is to set the groundwork of how to look at HTML first. A decent portion of the people I've worked with were looking at programming in a very linear left to right, top to bottom way, as if it's like writing an essay, rather than a series of different objects inside a container. This can frustrate a lot of people who are really trying hard to figure it out, but their brains are trying to keep up with every little tag, command, and element as they write it out. Once they see HTML as kind of like a map, showing countries inside continents, states inside countries, and so on as opposed to something like a movie script where things follow a linear path, they pick up on how it all works much quicker.
As for off topic questions, I used to make sure I could at least give a very general answer, but make a note to save the last bit of the lesson to address those more complicated ones, and give them a few sites where they can see an example of what they are asking about, and have them look at the code and see what they can deduce from what they already know. It's not about teaching that part here and now, but to get them not only comfortable with approaching code that they haven't seen before, and that it follows the same rules and patterns that they have already learned. This has the benefit of keeping those students who are advancing faster interested, and reinforce the idea to those struggling that no matter how complicated it looks, everything follows the same general pattern.
Lastly, I'd suggest having them send links to you on sites that have elements they find interesting and want to learn how to do. Pick a few and work them into examples in classes where the whole class tries to 'play detective' and figure out what's going on in the code. This is not an easy thing as a teacher to get right at first, but with a little practice, you'll see how to present it more effectively, and you will end up with a more engaged class.
posted by chambers at 12:14 PM on January 24, 2014
Be careful with analogies to explain systems - they can be amazingly helpful if judiciously used, but can get out of hand easily and end up just confusing the situation more. If you decide to go with one, think it through so the analogy that makes sense over the whole session.
HTML is fairly straightforward, but I think one of the most important things I've learned in situations like this is to set the groundwork of how to look at HTML first. A decent portion of the people I've worked with were looking at programming in a very linear left to right, top to bottom way, as if it's like writing an essay, rather than a series of different objects inside a container. This can frustrate a lot of people who are really trying hard to figure it out, but their brains are trying to keep up with every little tag, command, and element as they write it out. Once they see HTML as kind of like a map, showing countries inside continents, states inside countries, and so on as opposed to something like a movie script where things follow a linear path, they pick up on how it all works much quicker.
As for off topic questions, I used to make sure I could at least give a very general answer, but make a note to save the last bit of the lesson to address those more complicated ones, and give them a few sites where they can see an example of what they are asking about, and have them look at the code and see what they can deduce from what they already know. It's not about teaching that part here and now, but to get them not only comfortable with approaching code that they haven't seen before, and that it follows the same rules and patterns that they have already learned. This has the benefit of keeping those students who are advancing faster interested, and reinforce the idea to those struggling that no matter how complicated it looks, everything follows the same general pattern.
Lastly, I'd suggest having them send links to you on sites that have elements they find interesting and want to learn how to do. Pick a few and work them into examples in classes where the whole class tries to 'play detective' and figure out what's going on in the code. This is not an easy thing as a teacher to get right at first, but with a little practice, you'll see how to present it more effectively, and you will end up with a more engaged class.
posted by chambers at 12:14 PM on January 24, 2014
Disclaimer: I taught a few math classes in grad school long ago, and didn't think I was that great at it. For what it's worth:
1. I really struggled figuring out how to be adequately prepared but still flexible. I think what ended up working best for me was: A) a *very* short list of things to remember--say, no more than half a page, so I could check it with a glance; B) a few carefully-worked out examples or visual aids to focus on. In your case that might be some simple example html/css files that you could project onto the wall and talk about.
2. Personally I'd worry that even the general summary would raise more questions and turn into a big derail, so I'd stick to: "that's a great question, remind me if I haven't addressed it by our half-hour break." Or "ask me about it after class".
3. "Them doing stuff" is a great idea, as it keeps everyone awake and gives you a reality check about what's sinking in. I don't have any good rule of thumb for the rhythm.
Other random memories:
- the "them doing stuff" parts took me the most preparation: it's one thing to know how to do something yourself, it's another to be able to quickly understand the approach someone else took, see where they're going wrong, and propose a next step, all on the fly. You have to really know the exercise inside and out. I think my most painful failures came when I skimped here.
- an hour can go by really fast and a lot can go wrong in a computer lab, and any time spent waiting for you to fix something can hurt, so make sure the logistics are all thought through.
- Our teacher-training folks claimed the average time an instructor waits after asking for questions is maybe a second or two. If you say "any questions?" and mean it--count out a few seconds, take a deep breath, make eye contact with everyone, or whatever helps you relax for long enough that people can formulate a question.
posted by bfields at 12:34 PM on January 24, 2014
1. I really struggled figuring out how to be adequately prepared but still flexible. I think what ended up working best for me was: A) a *very* short list of things to remember--say, no more than half a page, so I could check it with a glance; B) a few carefully-worked out examples or visual aids to focus on. In your case that might be some simple example html/css files that you could project onto the wall and talk about.
2. Personally I'd worry that even the general summary would raise more questions and turn into a big derail, so I'd stick to: "that's a great question, remind me if I haven't addressed it by our half-hour break." Or "ask me about it after class".
3. "Them doing stuff" is a great idea, as it keeps everyone awake and gives you a reality check about what's sinking in. I don't have any good rule of thumb for the rhythm.
Other random memories:
- the "them doing stuff" parts took me the most preparation: it's one thing to know how to do something yourself, it's another to be able to quickly understand the approach someone else took, see where they're going wrong, and propose a next step, all on the fly. You have to really know the exercise inside and out. I think my most painful failures came when I skimped here.
- an hour can go by really fast and a lot can go wrong in a computer lab, and any time spent waiting for you to fix something can hurt, so make sure the logistics are all thought through.
- Our teacher-training folks claimed the average time an instructor waits after asking for questions is maybe a second or two. If you say "any questions?" and mean it--count out a few seconds, take a deep breath, make eye contact with everyone, or whatever helps you relax for long enough that people can formulate a question.
posted by bfields at 12:34 PM on January 24, 2014
If you say "any questions?" and mean it--count out a few seconds, take a deep breath, make eye contact with everyone, or whatever helps you relax for long enough that people can formulate a question.
I found that to be one of the toughest things to get a response from, until I changed how I asked and responded to questions during the lesson. I would recommend asking your students 'why' a lot. Why would they put this here? Why does putting this code here save you time later? Why do different browsers sometime end up showing the same HTML code in completely different ways? How you respond to their answers both when they are right and when they are wrong will determine how comfortable they are asking questions at the end of class. Many people refrain from questions for fear of being wrong and looking foolish. Taking a 'wrong' answer and running through it to show what would happen and why can be nearly as useful as teaching the right answer. If you can show them that their questions and responses, whether right or wrong, are both equally needed in order to figure all this out, and you give the answers they give a far shake it removes a good bit of the stress off the student, and the focus is where it should be - on the question, not the student. This will at first take a large chunk of class time, and work on your part to hone your personal method down and know when to move on, but you may find that you end up with a more engaged class with less stragglers overall.
The nice thing is, HTML is flexible enough that things can be done in many different ways, but there are certain methods that are the 'right' way because it saves you time and work. So most of the time the 'wrong' answers are more about thinking ahead and being efficient rather than a simple binary right/wrong thing.
posted by chambers at 1:24 PM on January 24, 2014
I found that to be one of the toughest things to get a response from, until I changed how I asked and responded to questions during the lesson. I would recommend asking your students 'why' a lot. Why would they put this here? Why does putting this code here save you time later? Why do different browsers sometime end up showing the same HTML code in completely different ways? How you respond to their answers both when they are right and when they are wrong will determine how comfortable they are asking questions at the end of class. Many people refrain from questions for fear of being wrong and looking foolish. Taking a 'wrong' answer and running through it to show what would happen and why can be nearly as useful as teaching the right answer. If you can show them that their questions and responses, whether right or wrong, are both equally needed in order to figure all this out, and you give the answers they give a far shake it removes a good bit of the stress off the student, and the focus is where it should be - on the question, not the student. This will at first take a large chunk of class time, and work on your part to hone your personal method down and know when to move on, but you may find that you end up with a more engaged class with less stragglers overall.
The nice thing is, HTML is flexible enough that things can be done in many different ways, but there are certain methods that are the 'right' way because it saves you time and work. So most of the time the 'wrong' answers are more about thinking ahead and being efficient rather than a simple binary right/wrong thing.
posted by chambers at 1:24 PM on January 24, 2014
I'm a learning tech manager, and have designed and performed a ton of technical training.
1. You should walk through your class a few times before you give it, so that you get familiar with your flow and can excise some of the detail from your notes. An outline is great, but your class will flow more smoothly if you have a stronger recall of what you are going to say.
2. "That's a great question! It is: (pick one)
3. Can you structure the training around a specific finished product? At the beginning of class, you tell them, "Today we're going to learn how to make this webpage (show on screen) using HTML and CSS." Then you walk them through the concepts they need to make the page, doing a little bit of lecture and demonstration, and then an exercise for them to do. With four people, you can easily monitor what they are doing and give feedback. Sites like Codecademy and Kahn Academy do this well: a little bit of exposition, then an opportunity for practice. This takes more work to design as an instructor, but it is a much more motivating and richer experience for the learner.
posted by jeoc at 5:29 PM on January 24, 2014
1. You should walk through your class a few times before you give it, so that you get familiar with your flow and can excise some of the detail from your notes. An outline is great, but your class will flow more smoothly if you have a stronger recall of what you are going to say.
2. "That's a great question! It is: (pick one)
- Something we will address later in this class, so hold on to that thought!"
- A little outside the scope of this class, but I am happy to talk about it when we finish here and can give you some great resources."
- Exactly what I was going to talk about next! Thanks for bringing it up!"
3. Can you structure the training around a specific finished product? At the beginning of class, you tell them, "Today we're going to learn how to make this webpage (show on screen) using HTML and CSS." Then you walk them through the concepts they need to make the page, doing a little bit of lecture and demonstration, and then an exercise for them to do. With four people, you can easily monitor what they are doing and give feedback. Sites like Codecademy and Kahn Academy do this well: a little bit of exposition, then an opportunity for practice. This takes more work to design as an instructor, but it is a much more motivating and richer experience for the learner.
posted by jeoc at 5:29 PM on January 24, 2014
With that many students, why not use "just in time" instruction?
Present a challenge, explain the starting point, and let them work.
Set a time limit for it, maybe 10 minutes longer than what it would take an expert.
After the time is up, ask them how they tried to solve the problem and how it went. THEN go over what the "ideal" solution is.
What you've done is A) created schema for understanding and caring about the topic, B) made them ready to hear WHY it works, and how their attempts failed, and C) made it a whole lot more fun.
I also tell them they get bonus points for NOT asking questions (there's actually a post on my blog about this, link in my profile) and I've found that having to figure it out on their own increases engagement and understanding, and helps them learn to collaborate. Or, if you're uncomfortable letting them work without answering questions, help them as they go, keeping it as practical as you can, but pushing them to figure out the "why" part as much as they can. Just articulating their answers makes them more likely to retain them.
It also makes your explanation much shorter and much less likely to be derailed by questions irrelevant to that particular task. People learn by doing. Particularly with technology and coding - it's either a really fun puzzle, or a really boring set of guidelines.
If you really want to start with a lecture, keep it short and focused on one thing. Then let them try. The more they can work hands-on with peers and an instructor around, the better.
posted by guster4lovers at 11:26 PM on January 24, 2014
Present a challenge, explain the starting point, and let them work.
Set a time limit for it, maybe 10 minutes longer than what it would take an expert.
After the time is up, ask them how they tried to solve the problem and how it went. THEN go over what the "ideal" solution is.
What you've done is A) created schema for understanding and caring about the topic, B) made them ready to hear WHY it works, and how their attempts failed, and C) made it a whole lot more fun.
I also tell them they get bonus points for NOT asking questions (there's actually a post on my blog about this, link in my profile) and I've found that having to figure it out on their own increases engagement and understanding, and helps them learn to collaborate. Or, if you're uncomfortable letting them work without answering questions, help them as they go, keeping it as practical as you can, but pushing them to figure out the "why" part as much as they can. Just articulating their answers makes them more likely to retain them.
It also makes your explanation much shorter and much less likely to be derailed by questions irrelevant to that particular task. People learn by doing. Particularly with technology and coding - it's either a really fun puzzle, or a really boring set of guidelines.
If you really want to start with a lecture, keep it short and focused on one thing. Then let them try. The more they can work hands-on with peers and an instructor around, the better.
posted by guster4lovers at 11:26 PM on January 24, 2014
I teach kids and adults HTML/CSS and Photoshop. In an ideal world, all my lessons would go down like this:
Step 1: Introduce concept. Tap prior knowledge. What do the people in the room already know about the concept of the lesson? How might this concept relate back to previously discussed concepts? (5 min max unless good discussion is going on)
Step 2: Launch your lesson. What's the objective? You should be able to fill in the blanks for every lesson... Given _______ (where blank is a lecture, activity, experiment, whatever), trainees will be able to _________ (desired outcome). (Example: Given teacher modeling and an activity on object classes, students will be able to modify the style sheet of a div layer and customize its borders, background color, and fonts.) Model the thinking and procedures you'd like them to acquire. Check for understanding. Ask things like, "Why would I elect to do X rather than Y?" (10 min)
Step 3: Provide trainees with the chance to explore the concept. This is your opportunity to give students the chance to make sense of what they've learned thus far, apply it in a practical context, and ask questions as needed. You should take this time to walk around and touch base with every student so you can assess their individual progress, and take the temperature of any concepts that may need to be retaught. Definitely have at least 3 activities available for people to try if they finish early and need something more challenging to do. I sometimes like to give people really complicated, finished style sheets and have them go looking through the different classes to see how screwing around with the parts they already know impacts what they see on the .html doc referencing them. YMMV. (30 min)
Step 4: Call everyone back for a recap. This is called summarizing or closing the lesson out in teacher-speak. Ask people what they noticed as they explored the concept of the day. Spiral review any other concepts you've covered in the past and ask students to make connections. Re-demonstrate anything that's confused folks. Assign homework, set expectations, then rinse/repeat the next time around. (5-15 min)
Feel free to get in touch if you'd like a template lesson plan to help you chunk up your notes into meaningful sections.
posted by These Birds of a Feather at 12:24 AM on January 25, 2014 [3 favorites]
Step 1: Introduce concept. Tap prior knowledge. What do the people in the room already know about the concept of the lesson? How might this concept relate back to previously discussed concepts? (5 min max unless good discussion is going on)
Step 2: Launch your lesson. What's the objective? You should be able to fill in the blanks for every lesson... Given _______ (where blank is a lecture, activity, experiment, whatever), trainees will be able to _________ (desired outcome). (Example: Given teacher modeling and an activity on object classes, students will be able to modify the style sheet of a div layer and customize its borders, background color, and fonts.) Model the thinking and procedures you'd like them to acquire. Check for understanding. Ask things like, "Why would I elect to do X rather than Y?" (10 min)
Step 3: Provide trainees with the chance to explore the concept. This is your opportunity to give students the chance to make sense of what they've learned thus far, apply it in a practical context, and ask questions as needed. You should take this time to walk around and touch base with every student so you can assess their individual progress, and take the temperature of any concepts that may need to be retaught. Definitely have at least 3 activities available for people to try if they finish early and need something more challenging to do. I sometimes like to give people really complicated, finished style sheets and have them go looking through the different classes to see how screwing around with the parts they already know impacts what they see on the .html doc referencing them. YMMV. (30 min)
Step 4: Call everyone back for a recap. This is called summarizing or closing the lesson out in teacher-speak. Ask people what they noticed as they explored the concept of the day. Spiral review any other concepts you've covered in the past and ask students to make connections. Re-demonstrate anything that's confused folks. Assign homework, set expectations, then rinse/repeat the next time around. (5-15 min)
Feel free to get in touch if you'd like a template lesson plan to help you chunk up your notes into meaningful sections.
posted by These Birds of a Feather at 12:24 AM on January 25, 2014 [3 favorites]
Completely agreeing with These Birds.
1. Always start with a lead-in and elicit responses. When you find out how much people know (and who knows it!) you can find out what you have to teach.
2. Then move on to what it is and why you need to know it. People always need to know why something is needed or important.
3. Have them do as much hands-on work as possible, working in pairs or groups if they desire. (This is what we call Student Talking Time in my course -- it's beneficial because students are the ones learning and they need the most work.)
4. Try to make sure that everyone understands, not just the best student.
We were taught to think about activities like this:
Teaching to the whole class -- great for lectures and explanations but too long leaves students bored and everyone has to do everything at the same time.
Individual work -- Good for independent learning at their own pace. Bad when students don't understand.
Pair work -- Good way to have students help each other. Bad when pairs become awkward or people talk about other stuff.
Group work -- Good for people being co-operative. More likely to contact each other in the future. People can choose how much to say. Bad when someone takes over.
What I do is very unrelated to what you are doing (I'm doing a ESL course) but some methods still apply.
posted by Ms. Moonlight at 9:32 AM on January 25, 2014
1. Always start with a lead-in and elicit responses. When you find out how much people know (and who knows it!) you can find out what you have to teach.
2. Then move on to what it is and why you need to know it. People always need to know why something is needed or important.
3. Have them do as much hands-on work as possible, working in pairs or groups if they desire. (This is what we call Student Talking Time in my course -- it's beneficial because students are the ones learning and they need the most work.)
4. Try to make sure that everyone understands, not just the best student.
We were taught to think about activities like this:
Teaching to the whole class -- great for lectures and explanations but too long leaves students bored and everyone has to do everything at the same time.
Individual work -- Good for independent learning at their own pace. Bad when students don't understand.
Pair work -- Good way to have students help each other. Bad when pairs become awkward or people talk about other stuff.
Group work -- Good for people being co-operative. More likely to contact each other in the future. People can choose how much to say. Bad when someone takes over.
What I do is very unrelated to what you are doing (I'm doing a ESL course) but some methods still apply.
posted by Ms. Moonlight at 9:32 AM on January 25, 2014
I teach programming and web development at a Canadian college. The following two sets of audio lectures improved my understanding of teaching and learning immensely.
* Art of Teaching: Best Practices from a Master Educator
* How We Learn
I recently started screencasting my lectures, saving a video of my laptop screen and my voice for later review on YouTube. Most of my lectures involve the live coding of example applications and websites. I've received a lot of positive feedback from my students for making these videos available. The videos also allow me to review and optimize my lecturing style.
To address your specific questions:
1) The notes I create for my lessons are available for my students to review outside of class. This way I have more freedom with my lectures. I can even assign portions of my notes as assigned reading material.
2) jeoc's suggestions for off-topic questions are spot on. I especially like "idea parking"! On a related note, I've been thinking about creating an online backchannel that the quieter students can use to submit questions during my lectures.
3) To ensure a balance between me talking and students doing, I assign what I call "Ultimate Challenges" which are short in-class coding tasks. A new challenge is presented after each new topic. Students receive marks for a valiant effort, rather than for perfect results. Unlike take-home assignments, which are also part of my courses, these challenges give my students the permission to fail epically and learn from their mistakes. Students are also free to pair-program their challenges.
All the best with your teaching. And remember to enjoy the process, your students will pick up on your enjoyment and enthusiasm.
posted by stungeye at 5:39 PM on January 25, 2014 [2 favorites]
* Art of Teaching: Best Practices from a Master Educator
* How We Learn
I recently started screencasting my lectures, saving a video of my laptop screen and my voice for later review on YouTube. Most of my lectures involve the live coding of example applications and websites. I've received a lot of positive feedback from my students for making these videos available. The videos also allow me to review and optimize my lecturing style.
To address your specific questions:
1) The notes I create for my lessons are available for my students to review outside of class. This way I have more freedom with my lectures. I can even assign portions of my notes as assigned reading material.
2) jeoc's suggestions for off-topic questions are spot on. I especially like "idea parking"! On a related note, I've been thinking about creating an online backchannel that the quieter students can use to submit questions during my lectures.
3) To ensure a balance between me talking and students doing, I assign what I call "Ultimate Challenges" which are short in-class coding tasks. A new challenge is presented after each new topic. Students receive marks for a valiant effort, rather than for perfect results. Unlike take-home assignments, which are also part of my courses, these challenges give my students the permission to fail epically and learn from their mistakes. Students are also free to pair-program their challenges.
All the best with your teaching. And remember to enjoy the process, your students will pick up on your enjoyment and enthusiasm.
posted by stungeye at 5:39 PM on January 25, 2014 [2 favorites]
This thread is closed to new comments.
In my opinion, the most valuable asset as an instructor for these kind of courses are:
- A conceptual overview (why are you doing this? what is a general approach to the technical tools? ex: html/css is a linear, text-based way to describe 2d rules and logic.)
- Technical feedback/troubleshooting help ("I can't fix this, can you help?")
- A structured sequence (it's helpful to do this, after this, and then do this)
- Opportunities for group feedback.
All the technical knowledge is online, and it's better and vastly more comprehensive than any one person can offer. But stackoverflow is never going to be a replacement for a human instructor, so I'd focus on those four aspects. Some ideas/solutions I've found:
If you can find the time to do it, have screencap videos, or resources available. In my experience, there's a lot of questions along the lines of "what did you do" that is best solved via a video. People can rewind backwards and listen to something again if they don't get it, etc. Warning: This takes a LOOOOONG time, often 3x the time it takes to run through a one video, since you want to rehearse it once or twice and record it once.
If the course is project-based, then you can have a lot of time having people talk about their projects and giving critical feedback.
If the course is technique-based, then you can do a short session, and have them work on it on their own while you walk around offering troubleshooting/feedback.
All in all - orient the classes around a series of short tutorials, and a lot of questions/feedback. I find that to be most helpful, since "you talking" is really not going to give people knowledge that is best learned hands-on.
posted by suedehead at 12:11 PM on January 24, 2014