How to write a timeline for a !!Con talk proposal

Every spring, I help review talk proposals for !!Con, a conference of ten-minute talks about the joy, excitement and surprise of computing. Because distilling a topic into ten minutes is hard, we ask prospective speakers to provide a timeline as part of their talk proposal, explaining how they plan to use their ten minutes of stage time. The timeline helps us make sure that the speaker understands the talk format, and that they’ve put some thought into what they’ll cover in their talk and how they’re going to fit the material into the allotted time.

We get a lot of talk proposals, so in order for a proposal to be competitive for acceptance, it needs to have a decent timeline, and a really good timeline can push a borderline proposal into the “accept” category. Conversely, a bad timeline can kill an otherwise promising talk proposal. So, this post is advice for people submitting talk proposals to !!Con (or, potentially, other conferences that also ask for timelines) about how to write a timeline that will make your talk proposal the best it can be.

What not to do

A good way to get your talk proposal rejected at !!Con is to fill in the timeline field on our talk proposal form with something that isn’t really a timeline at all. Although there’s a separate form field for an abstract (that is, the description of a talk that will appear publicly on our speakers page and is intended to advertise the talk), we always seem to get some talk proposals where the so-called timeline is just another abstract. In fact, we’ve even gotten talk proposals where the timeline is just a copy-pasted part of the abstract!

Here’s an example of a so-called timeline that really isn’t:

In this talk, we’ll cover X, Y, and finally Z. Along the way, we’ll gain some insights about Q and even touch on R. Aficionados of S and T will appreciate this talk.

This kind of “timeline” might explain what the talk is about and how it will flow, but it doesn’t offer any information on how the speaker will allocate the available time for various parts of the talk. Moreover, submitting a timeline that looks like this indicates that the talk proposal author has misunderstood what the timeline component of a talk proposal is for. Unlike an abstract, a timeline should not be written for eventual publication on our website as a way to attract people to the talk. Instead, it’s intended just for the people who are reviewing talk proposals to read, and calls for a different kind of voice than an abstract.

Then there are so-called timelines that look more or less like this:

• Introduction (1 min)
• Main content of talk (8 min)
• Conclusion (1 min)

That looks ridiculous, but believe it or not, we’ve actually received submissions with timelines that have even less detail than that!

Finally, here’s a timeline (heavily edited from one that was part of a real submission) that’s not terrible, but still not great:

I’ll introduce Z and talk about how it’s used. Then I’ll dig into the internals of Z. This will take a few minutes to explain, because the frobnicator is complicated. I’ll use either A or B as a toy example to illustrate the ideas (I haven’t decided which yet). At the end I’ll take about 90 seconds to show a real-world example, most likely either C or D.

This timeline is pretty short and skimpy on details, and it makes it sound like the speaker hasn’t entirely thought through what they’re going to cover; it doesn’t leave the reviewers feeling confident that the speaker will use the time well. A borderline talk proposal would most likely be rejected if the timeline looked like this — which is a shame, because there could well be a great talk hiding behind this lackluster timeline. An amazing abstract could be enough to save such a talk proposal from rejection, but instead of putting yourself on the hook to write an amazing abstract, why not write a better timeline?

What to do: some examples of good timelines

Okay, so what does a better timeline look like? There isn’t one right way to write a timeline, so instead of trying to give universally applicable advice, I’ll share a few examples of good timelines that were submitted along with accepted talk proposals this year. All of these are shared with the speaker’s permission.

Here’s the timeline that Tara Vancil submitted as part of her proposal for the talk “How Merkle trees enable the decentralized Web!”:

• 2 min: Intro to network topology
  • How are decentralized networks different than centralized networks?
  • Where must trust exist in each model?
  • What are trust and performance requirements of a peer-to-peer/decentralized system?
• 5 min: What is a Merkle tree?
  • What is a Merkle tree and what makes it unique?
  • Content validation properties (explain very briefly what a hash function does, and how Merkle trees use them to verify logs)
  • Explain performance properties
• 3 min: Examples
  • Recap how Merkle tree is uniquely suited to needs of peer-to-peer systems that need to share state
  • Merkle trees in Git
  • Flattened Merkle trees in the Dat protocol

This timeline isn’t especially long, but it offers enough detail to give us a sense that the speaker is comfortable with the topic and has a plan for how to proceed. It’s written with the talk proposal reviewers in mind, not with a general audience in mind, so it sticks to the facts, rather than trying to sound catchy and sell the talk — that’s what an abstract is for, not a timeline.

Here’s another good timeline, submitted by Geoffrey Litt as part of his proposal for “ENHANCE! Upscaling Images with Neural Networks”:

• (1min) Introduction
  • We can now “enhance” photos!!
  • Show examples from CSI and from a 2016 research paper
• (2min) A very brief neural networks crash course
  • A taxonomy of neural networks: Treating a single neural network as a black box, what are the different types of inputs and outputs that are possible?
  • Training a neural network: How does a neural network learn?
• (2min) GANs: inspired by art forgery
  • Human art forgers are in a constant battle with the police. As the detection techniques get better, so do the forgers.
  • By creating multiple neural networks (a “forger” and a “detector”) and pitting them against each other, we end up with a really good forger!
• (2min) Training a GAN
  • Explain how the GAN training process works using visuals
  • Show examples of the output getting better as the network trains
• (3min) Cool applications of GANs
  • converting text to images!
  • converting line drawings to photographs!
  • converting images to 3D models!

Like Tara’s timeline, Geoffrey’s is detailed enough to make clear that he’s comfortable with his topic of choice and has thought about how to use the time effectively, and it sticks to the facts (while still conveying his excitement about the topic). This example also shows that the actual talk need not conform precisely to what’s proposed in the timeline: in his actual talk, Geoffrey uses counterfeiting money, not art forgery, as a metaphor for understanding GANs. We expect that most speakers will rearrange things a little, or even a lot, between when the talk proposal is due and when the talk finally happens. The important thing at talk proposal submission time is not for the speaker to have every detail finalized; it’s for them to aware of the time constraints and to have come up with a plausible-sounding plan for a talk they could give.

Although most timelines are in bulleted-list format, it’s also fine to write paragraphs with complete sentences. Here’s a good example of a timeline in that format, submitted by Jan Mitsuko Cash as part of her proposal for “What alien invaders, birds, and computer simulations have in common: flocking!!”:

I’ll start with a quick introduction of what flocking and emergent behaviors are. Flocking happens when individuals form a group. Usually those individuals will be acting independently without any coordination, but by interacting with each other, complex group behaviors begin to emerge. When small actions result in larger behaviors, this is known as emergent behavior. (1-2 minutes)

After that, I’ll go over a simple simulation in NetLogo, which is an agent-based programming language with turtles. This will be the majority of the talk. The turtles will follow three rules:

• They will try to face a similar direction as their neighbors
• They will try to stay close to their neighbors
• They won’t get too close to their neighbors (don’t crash!)

When the turtles do this and are constantly stepping forward as the adjust the direction they are facing, the whole group will start traveling together around the screen. (5-6 minutes)

NetLogo has some controls to change variables during a simulation, so I’ll change the levels to which turtles will obey each rule and show how the flocking behavior disappears when turtles aren’t following the rules. (1-2 minutes)

If there’s still more time, I’ll also go over some optional material of how groups interact with outside elements. For example, what happens when a predator moves through the screen and turtles have a new rule to avoid it? What happens when flocks are looking for resources (like food)? (any remaining time, up to ~3 minutes)

Jan’s timeline, like Tara’s and Geoffrey’s, demonstrates that she’s knowledgeable about the material she’s planning to present and has put thought into how to present it effectively. She gives herself some wiggle room by putting a (brief) range of time for each section of the talk, with an optional section at the end to pick up any remaining time.

As a final example of a good prose-heavy timeline, here’s one submitted by Mark Dominus for his talk “I got the computer to find words with good anagrams and throw away the boring ones!!”:

I’ll spend a minute or two explaining the problem I wanted to solve, of finding words that are anagrams of other words. It’s very easy to do this, but unfortunately most of the examples are boring. For instance, “hackles” and “shackle”, or “hungover” and “overhung”. I will explain what is wrong with these examples and the method I thought of to rule them out.

Then I’ll briefly discuss the brute-force algorithm I implemented in 1992. This is simple so it’ll only take a minute.

I’ll spend a few minutes explaining the better algorithm, which is fun: the anagram problem can be transformed into a problem about finding a maximal independent set in a certain graph. Explaining maximal independent sets will take much less time than it might sound.

I’ll reveal the results of the new algorithm. Then I’ll reveal what happened when I dug up the old code and ran it on new hardware.

Then I will philosophize for a minute or two about what we can learn from all this.

I will also reveal the top-scoring anagrams.

Mark’s timeline demonstrates yet another way of showing the reviewers that the speaker is comfortable with the material and has put thought into how to present it. Unlike Tara, Geoffrey, or Jan, he doesn’t specify lengths for every part of the talk, and for the parts for which he does give a length, he doesn’t get any more specific than “a minute or two” or “a few minutes”. Still, reading this timeline, one can see how the talk can plausibly add up to ten minutes, which is what the proposal reviewers are looking for. Furthermore, “Explaining maximal independent sets will take much less time than it might sound” is a helpful hint to reviewers who otherwise might be wary that that part of the talk would take too long or go off into the weeds.

How short is too short? How long is too long?

Tara’s, Geoffrey’s, Jan’s, and Mark’s timelines all weigh in at between 100 and 250 words long, and that’s a good range to aim for. I’ve seen acceptable timelines that are as short as 60 or 70 words, although that’s kind of pushing it — a timeline with that little detail would need to have no wasted words, and would most likely need to be accompanied by a very compelling abstract in order for the talk proposal to be competitive.

At the other extreme, from time to time we get a submission with a timeline so long and detailed that it’s nearly a transcript of the proposed talk. While we’ve never rejected a talk proposal for having too much detail in the timeline, talk proposal submitters should consider whether a timeline of 1000 words or more is a good use of the proposal reviewers’ time — or their own time, for that matter. Considering how many proposals the reviewers have to get through, submitting a timeline longer than, say, 500 words means that we’re likely to only skim it (or have less time to focus on the abstract).

As someone who often prepares for talks by writing out the complete text of the talk, I understand the motivation for writing an extremely detailed timeline. However, it’s not necessarily worth doing at the proposal stage, for a talk that you aren’t even sure you’re going to give yet. If you feel you must write a thousand-word-long timeline, by all means do so, but consider keeping the long version for yourself and helping out the reviewers by submitting a distilled version of it as part of the actual talk proposal.

Thanks to Tara Vancil, Geoffrey Litt, Jan Mitsuko Cash, and Mark Dominus for letting me use their timelines in this post.