Enterprise solution for Video Conferencing
UX research project. The goal is to provide an enterprise online conferencing segment users with the best Video and screen-sharing experience under unknown network conditions. User disconnections from events as a result of low bandwidth should be handled.
My role was UX researcher role.
First of all, the main players were determined:
Video - supported in three sizes QCIF, CIF, and VGA.
Screen sharing - of two kinds: synthetic data as PowerPoint presentations or Word documents or nature pictures as nature photos. The different kinds of data influence compressed file size.
Periodicity - could be every 30 sec like.
Intensity - when presenter turns pages could be or full-screen data updated or part screen update.
File transfer during screen sharing and/or video
The goal is to phrase the criteria of the decision-making to improve user experience. The criteria should be phrased based on the technical spec of the system:
ability to send video in different resolutions;
ability to share the screen in different detail levels;
ability to define prioritization of the different content transfers;
and most common scenarios of data distribution during events.
Roy is a technical writer. He uses our platform for Video conferencing several times a week.
He works from his home and his bandwidth is not so perfect and his user experience is affected by it.
Rina is a manager in a high-tech company. She uses our platform for Video conferencing several times a day.
She works from her office so usually, her bandwidth is very good but sometimes she needs to download big files and it creates a bandwidth usage peak.
For the most common transferred data types (like PowerPoint presentation, Word document, nature pictures, CAD document, Desktop, etc) weight should be measured in a compressed state for the full or partial page update;
Different data transfer combinations to be tested: video with screen sharing, video with file transfer, screen sharing with video, and file transfer...
Peak detection should be separately analyzed with permanently low bandwidth
Visual changes should be smooth enough for not be noticed as much as possible.
Screen Sharing Scenarios Examples
saving network behavior
network behavior analytics
How we create criteria
Remove video packets up to next key frame few times before freeze
Hold video for few seconds on the server’s queue before freeze.
In the first case we see few short time video stuck before video freeze or release, in the second one we see one longer video stuck. We should choose one of these options.
Server keeps an information regarding percentage of video, sharing and file transfer.
This information will be used to decide freeze stream or hold video.
Send dummy packets from serverfor user’s bandwidth detection
Analyze user’s history on the client and update server
We can recover frozen video forcibly at the sharing stop.
The unresolved peak for X times during Y time
The unresolved peak for X times during Y time with new input
The unresolved peak for X times during Y time with PA input
Decision-making criteria phrased for:
Streaming (20%-80%) and video (60-250 Kbps per video) quality downgrade criteria.
Failure cases with not balanced decision-making conditions is handled.
This case may put the system into the "hysterics" condition when the freeze and recovery are happening frequently.
Several downgrade steps before feature freeze or close.
All scenarios are tested well during laboratory tests with Shunra.
Recovery cases criteria.
User experience is perfect and user disconnections from events are prevented.