Sydney Linux Users Group (SLUG)

This guide is © Mary Gardiner 2003-2004. This guide is available for redistribution and modification under the terms of the Creative Commons Attribution Licence

 

Introduction

This document is a short guide to preparing and presenting a talk at the Sydney Linux Users Group, and should be useful for other groups too. It is intended for speakers who are comfortable with their topic area but do not have much public speaking experience.

This guide covers the type of talks given at SLUG; preparing your SLUG talk; and giving your SLUG talk.

The type of talks given at SLUG

There are three types of talks given at SLUG meetings: general talks, special interest talks, and SLUGlets.

General talks

Length: 30 minutes (plus question time). In some months the organisers might combine two 15 minute general talks.

General talks cover a topic of interest to most of the SLUG audience. General talks need to be interesting to the majority of SLUG attendees, which means that your talk must not assume a large amount of familiarity with Linux and Free Software, but must still be interesting to people who do have this familiarity. Examples of good general talks include: overviews of new or little known Free Software user applications; overviews of significant revisions of major applications (such as user level overviews of new major kernel releases); and talks about the Free Software community — for example a talk about contributing to Free Software.

The aim of a general talk should be to give the audience members something new to try at home.

Special interest talks

Length: 30 minutes (plus question time). In some months the organisers might combine two 15 minute special interest talks.

Special interest cover a topic of interest to a subset of SLUG attendees. Special interest talks run in parallel with SLUGlets, so you can tailor a special interest talk to a specific audience. Talks with reasonable amounts of assumed knowledge, including talks aimed primarily at programmers or systems administrators, are suitable special interest talks, as are talks about specific uses of Free Software such as running a Free Software project or running a business that uses Free Software that might not be of interest to all attendees.

SLUGlets

Length: 10 minutes to 45 minutes. However speakers must not prepare 45 minutes of material — instead, they should prepare material for a tutorial and discussion. This will mean that the speaker will probably only talk for one quarter of their allocated time.

SLUGlet sessions run in parallel with the special interest talk. SLUGlets sessions have a tutorial format, and talks given at SLUGlets sessions should be shorter and allow for — and encourage — a great deal of interactivity. Ideally, SLUGlets speakers run a discussion, rather than give a talk. SLUGlets should be introductory level, accessible to newcomers to Linux.

Preparing your talk

What do you want to say?

In short: say what the audience wants to hear. The SLUG membership comprises mainly Linux hobbyists and some Linux professionals. Most attendees have a few years experience with Linux, but some don't.

If you're giving a general talk, you will need to pitch your talk at all of these people, so you will need to have something to say to both people new to Linux and to people who have been using Linux for a while. If you don't think your talk appeals to both groups, consider giving another talk type instead. Loosely, the aim of a general talk should be to get audience members thinking "hey, that's cool" and hopefully give them something to try at home.

If you're giving a special interest talk, you can afford to assume the audience is already interested in your general topic area, but you can't assume that they necessarily know much about it. Hence, special interest talks have tended to converge on walking people through a particular framework — whether it is features of a programming language, or architecture of a Free Software app. Picking the audience of a special interest talk might be tricky — be prepared to work through introductory material faster than you intended, or to spend your entire talk giving what you had intended to be introductory material.

If you're giving a SLUGlets talk, your material will need to be introductory level. You should definitely attend at least one SLUGlets session before attempting to run a SLUGlet tutorial.

The best way to gauge the audience would be to attend a few SLUG meetings, ideally talks in the same area as yours. Listen to the audience: were the questions above or below the level of knowledge assumed for the talk? Which parts of the talk were the questions about? Aim your own talk at the level of these questions.

In any case, presumably you are giving a talk about something that enthuses you, so you need to consider how to enthuse the audience. Your own enthusiasm helps here.

SLUG members are generally interested in practical demonstrations and concrete facts. Technical people are leery of unsupported claims, so support claims you make.

Sticking to the time limit

People whose last experience of public speaking was when they were a child are often surprised when their talk runs over-time. It is extremely common for this to happen: over-time talks are much more common than under-time talks. SLUG welcomes speakers who are relatively inexperienced at giving extended talks. However, this means that some of our speakers don't know just how short 30 minutes is.

30 minutes is not a long time to talk about something. 10 minutes is far shorter. It sounds like a long time to people who haven't done formal public speaking since school, but it isn't.

Here is a rough guide to what you can cover in 5 minutes, in 10 minutes, and in 30 minutes.

If you speak using slides, 5 minutes is about 5 slides, including an introduction slide. A good demo, demonstrating one simple thing fairly solidly, lasts about 5 minutes once you allow for opening the window, starting the program, finding where you are on the screen, demonstrating, explaining, and finishing off. So if you're giving a 5 minute talk, you have room for exactly 1 good demo without slides. If you're not giving a demonstration, you can cover a couple of points fairly shallowly.

10 minutes is about 7 slides (the slides to minutes ratio falls for longer talks). You probably still only have time for 1 demo, but you can probably afford 1 point and a demo; or 2 or 3 points with about 2 slides each. If everything you say is to be covered by demos, you would have time for 2 demos.

A 30 minute talk is about 15 or 20 slides. Experienced speakers will tend to require less slides. A good 30 minute talk might consist of 3 or 4 major points, with 2 or 3 sub-points (1 sub-point per slide) each.

If your entire 30 minute talk is a series of demonstrations, you can probably do 4 or 5 demonstrations. For each major point you intend to cover by talking, subtract 1 demonstration.

Be sparing with your slides. The more slides you have, the more likely it is you will go over-time.

There is not too much chance you will run under-time. It is extremely rare for that to happen at meetings like SLUG's. Your main concern should be finishing in the time available. If you are worried that you have too much or two little, test-run your talk in front of an audience and time it. You will talk about 10% faster than your fastest rehearsal.

If you do run over-time during your talk, a meeting organiser will probably try and hurry you up, and you may have to cut your talk short, since it's important that the meetings run to time. There's nothing really wrong with this happening, but you'll feel more comfortable if you've got your material roughly matched to your time constraints.

You might want to make the last third or so of your material "optional extras" like demonstrations, or in depth explanations of some things skimmed over earlier in the talk. If you have done this, you can drop the last third if you are running out of time without leaving out the meat of the talk.

Making good slides

As is pointed out later, your audience can read your slides and listen to your talk at the same time. Don't put your entire talk on your slides or the audience will get bored listening to you say what they have already read from your slides.

Don't prepare the structure of your talk by doing your slides, or your slides will read like speaker's notes. Prepare an outline of your talk separately, and prepare your slides using that outline. The titles of your slides should follow the outline: major points get their own section of the slides, minor points become the title of an individual slide.

Make sure your text and slide background strongly contrast: light text on a very dark background or dark text on a very light background. Make sure your font is fairly large (something like 28 point seems to work OK but this will vary based on your slide software).

Any individual slide should contain either text or a figure of some kind.

Slides are excellent for presenting any data that is better presented visually than explained verbally. There are plenty of examples of information that should be presented visually: diagrams of the subparts of a project; graphs showing the general trend from a bunch of figures; and tables comparing features in different projects. If you have this kind of data to present, show it in a slide rather than trying to explain it, or worse still, reading out lists of numbers.

Some kinds of text are also better read by the audience than read out loud. A good example is code listings: code listings are both boring and hard to follow when read out loud, whereas short code segments are easy for programmers to understand if read from your slides. Other examples of text that should go in your slides and not be read out include sample configuration files and sample commands.

Stick to 1 diagram or example per slide. Examples should be as trivial as you can make them while still showing whatever you want them to show. In particular, keep code listings to 15 lines at the absolute most.

Most speakers also use their slides to give short summaries that basically follow the structure of the talk. This is also useful, as it helps orient audience members and allows them to tune in to interesting parts of the talk. It also supplements the talk: the information on the slides might help them follow an otherwise difficult part of the talk by emphasising the important details or facts. These slides are normally bullet-point style.

On text slides of this type, stick to 4 or 5 bullet-points. Each bullet point should be at most a very short sentence. You can use the bullet-points to give a summary of your talk, but make sure your talk is bigger than the slides: it should substantially elaborate on the slides. Don't put all the meat in the slides, just the basic points. Another approach is to use the bullet-points as the basis for a discussion in your talk. For example, use the bullet-points to list facts or statistics that you want to discuss and compare.

Have a concluding slide that contains important reference materials and any contact details you want to share (speakers normally give an email address). Leave this slide up at the end of the talk so that people can copy information from it. It should definitely include the homepage(s) of the project(s) you were discussing, if any.

Resources

• Akkana Peck's Using Linux for Presentations Mini-HOWTO, which describes Linux slide tools.

Giving your talk

Speaking

The three most important things to do physically are to speak slowly, speak loudly, and to look at the audience.

If you can remember, smile at the audience. Smiling is a positive feedback loop: they'll smile back, which will make you smile more and feel happy and confident. They'll react well to you being happy and confident.

If you're nervous about speaking, make your introduction especially long. This gives you lots of time to settle in, and since it's introductory material, if you're a bit soft or fast at the beginning, the audience won't miss the meat of your talk.

Every once in a while, probably major breaks in your talk, consciously take a few breathes, slow down, and speak up. Pauses between major points are a good idea anyway, they bring the audience back on board.

Using slides

The most important tip I can give you about using slides is that your audience can read them too. Most of the audience members can read them much faster than you can read them out loud, in fact. The audience does not want you to read your slides to them, because by the time you've done that, they've had the chance to read them three times.

There are some important exceptions to this, particularly vision impaired people, but in general you should think of your slides and your words as separate yet complimentary sets of information. You're being given the opportunity to present information two different ways: visually and audibly. Use them to present information in different ways.

Keeping all this in mind, you should also try and make your talk understandable without your slides. It will flow better, and it will be accessible to people who can't read the slides. It will not be practical, as pointed out earlier, to do things like read out code listings, but you should explain what they do and what concepts they illustrate. For charts, explain briefly the general trend that is visible in them. Don't expect leave crucial pieces of information entirely for the slides to explain.

Your slides are an excellent way of conveying information like the outline of a talk, a set of definitions, or the major points. You may want to supplement this information by paraphrasing it, which will give the audience an alternative way of thinking about what you're saying, and will also help vision-impaired audience members. Paraphrasing is good, further explanation is good, but reading your slides out loud is a waste of people's mental bandwidth.

Giving demos

It is extra important to rehearse demonstrations. Don't ever give a demonstration that you haven't rehearsed.

During your rehearsals ask yourself "how much of the set up can I do before the talk?" Make a list of what windows you need open, what programs you need running, and see if you can start them before the talk. If you can't, at least you'll know which steps to carry out.

If you need to set up any hardware, for example speakers, arrange with the meeting organisers to do this at the start of the meeting.

A very important thing to keep in mind for demonstrations is that you will need to make fonts very large if anyone is to read anything you are demonstrating. If anything needs to be read, make sure the font in the appropriate application (e.g. your terminal or your browser) is around 24 points. Make it this large in your rehearsal so that you know that all the text will fit on the screen. Also, as with slides, make sure there is a high contrast between background and foreground colours.

Dealing with the audience

If you are enthused about the topic, you will enthuse the audience. In general, provided you approach the topic in a way that will interest SLUG members you won't encounter hostility in the audience. Make sure you're prepared for polite criticism of your subject matter (not of you!) though.

The most common problem is the audience member who uses the opportunity to ask a question as a soap box, followed by the audience member who feels compelled to answer your questions or give your speech for you.

Before your talk, tell the meeting organiser or MC whether or not you will take questions during your talk. If you don't want them, the MC will ask people not to interrupt. Even if you do want them, the MC will probably interrupt long discussions to let you keep talking (once two audience members begin talking to each other rather than to the speaker, they certainly should be interrupted or the talk will derail).

Even if you do want questions, if someone asks a question that has a long answer tell them that you'll discuss it during question time or in person. If someone asks something that's answered later in the talk, tell them that.

Democracy during question time does not work, but fairness does. If someone is getting carried away with a barrage of questions, disputes or answers, call on someone else and mentally put them at the end of your question queue.

SLUGlets do not have separate question times, and SLUGlet talks are audience directed, so much of this advice does not apply. For a SLUGlet, make sure that the discussion is not dominated by the loudest audience members, but you may let the audience carry the discussion as much as they and you are comfortable with.

Acknowledgements

Thanks to Andrew Bennetts for proof-reading this guide and for the tip about adding an optional bit to the end of your talk to drop if necessary. Thanks to Robert Dale, who taught Macquarie University's useful COMP495: Academic Presentation and Writing Skills course in 2003, and who patiently sat through a bunch of my rehearsals later that year. Much of the material in this guide about timing and rehearsals draws on that course. In particular, that's where the tip about presentations being speedier than rehearsals by 10% comes from. Thanks to Toss Gascoigne and Jenni Metcalfe from Econnect Communication who gave a speaking workshop to myself and other vacation students at CMIS in February 2002. That workshop taught me a great deal about audience-oriented (as opposed to speaker-oriented) talks.