Skip to content
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

Accept All button should never be disabled #59

Open
lykyd opened this issue Mar 24, 2021 · 4 comments
Open

Accept All button should never be disabled #59

lykyd opened this issue Mar 24, 2021 · 4 comments
Assignees

Comments

@lykyd
Copy link

lykyd commented Mar 24, 2021

I think on a business matter, website owners prefer that the user choose the "Accept All" ("Tout accepter").
The fact that the "Accept all" button is disabled when all the categories of cookies are already selected is bad.
It could lead the user to "Refuse all" just because he could not click on "Accept all" and did not reached for the "Save" ("Sauvegarder") button that is far at the bottom.

@felixgirault
Copy link
Contributor

felixgirault commented Mar 25, 2021

Hello

I think on a business matter, website owners prefer that the user choose the "Accept All" ("Tout accepter").

As Orejime is providing a way for users to get information and make choices, it is mainly targeted at them instead of business focused.
Website owners may not appreciate it, but the point of GDPR is precisely to let the user in charge.

It could lead the user to "Refuse all" just because he could not click on "Accept all"

I don't think this could lead anyone to "Refuse all".
"Accept" and "Refuse" are two explicitly opposite actions, so it sounds weird to me that anyone could use one as a fallback to the other.
Maybe the problem lies in that there is no way for the user to tell why the button is disabled. We could probably make it clearer that it is because all apps are actually checked.

@lykyd
Copy link
Author

lykyd commented Mar 25, 2021

Even outside of the user or business consideration, I think that it's not user-friendly to disable buttons when it is not necessary. Maybe there is another reason for disabling them that I just don't get ?

It works in both ways (accept or delete). Why shoud we prevent user to be able to click the "Delete all" and force him to click on "Save" at the bottom when all he wants is to "Delete all" ?

Probably explaining why the button are disabled will be more confusing than just letting them enabled.

Also, using the "pointer" cursor when hovering those links would be a good thing too.

@felixgirault
Copy link
Contributor

Maybe there is another reason for disabling them that I just don't get ?

I dug up this commit ad7ed06 (then slightly updated dbfb0ce) which replaced the old confusing checkbox with two separate buttons. The disabling behavior came along with this change. I can't tell you more about it just from git history but I'll get in touch with the original author.

Would your solution be to stop disabling the buttons? (I could buy into it, I just want to be sure it's your point first)

It works in both ways (accept or delete). Why should we prevent user to be able to click the "Delete all" and force him to click on "Save" at the bottom when all he wants is to "Delete all" ?

This is where I get confused, maybe your solution would be to make these buttons actions instead of mere helpers, so they would accept/decline all and immediately close the modal?

Probably explaining why the button are disabled will be more confusing than just letting them enabled.

You're probably right 😅

Also, using the "pointer" cursor when hovering those links would be a good thing too.

When talking about "those links", are you still referring to the accept/decline buttons?
There is already a cursor pointer on them (with the current version at least https://orejime.empreintedigitale.fr/)

@felixgirault felixgirault self-assigned this Mar 26, 2021
@felixgirault
Copy link
Contributor

Hi @lykyd, any news regarding my previous comment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants