I am using Storyline 360 and have an issue with the Numeric Entry box being populated by a zero when the slide starts. I have Googled this issue but every discussion is over 5 years old. Has there ever been a fix for this? I want the box to be blank when the slide starts, not have the user continually delete the zero before entering their value.
When you add a numeric entry field, the field should be blank by default unless there's a trigger changing its value.
I'm happy to take a look at your .story file to see what's going on. Are you able to share it either publicly here or privately through a support case?
Thanks for your response. I have just set up a brand new numeric entry with the only trigger being the one to store the variable and when I run the slide there is zero in the box. I can share the .story file (not publicly) but it is 400Mb (it is a huge project with lots of video content). Would that still be okay to send?
If you want to upload a smaller and more manageable file, you can either import the specific slide to a new project or duplicate the file, then delete the slides that are not relevant.
Thank you for sharing one of your slides as an example. I was able to reproduce what you're experiencing and noticed that if I create a new Numeric Entry and don't change the variable's name, the value remains blank.
This seems to be related to a bug we already have logged where The initial value of 0 is shown on a data entry field if the default variable is changed. The workaround is to keep the name of the default variable created instead of renaming it.
I am connecting this discussion to the bug report, and we'll keep you updated on any development.
Thank you for the update. Shocking that there hasn't been a fix for this yet. I have over 400 numeric input boxes across my project, with lots of triggers checking the inputs. No chance of renaming them back now and even moving forward, this is going to be a blockage as the boxes are appropriately named dependent on the area of the project. Fingers crossed this gets resolved soon. Thank you Maria.
We have prioritized other bug fixes for our upcoming releases, so this bug isn't currently being worked on. We'll report back to this discussion when a fix is slated for an upcoming release.
Just adding my voice as desiring a fix for this bug as well. I have a piece with about 50 numeric entries that initialize with 0 instead of blank. I've received several complaints from users having to backspace that out before inputting their data. That works but it would be nice if they didn't have to do that.
This is Articulate, not Google. They don't fix problems here, they just let us rant about them for years knowing they can charge us $1k/yr and then give platitudes of customer service...
Is there any chance Articulate could give us, the people who pay their salaries, an idea of how bugs are prioritised? It appears that the system in use at this moment is not working,
PS. not that I am expecting a reply (Prove me wrong)
Thanks for checking in on this and sharing your feedback!
This article goes into more detail on how we tackle bugs. I don't have any updates to share at this time as our team has been prioritizing other fixes, but I've included your notes in the bug report and will update this discussion as soon as we have news to share.
We appreciate your patience and apologize if this issue has been slowing you down!
Apologies but this is laughable at best. This bug has been present for literally 5+ years and it hasn't been addressed. This objectively means you do not care.
Not even a simple explanation in the thread can explain their INCOMITANCE at prioritising bug fixing. Coming from a software development background, If we had taken 5 years to even prioritise a bug we would be out of business.
It is obvious they have not addressed this issue in anyway shape or form, or they would be able to tell us were in the development phase the issue is.
So, let see, this bug is 5 years or more old what other bugs older than this are still being prioritised that we have reported to them?.
Stop dancing around and just fix the dam issue, seriously, if the fix is going to be more than 1 or 2 lines of code I will be surprised.
Hey Everyone! I found out a way to get around this issue. Works for me, hopefully for you too. If I set up a brand new numeric entry in the Base Layer (hope that's the name in English!) when I run the slide there is a zero in the box. BUT if I create it on an additional layer, the exact same one (even copying and pasting the original), the box looks empty upon running the slide, no famous zero in sight. (I'm from Chile, apologies for the Spanglish!). All the best! Andres.
Hello, I am also encountering this issue. I have a large number of text entries in my course. This would be a helpful fix so the learner does not accidently forget to delete the zero and receive a fail when submitting.
22 Replies
Hi, Tony.
Thanks for reaching out!
When you add a numeric entry field, the field should be blank by default unless there's a trigger changing its value.
I'm happy to take a look at your .story file to see what's going on. Are you able to share it either publicly here or privately through a support case?
Hi Maria
Thanks for your response. I have just set up a brand new numeric entry with the only trigger being the one to store the variable and when I run the slide there is zero in the box. I can share the .story file (not publicly) but it is 400Mb (it is a huge project with lots of video content). Would that still be okay to send?
Hi, Tony!
If you want to upload a smaller and more manageable file, you can either import the specific slide to a new project or duplicate the file, then delete the slides that are not relevant.
Here is a slide from my project. There are quite a lot of slides with this format of testing. Everything works except for removing these zeros.
Hi, Tony.
Thank you for sharing one of your slides as an example. I was able to reproduce what you're experiencing and noticed that if I create a new Numeric Entry and don't change the variable's name, the value remains blank.
This seems to be related to a bug we already have logged where The initial value of 0 is shown on a data entry field if the default variable is changed. The workaround is to keep the name of the default variable created instead of renaming it.
I am connecting this discussion to the bug report, and we'll keep you updated on any development.
Thank you for the update. Shocking that there hasn't been a fix for this yet. I have over 400 numeric input boxes across my project, with lots of triggers checking the inputs. No chance of renaming them back now and even moving forward, this is going to be a blockage as the boxes are appropriately named dependent on the area of the project. Fingers crossed this gets resolved soon. Thank you Maria.
Has there been any progress in the past 7 months fixing this bug?
Hi Rick!
We have prioritized other bug fixes for our upcoming releases, so this bug isn't currently being worked on. We'll report back to this discussion when a fix is slated for an upcoming release.
Just adding my voice as desiring a fix for this bug as well. I have a piece with about 50 numeric entries that initialize with 0 instead of blank. I've received several complaints from users having to backspace that out before inputting their data. That works but it would be nice if they didn't have to do that.
It has been more than 5 years. How long does it take to prioritize. :-(
It would be great to get this fixed! I can't leave all of my text entries as the default name, there are too many to keep straight
Checking to see if there is an update on this? Is there an ETA on the fix for this bug? We have multiple modules with numeric entry fields.
to create a variable for a numeric input field is a little bit special
https://community.articulate.com/discussions/articulate-storyline/numeric-entry-not-defaulting-to-blank-but-worked-earlier-this-year
yes please fix this bug. storyline is horrible about the timeliness of fixing problems.
I have currently run into this issue. Is there an update on when this will be fixed?
This is Articulate, not Google. They don't fix problems here, they just let us rant about them for years knowing they can charge us $1k/yr and then give platitudes of customer service...
Is there any chance Articulate could give us, the people who pay their salaries, an idea of how bugs are prioritised? It appears that the system in use at this moment is not working,
PS. not that I am expecting a reply (Prove me wrong)
Hi Martin!
Thanks for checking in on this and sharing your feedback!
This article goes into more detail on how we tackle bugs. I don't have any updates to share at this time as our team has been prioritizing other fixes, but I've included your notes in the bug report and will update this discussion as soon as we have news to share.
We appreciate your patience and apologize if this issue has been slowing you down!
Apologies but this is laughable at best. This bug has been present for literally 5+ years and it hasn't been addressed. This objectively means you do not care.
Brian, I absolutely agree.
Not even a simple explanation in the thread can explain their INCOMITANCE at prioritising bug fixing. Coming from a software development background, If we had taken 5 years to even prioritise a bug we would be out of business.
It is obvious they have not addressed this issue in anyway shape or form, or they would be able to tell us were in the development phase the issue is.
So, let see, this bug is 5 years or more old what other bugs older than this are still being prioritised that we have reported to them?.
Stop dancing around and just fix the dam issue, seriously, if the fix is going to be more than 1 or 2 lines of code I will be surprised.
Hey Everyone! I found out a way to get around this issue. Works for me, hopefully for you too. If I set up a brand new numeric entry in the Base Layer (hope that's the name in English!) when I run the slide there is a zero in the box. BUT if I create it on an additional layer, the exact same one (even copying and pasting the original), the box looks empty upon running the slide, no famous zero in sight. (I'm from Chile, apologies for the Spanglish!). All the best! Andres.
This post was removed by the author
Hello, I am also encountering this issue. I have a large number of text entries in my course. This would be a helpful fix so the learner does not accidently forget to delete the zero and receive a fail when submitting.