I have been building Storyline content and sharing it with team members using Tempshare, where everything has been working fine. I now need to host content permanently so have started to use Amazon s3. After launching the content from s3 i have noticed that some of the interactions are not working anymore. Rollovers that reveal a popup work in some locations but not others. It turns out that they work locally within the Storyline software and they work when zipped and uploaded to Tempshare, but not when the content is launched from the project output folder in a browser and not in s3 (as it is just a copy of the output folder). Any idea as to why this may be the case?
Amazon S3 is a great option for hosting content - glad to hear you're giving it a try! When you set up your account, did you follow the steps Tom outlined in this blog post and video tutorial? Are you using a supported browser to test the URL for the story.html file?
Thank you for the response. The problem isnt with s3. I thought it was initially but thats actually working as it should. The issue is with Storyline. The output from the project is working differently when its zipped versus when its not. The zipped content, uploaded on to Tempshare, works as it should. The output folders, not zipped, when launched in a browser are not working the same way. Some of the interactions are not responding. Is there any reason why the same content is only working correctly when its compressed?
Thanks for that information. So it sounds like Tempshare and Amazon S3 are working well for you, and you're only having issues when you are launching "not zipped" folders in a browser - is that correct?
If you view an Articulate Storyline course on your local hard drive, meaning you double-click on the story.html file from the published output to launch the content in a browser, you'll encounter security restrictions from the computer, web browser, Flash Player, and network that'll cause various features of your content to fail. To properly test your published content, you'll want to upload it to the environment for which it was published.
If you publish for Web, upload it to a web server like Tempshare or S3 (like you've already done)
If you publish for LMS, upload it to SCORM Cloud for testing
If you publish for CD for offline viewing, double-click the Launch_Story.exe file in the published output to view the course
I hope that helps, and please let me know if you have any further questions!
I have done this already. The content that is not working correctly when launched locally into a browser behaves the same way when uploaded to s3. The same issues in the same places occur. So it looks like the only way to get material published for web to behave as it should is to zip and upload to Tempshare. I need to be able to host this permanently. Any ideas? Any other examples of web content only working correctly when zipped?
You should be able to host permanently in Amazon S3 as long as you're using a supported browser to view the content hosted there - it's just a matter of pinpointing why it's not working for you. Would it be possible for you to share a screencast or screenshots of your steps? You're also welcome to work directly with our Support Engineers to troubleshoot this further. If you would like to open a case, simply fill out this form and let me know your case number so I can follow along, as well.
I can host permanently on s3. I have content up there working fine apart from the issues im talking about here. The content that is not working locally when published for web, is not working when its up on s3 either. Ill fill out that form and see if they can give me a hand. Thanks for your help Alyssa.
Hey Patrick. I've seen this behavior before. While AWS is a great tool, it does come with some challenges. What I discovered was that it was a permissions problem with some files. Normally when using an FTP server you upload and things go smoothly and permissions are predictable. Unfortunately with AWS this is not the case. Once I've uploaded my files to AWS I go through each file and folder to make sure the permissions are correct. I've yet figured out why this happens and why it is so unpredictable but it does happen.
Hi Michael, thanks for the response. The issue is with Storyline not s3. The things that are not working are present in the output from Storyline and then reflected in s3 when uploaded.
I'm sorry about that, Patrick. From the looks of Articulate Status, the case form is fully operational. I see that you were finally able to open a case (00990185 for my records), and that you're working with Angelo. I'll check in and share updates here as they're available.
Patrick, would you mind sharing a bit of information that will help us diagnose the error message you received when you tried to submit a case? It would be helpful for us know to what browser, browser version, and operation system you're using. Thanks in advance!
Where can i see my case number and who is dealing with my case? I have not received any response from the system or from Angelo?
Regarding the above: when i tried to submit a case i would fill out the form and try to attach a project file but when i clicked next i would receive a blank page with "the website cant be reached" on it. I tried a few times then tried without an attachment and it worked. It was a large project file so maybe that was the problem.
I think i spoke to soon, my apologies, i was losing patience with the process. I reckon it could be a permissions issue after all. The hyperlink triggers work fine on Tempshare, which is s3 hosted, so it must be possible to do the same on my own instance of s3. Im looking through my project files and folders trying to find something that isnt public but cant find anything.
Solved. It was being caused by two issues. One was permissions based. As Michael described (THANK YOU!!!) some of the content in subfolders was not being made public using group permissions, particularly the contents of the slides folder in story_content. I had to do them again. Secondly, i had been changing the story_html5 to index and launching through that URL. Again, no good. I watched Toms blog post and he was launching using story.html and hey presto! Functionality returneth :D Thanks for your assistance Alyssa.
It looks like Angelo reached out requesting your file on January 13th. Check your Spam/Junk folder to see if an email from support@articulate.com has been moved there. If it has, you should move the mail from your Spam/Junk folder and add the contact as a safe or allowed sender in your Spam/Junk settings and also add the sender as a contact in your address book.
In any case, I'm so glad you finally got it sorted! Let me know if there is anything further I can do to assist!
18 Replies
Hey there Patrick!
Amazon S3 is a great option for hosting content - glad to hear you're giving it a try! When you set up your account, did you follow the steps Tom outlined in this blog post and video tutorial? Are you using a supported browser to test the URL for the story.html file?
This post was removed by the author
Hi Alyssa,
Thank you for the response. The problem isnt with s3. I thought it was initially but thats actually working as it should. The issue is with Storyline. The output from the project is working differently when its zipped versus when its not. The zipped content, uploaded on to Tempshare, works as it should. The output folders, not zipped, when launched in a browser are not working the same way. Some of the interactions are not responding. Is there any reason why the same content is only working correctly when its compressed?
Hey Patrick,
Thanks for that information. So it sounds like Tempshare and Amazon S3 are working well for you, and you're only having issues when you are launching "not zipped" folders in a browser - is that correct?
If you view an Articulate Storyline course on your local hard drive, meaning you double-click on the story.html file from the published output to launch the content in a browser, you'll encounter security restrictions from the computer, web browser, Flash Player, and network that'll cause various features of your content to fail. To properly test your published content, you'll want to upload it to the environment for which it was published.
I hope that helps, and please let me know if you have any further questions!
Hi Alyssa,
I have done this already. The content that is not working correctly when launched locally into a browser behaves the same way when uploaded to s3. The same issues in the same places occur. So it looks like the only way to get material published for web to behave as it should is to zip and upload to Tempshare. I need to be able to host this permanently. Any ideas? Any other examples of web content only working correctly when zipped?
You should be able to host permanently in Amazon S3 as long as you're using a supported browser to view the content hosted there - it's just a matter of pinpointing why it's not working for you. Would it be possible for you to share a screencast or screenshots of your steps? You're also welcome to work directly with our Support Engineers to troubleshoot this further. If you would like to open a case, simply fill out this form and let me know your case number so I can follow along, as well.
I can host permanently on s3. I have content up there working fine apart from the issues im talking about here. The content that is not working locally when published for web, is not working when its up on s3 either. Ill fill out that form and see if they can give me a hand. Thanks for your help Alyssa.
Hey Patrick. I've seen this behavior before. While AWS is a great tool, it does come with some challenges. What I discovered was that it was a permissions problem with some files. Normally when using an FTP server you upload and things go smoothly and permissions are predictable. Unfortunately with AWS this is not the case. Once I've uploaded my files to AWS I go through each file and folder to make sure the permissions are correct. I've yet figured out why this happens and why it is so unpredictable but it does happen.
Thanks for that insight, Michael. I have not experienced that myself, so I appreciate you for popping in to share.
I'm not seeing a case number listed under your name, so please feel free to share the case number here once you finish filling out the form. Thanks!
Hi Michael, thanks for the response. The issue is with Storyline not s3. The things that are not working are present in the output from Storyline and then reflected in s3 when uploaded.
Alyssa, when i try to submit my case im told "the site can not be reached". Whats the problem?
Hi Patrick,
I'm sorry about that, Patrick. From the looks of Articulate Status, the case form is fully operational. I see that you were finally able to open a case (00990185 for my records), and that you're working with Angelo. I'll check in and share updates here as they're available.
Patrick, would you mind sharing a bit of information that will help us diagnose the error message you received when you tried to submit a case? It would be helpful for us know to what browser, browser version, and operation system you're using. Thanks in advance!
Hi Alyssa,
Where can i see my case number and who is dealing with my case? I have not received any response from the system or from Angelo?
Regarding the above: when i tried to submit a case i would fill out the form and try to attach a project file but when i clicked next i would receive a blank page with "the website cant be reached" on it. I tried a few times then tried without an attachment and it worked. It was a large project file so maybe that was the problem.
Hi Michael,
I think i spoke to soon, my apologies, i was losing patience with the process. I reckon it could be a permissions issue after all. The hyperlink triggers work fine on Tempshare, which is s3 hosted, so it must be possible to do the same on my own instance of s3. Im looking through my project files and folders trying to find something that isnt public but cant find anything.
Solved. It was being caused by two issues. One was permissions based. As Michael described (THANK YOU!!!) some of the content in subfolders was not being made public using group permissions, particularly the contents of the slides folder in story_content. I had to do them again. Secondly, i had been changing the story_html5 to index and launching through that URL. Again, no good. I watched Toms blog post and he was launching using story.html and hey presto! Functionality returneth :D Thanks for your assistance Alyssa.
Hi Patrick!
It looks like Angelo reached out requesting your file on January 13th. Check your Spam/Junk folder to see if an email from support@articulate.com has been moved there. If it has, you should move the mail from your Spam/Junk folder and add the contact as a safe or allowed sender in your Spam/Junk settings and also add the sender as a contact in your address book.
In any case, I'm so glad you finally got it sorted! Let me know if there is anything further I can do to assist!
There is one thing, if you're ever in Ireland look me up and lets go for a drink ; )
This discussion is closed. You can start a new discussion or contact Articulate Support.