The Difference between Screencasts and Software Simulations
If you’re new to creating software training—and even if you’re not!—you might use the terms screencast and software simulation interchangeably. But did you know they’re actually two different things? It can be easy to get these terms confused, so let’s walk through the nuances that differentiate these two methods and explore the use cases for each. Screencasts Screencasts are videos that show a recording of your computer screen. They’re often used to demonstrate the use of an application or software. They include all of your mouse movements and typically have audio narration that gives learners more contextual information about the process they’re seeing—such as the names of various software features or steps. Because screencasts are simply videos, they’re not interactive. When to use a screencast Screencasts are great for creating simple “how-to” videos. This kind of visual walkthrough is beneficial when you’re trying to explain a process that’s too complicated to explain with written text alone. And if the process isn’t something learners will be doing frequently, screencasts can be a helpful performance support resource that learners can easily reference in the future. How to create a screencast If you have Articulate 360, you already have access to not just one but TWO apps that are specifically designed for screencasts: Peek 360 and Replay 360. Learn more about when to use each app in this article: How to Decide Which Articulate 360 App to Use for Screen Recording. Want to see an example? Watch the “How to Add Comments in Review 360” screencast I created with Peek 360 below. This screencast provides a short overview of how to provide feedback on courses in the Review 360 web application. It’s perfect for an audience who may be comfortable with web-based technology and already have familiarity with Review 360. The screencast focuses on a simple process. It’s clear, concise, and to the point. So, how does a software simulation differ? Well, I’m glad you asked. Software Simulations While you also have to record your screen to create a software simulation, the major difference is that instead of simply showing the learners what to do, you give them the opportunity to try it out for themselves. They’re called simulations because you simulate the software’s interface by recording it and turning that recording into an interactive practice environment for learners. They can go through and click on all the buttons—like you did when you recorded it. It’s almost as if they’re using the software themselves. The advantage of doing it this way—versus simply having them use the actual software—is that you can build in on-screen explanations and feedback to guide them as they practice. Software simulations are usually the go-to for creating software training because they provide learners with a risk-free environment to help them learn a new app or process. Another thing that sets simulations apart from screencasts is that you can test your learners’ understanding by creating a simulation that’s graded. For every click in the right spot, learners can earn points. And for clicks in the wrong spots, points can be taken away. It’s a great way to ensure learners have understood how to complete specific processes within an app or software. When to use a software simulation Interactive software simulations are ideal when you want learners to physically practice using the software themselves—including entering data, interacting with drop-down menus, and identifying multiple steps in a more complex process. Software simulations give learners an opportunity to practice using the proper click-path of a specific process or software without fear of impacting the actual production environment or ruining any real-life data. With software simulations, you can put your learners in the driver’s seat so they can deepen their knowledge of a process, gain experience, and build confidence in using an app or piece of software. How to create a software simulation Articulate 360 subscribers can use Storyline 360 to create software simulations quickly and easily. Want to learn how? Here’s a tutorial that’ll help you get started: Creating Software Simulations in Storyline 360. Want to see an example? Explore the software simulation created with Storyline 360 below. In this example, users learn how to get started using the Review 360 web application. This simulation walks through four basic steps that you need to know how to do if you’ll be using Review 360. You’ll notice that because learners actually click through the software themselves, they must pay closer attention to each step in the process. This simulation is perfect for an audience who might not be as familiar with web-based technology or for users who are brand new to navigating Review 360. With simulations, learners can confidently navigate a new application because they’re practicing in the safety of a learning environment. View example More Resources Now you’re well on your way to identifying the nuances between screencasts and software simulations and you should be able to use these terms confidently when tackling your next project! To help you keep everything straight, I’ve outlined the differences in the handy table below. Screencasts Software Simulations Use case Demonstrate a simple, straightforward process. Train learners on a complex process through interactive practice and/or assessment opportunities. Interactive No Yes On-Screen Hints & Feedback No Yes Looking for more best practices around creating screencasts and software simulations? Check out these resources! And let us know in the comments what screencasts and software simulations you’ll be creating next. Follow This Process to Create Software Simulations and Systems Training Like a Pro 3 Methods for Recording Screencasts 4 Tips on Creating Software Tutorials in Rise 360 Tips for Using the Storyline 360 Screen Recorder Like a Pro Follow us on Twitter 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.How I Built This: The Confidence Self-Check Dashboard
What the Project Is The Confidence Self-Check Dashboard started with a challenge that many learning professionals will recognise: we're often very good at measuring learner perceptions at a single point in time, but much less effective at understanding the journey that got them there. Most confidence checks, smile sheets, and end-of-module surveys provide a snapshot. They tell us how a learner feels at the end of an experience, but they rarely show how much progress has been made between the starting point and the finish line. As learning designers, trainers, and educators, we're increasingly asked to demonstrate impact and effectiveness, yet many of our evaluation tools remain focused on isolated moments rather than measurable growth. The Confidence Self-Check Dashboard is an open-source framework designed to help visualise that growth. Learners can capture baseline, midpoint, and final confidence scores, creating a richer picture of progression across a programme, module, or learning journey. The system then visualises progress through checkpoints, historical tracking, and comparative reporting, helping learners and educators see not just where confidence sits today but also how it has evolved. What makes the project different is that the dashboard is only half of the solution. Built directly into the framework is a configurable Designer Mode that allows instructional designers, trainers, and subject matter experts to modify questions, scoring, weighting, feedback, and visual elements without touching the underlying code. Once configured, the framework can generate deployment-ready outputs for both standalone HTML environments and Storyline projects. For me, the project sits at the intersection of learning analytics, instructional design, and curiosity. It explores how we might move beyond static interactions and perception-based evaluation towards adaptable tools that not only support learning but help us better understand the impact of what we create. Why I Built This One recurring frustration I encounter as a learning designer is that many custom interactions end up as disposable solutions. They solve a problem for a specific programme, module, or client, but the moment somebody wants to adapt them, whether that's changing questions, adjusting scoring logic, updating feedback, or tailoring the experience for a different audience, the process often becomes disproportionately difficult. This isn't limited to Storyline. I've seen the same challenge across standalone HTML tools, JavaScript widgets, learning micro-applications, and community-shared frameworks. The learning community produces some incredible work, and I'm regularly inspired by the creativity on display. However, many of those solutions are understandably built to solve a specific challenge at a specific moment in time. Reusing them often means digging through code, unpicking logic, or rebuilding large chunks from scratch. At the same time, I was finding myself increasingly able to prototype ideas that previously would have stayed as scribbles in a notebook or half-finished thoughts in my head. That led me to a different question. Rather than repeatedly rebuilding interactions whenever requirements changed, could I create something that remained adaptable after development had finished? I became increasingly interested in building systems rather than outputs. Instead of creating another hardcoded interaction that would need future rebuilding, I wanted to explore whether the editing capabilities themselves could become part of the experience. The result was Designer Mode. Rather than expecting instructional designers, trainers, or subject matter experts to modify code, they could adjust questions, scoring, weightings, feedback, and configuration settings through a dedicated interface and generate deployment-ready outputs themselves. Ultimately, this project became an exploration of a broader idea: perhaps the most valuable thing we can build isn't the interaction itself, but the framework that allows other people to adapt it long after we've moved on. How I Built It The chronology of the project was actually quite different from what people might expect. It started with a community language-learning project where I was exploring how learners could benchmark their confidence over time using a simple Likert scale. At the time, I wasn't trying to build a framework. I was simply trying to create a better reflection point for learners. That evolved into a benchmarking dashboard, which I later adapted for quality management systems and professional development programmes. As the number of adaptations increased, I found myself repeatedly rebuilding or modifying the same interaction. The turning point came after sharing an earlier project with the Articulate community. Somebody asked a simple question (thanks to the E-Learning Heroes Community): "This is great, but how do I edit it myself?" That question stuck with me. The first version of Designer Mode was incredibly basic. It allowed users to configure the front and back of flip cards without touching the underlying code. Once that worked, I started asking questions: Could they change images? Could they update URLs? Could they alter scoring boundaries? Could they swap animations? Could they generate the code themselves? What started as a convenience feature gradually became the main project. At some point, I realised I wasn't really building interactions anymore. I was building frameworks that could generate interactions. The goal stopped being to build a better confidence tracker. The goal became building a system that could adapt itself. Once I made that mental shift, a lot of the design decisions suddenly became much clearer. My Development Workflow One thing I've learned is that my best ideas rarely arrive in a neat, structured format. They usually arrive as half-formed concepts, tangents, questions, and observations that need untangling before they become useful. Because of my dyslexia and dyscalculia, I often find it easier to explain concepts verbally than work directly with large blocks of code. Over time, I developed a workflow that helped translate those ideas into something more structured. ChatGPT often acted as a critical friend and sounding board. Gemini became my primary coding and debugging environment. Claude frequently challenged learner experience decisions, instructional design choices, and pedagogical assumptions. I also built a prompt generator that helped translate my often-discordant thought processes into something the various models could consistently understand and execute. Rather than generating code directly, it acted as a translation layer between ideas, constraints, learning requirements, accessibility considerations, technical limitations, and deployment requirements. One of the biggest lessons I learned was that prompting quality often mattered more than coding quality. I also learned very quickly that dirty context windows are real. The longer the conversations became, the more assumptions accumulated, and the more unpredictable the outputs could become. Managing context became almost as important as debugging. After what felt like the hundredth iteration, and probably wasn't far off, I finally realised I was solving the wrong problem: The challenge wasn't building a better interaction, it was making sure I didn't have to rebuild it again six months later. Exporting for Different Environments One of the design goals from quite early on was that I didn't want the framework tied exclusively to a single authoring tool. As a result, Designer Mode generates two separate deployment outputs. The first is a standalone HTML package that can be deployed independently and used outside of Storyline altogether. The second is a Storyline-compatible export. Rather than generating complete slides, the framework produces copy-and-paste-ready JavaScript that can be dropped directly into an Execute JavaScript trigger. The generated code sits behind a simple trigger, button, or slide event and handles the heavy lifting in the background. Supporting both outputs inevitably created additional testing and development effort, but it felt important that the framework remained flexible rather than becoming dependent on a single platform or workflow. Key Decisions & Trade-Offs One of the hardest parts of the project wasn't deciding what to build, it was deciding what not to build. There were plenty of moments where I could see an exciting next step. AI-generated learner feedback was one of them. Cloud storage was another. User accounts, enterprise integrations, reporting dashboards, and centralised administration all felt possible. But possible and sensible aren't always the same thing. AI-generated feedback sounds impressive until you remember that learners may act on that information. The last thing I wanted was a hallucinated recommendation confusing somebody or sending them down the wrong path. If that level of personalisation is going to happen, I think it belongs within a controlled organisational environment rather than inside an open-source learning widget. Cloud storage presented a similar challenge. Whilst it would unlock richer reporting and persistence, it also introduces authentication, security, GDPR considerations, APIs, hosting, maintenance, support requirements, and handover considerations. Very quickly, the project stops being a configurable learning tool and starts becoming a software platform. I had to keep reminding myself what problem I was actually trying to solve. The same challenge appeared within Designer Mode itself. Every new configuration option made the framework more powerful but also increased cognitive load. There is a point where flexibility becomes overwhelming. If somebody needs a developer sitting next to them to understand the configuration panel, I've probably failed. Sometimes the best design decision is leaving something out. 👉 Check out this build that exemplifies more of my design choices Why I Open-Sourced It The project is shared as open source because I genuinely believe we all stand on the shoulders of giants. That philosophy comes partly from learning design and partly from my blacksmithing hobby. Almost every forge project I've ever made has been inspired by somebody else's work, technique, or idea. Usually, somebody has already solved part of the problem before you arrive. The same is true in learning design: The more we share, the more we learn, the more we learn, the more we innovate. That's why the source framework, Designer Mode, and deployment outputs are all available for others to explore, adapt, and build upon. Not because it's finished, but because I hope somebody takes it somewhere I hadn't thought of yet. What I've Used It for Since Although the original use case focused on confidence benchmarking, the Designer Mode approach has quietly spread into a lot of my other projects. I've since added similar configuration layers to flip cards, quizzes, odd-one-out activities, swipe interactions, branching scenarios, media players, and other custom learning tools. Partly because it reduces build time, and partly because it reduces future maintenance. It also reduces the number of times I need to revisit the same problem. The framework can be adapted for: Skills audits Readiness assessments Professional development planning Reflective practice activities Learner self-assessment Progress check-ins What interests me most is that it turns what is often passive engagement into active reflection. Instead of simply consuming content, learners are asked to pause, think, and evaluate where they are right now. They feel included. Key Takeaways If there's one thing I'd encourage other instructional designers to take from this project, it's not that you need to become a programmer. You mustn't underestimate your ability to build. The tools available to us today mean that many of the barriers between an idea and a functioning prototype are lower than they've ever been. For me, the goal isn't to replace the work of learning design.It's to create more space for it. Less time wrestling with implementation. More time understanding learners. More time refining experiences. More time asking awkward questions. More time thinking. The biggest shift isn't that technology can generate code. The biggest shift is that instructional designers can now build tools, frameworks, and systems that previously required specialist development and teams. Use that opportunity wisely. Use it to remove the dross. Use it to reclaim time. And then spend that time doing the bits that humans are still brilliant at: creativity, empathy, reflection, judgement, and understanding what learners actually need. Ask Me Anything If you'd like to know more about the project, feel free to reach out or drop a comment below. I'm always happy to chat about generative AI in learning design, the successes, the pitfalls, and the occasional moments where everything goes wonderfully wrong. I'm also happy to talk about instructional design, learner engagement, accessibility, healthcare, accreditation, quality management systems, blacksmithing, or pretty much anything in between. Portfolio - Built with Claude Design and now hosted via GitHub Outside of learning design, you'll often find me metal-bashing in the forge, experimenting with new projects, or being supervised by my two feline quality inspectors, Tenacious D and Blackjack. Want to Share Your Build? Do you have a project you’d love to share with the community? We’re always looking for more How I Built This stories. Whether it’s a game, interaction, or unique design, we’d love to feature your process. Drop a note in the comments or reach out to the community team if you’re interested!Meet the Team: Hover Quotes for Storyline
Here's an example of how I've used quotes for meet-the-team type interactions. I've always been a fan of using quotes in my trainings and try to include a few in every course. Rise has some good options for quote blocks but quotes are rare in Storyline courses. View the example (download included)Back In My Day
Hello! Icebreaker games get a bad rap in corporate training. But I think Articulate's AI Avatar feature can breathe new life into this format. For this Futurama-inspired demo, I created a series of videos using the 'Upload Character' option in the Rise AI Avatar tool. Then I downloaded these videos and placed them in a 'Pick One' freeform question slide in Storyline. Your answer determines how my avatar responds. Try it out here: https://bit.ly/elhc553
Are you sure?
Hello! Personally, I've always found confirmation prompts like "Are you sure?" to be a little ominous and creepy. This week's demo is inspired by the hit horror movie, #Backrooms. This was another chance for me to practice with branching video scenarios, modal screens, and pairing footage created using Rise's new AI avatar feature with environments built in Google Flow. There are seven individual videos, which are shown/hidden depending on your choices. I found the AI text-to-speech in Storyline to be very versatile - the more you go round in circles, the more desperate the protagonist of the story sounds. There are four different routes through the demo. Be warned, two of the routes end in jump scares. You only have a 66% chance of making it through to the 'good' ending on one of the routes. Fancy your chances in the Backrooms? CLICK HERE
