12

I have the opportunity to customize a video player for an iOS/Android mobile app and am considering omitting the '<<' (rewind/skip prev) and '>>' (fast forward/skip next) controls.

My thought is these are redundant legacy features from when VCRs and the like didn't have a scrubbable time bar for the user to rewind and fast forward. Furthermore, the majority of the video content in this app are one-off videos and not part of a playlist so prev/next video isn't useful functionality.

My question is whether or not this would be bad practice as it's breaking user expectation and may be slightly disorienting. Also if there are any accessibility concerns or other unforeseen issues to this approach.

Thanks!

  • Please provide minimal supported screen size and usual video length. – Basilevs May 2 '15 at 3:54
15

It would not be inappropriate to remove a dedicated fast forward (FF) or rewind (RW) button from a digital video UI.

What are they designed for?

FF and RW buttons were designed to move quickly through physical tape media. In the case of the image below a cassette tape, but they showed up on media before this.

enter image description here

There was no practical way to move forward or back through the media otherwise, unless you were playing the tape. The functions were meaningful and practical for the medium.

Duplication of functionality.

Duplication of functionality is not always bad, but it is only really good when necessary - safety concerns being a good example. Digital video players almost always show a progress bar - which also tells you how long the video in full is.

Take YouTube's interface:

enter image description here

The progress bar (a single UI element) does the work of many things:

  • Current time
  • Total time
  • Fast forward
  • Rewind
  • Jump to specific location

FF and RW are accomplished through the action of dragging the "current position" widget. Alternatively the user is able to jump to a specific location by clicking somewhere on the progress bar itself. All of these functions are not possible in tape media, where FF/RW buttons make sense, due to physical constraints.

There is no need to add another method to accomplish what the progress bar already does.

Evolution of UX

What has happened is not the "removal" of the FF or RW buttons, but the evolution of them into the progress bar. The digital interface (computer or touch screen) combined with the capabilities of the digital media (total time available, instant skipping, others) has made it unnecessary to move through the media in a sequential way. The progress bar is FF and RW, for the media at hand.

Precedence

Concerns about if users would miss a FF or RW button should quickly dissipate with a fast review of other media players available to them. Take YouTube, pictured above, on the desktop or any of the following examples taken from my iPhone:

YouTube:

enter image description here

Netflix:

enter image description here

Notice the lack of a RW button, but there is a 10-second skip-back button. Ideal for when you are watching something a didn't quite catch that last bit of dialog. Instead of forcing the user to move the progress bar, or guess by hitting a generic RW button, Netflix has wisely added a simply one touch for quickly jumping back.

Video (Apple's default video player):

enter image description here

All have removed the FF and RW buttons in favor of the much more versatile progress bar. It is highly unlikely you're users would have a difficult time transitioning away from using the FF/RW buttons on your app (if they even still do).

Accessibility

This depends some on how you implement it, but generally speaking a progress bar should be no less accessible than dedicated buttons.

All mobile OS's have recommended button sizes. They normally range from 5-9mm, give or take, depending on the purpose of the button. The hit space supplied to the progress bar's "current position" should be at least as big, and could easily be larger since your app likely does not have many other controls floating around that the user might otherwise accidentally hit. The added length of the progress bar also provides additional space for grabbing.

If your concern about accessibility comes from physical constraints of your user population (age, arthritis, etc.) than how you implement the progress bar can also change. One thought, make dragging left/right on the video move the progress bar too - not just dragging on the progress bar.

Dedicated buttons could easily be argued as less accessible as well.

  • Dedicated FF/RW buttons have a set speed. I control the speed when I drag the progress bar.
  • That set speed might be too fast, or too slow for me.
  • How do I stop the FF/RW action with dedicated buttons? If I'm dragging, I just stop dragging.
  • Narrowing in on the expect point I want to be can require multiple FF/RW button presses. Dragging a little before is easy to do.
  • Thanks for the awesome answer! Any insight into the accessibility part of the question? I.e. do screen readers handle a time scrubber well enough to omit dedicated RW/FF interface elements? This application has to pass compliance. – Danny F. May 1 '15 at 21:01
  • @DannyForst - I've updated my answer. – Evil Closet Monkey May 1 '15 at 21:15
  • 3
    The Apple video player isn't really a good example... the prev/next buttons at the bottom are as obsolete as ff/rewind because you never know what will happen if you press those (they always appear even if there's only a single video on the webpage). – user42730 May 2 '15 at 0:34
  • 2
    Thanks for mentioning the "skip-back" button. A lot of players insist on keeping the rewind/forward buttons which are much less useful today, and very few add buttons to jump forward or backward a few seconds. – Manu May 6 '15 at 12:26
  • 3
    Also note that for very long audio or video, the progress bar becomes hard to use. See how youtube does it on 10-hours videos: you get a "zoomed in" view of the bar around your cursor. – Manu May 6 '15 at 12:28
3

On a large screen, progress bar does indeed provide FF and RW functionality.

This is not true for mobile devices with small touch screens - it is very hard to achieve accuracy better then 10% if video player is used in portrait mode using a finger and a progress bar. For longer videos (longer than half an hour) on such devices progress bar is nothing more than a source of anxiety.

I'd recommend to test your progress bar on the screen of minimal supported size an longest probable video and see, if it is usable enough.

1

In regards to the specifics of video playback, regardless as to whether or not there is something "before" my current playback, the "<<" is what I look for to instantly rewind to the beginning. And if the ">>" has no meaning, then don't include it.


MOST IMPORTANTLY: If the GUI element will never be used, then it's MORE disorienting to the user to have them presented to him.

Otherwise, whenever I'm faced with a question of the following form:

Should I include GUI controls that will only once in a while be used?

I start thinking in terms of supplying two modes, an advanced GUI and a more stripped down one. This can be done in multitude of ways, the easiest is a smaller-than-normal button which simply adds other buttons to the control.

Note though: This is not meant to hide functionality that makes no sense. Instead, think of it as a decluttering tool.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.