Skip to content
Platform implementation

Articulate Rise

Rise is the first mature implementation of the ISQ eLearning Design System. It uses a controlled hybrid model: native capability where it communicates clearly, custom code reserved for recurring needs Rise cannot adequately express.

Delivery architecture — three coordinated layers

LayerBest used forKey constraints
Native Rise blocksGeneral prose, images, standard accordions/tabs, simple knowledge checks, navigation, built-in accessibility behaviour.Limited visual control; rendered HTML can change when Rise updates.
Custom code blocksReusable editorial panels, scenario stages, specialised comparisons, decisions, tabs and resource treatments.Runs within Rise containment; links, iframe behaviour and script loading must be tested in published output.
Post-publish CSSHeading hierarchy, selected native block styling, spacing and platform continuity after export.Must be re-applied after every export; selectors can be fragile and should be tightly scoped.
External hostingShared CSS, images and selected media from approved storage.Requires stable URLs, correct MIME types, CORS, cache management and availability.
Custom blocks should be self-contained in structure but not duplicate shared CSS. A block loads the one approved stylesheet and uses namespaced isq- classes; course-specific inline CSS should be exceptional and documented.

Native, custom and post-publish decisions

Choose the least complex implementation that fully serves the learning purpose:

  1. Can a native Rise block communicate the content clearly? If yes, use native.
  2. Is the requirement recurring across courses? If yes, assess an existing or propose a reusable custom component.
  3. Does the custom treatment add real learning or communication value? If not, don't customise.
  4. Can the pattern remain accessible and responsive in published output? Test before approving.
  5. Does it require styling Rise-generated markup? Use tightly scoped post-publish CSS only, after export testing.

Stylesheet delivery & hosting

Reference an immutable version once a course is published — do not silently overwrite a stylesheet already consumed by a live course. A latest/test alias may be used only in development.

<link rel="stylesheet" type="text/css"
      href="https://xapistorage28032026.blob.core.windows.net/xapitestcourses/css/isq-rise-components-v1.0.0.css">

Current production version: 1.0.0 (internal header states v1.0.0; the filename on disk read by this site is isq-rise-components-v1_0_0.css). Next release should adopt isq-elearning-rise-v1.1.0.css naming per the umbrella system's naming resolution.

Publishing workflow

  1. Author — build the Rise course using approved native and custom blocks.
  2. Preview — desktop, tablet, mobile and keyboard checks in Rise preview.
  3. Export — apply agreed xAPI completion and tracking settings.
  4. Enhance — inject approved post-publish CSS and package assets.
  5. Validate — test launch, links, tracking, styling and completion in the published package.
  6. Release — record version, package and stylesheet dependency.

xAPI, hosting and versioning

Completion and tracking settings are applied at export and validated in the published package — never simulated. Rollback: retain previous production CSS files and document which courses consume each version. Every release records a changelog of added, changed, fixed, deprecated and removed patterns.

Troubleshooting

SymptomLikely causeFirst response
Styles missingStylesheet blocked, cached or wrong URL/MIME type.Open the CSS URL directly; check the network request and version.
Only some blocks failClass-name mismatch or legacy HTML structure.Compare markup with the approved example and this site's class index.
Post-publish styling disappearsExport replaced the modified files.Re-run the documented enhancement step after every export.
Interaction works once onlyGlobal IDs/variables or unscoped event handlers.Scope queries and state to each component root.