Designing Screen Sharing
Here we are again! In reference to my last post, I indicated that my group and I had picked to better the design of screen sharing for the user profile of a medical professional. After much thought, we decided to shift our user profile. Instead, we aimed to design a screen-sharing platform that caters to academic users. Considering our situation of COVID-19 and our current positions as students, we thought this framing of the problem would be a better fit.
Problem Overview
The shelter-at-home orders placed to fight the COVID-19 pandemic has forced millions of students to retreat home and to switch to online learning. As a result, the use of video conferencing platforms have experienced a huge spike in users. Due to the classroom settings of a regular academic year, we can say that students and teachers alike wouldn’t need to use video conferencing platforms to converse with each other for communicating lectures and presentations.
Consequently, we are dealing with the novelty of screen sharing to the academic audience of students. The screen sharing functionality of video conferencing platforms are in no means standardized to students in school. We saw this lack of standardization in the struggles that ensued when students expressed the scrambling of adaptation to online learning from students and teachers.
In order to design a screen sharing interface that acknowledged the needs of students, we talked to students again. We asked questions such as:
- How often have you used screen sharing as part of online learning?
- What platform do you use?
- When is screen sharing used?
- Have any problems arise when screen sharing was used?
- Why do you use screen sharing, if you do?
- Have you ever felt like your privacy was breached when using screen sharing?
After talking to about 15 students, we were able to create user profile that culminated the responses of these students:
Overall, students wanted to have more transparency in what they were sharing. Many students discussed the weariness of the privacy of their desktop that not knowing what was being shared provoked. We understood the need to be adhered to the idea of presenting their screen for a class, which would have higher stakes of accidentally sharing the wrong screen.
First Design ~ The Notification System!
When evaluating the responses from our users, we came to the understanding that there was a miscommunication between screen sharing and the student. What was being shared? What was not being shared? In order to tackle this problem of privacy, we ideated a notification system. This notification system would theoretically pop up when a user was about to screen share. This notification system is critical to our redesign of screen sharing platforms because we believe that the best way to reduce any miscommuncation between the interface and user is to provide clear notifications of what will happen when screen sharing is started. We don’t want our users guessing the magnitude of their privacy.
User Testing
Once this was created, we went around and asked students about this design. Specifically, we asked them to navigate the design as they would normally do if they were about to share their screen during class. The main takeaways from this round of user testing included:
- Questions about how accessible this software could be when attached to already existing video conferencing apps (BlueJeans, Zoom, etc.)
- The font and color mix were not reciprocated well
- The first question about notifications seems redundant
- Checkbox is too much information — like a survey
As designers, we agreed with the comments about the checklist being “too much”. The excessive information could be time costly when a student is trying to start their presentation for class while still in a discussion with other people in class. Also, what if the student has alot of windows and tabs open? Considering the likelihood of this user case as students usually have to have alot of windows open at a time, we considered the checklist to be too time costly for the user and scrapped it.
2nd Design
After scrapping the extensive checklist, in our last design, we reached a more simplistic version:
Similar to our first design of the notification system we provided details that were most important: having control over what will be avoided while screen sharing (do not disturb), choosing what to share, and a new feature, lock mode. When thinking about the lifestyle of student, especially in the realm of being present in online class, we considered the challenge of accidentally switching screens. This process of intrinsically switching screens during a presentation could reap embarassing outcomes of accidentaly sharing a completely irrelevant window while presenting. So, we wanted to create Lock Mode to mitigate this accident. It will essentially allow users to lock in on a certain window they want to share which will only share that screen to other participants.
User Testing
When we asked around about this second design of the notification system, many students liked the simplicity about it. One comment that stand out was the confusion of picking a window to share.
As designers, we were glad to get positive feedback. We understood how picking a window to share could be quite confusing, especially when a student could have so many windows and tabs to choose from. I will expand on this in the next section.
We took this into account when moving onto our final design which included the functionalities within an actual video conferencing interface.
3rd Design
In order to visualize our system within the realistic interface of an actual video conferencing session, we wanted our design to interact with other buttons in an interface like Zoom, BlueJeans, Google Hangouts, etc.
When considering the larger scope of our notification system, we thought it would be useful to add a series of notification windows that would help the user “check” that they are sharing the appropriate screen. When the user goes through the first wave of the notification screen, they will be presented with:
When View As Public is selected, this will show:
When the user selects to start screen sharing, this is what the interface will look like:
User Testing
We recieved outstanding reviews about our “Preview Mode”. However, we received more reservations about the complications of picking a screen to share and the redundancy of the “Screen Sharing On” indication in the bottom left corner. The “Preview Mode” eased a lot of users to know what they needed: the clarity of what screen they will be sharing.
As designers, we agreed with many of the comments of our users. We believed that the addition of “Preview Mode” would enact an early sense of comfort in knowing what will be showed to other participants in a call. However, our next deal of business was considering a few more user cases:
- What will happen if a user wants to change the screen that they are sharing while they are screen sharing?
- What if the student has an overwhelming amount of tabs and windows to choose from? The carousel form that we currently have on the first wave of the notification system could become costly and ineffective in visualizing these tabs and windows.
- What if the student is sharing their entire screen and but only want to share two windows that are not in full screen?
4th Design — Final Design
And we’re on to our final iteration and design.
Our first window is similar to our 3rd design, but we added a feature that enables users to have a more clear cut representation of what could be shared.
As you can see, we added a feature that allows a hierarchal organization of all possible windows and tabs to share. We knew that this option could be very useful as representing one application or window to share would be too vague in telling what specific tab or window of an application will be shown. This is why we added an indicative arrow that will show up whenever an open application is sensed to have multiple windows or tabs open. This way, users know that they have a choice of specifically selecting what part of that open application they’d want to share. It also gives more insight into what the screen sharing platform has access to.
If users have picked to share their entire screen, we’ve added a feature that allows users to “blur” their desktop. We did user test this feature and after much survey, the majority of users said that they would use it. We developed this feature as a response to some users stating that much of their insecurity about screen sharing resided in the possibility of accidentally sharing a part of their personal documents and things in passing from window to window. This would help with the user case in which a student chooses sharing their entire screen and but only want to share two windows that are not in full screen. The blurred screen would look like this:
Similar to our 3rd design, we added the wave of ‘checking’ your screen sharing before going Live where you can switch into Preview Mode.
Users thought that the previous text of “View As Public” didn’t sound appropriate and was confusing in understanding what the function would do. As the designers of this project, we also agreed with this comment of the users. In response to this criticism, we changed the text to “View As Participant”. This allows users to have more of a clear cut understanding of what the button will do, so they don’t feel hesitant of what it will do when it is pressed.
When Users Go Live With Screen Sharing
From the screenshot below, you can see that we added a few more icons to the toolbar of our video conferencing platform. We wanted “Lock mode”, “Blur Mode” and “Preview Mode” to be available at all times, allowing a consistency of control when the user is screen sharing.
In addition to the icons that we’ve added to the toolbar, we’ve also added a pause and play button. This would allow the user to pause their screen so that they can quickly recuperate from any accidental sharing of a pop-up or very personal screen. Think of this as a buffer so that screen sharing sessions can be kept professional and purposeful specific to a certain screen the user wants shared.
In order to allow users with the best viewing of their screen capable, we also added a collapse and expand button on the bottom toolbar. When in screen sharing mode the the top toolbar of participants in a call will also collapse after some time but will reappear when the user hovers the top of their screen.
Lastly, in order to get back to their place of screen sharing as fast as possible, we added the capability of pressing the underlined window being shared in the bottom left corner. If a user has to switch to another screen or tab to tend to something, they can quickly switch back to their presentation by pressing this button. This will allow a faster navigation of reaching their shared screen, which will also come in the form of the yellow notification bubble on top. This will allow users to know that even if they switch screens while screen sharing, they are still screen sharing on another window. We want users to fulfill their need of appropriately sharing their screen for an academic reason and having transparency in knowing what and when something will be shared under multi-tasking scenarios.
Future Improvements
I do believe that there is always room for improvement! If I were to further design this project, I would look more into the management of many windows and tabs when screen sharing. Through our design process, we focused on the control of transparency and privacy when setting up screen sharing and when in screen sharing mode. When people are screen sharing their presentations or lectures, it shouldn’t be likely that they need to switch the window that they’re screen sharing frequently. However, I would like to look into the efficiences of doing so. This could manifest itself into a questioning of how to design for multi-tasking sessions of productivity. How robust should the system be to account for every possible task the user could switch to? Is this worth designing for?
In this part of designing screen sharing we thought that it would be excessive to account for such cases as we realized a balance between how the user uses the application and what the application provides.
Conclusion
In all, this problem proved to be much more complicated than we initially thought it would be. In other words, it presented itself in many more user cases than we thought. While designing this project, I learned that a platform like screen sharing can rapidly change in functionality depending on the user. As I discussed in my last blog post, the standardization of screen sharing is yet to be investigated for medical professionals. Screen sharing proved itself to a valuable function of video conferencing applications, especially in times like now where sharing your lecture or presentation is important for communicating class material.
