And finally, some very detailed feedback and suggestions for VLT’s
and HOW’s from one of my project leads below. Summary: he really likes the
idea of a 2-hour tutorials, he just thinks there should be more than “just
talking” as Rich casually suggested.
Doug
Hi Doug,
I do
not like the idea of a "just talking" VLT.
I
think that from whatever people go to on the "tutorial day",
they should have something
to
take home with them. In other words, even if it's a short (2 hour) tutorial, people
should
be
able to pick up an example project as well as setup instructions, that allows
them to
experiment
with the stuff on their own (in their freetime at EclipseCon, or later at
home).
IMHO
it's not so important to do the actual hands-on exercises right in class,
but to get
help
getting started with setup and an initial project.
I
agree that this hasn't been very effective last year, mostly because speakers
typically
distributed
their examples in last minute. Having an USB stick handed out in class
worked
OK, but it typically took half an hour or so until everybody had the examples
on
their laptops, and even longer until things were really set up. So I think the key
part
in
making tutorials more productive, will be to ask speakers prepare their
material
well
in advance and encourage participants to download examples BEFORE they
enter
the tutorial.
When
this is done, I think that
* A 2-hour tutorial (aka VLT) would be sufficient to get participants set up
with their
example projects, and walk through the examples together. In other
words, people
would not write code on their own, but watch the presenters write or
explain the
examples. They would typically not have time to do their own local
experiments.
In practice, last year several 4-hour tutorials were set up like this
[but too long
for such a sort of "interactive presentation".
A 2-hour tutorial should have one 15-minute break in the middle, in
which people
can either get some refreshment or ask presenters for help setting up
their
workspaces. The ultimate goal of a 2-hour tutorial would be that
people get
some feeling for the technology, and (if they want) get a workspace set
up
themselves.
* A 4-hour tutorial should follow the same basic outline as a 2-hour tutorial
but have
3 15-minute breaks for setup help, asking questions or getting
refreshment. It would
allow to cover more technical aspects and details, optionally allow
participants to
do a little bit of coding their own (this worked truly well in the EMF
workshop last
year).
The goal of a 4-hour tutorial would be that people get a workspace
set up,
and understand the core APIs of some technology.
* In a full day workshop, I think the goal should be that participants not only
get
set up, but get some help specific to their particular needs. In other
words, they
should be able to do some coding their own; they should be able to ask
questions
regarding their needs in their current project. They should be able to
experiment
with examples and try their own side-tracks (assisted by the
presenters). I guess
that whoever goes to a Hands-on Workshop should acutally use what they
have
learned in their daily work later on.
Note that according to this description, a Hands-on Workshop would
actually make
sense for plain beginners or users too (not only add-in providers),
explaining JDT or
PDE features from a user's perspective ... perhaps a hands-on workshop /
beginners
class for plugin writers would really be well received.
The goal of a HOW would be that people get everything they need to
use the
technology themselves in their own projects.
The
main background of these thoughts is that the core value of a tutorial is to
get
started
with something. After this initial hurdle is taken, it's always much easier to
explore
the help system etc.
The
difference between a tutorial and a long talk would still be that the tutorial
digs
into
the technology and allows people to actually use it, while the talk would be
more
of a presentation. Therefore, I'd still call the 2-hour thing tutorial rather
than
VLT.
HTH,
Cheers,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
