> If "insight" means "tracking", this sounds very user-friendly.
What about a slideshow which has a video of the speaker, and changes the slides for particular timestamps.
At the moment you'll have to detect the playback event and just hope that the video is playing back at the "correct" speed, and change the slides based on a JavaScript clock.
While that works most of the time, it isn't what I'd describe as reliable.
Alternatives exist, like making the slides part of the video too, but now text cannot be copied out, links cannot be clicked, and so on...
I am by no means experienced in this area, but a quick search of MDN showed the 'timeupdate' event[1]. Is that not sufficient for the usecase you gave? The timestamp itself is available through the 'currentTime' property[2] so you can always have that value as well.
In theory, yes, that’s how you’re supposed to do it. Unfortunately, part of the real world problem with switching to HTML5 media elements is that browsers have an awful track record in terms of quality of implementation. At various points, even quite basic events simply haven’t been firing properly in one browser or another. And with browsers updating every six weeks and frequently changing things like the default controls you get on a video element, you’re constantly aiming at unnecessarily moving targets as a developer.
Yep, here's an example - if you mouse down on the video thumb, and don't move the mouse nor release the mouse button (so basically you've held the thumb in place):
- Does the pause event fire?
- Does the seeking event fire? Or does it only fire when you move the mouse to drag the thumb to a new time?
- Does the seekend event fire? Does it fire every time you move the thumb to a new position without releasing the mouse button? Or does it only fire when you release the mouse button?
- Does the timeupdate event fire? Does it fire once? Or repeatedly for the same position where the thumb is?
Every browser has different answers.
As for the timeupdate event, it only fires once every 250ms, which is painfully slow for applications that need to synchronize something with the video (slides, subtitles, etc.)
And even if you decided to ignore all the events and write a requestAnimationFrame-powered loop to query only the changes in the currentTime property, there's a bug in Chrome on Android where the video.currentTime property becomes out-of-sync with the video if any long-running JS or complicated animation blocks the event loop for a few seconds - https://code.google.com/p/chromium/issues/detail?id=509010
> If "insight" means "tracking", this sounds very user-friendly.
I personally would like advertisers and content producers to know at which point it is that users tend to bail on watching their video, or will click through to the content. That might allow business users to receive useful feedback and actually optimize their funnel, instead of wasting my time with a shotgun, best guess approach.
It would be interesting to see Youtube's statistics on this, because for almost every case personally on my mobile devices and every case I've seen others deal with, that bail-out point is "as soon as possible" if the ad can be skipped.
It wouldn't be so bad, if they would show you more than one or two different ads. I remember Hulu being especially egregious about that. I'd watch a couple hours of the back catalog of some show, and see maybe 20-30 ads in their "commercial breaks", except it was always the same ad.
There are many cases where it’s much more user-friendly to have proper control over audio/video players and proper event handling: custom controls to change resolution/quality settings, synchronization of the audio or video with accompanying material, integration of video with other content, having interactions elsewhere on a page adjust audio or video to match, remembering which tutorials a user has finished so you can start with the next one ready to go next time, and that’s just what I came up with in a few seconds.
Sure, if you just want to play your free videos from a site where each page is basically just a wrapper around the video element, and you don’t need any configuration for quality settings and the like, then custom control and events might not be particularly interesting. However, HTML5 media elements should let us do much more than that.
What about a slideshow which has a video of the speaker, and changes the slides for particular timestamps.
At the moment you'll have to detect the playback event and just hope that the video is playing back at the "correct" speed, and change the slides based on a JavaScript clock.
While that works most of the time, it isn't what I'd describe as reliable.
Alternatives exist, like making the slides part of the video too, but now text cannot be copied out, links cannot be clicked, and so on...