The rectangle behind you
Follow along and up
I crave follow-ups. When I was little, I loved opening the encyclopedia to learn more about something I just heard — particularly when it felt the volumes were roughly as big as I was. Later on, I cherished coming back from the movie just to read Roger Ebert’s review, or ⌘+clicking every link in the young Wikipedia.
Today, I still like looking up a newly-discovered word in a dictionary, an obscure product on Internet Archive, or a historical event on Google. In the middle of a conversation, you might find me scribbling something down to look up myself — or to send you later. When I worked on Medium underlines, part of my excitement of it was just working on better linking.
And I’ve always dreamed of creating a “link” that would work when I delivered talks.
Yes, as an audience member, you can easily write down something I’m saying to look it up later. But the act of jotting might be distracting and — more importantly — the best links to find are not always the first results Google spits out.
But I, the speaker, know all the links! If I do my job right and prepare for the talk, I am aware of exactly the obscure pages and documents you should check out if you want to dig deeper… and yet, there is no obvious way for me to give them to you.
The idea
My idea was to create a small talk companion: a web app you could open on any device you have, at any moment during the talk. During my talk, the app would slowly reveal new topics I brought up, and allow you to say “I’m interested in this! I would love to know even more” by simply tapping on a topic — in effect bookmarking it for the very near future.
The only remaining thing would be to provide your email address. And then, some time after the talk ended, you would get a perfectly curated follow-up email with more high-quality links about the things you expressed interest in — and only them.
Preparations
I built and tested a rudimentary version of this idea recently for my Beyond Tellerrand talk about fun and keyboards.
I started by looking at my slides and grouping them into topics. I ended up with 20 of them: the evolution of typewriters, ATASCII movies, overtyping, semigraphics, and so on. Here are the first five, matched with the slides:
I then created a little follow-up block of text for each section. Each topic contained anything from one to five links: sometimes they would point to obvious things like Wikipedia, sometimes to rare Internet Archive books, sometimes to Medium posts I made just for this occasion. Either way, each one would be the best possible companion to a given topic, for example:
How do mechanical typewriters work?
A nice Olivetti manual explaining different parts of a typewriter: http://machinesoflovinggrace.com/manuals/OlivettiLettera22Manual.pdf
For comparison, here’s a much older one: https://archive.org/details/TheBookOfTheNewCentury
A fantastic book about the insides of a typewriter: https://archive.org/details/MechanicalDevicesOfTheTypewriter
Then I added a way for my slide deck to communicate its progress with a custom simple Node server (I hosted it on DreamHost, although I bet there are many other options).
Before my talk, on every seat, we put out URLs and QR codes for the second component: the companion app. Before or during (or even after) the talk, anyone in the audience could open the app to “follow along.”
The app would talk to the server as well (via Websockets), and receive any new topics I just revealed. It would also allow people to tap on the topics they were interested in, and save that information back so that eventually a proper email could be sent.
The design goal was for the companion app to provide a distraction-free experience (after all, fiddling with the UI as I was speaking would go against the whole idea). That meant two things: UI simplicity, and high robustness.
In the visible UI department, the app needed just one tap on a topic to express interest. You could also enter your email address at any point, before, during, or after the talk. Everything you did was saved automatically and silently… and that was it.
Once I started talking about a new topic, it would appear at the top, like in a chat. This made saying “I want to know more about what he’s talking about right now” — likely the most common use case — to be always in a consistent place under your finger. And, if the new topic arrived as you were looking at the page, it would slide in and animate slowly, making it harder to tap on something wrong by accident.
A lot more stuff happened behind the scenes. I was worried about wi-fi failing, and I anticipated people jumping in and out as the talk went along. And so, saving was silent and automatic… but if the connection was spotty, you’d get an error message warning you — and you didn’t have to do anything, as the app would continue trying to reconnect in the background (with exponential backoff). A bunch of code was also dedicated to saving the data in local storage so that reloading the page would never lose any data.
At any given moment you could also input your email… and the app would warn you if you started selecting topics without providing the email address.
You can play with the simulation of the companion. It is not synced to the server in any way. Rather, it pretend the talk starts 5 seconds after you load the page, and each topic takes 4 seconds.
And, here is an example of the email you’d have gotten if you selected all the topics.
The outcome
Did it all work? I think so.
About 100 people (out of the ~450 in the audience) provided their email address, and eventually got a follow-up email. (This was an MVP, so I sent the emails myself one by one, after writing the script that helped me put them together them).
I didn’t track the open rate on the emails, and didn’t embellish the URLs so that I could see how many of them were eventually opened. Those would be improvements for a future edition — although, to be honest, I hate the interim URLs in newsletters as they obfuscate the destination.
The most the experiment failed so far was in the UI department: I made saving too smooth and people were confused whether their choices were actually being sent to the server. (One way to solve it would be either to provide an explicit Saving/Saved UI, or arrange the UI to look more like a form with an explicit Submit button.)
I plan to continue working on this and report back. If you’ve done or will do something similar, please let me know. I won’t mind sharing my code, either, if you’re interested.
(I have previously worked on a different type of a talk companion — one that would allow you to see the slides in real time and save or tweet them. This feels better, rewarding longer-term interest over short-term reactions.)
And either way, once you have a talk companion built, you can also allow the audience to send you something… but that’s a whole different story.
This was part of The rectangle behind you, a series of articles about interactive presentations.
By Marcin Wichary (@mwichary)
