Articulate - There's a lot to be said about simplicity - Pt 1

At the time of writing, I am over 10 months into an Instructional Design contract with a major New Zealand Government department (Accident Compensation Corporation) in a role that was heavily focused for the first 6 months on using Articulate Storyline to develop eLearning modules for use in their Totara LMS. I was hired despite the fact that I had never used Articulate before - something the people hiring me were aware of and not concerned about, given my background and experience.

The article is about using Articulate Storyline daily over those initial 6 months and on an ongoing occasional basis; of how easy it was to learn, create content and effective interactions; to produce dynamic HTML5 accessible resources...and to sometimes wish for more. It's also about my experience in relation to interaction and involvement with Articulate and its community website.

I confess that the very first thing that came to me when writing this article was the title. Now that I see the length of the article I have written (to be delivered in two parts) there's an unintended double meaning to the phrase "there's a lot to be said". But the title came about early on, because I can sum up my opinion of Storyline and what I want to discuss in this article in one word…Simplicity.

But simplicity in this instance is a double-edged sword.

Introduction

Over the course of this article I'm going to explain why simplicity can have both positive and negative connotations, and why simplicity can be both a powerful ally in producing advanced content...and why it can also hinder those exact same processes. This article is about my perceptions of and experience with Storyline 360 and is solely my opinion. It's not a detailed introduction to Storyline, nor is it an in-depth shoot-out between it and Adobe Captivate, despite how often I compare them. These are not two dissimilar products...but there are differences that might ultimately determine which you prefer. The intention of this article is to provide you with some food for thought if you are contemplating using Storyline, particularly if you are coming from (like me) an Adobe Captivate background.

At this point a disclaimer or disclosure of sorts. I'm a former Adobe Higher Education Leader (the first in New Zealand) and have used Adobe Captivate for well over a decade. But read recent articles here on my site and you'll know I don't look at the product through rose tinted glasses. I have concerns about both its complexity and its performance. I'm also impressed by its functionality, especially in the most recent release that I discussed here.

I also want to start by acknowledging that I am not able to compare apples with apples in this article. Whilst Adobe Captivate is a standalone product to purchase or subscribe to (but also available in a Digital Learning Solutions bundle) Storyline is part of an impressive Articulate 360 bundle that also includes Rise, Peek, Studio and Replay…with all this combining with impressive training resources, team purchase options and team workflow functionality…and most notably (in my opinion) the superb Review 360 service that I will discuss later.

That said, after typing that all in, I went to the Articulate site to make sure I had worded things correctly and I find myself confused. Articulate have a lovely website, but sometimes you just want them to be more specific with their bundles and pricing. It's further complicated by the fact that to separate Storyline 360 (that is part of a bundle) from a version that is standalone, that standalone product is known as Storyline 3…and even more oddly, Storyline 360 and Storyline 3 run to slightly different development cycles. It's common for support staff in the forums to explain that the update that they are talking about has been released to Storyline 360 but won't be applied to Storyline 3 for a while longer.

It's a confusing approach, but I think I can I see why they've done it. They no doubt have a lot of clients who only want Storyline and want it as a one-off purchase (that's Storyline 3) rather than having to pay for a subscription (Storyline 360) that includes so much more. But this approach creates an odd environment online where people are posting about issues or things that they have developed, and sometimes these issues are common to both versions and at other times, they aren't. Articulate are running two very similar applications almost in parallel, whilst at the same time having to explain that (queue Sesame Street song) "one of these things is not like the other".

It's even causing concern in the forums. Take this brief exchange where a Storyline 3 user noted that the 2019 User Conference was focused all on Storyline 360, and the response was "folks who joined us last year whom were on previous versions got a lot of insight and inspiration out of the sessions." Note also that the staff member even refers to Storyline 3 as a "previous" version, yet they still sell it as a standalone product to purchase on their site. It's odd and confusing. Is it the standalone version or is it a previous version?

Articulate need to bite the bullet and kill off Storyline 3 for the sake of clarity. I can't see why Adobe can sell Captivate via either a one-off purchase or an annual subscription, but Articulate can't do the same with Storyline 360? There's no harm to having one clear product that is either available separately or as part of a bundle. Just warn users that a one-off purchase means no more updates (other than bug fixes) unless you subscribe or (as with Captivate) pay a one-off upgrade cost.

It's simply like PowerPoint

It's noted online by many that Storyline is very PowerPoint-like. I wouldn't disagree. Those that are familiar with PowerPoint and its interface, but more specifically, a dab hand at PowerPoint animations and timings, will find many features in Storyline that are familiar and easy to use. Go to add some transitions between slides and it's familiar and comfortable…you know what you are looking at as you're simply looking at options that are typical for PowerPoint. The transition from being familiar with PowerPoint and moving to Articulate will be far easier than anyone wanting to contemplate a move from PowerPoint to the more challenging Adobe Captivate.

From the Microsoft-like toolbar, to adding in slide transitions and animation effects - You'll find a lot of Storyline is very PowerPoint-like.

But coming back to this comparison between PowerPoint and Storyline, the major difference with Storyline is in the introduction of a timeline (that Adobe Captivate users will be familiar with), layers (let's call them an invisible slides on top of a slide) and of course triggers, the way in which you use scripting for how the timeline and the items on it behave. Think of the triggers as object-orientated events associated with an action. "Change this button when the timeline starts"…or "Show this layer when the user clicks this button". I love the simplicity of these trigger scripts in Articulate, but they don't always have a lot of power to them individually.

Let me give you an example. Imagine I want to do the following when a user comes to a slide…

• Set a variable to 1
• Change the state of a button to look different (let's say red)
• Hide an object

In my head, I wish that I could code something along the following lines…

• When timeline starts, set variable to 1, change button to red, hide object

That's concise and powerful. But I can't do it that way in Storyline 360. I must do it this way…

• When timeline starts, set variable to 1
• When timeline starts, change button
• When timeline starts, hide object

It achieves the same result but with a lot more additional coding, which also takes up a lot more real estate in the trigger panel on screen. Articulate has opted for simplicity and straight forwardness over advanced, powerful scripting up front.

I can see that this opens the ability to code to a wide range of people who may not feel as comfortable with complex coding as others. In fact, that's an absolute strength of Storyline…getting started and getting into scripting is incredibly easy. If someone asked me what to start using first as an Instructional Designer, it would be Storyline.

But with the timeline you also see an immediate difference between Storyline and Captivate. Whilst both are time based (obviously) the timeline has more significance and focus in Captivate. With both applications, the timeline can be insignificant if all you are doing is dropping items on a slide for people to interact with; in both the timeline can be used to determine when an item becomes visible and 'in play' on the timeline…but it's only in Captivate that the timeline functions as much as you might expect in line with other applications.

That's not to say the timeline isn't a timeline in Storyline…it is, but the most notable difference is with playing or scrubbing the timeline. In Captivate, you can move along the timeline and see the changes to the slide as you scrub through time. It's more akin to animation than Storyline is. In Storyline, you can't scrub along the timeline and see objects change or move, you can only place objects at certain times to appear or disappear. The timeline may have meaning, but that meaning doesn't truly become clear until you preview a slide and check your timings there. Trying to come up with a way to describe this, I guess I would say that the timeline in Storyline is more about on-slide presence than about time.

The Storyline timeline

Layers upon layer

One of Storyline's killer features is layers. You can have a slide in your project and that slide can have multiple layers…effectively more slides on top of it. Imagine them as plastic sheets that you can drop on to the slide that you are working on, moving from layer to layer without leaving the slide. Layers can be scripted to be shown or hidden, so it's an effective way to build up a slide that has multiple things happening on it (and multiple things appearing on it) without having to move away from the slide in question. It's also important to note that the timeline layer (the base layer) can remain visible throughout the display of other layers. It's superb!

When I first came across the use of layers, I didn't think that I would use them that much…but in fact quite the opposite happened. I found that one of the greatest benefits was that it reduced the number of slides in a project…and related to this, the number of menu items that appear in the player when you publish your project.

Layers allow you to consider each slide almost as its own compact presentation, where several items of content can be displayed at various times, or removed from the screen…all with interaction occurring before the user moves on to the next slide. It allows a better way of working with a collection of content (I think) than Adobe Captivate does. In Captivate I find that you tend to stick to a tried and true approach of…show some content on a slide…move to next slide…show more content (even if it's related to the previous slide)…and so on and so on. Storyline does away with that in a much more economic and logical way of working. It's more compact…it allows you to create a project that isn't full of a multitude of complicated slides that you must manage. Practically and visually, it's a great way to work.

Perhaps I could put it like this…typically with Adobe Captivate, you build up interaction and complexity across a series of slides. With Storyline, that complexity and interaction can remain on one slide, through the use of layering.

Here's a simple example using my own work. Click this link and see Tammy's Story. Remember that Accident Compensation Corporation is the world's only universal no-fault accidental injury scheme, so unfortunately the animation is about Tammy having an accident, although you won't see anything graphic. What amazes me (even though I made the thing) is that everything you just saw occurred on one slide with multiple layers…and as you moved through each stage of the story, I was able to add and remove animation as layers, whilst keeping the user on the same slide! In Captivate, I would have most likely have needed to develop either an astoundingly complex timeline or I would have taken an approach that used many separate slides.

This YouTube demonstration/tutorial also shows the potential of layers well. As you watch the very first part, if you are an Adobe Captivate user, think about how many slides you might use to achieve the same thing, and then notice the simplicity of using a layer.

Take me to your Slide Master

Jumping back to my comment about Storyline being very PowerPoint-like, I want to come back to the notion of slide masters….something that many PowerPoint users will be familiar with. But I also wonder how many people are comfortable and experienced at using them? To me, it's one those incredibly powerful features of PowerPoint that a lot of people forsake or don't know about, to their peril. Slide Masters in PowerPoint can be completely ignored. I wouldn't recommend that approach…but you can easily get away with slide upon slide of unique or repeated content. But if you want to apply a style across a series of slides; if you want an object to be common across multiple slides; if you want to be able to make a change in one location that affects multiple slides – then you need to get to know Slide Masters and how to create master layouts.

Anyone who uses PowerPoint well will know the power of slide masters. Keeping close to PowerPoint, Storyline makes use of them also.

The same applies in Storyline. A colleague had developed a theme template that consisted of several agreed layouts that we then used to select slide styles for each of the slides we were creating. This led to consistency across the organisation and it also meant (as happened in our case) that if a change needed to be made to part of the look and feel of the project, we could easily make that change on a slide master and see it applied rapidly across multiple slides. For one project I was working on, the colour scheme for the slides needed to be changed significantly. Making those revisions in the master slide layouts (as opposed to having to make those changes to each slide individually) saved an inordinate amount of time.

Applying a layout style to a slide - So PowerPoint like!

I confess I became a bit fixated about using slide masters and the pre-set layouts we had created, more so than any time I have used PowerPoint.….not only making sure they were consistent, but that our slide masters contained the correct number of slide layouts and no additional layouts, so that anyone who works on my files at a later date will find them exceptionally well organised. Part of the reason for this is that I found it was very easy for slide masters to get cluttered with additional layouts or repeated copies of master layouts, particularly if you have spent time cutting and pasting slides from other project files. Even though two projects used a similar theme and slide layout, when I cut and pasted content from one project to the other, I'd suddenly find duplicated slide layouts in the slide masters section and wanted to fix that before proceeding.

Duplicate slide master layouts were both a problem and a bit of an obsession for me.
I didn't want my project file cluttered up with unused slide layout designs.

You are probably thinking "Is this a big deal?" and the answer is no. But I wanted to make sure that we had only the master slide layouts that were part of the original template theme so that there was no confusion as to which slide masters were part of the project…and to make sure that my work was exceptionally tidy when I handed it all over at the end of the contract. If only I was as good at house keeping as I seem to be with my computer work!

Perhaps the biggest feature of slide masters (besides creating a standardised layout across a project) is the ability to add buttons and triggers to these master layouts, to then have that functionality available across all slides that use that layout as a master. This is very powerful and saves a lot of time when using very consistent interaction within a project. I confess I love the "show this item for the rest of the project" feature in Adobe Captivate, and I am in two minds as to which is the most effective approach. They are both pretty cool.

Object states

One of the areas that I think Storyline succeeds where Captivate introduces complexity is with object states. This is the ability for an object to have more than one look/state/function, such as a style for when you hover over it, when it's selected or when it's disabled.

The interface for using states is so much more straightforward in Storyline. It's very easy to quickly create states or use a number of pre-set options….and these pre-set options add greater power to what you are doing. It's possible to import one of the characters available within Storyline, and by doing so, bring in some of their pre-set states (imagine the character having different expressions) that you can then easily and quickly manipulate with scripting. That's superb.

Storyline puts access to states and their functionality far more to the forefront of the software than I think Captivate does. Whilst object states in Captivate are powerful, I've always found the interface for working with them awkward and confusing. That said, if there was one minor criticism of Storyline, it would be that I frequently thought I was editing an object's state, only to find I wasn't….and would have to then remember to activate or deactivate the "Edit state" button depending on what I was trying to do. I get why they have done it the way they have, but I sometimes wished that states were always just displayed in a separate window, so that when you were editing and object, you could edit states without any need to enable or disable their editing.

Storyline not only provides a lot of characters to use in projects (both artwork and photos) but they come with a multitude of pre-set states that you can add to your project to then code changes in how the character appears. It's incredibly easy to do and saves so much time.

However the UI/UX for states is a bit confusing. Just look at this image and ask yourself...am I editing these states already or do I need to click on "Edit States" first? Neither Storyline nor Captivate handle editing object states as well as they could.

Responsive projects

The way that Adobe and Articulate choose to approach the concept of responsive projects that can be viewed on any device is very different…almost worlds apart. Whilst Adobe Captivate has an astoundingly powerful concept in its use of fluid boxes, Storyline doesn't attempt anything like the concept of fluidity of display and dynamic shapes. Captivate's fluid boxes allow for a truly dynamic and responsive presentations. They're certainly not easy to code and testing them even within the Captivate software itself isn't always the most pleasant experience…but my goodness it's an impressive piece of functionality. I could easily see myself using Captivate to create a responsive project, being comfortable knowing how the project would perform and look on multiple devices…and I would be very comfortable releasing such material as an app to be used on devices. The output is that good when you put significant work into making sure it is.

Storyline never gets that far into responsiveness. They have taken a simple approach that produces HTML5 responsive output, but Articulate's focus is that a project should be able to be viewed on devices of different sizes, without needing any adjustment by you. They aren't concerned with making it possible to adjust these layouts to a minute detail to cater for different screens and orientations. They want their player and HTML5 output to simply be viewable…and that's enough for them. That also shows in the testing controls you use to view your content in landscape and portrait mode. Again, it's incredibly easy, whilst also being very simplistic. If you know that your project is unlikely to be viewed on a wide variety of devices, then this approach (without the ability to heavily fine-tune the content) may be enough.

The ability to check how a project displays for a certain type of device,or to lock its responsive
display down to a specific ratio is simple, questionably effective, but also lacking complexity and power.

You may not need the amount of power that Adobe Captivate has to offer when developing responsive content. Articulate express the differences between the two products when they say…"our responsive player doesn't require any extra work. We believe technology, not course authors, should do the heavy lifting. So you just build your course like you normally would and publish". Hmm…that's a clever bit of writing. But look at that opening statement about course authors. The whole reason people like me have to use software like Storyline; the whole reason I get hired; the whole reason I have that expertise with the work that I do…is because I do the heavy lifting. I make the projects work the way that is needed. I'm more than prepared to spend the time getting those projects right. I'm more than prepared to shape the technology to work the way I want it to. I have to do it when using Adobe Captivate and I want to do it when using Articulate Storyline. It's disingenuous to say that the approach taken has been done purely for our sake, whilst not being able to provide a true justification for why the fluid functionality in Adobe Captivate doesn't exist in Storyline.

And look at the effort that Articulate have gone to on that page to justify it…and to promote the difference between Captivate and Storyline. That's a lot of writing just to highlight the fact that they are saving us from heavy lifting. I suspect this may be an issue that comes up a lot when comparing the differences between the two products, and they have gone to a lot of effort to show the strength of their simple (there's that word again) approach over an approach by Adobe that Articulate describes as "difficult, tedious, and cumbersome." Unfortunately, I'm just not convinced that Articulate win the argument.

Go on, tell me what you think!

An area where Storyline has significant strength over Adobe Captivate is with its online Review system. Just watch the introductory video on this page - https://articulate.com/360/review

We made substantial use of this system for getting feedback from Subject Matter Experts (SMEs) who were geographically dispersed. It allowed for tracking of comments, monitoring changes as any issues were closed, a historical account of that feedback and for previous iterations of the project to be accessed if needed.

But perhaps the simplest thing it allowed was an easy way for SMEs to see the functionality of the work that I was doing, before it was packaged up and added to our Learning Management System. I didn't have to explain how a slide was going to work from an interactive point of view - they could see it, they could test it and they could be involved in saying what worked well and what needed revision. It was also a useful way for me to include a slide now and then with comments like "waiting for text from…" as a none-too-subtle reminder that a key stakeholder hadn't done the work that we were waiting on.

At the end of that process we were able to export a CSV file of all the comments, to keep them as a record of the changes that had been made and the feedback we had received as part of the development of a module.

Articulate Review is simply an incredibly powerful, yet incredibly simple-to-use tool/website for empowering feedback across an organisation. I loved it! This is something that Adobe needs to introduce quickly, as the ability to share content and get feedback with Captivate is nowhere near as simple as this. Heck, maybe Articulate need to be a bit cheeky and figure out how they could let people publish their Captivate projects to this system also and then just charge a nominal monthly fee for its use?

I also liked (as the instructional design developer) how I instantaneously had a test environment for the modules I was creating, as well as one simple source or location that I could point people to. I was able to get anyone I wanted to provide feedback, even if these people didn't have a user account on the Articulate system (they just used their email address as their guest name).

An added benefit, as more people provided feedback, was that it was easier to reach consensus before proceeding with changes. Nothing is worse as a developer than changing something based on one person's feedback, or having an exceptionally vocal reviewer, only to find others disagreeing later and asking you to reverse the changes. If someone reviewing a module had a strong opinion, that opinion could be balanced by the comments that another SME might add. It also meant accountability and visibility (on the part of those making the comments) to others viewing the content under development.

I also found the review site useful in showing staff how responsive and quick I could be when making agreed changes. I could alter the project, upload a new version and then just ask them to take another look. Sometimes I'd get email responses such as "that was quick!" when I had made the amendments requested.

I need to add that I have commented on the Articulate forums that the review system needs more features from a team admin perspective. I found that some staff opted not to create a free Articulate ID account, but simply use their email address to comment (as mentioned earlier). The problem with this was that some staff used a personal email address (which I didn't want people to see and didn't want comments being sent to) and I also found that I could go back to these comments, pretend I was that person (by using their email address to 'log in') and edit or even delete what they had written…or post as them. There is a way to control this per project, but wouldn't it be great if you could set it that all projects from one organisation required users create an account (using their work email address) for security. I also don't like the fact that any reviewer can resolve comments, which is something we would have preferred to disable and only have the learning team sign off on resolved comments.

In the end, I created a document called "Articulate Review – An Introduction", that we now send out to staff when they use the review site for the first time, explaining how the system works, asking them to register a free Articulate ID account, but also asking them to leave resolving comments to us.

Making things accessible

Accident Compensation (where I was using Storyline) was probably the first organisation that truly insisted their modules be accessible. I'm not suggesting that other organisations haven't asked me to do this in the past, just that accessible content isn't just seen as important, it is a requirement. In previous organisations I've worked at, we tried to make the learning material as accessible as possible…but there wasn't a legal requirement to (at the time) and the audience were also known not to have accessibility needs.

Storyline has a very simple approach to accessibility that is tied to screen readers, 'alt' text and reviewing the tab order of objects on a slide. It's very easy to use this feature to determine the tab order of objects, whilst also entering or checking the descriptive text that will be read out by a screen reader. But I also found a frequent frustration with the tab order window when working with a slide with multiple layers, and ended up submitting a feature request for a change to Articulate. This is because when you check the objects on one layer, you have to then save and close the tab order window before moving to the next layer and opening it up all over again. As I was using two monitors, I often had the Tab Order window open on one screen, whilst trying to adjust the project on the other…and I couldn't understand why I couldn't click anything. I'd find myself closing the Tab Order window to then literally open it back up again a few seconds later just to overcome this issue. The Tab Order window needs to be one that is not modal but can always remain open regardless of what slide or layer you are on. Having it as a floating, 'always open' window would be much more powerful I believe.

The simplicity of using the Tab Order window to set the order that a screen reader will tab through objects. You also can add the alt text here. It's superb and makes creating accessible output very easy indeed! It's also frustrating! In this image I am working on items (1) on the second layer (2) but I can't just jump to the next layer (3). I need to save and close the window (4), select the next layer (3), go up to an off-screen "Tab Order" button (5) and then finally come back to the Tab Order window (1). And I need to do that for each layer on this slide!

I really welcomed the opportunity to produce accessible content, but in doing so we came across issues with the HTML5 "Modern Player" that Storyline wraps the modules in. Two of the most pressing issues were related to the inbuilt Previous and Next buttons in the player. The issues were…

• The JAWS reader (the only reader supported by Storyline) reads the inbuilt "<" and ">" buttons as "Button" and "Button" unless you show text with them (which we didn't want to do)
• When using layers, the "Next" button caused issues if you had the menu collapsed. Once you were positioned at the Next button and tabbed to go back up to the top of that slide, the menu would open, and you would have to tab repeatedly to get back to the content on the slide. Another, more accurate way to say this, was that there was no way to control the focus of the tabbing when using layers

The workaround for these two issues is to not use the functionality. That isn't a great solution. How many software systems do you know that suggest "when there's an issue with that function, the best approach is to not use it"? The workaround means deactivating those next and previous buttons and adding your own buttons onto slides. Terry Springer says it best when he said (almost 3 years ago at the time of typing this) - "The best way to handle this tabbing issue is to add your own custom navigation buttons and disable (remove) the player's navigation". Wow! Almost 3 years ago and the accessibility issue still exists.

Another thread on the modern player saw an on-going discussion (that I joined) with another accessibility issue with the modern player. However I did spot this snippet in a forum post around May of 2019 that showed promise. It was unique in that Articulate didn't typically post forward-looking comments...

"In the meantime, we're working on a better player structure that'll provide industry-leading accessibility support. We have several enhancements planned to comply with the latest accessibility standards across more screen readers and web browsers. I don't have an ETA yet, but we're excited to announce as these features are improved."

Later that same month, Simon Taghioff from Articulate posted a message in another thread that expanded quite significantly on what they are doing in terms of accessibility. It's a long post, but worth a read. So kudos, to Articulate. I can't wait to see how they resolve these issues…but I am concerned with how long it has taken for them to address the issue…something that I discuss in second part of this article.

Note – Thanks to ACC for allowing me to use work that I did in these articles. The graphics used in modules were not created by me, but were from a suite of images that we were required to use in order to match with ACC branding.