I expect much will be written about the problems encountered with communications with the remote pods at Event Camp Twin Cities 2011 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.
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, comes with a cost that may have contributed to the problems encountered at Event Camp Twin Cities: namely that the “real-time” feed delivered to remote attendees was delayed approximately twenty seconds.
During Event Camp Twin Cities 2011, 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, with several pods clustered on one Skype call. When the local participants wanted to have a real-time conversation, the plan was to switch to Skype, turning off the Mediasite feed, very much in the same way that a caller to a radio show is asked to turn off their time-delayed broadcast radio once they’re on the phone.
For reasons that are not clear to me, this switchover process did not work well at Event Camp Twin Cities. Again, 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 (delayed) Mediasite feed was used for the pods at Event Camp Twin Cities is that it provided 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.
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. This can easily be done using one of the “screen-sharing” solutions in wide use today; the A/V from a “master” computer would be broadcast to each pod. And then each pod would be linked to the event via its own two-way channel. This could be a Skype or other videoconference call, or perhaps a product like Google+ Hangouts could be used.
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, so that sound from the pods would not be distracting, but the complexities of switching between two channels on the fly would be eliminated using this approach.
I think that this approach might be an improvement over the design used at Event Camp Twin Cities 2011, as 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 by those who understand the issues better than I.
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!