I can’t say for sure. (Also, when you say “if its two separate workflows?” I don’t know if you’re referring to the fact that you have those 2 similar When workflows [in green] or you mean you have 2 steps in your workflow.)
But the idea I’m getting at is that your workflow must wait for the transition to finish (using a pause step AFTER your animation. My question about your 2 workflow steps you are showing here is:
“Is Button AboutUS actually on or in GroupFocus A?”
If that’s so, it could be that step 2 is stepping on step 1, if you get my drift.
I have no idea what happens if you are trying do animations on nested elements – frankly, that would seem like something that would never reliably work.
Here’s what I’d do to test:
First, get rid of step 2 temporarily.
Add a new step 2: a Navigate > Pause step set to at least 1500 ms
Test in run mode… does that fix the problem?
(Obviously, you’ll want to do the same / similar thing with the other when situation. I’m guessing one of these is the out animation and the other is the in animation?)
Once you’ve got this working more simply, you can fiddle with adding your old step (animating “About us”) back in. It’s possible that THAT step 2 is stomping on step 1, keeping it from completing.
Anyway, I hope you see what I’m saying.
BTW, I do not do a lot of this animated show/hide stuff as it just doesn’t work well. It’s just that I’ve experimented with it a lot and in those quick experiments it became obvious very quickly that you pretty much always have to include pauses after animation steps to ensure they complete.
IF step 2 does seem to be stepping on step 1, what you CAN do is actually DUPLICATE the workflow(s) – they will have the exact same When condition, but one version would have just step 1 (and a pause after, perhaps) and the other would have just step 2 (again, with an appropriate pause if required.)
I have no idea if that will work, but I’m just sharing my past observations here. Hope this is at least somewhat helpful to you.
(One more thought: There may be NO way to ensure that the hide and show do not stomp on each other prematurely EXCEPT by setting some custom state.
For example, in the workflow you are showing: You might need a new step 1 that does something like sets some custom state (a boolean) named something like “Animating In” to yes. After the pause step, you set that state back to no.
In your Animate Out workflow, you add another condition such that the flow cannot trigger while “Animating In” is yes. (Meaning you add an AND to the “only when” of Whatever’s Animating In is no.) You’d of course do the converse for the other flow (another custom state of Animating Out that you set to yes at the wf start and back to no at the wf end – again AFTER a suitable long pause step and add the requisite condition to the Animate In workflow).
That may not give you the user interface you desire as the user might click on the thing while animating and get frustrated that at that moment nothing happens and they have to click again. You’ll have to test.
Aside: it COULD be that this is a bug with animate. It does seem to me that – if a transition is not allowed to complete – it wouldn’t be unreasonable for Bubble to reset the transform on that element so that it’s back to its un-transformed state before doing anything else. I have no idea if that’s possible as I don’t know what library has been implemented here and what its quirks are…
Might be worth a bug report / enhancement request if you can build a good, simple example of how and why this is messed up. (what I’m saying is: build a new empty project that very simply shows how, even with pause state workarounds, you can’t ever get the behavior you desire… though I’m guessing you can actually make this work the way you want… might require a LOT of fiddling though!)
