Text variable references showing through when variable is empty

Hi,

Just upgraded to Storyline 3 from SL2 and I'm encountering some odd results having likewise upgraded my courses (built in SL2).

Throughout my course I have text-entry boxes acting as note capture fields, and the text variable created on first use is then re-called in other parts of the course so the user can update that note having developed their thinking.

In SL2 I was able to simply enter the variable reference (e.g. %LeisureDecisionsFree%) as text in the text-entry box while building and then when published it would be invisible until the user had input something (changing the value of the variable from nothing to something in other words). Having published as HTML5 only, as per the screenshot below I'm now seeing the variable reference appear everywhere.

Any thoughts (that hopefully don't require me to do something to every single text-entry box I've got as there are loads!)?

Cheers,

Matt

screenshot

 

 

10 Replies
Matt Stafford-Clack

Hi Alyssa,

Sorry I missed your reply - I've resolved the problem now. In the end I had to replace the variable reference "text" (%VariableName%) with either something like "Enter Text Here" or set the default variable value to a space character.

It looks as if SL2 and SL3 have different ways of resolving variables (specifically text variables occurring in a text entry field, as opposed to say appearing as text in a text box or on an object) without a default value? To lay out the apparent logic:

  • SL2 reads the variable name, looks for a default value, returns nothing as the value if no default is found.
  • SL3 reads the variable name, looks for a default value, returns variable name as the value if no default is found.

Whether that's any help to anyone your side I have no idea!

Also spotted something that might be a bit of a bug this morning, though I've already put a workaround in place so no worries. I had a slide with a menu layer calling up sub-menus on further layers, and those sub-menus each had a trigger to hide themselves and pop-up the primary menu when the users clicked outside their boundary.

Problem was I had another layer on the same slide with a text-entry field and when you tried to enter text it would hide itself and pop-up the primary menu layer I mentioned above. Drove me absolutely batty for a while until I figured out it was the 'click outside' behaviours on the other layers being triggered by trying to enter text (and it was only entering text that caused it, clicking anywhere else was fine). No idea why but removing those triggers (they were redundant as I already had a close button anyway) fixed the problem.

Cheers,

Matt

 

Alyssa Gomez

Hey Matt,

Thanks for sharing your discovery about how variable references within text entry fields are handled in Storyline 2 and Storyline 3. I actually haven't come across an example of a variable reference in a text entry field before (only regular text boxes), so this was a new one for me.

I'm interested to hear a bit more about the buggy behavior you mentioned. I'm having a bit of trouble visualizing your set-up, so would you mind attaching a sample slide to this discussion thread? I'd love to take a closer look! 

Ashley Terwilliger-Pollard

Hi Matt,

Thanks for sharing your example file here. For the first slide, I saw the behavior your describing, in that you can't click inside the text entry. I also tried to test out your workaround, and removing the "click outside" triggers on both layers did solve it.  It does seem our team is aware of a couple issues with the clicks outside trigger, so I'll share your example as a part of that. 

Additionally, for the variable reference on a text entry, that's something that my colleague Crystal had a cool method to help with here. Take a look at that and let me know if that also helps with your set up! 

Matt Stafford-Clack

Hi Ashley,

Interesting read, looks like I was in the right area with it being about how empty text variables are handled. In terms of effort removing the %Blah% that I'd typed in would have been about the same as overtyping with "Enter your text here" (which is what I did in the end) but I'll bear that in mind for the future.

If you want a really fun one to wrap your thinking gear around, any idea how to stop the HTML formatting showing through in (some) text-entry boxes as per the below screenshot? It disappears as soon as you start typing but I still get occasional reports from disturbed users who think something horrible, rather than superficial, has happened.

Like all the funnest problems: it's not consistent (happens in some text boxes and not others despite the same settings etc.); I can't replicate it in my environment; it only happens to a very few users; and those users aren't limited to a single browser.

Enjoy!

screenshot

Ashley Terwilliger-Pollard

Hi Matt,

Thanks for that screenshot - I know I've seen others run into the same issue before, and I believe it was connected to the browser and output type the user was viewing (HTML5 vs. Flash). Do you know any more about the users who this does happen too? Also are you only seeing this on your Storyline 2 or 3 content, or both? 

I'm looking for the similar reports I saw of this before, but my searching skills are failing me today. 😕 

Matt Stafford-Clack

Hi Ashley,

Unfortunately I have no details of the browser set-ups used - I tend to get reports passed to me shorn of user contact details. This was happening with SL2 (Published Flash with HTML5 backup) but I have held off releasing our SL3 version into the wild - I've been seeing some problems with an HTML5 only version requested by a client (very ahead of the times in just how anti-Flash they are!). For example it reliably crashes mobiles phones

My LMS folks have confirmed everything is loading properly, eventually, so I believe it's related to the pre-loading activity Articulate undertakes (current slide, next three, the rest). Since it was working before I'm wondering if there any difference between how pre-loading is handled for Flash and for HTML5?

The course size we're talking about is less than 100MB, but a huge amount of that is MP3 audio files containing narration, some individually pretty large.

Matt

Ashley Terwilliger-Pollard

Hi Matt, 

We've seen some reports of crashing on iOS Mobile safari, and a lot of it is based on the way safari handles data and cached copies of content.

We've been looking at improvements in this and recently released some in Storyline 360 which will roll out to Storyline 3 in the next update (later this quarter).  We've also seen the issue appear more frequently for users who are using custom fonts in their Storyline courses - does that sound like what you could be experiencing? 

As for the HTML formatting showing through, my guess is that the users could be using a non supported browser or version. You may want to instruct folks to use one of the browsers here and it'll depend on if they have Flash enabled in their browser or not. 

Let us know if you're able to narrow down the browser further, or if you can test it in Storyline 3 to replicate the same behavior. Storyline 3 offers a broader set of supported browsers so that would be curious to see how it behaves. 

Crystal Horn

Hey everybody. I'm excited to let you know that we just released update 3 for Storyline 3! It includes new features and fixes - check them all out here.

One of the fixes addresses an issue where in the HTML5 output, the trigger "when clicking outside an object" on the base or slide layer seemed to be firing even if you are not on the layer where the trigger resides.

Here’s where you can download and install the latest version of Storyline 3. Let me know how you make out!