How Rise Canvas was created

The Problem I was trying to solve

Articulate Rise is a fantastic e-learning authoring tool, but its built-in block library has limits. When you need something beyond what’s in the standard library, a custom stats infographic, a branching scenario with a bit more functionality, the ability to mix and match interactions and infographics in the same block, re-size components and align them how you want, your options are limited. The introduction of the Rise code block, which lets you drop raw HTML, CSS and JavaScript directly into a lesson was a game changer for me. The potential is enormous.

So this was the starting point. I knew I could find a better way to do what I needed in my courses. 

Phase 1 — The Individual Component Builders

The first decision was foundational: what format should these tools take?

I landed on self-contained single HTML files. No frameworks, no build tools, no dependencies, no server required. Every builder is one file that opens in a browser and just works. This was a deliberate choice, the tools needed to be simple to distribute, simple to open, and simple to maintain.

Each builder file contains three things inside a single HTML document:

• The UI — a panel of controls on the left (text inputs, colour pickers, sliders, toggles)

• A live preview — an iframe on the right that renders exactly what Rise will render

• A buildHtml() function, this is the engine that reads the current settings and generates the finished HTML string.

Building the first few

The first builders were the most important, because they established the pattern everything else would follow. I started with the components that get I used most, accordion, tabs, flip card, etc and built each one by working through a consistent set of questions:

• What content fields does this component need? (headings, body text, images, icons)

• What style options are genuinely useful? (colours, font sizes, layout variants)

• What does the output HTML need to do at runtime in Rise? (animations, interactions, accessibility)

Every builder was written with all settings held in a JavaScript object called S (for State). Every UI control reads from S and writes back to it. When anything changes, a refresh() function regenerates the preview. This means the preview is always a true representation of what you’ll get.