Forum Discussion
Please allow groups to be selectable from the States selection pane in Triggers.
To further emphasise this inconsistency, Groups *are* selectable in the "When user clicks..." trigger options.
Hi DeveloperIgniti,
Thanks for taking the time to explain this so clearly, and thanks, AndrewBlemings-, for chiming in.
Your example does a great job highlighting how groups behave like a single object in some trigger contexts but not others, which creates extra authoring work when you need to change states manually.
I'd like to better understand how often you run into this while authoring. Is it something you encounter occasionally, or in most of the interactions you create? Also, approximately how many grouped objects or custom controls do you typically build in a project before this becomes noticeable?
Understanding how frequently this comes up and the types of interactions you're building helps us better understand the impact a capability like this could have on your authoring experience.
Speaking for myself, I tend to just avoid grouping objects in general, in large part because I have noticed over the years that it affected how they could be interacted with. Groups make sense to me as logical containers, such as collecting (and hiding) a bunch of UI elements that I no longer need to see on the timeline, but that the grouping changes how I can interact with them means I just avoid them. I've taken to mostly using layers now as a replacement for groups.
I would like the option to for instance set a group of buttons to disabled after one is selected/clicked, facilitating a choose-one interaction.
Thanks for sharing more about your workflow, AndrewBlemings-.
It's interesting to know that you've largely stopped using groups and rely on layers instead. Your choose-one interaction example is also a helpful use case. I can see how being able to target a group directly in triggers would support that workflow.
I'm curious, are there any other interactions where being able to target a group directly in triggers would make a big difference for you?
Thanks again for taking the time to share the additional context!
Thanks for asking!
I think I first started using layers over groups in this way to contain UI components. If I have a small popup that appears when a learner hovers over a UI element, I currently make the whole component on a layer and then line it up to animate in and out as needed.
If I can instead build the rectangle with the text and include an arrow graphic and a close button all in one group on the base layer and just have the group toggle "Normal" when the learner hovers and toggle "Hidden" when the learner clicks the close button, that'd save me a layer.
I think another big consideration for me is that when I hide and show layers, their Z-order changes with respect to other layers. Layer B might've been "behind" Layer A when the slide started, but if I hide and show Layer B with a trigger, when it reappears it will be in front of Layer A. I don't always want that since that could mean certain UI elements on B are on top of the UI elements of A when they should be beneath A. My workaround is to have more triggers that re-show the already-visible layers in the right order so that their intended Z-order is maintained.
As opposed to a layer, objects on a slide's timeline maintain their Z-order when I change their state unless I deliberately alter the depth with the JavaScript API. Being able to group timeline elements and simultaneously change all of their states would keep their Z-orders where I want them, reducing the need to leverage layers and their slightly more finicky depth changes.
