Articulate’s New Feature Addresses a Pain, but Not the Problem

‍

Summary: Articulate Rise’s new Code Block eases a real pain, but it does not solve the core problem of limited native authoring. dominKnow | ONE has long supported external code, yet teams ship faster and maintain less when they build natively. Use code for true edge cases. Rely on built-in capabilities for speed, consistency, accessibility, governance, translations, tracking, and dynamic updates. If you have a Rise library, dominKnow can convert it and keep your team moving.

‍

If your LinkedIn feed is anything like mine, you’ve seen the buzz: Rise 360 has a beta release that now lets you add custom code blocks (HTML/CSS/JS) to lessons. Articulate users are excited, and some are saying, “finally”. That reaction makes a lot of sense when Rise users, for years, have been boxed into using rigid building blocks, resorting to purchasing plugins, or making changes to content post-publish. For dominKnow | ONE customers, though, this “new” capability is old news.

dominKnow enabled the integration of external HTML and JavaScript content over 20 years ago. When dominKnow first implemented this feature, it gave authors who already used external tools, like Flash, a way to add interactivity and more advanced functionality. However, ultimately this approach provided an inefficient workflow and limited who could create more engaging content. Over the past two decades, dominKnow has continued to innovate, enabling authors to design and develop highly engaging and interactive content natively within dominKnow | ONE authoring. Enabling the use of native workflows and development capabilities democratizes content creation and leads to maximizing team members' efforts, which in turn makes creating impactful learning content far more efficient.

So, why the excitement around Rise’s Code Block (Beta)?

Rise’s new Code Block lets authors insert custom HTML, CSS, and JavaScript. It is especially useful because Rise’s native authoring options are quite limited. When authors want to go beyond basic layouts and simple interactions, they often run into a wall and must fall back to Storyline blocks, third-party plugins, or post-publish changes. Not surprisingly, other vendors and consultants have built unofficial plugins to help Rise authors overcome these limitations, and authors have resorted to modifying content post-publish to achieve their needs.

So yes, code blocks in Rise are a welcome stopgap for Articulate and do bring relief for Rise users. Although it’s, in essence, a relief from a self-imposed problem inherent with the limitations in Rise.

The Problem with Code First

Using built-in authoring should be your default. It keeps your team fast, consistent, and future-proof. Custom code is valuable, but it works best as the exception for truly unique needs.

Why built-in wins for most work

• Speed and scale: Authors configure, reuse, and update without waiting on a developer. Changes roll out across projects in minutes, not days.
• Consistency: One design system, one review process, one analytics story. No patchwork of widgets that look and behave differently.
• Responsiveness by default: Layouts, states, and interactions adapt to screens without extra coding.
• Accessibility and QA: Native components follow established patterns, which simplifies testing and reduces risk.
• Governance and reuse: Versioning, roles, collections, and component libraries fit enterprise workflows.
• Translations and variants: Single-source updates do not break embedded code or multiply maintenance.
• Data and tracking: Variables, scoring, and xAPI are available without custom plumbing.
• Lower total cost: Fewer handoffs, fewer brittle dependencies, and faster updates reduce ongoing cost.

When custom code still makes sense

• Truly novel interactions or visual effects that are not yet available natively.
• R&D and pilots where rapid experimentation is the goal.
• Vendor-agnostic widgets that you plan to reuse across tools and sites.

In dominKnow | ONE, if you add code, you can still bind it to native variables, actions, and data, so the experience remains integrated and maintainable.

Tradeoffs at a glance

Built-in

• Pros: Faster to ship, easier to maintain, consistent UX, responsive, accessible, governed, trackable
• Cons: Bound to product roadmap for highly niche effects

Custom code

• Pros: Maximum flexibility, reusable across ecosystems, good for innovation
• Cons: Higher maintenance, QA burden, potential responsiveness or accessibility gaps, security reviews, inconsistent UX if not carefully styled, tracking requires extra work

Guideline: Try native first. If you cannot meet the learning goal with built-in capabilities, use custom code and connect it to the product’s native variables and actions so it plays well with the rest of the course.

dominKnow | ONE Supporting Native and Code

dominKnow has supported embedding and communicating with external code for decades. However, dominKnow knew that while this is a valuable option, it should be the exception, instead of the rule. This realization led to the development of native capabilities, resulting in an author’s first move not being “paste code,” but instead “configure the feature.”

Some examples include:

• Flexible interactivity without coding. Triggers, states, actions, variables, conditionals, scoring, feedback, and reusable components are available in both responsive (Flow) and slide-based (Claro) modes, all in the same product and interface.
• Consistent responsiveness. You do not bounce to a second tool and insert non-responsive blocks into your responsive design, nor do you require your author to code responsive blocks. No “Rise for pages, Storyline/Custom Code for interaction” split.
• Reuse for easy updates. With reuse, authors can update their coding widgets once (and for many more elements), and changes propagate everywhere.
• Dynamic publishing. When ready to send to learners, update the published course, with no need to download and upload the SCORM package to the LMS. Unlike Rise, when coupled with Reach 360, dominKnow | ONE authors can do the same with any LMS or multiple LMSs.
• Single source, multi-audience, multi-language publishing. Target roles, regions, and languages from one project instead of cloning courses. Further, when you create natively without a code block, your single-source design and translations don’t become a burden.
• Team scale governance and reuse. Versioning, roles, collections, and component libraries that are ready for enterprise authoring.

If you want to bring in your own code, go ahead. In dominKnow | ONE, not only are your code widgets reusable, so other team members can take advantage of your unique design, but you can also use our Content API and enable your widget to talk to the course. You can read and set variables, share data, and drive logic across the experience. Not only does this make a better integrated learner experience, but it also enables you to set up widgets that are flexible and can easily be adjusted by non-programmers who send native actions to your widget to “configure” it for their unique needs.

In the next sections, I’ve put together a few video clips to illustrate these points using the examples Articulate shared as use cases for their new coding block. In each case, it is clear why Articulate Rise users are excited but would likely be even more thrilled if they could achieve the same thing natively within Articulate Rise. With dominKnow | ONE, you can do just that and can insert code too, if you like.

Image blur or reveal interaction

This interaction example illustrates a way to hide an image, via a blur, and reveal it when the user interacts with it (mouses over).

• Rise approach: Use the Code Block to embed a custom blur or reveal widget because there are no equivalent native blocks or options.
• dominKnow | ONE approach: Either upload the same widget as a reusable widget or build the interaction without code using dominKnow | ONE’s image editor plus states and actions. When you use built-in controls, you get more control over triggers, timing, design, and responsiveness. When you keep everything native, it makes it easier for your team to develop and maintain.
  

‍

‍Why it matters: You get design freedom, fine control, and it’s just a lot easier when you leave your content creation in the native authoring capabilities and eliminate the need to create or maintain custom code.

Branching scenario

This next use case was a bit of a surprise when I first saw it. It looked a lot like Articulate Rise’s branching scenario block. However, upon closer examination, I saw they added several subtle but important aspects, such as a score for the scenario that simply aren’t possible in their native block.

• Rise approach: The built-in Scenario block, which enables a one-on-one branching discussion interaction, is quite handy, but the user base has cited several complaints over the years around its flexibility. Some of these are:
  
  • As an author, you can’t see the full branching logic
  • No scoring
  • No tracking data
  • Limited question and response text length
  • No audio options

The code-based example overcame some of these limitations, resulting in a valuable improvement in the learning experience.

• dominKnow | ONE approach: The Scenario Builder in dominKnow has a greater degree of flexibility and features built in than in Rise. It includes a visual of the branching design, unlimited question and answer lengths, ability to add audio, different score results and score feedback for different result paths, scores stored as a variable, customizable characters, and xAPI tracking data. Of course, you can also upload the same scenario widget, but then you can also reuse it across multiple courses.
  

Why it matters: Keeping your content in-tool enables consistent design across your content and makes it easier for all team members to support content maintenance. Ultimately, this in-tool flexibility helps teams to achieve their learning goals and get meaningful data and outcomes.

Personality quiz with data handoff

The last example provided is a clever personality exam with several questions that, based on the learner's responses, lead to an evaluation and identification of a personality type. Variations of this type of interaction can be quite valuable in providing a more realistic and real-world learning experience.

• Rise approach: Anything beyond basic quizzing tends to require a code block or Storyline block. If you build a single question quiz, the data stays inside the block and you can’t use it elsewhere so using a code block is the only way you can do this; besides loading a Storyline block.
• dominKnow | ONE approach: This can be built natively with input controls (text entry, radio, checkbox, slider, and menu options), variables, and actions. Using that approach, like the other examples, it is much easier to build, maintain, and have complete control over the design. However, in this case, I decided to use the code block, but improved it by taking advantage of dominKnow | ONE’s API. Yet another option not available in Rise. In this case, I wanted to use the results from the code block and set them as a variable so those results could be used natively in dominKnow | ONE. This approach enables dominKnow | ONE authors to then personalize the learning based on the personality type. This could range from personalizing the content for each personality type throughout the course or simply using that information for different reflection exercises.
  

The demo shows the custom code and the data handoff into native dominKnow | ONE logic.

Why it matters: Custom widgets don’t have to be a one-and-done dead end. You can leverage work done by others and then use it to drive personalization and a better overall learning experience throughout your content.

One tool, two modes, no context switching

A big reason Rise users are celebrating code blocks is that they finally get some flexibility inside Rise. In dominKnow | ONE, you have one interface for both fully responsive content (like Rise) and traditional slide-based (like Storyline). Robust layout control, interactions, variables, and review are consistent across design choices. There is no context switching between tools and no feature roulette or learning two tools.

Why this is bigger than a feature check

Feature parity headlines can distract from the real questions.

1. Do I need custom code for common use cases?
   In dominKnow | ONE, the answer is usually no. When the answer is yes, the integration is deep and maintainable.
2. Can my team scale without rewiring workflows?
   dominKnow | ONE is an LCMS, not just a page builder. Governance, reuse, translations, variants, collaboration, versioning, and dynamic delivery are designed in, not bolted on.
3. What is the total cost of ownership?
   Fewer tool handoffs, less brittle custom code, and dynamic updates add up to faster cycles and lower maintenance. The savings are especially visible at enterprise scale.
   
   Learn more about some of the differences between Articulate Rise and dominKnow | ONE

Already have a Rise library? We will convert it

If you are curious but looking at a wall of existing Rise projects, we have you covered. Our conversion engine transforms Rise packages into fully editable dominKnow | ONE projects. The process is quick and maintains fidelity, so your team can improve, localize, and extend content without starting over.

Learn more about Articulate Rise to dominKnow | ONE content conversion

Bottom line

Rise’s Code Block is a step forward for Rise. If you are evaluating your stack for 2025 and beyond, ask yourself a simple question. Do you want a tool that lets you paste code to escape limitations, or a platform that has spent decades removing those limitations altogether?

dominKnow | ONE has supported external widgets for years. More importantly, we built the native power that makes them optional. You get deeper interactivity, enterprise scale, and one consistent authoring experience across responsive and slide-based content.

Watch the demos and picture your work without workarounds.

1. Image blur
2. Branching scenario
3. Personality quiz and Content API data handoff 

Then see what your current library looks like in dominKnow | ONE. We will convert your Rise content and show you what real flexibility feels like.

Looking for a new LCMS or authoring tool?

We’d love to show you why dominKnow | ONE is the best authoring solution for learning teams, providing the power, flexibility, collaboration, and control they need to create, manage, and deliver high-impact learning content at scale.

‍Get your demo here, and we’ll show you around!