I'd look at the most common resolutions and focus on the smallest resolution in that group. In this case, 1024 x 768 is probably the sweet spot. The largest group negatively affected by that resolution are the 60 at 800 x 600. Most others, including the single users, can display 1024 x 768 without a problem. You might have 100 people out of something like 7000 who will have issues.
Hi, John -- While I will defer to your fellow community members to reach out with their recommendations on story size in relation to screen resolutions, I thought I might pass along the following discussions:
If you consider 1024 x 768 to be your lowest/smallest common denominator, you may consider using a story size smaller than that, so that even users on 1024 x 768 have a positive experience. If you develop at 1024 x 768 then users on a 1024 x 768 screen resolution are still going to possibly deal with scrolling, etc., because the course size is as big as their screen which doesn't work well when you factor in things like the windows task bar, etc.
I develop a lot at 1000x562, which displays very nicely on 1024 x 768 and larger screen sizes.
Because most screens are wide nowadays I prefer designing to a 16:9 aspect ratio vs the old standard 4:3.
I like the way it looks on the screen, I like the way I can use the available real estate when designing my slides, and most importantly it is a familiar experience to what people are used to seeing as phones, tablets, laptops, TVs, etc are all 16:9.
How is your player configured? Do you have a menu, etc.? If so, wouldn't the slide size plus the menu sidebar and the player frame, etc. add up to more than 1024x768?
If you include the menu sidebar and the navigation buttons, they, plus the player frame size when added to your slide size of 1000x562 come out to published dimensions of 1260x633.
The frame adds 20 pixels to the height and width, the navigation buttons add 52 pixels to the height, and the sidebar adds 240 pixels to the width.
We keep the player to a minimum (only the course title, no player nav, menu or tabs), but you're right, with the player our courses measure in at 1020x605, which is still a very friendly size for someone still using a 1024x768 screen resolution.
At that size someone on a 1024x768 screen resolution can view the course at 100% original size, no scaling, no scroll bars and nothing like the windows task bar obscuring part of the course.
That being said, you might decide to customize some of the player features so that the content automagically adjusts to your users screen size. Some content may not look that great but at least you'll know that the user can see all of it.
There are two different settings you can adjust: Browser size and Player size. I normally use the "optimal size" setting for both, but there are some nice options for filling screen, using the current browser size, and scaling the player to fill the window.
If you're doing a software simulation with a story size of 1000x562, what size do you make the browser window to ensure the video is clear and not blurry?
what size do you make the browser window to ensure the video is clear and not blurry?
Great question John. At this point we don't create software simulations using Articulate's recorder.
I hope folks here in the community who do use this feature in Articulate can jump in here with some recommendations.
Our process is a mixture of Camtasia and Adobe Premiere which gives us the ability to easily pan/zoom in and out. This allows us to plug in a video that fits well within our course frame size and zoom in when needed on important features.
The primary reason we do this is two-fold: 1) We have a ton of video production capability in house and also use these same videos for external customer training and internal micro-learning opportunities, and 2) Our products update frequently and we find this process easier for managing minor updates within our workflows.
12 Replies
I'd look at the most common resolutions and focus on the smallest resolution in that group. In this case, 1024 x 768 is probably the sweet spot. The largest group negatively affected by that resolution are the 60 at 800 x 600. Most others, including the single users, can display 1024 x 768 without a problem. You might have 100 people out of something like 7000 who will have issues.
Hi, John -- While I will defer to your fellow community members to reach out with their recommendations on story size in relation to screen resolutions, I thought I might pass along the following discussions:
Hope that helps! :)
Thank you Steve and Christie!
Steve's suggestion was approved.
We're on the same page, Christie. I read those articles this morning.
If you consider 1024 x 768 to be your lowest/smallest common denominator, you may consider using a story size smaller than that, so that even users on 1024 x 768 have a positive experience. If you develop at 1024 x 768 then users on a 1024 x 768 screen resolution are still going to possibly deal with scrolling, etc., because the course size is as big as their screen which doesn't work well when you factor in things like the windows task bar, etc.
I develop a lot at 1000x562, which displays very nicely on 1024 x 768 and larger screen sizes.
Thank you, Brian! This is good to know and very helpful.
Why 1000x562 instead of 1000x750 which is the same proportions as 1024x768?
Because most screens are wide nowadays I prefer designing to a 16:9 aspect ratio vs the old standard 4:3.
I like the way it looks on the screen, I like the way I can use the available real estate when designing my slides, and most importantly it is a familiar experience to what people are used to seeing as phones, tablets, laptops, TVs, etc are all 16:9.
Thank you, Brian!
Brian,
How is your player configured? Do you have a menu, etc.? If so, wouldn't the slide size plus the menu sidebar and the player frame, etc. add up to more than 1024x768?
If you include the menu sidebar and the navigation buttons, they, plus the player frame size when added to your slide size of 1000x562 come out to published dimensions of 1260x633.
The frame adds 20 pixels to the height and width, the navigation buttons add 52 pixels to the height, and the sidebar adds 240 pixels to the width.
We keep the player to a minimum (only the course title, no player nav, menu or tabs), but you're right, with the player our courses measure in at 1020x605, which is still a very friendly size for someone still using a 1024x768 screen resolution.
At that size someone on a 1024x768 screen resolution can view the course at 100% original size, no scaling, no scroll bars and nothing like the windows task bar obscuring part of the course.
That being said, you might decide to customize some of the player features so that the content automagically adjusts to your users screen size. Some content may not look that great but at least you'll know that the user can see all of it.
There are two different settings you can adjust: Browser size and Player size. I normally use the "optimal size" setting for both, but there are some nice options for filling screen, using the current browser size, and scaling the player to fill the window.
https://community.articulate.com/series/articulate-storyline-2/articles/changing-the-browser-settings-and-player-size-in-articulate-storyline-2
Brian,
If you're doing a software simulation with a story size of 1000x562, what size do you make the browser window to ensure the video is clear and not blurry?
Thank you,
John
Great question John. At this point we don't create software simulations using Articulate's recorder.
I hope folks here in the community who do use this feature in Articulate can jump in here with some recommendations.
Our process is a mixture of Camtasia and Adobe Premiere which gives us the ability to easily pan/zoom in and out. This allows us to plug in a video that fits well within our course frame size and zoom in when needed on important features.
The primary reason we do this is two-fold: 1) We have a ton of video production capability in house and also use these same videos for external customer training and internal micro-learning opportunities, and 2) Our products update frequently and we find this process easier for managing minor updates within our workflows.
All very interesting stuff thanks.
This discussion is closed. You can start a new discussion or contact Articulate Support.