The rectangle behind you

An interactive talk companion

This kind of drives me crazy:

The idea of someone needing to take a photo of the slide to share it, instead of being able to access it directly is just insane. After all, the presenter with the pristine, original source of the image, is just meters away!

This article is about an idea I had for a solution to this issue — including all the source code.

What did I try to do about it

I tried to solve this issue by writing a little companion site that anyone in the audience could open on their phone or computer as I was presenting. The companion site would always show the slide I was on, and allow you to save it or tweet it.

This animation illustrates how the whole thing works on the inside:

Things that seemed important while building it:

• on the companion site, you should always see the current slide, but also be able to freely go back to previous slides if you missed them (but never be able to go forward)
• you should also be able to save the slide you’re looking at, or tweet it (text and image)
• even if some of my slides are interactive, all of the companion slides should simply be images — it’s easier to save and share them, and I don’t have to worry about making them compatible with all the browsers out there.
• since the audience will be using the companion site on all sorts of devices (phones, tablets, computers), it needs to be responsive
• the interface should be very easy — don’t want the companion site to be distracting

The companion site premiered at Smashing Conference Whistler 2014, and it seems to have worked well:

Even though some things are still unclear:

• The site could’ve been more of a distraction than help, drawing attention away from my talk.
• I was very lucky with wi-fi — in other circumstances, the connection problems might have turned a helpful idea into an annoying nuisance.
• Since the website lives on, people can use it to share the presentation with others in the worst way possible: by just linking to a “naked” slide deck without my commentary and context.

I kept the companion site up and you can check it out at aresluna.org/whistler.

(Although, since the talk is over, the live syncing function won’t work and you will simply be able to see all the slides straight away.)

How does it work

There are three main components:

• My presentation is a website running on local computer connected to a projector. Everything is local.
• The companion site lives on my external server with a public URL (aresluna.org/whistler) that I announce at the beginning of the talk. All of the slides are images on that server as well, completely independent from the slides on my computer.
• There is a little server (in my case, hosted at Nodejitsu) that the two above websites use to communicate with one another.

As I give a talk, my presentation simply pings the server with the current slide.

Then, all the companion sites talk to the server, asking what is the current slide being presented. If the member of the audience is looking at the current slide, it automatically advances to match the presentation. If they’re looking at the past slide, the UI just makes it clear you’re “behind.”

If I (presenter) go back, nothing happens on the companion sites. They only go forward together.

Design decisions

• The companion site UI gives you a chance to go back and forward between the slides that you’ve already seen — and it also gives you a quick button (CURRENT) to catch up with the live slide.

The first two screenshots illustrate the user just following the talk. The last one is when the user chooses to go back to an earlier slide. Note the change in showing the slide number, and the Current button highlighted to show how to get back to viewing the talk “live.”

• The images are simply… images (not div backgrounds) so that you can or tap and hold, or right click to save them.
• The companion site is built responsively:

The appearance of the companion site on different devices. The UI changes between touch and click devices, too — on touch devices, it prompts people to press and hold to save, otherwise to “save to desktop.”

• The companion site shares a lot of design traits with the presentation itself (typography, palette), but it’s not exactly the same — since it’s important to establish which part of the site is the slide, and which the extra chrome.
• The companion site uses OAuth.io and Twitter API to tie into Twitter to be able to put together tweets with images (alas, it’s impossible to create a tweet with an image using Twitter web intents). It also tries to pre-fill text on slides where it makes sense, and adds the conference hashtag.

• The Twitter authentication happens after the tweet is ready to be filled out. (Doing it earlier would mean higher chance of people giving up.)
• Note that you can also alternatively tap and hold to save the image, and tweet or share from there.
• The companion site uses WebSockets to communicate with the server, but also regular HTTP GETs (polling) as a fallback.

Little details

• The images are compressed JPEGs, rather than PNGs, to make it easier on the conference wi-fi.
• The next and previous slide are preloaded on the companion site, so that when the presenter changes the slide on the projector, it appears instantaneously on the companion site. (This also means that someone can easily look at future slides when they mess a bit with JavaScript. But that’s okay.)
• For some of the slides I was interacting with on screen, I chose to take a screenshot of a representative state. (That means, that in some cases the slides were spoiling a bit what was about to happen on the big screen.)
• When the user is typing a tweet, it’s cached locally so that if the tweet sending fails, the user can reload the site and try again easily without losing the text.
• On a desktop, one can use left/right arrow to quickly go through the slides.
• Some slides (for example, half builds in between slides) can be designated to not be mirrored to the companion site.
• The companion site should understand and work correctly with skip slides
• As the presenter moves forward, the last visible slide is updated on companion sites… but not if the presenter moves backward (once you see a slide on the companion site, you should be able to “own it.”) However, this creates a problem for rehearsals and testing — how do you “rewind” the companion sites to the initial state? Instead of doing something explicit (and something the presenter is likely to forget), I just decided to automatically rewind the remote if the presentation shows any of the first three slides.

The source code and how it can be improved

View the entire code on GitHub

I want to end with a list of ideas for improvements to the above that I didn’t yet have time to add:

• The companion site loads badly, sometimes with flash of unstyled content. Also, images swap weirdly since I’m reusing one image tag.
• It would be nice if it was possible to zoom on the slide on touch devices to see its details. (Right now the page is not zoomable.)
• Disconnects or slow connections should be handled better, perhaps informing the user that the companion site cannot reach the server.
• On touch devices, it would be nice to allow to change slides by swiping, and not just tapping on small buttons.
• By necessity, the companion site’s slides (images) have to be generated from actual slides (HTML website). I have done it all by hand by taking screenshots of each slides. I investigated the use of something like PhantomJS to do it automatically, but it was problematic. However, if your talk comes from Keynote or PowerPoint, it will be easier to just save to images and use those.
• Likewise, recreating the metadata could be much nicer than a janky Shift-D copy/paste setup.
• The companion site needs to be as lightweight as possible (conferences wi-fi are tricky). There’s an opportunity to remove/bake in some of the libraries I use (jQuery, LESS). Another improvement would be to have lighter-weight JPEGs just to watch the slides, and higher quality ones for when people decide to save or share on Twitter. Lastly, sharing on Twitter converts images to base64 and sends them there, which is heavy. Could we just point to external URLs?
• Also, I need to load Twitter’s API to render tweets. It would be great to figure out how to do this when the tweet needs to be rendered, rather than on every page load.
• The companion site, especially if it’s meant to stick around, could be fleshed out to be more of a standalone piece: some context at the beginning, links to articles at the end, maybe even presenter notes attached to slides for context. Perhaps the last slide should have a questionnaire for people to ask about whether they enjoyed the talk?
• Another functionality that might make it less likely for the companion site to be distracting would be an ability to like or “star” any interesting slide, and then at the end give you a summary or maybe allow you to enter an email to send the slides to yourself — and only then you can share or otherwise process them, instead of doing it “live.”
• Since I had many slides with builds, I decided to skip some of them on the companion site. Perhaps it might be less confusing and easier to just show everything.
• I used OAuth.io all on the client. Is that insecure? It was unclear whether all-JS authentication is kosher; it seems that it might not fully be.

Thank you to Bill Couch and Sommer Panage for their help in developing and testing this idea.

The rectangle behind you, a series of articles about interactive presentations.

By Marcin Wichary (@mwichary)