-
-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help users avoid breaking the Web for themselves #2021
Comments
About a fifth of all user reports contain one or more user-blocked domains. So that's the ceiling on self-inflicted breakage. If you look at the top user-blocked domains (above), we do want quite a few of them blocked while blocking certain other domains is likely to break page contents. For example, while reports where the user chose to block |
I have a suggestion for stopping people from clicking on sliders randomly in an attempt to solve their problem- perhaps they could be categorized by something a non-developer might recognize as friendly? Privacy Badger the software clearly already has code that knows that something is a font or a non-tracking Javascript library. A developer would also likely make the right eyeball call by url ID alone, but a non-developer wouldn't. GUI header categories that show up in the existing popup on the same header level as "The domains below don't appear to be tracking you", but labeled "Fonts", "Extra Site Content", "Trackers", and "Unknown" seem like they might go a long way, but still provide transparency (and block-ability if totally necessary) If this is useful I can build and submit a PR for it. |
Reworking how we display domains to the user is not a bad idea! As I wrote above, a list of raw domains is "TMI" for most people. My concern has to do with how much work reworking the UI entails as compared to other tweaks we could try in order to help people avoid breaking the Web for themselves. Remember that ultimately the list of domains is a power user feature, not meant for the majority of Privacy Badger users. Splitting the list into categories should help, but so should hiding the sliders by default, for example. We should also consider the users who already chose to block all these known-to-break-stuff domains. |
Ok so we could:
|
I like these ideas! I suggest breaking them down into as many independent improvements as possible. We don't need to figure out how to hide sliders and do domain categorization at the same time. By the way, between these two, slider hiding seems like a stronger mix of impact/implementation difficulty. Thoughts on hiding sliders:
|
I don't think the current UI (a) shows whether the slider has been manually adjusted or (b) gives a way to reset it to Privacy Badger's recommendation, which seems important. Imagine a user had manually set |
|
I've worked on some mockups based on this issue and some usage for a while on my end. I've read a number of comments about reducing the obviousness of the domains. I think this is a good way to go, requiring users to take an additional step to engage with advanced settings. I've also been working on an overhaul of the UI to address the look and feel. I'd like to submit a PR if others think this will help address some of the UX issues above. I've not done any work on some other comments like categorizing, returning control of trackers etc. |
@cwattrus, these are beautiful!! |
Displaying a warning after a user blocks a domain that is known to break some pages might help because users will be aware of the fact that they probably broke it by blocking the domain. |
@cwattrus Thank you for the mockup! I think this is on the right track. I'm on leave with limited availability; sorry I can't provide more detailed feedback at this time ... Here are some first thoughts though: Can we break up the changes into smaller pieces/several stages? The mockup changes (rearranges) a bunch of functionality not all of which is slider-related ... What's the smallest set of changes we can make to address the biggest problem in this issue? We could follow up this first stage with further improvements (such as design fixes). I just think breaking up and minimizing the changesets will maximize our chances of shipping fixes. Perhaps we should open a new issue (or PR, but I don't advise writing code just yet) to continue discussing your proposal. Thanks again! |
@ghostwords, thanks for the response. I'm happy to do whatever is easiest for you. I do think it's best to get started with code. It's easy to get stuck discussing intangibles when it comes to UX. I'll see if I can break out a small impactful change and make a PR. To get familiar with the code and concepts I've worked on reworking the UI on the options pages and will submit a PR for that in the week. |
I opened #2359 to hide the "domains below don't appear to be tracking you" section in the popup by default for new Privacy Badger users. This should help new users break less of their Web experience by accident. |
This comment has been minimized.
This comment has been minimized.
We have to remember that it should be as simple as possible, without removing the more complex functionality that advanced users desire. Far too often I see older family members unintentionally breaking their web experience because of privacy badger or other plugins. @cwattrus mockups are great and I think they are a huge step in the right direction. BUT I showed the improved mockups to someone non technical and their immediate piece of feedback was "what does the orange cookie looking middle icon do?" They got red and green, but what is Yellow, perhaps it could be visualised better? |
Hi @pseacrest, take a look at the various PRs shown above your comment to see the progress we've been making. The biggest recent change was collapsing the slider list by default as of Privacy Badger version 2021.6.8. The sliders aren't really meant to be used by most users. What's important is a summary of what happened on the page and the "Disable for this site" button. Our next step is to re-evaluate how big of a problem this remains by reviewing user error report statistics. Let me know if you have feedback regarding our latest UI or thoughts regarding what else we could do to help users avoid inadvertently breaking the Web for themselves. |
Now that we fixed submitting user-set sliders with error reports in #2001, we regularly get error reports where the page is broken because of a domain the user manually told Privacy Badger to block. One such domain is
ajax.googleapis.com
, a CDN used to deliver popular JavaScript libraries.We want Privacy Badger to be an install-and-forget, no-configuration necessary tool. We still prominently show sliders in the popup, however. Regardless of what we say above the sliders, users see them and think, "aha! let's block everything, better safe than sorry."
We are going to want to rework the popup to make it more helpful to more people. A list of domains is TMI for most users. Redesigning the popup is complicated though. Are there any simple tweaks we could make to help users avoid breaking the Web for themselves?
We could see if the user has any user-blocked domains on the page they clicked to file a broken site report on. We could then show a message warning them that the page may be broken because of their customizations.
We could show a warning icon next to (or otherwise highlight) yellowlisted domains the user marked for blocking. The yellowlist here would act as proxy for a list of domains known to break websites (the yellowlist is probably good enough to start with).
Any other ideas?
This issue will probably take several related enhancements to resolve. I suggest opening a separate PR for each distinct improvement.
Some example reports:
Site-specific CDNs:
Content CDNs:
Shopify:
JavaScript CDNs:
Top user-blocked domains in error reports so far:
The text was updated successfully, but these errors were encountered: