Add support for a less intrusive user experience mode

Created on 31 October 2024, about 2 months ago

Problem/Motivation

The 2 widgets that are displayed on the bottom right of the screen for every page, if at least one active app is configured, are not necessary in the vast majority of sites. Examples are all those that don't use any cookies.

For such sites it would be great, if content blocking would still work, but those 2 widgets should just not be there.

Proposed resolution

Leave the content block as is and add an option to the settings, that the widgets can be turned off. Instead, provide a menu link from where visitors of the site can still go and see their privacy settings.

Also, add those infos to the documentation.

✨ Feature request
Status

Active

Version

3.0

Component

User interface

Created by

πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @jurgenhaas
  • πŸ‡©πŸ‡ͺGermany jan kellermann

    jan kellermann β†’ made their first commit to this issue’s fork.

  • πŸ‡©πŸ‡ͺGermany jan kellermann

    @jurgenhaas maybe checkout and test. This branch overrides hard the setup of klaro (we should add some config for this).

    - All external media will be protected.
    - All external sources are not loaded (because no consents given).
    - I think the small privacy button should stay (can later be disabled, i added in an other ticket a description for creating menu item).

    Please have a look.

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    @jan kellermann that certainly goes in the right direction. Can we make that configurable in the klaro settings? It should, however, default to the current behaviour.

    Would be great if that goes into the next RC. We could then run this by the Drupal CMS product owners.

  • πŸ‡©πŸ‡ͺGermany jan kellermann

    I added config and an update-hook. Please have a look.

    The new javascript is quite little tested - we need more than one review if possible (also with ajax and big pipe).

  • πŸ‡©πŸ‡ͺGermany rkoller NΓΌrnberg, Germany

    I really like the direction this one takes. Moving the Show Toggle Button checkbox underneath the Klaro! Dialog Mode section feels semantically and functionally closer. I also like, by switching over to radio buttons, it makes the different kind of available dialog modes more prominent - pre-MR, those two checkboxes were highly confusing. And finally a few additional observations and thoughts:

    • When the MR is applied the radiobuttons are missing a default choice, none was selected for me? .
    • Should the section, the klaro dialog mode radio button group and the show toggle button checkbox is in, also have section title like services and buttons have?
    • In regards of the microcopy of the radio button labels. I would drop the verb "Show" which is redundant. About the naming of the "silent" option. Based on the info in the parenthesis and the help text underneath, i would assume that on my site no cookies or any external services are used and klaro remains unobtrusive - and as a naive none technical new user i would ask is klaro automatically testing that fact for me and otherwise the "silent" option wouldnt be available? And it is not clear if everything is blocked or if klaro stays just "silent" as the labels implies. i assume the former. i've also tried to test opening a node that contains a remote media item, there the klaro block and opt in functionality is active. so klaro is blocking the mandatory defaults and everything else requires an opt in? The radio button label "Silent" might trigger some misleading associations? In regards of the other three radio button labels, just based on their names, it is also not clear what the difference between a notice and a consent manager is function wise. Stylistically one of the options uses parenthesis, the other "as" and the other doesnt have anything related to modals. in case of the latter option it might make sense to use "none-modal" to illustrate the difference to the two modal options explicitly instead of implied?
    • the online documentation and the menu link link point to the very same documentation page which only covers the part about menu links. i would rephrase the menu link documentation page. Instead of "can be used" i would use "has to be used". I would even move the detail, that this task requires the installation of the link attributes module, to the beginning of the page. Because i've just taken a look at the first one or two paragraphs and the screenshot and wondered where the attributes fieldset came from in the screenshot and how to get to being able to enter the rel attribute -> people only skim most of the time instead of thoroughly reading and my own example and experience is testament to that.
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    This is awesome. It can now be configured as if no consent management is available at all, and the site still remains compliant. Wonderful.

    Can I suggest to add a link to the https://www.drupal.org/project/menu_link_attributes β†’ module in the documentation as well? That would be required for users who want to create a menu link, and not a link field.

  • πŸ‡©πŸ‡ͺGermany jan kellermann

    After merging the dev branch the install-file was broken.

    I changed the settings form according to the discussion in #3485880.

    I also changed the JS commands for silent mode. In my tests everything was fine.

    Please review (hopefully for the last time).

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    This is still looking good. I haven't tested all scenarios, but silent and Notice dialog do work as expected.

    Thank you so much, this is huge!

  • πŸ‡©πŸ‡ͺGermany jan kellermann

    Merge is done. Thank you all!

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024