-
-
Notifications
You must be signed in to change notification settings - Fork 174
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
Implement distinctive visual cues to warn of scripts that are known to break something. #342
Comments
Refer issue #330 |
I appreciate that you let me know that there was already a proposal almost identical to mine, but at least for the moment I am not going to close this thread since I still maintain the additional suggestion of modifying the color of the relevant script names to a "pastel red" (indian red, #CD5C5C), which would make it much more intuitive for users to perceive that they are selecting a script that involves a breaking change, rather than a warning symbol and aligned at the very end of the script name. Thank you very much for your collaboration! |
Thanks for your feedback @ElektroStudios, let's keep this separate from #300. We should have cues for script safety to prevent issues. Let's define how.. I will give you a bit context about how privacy.sexy works now. Its script can have two recommendation levels (Standard/Strict), or they'll not be recommended at all. Categories have no recommendations, this applies on scripts only. So scripts can have either of these three states:
I was playing different ideas:
These add visual cues on scripts. But how about the categories? How can we give feedback about whether an applying a category as a whole can be breaking or safe? It would be good to warn directly if a category has an unsafe script deep in its hiearchy somewhere. Would using circles with mixed colors make sense? Mixed-color circles to indicate a mix of script states within a category and uniform-color circles to reflect uniform script states within a category:
What do you think about this? Or can there be better solution? We have three challenges we need to solve:
If we can clarify this, I want to prioritize this and get it done in next feature release 0.14.0. @plantindesk, your recent contributions have been very valuable, and your input on this matter would be greatly appreciated ❤️. P.S: Visual Studio is solved in #327 thanks to @Cajunvoodoo and it will be released as part of the next patch. |
I don't understand why the category name "None" to represent the highest level of risk. Wouldn't something like "Critical" be more appropriate?. Maybe I just didn't understood what the "None" word is meaning in this context. In any case, if there are three levels of risk, that should translate into three levels of priority on the color of the circle. And the circle should highlight only the highest risk level selected in the scripts within that category. Mixing the colors in the same single circle is simply unnecessary, because by using a circle filled with the color that represents the script selection having the highest risk, it is already warning the end-user about the current risk, am I explaining correctly?. I don't find it useful to mix colors in the same single circle to warn of lower priorities too. That is my opinion. Then: If within a category a mix of "Standard", "Strict" and "None" scripts are selected, the color of the category circle should be red, since "None" has a higher priority / risk level over "Standard" and "Strict". Likewise, if only a mix of "Strict" and "None" scripts are selected within a category, the color of the category circle should be red (None has a higher priority/risk level over Strict). And if within a category a mix of "Standard" and "Strict" scripts are selected, the color of the circle should be yellow. Etc.
Honestly, I would prefer the color of the scripts with risk "None" to be highlighted in an Indian Red color under a dark theme. Once you have been able to categorize the scripts into the three states mentioned, meaning that by then you will have already implemented a mechanism that automatically each script has its risk level property defined, would it be too difficult to implement the color change, as an OPTIONAL feature available through checking/unchecking an "Appearance Peferences" option in the application settings?. In any case, continuing with the circles idea, I think that perhaps the freemium application NTLite could help or inspire you. In NTLite, instead of showing circles, the visual cues are simplified by coloring the left side of the checkboxes. This could be a good idea for Privacy.sexy too, although the drawing logic of the checkbox controls may have to be modified to carry out this customization. And regarding how the color is decided for each checkbox, in NTLite, the comparison with the idea that you've explained about the circles it would be totally unfair, since in NTLite the categories doesn't have visual cue; what have visual cues are the tree of checkboxes that represents Windows components, and it is understandable that selecting a critical root component has a red warning color or risk level, while its child components that are safe to remove them have a green color. So I think it can't be took as example to discuss the idea that you've proposed about the circles. But I still think that it could be of help to inspire you, due the fact of how the checkboxes are colored on its left side, thus avoiding adding additional controls or symbols, such as a colored circle. I'll show you a screenshot of the program so you can see how the visual cues are like: Dark Theme: Light Theme: |
I think the screenshots @ElektroStudios are perfect 🤔 |
For me, the flat left border looks the best, although not all of the border colors of that group should be yellow, I'm right?. I mean, It should look like the right margin image but with left border colored instead, don't?. Anyway, this is what ChatGPT 3.5 thinks about the comparison between left border / flat left border and a filled background (I think it is a valid and objective opinion): |
Thanks for quick input @ElektroStudios, you've been really helpful ❤️. There's one issue with left borders:
This does not work well, then I move the border outside of checkbox instead of inside. But it does not work with radius: If I remove the radius from existing checkbox, it looks nice: We can also remove white left border so its more integrated: Separating a bit works well: So three alternatives work:
I guess this is the best way right?
GPT: If I push GPT harder, it wants to add texts "Strict, standard" etc. We do not align at all, I think humans call the shots here 😃 |
@undergroundwires Also according to me Also if you want to do anonymously go for Huggingface Chat cause it also give |
I find "No Margin" (1st image) to be annoying (irritating to see) that white border so close to the other, and I think this is not subjective. I would opt for "No margin, remove left white border" (2nd image). The "No margin, remove left white border" feels like a single visual element, as if it were part of the same checkbox. It becomes clearer to see what you have marked and the color. I think with our human brain and vision signals it is much faster and productive to identify it like that, I mean in that image we have to focus our attention on only one single figure with a colored side, instead of separating the vertical colored rectangle element like in "Some margin" (3rd image) to add two different visual elements that are "far away" each other, it seems a little strange to me, I wouldn't say it is annoying, but maybe it feels imperfect or not as optimal as it could be. In the end I think this is all a matter of personal preference. Except for what I said about the 1st image. EDIT:As a suggestion, I would make bigger the width of the colored border, like in the "Flat border" example which feels like around the 25% (8px in your example) of the left side is filled. This is totally a personal preference, but I think it helps to make it even clearer and consistent to see it. |
No margin, remove left white borderHere's how it looks with different PX using all the alternatives (spacing used in privacy.sexy):
4px looks too shy, so it should be at least 6px. I think the options are 6px-10px-15px-20px.
What do you say here? After choosing this we can also define "some margin" I also think it should be considered because it clearly separates the visual elements, and we can take a last look later between these two options. |
The larger you make the filled rectangle left at the outside of the checkbox boundaries, the more it will look in conjunction like a confusing kind of toggle (on/off switch) button, like in the 20px and 30px images. So 6px is fine. But it would be better 10px or more if the filled rectangle can be put inside the checkbox bounds, aligned to the left side, like what you have shown here: |
Sorry , I keep editing posts @plantindesk... Margin used:
|
And hovering the mouse cursor on the filled rectangle it will prevent the checkbox from being able to be clicked/checked?. I think it shouldn't prevent the user from checking/unchecking the checkbox.
I love how it feels the 6px filled inside the checkbox bounds. Except for the curvature from the top and bottom sides of the filled rectangle, to the inside. |
I fix it using a CSS hack. This is 6px.
Keeping the white border on top and at bottom border looks better I think. Should checked states be styled too?
I guess we'd like to keep seeing the level of stuff we choose, but it looks a bit ugly when its styled inside this way. Feel free to comment. I know its a lot but it wouldn't happen without your contribution @plantindesk and @ElektroStudios so please keep giving feedback. In the end I will list the options that we liked so we can choose one of them. |
but Navigator API is yet remaining. I will do after 29th 😅 |
Of course, what would be the point of this feature (and all of your work put on this) if the visual cue does not remain visible when the checkbox is checked?. No one can remember the color / risk level of all the marked checkboxes when they are a lot. Keep it going! |
@mziehm Sorry but according to me, as a UI/UX designer, it will affect the appearance of UI. In other words, It will make UI worse. Try converting the website to UI/UX design, customize it according to your preferences and see if it looks right. |
Problem description
The other day I just enabled a script that breaked my Visual Sutido 2022 IDE (script name:
Disable participation in IntelliCode data collection (breaks Visual Studio 2022)
), and I spent a long time trying to figure out why it wasn't working, until I realized it could have been due to some script I activated in Privacy Sexy. It's been hours since I used Privacy Sexy and then I used Visual Studio, that's why I didn't realize it before.Obviously I didn't paid enough attention to the fact that the script name warns that Visual Studio 2022 breaks.
I consider that a simple text warning at the end of the script name, in parentheses, is not enough to focus our attention on that warning, it does not sufficiently prevent us from ending up activating a script that breaks an important program that we need to use.
Proposed solution
Implement distinctive visual cues to warn of scripts that are known to break something (that is, scripts whose names ends with a warning like:
(breaks *****)
)For example: highlight in a striking text color, like yellow or indian-red, the script names that are known to break something.
Without a doubt, that would be an ideal, efficient, beauty and not annoying way to warn.
(the text in the image above is ugly and it doesn't feel very comfortable because I just did a fast color replacement in the screenshot)
Of course the textual warning between parenthesis must be preserved. What I'm proposing is not a replacement, it is an addition.
Alternatives considered
What I've explained above is what I consider the optimal solution.
However, another alternatives may be:
Add a warning symbol (⚠️ ) at the start of the script name.
Show a confirmation dialog (a message box) when enabling any script that is known to break something. The message would warn the end user about what is known to break after executing the script and if really want to activate it, then the user should press "Yes" or "No".
The text was updated successfully, but these errors were encountered: