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

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. 

I tend to start from the position that states make an object change, and layers are to display different objects when the learner does something.

Does it in any way affect the size of file? 

I tend to agree with you on this one Bruce. For me, states are to change the appearance of one object, whereas a layer is to add additional information or change the appearance of multiple objects.

I don't think that using states vs. layers or vise versa will have an impact on file size, but I'm not positive on that. Anyone else care to interject?

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).

Hi David,

So glad you brought up the topic of screens vs. layers. Can you give us some insight into how you decide which one to use?

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.

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. 

~ 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! ~

To add to the conversion, I have found that layers can be beneficial when printing the e-learning for the SME to review. The slide is difficult for them to look over if states were used for everything.

Very good point Douglas.

@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.

@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?

@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.

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.

@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.

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.

Hey guys! Thanks so much for all your insight on this topic. I thought your answers were so interesting that I decided to write an article about it. Check it out and let me know what you think!

What is the upper limit for number of layers on a single slide before problems may occur? 10? 50? I am creating a dialog between 2 people, and each layer is a response, and I need about 25 layers. Can I do this without any issues?

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.

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

16 layers with only text boxes should impede performance at all, Lester.