No matter what i do to the font and font size of the text within a text entry box, it always reverts back to the Articulate font, 12 point.
I've already noticed there are two ways to edit the font: You can click on the box and change the font, or you can edit the text and then change the font.
I've done both and every time it reverts back to Articulate 12pt.
Is this a bug? What's the work around? Highly annoying!
Now I will have to test it in SL3. For me, it always occurred in text boxes automatically generated when creating software simulations. I would take great pains to reformat the text to look like the real text entry, then every time I saved and re-opened, it would revert to some default I did not want. Locking on the timeline did not work. Changing text box properties did not work. Worse yet, sometimes it didn't show up until the course was published. Believe me, clients notice such things.
This is something we still have reported in Storyline 3 and 360. I'll include the discussion here in the report we have so that we can update you when there's movement on this issue.
Hi Ashley, I'm sure I'm not alone in sharing some frustration in seeing that an issue remains unresolved for some time. We frequently see requests to report issues. I personally don't have time to report every issue I've encountered. This in itself would be a full time job, even in a great product like Storyline. What would be really useful, and already discussed in a different forum thread would be:
a) an indication of whether the issue has already been raised b) an opportunity to "vote" (such as the "Mark as Helpful" flag) to indicate that I also have this issue. Articulate would very quickly be able to get accurate stats regarding the extent of the impact without authors having to take time out to repeat already raised issues.
This bug has been around for four years. It is a bug that is here to
stay...nobody knows how to fix it, nobody ever will. I moved away fro
Storyline two years ago for this very reason.
This issue completely changed how my department works and how we deliver training.
Same here. We just find ways to avoid text entry. Lame workarounds like "click in this box and we will enter the data for you." Doesn't work for all scenarios but what alternative do we have with SL1,err SL2 wait SL3!
The bug is a showstopper for any kind of software simulation application
requiring text entries. If you can't make data entry fields behave exactly
like the software you are emulating...its of no value to me. Storyline is
only good for simple gaming, drag and drops, crosswords. It is all macro
driven...you can't get into the API. If you need a toy for your
instructional design and development projects or very non demanding
clients)...stick with Storyline.
This issue was the catalyst for us to rethink our full approach to training.
We avoid the issue by having moved completely off SL-whateverversion. At first, we just used SL2 for the most trivial of training projects; now we don't use it at all. I don't think I've even started the program in nearly a year.
I tried to use Storyline as a simulator / demo tool including text entry from SL1 and re-tried it every release. It would be soooo useful if you could ask the learner to type in exactly what they should and have it look just like the text boxes in the real system. I spent quite a bit of time with Articulate developers reporting exactly how the bug performed in SL 1 and SL 2 and it was reported fixed a couple of times. Alas, not so. Apparently it still misbehaves, ignoring specific text box formatting commands and weakening the demo/simulation features.
HOWEVER, I paid my bucks and bought 360. Why? I can do my work for most client requests more effectively and faster in SL than I can in the other tools.
I've found my own workarounds for doing the simulations my clients demand--buy another expensive tool that does it right. However, there are still many good features in Storyline and the software is improving steadily. I smell sour grapes when someone on this forum calls SL a "toy" or "totally useless." These OTT comments might do one useful thing--convince Articulate that they ought to fix the problem once and for all. I don't really think it's all that tough. Just give us a method to override the default text box properties in recorded simulation text boxes.
The Text Entry Font Style Was Reverting to the Theme Font When Removing the Standard "Type Your Text Here"
The Text Entry Font Was Defaulting to 12 Pixels When Using a Higher-Resolution Slide Size, Even if You Changed the Font Size
The Text Entry Field in Screen Recordings Would Randomly Change Font when Clicking Inside the Text Entry Field
These 3 bugs should no longer be present in Storyline 2, Storyline 3, or Storyline 360. Let us know if you still see them!
What We Haven't Fixed Yet
These 2 bugs have a narrow impact or are unique to one customer:
Text Entry Doesn't Retain Alignment Formatting: This works OK in almost every case, including all HTML5 cases. The text entry Flash prompt is showing up in the right location, but when the learner starts typing, the text is top-aligned. We need to fix it so that the typed characters show up in the middle as well.
Action Fine Tuning Reverts the Frame Selection to 1-0 on Some Slides: One customer in this thread reported this problem, and we haven't been able to reproduce it outside that single customer environment.
What We Can't Reasonably Fix Right Now
Fonts for Variable References May Be Different in Published Output: We can't make variable references display using custom fonts right now because we don't know what characters a variable might use, and embedding every character in a font would seriously inflate the size of your published output.
Judging by the amount of activity on this thread yesterday, we've missed something really important (or maybe more than one important thing), and we want to help. Please click here to tell us exactly what's going wrong and we'll investigate.
We can all continue to add onto this forum thread if that's the easiest way for folks to communicate, but that may not be the best method of digging deep into individual issues.
As always, thanks for letting us know what's important to you!
Text Entry Doesn't Retain Alignment Formatting: This works OK in almost every case, including all HTML5 cases. The text entry Flash prompt is showing up in the right location, but when the learner starts typing, the text is top-aligned. We need to fix it so that the typed characters show up in the middle as well.
To throw in my two pennies, I get this issue every single time I try to insert a text entry field.
As most other people on this thread, I've stopped using them completely. Can't believe it's not been fixed in 5 years.
Click here for a 2-minute peek at what I'm seeing when I test alignment formatting in Storyline 3 or Storyline 360. Does this describe the problem you are seeing as well? Thanks!
Yes, that's exactly it. Also, inconsistent behaviour with fonts. They change size, weight and typeface randomly. For me sometimes, the font formatting will change between previews.
Fonts for Variable References May Be Different in HTML5 Output: We can't make variable references display using custom fonts right now because we don't know what characters a variable might use, and embedding every character in a font would seriously inflate the size of your published output.
Judging by the amount of activity on this thread yesterday, we've missed something really important (or maybe more than one important thing), and we want to help. Please click here to tell us exactly what's going wrong and we'll investigate.
We can all continue to add onto this forum thread if that's the easiest way for folks to communicate, but that may not be the best method of digging deep into individual issues.
As always, thanks for letting us know what's important to you!
So are you saying projects published with Flash as the default will always display the correct font regardless of font choice?
I apologize for the inaccuracy of that Knowledge Base link, Logan.
We won't be able to make variable references display using custom fonts in Flash OR in HTML5. I'll edit the text above, and we've updated the KB article accordingly.
195 Replies
Now I will have to test it in SL3. For me, it always occurred in text boxes automatically generated when creating software simulations. I would take great pains to reformat the text to look like the real text entry, then every time I saved and re-opened, it would revert to some default I did not want. Locking on the timeline did not work. Changing text box properties did not work. Worse yet, sometimes it didn't show up until the course was published. Believe me, clients notice such things.
I surrender. I'm learning to love the Articulate font.
Hi David,
This is something we still have reported in Storyline 3 and 360. I'll include the discussion here in the report we have so that we can update you when there's movement on this issue.
I started this thread 5 years ago, the problem hasn't been fixed. Don't hold your breath Dave.
Thank you, Ashley. I know your heart is in the right place. You have been
swatting this bug as long as the rest of us users. Good luck and God Speed!
Thanks David. 😊 That's exactly the note to end my day on.
I also wanted to let you know that it looks like you may have two ELH accounts - so if you need help reach out to our Support team!
Hi Ashley, I'm sure I'm not alone in sharing some frustration in seeing that an issue remains unresolved for some time. We frequently see requests to report issues. I personally don't have time to report every issue I've encountered. This in itself would be a full time job, even in a great product like Storyline. What would be really useful, and already discussed in a different forum thread would be:
a) an indication of whether the issue has already been raised
b) an opportunity to "vote" (such as the "Mark as Helpful" flag) to indicate that I also have this issue. Articulate would very quickly be able to get accurate stats regarding the extent of the impact without authors having to take time out to repeat already raised issues.
If this hasn't already been raised as an issue, I'm happy to reach out to your Support team! :-)
This bug has been around for four years. It is a bug that is here to
stay...nobody knows how to fix it, nobody ever will. I moved away fro
Storyline two years ago for this very reason.
Mr. McD. - you are not alone.
This issue completely changed how my department works and how we deliver training.
The results, Our development time is shorter, our "customers" are happier, and the training takes less time. Win. Win. Win.
Same here. We just find ways to avoid text entry. Lame workarounds like "click in this box and we will enter the data for you." Doesn't work for all scenarios but what alternative do we have with SL1,err SL2 wait SL3!
The bug is a showstopper for any kind of software simulation application
requiring text entries. If you can't make data entry fields behave exactly
like the software you are emulating...its of no value to me. Storyline is
only good for simple gaming, drag and drops, crosswords. It is all macro
driven...you can't get into the API. If you need a toy for your
instructional design and development projects or very non demanding
clients)...stick with Storyline.
This issue was the catalyst for us to rethink our full approach to training.
We avoid the issue by having moved completely off SL-whateverversion. At first, we just used SL2 for the most trivial of training projects; now we don't use it at all. I don't think I've even started the program in nearly a year.
Truer words, never spoken.
And not even that great as a toy due to the overhead and learning/remembering curve associated with it.
It's a fine development tool if you don't need software simulation. I would never recommend it for software simulation.
Agreed!
I tried to use Storyline as a simulator / demo tool including text entry from SL1 and re-tried it every release. It would be soooo useful if you could ask the learner to type in exactly what they should and have it look just like the text boxes in the real system. I spent quite a bit of time with Articulate developers reporting exactly how the bug performed in SL 1 and SL 2 and it was reported fixed a couple of times. Alas, not so. Apparently it still misbehaves, ignoring specific text box formatting commands and weakening the demo/simulation features.
HOWEVER, I paid my bucks and bought 360. Why? I can do my work for most client requests more effectively and faster in SL than I can in the other tools.
I've found my own workarounds for doing the simulations my clients demand--buy another expensive tool that does it right. However, there are still many good features in Storyline and the software is improving steadily. I smell sour grapes when someone on this forum calls SL a "toy" or "totally useless." These OTT comments might do one useful thing--convince Articulate that they ought to fix the problem once and for all. I don't really think it's all that tough. Just give us a method to override the default text box properties in recorded simulation text boxes.
Hi, all.
There are a lot of replies here, and some issues seem to be blending together. A quick update to sort the good from the not-so-good:
What We've Fixed
In Storyline 2 Update 10 (November 2016), we fixed 3 bugs related to text in data entry fields:
These 3 bugs should no longer be present in Storyline 2, Storyline 3, or Storyline 360. Let us know if you still see them!
What We Haven't Fixed Yet
These 2 bugs have a narrow impact or are unique to one customer:
What We Can't Reasonably Fix Right Now
Fonts for Variable References May Be Different in Published Output: We can't make variable references display using custom fonts right now because we don't know what characters a variable might use, and embedding every character in a font would seriously inflate the size of your published output.
Judging by the amount of activity on this thread yesterday, we've missed something really important (or maybe more than one important thing), and we want to help. Please click here to tell us exactly what's going wrong and we'll investigate.
We can all continue to add onto this forum thread if that's the easiest way for folks to communicate, but that may not be the best method of digging deep into individual issues.
As always, thanks for letting us know what's important to you!
Text Entry Doesn't Retain Alignment Formatting: This works OK in almost every case, including all HTML5 cases. The text entry Flash prompt is showing up in the right location, but when the learner starts typing, the text is top-aligned. We need to fix it so that the typed characters show up in the middle as well.
To throw in my two pennies, I get this issue every single time I try to insert a text entry field.
As most other people on this thread, I've stopped using them completely. Can't believe it's not been fixed in 5 years.
Good Morning, Daniel.
Click here for a 2-minute peek at what I'm seeing when I test alignment formatting in Storyline 3 or Storyline 360. Does this describe the problem you are seeing as well? Thanks!
Hi Justin,
Yes, that's exactly it. Also, inconsistent behaviour with fonts. They change size, weight and typeface randomly. For me sometimes, the font formatting will change between previews.
Dan
So are you saying projects published with Flash as the default will always display the correct font regardless of font choice?
Thanks for the clarification, Daniel. We're working on that alignment issue as we speak.
I haven't been able to reproduce a problem with inconsistent font behavior, but if you have an example of that, please do share it with us!
I apologize for the inaccuracy of that Knowledge Base link, Logan.
We won't be able to make variable references display using custom fonts in Flash OR in HTML5. I'll edit the text above, and we've updated the KB article accordingly.
If you're using Storyline 360 or Storyline 3 HTML5 output, you could try this creative JavaScript solution from community member Matthew Bibby.
This discussion is closed. You can start a new discussion or contact Articulate Support.