States vs. Layers: How do you decide which to use?

A lot of really great questions came up in this week's AMA with Tom Kuhlmann. One of them that really got me thinking was this question from Nan Boyer about when to use states vs. layers:

"I LOVE the States and Layers features, but I sometimes have trouble identifying which feature would be more appropriate to use and when to use it. I have started using Layers only to discover that States would have been the better choice, and visa versa. Do you have any guidelines/helpful hints that would help identify, before I start developing, when Layers and/or States would be appropriate."

As Tom said, there really is no right or wrong answer, but I'm really interested to hear what all of you think about this, so I'll just throw it out there: How do you decide when to use states vs. layers?

29 Replies
Nicole Legault

One thing to keep in mind... Let's say I have an object that appears and I want to decide whether it shows up on a state or layer... if the object has any clickable components or buttons on it, you would probably want to put it on a layer instead of a state, since you can't add triggers to state objects. 

David Glow

It depends... 

The biggest challenge I have with use of layers vs states is with master slides- sometimes I see master slides set up with layers for some global UI/UX elements, and the designer makes decisions to make other layers hidden or non-clickable.  From the UI control perspective, this makes sense.  Unfortunately, I have found sometimes that they did not think through the impact to content slides and it can cause challenges with how folks would prefer to build.

This same challenge of layers and impact on other layers (appearance and clickability) can be a factor in the decision.

Not a perfect/complete description and not a hard rule, I generally use the practice guideline

  • states to change appearance of an item
  • layers to bring in new elements and/or functionality

One last thing- nobody seems to be bringing up the "screens vs layers" discussion, but I want to weigh in: keep screens down when you can. Not just for the file size, but there is a bug you can trip (when you see all your screens flash on and off like a strobelight in Story view, you know you tripped it).

David Glow

I can sum up my philosophy on that easy (applies to PPT, other toolsas well): I must be talked into adding a screen.  It is done by necessity, avoided as a default.

I've seen others with differing opinions, but when I see a colleague at my org produce content with 160 screens and the equivalent design takes me less than 30, it's easy math to determine the maintenance and bandwidth savings.

This is also why I am much more a fan of "take screenshots and add animations and triggers vs auto-recording for sims". More upfront work, but much more efficient and maintainable output.

The biggest challenge is ability- I find many designers trained in the "add a screen for each new thought" methodology, and rewiring and thinking different can get them confused and tied in knots.  So, you have to be sensitive of that, and work within ability constraints in a team environment.

Kevin Thorn

Great discussion here and a question often posed to me. In short, it really boils down to practice and building courses, interactions, sequences, navigation paths, etc. The more you build, the more  you begin to realize and see more efficient approaches to development.

I'll echo there's no right vs. wrong as one can build the exact same interaction with object states as with layers where the learner would see the exact same thing regardless of the build. 

Comes back around to David's philosophy on 160 screens vs. 30 - it's more about efficiency and post-launch maintenance. This now skirts into the discussion/debate on whether to storyboard before development - Design before Develop. The conundrum here is newer users of Storyline don't have the skills yet to know the capabilities and limitations of Storyline to know the best design (storyboard) to script. Hence, one dives into Storyline the best they can with what they know and learn on the fly.

I'm also in agreement with Bruce, Allison, David, Nicole, and others where a State is to change the look/feel of an object but it's limited to on click action - that object. Whereas a Layer can display more objects with multiple click actions per object. 

Ashlee Smith

~ Thanks for these Great Tips community! ~

I personally Usually use  LAYERS  for feedback and also when I need to Build upon a base slide and (usually) like to keep some parts visible.

I normally use STATES to change the look of one object or to add a Hover effect.

~Thanks Community~ Great Tips, as always! ~

Allison LaMotte

@David: I see what you mean about not just adding slides haphazardly, however I think that the same goes for any content that you add, whether it is a slide or a layer or anything else. It is always important to make sure that the content adds something to your course and supports the learning objectives. 

@Kevin: Based on your experience, how do you make the decision to create a layer vs. a slide? What criteria do you base this decision on?

@Danika: That is a good rule of thumb for the use of layers: If you'd like to build upon a concept presented on the base layer and/or keep some parts of the base layer visible.

@Douglas: That is a great point! Thanks for pointing that out.

Kevin Thorn

@Allison: Great question! My first thought is based on...well, experience. At this point I can look at a storyboard and know right away how to approach the development on whether to use Layers or branch an interaction out to Slides. In fact, some ideas fester between my ears awhile and a simple pencil sketch will reveal the best approach. Doesn't answer your question though. :)

Seriously, several factors come into play when making this determination - animation effects, media such as audio and/or video, and navigation.

- Animation effects: While there are some fancy trickery things you can do for visual effectiveness, sometimes the amount necessary to create a smooth transition between Layers gets messy. For instance if you wanted the current layer to fade out when the user clicks an object to reveal another layer, it takes two layers (one for fade out previous layer and one to fade in new layer). If you have more than 3-4 layers, it can become an asset management nightmare.

- Media: There's two parts to this as audio and video are two different animals. First, let's assume you want to show a different video on each of 4 layers. A high quality HD video in .mov format are large in file size. Four of them on one slide (layers) may impact load time depending on the end user's environment. Audio is not as bad but longer narrations (> 1 min) with lots of animations/annotations with images tend to load up a slide's *weight*, too. Additionally, there are playback considerations whether to use the seekbar or video controls, layer properties, etc. when managing a slide with that much going on.

Navigation: With Storyline 2 we now have the ability to control the Next button but with multiple layers and allowing users free control over how they explore content, managing the navigation with the Next button can be tricky. Even custom navigation controls adds another layer of conditional evaluation.

To me it's really about the design. I know there's a lot of debate on whether to storyboard or not, but even the basic level of design effort will help foresee any potential complications or obstacles. 

Bottom line: There's no rule that I approach one over the other. First it's design. With Storyline's ability to do the same thing 100 different ways, I think through what's best for the end user as well as efficient development for post-publish maintenance.

That help?

David Glow

@Allison: Just to clarify- I wasn't referring to adding content haphazardly vs not adding content;  it has been determined that content is needed- from that point, my default is still "use screens less".

It's a default, not a hard rule.  Kevin just provided a few prime examples where a screen would be much less maintenance than a layer. As long as their isn't a filesize issue (screen count bumps up filesize greater than layers with equivalent content in my experience), I'd probably go screens.

Actually, a BIG hattip to Kevin on talking about media.  I have clients who want to play content on iPads and don't want to use the player app (don't get me started...). In any event, the rules for iPad HTML5 requires single media per screen, no passive triggers, top layer.... thus mandating a lot of screens.

My default for "use less layers" is probably better stated as "avoid bloat". Screen use often represents bloat (often with junior developers). But certainly the default isn't a hard rule, and there are a TON of exceptions that must be taken into account to meet project needs.

Kevin Thorn

David just pointed out something I failed to elaborate in more detail - mobile. If at any time in the Elearning Industry, "mobile first" should be your first thought starting any project regardless of it's end delivery point. 

As David eloquently summarized, "...there are a TON of exceptions that must be taken into account to meet project needs."

Prototype. Test. Test again. Revise prototype. Test again. Test. And then test some more.

Allison LaMotte

@Kevin: Thanks for taking the time to explain your methods in such great detail, it is always interesting to see how others approach this aspect of course design.

In my experience as an Instructional Designer, another factor that would lead me to create a slide over a layer was the amount of voice-over text. A lot of clients that I worked with would specifically request that I create a slide when the text was too long to make the notes tab easier to read/follow along with.

@David: Thanks for clarifying, I see what you mean. I agree as long as there is some sort of relationship between the information on the different layers. I would hesitate to create a slide with a bunch of unrelated information on different layers just to avoid creating several slides, unless there is something on the base layer to tie it all together.

Nicole Legault
I really love this topic and was just giving more thought to why I choose one vs the other. Another thing I realized is that since  states are hidden,  they are harder (more clicks) to access and edit. It's also longer to get a quick view of how states look because you have to either preview or hover the mouse over the state in the states panel to preview how it looks. 
 
All that to say, if I'm adding something to the screen with multiple elements, more than one object, etc, it might be easier to put it on a layer vs. a state for quick editing purposes.
Charles Kent

I've just done a little test and Layers create a bigger file output than states, This could be due to fact it mimics the original slide.

It's a small increase but over say 50 slides this would build up and would output at a hefty file size.

I tend to use states but only because I feel I have greater control over objects/buttons etc, that's not to say I don't use layers.

Kevin Thorn

Hi Lester,

Not sure anyone has reached an upper limit as a lot of other factors may cause problems. For example: you may have one course with 50 layers with images that works fine, yet another course with 25 layers with video and it has performance issues.

Keep in mind Layers are part of that slide. So the more objects (images, text, shapes, etc.) you add to a Layer adds to the overall size of that slide when it loads on screen. 

I can confidently say that I've built several projects that had 50+ Layers and work flawlessly. Just be aware of your design and ensure you manage your assets (compressing images) as you build it out.

Lester Bennett

Hi Kevin - Thanks for the reply. I am talking about multiple layers on a single slide. I ended up with 16 layers on one slide - do you think that will be ok? Nothing but text boxes on them, so they aren't very big.

Thanks!
Lester

[cid:image001.png@01D0BB29.CE3027A0]Lester Bennett, MA Instructional Technology
Training Developer | Instructional Designer, Global Channels Training and Development
Verizon Learning and Development | Verizon Enterprise Solutions
916-779-1959 (w) | 916-667-1653 (m)

P Please consider the environment before printing this email