Event Camp

I expect much will be written about the problems encountered with communications with the remote pods at Event Camp Twin Cities 2011 (ECTC) last week. Rather than concentrate on what went wrong, I thought I’d share some ideas on hybrid event architecture that grew from my on-site experience and a long conversation with Brandt Krueger, who produced the event, the following morning. Without Brandt’s explanations, I wouldn’t have been able to write this post, but any errors or omissions are mine and mine alone. I am not a production professional, so I write this post in the spirit of provoking discussion and input from those who have far more experience in this area.

Event Camp Twin Cities hybrid event design

Let’s start with a brief description of the set-up at Event Camp Twin Cities. As with many hybrid events, there were three audiences:

• The local on-site attendees in Minneapolis
• Seven “pods” (small groups of people that gathered in Amsterdam, Philadelphia, Toronto, Vancouver, Silicon Valley, and two corporate headquarters)
• Individual remote audience members

Both the pods and the individual remote audience members viewed the activities in Minneapolis via Sonic Foundry’s Mediasite platform. This product provides, via a browser-embedded player, A/V from the event (e.g., a presenter speaking) alongside additional media feeds (e.g., presenter slides). The flexibility of this technology, however, includes a cost that contributed to the problems encountered at Event Camp Twin Cities. The “real-time” feed delivered to remote attendees was delayed approximately twenty seconds.

During ECTC, individual remote audience members viewed the Mediasite feed and interacted with the proceedings via Twitter as a backchannel, ably assisted by remote audience host (aka virtual emcee) Emilie Barta. From the accounts I’ve heard, this channel worked well.

The pods also viewed the Mediasite feed and could interact via Twitter. To provide additional interactivity for the pods, Event Camp Twin Cities set up live Skype calls to the pods. Several pods clustered on one Skype call. When local participants wanted to have a real-time conversation, they switched to Skype, turning off the Mediasite feed. This is like the way a radio show caller turns off their time-delayed broadcast radio once on the phone.

How it worked out

For reasons that are not clear to me, this switchover process did not work well at ECTC. Rather than concentrate on what happened and why, I’d like to suggest another architectural approach for the pods’ experience that may prevent similar problems in the future.

Instead of switching between delayed and real-time channels for the pods, I think that pod <—> local communications should be set up only via real-time channels. One reason that the pods at ECTC use the (delayed) Mediasite feed is that it provides a convenient aggregation of the two broadcast sources needed for any event these days—A/V of what is going on at the venue plus a channel for slides or other supporting materials. That works for the individual remote audience, which only interacts with the event via Twitter. But when you want to have significant real-time, two-way communication between pods and the main event, you have to handle the complexity involved in switching between delayed and real-time channels on the fly.

Possible improvements

Here’s how my approach would work. All the pods would receive a single real-time broadcast channel for supporting materials (slides, movies, etc.) created at the event. You can easily do this using one of the “screen-sharing” solutions in wide use today. The A/V from a “master” computer would broadcast to each pod. And the event would link to each pod via its own two-way channel. This could be a Skype or other videoconference call.

With this architecture, the pods would not receive a delayed feed (i.e., no Mediasite feed), so no switching between delayed and live would be necessary. (Individual remote audience members would continue to receive the delayed feed, as before.) The main event site would need to produce the audio feed, to avoid distracting sound from the pods. But this approach would eliminate the complexities of switching between two channels on the fly.

I think that this approach might be an improvement over the Event Camp Twin Cities 2011 design. It would allow easier spontaneous real-time interaction with the pods while eliminating one potential source of problems during the event. I await with interest any comments from those who understand the issues better than I do.

Hybrid event production professionals, hybrid event attendees, in fact, all event professionals: what do you think?

Thanks, Ruud Janssen, for the photo of the production studio at Event Camp Twin Cities 2011!