Since we’ll be holding our second week-long Digital Research Institute in June, I thought I’d put together a list of the lessons I’ve learned teaching technical workshops over the past two years. If you have more lessons in mind, drop me a line at @psmyth01.
What specific skills or knowledge do you want your attendees to have when they walk out of your workshop? It’s often easy to have nebulous goals for your attendees, such as “become familiar with the command line” or “learn Python.” While it’s all right to promote your workshop with more general terms, the main event will go more smoothly if all steps taken in your workshop move toward a single, specific goal. Thus, “build a tiny Create-Read-Update-Delete app” or “remove duplicates from this data set” are better than “learn SQL” or “become familiar with JSON.” Students learn better when working toward concrete goals, and the sense of accomplishment that comes with achieving something specific encourages students to continue to learn after the workshop.
Think back to a time before you learned the technical skill you’ll be teaching. What knowledge did tutorials and teachers assume, but that you didn’t have at the time?
There are many technical concepts that can seem simple or obvious after long exposure, but which take time and experience to fully understand. Experienced users tend to forget a time when they didn’t know about these concepts, and so often don’t give them enough time and attention in workshops. They include:
Unless you’re sure your attendees will be highly technical, don’t assume a full grasp of these concepts, and leave time to address them in your session.
This is a corollary of “Don’t Assume,” but it’s worth saying this explicitly. In computer interaction and programming, it’s easy to fall into the specific language of the field. Terms like “argument,” “method,” and “array” are useful because they’re specific and descriptive. However, for those that don’t read technical documentation every day, they can impose a cognitive load, and for beginners they can be downright baffling. Fully explain any technical terms you use, and, if possible, repeat a shorthand definition the next few times you use the word. For example: “an argument—you know, something you pass IN to a function.”
“Multimodality” is a fancy word for getting information across using a number of media. In other words, don’t just put an instruction on a screen or say it out loud. Put it on the screen AND say it out loud AND put it on a handout AND put the handout online. Ideally, every communication you make should be iterated in three different places.
This can seem pretty extreme, but it will save you trouble in the long run and makes learning much easier for attendees. First, it’s very common for attendees to mishear, zone out, become distracted by a neighbor, or fall behind. By providing multiple means of viewing instructions, you mitigate these inevitable lapses in communication. Second, handouts and online materials remain available to students after your sessions. Finally, many attendees may have hearing, vision, or cognitive disabilities that make it difficult to follow information from a particular medium. By providing multiple channels of communication, you make your workshop more inclusive and accessible.
Another facet of multimodality is using unconventional materials or media to impart difficult concepts. For example, Digital Fellow Hannah Aizenman uses poster paper and markers to have students create visualizations before using a computer. This allows students to think about methodology before getting bogged down in the details of a specific program or tool.