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"

(Helpful Hints)
(Helpful Hints)
Line 2: Line 2:
  
 
== Helpful Hints ==
 
== 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.
+
* '''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 [mailto:speakers@eclipsecon.org speakers@eclipsecon.org].
+
* '''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 [mailto:speakers@eclipsecon.org speakers@eclipsecon.org].
* Don't try to cover too much. Teach fewer, more focused topics.
+
* '''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.
+
* '''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: "Here's a 90%-complete Eclipse application; write the remaining 10% integration code to connect with it."
* 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'''.
* Have a way for attendees to fast-forward through topics if they get behind. (See the "Advice" section for more on this.)
+
* '''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.
+
* '''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.
+
* '''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.
+
* 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.
+
* '''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.
+
* '''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 ==

Revision as of 23:48, 31 January 2012

Thanks to Tom Watson, John Arthorne, Eric Cloninger, and Gunnar Wagenknecht.

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: "Here's a 90%-complete Eclipse application; write the remaining 10% integration code to connect with it."
  • 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/
  • Slow WiFi is always a surprise, especially when your setup plan includes installing things into Eclipse. I highly recommend preparing packages for Linux, Mac, Windows 64-bit, and Windows 32-bit in advance. 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 used by an EclipseCon presenter, who credits Jeff McMeekin and Jean-Michel Lemieux for creating it: http://sourceforge.net/projects/samplings/

Back to the top