Designing A Conference: Details

Some details might help Tinderbox novices follow “Designing A Conference With Tinderbox.” If you haven’t read that post already, you should probably read it first.

Prototypes For Papers

I seldom build a tree of prototypes in Tinderbox, but this task is an exception.

We have a prototype Paper that represents a submitted research paper. It has the key attributes you’d expect: author, title, submission number, reviewer scores, and the email address of the corresponding author.

We then have a bunch of prototypes that inherit from Paper and represent various categories of accepted paper. These prototypes do two things:

• Add some distinctive appearance, so it’s easy to scan a complex map and pick out the accepted papers.
• Provide an easy handle for agents that want to search for all the accepted papers, or for specific kinds of accepted paper.

Agents For Double Checking

Web Science ’13, like many conferences, uses the EasyChair Web application to coordinate reviewers. EasyChair is a headache, but perhaps less of a headache than the old days where we photocopies every paper four times, stuffed and mailed a hundred envelopes, and collated reviews on paper tally lists.

EasyChair gives you a convenient count of the number of acceptances you’ve sent. Obviously, we want to be confident that our own records and EasyChair’s are in sync. One way to increase our confidence is to check that the number of accepted papers in each category matches the number of EasyChair acceptances. An agent can make short work of this.

We simply look for all the notes that have the appropriate prototype, count them up, and check the total against the number of acceptance emails. If they don’t match, you know you’d better go hunt down the discrepancy!

Even then, you never know. One author of an accepted paper didn’t read his email with sufficient care, and assumed his paper had been accepted for a workshop. He came, read his paper to the workshop, and left Paris. Only as he used the train’s wifi on the return voyage did he realize his mistake. That was awkward, but not as awkward as the encounter would be with a researcher who has travelled a long distance at great expense, only to find their presentation is not on the program.

Trial By Fire

Using the prototype Tinderbox Six to manage the program was a risk. Through the process, the software changed from day to day, and it was not unusual for progress on the conference to require a quick fix to the software. Many details of the screen layout in these examples will therefore look a bit strange to today’s Tinderbox 5.12 users, and they’ll doubtless seem quaint when Tinderbox Six is actually released.

I also kept my conference notes in Tinderbox Six, such as they were — program chairs have many distractions, I was on stage a lot and it’s hard to take notes when you’re on stage.

As usual, the left margin is reserved for notes to myself — especially notes about #Tinderbox features that I wanted as I made the notes. For example, the test version I was using didn’t understand that double-clicking an adornment should create a new note, just like double-clicking in the background of the map. This is the sort of thing that Test Driven Development doesn’t catch (it’s a dog that didn’t bark in the night) but that is still very good to know about. Tinderbox Six was well behaved through the conference, giving us a little more confidence as we approach the widening of the circle.

Questions? Email me.