[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipsecon-na-program-committee] raising the bar etc. for tutorial presenters
|
Memories from our tutorial a few years back. I didn't look to see if we got great marks, to be honest, because it was a very difficult period for me personally. What I remember we did was to prepare all our exercises in advance and give them to several people with eclipse experience and no understanding of the project to see if they could install the prerequisites. Once we had that, we had 2 people wandering the audience with flash drives to make sure people could get set up.
I know the team spent a lot of time getting ready, but perhaps it was hard to understand their (non-North American) accent. That can't be helped. Not everyone can be a natural at standing on stage, so we have to figure out what is the barrier between professional content with compelling speakers and knowledgeable speakers with so-so presentation skills. Not everyone can be a clown and clearly know nothing as I manage to do every year. ;-)
If we think there are some tutorials that are at risk, perhaps it would be good to pair them with some mentors who can guide them through milestones and prep work. But I am just one person, so I also nominate John Duimovich. ;-)
-E
On Tue, Jan 24, 2012 at 9:29 PM, Anne Jacko
<anne.jacko@xxxxxxxxxxx> wrote:
Thanks, John. More good information to distill and provide to tutorials presenters!
Anne Jacko
Eclipse Foundation
On Jan 24, 2012, at 12:27 PM, John Arthorne wrote:
I will mainly echo Tom Watson's comments:
- Having well prepared exercises is
important. You want something more advanced than "hello world"
so people feel like they got value out of it, but don't rely on people
writing extensive chunks of code during the allotted time. Write the parts
of the exercise code that are not relevant to your tutorial in advance,
so they can focus on the particular area you are teaching. Bad exercise
example: write an Eclipse application from scratch that integrates with
<some technology>. Good example: Here is a 90% complete Eclipse application,
write the remaining 10% integration code to connect with <some technology>.
- Allocating no more than 25% of the
time to slides sounds like a great rule of thumb. It's fine to have extra
slides that you don't cover in the tutorial so people can read them afterwards
as a refresher.
- Having a way for people to skip steps,
or "catch up" if they missed a step is critical. Otherwise if
someone gets behind near the beginning they may waste the next three hours
because they can't catch up. Gunnar had an excellent plugin for managing
this that he used in his server side tutorial. Maybe he can share a link
to that code or put the plugin up somewhere that all presenters can find
it.
- It is important to keep things interactive
even when not doing exercises. It's otherwise too easy for someone to zone
out, start surfing the web, etc, because you exceeded their attention span.
Ask the audience questions, add a pop quiz, or let the audience vote on
what module you do next to keep the audience engaged. Sometimes tutorials
give out novelty prizes to keep people engaged and to add some fun to it.
- Don't assume wireless will work quickly
or reliably - have a contingency plan for when wireless fails or is too
slow to download builds, etc.
John
Hi all,
You may recall that we discussed trying to improve tutorials
at ECon this year. Past attendee surveys have consistently rated tutorials
lower than other types of talks. The most common complaint is that tutorial
presenters are not well-prepared and too much time is wasted getting people
set up. Another issue is lack of organization in presenting the material.
It's understandable that attendees feel frustrated when they have invested
a half-day at a session and don't feel they got enough out of it.
I will soon be contacting all tutorial presenters about
their volunteer helpers, so this is a good time to convey suggestions or
expectations to them.
I would appreciate input from any or all of you about
what to communicate to the presenters. Concrete ideas and useful URLs are
best.
Thanks in advance, and I look forward to gathering and
sharing your input.
Anne Jacko
Eclipse Foundation
503-784-3788 (cell)
_______________________________________________
eclipsecon-na-program-committee mailing list
eclipsecon-na-program-committee@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipsecon-na-program-committee
--
Eric Cloninger (
ericc@xxxxxxxxxxxx)
Product Line Manager, MOTODEV Tools
Eclipse Sequoyah Project Lead
