Dashboard enhancement: possible PR for decoupling state of switch from its control action

[cin...@gmail.com]

Hi,

In my opinion, it is often desirable to detach the status indicator of a control input from its actual action.  

Especially the switch control of the dashboard cannot achieve this in the current implementation, since every press immediately changes its status.

In contrast, pressing the switch could just emit a message as the opposite of its current state, but not change its status until the node gets an input.

I implemented this as an optional feature a while ago and it works quite well.

I'm pretty sure others could also profit from such an enhancement, should I create a pull request?

Thanks!

[Mark Setrem]

Sorry I'm confused. Are you using the switch as a way of displaying a value and passing it on when pressed? 

If you want to pass on a pre-existing value aren't you just using the wrong UI widget and wouldn't a button be more suitable? 

If I click on a switch I personally expect its state to change and for it to have the option for it to not would to me be confusing.

[cin...@gmail.com]

consider the case you want to control a light. You press the switch, its sends over some kind of infrastructure (mqtt, modbus, knx what ever) a signal to turn on the light. But do you really know the light is on? Therefore, the actor which turns the light on provides feedback - the light is on. Therefore, instead of immediately change the state of the switch to on, it should change only if it receives the feedback from the actor. Thats the idea of this enhancement. 

[Dave C-J]

For the switch, I can see the use for this. It would need to be an extra option so as not to break existing behaviour. I think it would be an option that is hidden by default that appears when the "pass through to output" option is unticked, and is a select that says something like "icon shows state of output" - the default, or "icon shows state of input".

thoughts ?

[Colin Law]

I think it would be confusing if nothing happened immediately when you
clicked the switch. I can see one clicking again thinking that it has
not worked, so confusing the situation further. For me the ideal
situation would be a three state indication, something like clicking
it moves it, but when the confirmation comes round it changes colour.
At the moment I do this by putting an icon beside the switch that I
switch red/green to give the feedback that the switch has actually
done something, but if the background colour of the switch could be
changed then, for me, it would be ideal.

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/node-red/CACXWFwLmzWUv2no7Ks%3DBKf7PKLaYVoqWphPzCVQ5gwDG4hfOTA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

[cin...@gmail.com]

Thanks for the discussion!

My thoughts to this: In an ideal world, the feedback should be received with little latency. Therefore, after pressing the switch, it should not take long to change its status, which would avoid the confusion you describe. Just to understand it correctly, you would like the switch to switch, but not change its color? This would contradict the visual indication "right" means on, "left" means off?!?

If one is interested, here in this branch the current state is

https://github.com/cinhcet/node-red-dashboard/tree/switchStatusDetachFeature

With respect to the UI. In this implementation, the standard behavior is as before. Then there is a checkbox to detach this. Do you think it is worth hiding this option by default? Personally, hidden options are often more confusing than default values. Especially, what happens if the option is enabled and then the "pass through to output" option would be unticked? 

[Colin Law]

On 16 March 2017 at 16:51, <cin...@gmail.com> wrote:
> Thanks for the discussion!
>
> My thoughts to this: In an ideal world, the feedback should be received with
> little latency. Therefore, after pressing the switch, it should not take
> long to change its status, which would avoid the confusion you describe.

Unfortunately the world is generally far from ideal. With the UI
running in the browser in a phone half a world away it can take a fair
time. There are few things worse than tapping something, not being
certain whether you touched the screen in just the right place or in
just the right way, and then waiting for some feedback which may never
come before deciding to try again.

> Just to understand it correctly, you would like the switch to switch, but
> not change its color? This would contradict the visual indication "right"
> means on, "left" means off?!?

Think of the press buttons with a light inside. Pressing the button
pushes the button in, but it does not light up unless the device is
actually powered up. Right means on please and left means off please.
Red means actually on, green or grey or whatever means actually off.
In practice I suppose what it actually means is four icons, if they
were configurable then we could specify whatever images we wanted for
the different states.

Cheers

Colin

> https://groups.google.com/d/msgid/node-red/17660e89-b198-4755-b9e4-767980c9c75f%40googlegroups.com.

[cin...@gmail.com]

Unfortunately the world is generally far from ideal. With the UI 
running in the browser in a phone half a world away it can take a fair 
time. There are few things worse than tapping something, not being 
certain whether you touched the screen in just the right place or in 
just the right way, and then waiting for some feedback which may never 
come before deciding to try again. 

mhh, to me the points you mention are exactly the reason for decoupling the switch state from its action. If you test the branch I posted, you can see that pressing the switch will still show its "I have been clicked" animation. Especially on mobile devices, where I am not sure whether it has worked or not, I really find this useful the last weeks I tested this, since if you had the impression it has not worked, just press again and it will send the desired command. And if there is feedback, you see it.

 

In practice I suppose what it actually means is four icons, if they 
were configurable then we could specify whatever images we wanted for 
the different states. 

Would a separate widget not a better solution for this? 

One thing: Assume the button is in its "off" state, both from its control and its status. Then you press it, it moves to its control "on" status. But the feedback does not come. If you press again, which message should it then send? The "off" message, or again the "on" message?

[Dave C-J]

Hi,

If the passthru is then ticked again, the option should hide and revert to existing behaviour. (Showing state of output).

sent from phone

[Colin Law]

On 16 March 2017 at 17:40, <cin...@gmail.com> wrote:
>> Unfortunately the world is generally far from ideal. With the UI
>> running in the browser in a phone half a world away it can take a fair
>> time. There are few things worse than tapping something, not being
>> certain whether you touched the screen in just the right place or in
>> just the right way, and then waiting for some feedback which may never
>> come before deciding to try again.
>
>
> mhh, to me the points you mention are exactly the reason for decoupling the
> switch state from its action. If you test the branch I posted, you can see
> that pressing the switch will still show its "I have been clicked"
> animation. Especially on mobile devices, where I am not sure whether it has
> worked or not, I really find this useful the last weeks I tested this, since
> if you had the impression it has not worked, just press again and it will
> send the desired command. And if there is feedback, you see it.

Sorry, I am confused in that case, I thought you wanted it so the
switch did not move till the new value came back. Tell me again what
happens when you touch the switch please.

>
>>
>> In practice I suppose what it actually means is four icons, if they
>> were configurable then we could specify whatever images we wanted for
>> the different states.
>
>
> Would a separate widget not a better solution for this?
> One thing: Assume the button is in its "off" state, both from its control
> and its status. Then you press it, it moves to its control "on" status. But
> the feedback does not come. If you press again, which message should it then
> send? The "off" message, or again the "on" message?

If it has moved then you know it has sent its message so you just have
to wait. If there is a temporary loss of connection then when it
re-connects the switch will go back to the off state, so then you know
to try again.

Colin

[cin...@gmail.com]

Hi, thanks for your comments!

Sorry, I am confused in that case, I thought you wanted it so the 
switch did not move till the new value came back. Tell me again what 
happens when you touch the switch please. 

sorry for not explaining it well. Yes, indeed, if you press the switch, it does not move. But still there is a little animation (gray red circles that become larger, dont know how to describe it better) that indicate that you have pressed something. At least in my opinion, that provides good feedback already, what do you think?

@Dave

If the passthru is then ticked again, the option should hide and revert to existing behaviour. (Showing state of output).

should work (hopefully), see the PR 

[Cor Bosman]

I use status 'leds' (just simple ui-templates) to decouple the switches/buttons I have from the actual status of the hardware/actor. The actor sends a message back, which changes the led colors. 

[Dave C-J]

Yeah - lots of flexibility with template.

We have merged a change as described above into 2.3.6 on master.