Do you ever have to train learners on how to use an application or website? If so, you may want to consider using the screen recording tool in Storyline 360 to create some software simulation...
Published 8 years ago
Version 1.0
Blog Post
Here is a unique challenge I thought to share.
My office uses 1920X1080 but serves customers still on 1024 X 768. Our application is very Excel-like with detailed tables of data, generally displaying at 10pt type. And not only is the resolution vastly different, but we have 16:9 vs 4:3 ratios working.
Recording at 1024X768 shrinks the text size unreadable when rendering 1024X768. And, when you play a 1024X671 capture (accounting for the largest browser address bar), playing it on 1920X1080 renders fine, but looks a bit "picture in picture".
Still, capturing at 1024X671 is the best resolution for most our customers (since any shrinking down from a larger resolution has a big impact on readability at smaller sizes), but we wanted to go full screen(ish) to let the 1980X1020 monitors show it bigger.
So, we added a script to start button on our first screen (in Storyline, our new WordPress based portal will automatically launch the asset in a new window, full size).
var el = document.documentElement
, rfs = // for newer Webkit and Firefox
el.requestFullScreen
|| el.webkitRequestFullScreen
|| el.mozRequestFullScreen
|| el.msRequestFullScreen
;
if(typeof rfs!="undefined" && rfs){
rfs.call(el);
} else if(typeof window.ActiveXObject!="undefined"){
// for Internet Explorer
var wscript = new ActiveXObject("WScript.Shell");
if (wscript!=null) {
wscript.SendKeys("{F11}");
}
}
This will make the player area of your storyline file take up the maximum screen area it can (in my case, the 4:3 ratio recording fills the available horizontal space of the 16:9 screen with a bit of space on the side, but does present it in the best available real-estate. (note: your output must be set to use available window space for the window containing the content).
It is a touch fuzzy- but a tradeoff in the crispness is a good concession to make for giving it more presence on screen, easier readability, etc...
Time permitting, I'd run the screens through PS, wiping out all the text, and vector trace the grid lines, and then copy/paste text and then create text fields in SL to import the values, which would make it perfect.
But in the meantime, this hack works pretty well.
If you want to grab the script to see how it will swell your output to fullscreen, it's a quick way to test how things will look if you just want to grab all the available real estate for any screen you deploy to.
My office uses 1920X1080 but serves customers still on 1024 X 768. Our application is very Excel-like with detailed tables of data, generally displaying at 10pt type. And not only is the resolution vastly different, but we have 16:9 vs 4:3 ratios working.
Recording at 1024X768 shrinks the text size unreadable when rendering 1024X768. And, when you play a 1024X671 capture (accounting for the largest browser address bar), playing it on 1920X1080 renders fine, but looks a bit "picture in picture".
Still, capturing at 1024X671 is the best resolution for most our customers (since any shrinking down from a larger resolution has a big impact on readability at smaller sizes), but we wanted to go full screen(ish) to let the 1980X1020 monitors show it bigger.
So, we added a script to start button on our first screen (in Storyline, our new WordPress based portal will automatically launch the asset in a new window, full size).
var el = document.documentElement
, rfs = // for newer Webkit and Firefox
el.requestFullScreen
|| el.webkitRequestFullScreen
|| el.mozRequestFullScreen
|| el.msRequestFullScreen
;
if(typeof rfs!="undefined" && rfs){
rfs.call(el);
} else if(typeof window.ActiveXObject!="undefined"){
// for Internet Explorer
var wscript = new ActiveXObject("WScript.Shell");
if (wscript!=null) {
wscript.SendKeys("{F11}");
}
}
This will make the player area of your storyline file take up the maximum screen area it can (in my case, the 4:3 ratio recording fills the available horizontal space of the 16:9 screen with a bit of space on the side, but does present it in the best available real-estate. (note: your output must be set to use available window space for the window containing the content).
It is a touch fuzzy- but a tradeoff in the crispness is a good concession to make for giving it more presence on screen, easier readability, etc...
Time permitting, I'd run the screens through PS, wiping out all the text, and vector trace the grid lines, and then copy/paste text and then create text fields in SL to import the values, which would make it perfect.
But in the meantime, this hack works pretty well.
If you want to grab the script to see how it will swell your output to fullscreen, it's a quick way to test how things will look if you just want to grab all the available real estate for any screen you deploy to.
- Great tip, David! Thanks for sharing your experience and your tip about the script. Many people also don't know that when you're viewing an app or website inside a web browser you can hit F11 to maximize the screen size and get rid of URL bars, etc. Thanks again for sharing, David! :)
- Beyond that some folks don't know- even if you put instructions right on-screen, sometimes, they just don't hit it. Putting the command in a button to launch it can help avoid those calls ("I am looking at your content and it looks small")...
Of course, you have to give a button to allow them to reduce it, or exit the content if they need to switch to another app (which happens often when you need to react to customer needs).