It's awkward behavior when the hover state remains active even after the button is clicked and transitions to the Selected state. In fact, the selected state will become active only after the cursor has moved away from the button (review my video for a brief demonstration). If hover states were entirely removed, your slide would function properly. Alternatively, in addition to Jürgen's suggestion, you could address this issue by updating and reducing the number of triggers, as demonstrated in the example below.
“If state of XYZ = Normal” will work only if all the other state options are custom (bespoke) states. Not really a bug, but a design choice. All the built-in states (the names you see in the drop down) are overlays of Normal. Therefore, (like all of us), they report themselves as Normal. The condition “if state is Normal” will be reported True by Selected, just the same as Normal. So Jurgen’s suggestion is the only trustworthy option: “If state is not Selected”
Walt, your opinion is valuable and appreciated. In this particular scenario, both solutions are viable. In the original setup, triggers didn't function, and you explained the reasons why effectively. Relying solely on the Normal state isn't reliable without additional supporting conditions. My conditional statements precisely outline the desired actions, timing, and context. The choice between "Normal" and "not Selected" in this case wouldn't matter. If I were Joshua, I'd opt for Jürgen's suggestion for its efficiency in updating existing triggers. However, if I were starting from scratch, I'd prefer my solution, as it reduces the number of triggers from 40 to 20 while achieving the same outcome. It's akin to coding, where we aim to streamline our code to achieve the same effect with fewer lines. My primary focus in this post wasn't the debate between "Normal" and "Selected" states; it's more about the battle between "Hover" and "Selected" states, a topic that's widely discussed in the Articulate community. I aimed to visually demonstrate this in my video presentation. I don't mind if the "Hover" state overlaps the "Selected" state in terms of visual appearance as long as it does not affect the content itself, and it is illogical for the "Hover" state to override content in my "Selected" state, as evident in my video example. Additionally, I see no rationale behind activating the "Selected" state only when I move my mouse away, especially after clicking on the button. It takes two steps/actions for me to see what I actually have selected. I understand that it's activated in the background, but I don't receive visual confirmation of the change until the mouse is away. It displays "Hover" instead of "Selected," which I find inconsistent. As you've pointed out, it seems to be more of a design decision rather than a strictly correct one.
5 Replies
this is a known bug with trigger and check button states
It's awkward behavior when the hover state remains active even after the button is clicked and transitions to the Selected state. In fact, the selected state will become active only after the cursor has moved away from the button (review my video for a brief demonstration). If hover states were entirely removed, your slide would function properly. Alternatively, in addition to Jürgen's suggestion, you could address this issue by updating and reducing the number of triggers, as demonstrated in the example below.
Thank you both!
the not selected/selected fix works.
will clean up according to your suggestion.
Thank you once again.
Information for anybody reading this thread.
“If state of XYZ = Normal” will work only if all the other state options are custom (bespoke) states. Not really a bug, but a design choice. All the built-in states (the names you see in the drop down) are overlays of Normal. Therefore, (like all of us), they report themselves as Normal. The condition “if state is Normal” will be reported True by Selected, just the same as Normal. So Jurgen’s suggestion is the only trustworthy option: “If state is not Selected”
Walt, your opinion is valuable and appreciated. In this particular scenario, both solutions are viable. In the original setup, triggers didn't function, and you explained the reasons why effectively. Relying solely on the Normal state isn't reliable without additional supporting conditions. My conditional statements precisely outline the desired actions, timing, and context. The choice between "Normal" and "not Selected" in this case wouldn't matter. If I were Joshua, I'd opt for Jürgen's suggestion for its efficiency in updating existing triggers. However, if I were starting from scratch, I'd prefer my solution, as it reduces the number of triggers from 40 to 20 while achieving the same outcome. It's akin to coding, where we aim to streamline our code to achieve the same effect with fewer lines. My primary focus in this post wasn't the debate between "Normal" and "Selected" states; it's more about the battle between "Hover" and "Selected" states, a topic that's widely discussed in the Articulate community. I aimed to visually demonstrate this in my video presentation. I don't mind if the "Hover" state overlaps the "Selected" state in terms of visual appearance as long as it does not affect the content itself, and it is illogical for the "Hover" state to override content in my "Selected" state, as evident in my video example. Additionally, I see no rationale behind activating the "Selected" state only when I move my mouse away, especially after clicking on the button. It takes two steps/actions for me to see what I actually have selected. I understand that it's activated in the background, but I don't receive visual confirmation of the change until the mouse is away. It displays "Hover" instead of "Selected," which I find inconsistent. As you've pointed out, it seems to be more of a design decision rather than a strictly correct one.