How can I mark a slide as already visited in the Player navigation

Hi Stuart,

There isn't a way to trick the player into giving a particular slide a visited state - but it sounds like you may have set your menu to a restricted navigation? If that is the case, users can use the menu to navigate to slides they've already seen but they won't be able to use the menu to jump ahead or skip slides as described here.  If you'd like the users to be able to more freely use the menu, you may want to set it to a free navigation.

Ashley,

Thank you for responding.  Sadly, it does not help me at all.  Yes, I'm using a restricted flow.  I stated that in my message, and that my course mandates students follow a sequential flow through the chapters and lessons.  I am using branching and a freedom to explore in any order extensively within each lesson, but not from lesson to lesson.

The more time I spend trying to implement an entire college length course on a very advanced and complex graduate-level engineering topic in Storyline, the more frustrated I become.  I am finding Storyline to be an very expensive collection of great ideas that are only half thought out and poorly tested.  Storyline demos nicely, and might be adequate for short, simple internal training modules on single topics, but Storyline is not even close to being up to the task of doing anything extensive.  I do not have any experience with other Articulate products, but this one gets a vehement thumbs down.  I think it is time to totally scrap several weeks of development effort and find a product that the developers care about and have actually tested.

Has anyone out there run into a problem similar to what I described in my initial post?  How did you get around it?

Hi Stuart,

I'm sorry to hear you feel that way about Storyline, but I can assure you that our development team is always hard at work on fixing bugs, adding new features, testing them all and listening to and caring about the needs of our customers. If there are particular features you'd like to see implemented in new versions/updates I'd encourage you to share your thoughts here in the form of a feature request.

In regards to your set up, there is not a way to restrict navigation in the menu on a lesson by lesson (presumably these are set up in scenes?) basis. It's an all or nothing approach within the player menu, but if you'd like to look at restricting the course's progress from lesson/scene to the next, you may want to look at customizing the navigation from within the slide using variables and triggers such as this description on how to disable the next button until a user has interacted with a slide.  Using a set up where the user needs to pass through a "gate" or checkpoint within each lesson which would adjust a variable, allowing the user into the next part of the lesson, may fit your needs. If that is the case, you could set up a slide to serve as the menu adjusting the state of buttons into each lesson. Here is an example of a menu in a lightbox.  Here is another example of a menu that slides in and out from the left side or this one that appears from the bottom and adjust the text color based on which slides were visited. 

I hope that helps clarify other ways to set up the menu within Storyline, and if there is anything else I can assist with please let me know. 

Ashely,

Thank you again monitoring the forums and  for being so quick to respond. 

Yes, each of my lessons is a scene.  The Chapter Progress slide is yet another scene, and contains links to each lesson scene.  Just as you have suggested, this Progress slide already makes use of variables to control the sequence of going through through the lesson and controlling the functionality of the Next button.  All of that is OK for a single chapter.   BUT, I am developing a BIG course -- a least from my perspective.  When I am done, there will be several chapter scenes, several dozen lesson scenes, and approximately 1,500 to 2,000 slides ( and that's without splitting video segments into separate slides, which I might need to do for some video clips).  With this much material for students to digest, the Player Navigation Menu -- if it works well -- is a vital tool for allowing students to jump back to previously completed chapters and lessons as they apply earlier concepts in later lessons. 

The example user-defined menus you provided are nice, but they do not address my question of how to control the Player Menu.  Yes, I could manually duplicate what the Player Menu already does, using fancy techniques like these examples.  I would need to setup navigation menus that can expand and collapse for each chapter.  I would need to define hundreds of variables to control when those menu items not available for selection in a restricted flow.  I would need to manually update this menu as the course development progresses and for each update to the course over the next several years.  All of that would be reinventing the wheel, when what I'm trying to build a car under a very tight schedule.  I want to use the wheels that are already in the Player, not reinvent them! 

I paid a lot of money for Storyline because it has features like the Player Menu, that, in literature and in simple demonstration examples, looks like a nice wheel to use in my project.  The menu automatically generates itself.  I can customize what appears in the menu.  It has expand/collapse for subsections.  It has the restricted access mode that is vital to my course.  I can customize colors of visited and current menu items.  All of that looks wonderful -- until put into use.  That's when what I refer to as "half-baked" issues become apparent.  Some critical feature that a fully baked Player Menu should have, but doesn't, include:

- Greying out menu items that cannot be selected.

- Adding check marks or other tokens to completed items in the menu

- Overriding the restricted flow restrictions for specific menu items (i.e.: some menu items always accessible, no matter where the student is in the restricted flow)

- Explicitly changing the state of specific menu items to show as already visited, or perhaps changing back to unvisited.

- A progress bar

Many of these features would be a simple matter of providing user-access to the states of Player menu items, in the similar way that states can be added, modified, and triggered on slide objects.

I know I'm ranting, but I'm also frustrated that the wheels I paid a lot of money for so I could build my car more quickly are turning out to not roll very well.  Now, based on what you have said, these expensive wheels need to be thrown out and I need to invest considerable time and effort into inventing my own set of wheels -- and then maintain the complex code behind those wheels for years to come.

Stuart,

I am working on a linear lesson where each scene represents a new topic. I'm similarly using restricted navigation to ensure each scene's slides are viewed before the next scene's slides. At the end of my lesson's intro scene (the main branch), I have a topic menu that I'm guessing is probably similar to your chapter progress slide. Each topic menu item is clickable and navigates to its respective scene/topic, but I have them set to a disabled state (and therefore unclickable) until the previous topic has been marked as complete. I'm using variables to track when each topic is "started" and "complete." 

After reading about your testers wanting to click the menu instead of the chapter menu to open the next lesson, I am now wondering if my users will do the same... As it stands, I am requiring them to use the topic menu I've provided, and I've inserted instructional prompts to remind them to do so. Perhaps you could add a time-delayed reminder/prompt on your chapter menu that appears in case they are clicking on the menu items with no results?

My only other idea is to force the next lesson's slide to be a visited state by automatically navigating there and back using triggers and a variable. For example, if when visiting Slide A you want Slide B to also be marked as visited (and therefore clickable in the menu), you could have the following variable and triggers in place:

Variables

• slideBvisited (default value = False)

Slide A triggers

• Jump to Slide B when the timeline starts (on Slide A) if slideBvisited is equal to False

Slide B triggers

• Set slideBvisited equal to true when the timeline starts (on Slide B) if slideBvisited is equal to False
• Jump to Slide A when slideBvisited changes if slideBvisited is equal to True

The obvious downsides to this solution are (1) more variables to manage, and (2) the user will see Slide B very quickly appear and disappear the first time Slide A is visited. I suppose you could incorporate a mask layer on both Slide A and Slide B so their contents are hidden when they are first "viewed" programmatically (when slideBvisited still = False). Upon visiting each a second time, the mask layers could be hidden based on the now-True value of the slideBvisited variable.

Your suggestion about having more control of the menu would be a lot easier, but maybe the above idea wouldn't be so bad?

Edit: I forgot variables can't have underscores, so I updated my example above to remove them.

Chad,

Thank you for the suggestions!  It does sound like your "topics" slide and my "progress" slide are very similar.  On a different test I did a few weeks ago, I played with automatically jumping to a different slide and then back.  The glitch was very obvious.  Perhaps covering the other slide with solid black would make the glitch less annoying, but it would still be visible that the screen glitched.

Until Articulate gives users more access to what goes on behind the curtains in the Player, I'm pretty much stuck with what appears to students as a broken Menu.  To mitigate this a little, I have added a dummy menu item at the very top of the menu that says "COURSE NAVIGATION RULES: You can go back to any completed lessons.  You cannot jump forward to uncompleted lessons."  The menu is set to not wrap long lines, so only the first part of the line show up, and a "tip" box with the remaining text pops up.  I also added an explanation of what can and cannot be done with the Menu navigation to the course introduction portion of the course.

Again, thanks for your insights and ideas.

Hi Stuart,

I also wanted to let you know that I took a portion of your previous post and sent it along as a feature request as those go to our product development team and this is how they'll keep track of those requests as well. You've likely receive the confirmation email that it was submitted this am.

Thanks again for sharing your thoughts here and if there is anything else I can please let us know. 

I think I had a similar needs previously where I need to control the Menu based on the learner's progress. By the default, the Menu is restricted but it will automatically enable once completed in unsequential navigation. I managed to solve the issue by creating my own customize one slide of Menu where I have the full control of each item on the menu. I can enable/disable the items on the menu at any point of time using variables.

Here's what I did.

Add the variables:
variable name of Lesson 1 Item 1 -> vL1i1 (false default)
variable name of Lesson 1 Item 2 -> vL1i2 (false default)

Button name:
button name of Lesson 1 Item 1 -> bL1i1
button name of Lesson 1 Item 2 -> bL1i2

Slide Condition:
If Slide of Lesson 1 Item 1 is visited or completed
  Adjust variable vL1i1 = True
 

Now when you open the customized menu, add a slide trigger
Condition:
  If variable vL1i1 is equal to True?
     Change the State of "bL1i1" (the button name of Lesson 1 Item 1) to Enabled

Now you have successfully activated Lesson 1 Item 1 button on the customized menu.

Storyline is not a Programming Software where you can do magic. Patient is the key.

Hope this helps.

~rex

Thanks Rex for sharing those steps here and even though it's an older forum discussion it's always good to have those ideas and steps shared here.