Would anyone care to share their thoughts and advise on what to consider if we're deviating from the default story size?
Does a size of (for e.g.) 1024 x 768 mean better resolution when viewing on a PC/laptop? Conversely, would remaining at the default 720 x 540 mean the course is flexible and could be viewed on tablets as well? Or am I just barking up the wrong tree?
Would love to know everyone's thoughts on this and what the pros / cons are of going larger vs. sticking with the default.
Thanks. Indy
*************
PS, this question is in context of starting from scratch, not trying to resize slides that have already been designed.
Looks like you are looking for some user feedback here and hopefully some users will chime in to share their findings and best practices regarding this topic.
I did want to share our documentation on choosing a story size here. Nicole has a great post here that you may want to check out as well.
We went to a higher resolution template, as our courses did not look good when viewed full screen on some devices.
One think we noticed is that the NEXT and PREV buttons are much smaller if the project resolution is higher. I'm not sure if there is a way to correct this. I think the text in the built-in player menu got smaller too, but we ended up using a custom menu anyway, so we did not look for a solution to that.
We also noticed that the higher resolution course used more CPU when viewed in Chrome with Flash, which has been a problem for us.
Our current project size, not including the player, is 1600x960.
The most important decision is how the story size and the player format work together. For example, if you are using a menu in a 16:9 formatted player, you might want the story file to be a 4:3 format inside that player. If you're designing for mobile you want a responsive design that will scale nicely in the articulate mobile player.
Next, consider your user population. Many "road warriors" have moved to smaller laptops and netbooks with smaller screens. Design for your users. Not everyone has a 24" monitor that can handle larger resolutions.
We made the decision that our courses just weren't going to work well on phone-sized screens, but they do resize well on tablets. We went with the minimal/transparent player, where the only real-estate used by the player is at the bottom, where the NEXT button resides. We integrated everything else into our master slides.
Hi Dave and Mike, thanks for the valuable insight! I agree with you Dave about the road warriors, definitely an appetite for, at the least, tablet compatibility.
Correct me if I'm wrong, but the Story Size settings affect the slide itself, not the player as a whole, right?
And last but not least Mike... Just to understand the through process, what swayed you to go with the 1600 x 900... Was it about the course content, or was the decision largely to do with being better suited to PC screens whilst being "good enough" for tablets?
The story size won't impact the player as a whole, but there are player elements which will change the overall size of the story upon viewing the published output as detailed here. So you may want to keep those in mind as you're building your course and looking at story size.
I hate to contradict Ashley but the player will change based on the slide size as the buttons will get smaller and progressively more unusuable (not an issue if you do not use the player buttons), Also in HTML5 the font size of the player and menu cannot be adjusted so that may be an issue.
I would suggest that in an environment where you cannot control the devices using your courses 1600x960 is too large. Tablets using this resolution will struggle to download the content and it may cause them to crash, the ninja game I built was originally 1080p and crashed iPads on the first slide (android devices faired a little better they got to slide 3). I would agree with Dave a lot of users now have much smaller screens (although have higher resolution) than perhaps 5 years ago. Also the larger the project the higher the bandwidth requirements.
I generally go for 960 - 1000 pixel width for most projects and let them scale, the one caveat is that if I am using screen recordings or screenshots I would recommend locking the player as scaling will pixelate your images.
Articulate recommend that if you are targeting iPads you use the 720 width, I find this a little small.
Not a contradiction Phil, I think I just read or understood Indunil's question differently in terms of how the story size is used just to set the slide overall size and the player sits around that adding to the overall size based on what you've chosen to include in the player. Always good to have more than one idea or opinion shared!
If you'll be using mobile devices, you may also want to take a look at this article which helps give you a sense of the different elements you can add and how they'll impact the player size and appearance.
Indunil, 1600x900 is our slide size, with the player area adding a little height at the top and bottom. In Safari, this almost completely fills the screen on the iPad. This works well with our course content also.
Phil, we had the same issue with button and font sizes. We created a custom menu to get around the font size problem, and we use alternate buttons on most of our slides. The NEXT button is small on the iPad, but still large enough to click. Our courses are all under 12MB, with the bulk of the content coming in as streaming video, so no problem with mobile devices downloading our content.
Thanks Mike, I should have added that if your content is not very complex then size shouldn't be an issue.
I would still try and keep the around the 1000 pixel point W3Schools showed 97% of people had screens of at least 1024x768, this works great on an iPad where resolution is 1024x768, however if you allow the content to scale it will fit the text just may be too small.
The key thing though is to design for your audience first and foremost.
I realize this original post is 6 years old, but I'm running into an issue after setting my slide size to 1280x720. The border around the frame of the course only covers half of the navigation UI elements on the bottom of the navigator. See the attached image where the next, volume, and seekbar are not covered by the border, even though the preview shows differently.
I'm sorry you're running into this snag! I don't see this on my end when testing a 1280x720 slide. Some users with similar issues find that a simple repair of Storyline 3 helps. I'd also check if the Windows Display setting is at 100%.
13 Replies
Hi Indy!
Looks like you are looking for some user feedback here and hopefully some users will chime in to share their findings and best practices regarding this topic.
I did want to share our documentation on choosing a story size here. Nicole has a great post here that you may want to check out as well.
There are forum threads as well if you search: Determining Story Size - Best Practices
We went to a higher resolution template, as our courses did not look good when viewed full screen on some devices.
One think we noticed is that the NEXT and PREV buttons are much smaller if the project resolution is higher. I'm not sure if there is a way to correct this. I think the text in the built-in player menu got smaller too, but we ended up using a custom menu anyway, so we did not look for a solution to that.
We also noticed that the higher resolution course used more CPU when viewed in Chrome with Flash, which has been a problem for us.
Our current project size, not including the player, is 1600x960.
The most important decision is how the story size and the player format work together. For example, if you are using a menu in a 16:9 formatted player, you might want the story file to be a 4:3 format inside that player. If you're designing for mobile you want a responsive design that will scale nicely in the articulate mobile player.
Next, consider your user population. Many "road warriors" have moved to smaller laptops and netbooks with smaller screens. Design for your users. Not everyone has a 24" monitor that can handle larger resolutions.
Good points, Dave.
We made the decision that our courses just weren't going to work well on phone-sized screens, but they do resize well on tablets. We went with the minimal/transparent player, where the only real-estate used by the player is at the bottom, where the NEXT button resides. We integrated everything else into our master slides.
Hi Dave and Mike, thanks for the valuable insight! I agree with you Dave about the road warriors, definitely an appetite for, at the least, tablet compatibility.
Correct me if I'm wrong, but the Story Size settings affect the slide itself, not the player as a whole, right?
And last but not least Mike... Just to understand the through process, what swayed you to go with the 1600 x 900... Was it about the course content, or was the decision largely to do with being better suited to PC screens whilst being "good enough" for tablets?
Thanks again gentlemen!
Hi Indunil,
The story size won't impact the player as a whole, but there are player elements which will change the overall size of the story upon viewing the published output as detailed here. So you may want to keep those in mind as you're building your course and looking at story size.
I hate to contradict Ashley but the player will change based on the slide size as the buttons will get smaller and progressively more unusuable (not an issue if you do not use the player buttons), Also in HTML5 the font size of the player and menu cannot be adjusted so that may be an issue.
I would suggest that in an environment where you cannot control the devices using your courses 1600x960 is too large. Tablets using this resolution will struggle to download the content and it may cause them to crash, the ninja game I built was originally 1080p and crashed iPads on the first slide (android devices faired a little better they got to slide 3). I would agree with Dave a lot of users now have much smaller screens (although have higher resolution) than perhaps 5 years ago. Also the larger the project the higher the bandwidth requirements.
I generally go for 960 - 1000 pixel width for most projects and let them scale, the one caveat is that if I am using screen recordings or screenshots I would recommend locking the player as scaling will pixelate your images.
Articulate recommend that if you are targeting iPads you use the 720 width, I find this a little small.
Not a contradiction Phil, I think I just read or understood Indunil's question differently in terms of how the story size is used just to set the slide overall size and the player sits around that adding to the overall size based on what you've chosen to include in the player. Always good to have more than one idea or opinion shared!
If you'll be using mobile devices, you may also want to take a look at this article which helps give you a sense of the different elements you can add and how they'll impact the player size and appearance.
Indunil, 1600x900 is our slide size, with the player area adding a little height at the top and bottom. In Safari, this almost completely fills the screen on the iPad. This works well with our course content also.
Phil, we had the same issue with button and font sizes. We created a custom menu to get around the font size problem, and we use alternate buttons on most of our slides. The NEXT button is small on the iPad, but still large enough to click. Our courses are all under 12MB, with the bulk of the content coming in as streaming video, so no problem with mobile devices downloading our content.
Thanks Mike, I should have added that if your content is not very complex then size shouldn't be an issue.
I would still try and keep the around the 1000 pixel point W3Schools showed 97% of people had screens of at least 1024x768, this works great on an iPad where resolution is 1024x768, however if you allow the content to scale it will fit the text just may be too small.
The key thing though is to design for your audience first and foremost.
Very true. Our courses do not typically contain a lot complex graphics.
I realize this original post is 6 years old, but I'm running into an issue after setting my slide size to 1280x720. The border around the frame of the course only covers half of the navigation UI elements on the bottom of the navigator. See the attached image where the next, volume, and seekbar are not covered by the border, even though the preview shows differently.
Hi Anthony!
I'm sorry you're running into this snag! I don't see this on my end when testing a 1280x720 slide. Some users with similar issues find that a simple repair of Storyline 3 helps. I'd also check if the Windows Display setting is at 100%.
Let us know how it goes!