Skip to main content
Jump to: navigation, search

EclipseCon Tutorial Guidelines

Revision as of 16:07, 3 February 2012 by (Talk | contribs) (EclipseCon 2012)

EclipseCon 2012

Factoids about the 2012 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 want a good return on that investment. In our post-conference surveys, attendees have consistently given tutorials lower marks than other types of talks. We want to change that!
  • To help raise the quality of tutorials, we are implementing a presenter checklist and mentorship program.
  • We are recruiting [ 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
  • 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.
  • We are happy to provide you with a list of email addresses for your tutorial registrants. Email to request the list. 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 two USB memory sticks for each tutorial. If you will find these useful, please ask for them when you register at the conference. If you would like more than two sticks, please send email to to request more by March 1. USB sticks are, of course, not the idea way to distribute and install software, so please consider these to be an emergency backup.

Checklist for Tutorial Presenters

Members of the program committee (PC) will work with tutorial presenters to make sure they complete the items in this checklist on time. Committee members will also serve as individual mentors for presenters who ask for mentorship.

  1. February 20: Presenters submit materials to PC
  2. February 27: PC sends feedback to presenters
  3. March 5: Presenters submit revised materials to PC
  4. March 10: PC sends final feedback to presenters
  5. March 12: Presenters posts final materials posted on website
  6. March 15: Presenters email tutorial attendee lists to give setup info, etc.

Volunteer Helpers

We have a list of student volunteers who will serve as tutorial helpers. If you would like to have a helper, please email by February 20. Our helpers are very eager to get their tutorial assignments!

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.

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
  • 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):
  • 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 McAffer and Jean-Michel Lemieux for their RCP book.)

Back to the top