Text in radio button 'jumps out' on hover
Aug 09, 2022
Hi everybody,
Weird thing going on here: when I make a radiobutton, and if the linked text is in 2 lines, storyline sometimes (not everytime as you can see in the video: https://360.articulate.com/review/content/97612add-4a29-4a5f-8f31-96a0fd7dbc90/review) automatically gives different lay-outs to the other states, like Hover, Down, etc. See image in attachment. I didn't do anything in particular as I recall.
Very annoying, since this means I have to adjust every states seperately to align with the Normal state. Or is there any quick fix available?
How come this happens? And is there anything I can do about it to prevent it from happening again?
I copied the radiobuttons where is works well to 'fix' the tirth one, but helas, it changes the states automatically again. Is it the text that triggers it?! Any tip is welcome here!
12 Replies
Hi Sofie,
Sorry to hear about the behavior you encountered. I'd like to offer a few troubleshooting steps to help correct your experience:
If the issue persists, would you be willing to upload a copy of your project file here or in private by opening a support case so we can take a closer look at the behavior? We'll delete it as soon as we're done troubleshooting.
Hi Joe,
Thanks for reaching out.
Therefore I will attach the storyline-file. The issue is related to the third textbox below. The other two above are fine.
I did see that if I use an 'enter' in the radio-buttontextbox, the states do align, but this gives some extra spacing in de textbox, that than doesn't align with the other two textboxes above. Therefore this isn't a good solution for me.
Hope you can help me fix this!
Kind regards, Sofie
there is a problem with your story file - I have changes some width of the button text and if i close the file - storyline freezes - no error message - no cpu use - no IO - nothing => kill task didn't work !!! I had to restart the computer !!!!
this a type of error i never had with storyline
I can not reproduce the problem you have, @jürgen schoenemeyer, if I download it from my link here.
But, it is clear that there is a problem indeed, but what is the solution? :) And (maybe more important) what is triggering it?
I imported the slides from Powerpoint. I get a message some fonts are missing when opening (see attachment). But I don't think that any of the two have to do anything with this issue?
>I imported the slides from Powerpoint.
this may be the problem
I never import complete slides from powerpoint - if I use powerpoint as source I only copy media (text, images) - but never via the clipboard direct to storyline
> I get a message some fonts are missing when opening
this is usually not a problem at all
I could repare your file, I have deleted the states "Down", Disabled", "Selected" complete
then I created the 3 states new with "Add State" (never use clipboard here)
result:
https://360.articulate.com/review/content/ed1aa965-4248-4109-aed1-b9709a8714c7/review
Jürgen
Hi Jürgen
Thanks for your response.
Since I had this issue too in the past with slides that were made from scratch, I don't believe the import from Powerpoint is to blame here...
The repair that you suggest is indeed a way to fix it, but it's quiet time consuming My 'solution' is to edit every state on its own. Also time consuming. So I was wondering if there is a way to avoid this different states from existing in the first place?
Really weird that sometimes it goes perfectly well, and other times the states differ without any different action from my side (as I recall)...
If anyone can help, it would be very welcome!
In my experience, such software bugs have an extremely low priority at articulate - you can fix it by hand (with a lot of effort). So it may never be fixed. So I guess we'll just have to live with it.
Jürgen
I'll learn to live with it.
*Let it go, let it gooo...* ;)
Hey, I think this might be an issue with your text box formatting in States. Move into the radio button group, select the text box, and determine what the text-box rules are (expand height, width=y, etc). Then use those same rules on the text box in the next state. If you tweak the text-box rules after the state has been made, those rules don't always carry forward to the other states. Make sure that you have your text box defined exactly as you need it before you add a state.
In this case, it looks like you don't have "wrap text" selected in the "down" state; but do have it in the others.
Hi Pierre,
Thanks for your suggestions. I will have a look at them when the issue reappears.
I already noticed that indeed, when you tweak the text-box after the states are made (they are made by default in the radio button-text boxes so difficult to prevent this from happening!), that the new settings don't always carry on to the different states. It's a pickle though, because sometimes they do alter with the normal state (as they should!), other times they don't... Isn't this worth a bug report and hopefully solution from the developer team?
I will also look into the 'wrap text' setting for every state.
Kind regards & have a nice weekend!
I think it is a bug in the end-user-experience perspective, but I don't think it will fit Articulate's definition of a bug. They'll think of it as a "feature" that all variables of the text box get carried over. Part of the problem is a lack of clarity on what a "state" is. The object isn't a "master". You can edit the normal state and paste something into the state, and it does not copy over to all of the "child-but-not-children" states. The states behave more like groups with built-in triggers; but then Articulate hasn't committed to that UX either, as you can't access that group in the timeline. Articulate has done us the "favor" of treating states like groups when it comes to focus order; that is, not including the child-but-not-children objects (so frustrating).
So my understanding of the solution, in order:
1) Submit "another" feature request that grouped objects appear in the focus order
2) Then submit a feature request that states get a UI treatment that better parallels their UX behavior as groups.
3) Then submit "another" feature request that "set as default" actually applies the variables of the text box as well.