Whether it would be out of pure frustration or laziness I think we all have had our moments where we conceptualize something that would enhance our experiences using existing products/services. In that spirit, I have decided to start logging a few of those occasions on this portfolio in a series called IDEA – Imagine Designing (in) Existing Areas. These posts will showcase ideas without user testing.
I spent the weekend watching the 11th Counter-Strike: Global Offensive (CS:GO) major on the streaming platform Twitch which got me thinking about online video players. As CS:GO tournament organizers choose their platform the CS:GO community has seen their fair share of streaming platforms over the years. In recent times, YouTube and Twitch have been the most utilized services. Over the years we have seen fantastic advancements in streaming videos online. If we look beyond the fact that anyone with a decent computer/smartphone and internet can live stream at any time (opening up a global market for services such as Twitch) we can find other improvements in streaming. We have seen the, at times dysfunctional, Flash Player being exchanged for the seemingly stronger, faster, and web-customized HTML5 video player. Companies, such as YouTube, has given us the opportunity to close the browser in the middle of watching a video then to return to the video at the exact second where we left off.
I mentioned watching the CS:GO major which on day 1 of the tournament meant a 12+ hours stream. Streams and videos are seemingly getting longer and longer which coincides with the “10+ minutes YouTube video rule”; i.e. a YouTube metric saying that average time spent on a single video is more important/profitable than count of views – longer videos will most likely have a longer average viewing time. Don’t cite me on this as I’m just going off of other posts. As we get more exposed to longer videos we will start running into a problem on smartphones where we have the combination of fat fingers and a small surface (and even smaller controllers). As I missed a specific matchup between two teams in the early stages of the tournament I decided to watch a replay via YouTube’s mobile application. I found myself wanting to fast-forward or rewind 1-3 minutes (in a 12 hours video) because of technical timeouts in the on-going match. Needless to say, it was impossible. Rather than fast-forwarding three minutes I instead fast-forwarded 30 minutes which lead to knowing the end result of the match. I do realize that 12 hours of content is quite a lot, and perhaps an unlikely scenario for most users, but I can imagine that other people have experienced a similar situation.
I watched the later stages of tournament together with a group of friends and I discussed this specific issue with one of my friends who is a programmer. We started to look around for fast-forwarding functionalities on streaming applications and were surprised to find that by double tapping the left or right side of the screen it will enable the user to skip 10 seconds of the video (see GIF below). By tapping multiple times that number will increase to 20, 30, 40 seconds etc. This is great if the user missed a piece of information during the video and wants to rewind 10-20 seconds.
Existing fast-forward functionality in YouTube’s mobile app by double tapping the right side of the screen.
Although the functionality is quite hidden and arguably needs stronger signifiers (i.e. something that enables us to getting closer to the actual affordance of the object) it is in my opinion a strong feature for smartphones. However, it does not necessarily solve my issue of fast-forwarding three minutes (or perhaps 60 seconds) without having to double tap the screen a lot of times. And with every double tap, the video has to reload which will be quite time-consuming if you’re on a bad connection. So what would be a potential solution to fast-forwarding and rewinding in (really) long videos?
At first I was thinking about a vertical line for fast-forwarding but that might be creating confusion as today’s applications more often than not has a horizontal slider for “moving in time” such as Spotify. Alternatively, adding rewind and fast-forwarding icons would solve the issue of not having to double tap until you experience cramps by adding functionality of skipping, let’s say, 30 seconds at a time (see Figure below). However, there are downsides to this as it will not be a specified move by the user as she/he has to adapt to 30 seconds at a time; it will in a sense be a specified move by the application itself on the behalf of the user. Another concern would be – and I suspect these icons have not been implemented by the YouTube team for that reason – that it would ruin the minimalistic design of the fullscreen mode of the application. Thus a functionality as the double tapping of the screen (as the GIF shows in this post) has been added. However, imagine that by touching the icon the video would fast-forward as VHS tapes would in older days. If I were to touch the fast-forward icon the video would start playing in X times the speed of the normal speed. I know there is functionality for playing the video in different speeds on desktop but I have yet to see it on YouTube’s mobile app. Also, such a solution would require more clicks (or touches if you will) than just keeping your finger in one place for X amount of time. This would then present functionality that a lot of people are familiar with but it would be accessed in a different way and on the behalf of the user. One could also imagine that by touching the icon one time would fast-forward 10 seconds making a clearer signifier of the feature discussed prior. I believe that from a metaphorical perspective, tracing back to the old VHS players, such actions would make sense.
Figure of adding rewind and fast-forward icons (from Material.io’s icon base).
To conclude, I do believe that by adding the timeline, for moving to whatever point in the movie we like, we got complacence in the area of fast-forward and rewind on smartphones. I don’t expect that a lot of people feel the same about this issue. But this was definitely a design challenge for me. What direction would you take for solving this or a similar issue?