I am not going to blog forever about conferences in computer science and software engineering, but there is still room for a few mundane, down-to-earth, modest, concrete, pragmatic (further adjectives available upon request) suggestions which, if followed consistently, could make everyone’s conference experience better. To confirm this view: the intent of this post is not to criticize, but to help.
The most obvious has to do with slides. For many years, I have given self-applicative technical lectures to students: talks about how to give a talk. (The justification for my claim of expertise in this field is not necessarily that I am a good technical speaker—that is not for me to judge—but the incredible, actually world-class, experience that I have had attending bad talks by others. Probably in the thousands by now.) My lectures always include one on slide design, and I mention in particular that font size should be big enough: typically something like 24 pt by default, going down to 18 if necessary, occasionally 16 for program text, but never below.
(Note for completeness: there is one exception to this minimum-size rule: sometimes you have covered a topic and in a later slide you want to give the listener a discrete reminder of that discussion. Then you can include a small screenshot of the earlier content as a subtle prompt triggering a quick memory recall. That case is special and all others should obey the rule that every attendee should be able to read everything on every slide.)
The general quality of slides has improved over the year, and I had come to think that the preceding advice was no longer necessary. But then came the Zoom revolution, amplified by Covid, and people started using slides as meeting support (rather than public presentation), which tolerates, to a point, small font sizes. As a result, some of them have reverted to using Lilliputian text in conferences! Here is a slide from a presentation at the recent International Conference on Software Engineering:
What could the presenter possibly have been thinking? Here is another one– mind you, from a keynote speech:
The talk was given in a big room, with two very large screens (the one pictured here and another identical); I was sitting pretty close; and still all that I could read was the title, plus the entries in the table. What puzzles me is what goes on in the mind of a speaker preparing such a talk, especially a prestigious invited one which, presumably, deserves some careful design and preparation.
(By the way, if while delivering your talk you see me in the room taking a few pictures, it may be that I am so entranced by the content that I want to capture it even before you make the slides and the paper available; or it may be that I am enriching my collection of examples for the next edition of my technical-talks lecture.)
Slide design is only one component of talk quality. The most important parameter is psychological: authors should devote the same attention and enthusiasm to the presentation that they applied to the article. It takes enormous effort to have a paper accepted at a top CS conference; it is a pity to waste some of it because of a mediocre verbal presentation that will lessen the paper’s potential impact. Again and again you see speakers reading a prepared text in a monotonous tone. Come on, you can do better. Show some excitement. Vary your voice. Construct your talk as a talk, not as a readout of slides extracted from the paper. Think of the listeners, what will make them pay attention (rather than go back to their laptop and read Facebook). Decide what you would like them to remember from your presentation. Build on your own experience when you are in the audience: what distinguishes the talks that you will forget the minute they are done from those that will make a durable impression on you?
Reflect on the structure of the talk: instead of a logical but boring progression (problem, obstacles, example, your solution, example application, lessons), consider others that might give you a better chance at grabbing the listeners’ attention and keeping it; for example, spilling most of the beans at the start (giving the key idea in the first three minutes), then developing, then keeping a surprise at the end. You can find lots of good advice in books and on the Web.
Also, get the best speaker in the team to present. A really irritating cliché, a truly terrible idea masquerading as do-gooder attitude on the part of senior faculty members, is “I let the Ph.D. students present, it’s good training for them.” No! The purpose of a presentation at a top-level international conference is not to submit a beginning Ph.D. student to a baptism of fire. There are other venues for that, back home. The purpose of a presentation in such a venue is to showcase your research in the best possible way, and to help in the advancement of science and technology. This goal requires summoning your best resources. If Richard Feynman is in the audience, I want to hear the presentation from the mouth of Richard Feynman, not from a terror-struck beginner from his group.
Regardless of who gives it, I also want to hear a good presentation. When I am subjected to a mumbled, incomprehensible soliloquy from a Ph.D. student looking at the screen the whole time, I am not upset at him, but at his supervisor. It is unconscionable to let a team member, junior or seasoned, give a high-profile talk without having rehearsed it within the team, at least once and as many times as it takes until the team is happy with it. This rule is one of basic professionalism and I am flabbergasted to see how many teams do not apply it.
Overall, it’s not so hard. The truly difficult part is the research and the writing of the article. Compared to that effort, preparing and delivering a good presentation is a feasible but necessary task. If we as a community devote to presentations the basic care they deserve, much of the frustration that sometimes mars conferences will dissipate, and conferences will better play their role in uniting the community and advancing the discipline.
Bertrand Meyer is a professor and Provost at the Constructor Institute (Schaffhausen, Switzerland) and chief technology officer of Eiffel Software (Goleta, CA).