Interfacing with Video on Mobile Browsers

Video on mobile web browsers

Whether you’re watching an episode of your favorite TV show, or wanting to see your best friend’s kid, cat, or dog roll around on the floor, videos are a significant part of browsing the web. With the growing availability of portable devices that conveniently fit into palms, pockets, and bags, you are are more likely than ever to view video on a smartphone or tablet. With millions of apps available on the marketplace, how are you going to watch the video – in an application or in the device’s mobile web browser? According to the Nielsen 2013 Consumer Mobile Report, videos are being watched in mobile browsers just as frequently as in applications in developed markets.

This poses a usability predicament because the default players found in mobile web browsers lack nearly all of the features that connect viewers to both other content and other viewers. They also strip potential revenue streams for the content providers.

Consider that 18% of the web runs on WordPress. Even if videos on these sites are built using an HTML5 <video> tag, video on a mobile device will either default to a featureless native player or worse, a player that does not recognize events from touch screens. This lack of usability undermines the core goal that the viewer set out to do, watch videos!

Fortunately, there is a solution to providing viewers with a usable experience that is similar to a desktop or native application: use an HTML5 video player that provides features beyond the basic <video> tag.

Getting the most out of your <video>

An HTML5 video player is necessary to get the most out of a mobile browser. It has features that were once only available to traditional desktop players or in customized native apps. Viewers gain a similar experience across Android and iOS without being forced to download a separate app.

While apps can make it easy to access branded content, a viewer should not be forced to download one application per content provider. Video players that work within the mobile browser should therefore have the same features as the native app or desktop browser. The option to view on a mobile-optimized site ensures that most viewers are able to access content.

The following UI/UX interactions can be built into an HTML5 video player:

  1. Respond and Adapt
  2. Touch controls
  3. Customized skinning
  4. Monetization control
  5. Fullscreen playback

Respond and Adapt

Just because an HTML5 player allows a video to work on a mobile device does not mean it provides a quality experience for viewers. A player must be designed to handle multiple device sizes and respond to the width of any screen. When viewing on a phone or tablet the player will grow or shrink to the width that fits the architecture of a responsive site. The player should also adapt to the available bandwidth when downloading or streaming a media file. Here are some other items to keep in mind.

responsive design preview

  • The original aspect ratio of the video should be retained as the player expands or contracts.
  • Captions and subtitle text tracks should resize.
  • Video controls should remain at a usable size and should not become so small that they cannot be touched. Some controls can also be hidden on smaller screens.
  • Multiple video qualities should be provided to account for varying levels of bandwidth. The player will pick the best source to get the content into the viewer’s hands.

Friendly Touch

Touch is the main way users interact with the majority of mobile devices that support video playback. Because of this, the controls need to be clear and can easily interact with touch events. Traditional mouseclick interactions do not transfer one-to-one on mobile. A click to begin playback followed by a mouse “hover over” of the video will show or hide controls on a desktop. This tactic does not work on a mobile touch interface. Instead, a tap should reveal controls rather than pausing the video. Additional features like playlists and related videos should respond to scrolling gestures.

Tips:

  • Interface elements can be put into “drawers” that are displayed via directional swipes, keeping the video as the main focus.
  • Make sure the touch event is registered over an area greater than just the button. This helps account for those of us with larger fingers.
  • Tooltips that appear on hover on desktop should appear after a tap event on mobile.
  • Convenient access to social apps is not yet available at the browser level. Links that are shared should come pre-highlighted for viewers to easily grab and share.

Customized skinning

No skin video on mobile browserNo custom skin
Custom skinned video on mobile browserCustom skin

A basic HTML5 <video> element comes with a set modifiable controls that are displayed differently depending on the browser. Though these controls do allow a viewer to ultimately play a video, a customized player does not have to rely on the these default controls and can be configured with HTML/CSS. All of these customizations will be retained on a video player in a mobile web browser. This helps to provide brand familiarity with viewers and further creates a unified experience between mobile and desktop. This goes for the controls and any logos that might be associated with the player.

Based on the images at left, which provides a better first impression to viewers while while browsing content on mobile?

Fullscreen Playback

fullscreen mobile web video

Fullscreen enhances the visual experience and increases viewer engagement. When a video goes fullscreen on a mobile browser, the browser’s chrome is still displayed. This can interrupt the viewer’s experience and fails to fully engulf the viewer in the video. One feature of iOS 7 has the browser chrome reducing size after a certain scroll point. This is already available in Google’s Chrome browser though it is not yet the most widely adopted browser for Android. A Javascript trick can be used to control the scroll location of the video when going fullscreen to automatically hide the browsers controls. This would allow all of the custom skinning to be retained. For now, as we wait for iOS 7 and Chrome to gain wider use, fullscreen can switch back to the native fullscreen player to provide uninterrupted viewing across the entire screen.

Monetization

It is worth noting that money spent on mobile video ads is projected to reach $4.14 billion in 2013, an increase of 41% as compared to 2012. Even though ads are seen as a hindrance to viewing content and may not be the most usable on mobile streams, there are ways for publishers to provide viewers with a better experience on smartphones and tablets.

On tablets where there is more real estate, ads can be positioned around the video and respond to any responsive design. HTML5 video players can also provide interface elements to skip a video ad. It’s worth noting that these won’t appear on the iPhone because video playback is automatically forced into fullscreen mode.

Even though there is no current API to disable the seek bar during video playback, there are some tricks that can be used. For Android and iOS tablets, video content owners can hide the seek bar outside of fullscreen because you control the display of the controls. This allows them to display additional information to a viewer, like how much longer the ad will be played. When a viewer goes into fullscreen while watching an ad, you are able to rewind to the point of furthest progression, which essentially disables the seeking. A much better approach would be an API that controls the visibility of the seek bar for these situations.

Conclusions

An HTML5 video player allows viewers to access video from anywhere they are connected to the internet. Just because consumers are opting to view video on mobile browsers does not mean that content owners and publishers need to sacrifice on features and usability. A robust player gives the viewer a reliable experience that remains consistent across any device. Your brand and your monetization will remain intact as the transition to mobile video consumption continues to bloom.