Design and develop a prototype for a simpler video presentation tool
User flow, development and prototyping
OpenFrameworks
To work on my ability to confidently present work via Zoom or other virtual meeting software, I needed to work on de-emphasizing the slides and comfortably speaking about the work. In a workshop with designer Mike Monteiro, he demonstrated this by speaking and commanding the room without sharing his screen. The viewers' attention was on him, his words, and the content of what he was saying. When he was ready to, he switched on to share my screen, supported his point, and then switched it off. Just the thought of trying to do this made my palms sweaty. I realized that I had a great deal of anxiety over the "share my screen" functionality in Zoom.
I realized that I had a great deal of anxiety over the "share my screen" functionality in Zoom.
I noticed that other people in my professional life seemed to share this feeling, and each had developed their own set of coping strategies to manage it. My strategy was to log in early with my tabs and my screens ready to go, and take over the screen share immediately. This coping strategy had zero wiggle room to experiment with directing a viewer's focus. However, I knew that I needed to play with this idea. So, I started to think more on this problem and possible solutions.
The video below is a quick demo of me showing off the final tool. You can also take a peek at the project status and code on github. As I may revisit this project in the future, that will be the most current iteration of the SimpleShift Presentation Tool. Additionally, if you want to play with the tool itself I can send you a beta for use on Macs. Request a beta by sending an email to beth@politetype.com.
I need to be able to give a presentation and keep the focus on myself, as the speaker. While presenting, I wanted to be able to bring up a slide, then easily dismiss it.
I started with a closer examination of why I had anxiety about sharing my screen. I felt like I looked as if I didn't know how to use technology. I was nervous that I was going to accidentally share a screen that shouldn't be shared or would somehow embarrass me, like a messy house. I felt like in order to fix any screen-sharing problems, I would have to create an awkward or uncomfortable silence. I feared that the other people on the call would feel like I was unprepared and didn't value their time.
Now, I could have practiced the skill of switching between screen-sharing and presenting. However, when I looked at the causes of my anxiety, I didn't think that my emotional reactions were necessarily the cause of the problem. It is embarrassing to share something that shouldn't be shared. It is a bit rude (intentionally or not) to mis-use other people's time and attention. I realized that the dominant user flow for conference calls (sign-on —> screen share —> select screen —> navigate back to zoom call) actually introduces a range of mistakes that is much wider than what the typical user would be comfortable with experiencing. There is a mismatch between the user and the technology.
For this particular scenario (a pre-planned client presentation), there are things that could be put in place before the call even begins. Typically, I not only know that I am going to be the presenter for the duration, but I also know exactly what it is that I want to present. If I could have my presentation deck pre-loaded and ready to go, then I wouldn't have to panic about navigating live, while trying to keep focus on the presentation content. Additionally for this particular project, I wanted to further explore the experience of remotely presenting work, but I did not want to create an entirely new video conferencing app in order to do it. I realized that there was a supremely lazy (efficient?) way around this problem. If I simply share my screen at the onset of a presentation that I am giving, I can display a video of myself there and completely control what the viewers are observing. This meant I could create an independent environment in which to develop enough of a technological proof-of-concept for me to create and experiment with a different user experience.
The first pain point that I wanted to address was the share screen functionality. I had the advantage of working with a very limited set of needs and one well-defined goal: Allow the presenter to easily toggle between a speaker window and a presentation window. Since the only criteria for an MVP was that I create something that I can play with, I approached this problem differently than I would approach a multiple-stakeholder project. I didn't need to design an entire product, I just needed to demonstrate an idea for myself.
Describing the MVP as a tool with which "A presenter can easily toggle between a speaker window and a presentation window," I realized that there was a but more minimal functionality that needed to be created, in order to support the tool. I also needed to be able to drop in a presentation or slides, and allow the presenter to cycle through a slide deck.
As I thought about the standard functionality for cycling through a slide deck with the right/left arrow keys, I recognized that I did not have anxiety when performing this task. I have even made errors when doing it, but I was able to easily recover and correct the error, without interrupting the flow of the presentation. I started to think about the problem in terms of 'forgivable mistakes.' If I was in the middle of delivering a presentation, how easy would it be for me to recover from my own user error?
I started to think about the problem in terms of 'forgivable mistakes.'
I was very comfortable with the way slide cycling worked. The arrow keys are natural and intuitive. I decided that using the up/down arrows would support this already universal functionality, nicely. If my hand is already comfortable and positioned to use the right/left arrows, it is easy to add this new functionality into the up/down arrows. (And hopefully, it wouldn't interfere with the slide-cycling functionality!)
Rather than pre-map out everything, I decided to just jump right into building something. This made the process a) more streamlined, since I could stop as soon as I felt I had experimented enough to become confident and b) more fun to work on. Using OpenFrameworks, an open source C++ framework, I got to work on the most basic functionality requirements. I was able to get this up and running in the relatively short timeframe of one Friday night.
As I was working on the prototype, I happened to take a break to watch an episode of John Oliver's Last Week Tonight. I realized that newscasters and teams have long been deploying their own solution to this problem. I decided to build in a "newscaster" slide view, to take advantage of this clever layout. This view allows the presenter to maintain the focus of the presentation on themselves, while keeping a reminder slide visible. This is a helpful addition for viewers who maybe got lost during the presentation, or who may have dropped in during the middle of the presentation. It also helps the presenter, who may need just a bit of reminder clue to ensure that they are staying on topic, and hitting major points.
With a working prototype, I was finally able to practice this new strategy towards a virtual presentation. It's helped me become aware of when I was letting the slides lead the presentation, rather than using them as a tool to enhance what I need to convey. Interestingly, the act of working on this exploration helped relieve a great deal of the "screen-share anxiety" that I was feeling. Once I framed the problem with a UX/UI solution, I realized that there was not something shameful that I was doing wrong. It was just a mismatch between the technology's system and how I wanted to use the technology.
