A SHORT GUIDE TO PRESENTATIONS
		    ==============================

Overall structure
-----------------

When you prepare your presentation, you need a clear idea of the
important points that you wish to present to the audience. These
points will then make your outline slide.

Typically you need to present the background for your idea and the
motivation for your work, as an introduction. At times it makes sense
to have 1-2 slides of motivation *before* your outline slide: this may
help you attract attention and make the ouline slide more meaningful.

After the introduction and motivation, you describe the problem you
solved. Your main effort here is typically on two sides: (1) show how
the problem you solve is perhaps a small but fundamental part in a
larger scientific challenge and (2) give hints on why the project is
not easy. The second point should focus on intellectual challenges
rather than logistical issues or difficulties related to your previous
background. A good way of showing the difficulty of your problem is,
in many cases, to show that simple solutions (those which might come
to the mind of the audience as you explain the problem) cannot work.

As part of the introductory material (or wherever it makes sense),
remember to define formally everything which is crucial to your
discussion. Don't give any important definition for granted. You have
been working a long time on the subject: many words may seem
self-explaining to you and several concepts trivial--they might not be
to your audience. If in doubt about the level of the audience, enquire
people who might know--try not to guess.

The main share of the presentation should say how you solved your
problem and possibly give qualitative indications of the value of the
solution (e.g., is the solution exact?) Then you show your results
and discuss how they relate to the original goal (is the problem
solved? are the results satisfactory?  you should always find
something positive about your results but you should be honest in
showing the limitations of your work). You should conclude saying what
will be your future work (for intermediate presentations) or what
could be done by future students or researchers to improve your
results or to exploit your solution at best.

During the whole presentation, be very clear about what was done
previously, what is exactly your contribution, and what is left for
you or others to do.


How to maximise understanding
-----------------------------

Do not assume that you audience knows the background of your work as
well as you do--or at all. We all work in very specific fields, and if
someone in the audience has deep knowledge about compilers, he/she
might know way less about printed circuit board design, for example.
You should assume the general knowledge of a coumputer scientist or
electrical engineer, not more. This should be enough to understand
well your problem--maybe not to appreciate all details of your
solution, though.

Helping people to understand the motivation and the problem is
absolutely essential: if anyone misses in the first 2-3 minutes the
problem you're try to solve, most likely he/she won't listen to the
rest of your presentation--you've lost your public and this is about
the worst you can achieve in a presentation.

You must not give an introductory lecture, though, but you should give
explanations about basic things: it takes a few seconds and it is of
great help. At times it simply takes practically no time at all to
clarify technical words--even if you think everybody should be
familiar with them: you can just casually drop a couple of synonimes
or descriptive expressions. Again, this calls for some reharsals to
make sure you think beforehand of all such situations: your
descriptions should *look* casual but must in fact be perfectly
planned in advance.

An example: Don't say "There has been considerable progress in the
last years in retargetable compilers, and our goal here is...".
Instead say "There has been considerable progress in the last years in
retargetable compilers--that is, in creating effective compilers to
generate code for any machine provided that a description is made
available to the compiler; in this framework, our goal here is...".
It does not take 3 seconds, and if all know it in the audience, they
won't most certainly be "offended" by the precision. Those who don't
know, will be able to continue following you.

Try to mark well the steps you go through in the presentations: "Now
that I introduced informally the problem with a simple example, I will
formalise it so that we can understand its complexity and then work
out a solution... ".  Tell the audience at all critical points what
you have just done and what you are going to tackle next; mark moments
when you are turning a page. This can also be done visually, by
repeating the outline slide, for example. Don't fear to be repetitive:
it's hard to make too much of this and turning points are excellens
chances to recapture attention.

Do as many examples as you can! Many (probably most) people understand
much faster abstract concepts by generalisation from a specific
example. It is often a good way to introduce your problem with a small
example, and then you can immediately generalise it and present it in
a more formal and rigourous way: people will be helped in the process
by having in mind the example. Similarly, when you introduce
algorithms you can show how they work on simple examples. Try never to
leave important parts of your talk purely in abstract terms without
showing the relevance or meaning of what you say on a specific
instance. In some cases, it is a good idea to work out a nontrivial
but simple example which you carry on from the beginning to the end of
the talk, for all purposes you need an example--people will grow
familiar with the example and will be quick to grasp the additional
concept or step you introduce. Note that preparing good examples is a
difficult and time-consuming task.


Behaviour while you talk
------------------------

In order to make a good presentation, it is essential that you try it
*many* times aloud to an imaginary audience. Not even very
experimented speakers can improvise well and master a good timing
without preparation and reharsals. Don't just go over the presentation
in your mind: find a quiet place to reharse and explain things exactly
as you would do in front of some people: speak aloud, use a firm
voice, articulate well words.

You must look at the people listening to you--and not just to a couple
of people sitting in the first row or to "important" people in the
audience. You should try to use your look to captivate everyone in the
audience. In particular, be careful not to turn your back to the
audience--typically to look at your slides. You can see your slides in
the monitor of the computer, and this will help you face your
audience. You must know perfectly your slides and in a fraction of
second you should be able to remember what is on each slide and what
you what to say about it. If you can't, reharse again.

You must absolutely avoid, except possibly in rare special cases, to
read the text from the slide. You need to have a clear plot in your
mind and you can let people read details on the slides by their
own. Again: in order to have a strong plot and not feel the need of
reading the slides, you must try the presentation aloud multiple
times. It is essential for a good presentation that you know *exactly*
for each slide the concepts you are going to discuss and those that
you are going to skip. Yet, it is usually much better to avoid
memorising a precise text: learning by heart a text makes
presentations duller and is prone to blanks because you then look
desperatly for that specific word you can't recall.

Use pointers (laser or other) to show successively on each or most
slides what you are referring to while you speak. While you practice,
use the same type of pointer you'll be using for the final
presentation, if possible. Definitely, decide beforehand what you're
going to point and when--do not improvise. Keep your pointer steady to
the object you want to draw attention to, avoid beaming everywhere on
the slide or moving the pointer around too fast: your pointing should
clarify your words, not confuse the audience.

Pay attention to how long your presentation is. Taking more time than
you were allowed is a very good way of indisposing the audience. In
many cases, you simply won't be allowed any additional time. Missing
the correct timing will clearly show that you did not practice--at
least not enough!


Slides appearance
-----------------

Never use characters too small to read from a distance; don't
overcrowd slides. Usually, the audience must be able to read the whole
text while you discuss the slide. There should be only a few words,
which will help the audience follow your speech. Text is not there for
you to remember what to say: you should know that anyway!--although of
course slides will help you follow the plan you have in mind.

Use figures! Get in the habit of trying to represent graphically your
thoughts: (1) they are very often more easily grasped in graphical
form and (2) well constructed figures may convey informations that
would take many sentences to describe.

Use figures also to vary the presentation. You'll lose your audience
very soon if your slides are all identical in layout, with 3-4 bullets
on every slide and a 10-15 words sentence per bullet--invariably. You
need to find the balance, not all pictures and not all words. Use
small quantities of text around figures and graphs to indicate what
people should get from the figure. Never let people guess.

If you anticipate comments or questions on specific topics, but cannot
or wish not to discuss the related issues in the presentation (e.g.,
because of limited time or low relevance), prepare a few backup slides
that you are not normally showing but which you can always use if the
anticipated reaction teakes place.


For more information
--------------------

Tufte, The Cognitive Style of Powerpoint, Graphic Press, 2003.

Tufte, The Visual Display of Quantitative Information, Graphic Press,
   2001.

Shaw et al., Strategic Stories: How 3M Is Rewriting Business Planning,
   HBR, May-June 1989.


-- $Id: presenting.txt,v 1.2 2004/02/22 23:23:34 ienne Exp $