Forum Discussion
Button on base layer showing on second layer
Hi, everyone!
This question has been discussed before, but I have tried all the solutions recommended and I can't figure out a solution.
See the attached picture: after a user clicks on a button to "continue" on the base layer, this layer appears. Everything on the base layer is supposed to be hidden, but you can see the black button peeking out from behind the pink box (this button is what the user clicked on the base layer to show this layer).
There is no animation on the base layer, just a slide with a background picture and text. There is no animation or hover states on the layer. I have tried deleting and re-creating the button. I've created my own buttons with shapes rather than use Storyline presets. I also deleted the button's hover state (I program my own hover states rather than use presets as well). I'm attaching the second layer settings, but I've tried changing every setting I can think of.
I continue to encounter this problem throughout this project. The workaround is, I create new slides when new layers would be more efficient. Please help!
Thank you!
Erin
Any chance you can share a copy of the project file (after removing any proprietary info)?
Sure. The project is rather large, so you want to go to slide 1.4 PreMtgInfo. If you preview that slide and hit "Continue," you'll see what I mean.
Great. And...just for clarity, the desired/intended outcome is...what again?
The outcome of the course, or of this slide issue? The desired outcome is that buttons the user clicks on NOT appear on subsequent layers, when I've chosen to hide all objects on base layer.
The outcome of the course is for the user to learn the steps of leading an action-mapping session. :-)
Very interesting... can't find a programming issue anywhere, so my advice would be to take one of the following two approaches:
- On the mentorClick layer, create a shape (in this case, a solid white rectangle) and send it to the back of the stack to mask the button peeking through
- For the button on the base layer, create a Selected state and delete all content from that state so it is completely empty. Adjust the trigger to read "Show layer mentorClick when the state of continue 1 is Selected. This will force the button that is peeking through to become "transparent"
I will try both of these things. Thank you! It has been driving me crazy. I have no idea why it is doing this.
Oh, sorry - yes, the outcome for the slide :)
Awesome! Let me know how it goes
Wow! Thanks for posting this; I learned something new.
When you hover over the Continue button, your trigger changes it to the hoverr state. Then you click, and are still hovering over it. The click shows the layer, and the hover keeps the button visible, overriding the setting not to show the background objects. What I didn't realize until now is that the built-in superpower of hover includes letting go of the button before starting the click action. So you will be all right if you change the name of the state back to Hover, and get rid of this trigger:
Walt, you're a miracle-worker! I was taught to never use built-in states, but rather to create your own. Do you use the built-in hover states for buttons in your own programming without any problems?
Thank you!!!
Just out of curiosity, who informed you that built-in states should be avoided? I heard a rumor that this was something being taught at a bootcamp by a certain well-known figure on LinkedIn...
Feel free to respond via a private message if so inclined.
Well, that's perhaps too wide a brush. The truth is that the built-ins are a lot more nuanced than that. Most of the problems with built-in states come from trying to use the built-in state and using your own triggers to duplicate their action.
Some of how I approach built-ins in development:
1. I don't use built-in buttons; too much baggage, including hover and glow.
2. I don't use hover; too many problems with touch screens and accessibility.
3. Visited can be useful, but its scope of its trustworthiness is mainly limited to the same slide and its layers.
4. Selected is extremely reliable as are Drop Correct and Incorrect.
5. I use built-in states, but mostly in conditions to indicate to the system a previous action, rather than a change of appearance to the user. There are some difficulties in always getting what you want with changing the appearance, so I usually use custom states for that. When I use built-in states, I usually duplicate Normal with no change and give it a built-in name. I frequently use Selected and Hidden, often Drop Correct and Incorrect, and sometimes Visited.
Just a personal rant: I would cheerfully strangle with my bare hands any developer that puts something on my screen that I want to do, but that doesn't do anything when I click it; not even show an error message. So I don't ever use Disabled.
The ultimate decision point is that the built-in states a pretty powerful doing what they are designed to do. They completely fall apart when asked to do more or used some other way.Thank you for this information, Walt. Extremely helpful.
- You're welcome. PIAWYC (Pass it along when you can).
