Forum Discussion
Buggy Behaviour of Buttons and Checkboxes in a Group
Articulate probably had some ideas when changing Group behaviour, but especially when using buttons, checkboxes and other UX elements in groups the behaviour Articulate had in mind fails. Maybe its even a bug.
https://360.articulate.com/review/content/d4e2610c-ef4d-4eca-84bc-97bed7c4a9f6/review
Check this sample of grouped and ungrouped UX elements and you will notice the difference immediately when hovering. All grouped elements react on hovering the group. That is for sure not what i want...when i want UX elements grouped i want them to act independently on a hover. If i need a group hover i add a hotspot.
Adding the Storyline so Articulate devs can test and fix this.
And just discovered by following some other posts that this behaviour is in Storyline for about 8 years. This cannot be intended ! Fix this !
Patient: "Doctor, it hurts when I raise my arm this high."
Doctor: "Then don't raise your arm that high."
Hi Math,
Thanks for bringing this up!
I can confirm that we are already tracking a known bug that causes the hover state of all objects in a group to activate even if the trigger only involves one object in the group.
I've added this community post to the report so we can notify you as soon as a fix is released. Thanks for your hard work on analyzing this behavior!
Great... for my specific case i already made a ( time-consuming and troublesome ) workaround.. but i do hope this gets fixed soon, as this is a pain in using groups.
Hello,
I'll have to concur, this is really a strange behavior. Objects should keep their separate states when grouped. It is really strange to be forced to add a disabled state on all the elements so as to not having the whole group to show the hand cursor.
It is really a pain when doing custom menus, which we do a lot, because of course we want to group our menus elements and of course we stumble every time on that bug :(
I am having the same issue. Any updates on the status?
Hi Bart,
Thanks for checking in on this! I understand you are looking for an update on the bug where the whole group activates the hover state even if the trigger only involves one object in the group. There currently hasn't been any movement on this as we prioritize other fixes. I'm going to include your voice in the request. We’ll update this discussion when there is any news to share about this.
In the meantime, a workaround for the issue would be not to group objects together when using triggers or if one of the objects has states.
Coming here to check the status of this bug again. Can this frustration be voiced again, please?
Indeed this is a bug existing for at least a year ( or longer ) and acknowledged by Articulate staff !
Fix it asap !It has been in since Storyline was created; the bigger issue is that anyone who relies on the broken functionality in a course would now have to fix that issue if it ever gets fixed.
I have courses that use this group behaviour
Relying on a bug :-) :-) :-)
And you only would need to fix it if you republish it. Better not relying on it in new projects... oh wait... Articulate is not gonna change...or are they... clear example of problems caused by untransparant Articulate policy. They promised change on transparancy...
The argument would be whether it is a bug, as it has been in place for 12 years. I could name 12 courses out of 500 that use it but at this stage it is probably an unexpected behaviour change.
Articulate employees in the past called it indeed a bug in messages with me :-)
For anyone who might still be facing this problem, creating nested groups might be a solution. I published a video onto YouTube today to demonstrate what this can do: https://www.youtube.com/watch?v=PaKtKkl5N74&list=PLgWxRODbk1M3kVbnoSaTS64UPQAJVPAF7&index=13&ab_channel=DiscovereLearning
