Storyline 2: Caveat, Critique and Request

Ok, let me preface this by saying that I have been a loyal Articulate customer for about 7 years now.  I have dutifully upgraded and migrated from early Articulate to SL2.  I've developed scores of increasingly sophisticated modules with the products.  We've also been a long term AO client as well.   I've always been impressed with the prompt customer service and the amazing community that's been built around the offering.  I remain a huge fan.

That being said, beyond a certain threshold, SL2 doesn't work.  Granted, that threshold is a big one that 95% of users don't cross.  But here's the problem: SL2 is too good not to push to that threshold.  SL2 crosses into a realm of advanced user experience and has the potential to really change the learner experience in the hands of the right designer.  But once you do cross the threshold, whether it be size or complexity, the application becomes unstable.  I've experienced this over the last few months working on a nextgen project and have followed the 'repair' advice at least fifty times.  I must uninstall 10 times a day.  I have followed every scrap of advice in the threads like a starving man trying to get my project to alternately save/publish.  Yes, my project is big but I have more than the system requirements and have followed every protocol about publishing locally etc.  It just doesn't work.  I don't know whether the app designers were too ambitious or the coders unable to execute but there's a disconnect with SL2 at the margins which will stifle its development until it is made more stable.

Here's my request.  Is is possible to provide an honest list of factors that lead to error messages/crashes/etc?  Surely you have log reports and could advise on what causes crashes more often than not?  For example, after wasting hours, I discovered a thread on how the logo as png could crash the app.  Knowing that would have saved me those hours.  I now have a project I must essentially rebuild yet again because while it published yesterday morning, it would not publish in the afternoon after a few minor tweaks.  I don't believe I am the only one in this situation.

Please do not respond with a "let's open a support ticket for this" offer.  It isn't related to a single instance but a series  of them.  I could be opening tickets for weeks.  Just give me a guide to what might cause crashes so I can avoid these and I'd be ever so grateful.

Again, I'm a fan and supporter and I am trying to offer a constructive critique based only on my experience as a relatively well-informed operator.  Other user experience may vary.  Thanks for your patience AND an (almost) great product!

3 Replies
Ashley Terwilliger-Pollard

Hi Bud,

Thanks for reaching out here and being such an avid user and fan of Articulate. We're happy to have you as a part of our community as well! 

In regards to your specific query about SL2 and the experience you've been having, I wanted to offer some thoughts, ideas and solutions here for you. 

First, in regards to your large files, here are a few suggestions to consider:

1. If the file size is continuing to increase and getting larger with every change, I'd look again to what you're adding and how large those files are. If it's a very media heavy course, that will be something to look at in terms of ways to reduce a heavy load on the program 

2. To help with media heavy courses, look into videos that can stream over the internet, likely in the 2-3 mbps bitrate range, and especially when inserting videos ones that have a smaller duration and spreading multiple videos out over a few slides. 

3. Look at using more slides if adding a lot of elements to one slide. Storyline preloads content in the published output, to help handle larger courses and decrease playback delays but when going through a preview or timeline preview, it'll have to load all the elements for each slide before it can continue. 

4. As you mentioned, always working from your local drive and following the general guidelines here.  We likely sound like a broken record the number of times you've seen this in the forums - but it's often the stem of many of the issues we see. 

5. Close down other programs or applications. If the Storyline file is growing in size and being unruly when it comes to working in the application or trying to publish, I try to close down anything else that could be taxing the system and give all the power to Storyline. 

If there are specific issues or features you'd like to see, we are always happy to discuss here and get insight from multiple community members but the best way to keep track of them and ensure they're filed correctly with our Product development team is to submit a feature request.  There is no limit to the number you can submit and your honest feedback is what we're looking for! 

Lastly, I know you mentioned you didn't want to be told to submit a support case, and I didn't see a recent one for you in regards for the SL2 issues you've been having. Submitting a support case is really the best option for our team to understand and take a look at the issues you're experiencing, and based on what we find out, report to our Quality Assurance team as necessary to get solutions or fixes in place. 

For example, you asked about error messages/crashes, and we do have a process in place to pull those error logs and share with our team. Other error messages that are reported and our team investigates are then documented such as the example here in regards to the "The project cannot be saved" error. 

If you want us to take a look at anything, please let us know. We're also happy to try test publishing one of your files  - and if they're as big as you say, it may be easier to send it along to us here.  If you do go that route, please let me know the case number so that I can follow along as you work with our Support engineers.