Remote workshops (or any workshops for that matter) should provide disproportionate value to the people who show up. In order to accomplish that, we try and design our workshops so that they can be adjusted, sometimes on-the-fly, in order to provide the most value to the people who are attending.
As part of the process of designing a new workshop we do a couple of things to help us tailor the content to the people who are in the room zoom. This includes: creating an audience profile, drafting a schedule, and designing learning chunks.
Create an audience profile
Drupal to Drupal migrations, the workshop we're currently working on, is a huge topic. Given how many blog posts, tutorials, and webinars have been created to cover it already it's easy to see how it would be really hard to narrow it down to a tight and valuable couple of hours. It's important to know your audience because what you teach and how you teach it are based on who you are teaching.
For each of our workshops we create an audience profile and try to describe the people who we think are most likely to sign up for the workshop. This is done by asking questions like:
- Who's coming? Agency developers? Freelancers? Are they evaluating the technology for possible future use? Or are they already in the middle of a complex implementation? Are they a lone developer? Or will they be attending with others on their team who have a shared goal? If multiple people from the same organization are attending, they should be able to work together on real, shared, problems instead of toy examples in isolation.
- What direct experience do they have? What do they already know? Do they have practical experience with the topic already? Or just theoretical knowledge? Do we need to cover basic terminology or can we skip ahead?
- What related experience do they have? Have they built websites with WordPress before but never Drupal? Are they a Java expert with years of system design experience who is just learning PHP now?
- Why are they showing up? What are they hoping to learn? What would make this workshop a success for them? Are they participating in a synchronous workshop vs. doing asynchronous study for time-management? Are they attending because their boss wants them to? And if so, what does their boss want them to learn?
- What objections or concerns do they bring with them? Have they tried a migration in the past and been burned by the process? Are they annoyed that their boss is making them go? What prejudices around the topic are they carrying that you'll need to work around or through?
The main purpose of this audience profile is to inform which learning objectives will be most relevant. It also helps us decide what to cut, and what to keep. These profiles can also be useful when marketing the workshop, and helping people self-select if this is going to be valuable for them.
Draft a schedule
How long is the workshop going to be? How do breaks fit in? Is it a full day? If so you'll need to make sure you break for lunch. Having a rough idea of how you plan to break up the time you have available will help inform how much you can cover. That leads to helpful boundaries to use when figuring out things like how many slides to include, or how long to give people to work on an exercise.
Our theming workshops are run as either a single 8-hour workshop, or 3-day by 3-hour workshops.
For the 8-hour version we include 60 minutes for lunch, 2 15-minute coffee breaks, and a 15-minute buffer on either end. This leaves us with 4 75-minute time slots. We usually do 2 learning objectives per time slot, so a total of about 35 minutes per objective. Some of those slots get reserved for things like Q&A or practice time.
For the 3-day version we have 3 3-hour chunks of time in all. Each of these have a 10-minute before/after buffer and a 15-minute break in the middle, giving us 2 72-minute chunks of learning time, which we also usually divide into 35-minute slots.
This tells me that when I'm designing a set of materials to cover a specific objective I need to fit that into 35 minutes. Or, at most 70 minutes if it's more complex. I usually even divide this further, 10 minutes for lecture, 15 minutes for practical application, 10 minutes for Q&A and recap.
Design learning chunks
With an audience profile in place you can start to define the learning objectives for the workshop. What are you going to teach people? We often do this using the common SWBAT (Students Will Be Able To) format. Regardless of the framework you use to define learning objectives, the most important part is to make them as specific as possible. We'll create presentations, handouts, and exercises all based on these objectives. Remember, workshops operate in a fixed period of time. If you want to teach something you have to be willing to exclude everything else.
Example
| Topic | Bad objective | Better objective |
|---|---|---|
| Migrations | Process plugins | How to chain process plugins together into a processing pipeline |
| Migrations | Running migrations | Write scripts that everyone on the team can use to consistently execute, and rollback, migrations in their testing environment. |
| Theming | Write Twig templates | Use Twig to output the value of a specific field nested inside the {{ content }} variable. |
| Theming | Add CSS to a theme | Define asset libraries for incorporating CSS from the Bootstrap framework and custom global styles on every page of your site. |
Then, with a draft schedule in place, I know roughly how much time I can dedicate to each objective. (This also has the effect of knowing how many objectives I can hope to cover during the entire workshop.) And I can design the slides, exercises, and other materials for each chunk.
One thing that we often do is create more of these learning units than will fit into the schedule with the intent of mixing and matching things a bit depending on who is in the room. While we've got a profile in mind when creating the initial skeleton for the workshop we want to be able to adjust things depending on the actual final audience. And, be able to offer our workshops to a broader group of people.
For the theming workshop we've got a unit that covers "An introduction to Drupal themes" which covers basic terminology, the concepts of inheritance, and asks students to explore the themes in Drupal core and the UI provided for managing them. This is a great lesson if the room is full of people who are totally new to the world of Drupal themes.
But, if a particular instance of the workshop is attended by people who all have experience theming Drupal 7 sites and are wanting to learn how to do it in Drupal 8, we can skip that unit. It would be a waste of everyone's time and energy. Instead we'll swap in a unit on "Breakpoints and Responsive Images", or "Compiling JavaScript with Webpack" that we would otherwise have left out due to time constraints.
Conclusion
If you plan for your workshops by starting with an audience profile, a draft schedule, and discrete learning chunks, you can facilitate a better overall experience. One that allows for self-direction/self-selection. Rather than prescribing what every minute of the entire workshop will look like you can provide opportunities for the people who are there to propose topics. And, you can adjust the plan on-the-fly. Instead of beating yourself (and your students) up if things aren't moving as fast as planned it's easy to drop a chunk when the borders between them are well defined.
Because remember, workshops should provide disproportionate value to the people who chose to show up.
This isn't anything new, and is well covered in books like "How to Design and Teach Workshops that Work Every Time" by Fitzpatrick & Hunt. But it's fun to share the thought process we go through. It's come a long way since 2009 when I first started at Lullabot and we would show up for a week long theming workshop with only 3 days worth of content and made the rest up the night before! Both approaches allow for tailoring the content to the audience. But it's a lot less stressful now.