A couple of ways to use progress meters

Hi all.

I wanted to share something I've been playing around with.

Here's a proof of concept I've been working on for two ways to use progress meters:
1. Progress meter doubling as a menu

2. Progress meter being used to deliver 'extra info'.

I don't have a way to share published output at the moment - so here's the .story file. The mechanics of the progress bar are in the slide masters. Also it doesn't play nice with IE as it uses wipe animatons.

Hope it's of use to someone.

16 Replies
Mike DiFonzo

This is really great! I'm not quite at the progress bar level yet but this is a great reference tool. Only suggestion might be to make the current node a different color to make it stand out.

Wipe animation is an issue in IE? I'm using Wipe and our system-wide default browser is IE (I prefer Chrome).

Shaun Martin

Hi Michael - thanks for the feedback. I can see the value in having the curent node standing out a bit more.

And yes wipe animations (along with a couple of others) don't work in IE or Edge. They'll look fine when you're previewing in Storyline, but when you publish they don't. For example if you had a line wiping in from the left with a duration off two seconds, what you'll see in the published output is the line will just appear after two seconds (at the end of the animation).

More info here: https://articulate.com/support/article/Storyline-360-Some-HTML5-Animations-and-Transitions-Don-t-Work-in-Internet-Explorer-or-Microsoft-Edge 

Mike DiFonzo

Thanks for the link. I recall seeing that but totally forgot about it. Now I have to go back and remove those animations. Wish there was an easy way to see an animation list without going to each one.

I'm hoping to be able to incorporate a progress bar sometime in the future. Thanks for sharing.

Shaun Martin

Hi Naweed,

I put the progress meter content on the slide master so that I only had to set up the graphics, animations and triggers once. Because I wanted the progress meter to be a bit dynamic (e.g., animating the progress the first time you move forward to a slide, but visually keep track of how far someone had progressed if they went back to a previous slide), I needed quite a few triggers - 33.

If I was doing a static progress bar (that didn't animate, didn't remember progress if going backward etc.) then I would probably just do it on the slides, rather than the master.

Hope this makes sense!