Hello - what is the expected behaviour of objects in a group where it pertains to their hover states?
Eg. I have buttons that are part of a menu, I group them together so that I can animate their entrace together. Would you expect to see their individual hover states? Because when I group objects together like this, then mouse-over the group, it activates the hover state on both buttons in the group rather than individually.
In other words, is grouping the creation of a new distinct object, or a container for objects?
Yes, hover applies to the whole group, which is a handy feature of groups, but it can totally work against you like in your case here.
You could animate those objects seperately or you could leave it as is, and then show your separate objects over the menu, once the animation completes, so you have the objects nice and sepearate for the user to click. I hope this made sense. :)
The benefit of groups is only good if you can add anything and get the same behaviour as when not grouping them. If adding multiple UX elements makes them all act on hover...as now is...its a bug. If i want a group to act as a whole, i add a hotspot in it and add the trigger i want there...
As is now...groups cannot be used with multiple UX elements.
Second voicing support to prioritize this bug. I have to create a lot of sliding menus that slide in and out of the the learner's view. It's extremely time-consuming having to create motion paths for every single menu item, but it's the only way to have hover effects work properly. As Math mentioned above, having groups act as a whole is not a handy feature, but an inconvenient bug.
Basically adding subgroups ensures you can select individual elements with hover and/or clicks. Remains that this still is a bug and also should work on a single group.
Is there a way you can make layers work for your menu? It would save a lot of time over using motion paths, even if you can get the groups to work. If not, at the very least, use scrolling panels, and fly in entrance animations, which is better appearing, and easier than motion paths.
I do use layers, but fly in entrance animations don't work for me. I need to have precise control over the path length and positioning of my objects sliding in, and only motion paths give you that pixel-level accuracy.
8 Replies
Yes, hover applies to the whole group, which is a handy feature of groups, but it can totally work against you like in your case here.
You could animate those objects seperately or you could leave it as is, and then show your separate objects over the menu, once the animation completes, so you have the objects nice and sepearate for the user to click. I hope this made sense. :)
This cannot be intended... Check this sample and post..
https://community.articulate.com/discussions/articulate-storyline/buggy-behaviour-of-buttons-and-checkboxes-in-a-group
The benefit of groups is only good if you can add anything and get the same behaviour as when not grouping them. If adding multiple UX elements makes them all act on hover...as now is...its a bug. If i want a group to act as a whole, i add a hotspot in it and add the trigger i want there...
As is now...groups cannot be used with multiple UX elements.
Second voicing support to prioritize this bug. I have to create a lot of sliding menus that slide in and out of the the learner's view. It's extremely time-consuming having to create motion paths for every single menu item, but it's the only way to have hover effects work properly. As Math mentioned above, having groups act as a whole is not a handy feature, but an inconvenient bug.
Luckily there is a workaround for this. Do check Chris Hodgson's trick how to fix the 'Group'-hover-bug.
https://community.articulate.com/discussions/articulate-storyline/buggy-behaviour-of-buttons-and-checkboxes-in-a-group
Basically adding subgroups ensures you can select individual elements with hover and/or clicks.
Remains that this still is a bug and also should work on a single group.
Rick,
Is there a way you can make layers work for your menu? It would save a lot of time over using motion paths, even if you can get the groups to work. If not, at the very least, use scrolling panels, and fly in entrance animations, which is better appearing, and easier than motion paths.
Chris's trick is the best solution for this, I wouldn't complicate it more than it needs to be.
I do use layers, but fly in entrance animations don't work for me. I need to have precise control over the path length and positioning of my objects sliding in, and only motion paths give you that pixel-level accuracy.
Thank you for this, Math!