event selection popup shows for elements with one event
Description
Environment
relates to
Gliffy Diagrams
Activity
Lukas Ladenberger October 26, 2015 at 4:47 PM
Fixed and implemented as discussed.
Lukas Ladenberger October 26, 2015 at 2:38 PMEdited
— IMO, this is intrusive. It is only useful when the next event the user wants to trigger is associated to the SAME element. I assume that this is not the case in general. maybe this can be made configurable per event ( eg. closePopupOnActivate flag , default = true )
The best solution would be to hide the tooltip after executing an event of the list. I don't want to introduce to much flags
— Another idea about behavior configuration is to provide a per-element configurable strategy regarding click behaviour a) "informative" strategy : always open popup b) "eager execution" strategy : execute event if a single one is enabled. open popup if no event or more than one events are enabled
This is a nice idea. However, I would suggest to create a separate feature request for this. See: https://probjira.atlassian.net/browse/BMSPROB-23
— also open popup on hover (then this is now a tooltip?) - to provide event availability and enablement information
Yes, now it's a "real" tooltip.
Vlad Gheorghe October 26, 2015 at 1:59 PMEdited
Remark on UI-H2.1 - I fully agree.
— If one event is wired, and the event is disabled, what is the expected behaviour when clicking on the element? In this case the user would expect a something like a message. I would suggest to display a popup with the event showing disabled.
Agree. non-intrusive and uniform with other cases..
— The current behaviour when showing the tooltip with a list of events is: Whenever the user clicks on enabled event of the list, the tooltip stays open and the list of events will be refreshed (deactivated/enabled status of the events).
IMO, this is intrusive. It is only useful when the next event the user wants to trigger is associated to the SAME element. I assume that this is not the case in general.
maybe this can be made configurable per event ( eg. closePopupOnActivate flag , default = true )
Another idea about behavior configuration is to provide a per-element configurable strategy regarding click behaviour
a) "informative" strategy : always open popup
b) "eager execution" strategy : execute event if a single one is enabled. open popup if no event or more than one events are enabled
– also open popup on hover (then this is now a tooltip??) - to provide event availability and enablement information
Lukas Ladenberger October 26, 2015 at 12:52 PM
Two remarks:
If one event is wired, and the event is disabled, what is the expected behaviour when clicking on the element? In this case the user would expect a something like a message. I would suggest to display a popup with the event showing disabled.
The current behaviour when showing the tooltip with a list of events is: Whenever the user clicks on enabled event of the list, the tooltip stays open and the list of events will be refreshed (deactivated/enabled status of the events). Is this behaviour expected? I find this useful, since the user can directly proceed with executing further events.
Lukas Ladenberger October 26, 2015 at 12:46 PM
I agree with the tooltip "rules", expect on one point: UI-H2.1. as long as the mouse is not moved. This should be: "As long as the mouse is not moved outside of the hovered element." This is important since, the user can not enter the tooltip box, because it would be hidden, as soon as the user moves the mouse. Anyway, these "rules" are already considered and implemented by BMotion Studio. So let's agree on these "rules".
A few points are remaining:
(Comments on 3.1) I agree. We should introduce a (short) delay. Do you have any suggestion in respect to you user experiences?
(Comments on 3.2) Ok, I see the problem. Indeed this could be confusing for the user. So, I think the tooltip disable/enable flag could be removed in general to avoid confusion by the user.
I agree with your behaviour proposal.
Observed : see summary
Expected : For elements with a single event handler, the event should be executed directly.
Note: this is the behaviour of 0.2.1
This is a major usability issue.