Predictable in a user application is the same result from the same action every time. UX changing based on opaque logic and heuristics is anything but predictable.
My bet is that they did this to not break Youtube. I mean it makes sense (you don't want video sites to not work) but it's also such a hacky sort of thing
I don't get why they couldn't make this a permission thing like a mic. Ask the website to allow autoplay.
Which is fine to me. If I go to a website specifically for videos, I want it to autoplay, having to press play is a pointless action.
If I go to a website to read articles, I do not want autoplay, and I definitely don't want the video to even follow me around as a tiny minimized window when I scroll down and yes I will close the tab or press back pretty quick if that happens (as I come to the realization the effort to read this article is not worth the gain and realize that I probably was procrastinating anyway to end up on that article in the first place so should do something more productive). If it's interesting enough I will play the video myself, preferably with full control of its time slider myself and preferably without it auto-starting an unrelated different video after this one was done.
Allow location access? Y/N
Allow autoplay? Y/N
Safe this password? Y/N
Translate website? Y/N
This website uses cookies. OK
Do you want our newsletter? NO
Yeah, I don't know either. Adding to that list sounds like a great idea.
...because then it's not autoplay anymore?
Which then becomes yet another reason to use the sign in feature, and yet another reason to stay with the same browser brand.
(hope kids still remember clippy)
In my experience, "learning" and "predictable" do not go together.
They probably don't want to break websites (as autoplay has no permissions model), but breaking the most annoying feature on the web right now is a good thing.
Then, you can enable sound manually for each site in the site settings panel.
But "fi<enter>" never launches Firefox anymore because of that one time you accidentally launched Finder instead. And since you keep accidentally launching Finder that way, it never learns that you want Firefox.
So you try "f<enter>" but you accidentally launch Flux. And because you keep forgetting it thinks "f" = Flux, it always launches Flux.
So you have to use "fir<enter>" to launch Firefox. But "fire<enter>" somehow launches Firewatch, a game you forgot you had installed on your laptop.
It's the most obnoxious system ever where each additional keystroke reorders the entire fuzzy result list in the name of "learning." It really is the opposite of predictable.
Nevertheless, they don't let themselves be caught up by this minor obstacle and use whatever random reward function they can implement with the data they have.
The resulting system won't actually learn to solve the original problem - but it will learn something, so, hey, it's self-improving!
See also: Probably every single recommender system in use. (At least that's my subjective impression)
For me (and relevant to TFA) this is what is often missing from such learning engines; an option to manually intervene when necessary. It's hubris to assume that the heuristics will always get it right, and I would have to imagine there's valuable data in seeing what manual corrections a User makes, so I'm not sure why it's not included more. A .conf file, the "add/remove" weight as mentioned before, just some way for the user to correct the heuristics when they get it wrong. And they will get it wrong, and frequently do.
I pretty much continue to install Adblock so I can kill the auto-play elements on websites that just should not autoplay.
> predictable
What could possibly be more predictable than disabling autoplay altogether?
Google says it enabled autoplay for 'over 1000 sites', but we all know Google only cares about one thing and that is playing more ads on YouTube.
(for the record, at least half the time I open a youtube video I don't want it to play immediately)
It would be much nicer if the various plugins I use to control that behaviour wouldn't stop working every 4 months due to another youtube redesign (whether in UI or Backend on the Client).
Since voice isn't counted as a "gesture" the user can't say "play" to start a a video.
It's not just autoplay it's any sort of dynamic (js initiated) playing of media.
https://chrome.google.com/webstore/detail/lipsurf/lnnmjmalak...
I added an ugly workaround, a slide to the tutorial that asks users to go into their flags and allow autoplay without any gestures. Chrome extensions should have better privileges for playing videos, fullscreening etc. IMO but it all needs to be hacked around limiting extensions.
I also don’t like how quick google is to make such unilateral changes and just boom there they are in production on the web. Good luck Keeping your site browser agnostic. The but ticket for this feature even advised that site developers check to see if the browser is chrome first and then do different logic. What a mess.
I like Inbox's recent behaviour that explains why it deems a particular email important - it would be good if this sort of explanation was more prevalent with publicly-available ML systems.
Looking a little further, it appears to be a ProtocolBuffer file, but would a bit of documentation hurt?
There’s no browser api that tells you if autoplay is supported, and you won’t get meaningful errors when you try to autoplay when you can’t.
Ultimately the right solution is to just-don’t-autoplay-ever, but it’s a hard sell when you see a 20-40% drop in VOD begins when you remove autoplay.
I’m not sure how to even approach Chrome deciding to autoplay “sometimes”. You have to tell the video player to autoplay a video a.m3u8, but swap that out for preroll.m3u8 before you know if any of it is going to work at all. If it fails, you’re gonna see weird errors in IMA3, or at the video player level, none of which really help you decide how to gracefully handle the situation.
So yeah, if you have client-side preroll, just don’t autoplay I guess.
Which tells me that with autoplay enabled, 20-40% of people are probably clicking 'stop' just after the video starts playing, so aren't watching your content anyway.
What about disabling autoplay even without sound? Unwanted autoplay videos burn through battery even while muted.
Now a lot of "GIFs" aren't in GIF format, they're videos with no sound, and that makes a lot of sense because it's 2018 and we've learned some things about compression and video since 1987.
If silent videos didn't autoplay consistently, people would keep using actual GIFs, using way more bandwidth for the same purpose.
chrome://flags/#autoplay-policy
> Alas, this flag only prevents video that has sound from auto-playing. It’s the inadequate option that my earlier comment was referring to.
>
> Here’s more: https://www.chromium.org/audio-video/autoplay
> https://developers.google.com/web/updates/2017/09/autoplay-p...
>
> Quoting the blog post, Google’s decision that ”Muted autoplay is always allowed” is the problem. If any other Chrome users wondered why videos now auto-play without sound (even with this option set), at least based on the relatively minimal docs about this flag, this is why.
Set the flag to "Document user activation is required", restarted browser, went to youtube, videos autoplay
Ditching Chrome is another excellent and recommended option.
If google want this on-by-default on youtube, I wouldn't mind. As an upside, this would make it obvious they favor their own product.
My autoplay desires are pretty simple. If the site's Youtube, Vimeo, or another site that exists purely for video, I expect videos to autoplay. It'll annoy me anywhere else. I'd be fine with a whitelist. What I like the least about their new implementation is that the behavior of the browser will change on its own. I don't like my software trying to predict me or changing its behavior without an explicit command to do so.
I hate this shit just like I hate their ads program. Where're all the net neutrality proponents when the popular browser vendor is the offender?
I start by asking a user whether they want to view the experience in “Stereo Mode” or “Normal Mode”. Whatever they click on, I use that click event to start playing a 500ms long mp3 of silence. When that clip finishes, I use its ‘ended’ event to start it up again. Meanwhile in the render loop, if the user enters an area where I have some auto playing narration, I set a global flag and store the track name in a global variable. Those flags get picked up the next time the 500ms track finishes, and the named track is substituted in.
This is ridiculous, and this is just to play sound files at various points in time. I wouldn’t be surprised to find out that some of Cabbibo’s work uses multiple Audio Contexts or other complicating factors that would make it difficult to retrofit.
Given the impressive amount of work they put into the site, it's unfortunate a few lines of feature detection and polyfills weren't placed in there, because maybe then this could be a `sed -i /install google chrome/install Firefox/` fixup.
(I say that on the presumption that firefox is now able to handle the multimedia stuff which has been my personal experience with it, though not quite at the same level as the artist, just some pitch shifts and hand rolled synth stuff).
1: https://imgur.com/a/4rMgv7g 2: https://imgur.com/a/j90myrD
It's also annoying to have to do such a change to your art for a single browser.
Overall I think the artist's frustration is understandable, but I agree "destroyed" is perhaps too strong a word.
On the other hand I'm happy that ads can't easily play sounds. I do wish youtube had to play by the same rules.
But I think he’s also expressing doubt about creating art/work on the web in the future because of things like this.
Not good enough. I can't even disable autoplay using Chrome's configuration. It doesn't work... but it works on FireFox.
You can forego it by enabling end-to-end-encryption, but since they require a second password for that, the percentage of Chrome Sync users who use this, is probably close to 0%.
Unfortunately this does nothing for moving images (moving ads).
Youtube probably is not on the blocklist, but it will add youtube to your personal blocklist if you always pause the videos.
What? How is that an accurate summary? The whole post is about how Chrome will learn your preference for whether to autoplay on domains, not about how it is whitelisting certain domains.
Imagine if someone makes a YouTube competitor. They won't have autoplay for an user's first 20 sessions at minimum! That's significant
Instead I had a sort of loss aversion based reaction where I think now some things will autoplay that didn't before, but in fact fewer things will autoplay full stop.
Do they see through Google Analytics or do they send my behavior to their servers when I am using Chrome?
I'm surprised Google's documentation is not designed with readability in mind.
How would they know that without tracking and centrally recording your autoplay actions in Chrome?
(Unfortunately, the PulseAudio volume control doesn't show Chrome in its "applications" tab before it has played a sound.)
What am I missing?
Wolf only does this by learning sheep' preferences.
Of course keeping sheeps happy is wolf's first priority.
“We just want to learn everything about you, collect all your data and watch everything you do”
But what part of "No, never" does Google not understand?
Nuke Chrome, Android, Youtube, and Web search.
