Storyline Best Practices

I've been asked by a client to come up with a list of best practices for Storyline development.  Would anyone care to add or edit?

Begin with the end in mind

• Know your audience. What devices will they be viewing on. What’s the demographic? What’s the optimal screen size? Does it include an “ever-present” menu, or will the menu be a drop down? What fonts will work and at what sizes on the desired device?
• Define your learning objectives. This mat seem like it has nothing to do with Storyline development, however, when you design a course with Storyline in mind, you can create content that leverages Storylines unique set of features. Rather than just designing a course then trying to make it fit into what Storyline does well. We ALWAYS include a developer in the design stage of the process, with frequent brainstorming sessions and reviews. More than once, we have received a storyboard with content that was just un-buildable. So avoid that.
• Clearly outline your development process and review cycles. Ideally, we do not begin full development until a FINAL storyboard has been signed off on. The earlier in the process that edits are caught and made, the easier and less costly they are. If Rapid Development is the goal. This is the key to making that possible.
• Design the GUI (Graphic User Interface) and Style Guide before Instructional Design begins. We always design a style guide for a course or set of courses. That way, the instructional design team can have a feel for how the final course will look As they design. It heads of problems and informs design decisions.
• Storyboard/Design Document. Ideally courses are Instructionally designed within Storyline. This allows the designers to use the actual template that the course will be built in. It also allows developers to quickly and roughly prototype working interactions and scenarios. We do not expect Instructional Designers to be able to “Develop” a storyline course, but adding text, script and basic shapes allows them to see and build out a course as it will be in the final versions. This also drastically reduces the amount of time taken in either importing a storyboard from PPT or a 3-coloum word format.
• If Storyline is not an option for storyboarding your course. Use PowerPoint. We duplicate the course template, look, feel, layouts etc in PowerPoint, again, allowing the Instructional Designers to give a good approximation of what the final course will look like. We use the “Notes” field in PPT to contain any voice over that will be recorded. This script is exported from Storyline and sent straight to the VO artist. So only include text that you want recorded.
• If using branching, set that up in the Powerpoint. Add a visual button with an “Action” that takes it to the slide you desire. That navigation will import directly into Storyline, making development faster, easier and more cost effective.
• We still follow the basic 3 column Instructional design format (Script, On-screen, Developer Instructions), we just adjust it to fit with the software.

Script - Goes in the notes field

On-screen - Goes in the main screen area. Text, visuals, anything that will appear on that page.

Developer Instructions - Create a specific area off to the right or left of the main screen. This area will contain any specific instructions to the developer. i.e. Timing, interactivity, preferences, client requests. It should be clean, clear, bullet points, leave nothing to interpretation.

• Storyline has had a few bugs over the years. One of the worst being that it can run out of memory. That means you cannot save your work. You lose everything from the last save, and there’s no way around it. The most robust solution we have found is to run Storyline in Windows 8 64-bit.

Setting up the template

• Before you start developing, make sure your fonts, colors, slide masters and player settings are correct. Changing any of these in a developed course can have catastrophic consequences.
• Think about your content. Smaller scenes are easier to deal with, so look for natural breaks in the content that will allow you to split it into different scenes.
• Remember, the better the template is built, slide layouts, feedback masters, design rules etc. The faster you will be able to develop.
• Turn on the on-screen guides, and line them up at important places on screen. You can drag them to the right spot, and create more of them by holding the control key down while dragging. This will allow you to quickly position and align key elements, as well as making sure that things stay in the same place from page to page.

Starting Development

• Once you have the basic structure and template of the course built, begin designing or importing the course.
• If importing from PPT, you can import different PPT Sections into separate Storyline Scenes.
• PPT ALWAYS imports slides with a trigger that automatically forwards to the next slide when the timeline ends. Select all the slides in the Story View and change the Slide Properties to “Slide Advances Manually."
• Get into the practice of naming EVERYTHING correctly. Elements in the timeline, layers, slides, scenes. When setting up triggers and conditional logic using variables, a well thought out naming convention will save you time and sanity.

Timeline

• If you are adding voice-over. Make sure your script is final. Then publish the course as a word file. That way, the VO artist can be recording voice over while the course is being developed. When you get the audio back, split it and label it with the slide number. i.e. 1.2, 1.3 etc. Also, if you are creating a build, split the audio by each part of the build. So if there are 4 parts on a slide, then you would have 4 audio clips. i.e. 1.2a, 1.2b… It can become cumbersome to develop long slides in storyline. So importing the parts of a build separately gives you a clear visual in the timeline without having to scrub through to find the right spot to sync an event or animation.
• The timeline is SL can become cluttered. So name everything.
• Work from bottom left to top right. Place the objects that come on screen first at the bottom of the timeline and work towards the top. In longer slides, this will help you. As you move further along the timeline, you reduce the need to scroll up and down by putting the later objects at the top. (See attached screenshot)

Functionality

• Wherever possible, work WITH SL's built in functionality. e.g. Don’t delete feedback slides on a question and ad your own. Instead, use the feedback slide masters to design your feedback the way you want. There’s frequently a lot more going on in the background that you realize. So editing SL’s inate functionality can cause major issues later on.
• Always keep it simple. Almost all the time, the simplest way to teach something is the best. That follows in Storyline. Keep triggers and variables to a minimum. Always look for the simplest most elegant way to do something. It takes time to run triggers and inspect variables in the final published course. Having too many of them can result in laggy, glitchy course that run poorly and are a nightmare to edit, QA and maintain.
• Transitions. Pages and layers have transitions. They allow content to fade in nicely from one page or one layer to another. What they also do is stop any triggers from running until the transitions have finished. As standard, we turn all page and layer transitions off. This results in quick, clean movement from one to the other. If we need to fade something in, we use an animation on the object.

File Management

• SAVE OFTEN! This should become second nature, but save at least at the end of every page.
• BACK-UP Everything! Make sure you have a redundancy system.
• Use a version nomenclature. e.g. mycourse_v1. This accomplished a lot of things. First, it means that you have multiple files. If something goes bad, you always have an earlier version. Update the number EVERY time you make a major change or update to the file. If you are collaborating, make sure that only 1 person is working on a file at one time. From the moment development starts, there should only EVER be one live file. No duplicate documents, lost changes, overwritten work.