The proposal builder: five fields, five checks

A conference proposal is five short pieces of writing that have to agree with each other: a title, an abstract, an outline, a bio and a private note to the committee. Most proposals are assembled in the last hour before a deadline, in a browser tab, with the five fields filled in the order the form happens to present them. The builder below walks through them in the order a reader uses them instead, and applies the five checks a committee applies on a first pass.

Nothing typed into it leaves the page. There is no account, no saving and no request to any server: the text exists in the browser tab and disappears when it is closed, which is the honest arrangement for a form that asks people for unpublished work.

The five checks it applies

The checks are the ones a reader can perform in the ninety seconds a first pass gives a submission, and they are applied to the shape of the text rather than to the idea in it.

Is the title the right size? Four to nine words, under about sixty characters. The constraint is typography rather than taste: schedule grids and mobile listings truncate somewhere in that region without warning anybody.

Is the abstract the right size? Between about forty-five and a hundred and ten words. Below the floor there is no room for the sentence that says what changes for the audience; above the ceiling the second half is read at a skim.

Does the abstract promise an outcome? The builder looks for language about what the audience gets, because a talk that describes a situation and never says what to do differently reads as a report.

Does the outline fit the slot? Beats are counted against the chosen format. More beats than a slot holds is the signature of a survey, and surveys lose to specifics. Fewer is usually fifteen minutes of padding waiting to happen.

Is the notes field used? It is private, most people leave it empty, and it is where prior outings of the talk, scheduling constraints and deliberate overlaps belong.

What it cannot tell you

The builder cannot tell whether a proposal is good. It measures length, structure and the presence of certain kinds of sentence, and none of those is the thing a committee is actually weighing, which is whether this talk is worth an hour of a roomful of people’s time and whether this speaker is the person to give it.

A green line means the shape is right. It says nothing about the idea.

It also cannot see the pile. A proposal can pass every check and still be declined because somebody else proposed the same subject, or because the day already had three talks at that level. That is the ordinary outcome rather than a failure, and rejection and resubmission covers what it means and what to do next.

Two habits are worth more than any check here. Reading the abstract aloud finds the sentences that do not survive being spoken, which are usually the ones that were written to sound impressive. And showing the title alone to somebody outside the work shows what it actually promises, which is frequently not what it was meant to promise.

Using the output

The button assembles everything into labelled plain text, which is the format that survives being pasted into a submission form, an email or a document without carrying any styling with it. There is nothing to download and nothing to install.

Because nothing is stored, a draft in progress is worth keeping somewhere else. The plain text output pasted into a file is enough, and it has the useful side effect of making the next proposal faster to write: the bio travels almost unchanged, and the outline is a shape that can be reused.

Each field has a page of its own behind it: the title, the abstract and the speaker bio. The form these five fields get pasted into is described on the call for speakers page, what happens to them afterwards is on the review process, and for a first submission first-time speakers covers what belongs in the notes.

Questions