Live data from Hacker News

Google show signs of reconsidering auto mute after developer critique

bugs.chromium.org

51–56 of 56 posts

Re: Google show signs of reconsidering auto mute after developer critique

#51

Earlier quoted context omitted.

>Yeah, clearly they read the dialogue if by adding more dialogue you change their action. No, because with our first-stage dialog we can just keep showing it until they click yes, but with the native dialog we only get one chance, and if they click "no" we might not even get a callback that they clicked anything at all on some browsers (which I honestly kind of like from a privacy standpoint). But to be clear, i'm no…

So are you saying that you don't allow them to say no to the first-stage, and have it pop up immediately after, or that you pop it up every time they open the app? I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using. I know that in context it makes sense, but people read things and don't think about them…

>So are you saying that you don't allow them to say no to the first-stage, and have it pop up immediately after, or that you pop it up every time they open the app?

Basically we lock them from going further in the app by repeatedly showing the dialog immediately after a "no" answer, because at that point they need to scan barcodes and if they can't then the entire app is completely useless anyway.

>I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.

It just feels like it to me. We found it difficult to explain how you MUST say "yes" to the next prompt, it's for barcode scanning (which explaining this alone feels condescending, the app is called "x barcode scanning" FFS), the app cannot function without it. Just asking to ask alone feels wrong. I want my applications to be as easy to use and straightforward as possible, and doing stuff "automatically" rather than making the user manually do it is like 40% of my job, so it feels really wrong when I need to make it worse in that way.

>Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable?

Yeah it's the native one, so you can't change what it says.

It's tough, i can understand not wanting to allow websites to spam notifications constantly, but the "you only get one chance" really sucks.

Re: Google show signs of reconsidering auto mute after developer critique

#52
post #25

Earlier quoted context omitted.

Those are both already horrible UXs that are abused in the same way the "subscribe to our newsletter" is. I won't ever do any of those three for 99.9% of websites I visit, and yet 70% are requesting it. They've become user-hostile ways to give websites a way to force interaction from me that I don't ever want, and if I did I could chose the option in the account preferences (if I cared enough to make one).

The way that browsers typically handle this though is that your interaction isn't blocked by the prompt. There's a default state ('disallow'), the website can ask you for permission, and you can choose to either: 1. Allow 2. Deny 3. Do nothing at all The website then must take all three into consideration so your experience isn't ruined as a result of a blocking-state. I agree that the permissions system isn't ideal,…

Its not about being blocked from continuing, it's about having to answer questions (or click away the dialogues) to peruse content.

And the "subscribe to our newsletter" overlay often does block progress without hunting for the often obfuscated "no thanks" link.

Re: Google show signs of reconsidering auto mute after developer critique

#53
post #5

Usually when a major web browser decides to do something that has the potential to break existing websites they do extensive testing and put the call out for dev feedback before they release. Why didn't that happen here? Also it's odd that Chrome decided to explicitly whitelist some sites. Surely that's an admission that their automated workflow doesn't actually work well?

Why didn't that happen here?

Chrome has long been the means for expressing "Google knows best" and leaving us to pick up the pieces. It's entirely predictable behavior that they're narrowing another aspect of expected solicitation of feedback before acting.

Re: Google show signs of reconsidering auto mute after developer critique

#54

It might be just me, but I cannot (for the life me) understand what the issue is here. Maybe it's because I'm not a mobile game developer or content creator where audio and video is my life. I think people like me would benefit with an actual side-by-side demonstration of what the issue is now vs the resolution the author is proposing.

This new Chrome "feature" mutes audio from many browser games and interactive audiovisual websites, offering no indication that audio is muted, and no way for the user to restore the audio.

By trying to silence autoplaying video ads, they have thrown the baby out with the bathwater (except for certain specially whitelisted domains, like youtube).

Re: Google show signs of reconsidering auto mute after developer critique

#55
post #11

I’ll immediately switch to using any browser that blocks auto play by default on all websites without exception.

Firefox -> about:config -> media.autoplay.enabled -> false Edit: troydavis points out this Chrome option doesn't actually block autoplay: Chrome -> chrome://flags/#autoplay-policy -> Document user activation is required

Doesn’t seem to work on mobile (iOS)? Desktop is already sorted with noscript or uMatrix.

I use Firefox focus on mobile for news sites since it blocks most video and othe trash, but the lack of tabs and bookmarks is an issue.

Post reply on HN