The subtle art of workshop-giving

People working on computers at a workshop
"The moment behind the photo workshop," by ABC Open Central Victoria

Over the last couple of years, I’ve given a number of (somewhat) technical workshops for grad students and faculty here at Emory. I love doing it. It’s really gratifying to impart skills, and preparing for workshops gives me a chance to think through and develop my own knowledge in a systematic way.

It’s not that easy, though. Teaching a workshop requires no less skill than teaching any other kind of class, and just as much preparation. It’s also slightly different from, say, leading a discussion section; it requires a different method of instruction and different kinds of preparation.

This semester, one of DiSC’s grad fellows, Franky Abbott, has been helping us perform a comprehensive assessment of our activities, including workshops. With Franky’s help, we’ve been collecting and analyzing survey results, and I now feel I have a much better sense of what works and doesn’t work for students.

Be clear about content and prerequisites

If the workshop’s for absolute beginners, say so. If it requires some knowledge, say that, too. If it’s more appropriate for humanists or social scientists, let the students know in advance.

Hands-on is better

If there’s a way you can get students working along with you, the experience is much more meaningful for them.

Have a helper

You need at least one person to roam the room while you’re demonstrating. This person should watch for students who are having trouble, tell you when you’re going too fast, and ask questions when you say something confusing.

Have a handout

Students love handouts. It alleviates a lot of their anxiety about keeping up with notetaking or trying to remember all the information.

Offer an agenda

This doesn’t have to be formal — you can just write it on the board — but students really like to know what comes when, even more than they do in conventional academic settings. I think this is because they get nervous about whether they’ve missed something or whether it’s coming later in the workshop.

Have students work in pairs

During one workshop, we ran out of laptops, so we had to pair students up. I was amazed at how well that worked. They could help each other without feeling they had to stop the workshop to get my attention.

Many students won’t tell you when they need help

I was surprised to discover that many people are extremely reluctant to hold up a workshop, even when they’re totally lost. That’s why you need to stop frequently, walk around the room, and make sure everyone’s keeping up. I like to learn students’ names and then ask them individually, “Still with me?”

Go sloooooow

You basically can’t go slowly enough. Speak slowly. Repeat yourself. Narrate every action you perform, even if you’re just double-clicking on an icon. People often get lost because of little things like that.

Zoom in on your code

This is a trick I learned from Jeremy Boggs. On a Mac, just pinch outward with two fingers to zoom in. It helps enormously. And be sure to stay zoomed-in on code for longer than you think is necessary.

Many students won’t prepare

No matter how much you plea, many students won’t install software in advance. If you can, have backup laptops available with the software already installed.

Ask students to be patient with each other

I like to ask students to remember that we all have trouble with different things. Often what’s obvious to one person is baffling to another, and vice versa. I tell students that there will very likely be moments when they have to wait for someone else to catch up, and that’s OK.

Give yourself enough time

Workshops become very stressful when you’re trying to both keep everyone on top of the material and make sure you end on time. Give yourself more time than you need.

4 Replies to “The subtle art of workshop-giving”

  1. Great post Miriam. I teach a lot of workshops as well and this resonates. An unlikely piece of advice I would like to add is:

    Don’t be afraid to lecture a little

    I find that a lot of people in the academy are looking for a structural and sometimes theoretical background for how and why a tool works. One shouldn’t be afraid to take the time to explain that architecture. For example, when I teach our wiki workshops I explain some of the origins of wikis, what motivated their creation, how they differ from other CMSes, what ideologies define their operation and interface and how those characteristics align with our institutional practice. I can see students making a connection that will help them do self-discovery, and I also get to do some instruction of how and why these tools are important for contemporary academic practice. Same goes with Zotero workshops. Explaining the history of the tool, along with its predecessors such as Refworks and Endnote, allows me to frame why it is the way it is and how understanding that why will make it easier to use the tool. (I especially like being able to tell my story about Roy Rosenzweig coming to CUNY while I was a student and giving his early Zotero lecture complete with a box of notecards).

    That being said there of course also needs to be the nitty gritty of allowing people to get their hands dirty and not letting the lecturing get out of control.

    Oh yeah, one last thing I would add is that institutions should try to provide their own step-by-step tutorials for different tools that are aimed at their constituents. We have done that with our wikis and with Prezi, since they are used by so many, and having it in a familiar voice is a good bridge for helping after the workshop is over. I know that my assistant has done a great job at building these out and it is a great resource for students when neither she nor I are available for help. If you want to take a look they are here:

  2. Such a good call, Kimon. I think we humanists are trained to facilitate free-form discussions, which is generally awesome. But in a situation where you’re trying to impart technical skill, students often want a lot more structure than we’d normally introduce.

    That’s an interesting point about developing specific tutorials for constituents. That’s my own inclination, too, but I often correct myself and think, “No, no point duplicating effort.” But you’re right, voice matters a great deal in a tutorial, and you know your constituents best. Incidentally, I love ScreenSteps for developing tutorials.

  3. Great advice! I just finished presenting a series of workshops on Anthropac, NetDraw, and UCINet, and I can remember almost every one of your tips coming up throughout the semester. I wish I had this list when I started!

    I will have to check out ScreenSteps for making documentation, but do you have any advice about creating screencast recordings for teaching software?

  4. Wow, those are some cool workshops, Russell! You know, I have yet to master the art of screencasts. Maybe that’s next on my agenda! I do tend to like Snapz Pro for screen capture in general, though.

Leave a Reply

Your email address will not be published. Required fields are marked *