Jun 1, 2015
The core purpose of this article is to provide an open source variable scrubbing speed solution for web developers. It is called ScrubbingSpeed.js. I intend it to be a jump-off point for porting to other languages and platforms too. Below you will find examples in addition to notes about further development and improvement ideas. In addition to this core purpose, we will take a brief look at current implementations of variable scrubbing speed in iOS, Android, and YouTube’s HTML5 video player. First however, we will refresh on what variable scrubbing speed is and why it is useful.
Have you ever tried to scrub to a specific part of a long video or audio file only to end up being way off of your target? If so, then you can benefit from the variable scrubbing speed concept, in fact a lot of people can. At its core, the implementation of this interaction design pattern empowers the user by providing him/her the ability to change and select a value within a range using great precision. This pattern is best used for sliders that are confined to a short length and/or have a large range of values. Great use case examples include video scrubbing, audio scrubbing, and digital book page scrubbing. In fact iOS, Android, and YouTube’s HTML5 video player leverage this pattern for these very use cases.
Below you will find example animated GIFs showcasing variable scrubbing speed implementations. The specific examples are of the iOS Music App, Android’s YouTube App, and YouTube’s HTML5 video player (which at the time of this writing is only supported on desktop). The visual treatment between each implementation varies as does its discoverability.
Image Credit: Jeff Benjamin
Good – The discoverability is ok as it leverages textual labels indicating speed.
Bad – The labels are often hidden by the user’s finger making discoverability less effective.
Good – The fact that it is implemented?
Bad – There is not a single visual identifier suggesting variable scrubbing speed (the fuzzy dot is a developer-only tool to show the touch and isn't native to the app). Poor design? Is Google running a UI test?
Good – Of the three examples, this has the best discoverability by leveraging both animated arrows and subtle track height animation as vertical movement is made.
Bad - Once engaged, it is the heaviest implementation from a visual standpoint (some may enjoy this however).
The core goal of my implementation is for it to be visually minimal but not so minimal that the functionality is not discoverable. The final implementation is a blend of my own thoughts and what I find successful in the examples above. I have a few improvement ideas too, but these will only see the light of day if there is feedback and interest in my particular solution. Here are two examples:
Good – The visual treatment is minimal and the discoverability I feel is on par with the YouTube HTML5 example above. On mobile however, the user’s touch may hide the arrow. As a result, the speed-overlay starts out at 10% opacity to act as a secondary cue. The speed-overlay increases its opacity too as the user drags vertically providing subtle visual feedback with each input change.
Bad – I’m not convinced that the speed-overlay is ideal in all situations as it may compete with or obstruct other in-frame content. iOS’s Music App implementation doesn’t have any indication where the user can actually drag to affect scrubbing speed, and this speed-overlay is my current approach to remedy this.
I'm releasing ScrubbingSpeed.js before it is perfect to garner input. I still have some improvement thoughts however:
You can view the source and usage breakdown on Github.Github - ScrubbingSpeed.js
Overall, I think there is plenty of room for improvement in all implementations. Ideally a platform agnostic solution will arise and become standard. We are not there yet. ScrubbingSpeed.js is an attempt at finding a better middle ground between visual minimalism and discoverability. My hope of going the open source route is to encourage a jump-off point for other interaction designers and interactive developers.
If you have improvement ideas or any other thoughts, just reach out on Twitter @derekknox or email me derek [at] derekknox.com.