Design review: Confirmation for toggles

[spacegaier]

I need some design guidance:

We have the concept of tap_action, hold_action and double_tap_action (docs). I am looking at it in the context of an Entities card.

1. If you use an entity from a domain where there are no interactive elements rendered (no toggles, buttons, etc.) e.g. a simple sensor, those actions are automatically tied to the whole row => they are executed when you interact with anything in the row (the icon, label or value display). All good ✔️.
2. If however you use an entity from a domain where we render an interactive element, e.g. a toggle for a switch or light, then the currently configurable actions only apply to the icon and the label of the row, not the interactive element. That means you currently cannot use any confirmation to guard accidental interaction with an element. I want to close that gap 🌉.
3. To close the gap, we need a way in the configuration to specify those actions for the interactive element. We already do that for some of the Entities card special rows, specifically the type: button rows. And that is where the "problem" comes in ⚠️.
4. For type: button we tie the actions purely to the button. That makes sense if it is a pure "standalone" button row without any ties to an entity (so manually specified label, icon, etc.), since there is nothing that for example a more-info call could show here. It gets a bit muddy already, if you use the button with a real entity (which the configuration allows so that the name and icon can be automatically taken from it). But also here, the entity itself is not the focus, but the button is (since otherwise you would not have used a row of type: button anyway). So still okay 👍.
5. => ❓ How to design the configuration so that we can still maintain our current functionality where we can control what happens when you (double) tap or hold the row (icon and label) while also allowing us to control what happens with the interface element and safeguard it?

I thought about two config variants. Let's use the following as the base. Simple switch, where a tap opens the more-info (technically redundantly specified as this is the automatic default anyway).

type: entities
entities:
  - entity: switch.ac
    tap_action:
      action: more-info

To now safeguard the switch we could add new config for (double) tap and hold with the prefix interactive_ to indicate that this applies to switch (e.g. domains switch, light, fan, humidifier, automation, ...) or the button (domains lock, cover, script, ...).

    interactive_tap_action:
      action: toggle
      confirmation: 
        text: Are you sure you want to cool down?
        exemptions:
           - user: 123

That however might be overkill since I am not sure if there are (many) use cases where for a switch toggle where we need to differentiate between tap, double tap and hold. So we could simplify to only use a confirmation section directly to safeguard and always leave the default tap = toggle behavior:

    interactive_confirmation: 
      text: Are you sure you want to cool down?
       exemptions:
         - user: 123

What do you think?

[bramkragten]

Would just add a confirmation option then.

A toggle should toggle, you should not change that behavior.

[spacegaier]

You don't see the need to prefix it to interactive_confirmation (or something similar) so we don't have two confirmation in the config? This could be confusing.

type: entities
entities:
  - entity: switch.ac
    tap_action:
      action: more-info
      confirmation: 
        text: Really more-info?
        exemptions:
           - user: 123
    confirmation:
      text: Really toggle the AC?
      exemptions:
         - user: 123

[bramkragten]

They are on different levels, so no, not really I think...

[spacegaier]

Yes, from a technical perspective it of course works fine, was just concerned about users being confused by the structure since I assume we will not add support for the into the visual editor. But people messing with YAML should know what they do :) .

I am okay with it either way.

[pickonedev]

I think that the confirmation wolud be ok, as @bramkragten said. I'm used with this method already.

[matthiasdebaat]

Hi!

Just saw your discord chat for feedback and I'm happy to help you with that. If I understand correctly you would like to to safeguard e.g. an AC switch, so that someone doesn't accidentally turn it on? I've made two small prototypes in Figma to get a better understanding what your proposal means.

1. More-info
2. Safeguard

Form a UX designer point of view I think the user should always be able to toggle switches and gets immediate results. Same goes for checkboxes and radio buttons. Nielsen Norman Group has a great guideline about toggles.

In my opinion it's better to safeguard this by replacing the toggle with a button that opens the more-info dialog. I've made a prototype to illustrate this.

If you would like to discuss this further we could always do a discord call.

[spacegaier]

Yes, your understanding of my goal is correct.

Reg. the rest: I have now read your reply multiple times and cannot decide whether we are on the same line or not 😄. Every time I read it, I "toggle" ( 😉 ) again in my mind. I've now landed on: we agree and your wording / example is just throwing me off a bit.

I think we are all (including Bram from his comments above) aligned, that a toggle should immediately lead to either a direct toggle action (e.g. light on/off) or a confirmation popup and then followed (based on the popup user selection) an immediate reaction (either light on/off or go back to the state before the initial user tap).

That matches Brams comment that we will not support that a user can specify what a tap or hold action on a toggle can trigger. Instead it will always be the regular toggle action (no support for hold or double), but we will allow a confirmation popup.

I think I was mainly confused a bit by this: "In my opinion it's better to safeguard this by replacing the toggle with a button that opens the more-info dialog". In my mind a user would never use a toggle to open the more-info but I now see that one of my configuration variants would allow that. But as Bram confirmed above, we should/will not do that, so I think we are in agreement ✔️.

[matthiasdebaat]

Sorry, my bad. I hope this makes it clearer.

• I think that clicking on a toggle should get the immediate results by turning it on/off.
• A confirmation popup stands in the way for immediate results.
• I agree you should have an extra step if you want to make sure you don't turn a device on by accident.
• I recommend to use a button to the more-info popup instead of the toggle with a confirmation popup.

[spacegaier]

Just showing the more-info as a popup does not solve the use case I have in mind.

I want to be able to tell/warn the user what the risk of using the toggle is. E.g. "Toggling this switch will reset all target temperatures in the house. Are you sure?".
That would then be in line with what we already support for the regular configurable actions.

Just showing the more-info dialog provides no additional insight to the user.

[matthiasdebaat]

You've got a point. Explanation in a confirmation dialog is better. Reminds me about that time Hawaii EMA send an Emergency alert by mistake.

Just let me pitch an other pattern 😉 Instead of a toggle use a button and a confirmation dialog. I really think a toggle should get immediate results without a dialog.

[spacegaier]

But then you loose the benefit of having an easy and clear visualization of the state, as you have to carefully read the button text ("Turn On" vs "Turn Off").

So I don't think we want to loose that. Hence why I vote for toggle with optional confirmation dialog.

[Mariusthvdb]

just as an additional link to my FR for lock/confirmation on covers please see: #8947

Covers are a special category imho, and would benefit greatly from being 'guarded' in the frontend, against accidental opening at least.
Hope you could also consider adding the Pin dialogue.

[franz134]

quite a while ago... but I want to add such a confirmation dialog to the switches I'm using to control my 3D printer to avoid turning it off accidentally (or shutting down a PC). Was there any progress in the meanwhile with official implementation?
Also looked at double-tap-action but I didn't get either to work.
If someone could post the ymal from the code editor & config (if needed) of a working example I would be very thankful.
I like the way of the last figma example, that only one way with the confirmation: #8905 (reply in thread)

excuse, I'm relatively new to HA/ymal and not native english

[Dmoua68]

https://community.home-assistant.io/t/confirmation-dialog-on-switch-button-ui-actions/682/29

[fvbrandt]

Any news on this?

Both from an end-user perspective and from the perspective of the lovelace maintainer, I would much prefer a native solution that works with a regular switch entity and has the same look & feel as other switches in the UI, just with the added confirmation dialog.

I like the proposal with the "confirmation" directly on entity level. If you want to add a confirmation dialog to a switch, it is clear which action is meant (the toggling of the switch, of course). No need for users to learn about different actions that they don't want to mess with.

[matthiasdebaat]

I think we should make it possible to have a confirmation dialog on an action. But that can't be a switch, because a switch should always have direct result.

A solution could be: if a user adds a confirmation dialog to a switch, we should swap that with a button.

[fvbrandt]

IMO a) the linked article only argues against having to click an extra "Save or Submit" button but does not argue against a "safety warning" popup and b) even if an article would argue against that, from an actual end user perspective I would absolutely object. I think the number of requests clearly shows that people would like to have confirmations for switches and I don't see why one would break UI consistency with other switches just because of some abstract rule. Why can't my switch be a switch just because I want to have an extra safety popup? Empirical user feedback > abstract guideline.

[chammp]

Chiming in just to add one thing: The Real World™️ does for sure know on/off switches with security measures against accidential inputs. Just take a look at cockpits of airliners and you will see switches that are covered in a cap that needs to be moved away before engaging/disengaging some vital system. Or levers that need to be pulled and then moved into another position.

That aside, I tried to use template locks to prevent stuff from happening by accident (basically by hiding the "physical" switch behind a template lock that copies switch's state), but these cannot have codes (yet, there is my open PR that would add this and more, however maintainers and me have slightly different opinions of the overall direction here).

[Stan-Tastic]

I think that if it's optional and has to be manually configured, the user would not expect a direct action anymore. I'd like to have a switch that asks me for a confirmation, not additional cards or whatnot.

[Mariusthvdb]

yep, meanwhile we're on 2024.4.2 and still have no guard except for some faint warning/confirmation on the lock more-info. which to me is the worst experience we could fathom. click a lock and get a more-info of the same entity?

still using the ancient https://github.com/iantrich/restriction-card to overlay a lock on my toggles, and allowing for some detailed options.

tbh, the 'rule' the toggle should always directly toggle is a bit out of touch with real life imho. Sure, if it is supposed to toggle without restrictions, it should do so.

This discussion is about purposely adding those restrictions. In which case the behavior should purposely Not toggle right away, but give the user time to rethink (compare manual alarm panel), or enter explicit confirmation on a popup.

or

when clicked pops up this confirmation

We can even use that on the modern Tile card:

and have a pin popup

custom:button-card has a lock,

click/hold it it starts flashing.

click again and the switch toggles.

dont click again and the flash times out to return to the lock

there is also a permanent lock unable to interact:

just figured these examples would add to the discussion

[mfenske]

I stumbled over this discussion, because I just ran into that problem.

First, the implementation for now is not a consistent behaviour. When I add that confirmation option to a list of entities, a tap on the name gives me the dialog while a tap on the switch not.

Second, I didn’t expect a general discussion about best practice using switches. If a user prefers to stick to ui-guidelines, he wouldn’t implement a guard on a switch. To argue with “design decision” in a mostly editable GUI make no sense. Out there are some of the cruellest GUIs I have ever seen (build in HA). But hold on - the switches for now gives the user direct feedback… (sorry for that sarcastic comment). I build this stuff just for me... (as 95 % of all HA-Users).

Last, users shouldn’t be forced to use third party solutions for this simple task!

Please overthink the actual concept. I'm going with Stan-Tastic. Thanks!

[Mariusthvdb]

the absence of the confirmation on the right side entities element, a Button in this case was also brought up here
https://community.home-assistant.io/t/auto-entities-automatically-fill-cards-with-entities/147801/1388?u=mariusthvdb

not sure whether that is the same issue from a design perspective, but UX remains identical: setting a confirmation on an entity, and not getting it on the main element of interaction: the Button itself.

[karwosts]

A related pull: #21453

[Misiu]

Awesome news, thank you!!!
Do you have any plans to support other domains/cards? For example, I use a cover to control my garage door. If that changes anything, I use a tile card. It would be great to be able to confirm the opening of my garage door!

[karwosts]

@Misiu - not sure I understand. I think a tile card can already add a confirmation to a cover, as all its operations run through the tap_action which has always had an optional confirmation.

This change was only related to entities card. Does that make sense?

[Misiu]

Sorry I didn't show my card config before:

type: tile
entity: cover.garage_door
features:
  - type: cover-open-close
layout_options:
  grid_columns: 4
  grid_rows: 2

I have a cover and features that allow me to open/stop/close the cover. Ideally, the confirmation should show when I click on open.
I hope this makes more sence now

[karwosts]

Ok I see. Hmm well I didn't have any further plans for messing with design of tile cards right now, perhaps thats a bit out of scope here. Maybe someday? 🤷

What you could do if you wanted is remove the open/close feature, set the icon tap action to toggle, and add the confirmation to that tap action.

[Mariusthvdb]

for the cover in a tile, there is also an option to set restriction card (custom and ancient...) to it:

Id be happy to provide the config for that, if it's ok to post here. otherwise ping me in the community