Player or not player... that is the question...
Jun 01, 2022
Hello all !
I realize that I NEVER use the menu display in Storyline, the "next", "previous", "validate" buttons etc… because, as a graphic designer, I prefer to create them myself…
But I realize that displaying the menu makes navigation much easier (going back to a particular slide in just one click, for example) and it also allows the learner to know exactly where he is in the module.
Displaying the menu is also a huge time saver because it avoids creating one from scratch in Storyline with dozens of variables (example: “make such part accessible when the previous part has been seen” etc etc.)
Being able to add buttons directly in the player (ex : “Help” “Resources” “Contact” etc) is also super useful.
MY QUESTIONS :
I would like to know if you use these options in the design of your own modules?
Thanks !
Fred / Bordeaux / France
3 Replies
Fred,
This is just my opinion. I always look at the process from the perspective of the learner and the ongoing maintenance required by the client after I deliver their final product. So many developers want to experiment with the look/feel (e.g., custom menus, Javascript) but don't think ahead about the maintenance and whether or not the next update to Storyline could break the functionality.
I always try to achieve what my clients want using the native capabilities of the product first. If that doesn't work, I explain the feature can be added but there is no guarantee that the Javascript or some other programming might work after the next upgrade. In many cases, the feature doesn't make much of a difference in the end when it comes to delivering the actual learning to the end-user even if it looks "cool" to add to the course.
So, just my two cents. I think some people will disagree but, I deal with a lot of "previously-developed" Storyline projects that no longer function or were "over-engineered" to the point of becoming a nightmare to maintain for the client.
Richard
I like having the menu visible. I prefer to give learners the ability to see what's ahead of them, to track their slide and scene progress (by the little check marks that appear next to slides they've viewed and the opening/closing of scenes), and to review previously-viewed slides.
From an instructional design standpoint, unless there's a compelling reason to hide the menu, it should be visible. I can imagine some cases (e.g. elaborate branching scenarios) where you'd need to hide/disable the menu. But I'd build that as a separate project, so I can only hide it when I need to.
As for forward/back navigation, I leave the default/player ones on (mostly for mobile), but I also create back/next buttons for my slides. I like having them right across the bottom of the slide. They're a larger target than those in the player. They're always in the same place, which is good UX, and they create a lower border to the slide. The only downside to them is that they eat some screen real estate. But I think they're worth it.
Ethan Edwards, Chief Instructional Strategist at Allen Interactions hosted a seminar several years ago titled 10 Ways to Ruin Your e-Learning: A How-To Guide in Reverse. #9 on Ethan's list is using the standard "C-shell" template for the screen layout of your lessons, as it consumes a considerable amount of screen real estate for largely non-instructional purposes.
The "C-Shell" is defined by the rectangular areas tinted red.
2 things to consider: Your corporate logo rarely contributes to learning, and navigation does not equal engagement.
Video: 10 Ways to Ruin Your e-Learning: A How-To Guide in Reverse
PowerPoint: 10 Ways to Ruin Your e-Learning: A How-To Guide in Reverse