Autoplay video on mobile web is coming. Is that good or bad?
At long last, true autoplay video on mobile web has arrived. Apple has announced that Webkit, the open source web browser engine that powers the iOS Safari browser, will support autoplay and inline video in iOS 10. Google has also announced that Chrome for Android 53 will support mobile web autoplay video.
What’s changing and why do I care?
This is a very big deal and could profoundly change the entire mobile web browsing experience as we know it. In all previous versions of iOS, watching videos from the browser meant two things:
- Videos required a user gesture to initiate playback — like a tap.
- Videos would automatically jump into the iOS native player and run full-screen.
To illustrate the current experience of watching video on iOS 9 in Safari, let’s take a look at a real life example.
Below is a screenshot from the The Verge’s video section:
To play the video I have to tap the player to signal my intent to play the video. Easy enough. *Taps*
After I tap, we jump into the full-screen iOS video player and it plays a video ad (more on video ads later). I wait patiently for the ad to conclude and eventually we move to content:
Video playback is handled completely outside of the browser and within the iOS native player. I would not call this a poor user experience for watching video. I tap a video. I watch it. It works. If it ain’t broke, don’t fix it, right?
Wrong. The internet has changed drastically in the years since the first iteration of iOS was released. Web developers are now using video outside of our traditional mental models to create new captivating and engaging visual experiences.
Let’s look at three new ways that autoplay and inline video are currently used on desktop web and how they will affect our mobile web browsing experience moving forward:
- The .gif is dying and the GIF is born.
Sometimes text-based communication doesn’t paint a vivid enough picture on the canvas of our minds — at least not in the same way an animated series of images could. Our emotions and expressions are too damn special for simple words! I can sit here and tell you that I find mobile web autoplay video extremely interesting, or I can show you:
Whether you like it or not, GIFs on the Internet are a thing. A very very big thing. The problem is that they kind of suck. This is of course a relative comparison of them sucking to the alternatives available, one of which is video.
If you try to save the .gif above you will notice that is the same ol’ GIF that’s been around since the dancing baby you put up on your first GeoCities website:
But there’s a big difference between intrigued James Van Der Beek and the dancing baby. The baby is not a .gif but a video. (Well, actually it looks like Medium uses a service to turn Giphy HTML5 video links back into GIFs. You can check out the video version of the gif here if you’re on desktop. But let’s pretend that it is so I can make my point)
Why would you want to use video instead of a gif you ask?
The baby is less than half the size of Mr. Van Der Beek and nearly four times as long. The benefit of using video over GIFs is clear from a pure resources point of view. Less size = faster loading = happy mobile user. This is actually the main “motivation” cited on the Webkit blog post for why they are allowing autoplay and inline video. See excerpt below:
We’ve found that GIFs can be up to twelve times as expensive in bandwidth and twice as expensive in energy use.
But in a world of no inline or autoplay video, that same dancing baby will not dance until you tap it (press play). This is certainly not an acceptable form of the automatically looping GIF that we know and love. So rest assured, that baby will dance all night long in it’s pure and compressed video form when iOS 10 and Chrome 53 for Android roll out.
Does this mean GIFs are going to die?! Yes, they most likely will — just like the floppy drive, CD player, and wired headphones (soon). Apple will be the main cause of death for the GIF once and for all.
The final nail in the coffin is Apple’s addition to inline video playback within the Messages app in iOS 10. If I sent the dancing baby video to myself today, I have to click to play it. In iOS 10, that video will play automatically.
But don’t worry, this doesn’t mean GIFs will actually die. The GIF has transcended beyond a mere file type into an eponymously named concept that is invulnerable to even Apple’s seemingly endless power over technology. So the GIF will live on and the .gif will die. Which is good news, because saying GIF is so much easier than “HTML5-enabled looping video asset”.
2. Web developers use video to create beautiful web experiences.
For the past couple of years, full-page video backgrounds have been the guilty pleasure of choice for corporate and startup marketing sites. Even our company is guilty of this pleasure not once, but twice. And why shouldn’t we? It looks awesome! It is an easy way to deliver a visually engaging and impactful message and overall mood to any previously static site.
But when it comes time to replicating this wondrous ocular perception of motion on a mobile device, our options are severely limited. Without autoplay mobile video, we are left in the boring and stale world of solid colors, gradients and images.
Developers often times do find clever ways to hack together designs that incorporate video on mobile, but it’s usually in an undesirable and resource-intensive way. Let’s take a look at what Google had to say about it in their Chrome 53 autoplay video blog post:
Disabling autoplay had the unintended effect of driving developers to alternatives such as animated GIFs, as well as <canvas> and <img> hacks. These techniques are much worse than optimized video in terms of power consumption, performance, bandwidth requirements, data cost and memory usage
In addition to our previous explored area of GIFs, they mention other common methods that developers use to workaround the constrictive nature of mobile browser video handling. Using these “hacks” cause performance issues on the user’s device and lead to a poor overall user experience.
Are you starting to see a theme here? Humans like pretty moving pictures. Ever since the Lumière brothers first blew our minds with their witchcraft, video has captivated us. If you try to take it away from us we will just figure out clever ways to bring it back into our lives.
3. Users everywhere are multi-tasking like never before.
Are you listening to music while reading this? Maybe you have the TV on in the background? I’m personally guilty on a nightly basis of watching TV with a laptop in my lap and a phone in my hand. We have screens on screens on screens — and we like it.
You may have noticed the rising trend of “sticky” video players popping up all over the place on desktop web. If you are reading this on a laptop or desktop computer, you can see an example if you visit this link to CNN. The player will snap to the top-right corner of the page if you scroll it out of view while it is playing.
This is a two-way benefit for you and CNN. Good for you because you can read the article and listen to or watch the video simultaneously. Good for CNN because then they can go to their advertisers and claim that they have 100% viewability for all of their ads.
YouTube popularized this form of multi-tasking when they rolled out their collapsible video feature a few years ago. As I’m sure 99% of you reading this know, this is the feature where you swipe down to make a video float to the corner and still play while you search and browse for your next video.
Wouldn’t it be nice if we had this experience on the web? Well now it is possible with Safari’s new rules regarding inline video. Since the video is not restricted to the full-screen native player of doom, it can now be placed anywhere on the page. So expect to see many more “watch and browse” mobile video experiences in the near future.
So is this a good thing or bad thing?
The three use cases above certainly do not cover all the ways developers are using or will use video in a mobile web environment. I find a new and clever uses of video to create motion and visuals online almost every single day. But Apple and Google lifting their autoplay and inline restrictions opens up a whole new playing field for web designers and developers.
But as the extremely overused and cliché saying goes that I’m going to use because I’m not that clever — with great power comes great responsibility. I believe there was a very good reason for Apple and Google not letting us play with all the toys. It’s because they know once they unlock the toy chest we are going to raise all kinds of hell shooting the neighbor’s dog with nerf guns and lighting firecrackers in the basement.
Abuse of autoplay video is inevitable. I am most concerned in the area of video advertisements. Publishers will now have an opportunity to create massive amounts of mobile web video supply (ad views to those normal folk out there) to sell to advertisers. Luckily for the users, one of the rules established by Apple and Google is that the audio track must be either non-existent or disabled in order for the video to autoplay. This means that ads will not be automatically blasting sound while you cruise around mobile web. But with user opt-in no longer a requirement for the video itself, we will inevitably have video ads shoved down our throat left and right.
This could lead to some interesting outcomes:
The use of ad blockers could sky rocket.
This is already a huge issue in the online advertising world, and creating poor ad experiences will just further perpetuate the problem. This will cut down on the number of monetizeable ad opportunities for publishers.
Mobile Web video advertising demand could plummet.
I got a C in economics in high school but even I know that an increase in supply leads to a decrease in price. With more supply available, it’s value will fall. Although this problem could be alleviated by the increased amount of more desirable viewable video supply that publishers will be able to create using new mobile “sticky” players.
Client-side ad mediation could cause slower load times
Right now most mobile web video advertising decisioning happens by sending data about you and your browsing environment to a server and that server either does or does not return an ad based on that data. With mobile web video being injected with autoplay rocket fuel, more advertisers may push for client-side advertising to measure a rapidly increasing supply pool using their own tech. Mobile web client-side mediation (VPAID JS tags for my advertising brethren) gives them much more control over the player environment and allows them to measure viewability and determine whether they want to serve an ad to you themselves.
This is a problem because one of the largest pains of desktop video ad serving is client-side mediation. Everyone reading this has most certainly experienced this issue whether they knew it was happening or not. When a video takes a long time to load most users believe it is because of their slow internet connection, but usually it is an ad player taking all that time to look for an ad. This is because a lot of the ad decisioning is handled in your browser or “client”, hence “client-side” mediation.
I could go on and on about this subject (I do work at a video tech company after all) but that is for another post.
I believe that the first year of mobile web with autoplay may be a rocky one, but we will eventually hit our stride. We will see it awkwardly used when it shouldn’t be and thrown in our face when we don’t want it, but I believe good shall triumph evil. We will all come together and collectively determine what an acceptable mobile web video experience looks like.
Autoplay video on mobile web will immediately open up a new dimension of user experience only before accessible in a native in app environment. So I think this is good. Very good.
