10 Replies
Walt Hamilton

It provides a lot of really desirable things, but more slide real estate isn't one of them.  I set up a screen capture app, which has a window on the screen that isn't from SL. You can see the dotted lines on the preview of my project. I have two slides, and I took a screen shot of each of them with the recording app's window superimposed. Notice at the bottom of the pictures that the overlay is the same size on both pictures. One slide has nav controls and a menu, and the other has none.

As you can see (and you can see the same thing if you go to player settings), all the controls are placed outside the slide area. The available area on the slide is the same size with or without controls.  Like Sam says, the controls are in an area where slide content cannot go.  The controls are actually added outside the slide, and you can't have that area.



 Note that the controls under this slide belong to the recording app. Removing the SL controls has not increased the size of the available area on the slide.



So, if I'm understanding correctly - if you turn off the player's nav buttons and create your own buttons, those created buttons are taking up real estate on the slide. Using the player's nav buttons do not. I'm asking because a colleague insists on drawing their own buttons for slides, including defining states. My argument is that drawing your own buttons takes up room on the slide that could be used for instructional elements. Am I correct in that assumption?

Cary Glenn

Custom buttons take up more valuable space on the slide than the built in buttons. From what I understand about accessibility the built-in buttons work better than custom buttons. With the modern player I prefer the built-in buttons for time and space saving. I think the only downside to the built-in controls is the lack of colour choice.

Sam Hill

I see what Cary is saying, but I don't think custom buttons take up any more slide real estate than the built in player navigation. If that was the case, you'd just add x amount of pixels more to the slide dimensions in place of the built in player navigation.

The player navigation is always added on to the slide dimensions. Therefore if you optimise your slide size for a particular display (the smallest display size you choose to support, e.g 1024x768), you do sometimes run the risk of going over size, or the player scaling your slide size down in order to fit within the browser. It is for this reason, that we and our clients choose not to use the built in player navigation.

So, if I defined a slide size of 1022x630, and then used the Storyline player, the player UI would be added around the slide size I have defined. If in this scenario, as user on a display size of 1024x768 viewed my project, they would be either forced to scroll, or would be viewing a slide that is significantly smaller than 1022x630 due to it having to scale.

I have uploaded a couple of images just to illustrate this. 

In the image sl-w-player.gif, this shows a slide with the modern player. You will see the player UI takes up some valuable browser space with a dark grey margin around the edges. 

In the other image sl-wo-player.gif the player is turned off, and I have included some navigation buttons within the slide. You can see the slide content is able to fill the browser and would in turn allow the slide content to be shown much larger allowing for more of the screen realestate to be used when the player is turned off.

This is why I would argue that not using the built in player provides more screen realestate to the developer.

There are other pros and cons, but when it comes to question of screen realestate, we always go without the player to optimise the space used.

Edwin Martinez
Cary Glenn

From what I understand about accessibility the built-in buttons work better than custom buttons.

Hi Cary, just wondering if you'd be able to point me to the right direction in terms of player button best perform with accessibility. Found this online, but just wondering if you know of any other resource available?



Sam Hill

Hi Edwin, what would you like to know about accessibility and the Player? I can highlight some of the advantages of the player. They use something called landmarks, which identify to assistive technology the location of certain controls such as main navigation. The buttons in the Player such as the Hamburger button identifies whether it is Expanded or Collapsed (something we can't specify as easily if building our own).

You can build accessible content without using the Player if you don't want to use it, but if you are not comfortable with accessibility, the Player will do some of the lifting for you.

Edwin Martinez

Hi sam, thanks for replying back. Just wondering what would be the pros and cons when using custom player buttons over built-in button. More so with accessibility, and how well it operates when undergoing a screen-reader.

Would simply by adding alt text to a custom next/previous button be sufficient? Also, do you know where I can find more info about 'landmarks'? Do you know any references that I could read online?  Cheers

Sam Hill

Hi Edwin, if you build your own navigation, you can make it fully accessible. There is no problem there.

There should be plenty of information on the web about landmarks, but they are used to group a bunch of related elements. They help with providing hierarchy for the content. Storyline doesn't let you define any landmarks of the content. These are taken care of for you, and used predominantly in the Storyline Player.

You shouldn't really need to add Alt text to the Custom Next/Previous buttons if they contain text labels. The Alt text will inherit those text labels. When it does become a consideration is if the button is just built from a graphic or shape. You will need to define a meaningful Alt text in this instance.

As I said, as long as you are familiar with accessibility and know how to test keyboard and screen reader accessibility, you will be able to achieve what you need to for accessible content.

Edwin Martinez

Thanks again Sam, you make a good point about Storyline's built-in player from what I was reading earlier https://articulate.com/support/article/Storyline-360-Accessible-Player. It takes care of all the guesswork around player accessibility by defining elements & hierarchy for screen-readers. Cheers  mate