You guys crack me up. Forum support from Staff is excellent, so let's not bash them. Although if I see the link to that Javascript Best Practices page one more time, I might try to jump out the window! ;)
Thanks for weighing in here - and offering a few laughs. I know it can be frustrating to see the same answer in different threads or even the same threads, but we're always aware that other users may come across it who are looking for a similar answer and don't know about particular tutorials or KB articles, so we try to share those initial elements in addition to any more answers or information we have to offer.
We do appreciate the constructive feedback, and I'll share it with our community moderators team as well. In regards to the feature requests and where they stand - I know a number of folks have previously talked about wanting to see a list of all the requests, and how they're ranked. It was something we shared with our product development team and continue to discuss - just no updates or information to share at this time, as we're still not sharing the product road map in regards to features, updates or fixes.
Hope that helps put our answers and assistance here in the forums in a different light, and if there is anything we can do to assist we're happy to help.
Not really, this thread is all about the un willingness of Articulate to provide JavaScript developers documentation for all the public function and variables available through triggers or inc in js files, in order that more sophisticated solution can be provided for clients requirements. Since your reply only comments on features for the future and this clearly is not about feature request, it seems a little out of place on this thread.
If you could get the product development team to reply to this thread that would be a good start, then the community have a chance to get past the moderators (best intensions and all that) and get the ball rolling!!
Is there a reason why unlike other products, articulate product team is gaged, usually it is encouraged in most software houses,no?
Since we don't currently have the documentation or the variables that you're looking for as accessible as a feature of Storyline, nor the support for Javascript - adding in both of these things would be considered feature requests. I can share this thread with our team, as we always do for threads that become popular topics, but I cannot guarantee that they'll be able to pop in here and offer additional insight.
Storyline has JavaScript built into it through its triggers, titled Execute Javascript in the dropdown menu, there you can place javascript which runs fine, I am not sure your on the right page regarding this thread!
I'm sorry if we're misunderstanding each other. Yes - you can add an Execute Javascript as a part of the triggers, but I cannot assist with what would be in that code or what particular elements or code of the API you are looking to access. That's what I'm referring to in regards to the additional elements being feature requests in terms of documentation or expanding what the trigger window offers to you as a user when using the "Execute Javascript" trigger. If you review our Javascript best practices here you'll see that notation of our support listed along with some general guidelines and how tos.
Wow, you don't even read the threads, 'our best practices here' link is always quoted by those either at Articulate or Staff in this forum, but the users here are fed up with that standard irrelevant reply, it has nothing to do with documentation, its simply not rational to know that there are a list of functions and variables that can be used (developed by articulate software engineers) by user that have not adequate documentation.
Its not a feature, it is something the current version already has, it just requires somebody to passionate to argue the case for the users, this information which must already sit in folder somewhere at articulate software HQ, be released to the general public. It's really in inexcusable in a world filled with more API's being released to advance development of mobile apps, big data, and frameworks, that Articulate deem this information sacrosanct. After all the functions have been written and exposed to the triggers for a reason and therefore would been documented by Articulate developer to be added to the stack, so no extra work needs to be done, its already available for release.
May I make a suggestion that you ask the product manager to consult with his exec team and come back here with a rationale as to why the community cannot have access to the existing documentation, so the community can judge on its validity!
Regards
FYI, we who asks for this information know the how to's better than most and find nothing useful in the link you have provided, if you have something a little more advanced, in depth, even fresh, then I look forward to reading it.
This is something that I've itched for since SL1's early days. I suspect the reticence in releasing documentation has to do with the lack of parity between the types of players. I can see some folks getting confused about why a method fails in the Flash player.
AMP - Doesn't support any kind of player access.
Flash - Limited javascript player methods
HTML5 - Broad set of methods and properties including those you listed earlier in the thread.
It's the only thing I can figure that explains why we haven't seen documentation of the stuff available through HTML5-based player. Well... playing devils advocate... Another possible reason is that these methods could change quickly. Once you publish stuff, it's harder to reach under the hood and change things up without a lot of complaints from the user base.
That aside, I completely agree that most developers with technical depth reach point of frustration pretty quickly with the limited exposure of methods and properties in the player. Something that the player uses to update a display element or manage logic could easily be exposed for use by a trigger or through JS. So why not provide that same visibility and flexibility to the end user of the tool? Only the product manager knows the answer to that:) I'm sure the staff has a good reason. Even if it's tough to swallow by folks that have been doing this awhile.
Meant to extend this... If you go into a developer console, you can see the methods and properties for story and player through autocomplete. With a little trial and error, I've been able to uncover some handy stuff. Again, it's only HTML5 for most of these. Still handy.
Chrome > More Tools > Developer Tools > Console. Type player. in the console and autocomplete will populate with stuff to explore.
I run product operations at Articulate and thought I’d jump in to share some additional insights. First, let me state that I understand why you perceive this as an arbitrary decision. On the surface it would seem like we could just dump out a list of the system variables, disclaim their use, and let the few who know what to do with it have free rein. That seems especially possible given the couple you mentioned in this thread already.
However, the reality is that the product was not built with this level of customization in mind. In fact, as Steve mentioned the variables customers utilize only work in the HTML5 player, not Flash, and weren’t revealed by us but rather by some savvy users like him. We know that any usage of those today will at best only work in HTML5, likely won’t have the desired result, and definitely will not work in future versions. We simply can’t set our customers up to fail like that.
Whether you believe us or not, we do take input like this to heart in our product roadmap process. At this stage I can’t promise that this is an area we’ll support but I assure you that the right people are aware of the need and are considering whether it’s something we can deliver in a future-proof way that benefits the majority.
Finally, I feel like this thread has run its course. If you’d like to continue the conversation please submit a support case and ask to be connected with me directly.
Thanks for you input much appreciated, its not a question of belief, it's just a question of your willingness to help us developers working on large projects for big organisations and not the wider public, who have repeatedly asks for, but received silence or the standard reply.
So although you answer suits your policy it of course does not bring us any closer to getting documentation asked for! I left to assume that the software engineers, developed a whole bunch public classes, methods and vars, without ever explain to the team their use and integration into the core stack! So that why I am falsely holding onto the perception that documentation exist and its usefulness would before us the Javascript developers trying to get the best from your tool.
I am a strong believer in transparency and democracy especially groups of folks within the same expertise, it can do no harm to release what you have with an explicit disclaimer and no support for those developers who have asked for it and I guess we will support what we discover in your forum for others trying to push the envelope, that's how it works everywhere else, no?
Organisation like yours are usually pleased to have such an active, well informed, highly technical community and fall over backwards to supply as much as possible (not the same old link for every ask that's challenging) and reap the rewards of the additional praise, the traffic and PR this brings you free of charge. The alternative is a bunch of very influential developers working with blue chip or NGO's rubbishing off Articulate for lack of support for such a silly little thing as documentation!
But you right, since you hold control over us from a storyline development view, you can indeed decide when a subject has come to a close and cut down a thread if it becomes to troublesome.
So I guess its thanks for nothing and good bye Brian Gil
It may be possible to add a JavaScript on the slide master to interrogate the slide number (player.slideIndex) system variable and set a user-defined variable to be displayed on the slide.
If anyone does this, please post the code here. I have a 60 slide project that I've had to manually renumber slide N/M twenty times if I've done it once.
Slide number and scene number should be public variables.
The scene and slide index can be extracted. However, they might not be as useful as you'd like as they're not intended to represent literal sequence. For flexibility, it appears that there is quite a bit of abstraction in almost all of the properties of the player and slide objects.
With some work, you might have some good luck setting up your slide titles in some kind of an external table within an XML or json file. This would give you something to query against the slide title, which is easy to extract and reliable, provided that each of your slide titles were unique.
This is the biggest challenge with documenting the internal player variables. Most of them simply aren't useful to the developer without significant acrobatics.
Last year I built a Javascript Explorer that helped reveal the Javascript variables for each build. What was strange to me was that the Flash build and the HTML5 build had different APIs, but on reflection I guess that makes sense.
I really wasn't talking about system variables, so I was off-topic - sorry! These Javascript variables I am talking about reveal themselves in published projects. If you want to mess around with published projects, these Javascript variables might come in handy after-the-fact.
Mark
Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or proprietary material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender and delete it from your computer.
I know this thread is old. And looks like it got a little dicey there. But...what I'm looking for is not difficult, and is a standard function in similar products like Captivate. I just want to be able to reference some standard system variables like Date/time, Slide Number, etc. I dont think we should have to code this. Standard variables should be available in the Insert Reference function. StoryLine only returns the User Defined variables as reference items. Am I totally missing something somewhere?
Just a quick note here, I am very hard-pressed to understand why there isn't a publicly disclosed variable for slide numbers. This would come in super-handy for quiz questions. I'm sure that you folks at Articulate doing support can see just how useful that would be and yet your hands are tied from giving out that information. This is a great product and the forum staff here are fantastic, but the policy to not disclose a variable I can use in my slides that would save me a great deal of time is just gobsmacking.
As is the concept that they are not released to protect us because in the future they may change. You mean like an upgrade from 1 to 2 that means every SL1 project has to be upgraded? Have you read how hard Articulate is beating that particular horse on both sides? "You don't want the variables because they might change." "You want 360 because it will change."
63 Replies
Hunter: you must be the end user.
Balloonist: yes indeed, I am from your tribe
Hunter: Just below the gas burner, is a compass and coordinates to useful destination
eb
You guys crack me up. Forum support from Staff is excellent, so let's not bash them. Although if I see the link to that Javascript Best Practices page one more time, I might try to jump out the window! ;)
Mike,
I agree, it is.
Hi all,
Thanks for weighing in here - and offering a few laughs. I know it can be frustrating to see the same answer in different threads or even the same threads, but we're always aware that other users may come across it who are looking for a similar answer and don't know about particular tutorials or KB articles, so we try to share those initial elements in addition to any more answers or information we have to offer.
We do appreciate the constructive feedback, and I'll share it with our community moderators team as well. In regards to the feature requests and where they stand - I know a number of folks have previously talked about wanting to see a list of all the requests, and how they're ranked. It was something we shared with our product development team and continue to discuss - just no updates or information to share at this time, as we're still not sharing the product road map in regards to features, updates or fixes.
Hope that helps put our answers and assistance here in the forums in a different light, and if there is anything we can do to assist we're happy to help.
Not really, this thread is all about the un willingness of Articulate to provide JavaScript developers documentation for all the public function and variables available through triggers or inc in js files, in order that more sophisticated solution can be provided for clients requirements. Since your reply only comments on features for the future and this clearly is not about feature request, it seems a little out of place on this thread.
If you could get the product development team to reply to this thread that would be a good start, then the community have a chance to get past the moderators (best intensions and all that) and get the ball rolling!!
Is there a reason why unlike other products, articulate product team is gaged, usually it is encouraged in most software houses,no?
Hi Eric,
Since we don't currently have the documentation or the variables that you're looking for as accessible as a feature of Storyline, nor the support for Javascript - adding in both of these things would be considered feature requests. I can share this thread with our team, as we always do for threads that become popular topics, but I cannot guarantee that they'll be able to pop in here and offer additional insight.
Thanks again.
Storyline has JavaScript built into it through its triggers, titled Execute Javascript in the dropdown menu, there you can place javascript which runs fine, I am not sure your on the right page regarding this thread!
Hi Eric,
I'm sorry if we're misunderstanding each other. Yes - you can add an Execute Javascript as a part of the triggers, but I cannot assist with what would be in that code or what particular elements or code of the API you are looking to access. That's what I'm referring to in regards to the additional elements being feature requests in terms of documentation or expanding what the trigger window offers to you as a user when using the "Execute Javascript" trigger. If you review our Javascript best practices here you'll see that notation of our support listed along with some general guidelines and how tos.
Wow, you don't even read the threads, 'our best practices here' link is always quoted by those either at Articulate or Staff in this forum, but the users here are fed up with that standard irrelevant reply, it has nothing to do with documentation, its simply not rational to know that there are a list of functions and variables that can be used (developed by articulate software engineers) by user that have not adequate documentation.
Its not a feature, it is something the current version already has, it just requires somebody to passionate to argue the case for the users, this information which must already sit in folder somewhere at articulate software HQ, be released to the general public. It's really in inexcusable in a world filled with more API's being released to advance development of mobile apps, big data, and frameworks, that Articulate deem this information sacrosanct. After all the functions have been written and exposed to the triggers for a reason and therefore would been documented by Articulate developer to be added to the stack, so no extra work needs to be done, its already available for release.
May I make a suggestion that you ask the product manager to consult with his exec team and come back here with a rationale as to why the community cannot have access to the existing documentation, so the community can judge on its validity!
Regards
FYI, we who asks for this information know the how to's better than most and find nothing useful in the link you have provided, if you have something a little more advanced, in depth, even fresh, then I look forward to reading it.
This is something that I've itched for since SL1's early days. I suspect the reticence in releasing documentation has to do with the lack of parity between the types of players. I can see some folks getting confused about why a method fails in the Flash player.
It's the only thing I can figure that explains why we haven't seen documentation of the stuff available through HTML5-based player. Well... playing devils advocate... Another possible reason is that these methods could change quickly. Once you publish stuff, it's harder to reach under the hood and change things up without a lot of complaints from the user base.
That aside, I completely agree that most developers with technical depth reach point of frustration pretty quickly with the limited exposure of methods and properties in the player. Something that the player uses to update a display element or manage logic could easily be exposed for use by a trigger or through JS. So why not provide that same visibility and flexibility to the end user of the tool? Only the product manager knows the answer to that:) I'm sure the staff has a good reason. Even if it's tough to swallow by folks that have been doing this awhile.
Meant to extend this... If you go into a developer console, you can see the methods and properties for story and player through autocomplete. With a little trial and error, I've been able to uncover some handy stuff. Again, it's only HTML5 for most of these. Still handy.
Chrome > More Tools > Developer Tools > Console. Type player. in the console and autocomplete will populate with stuff to explore.
Hi Eric,
I run product operations at Articulate and thought I’d jump in to share some additional insights. First, let me state that I understand why you perceive this as an arbitrary decision. On the surface it would seem like we could just dump out a list of the system variables, disclaim their use, and let the few who know what to do with it have free rein. That seems especially possible given the couple you mentioned in this thread already.
However, the reality is that the product was not built with this level of customization in mind. In fact, as Steve mentioned the variables customers utilize only work in the HTML5 player, not Flash, and weren’t revealed by us but rather by some savvy users like him. We know that any usage of those today will at best only work in HTML5, likely won’t have the desired result, and definitely will not work in future versions. We simply can’t set our customers up to fail like that.
Whether you believe us or not, we do take input like this to heart in our product roadmap process. At this stage I can’t promise that this is an area we’ll support but I assure you that the right people are aware of the need and are considering whether it’s something we can deliver in a future-proof way that benefits the majority.
Finally, I feel like this thread has run its course. If you’d like to continue the conversation please submit a support case and ask to be connected with me directly.
Sincerely,
Brian
Brian Gil
Thanks for you input much appreciated, its not a question of belief, it's just a question of your willingness to help us developers working on large projects for big organisations and not the wider public, who have repeatedly asks for, but received silence or the standard reply.
So although you answer suits your policy it of course does not bring us any closer to getting documentation asked for! I left to assume that the software engineers, developed a whole bunch public classes, methods and vars, without ever explain to the team their use and integration into the core stack! So that why I am falsely holding onto the perception that documentation exist and its usefulness would before us the Javascript developers trying to get the best from your tool.
I am a strong believer in transparency and democracy especially groups of folks within the same expertise, it can do no harm to release what you have with an explicit disclaimer and no support for those developers who have asked for it and I guess we will support what we discover in your forum for others trying to push the envelope, that's how it works everywhere else, no?
Organisation like yours are usually pleased to have such an active, well informed, highly technical community and fall over backwards to supply as much as possible (not the same old link for every ask that's challenging) and reap the rewards of the additional praise, the traffic and PR this brings you free of charge. The alternative is a bunch of very influential developers working with blue chip or NGO's rubbishing off Articulate for lack of support for such a silly little thing as documentation!
But you right, since you hold control over us from a storyline development view, you can indeed decide when a subject has come to a close and cut down a thread if it becomes to troublesome.
So I guess its thanks for nothing and good bye Brian Gil
It may be possible to add a JavaScript on the slide master to interrogate the slide number (player.slideIndex) system variable and set a user-defined variable to be displayed on the slide.
If anyone does this, please post the code here. I have a 60 slide project that I've had to manually renumber slide N/M twenty times if I've done it once.
Slide number and scene number should be public variables.
Sam
Hey Sam -
The scene and slide index can be extracted. However, they might not be as useful as you'd like as they're not intended to represent literal sequence. For flexibility, it appears that there is quite a bit of abstraction in almost all of the properties of the player and slide objects.
With some work, you might have some good luck setting up your slide titles in some kind of an external table within an XML or json file. This would give you something to query against the slide title, which is easy to extract and reliable, provided that each of your slide titles were unique.
This is the biggest challenge with documenting the internal player variables. Most of them simply aren't useful to the developer without significant acrobatics.
Hello all,
I've been reading a lot of messages in various posts regarding variables one can use with javascript.
Does anyone know if it is possible to retrieve the number of questions that have been selected from the question databank ?
I am building a dynamic progress bar, so I'd like to get this value autmatically so as to not put in manually in the call of the function.
Also, simple question, why the automatic initial capital letter when calling a javascript function in SL2 ?
Have a nice day.
Last year I built a Javascript Explorer that helped reveal the Javascript variables for each build. What was strange to me was that the Flash build and the HTML5 build had different APIs, but on reflection I guess that makes sense.
Here's the file, have some fun exploring.
Nothing I'm familiar with Mark, but I always appreciate users popping in to share with the community, so thank you.
I really wasn't talking about system variables, so I was off-topic - sorry! These Javascript variables I am talking about reveal themselves in published projects. If you want to mess around with published projects, these Javascript variables might come in handy after-the-fact.
Mark
Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or proprietary material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender and delete it from your computer.
I know this thread is old. And looks like it got a little dicey there. But...what I'm looking for is not difficult, and is a standard function in similar products like Captivate. I just want to be able to reference some standard system variables like Date/time, Slide Number, etc. I dont think we should have to code this. Standard variables should be available in the Insert Reference function. StoryLine only returns the User Defined variables as reference items. Am I totally missing something somewhere?
Hi Heather!
A listing of system variables is not something that we have available at this time and Brian's statement above sums it up best.
Just a quick note here, I am very hard-pressed to understand why there isn't a publicly disclosed variable for slide numbers. This would come in super-handy for quiz questions. I'm sure that you folks at Articulate doing support can see just how useful that would be and yet your hands are tied from giving out that information. This is a great product and the forum staff here are fantastic, but the policy to not disclose a variable I can use in my slides that would save me a great deal of time is just gobsmacking.
As is the concept that they are not released to protect us because in the future they may change. You mean like an upgrade from 1 to 2 that means every SL1 project has to be upgraded? Have you read how hard Articulate is beating that particular horse on both sides? "You don't want the variables because they might change." "You want 360 because it will change."
You mean "slide-number" as a variable might change? Or maybe something more obscure like "aaa-slide-number" might change?
Can we get real for a minute? Why can't I just do %SlideNumber% and get the slide number?
how is this still an issue 4 years after it was first mentioned?
This discussion is closed. You can start a new discussion or contact Articulate Support.