Help with Tracking Progress in Nav Menu

Hello,

I'm working on a project to walk users through a process and I need help with the nav menu.

What I'm trying to do: I'd like the nav menu to indicate when a user has completed a step so as they are going through the process, they can see their progress and which steps have been completed (in case they jump around).  

What I've created thusfar: Each step/slide in the process has a separate variable (most are true/false).  The nav menu is on a master slide with triggers so that when a step variable is set to True, that icon in the menu will change states.  It doesn't matter to me whether the icon changes state when they first view the step or if it changes after they move onto another step.

What's working: The nav menu seems to function as I intended so long as I just use the next button.

What's not working: When I use the menu at the top to jump around, the icons keep changing states.  I've played around with this a bunch and can't find a pattern.  I've checked the variables and the variables are all correct.  It's the triggers that are not behaving according to their conditions.  All icons should either be "Normal" or "Visited" but sometimes they're even changing to "Hover" state.  

I can't figure it out and am not sure if this is a bug or the result of some monstrosity I've created.

Any thoughts or suggestions?

Note: the project is still very much in draft form.

8 Replies
Crystal Horn

Hi Adam!  I've actually asked our technical writers to create an article entitled, "It's not a bug; it's the monstrosity you've created."  We'll be sure to reference it in your next post.  🤣

Actually, I think your project looks great.  I love the progress meter idea, and so many people appreciate seeing these examples.  So, thanks for sharing!

The one thing I noticed on your slide master where the navigation bar lives:  You are using triggers to change pre-built states, like Visited.  Pre-built states have their own rules, and they'll change themselves without any trigger.  When you use triggers with pre-built states, weird, monstrous things can happen.

Here's what I would recommend, and maybe just try it on a couple of icons to see if it works.  Instead of using a pre-built state, like Visited, create a custom state with a different name.  Trigger that state instead, and see if some of the oddity subsides.  If so, go forth and be merry!  If not, let me know, and we'll dig a little deeper.

Adam McCash

Hi Crystal,

(I would love to see an article titled that!)

Thank you so much and that's very helpful to know.  Do you know if there are any articles or info about the rules around pre-built states?  I had no idea and I'd be curious to learn more about those.

Also, do you know, if I duplicate a pre-built state, do those rules carry over?  Another way of asking this is, can I duplicate a pre-built state (with a different name) to avoid these rules, or do I need to create a new state from scratch?

I'm playing with them now and will let you know what transpires of this creature.

Thanks again!

Adam McCash

Hi Crystal!

So I went in and created new custom states.  Since I was unsure if pre-built state rules copy over, I just created new states from scratch.  I also cleaned up the triggers a bit to remove some of the redundant conditions I'd created.  Unfortunately, I am encountering the same issue.  

I tried setting the default state to a custom state as well in case the Normal pre-built state might somehow be acting up, but I got the same results.  

At this point I'm still convinced that it's some tiny thing I've done that anyone with common sense would find right away, like a mechanic saying, "Ah yep. I see the problem right 'ere.  Ya got an ice pick sticking out of the rear wheel.  They usually don't go there."

I've attached the revised storyline file, and here's a link to the published version.

Im not crazy

 

Ashley Terwilliger

Hi Adam, 

I'm not qualified to identify crazy (my sister is the one who did all that extra schooling!), but I spotted a few areas you may want to take a look at.

First, I saw you mention that you didn't want to see the Hover or Visited states. Since they are built-in, they'll function as defined here. If you do not need those - go ahead and delete them! 

Next, I updated the trigger order on your slide masters to make sure that the states were changing before advancing to a new slide. That's key to make sure that the triggers have time to execute (you can read more about that here). 

I think that fixes things up so that the top navigation works the same as the next button. I recorded a quick Peek video of those changes too - in case a more visual representation helps! 

The one piece that *may* need a bit more tweaking is NavBar5. I wasn't 100% clear on how you'd like that to function based on the additional layers/slides shown to the learner. It could be that post-holiday fog I'm in or that there is still something off-kilter there! Let me know, and I can take another look. 

Finally, I attached an updated copy of your .story file with my changes above and published it to Review here. That way you can play around with it "live." 

Adam McCash

Ah thank you Ashley.  Yes, I always forget to factor in that the order of the triggers matters a lot.

And thank you for taking the time to dig in and clean up some of my messy layout!

I was quickly testing the version you published (and the file you shared) and I'm still encountering the same issue.  The first time I view any page, the buttons function properly, no matter the sequence.  When I revisit any of the pages, the nav buttons go all wonky.  Some will switch back to their "Normal" state and I can't figure out a reason why.  

Re: NavBar5 - In this step users are writing out the actual activity instructions, but I wanted to change the prompt based on their decision from slide 1.7.  So if a learner picks option 1 on slide 1.7, when they go back to that step (via NavBar5), I'd like them to go directly to the Option 1 prompt rather than going through slide 1.7 first (if that makes any sense at all).  This is probably a bizarre and unnecessarily complex way of achieving this.  

Any thoughts or suggestions on the issue of revisiting slides and the wonky nav buttons?

Ashley Terwilliger

I clearly should lay off the eggnog - as I missed that piece that it was only on a revisit! I thought the buttons weren't working correctly when you used those to navigate vs. the next button! 

Since the trigger on your NavBar# are to change the state when the timeline starts, Storyline is looking for the timeline to start each and every time on the accompanying slides to check the status of your variables. An easy way around this is to set the slide properties to "When revisiting: Reset to initial state." I published a new copy to Review here, test that one and you can now navigate with the next button or the navigation buttons and the completion status of each navigation button will remain. So hopefully that solves the first piece!

As for NavBar5 - that makes a lot of sense, and seems to be working! The questions looked so similar I wasn't 100%. 

Double check my work, and let me know if anything else isn't making sense or working properly! It always helps to have another set of eyes on the project. 😀