Investigating about a Player Non-Player
Habits in use terms and priorities.
Now watch it on a real video!
api.video is a French startup born from the experience of 10 years of work in the video field with the libcast.com, a video platform which helped other companies manage their videos. The company's goals are to improve the management and spread of videos as content on the web by simplifying the process for devs.
The company has an EDGE infrastructure that makes the work of developers easier with rapid video import, transcoding and streaming availability without any buffering for users. Thanks to their API, developers will be able to easily and quickly manage the use and broadcasting of videos on the web like never before.
When Cédric, the CEO of api.video, asked me to design the video player, I immediately perceived the need to create something basically “anonymous”, which could be applied to the videos of different clients for different companies, considering it would be used by platforms and websites outside api.video it was necessary in my mind to design an highly adaptive player. The basic idea was to have a Player-Non Player for api.video, depersonalized and modern, transparent, without colors or background shapes but which at the same time easy to use for everyone, on any medium and in some way also customizable by the developers who would then integrated it.
Videos today are very popular content. It’ s a fast and multilingual content that reaches everyone and everywhere, online or offline. One of the fundamental approaches for a designer is to also imagine the product usage scenarios, whether it is a digital or physical product. Imagine how end users can use it in the most spontaneous way possible, without too much mental elaborations to activate that sense of positivity. It is not trivial, it is not obvious, especially when you cannot get to know users well. And this can be a big problem, because you don't know real data, you can't really know the habits, but think in the most general sense possible by asking yourself questions before even starting. So spontaneous questions arose during the design process:
The users of the videos could be of any age. But I'm honest, a first thought was about teaching. And I imagined to children that they could use the api.video player to follow a online live lesson or offline video content to study.
I obviously imagined other scenarios trying to understand the habits of users who already use videos on known platforms, who already use players to interact with them. Some platforms have accustomed us to also perform some actions to use a video, such as double taps to the right and left of the video to go forward a few seconds, choose chapters scrolling directly on the progrees bar, activate subtitles with a tap or click in the center of the video to pause it or manage its audio volume.
There would be a lot to discuss but the main goal for introducing the player, at least at this early stage, was without a doubt to simplify the player and make it usable by anyone, respecting habits.
I started creating quick tests to show to the team and try to receive feedbacks from them too. Very important to have a good communication with the people you work with. I made some wireframes and uploaded them directly from Sketch to Zeplin for comments and new ideas. After all, the api.video team knows much better the habits of users who watch videos, knowledge gained in more than 10 years of experience through the previous Libcast videoplatform.
#1 Thinking about a menu button in top, essential to contain all future buttons. Here a large progress bar, great for mobile and some buttons in botton. Understanding which buttons were useful for users.
The problem of time applied on progress bar. What neutral color? Time is necessary? What about spaces? What about informations to show?
#2 On external platforms can be useful to have a title of video on it? How users can jump chapters or parts of videos? Team originally asked to me to take it down but when you are following a video lesson it can be great! Added a central Play button, chapters list, subtitles, picture-in-picture and volume. Was necessary to have a background applied on video when users hover-on or tap-on but at same time show the video when the action is done.
#4 I added here the logo of the company will use api.video to share videos. I understood how is important have a link with the company’s platforme when the video is outsourced on other websites. Here it was born the concept of customization for the player. So client will be able to select what add as button or informations on the video. Added the test about of buttons with the time of start of chapters, clicking on them you can go on other chapter. Not so great idea on mobile and when to many chapters. It’s a fail? Cool!
#5 Added the chapter title and subtitles enabled. All secondary actions in right area in vertical. Enlarged version of progress bar in mobile is a great solution to faster choose the part of video user would like to watch.
Example of a video with the central play button No Actions.
All status of a video changes based on user actions. Darker layers added to enhance the default white buttons.
Here a legend with the reference numbers that I’m going to explain below:
And other versions of a video in dimensions,live streaming, VR, mobile versions, and other more
Example of videos with the central play button Hover on version and different colors test customized by Devs-clients
I would have had to design a player that would have had to adapt the different video-formats. There are aspect ratio standards for videos (4: 3, 3: 2, 16: 9, etc...) but I saw it more as a barrier in this case than a solution.
I also considered some general habits of users who often use videos. Here some habits about videos:
• Users recognize videos thanks to the play button on it. It’s the start of the experience. Let’s videos recognizable for everyone.
• Users, especially students, need to watch a part of the video several times. They use mobile devices a lot.
• Maybe audio volume is unnecessary. But it might be a lack for some.
• Some people are used to showing a video on a large screen or TV. Chromecast is an important feature.
• Some people watch videos...but don't watch them. They only listen to the audio while doing other things. Picture in picture is a function to be enhanced.
• Subtitles might be a truble for some. Users can activate them and then customize colors and sizes.
• Live streams have a continuous flow. Users love being able to use Time Shifting to go back.
• The use of mobile is very high and growing. Optimize the progress bar to improve the UX.
Currently the player is specifically created for Videos and Live Streaming. It is also possible to test the player in a fast way thanks to a new service recently published by api.video on which you can upload a video in a few seconds and share the link with whoever you want. YES!
So and use the player (Only functions ideal for a general audience are enabled) or to learn more or accelerate your work as a developer in the field of videos visit
All projects shown here are designed by Marcello Di Giovanni and commercial rights are reserved to the company to which the project refers. Some graphic elements or design structures may have undergone changes during development, for strategic choices or for improvements in UI or UX design following internal team’s decisions.
Music by musicvine.com/track/soundroll/line-of-drums used and published by api.video at this link: https://api.video/blog/product-updates/new-release-and-features-september-2020
Pictures usable for free by Pexel.com
Imagine you find a video on on a website or on a platform. How you will be able to recognize it? By a signal like a play icon or a button with the text “Play” or “Watch it”. So it was necessary to add a recognizable sign like a Play icon. I added a unique shape based on api.video brand, sinuous and rounded, trying to create a unique icon (there are many types of play icons in the web) and give developers the possibility to customize it with colors that are visually connected to their brand.
The default color is the orange of api.video - A video then outsourced will still have the identity sign of the api.video brand, around the web, together with the other icons, will be the distinctive sign.
As I have previously specified, this type of content must be recognized as such, following the argument that the Play button is also a useful sign to recognize that an image viewed on the web is not a photo, but a video. The Play button will always have a central position, it is the main button. Without too many extravagances, to be useful to a large scale of users we do not know and that we cannot know, being users of external platforms, the progress bar is in the lower part of the video, totally at the bottom when viewing the video, in the area bottom left functions such as skip / rewind 10s, 20s, 30s or speed up video speed, for desktop video. Buttons that move instead in the central part of the video on mobile, to improve the experience.
In the lower right area, on the other hand, subtitles, audio volume, chromecast or picture in picture. At the top right the menu function that hosts all the other functions such as chapter management, sharing, download. On the top left, the company image with link, the title of the video and the title of the chapter. Obviously it is a player that adapts to the needs of the developer who integrates it, to the size of the video in px terms and to the device on which it is watched.
Imagine developers who create a website or a platform and want to decide how to manage all dimensions, in the sense of aspect ratio, of their videos, which despite being produced by cameras that follow these standards could still be cut in size with editors (As when with iPhone you cut video-pics to the size it in height and length you want).
It is therefore not possible to predict the dimensions in px of the content managed on different platforms.
I therefore worked out a very general grid that includes margins and spaces within the videos, which generally have a rectangular or square shape, and that could simply be a guide to organize all the internal elements of a video in the best possible way (Buttons, icons, links, etc...).
The grid would then also considers in a smart way the size of the videos for a better adaptation of its own player.
Fundamental problems identified to be solved were:
• Consider dimensions of videos added on external platformes
• Let the player show the video always (Also when you hover on)
• Videos can be external to a platforme. Connect them
• Around the world? Ok, no texts for languages!
• Videos are pop. Remember the habits of end users
• Design a player easy to use for everyone thinking about ages
• Add the ability for clients to customize the player
• Think about all devices possible on which final users will be watching videos
• Imagine the evolution of the videos as medium
• Observe the standard symbols
• The player will be applied on videos of different sizes
• Live videos, 360° videos, interactive videos, and other more type
The illustrated connection obviously has users as final actors, those who will use these contents everywhere on the web for various purposes, through devices of various kinds such as PCs, smartphones, TVs and much more, users who always deserve attention as end users. For the use of videos, it was therefore necessary for api.video to develop and create a video player within the company that was then used on all dev-clients for apps, software or platforms and then by the end users of these contents.
The new Player for videos
Designing a video player easily usable by everyone, everywhere and in all format possible.
Who can be the end users of the videos?
What media will they use to watch them?
How can they interact with the interface?
What habits do users have?
How the player can be customized by devs?
I designed other versions of this player cannot show now here. But thanks to this test phase I understood a lot.
How elements as a button or a link can be integrated in a video? First of all we need to think to better organize the interface and dedicate area to precise functions, like a website where there is the space in top dedicated to a nav bar, a footer where find informations or links, etc... I believe that this greatly improves the user experience by reducing the margin for error and mental processing. So the goal was to have an organization of all to give the right space to the most used functions making them easily accessible.
Video showed on a website or on a platform integrated by devs thanks to api.video before any actions by the user.
The Play button is the signal with an opacity of 80% before any actions.
The hover-on as action on video will changes the status.
It will appears a darker layer only on top (Status #2), main buttons like Menu (to see other infos or to set the video), audio volume (Imagine to play this video during the night! So you can set it before playing) and main informations: Title + Company logo with a link + Duration of video.
The central button Play became white with no opacity (100%).
Feedback after hover-on buttons of a video for desktop version.
Feedback after hover-on video user are watching. Status #4
Click on subtitles button to set background color, text color and size. Click on Close button to confirm.
Click on progress bar to choose the minute of video you want to watch or click on Chapters List button.
As you can see the progress bar is segmented when there are chapters. In this case you can see 10 chapters.
When you hover on a chapter, it will appears a signal on the progress bar to show the minute of start of the chapter.
Set volume with hover on and drag of a simple line.
Re-Play the video or choose next videos suggested in bottom in previews. Status #4.
User experience on mobile is different so something will changes for the player. The progress bar is larger to be easy to use, have a more comfortable and precise scroll with your fingers.
Some buttons, the ones most used by mobile users such as Chromescast or Enlarge, are in the top right area for small videos (Watched vertically), the remaining ones in the Menu area, as space is reduced and there would be a overlapping of icons. The main buttons such as Play / Pause, Rewind and Fast Forward move to a central area, as already described above. Not all setting functions are enabled for the mobile version.
Some components have been added necessary for better UX design of videos watched on mobile.
Mobile version and resized videos