Creating Software Sims: Setting Your Recording Size & Area

Do you ever have to train learners on how to use an application or website? If so, you may want to consider using Storyline’s screen recording tool to create some software simulations. Software sims are a great way to teach learners how to use an application, system, or website without affecting the real environment or live data. In this first part of a multi-part series all about software simulations, we’re going to take a closer look at the optimal size to set your recording area, and how you can keep it looking as neat and professional as possible.

Set Proper Recording Size

Setting your recording size to the proper size will ensure your software simulation looks crisp and clean and appears as high resolution, avoiding fuzziness and distortion of your background. By default, Storyline slides are sized at 720x540 (that’s 720 pixels wide by 540 pixels high), which has an aspect ratio of 4:3. When you launch the screen recording tool in Storyline, the default recording size is 720x540, (or whatever size you've set your story to be) as indicated in the image below.

Storyline’s default recording size is 720x540, or the same size as your slides.

However, to make sure your recording stays crisp and high resolution no matter what screen size you view your course on, it’s best to record at a larger resolution than 720x540—1200x900 or 1400x1050, for example—while maintaining the 4:3 aspect ratio.

In fact, as a best practice, it’s a good idea to record your software simulation with as big a recording area as your monitor will allow, while still keeping the same aspect ratio as the slides in your .STORY project. The reason it’s important to make sure your recording area is set to the same aspect ratio as your slide size is because if it’s not, you’ll have empty space on each side of your recording, which looks messy and unprofessional.

Notice the white bars along the top and bottom of the recording; this is caused by setting the recording area to a different aspect ratio than the slide size.

Another good reason to record at a larger resolution than 720x540 is that you might find it difficult to fit an entire software application or website into an area that small. In fact, certain applications can’t even be resized that small.

The key takeaway? Set your recording area to be as big as your monitor will allow, while always maintaining the same aspect ratio as your slides.

Keep It Clean

When you set up your recording area, try to get everything to look as neat and tidy as possible. This includes closing any personal bookmarks and tabs, closing any expanding menus, and hiding personal or irrelevant information.

Before: Notice how messy it looks with all the tabs open and personal bookmarks displayed.

After: The recording area looks much tidier with all the tabs and bookmarks hidden from view.

You’ll also want to close any systems with pop-ups or alerts to prevent something from appearing during your recording that you’ll have to edit out afterward. In my example above, I’m logged into the system using my own account, and my name and avatar are displayed. Depending on the topic at hand, I might go so far as to create another account with a generic avatar and name to make the content less personalized. It all depends on the specific requirements of your project.

Crop Out Unneeded Areas

When you set your recording area, you should also do your best to crop out any parts of the screen that the learners don’t need to see. For example, let’s say you’re creating a software simulation that shows how to use an application that runs inside a web browser. Do your learners need to see the URL bar and the scrollbar along the right-hand side? Consider cropping them out of your recording altogether to give your recording a sharper look; doing so also lets the learner focus solely on the parts of the screen that are relevant.

After: Look how neat and tidy this recording area looks with the URL bar and scrollbar cropped out of the recording.

These are my three top tips for setting a recording size and area that will help you create a high-quality, professional-looking software simulation. To read more articles, tips, and tricks related to creating software sims, check out this series: Everything You Need to Know About Creating Software Simulations with Storyline. Do you have any other tips of your own for setting the recording area and size? Let me know in the comments!

Want to try something you learned here, but don’t have Articulate 360? Start a free 60-day trial, and come back to E-Learning Heroes regularly for more helpful advice on everything related to e-learning. If you have any questions, please share them in the comments.

Hi. Timely article! :) I recently published a software simulation that was captured in 1920X1080. I set all of the publishing quality settings to the max but when I viewed the scorm package in my browser, it looked really blurry. Eventually, I figured out that I was downsizing the resolution of my screen capture as the Storyline project was created in the default size of 720X405 in 16:9. I changed my story size to 1920X1080 and my captures now look crystal clear. I hope this helps!

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 monitor... Expand

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.

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).