Buggy Behaviour of Buttons and Checkboxes in a Group
Jan 19, 2023
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 !
18 Replies
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
Great solution, Chris.
I would argue this is not a bug and it's just the nature of how groups work and it's actually great when creating a button with more than one object.
As said Articulate employees themselves put it on the bug-list ;-)
I hope it stays on the list forever ... :)
I agree with Nejc at this stage; changing this behaviour will break a lot of peoples work
Articulate actually changes their internal code and HTML almost every update. If you only use 'default' options then indeed i agree it would be nice if updates never break existing projects. But that also limits Articulate to make newer versions completely backwards compatible and thus hang on indefinately to the old way Storyline is setup.
If you depend on Javascript code in your projects, you need to doublecheck projects every update Articulate makes... as the changes in updates are not documented good enough to ensure the way you use Javascript still works after updates. I try to make my code as simple as possible and document it thoroughly, so i can fix things quick when Articulate updates break things. Bonus of using Javascript this way, is that all code and tricks i make...i can reuse in any rapid authoringtool that supports Javascript.
The 64 bit version could have been a great start with a modern Storyline. Alas they did clamp tight to the setup of the old version.