Live view for presenters

[amyjko]

Is your feature request related to a problem? Please describe. Anyone participating in the backstage faces two critical social information gaps: 1) what the audience is seeing and 2) when they are seeing it. These two pieces of real-time information are essential for many things: 1) interpreting the meaning of chat messages and emoji reactions, which occur in real-time, 2) confirming what the audience is seeing before talking about what they are seeing, and 3) confirming the layout of streamed information. Without all of this information, presenters and facilitators cannot verify the quality of the audience experience and react to quality concerns. The workaround for this, which all presenters we've talked to have done, is to open another tab to see the audience view, and muting the tab's audio. This works okay, but it requires a large display to fit two large tabs and many presenters do not discover this strategy, leading to quality concerns in the first few days of the conference.

Describe the solution you'd like The backstage view should simply stream the audience view, muted, and in case it's distracting, it should be hideable.

[rossng]

I agree. We do have significant plans to tackle this in future.

Additionally, we have considered adding a low-resolution preview of the audience stream to the backstage. There are some issues, on which I'd be interested in opinions:

• How do we communicate the stream latency intuitively to presenters?
• How do we avoid starving bandwidth for presenters on weak internet connections (very common!)?
• Must we force-mute the stream to avoid audio feedback loops, or is there a clever solution? It is a high priority for us to avoid introducing potential audio loops - it's really awful for the audience.
• Where do we put the preview on the page?

[amyjko]

Those are indeed hard design questions, but current practice can be a guide. Here's the task I find presenters commonly doing, unsupported:

• They discover a momentary need to see what the audience is seeing
• They open another tab, navigate to the room, enter audience view, get the information they need (latency, what is currently visible)
• They close the tab, and use the information to decide what to say/do next.

It's rare that I've seen anyone need the view on an ongoing basis.

A simple design might therefore be a "peek" interaction: popup the audience view in place to get the information necessary, then dismiss it to resume. This would reduce the whole 15-20 second interaction above to <1 second and minimize bandwidth consequences.

For audio, given the structure of the task above, I'd recommend swapping: when the "peek" is visible, mute the backstage audio, and let the presenter listen to the audience audio. Once the "peek" is closed, swap back.

The UX for this would look something like this:

• A presenter discovers a momentary need to see what the audience is seeing
• They request to peek at the audience view
• Their audio switches to the stream, the video is shown, and they get the information they need
• They close the audience stream and resume their presentation/backstage discussion, etc.

This would be useful for confirming that they are live, for verifying stream layout, for judging latency.