User:OrenBochman/Running A Demo
 | This is an assignment for Simone's adoption program. You are welcome to edit this page if you notice any errors or have any additional information to add, but as a courtesy, please notify OrenBochman if you make any major changes to avoid any possible confusion between him and his adoptee(s). Thanks! |
Strategies for running a fabulous tutorial
[edit]It is not enough to create great extensions. No one will use them if you do not publicise your work. The same is true about any type of development work you are doing. In this tutorial and the next, you will learn how to become a better educator and deliver a smashing tutorial
People learn skills by practicing them. That's the reason we run tutorials at the hackathons. They are an important part of MediaWiki culture, as mentorship has been since the beginning. The difference between a presentation and a tutorial is active hands on involevment. Talks, presentations, slide decks are all passive for the audience. Tutorials put people into action.
Learning styles: about the students
[edit]- kinetic
- verbal
- auditory
There are many learning styles, most of which fall into three categories: hearing something, seeing or doing/touching something. Of these, doing something builds skills the fastest. So how can you teach skills to people with all of these learning styles? Mix it up! Include several types of exercises/hands-on activities in your tutorial.
Developer culture leans toward looking at code. It's a primary activity in dev. But, it's not the best way to learn a skill. Why? If you just show a code snippet and talk about it, tutorial participants are engaged in listening, a passive particpation. They are taking in information, but not using it yet. To learn a skill, people need a chance to actively participate, to practice the skill by doing it.
Tutorial structure
[edit]A successfull tutorial has a structure. This is the recommended structure for an academic tutorial.
- Beginning—tell them what you are going to tell them.
- Middle—tell them.
- End—tell them what you have told them.
However it is recommended to go beyond the dry academic model by adding another level of structe aimed at connecting with your audience emotionaly by creating interst. For each point:
- Hook—get the audience interested.
- Tap into their problem or pain.
- Speak to thier hopes and fears.
- Weave a powerful story of success.
- Deliver the key message.
- Share the principles that support the key message.
- Interact with one of the startegies listed next, e.g.
- Handle a question
- Do a hands on training task.
- Summarize your key message.
- Close with your key message framed as as a call to action.
Teaching strategies and exercise ideas
[edit]Teaching strategies tend to fall into these categories: inductive, expressive, deductive, prediction. Thinking about your topic in terms of each category might give you some exercise/activity ideas. Here are some more:
- Repetition - repeat your most important points/skills at least several times
- Positive reinforcement of specific actions wires that behavior into brain (toss out candy/schwag or praise)
- Break into groups/paris and work on a problem together (have a time limit and way to get their attention again)
- Practice solving a problem in a code snippet, lab, etc.
- Create something that summarizes your tutorial info: infographic, chart, article stub, template, summary doc, help page, guide, cheat sheet, etc.
- Quiz each other, vetting quiz (last one standing wins, game of tag asking questions of each other)
- Report back to whole group about results, observations, etc.
- Ask for their examples, experiences with problems
- Have them teach each other or you
- Brainstorm solutions together
- Predict the results of something after you've demonstrated it once or more
- Question and Answer, but you ask the questions and participants answer (toss schwag to the correct answer).
- Fill-in the blank, complete/improve this example, find the problem/bug, solve this problem, etc.
The workshop
[edit]"Students"/dev tutorial participants are more likely to use what you taught them if they have a specific opportunity to practice it immediately. This can be challenging, depending on the subject you're training people in and the resources at your disposal. So, preparation time is important for creating a practice zone. Preparation for "students" is important, too! If they have a chance to look at the materials and experiment with the "practice zone" before the tutorial, they are more likely to bring good questions and to learn faster during the tutorial.
If you have a Lab, Sandbox or Project they can work in, be sure you publish the URL, path, permissions process, etc. well ahead of time. Nothing is worse than losing 15 minutes of a 45 minute tutorial to get everyone logged in. If there are additional manuals, guides or live help options, be sure they have those links, handles, IRC #s, email lists/addresses, places to find a mentor, etc.
Offering resources, encouraging participation
[edit]Empowering people with ongoing opportunities to engage with the dev community obviously increases the chances that they will contribute code. But, it also strengthens our community and encourages mentorship. Again, if there are additional manuals, guides or live help options, be sure they have the links, handles, IRC #s, email lists/addresses, places to find a mentor, etc. (This is an example of repetition. I want to drive home the message that you should reiterate your most important points - loop, recurse, repeat, repeat.).
Ask for feedback before your audience leaves
[edit]Why?
- Open communication is part and parcel to the open source world
- You can become a better teacher
- You can develop better relationships with devs who can help with your projects
- You can develop a better tutorial the next time
- It tells devs that their experience matters to you
- It makes devs more likely to say good things about you and your tutorial
- It makes devs more likely to participate in future hacking
- It gives you the chance to learn
- It's just really darn good for the community! So, do it.
You can get quick feedback by asking for a show of hands in response to some key questions. This helps keep communication open and increases the likelihood that your audience walks away feeling good about your tutorial. You can also create a form online to collect anonymous feedback or MediaWiki/Tutorial discussion/talk page or simply ask people to email/msg/talk page you with their feedback right then and there.
Follow up
[edit]Follow up your tutorial immediately, with a user page notice or email to participants, including links, resources and info about ensuing on-wiki discussions. This helps to keep them involved and may help you with more eyes/hands on a project.
Test yourself
[edit]| QUESTION |
|---|
| What is the problem for presenting the audience with talks, presentations and slide decks ? |
| ANSWER |
|---|
the problems are:
|
| QUESTION |
|---|
| How can you make a code snippet varient more interesting the second time round ? |
| ANSWER |
|---|
you should engage by:
|
| QUESTION |
|---|
| How should you end the tutorial ? |
| ANSWER |
|---|
you should engage the audience one more time by:
|
Discussion
[edit]Any questions or would you like to take the test?