RANT: Changing behavior of the Next button in Presenter/Engage '13

I'm beyond frustrated right now. I'm explained this through support and filled out a "feature request," but perhaps someone can explain the logic behind Articulate's decision to completely change how the Next button functions (in an Engage '13 interaction) all of a sudden?

I had been using an Engage interaction in our courses as a "help" file in the topbar right (near the Exit button) - it described to the user what the player buttons mean, how to navigate through the course, etc.). Every course had it. it's optional...like an FAQ almost.

However, in upgrading to Presenter '13, this functionality got all glitchy and didn't work correctly, so I was forced to make this slide part of standard course content (as a PPT slide). That meant also redoing my standard template in Storyline, s well - so both template interfaces would match. Needless to say, it took some work.

Fast forward to today - I had to upgrade a presenter '09 course to '13 and add in the new Engage interaction. After realizing the Next/Previous buttons seemed to be turned off by default (huh?), I added them in and published the course.

However, when I get to the Engage interaction and click next, I don't go to the next slide--you know, like I would any other time EVER that I click the Next button in an Articulate course. Instead, it goes to the next little pop-up in my labeled graphic interaction. Huh? I click Next again - same thing. I have to click 10 times to get through these items before it finishes and goes to the next page.

OK...I can see why someone *might* want to force the user to see everything in the interaction. But there is no way to turn this off. None. WHAT? WHY? Why would this not only be the default action, but the ONLY action? It seems completely ridiculous to me.

Articulate Support's workaround (ah, our favorite word!) is that the user should just go to the menu on the left to advance the slide. But if I wanted to users to advance through the course using the menu, I wouldn't be using the Next button, which has ALWAYS performed the same way...until now. Why am I being forced to make the users jump around the screen to go to the next page?

As far as I'm concerned, course navigation should be consistent and not create confusion for users. However, this is exactly what has been created with no way to disable it.

I can turn off the Next/Previous buttons in the interaction, but would leave an even more confusing scenario for users used to clicking Next to advance because the buttons are simply not there at all.

The ironies are:

1. I had to rebuild my templates because of a functionality glitch in the upgrade due to this exact interaction, and now the "new" way is even worse.

2. This interaction is to explain course navigation to users, which isn't even accurate anymore because of the behavior this exact slide now exhibits.

Surely I'm not the only one experiencing this issue or having a problem with it, am I? I just don't understand the decision that was made to have this function this way without a way to opt out of it. It really leaves me handcuffed. I do not want to force our users to have to click 10 times (on our interaction) in every course to skip past this slide, or fumble around to a different part of the interface because of this one slide.

Any real ways to get around this?

</rant>

13 Replies
Tom Kuhlmann

Hey Chris,

I understand your frustration. Below I offer some background on why the changes were made and a few solutions.

Just a little background.

What makes rapid elearning attractive is that the non-programmer can build courses leveraging PowerPoint's authoring. Of course that means you have some constraints in PowerPoint and you give up some programming control. Which can be the source of frustration when you want to do more than what comes out of the box.

To make up for some of the constraints of PowerPoint we created Engage. You get easy authoring because all you have to do is select a form-based interaction, add your content and hit publish. The drawback is that form-based authoring's simplicity comes with limited programming control, as well. It's designed that way on purpose.

Because Engage is a stand alone application, it has it's own navigation controls.

The original version of Engage had navigation controls that conflicted with the default player controls in Presenter. So when you inserted an Engage interaction you had two different types of players with different navigation. We had a lot of requests asking that we integrate the Engage navigation with the Presenter course player. And that's why we made the change because it's what was frequently requested and confirmed during our beta testing. Of course, as you note, the change doesn't meet everyone's need.

Essentially, the Engage interaction is content created in a separate application. So it has its own player controls and navigation. When you insert it into the PowerPoint slide you have to account for the Engage player settings chosen by the course author.

When creating an Engage interaction you have two choices:

  1. Do you want Engage to have it's own navigation?
  2. Do you want no navigation and only onscreen clicks?

Whichever you choose impacts how the navigation integrates with the player.

Solution

Currently there are three options when inserting the interactions into the PowerPoint slides:

  • Insert Engage with the interaction's navigation controls and the course player's prev/next buttons are assumed by the Engage interaction. This lets you use the prev/next buttons to navigate through the parts of the interaction (and display each element in the menu). In a sense the interaction elements are treated as sub-slides. 
  • Insert Engage with the navigation controls that were disabled in the interaction. Unfortunately that currently overrides the course's player controls and turns off the prev/next buttons because that's how the interaction was designed. Of course that leads to your frustration because you want to have the interactions act as a single slide with only onscreen clicks and still have the default prev/next buttons in the course player. That makes sense and we also submitted a feature request on your behalf.
  • Insert Engage as a web object. Another solution in the short term is to publish the interaction any way you want. Change the name of the interaction.html to index.html and then insert the interaction as a web object. It doesn't take much longer. What you'll get is something similar to the way the interactions used to behave. You also have the means to customize the player color schemes to match your slide and create a more seamless experience.

I created a demo to show how each looks.

http://zizbo.s3.amazonaws.com/engage-nav2/presentation.html

Hopefully that helps.

Again, I don't want to dismiss your frustration because ultimately you want to be successful using the tools and not feel like you have to make a bunch of workarounds. We did submit the request and also made sure that the current product manager is aware of it.

Chris Perez

Thanks for the reply, Tom!

The web object option might be viable, but probably the only one of the ones I've been given. I'll see if i can get it to work!

My problem is the amount of rework I now have to do because of this issue (updating our department-wide templates again, fixing other courses that are in progress being created by others, etc.), in addition to us probably not using Engage at all anymore. Honestly, it just serves no purpose because of this functionality change.

And I think whoever the people are that requested this change/feature for Engage should be ashamed of themselves. I feel like it's a dumbing down and catering to the lazy to incorporate this kind of "feature" into something that's supposed to be interactive.

I realize that sounds harsh, but this change undermines the whole point of Engage (as I see it). Why create an interaction--in which the sole purpose is to get the user to ENGAGE with the elements on the screen--and then remove the interactivity from it? If a user can just sit there and click Next, what's the point of the interaction? It completely defeats the purpose of it. Might as well just put the info an separate slides and click Next through it all.


Engage absolutely should have it's own controls - but I don't see where the problems were with the prior version. It worked exactly as it should have. Engage files were self-contained, but also followed the 'rules' of the rest of the course navigation. That has been completely disrupted now and provides and inconsistent user experience.

Anyone that insisted this be the default function of Engage as it sits right now is doing a huge disservice to the rest of the elearning community and developers that want consistency and expected functionality for our users. I'd really love to know the reasoning they gave for including this as a feature. I still cannot make sense of why anyone would want Engage to function this way.

Chris Perez

Well, I seemed to have uncovered another issue adding this as a web object. Since I would have to use this same URL for every course we produce, when I go back to visit the slide, it asks me if I want to resume where I left off. I don't see a way to turn that off. Is there one?

Otherwise, any user that takes more than one course of ours will see the 'resume' pop-up every time this page comes up again. :(  Not usable if I can't turn that resume prompt off.

Phil Mayor

Chris Perez said:

Well, I seemed to have uncovered another issue adding this as a web object. Since I would have to use this same URL for every course we produce, when I go back to visit the slide, it asks me if I want to resume where I left off. I don't see a way to turn that off. Is there one?

Otherwise, any user that takes more than one course of our will see the 'resume' pop-up every time this page comes up again. :(


That one I can help with, You can switch of the resume function when you publish the engage interaction.

 http://community.articulate.com/tutorials/products/changing-the-player-s-resume-behavior.aspx

Nicole Naude

Tom Kuhlmann said:

  1. Do you want Engage to have it's own navigation?
  2. Do you want no navigation and only onscreen clicks?
  • Insert Engage with the navigation controls that were disabled in the interaction. Unfortunately that currently overrides the course's player controls and turns off the prev/next buttons because that's how the interaction was designed. Of course that leads to your frustration because you want to have the interactions act as a single slide with only onscreen clicks and still have the default prev/next buttons in the course player. That makes sense and we also submitted a feature request on your behalf.

Hi Tom and Phil -

I'm wondering if there's been any progress on the above feature request. I'm experiencing the same issues as Chris, and while the suggested web object workaround might be an alternative, a fix would be much appreciated - especially as the workaround doesn't let you preview the web object's look and behavior until publishing.

Thanks,

Nicole

Brian Batt

Nicole Naude said:

Tom Kuhlmann said:

  1. Do you want Engage to have it's own navigation?
  2. Do you want no navigation and only onscreen clicks?
  • Insert Engage with the navigation controls that were disabled in the interaction. Unfortunately that currently overrides the course's player controls and turns off the prev/next buttons because that's how the interaction was designed. Of course that leads to your frustration because you want to have the interactions act as a single slide with only onscreen clicks and still have the default prev/next buttons in the course player. That makes sense and we also submitted a feature request on your behalf.

Hi Tom and Phil -

I'm wondering if there's been any progress on the above feature request. I'm experiencing the same issues as Chris, and while the suggested web object workaround might be an alternative, a fix would be much appreciated - especially as the workaround doesn't let you preview the web object's look and behavior until publishing.

Thanks,

Nicole


Hi Nicole,

I can't give too much away, but this is something that we're looking to address in the next update.  

Nicole Naude

Thanks, Brian - I'm eager for that fix.

In the meantime, I've been mildly successful with the web object workaround. However, the sizing of the Engage slide as a web object is a bit unwieldy when in Presenter, especially as the "window size" option is unavailable when displaying in slide. The effect of this is that the web object displays with both side and bottom scroll bars. I've tried a number of combinations of the browser/screen options, but if you have any quick tips on how to make this work  visually I'd appreciate them.

Best,

Nicole

Wendy Laverty

I agree this is to say the least a nuisance.  We have over 200 courses and it's taking ages to go through each one add in the next/previous buttons.  It is sad to say these changes by Articulate seem to be change for change sake and to hell with the rework it causes for clients who are upgrading not good forethought by the development team in fact it is costing us money!!!!

Theresa Oubre

Are there any updates on this issue? We're running into it using one of the new interactions: quick choice. The interaction is made to do  things like ask a question and have users select an answer before moving on, but with this function in the prev/next buttons, if they select the right answer, they are forced to look at the wrong answers before advancing to the next slide using the buttons... which is a bit ridiculous and seems to defeat the purpose of the interaction..

Leslie McKerchie

Hey everyone!

With the release of Update 3 for Articulate Studio '13, you can now control how the Prev and Next buttons behave for Articulate Engage interactions embedded in Articulate Presenter courses. The navigation buttons can either jump to the previous/next step in the interaction or the previous/next slide in the overall presentation. See this article for details.