Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseCon Tutorial Guidelines"

(Advice from experienced tutorial presenters)
 
(41 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Thanks to Tom Watson, John Arthorne, Eric Cloninger, and Gunnar Wagenknecht.
+
<!-- == EclipseCon 2013 ==
 +
Factoids about the 2013 tutorials (everything in this list will also be communicated via email to tutorial presenters):
 +
* We want EclipseCon tutorials to be really great. Attendees spend half a day in each tutorial, and their expectations are high. As a presenter, you invest a lot of time and effort, and you deserve a good return on your investment. In our post-conference surveys, attendees have consistently given tutorials lower marks than other types of talks. We want to change that!
 +
* We are recruiting [http://wiki.eclipse.org/EclipseCon_Tutorial_Guidelines#Volunteer_Helpers student volunteers] to serve as tutorial helpers.
 +
* Tutorial rooms will be set "mixed" -- mostly tables, with a few rows of chairs at the back.
 +
* Tutorial room capacities vary in size. To find out the capacity of your room, email [mailto:speakers@eclipsecon.org speakers@eclipsecon.org].
 +
* Rooms will have WiFi and power strips. We can't guarantee the speed or reliability of the WiFi, so be sure your tutorial will go well even if the WiFi isn't great. The WiFi is generally good, but hundreds of tutorial attendees downloading software packages at the same time will definitely have an impact. The best solution is for attendees to arrive at their tutorials with software already installed.
 +
* Attendees are asked to pre-register for tutorials. We stop registration for a tutorial when it reaches capacity, but we do not check a registration list at the door to make sure everyone in the room is "legal." It's an honor system.
 +
* To get the list of email addresses of your tutorial registrants, email [mailto:speakers@eclipsecon.org speakers@eclipsecon.org]. Please be sure to keep this list private and only use it for communicating about the tutorial; we need your help to maintain the Foundation's strict privacy policy.
 +
* We have 8 USB memory sticks for each tutorial. If you think these will be useful, please ask for them when you register at the conference. USB sticks are, of course, not the ideal way to distribute and install software, so please consider these to be an emergency backup. -->
 +
 
 +
<!--== Volunteer Helpers ==
 +
We have a list of student volunteers who will serve as tutorial helpers. Our helpers are very eager to get their tutorial assignments! Please let us know ASAP if you would like a volunteer assigned to your tutorial -- send email to [mailto:speakers@eclipsecon.org speakers@eclipsecon.org]
 +
<br>
 +
<br>
 +
It's up to you, as the tutorial presenter, to determine what your helper will do. We suggest that you email your helper ASAP to ask about his/her skill set so you can make the best use of your helper, and then let your helper know what you expect in as much detail as possible.
 +
<hr>
 +
<br>-->
 +
 
 +
'''Thanks to Tom Watson, John Arthorne, Eric Cloninger, and Gunnar Wagenknecht from the 2012 Program Committee for the hints and advice below.'''
  
 
== Helpful Hints ==
 
== Helpful Hints ==
Line 7: Line 26:
 
* '''Test your material!''' Ask a couple of people at the same level as your intended audience to try installing the software and doing the exercises.
 
* '''Test your material!''' Ask a couple of people at the same level as your intended audience to try installing the software and doing the exercises.
 
* '''Do a dry run of your exercises on the different platforms''' you expect your attendees to use.
 
* '''Do a dry run of your exercises on the different platforms''' you expect your attendees to use.
* '''Find the right level.''' "Hello world" is too simple, but creating extensive chunks of code is too much. A good example: "Here's a 90%-complete Eclipse application; write the remaining 10% integration code to connect with it."
+
* '''Find the right level.''' "Hello world" is too simple, but creating extensive chunks of code is too much. A good example: Give the attendees a 90% complete Eclipse application, with the 10% missing part being related to the subject of your tutorial. Ask them to only code the parts relevant to your subject and have the rest of the code already in place.
 
* '''Create an agenda''' so you know if you are moving faster or slower than planned; it is very common to not get through all the planned material.
 
* '''Create an agenda''' so you know if you are moving faster or slower than planned; it is very common to not get through all the planned material.
 
* If you are behind schedule, '''be prepared to skip topics'''.
 
* If you are behind schedule, '''be prepared to skip topics'''.
Line 17: Line 36:
 
* '''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.
 
* '''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.
  
== Advice from experienced tutorial presenters ==
+
== Advice from Experienced Tutorial Presenters ==
* ''I created cheat sheets.'' Cheat sheets in Eclipse really helped me out because it presented the attendee with a well-structured set of steps to click through for each topic. I was also able to use Eclipse commands from the cheat sheets to perform mundane tasks for the attendee when they were following the tasks from the cheat sheets, such as creating a new plug-in, etc.
+
* '''I created cheat sheets.''' Cheat sheets in Eclipse really helped me out because it presented the attendee with a well-structured set of steps to click through for each topic. I was also able to use Eclipse commands from the cheat sheets to perform mundane tasks for the attendee when they were following the tasks from the cheat sheets, such as creating a new plug-in, etc.
* ''For each topic, I assumed previous topics may have been skipped and organized the materials accordingly.'' If your topics build upon each other, make sure there is an easy way to "fast forward" up to the next topic. This allows you to skip topics if you're short on time, and helps laggers catch up quickly. Here is a link to my projects in git that includes the cheat sheets and presentation material I used (org.eclipse.equinox.adaptor.cheatsheets): [http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/tree/demos/adaptors/ http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/tree/demos/adaptors/]
+
* '''For each topic, I assumed previous topics may have been skipped and organized the materials accordingly.''' If your topics build upon each other, make sure there is an easy way to "fast forward" up to the next topic. This allows you to skip topics if you're short on time, and helps laggers catch up quickly. Here is a link to my projects in git that includes the cheat sheets and presentation material I used (org.eclipse.equinox.adaptor.cheatsheets): [http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/tree/demos/adaptors/ http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/tree/demos/adaptors/]
* ''I highly recommend preparing different packages in advance'' for Linux, Mac, Windows 64-bit, and Windows 32-bit. It's a lot of effort, but worth it.
+
* '''I highly recommend preparing different packages in advance''' for Linux, Mac, Windows 64-bit, and Windows 32-bit. It's a lot of effort, but worth it.
* ''Here's a link to a plug-in that provides a way for people to skip steps and catch up.'' This was created by Jeff McMeekin and Jean-Michel Lemieux: [http://sourceforge.net/projects/samplings/ http://sourceforge.net/projects/samplings/]
+
* '''Here's a link to a plug-in that provides a way for people to skip steps and catch up:''' [http://sourceforge.net/projects/samplings/ http://sourceforge.net/projects/samplings/] (This was created by Jeff McAffer and Jean-Michel Lemieux for their [http://www.amazon.com/Eclipse-Rich-Client-Platform-Applications/dp/0321334612 RCP book].)

Latest revision as of 20:42, 25 May 2013


Thanks to Tom Watson, John Arthorne, Eric Cloninger, and Gunnar Wagenknecht from the 2012 Program Committee for the hints and advice below.

Helpful Hints

  • Keep the presentation (slide) part very short - 30 minutes or less. Attendees are there to learn by doing, not by watching. If you have lots of good slides, include them in your materials to help expand or clarify -- just don't present them all during the tutorial.
  • Make the setup as simple as possible. Put setup info into your website abstract and email attendees ahead of time to tell them what to have installed before they arrive. To request a list of email addresses of your tutorial registrants, email speakers@eclipsecon.org.
  • Don't try to cover too much. Teach fewer, more focused topics.
  • Test your material! Ask a couple of people at the same level as your intended audience to try installing the software and doing the exercises.
  • Do a dry run of your exercises on the different platforms you expect your attendees to use.
  • Find the right level. "Hello world" is too simple, but creating extensive chunks of code is too much. A good example: Give the attendees a 90% complete Eclipse application, with the 10% missing part being related to the subject of your tutorial. Ask them to only code the parts relevant to your subject and have the rest of the code already in place.
  • Create an agenda so you know if you are moving faster or slower than planned; it is very common to not get through all the planned material.
  • If you are behind schedule, be prepared to skip topics.
  • Have a way for attendees to fast-forward through topics if they get behind. (See the "Advice" section for more on this.)
  • Make sure your material allows attendees to finish exercises on their own -- this will also make your posted material easy for non-attendees to follow.
  • If you type a shortcut when you demo, be sure to explain it. Your attendees may not know the ones you're using.
  • For demos, a simple desktop and user profile works best. Attendees may find your usual background image or desktop distracting.
  • Keep things active in the room, even when the attendees are focusing on their exercises. Ask the audience questions, add a pop quiz, or let the audience vote on what module you do next to keep them engaged. Give out novelty prizes to keep people's attention and add some fun.
  • 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.

Advice from Experienced Tutorial Presenters

  • I created cheat sheets. Cheat sheets in Eclipse really helped me out because it presented the attendee with a well-structured set of steps to click through for each topic. I was also able to use Eclipse commands from the cheat sheets to perform mundane tasks for the attendee when they were following the tasks from the cheat sheets, such as creating a new plug-in, etc.
  • For each topic, I assumed previous topics may have been skipped and organized the materials accordingly. If your topics build upon each other, make sure there is an easy way to "fast forward" up to the next topic. This allows you to skip topics if you're short on time, and helps laggers catch up quickly. Here is a link to my projects in git that includes the cheat sheets and presentation material I used (org.eclipse.equinox.adaptor.cheatsheets): http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/tree/demos/adaptors/
  • I highly recommend preparing different packages in advance for Linux, Mac, Windows 64-bit, and Windows 32-bit. It's a lot of effort, but worth it.
  • Here's a link to a plug-in that provides a way for people to skip steps and catch up: http://sourceforge.net/projects/samplings/ (This was created by Jeff McAffer and Jean-Michel Lemieux for their RCP book.)

Back to the top