Forum Discussion

AlexHigham-8141's avatar
AlexHigham-8141
Community Member
1 month ago

Coded Interactions

 

I've recently been experimenting with coded interactions in Rise 360 to see how far I can push the interactivity beyond the standard blocks.

I've been using GPT to help produce and refine the code, then tweaking and personalising the interactions to meet specific brand guidelines and learning requirements.

I'm really happy with the results so far, and it's opened up a lot of possibilities for creating more bespoke learning experiences directly within Rise.

There are some limitations I've noticed during testing, particularly around incorporating audio effectively within the interactions and ensuring they remain fully responsive across different screen sizes and mobile devices.

I'd be interested to hear from other eLearning developers who are experimenting with coded interactions:

  • What limitations have you come across?
  • How have you approached responsiveness and accessibility?
  • Do you see coded interactions becoming a bigger part of how we build bespoke experiences in Rise?

Here's an example I've been working on:

https://360.articulate.com/review/content/42e03dcc-6233-4bf0-908e-64d5543c0c7c/review

6 Replies

  • Hi AlexHigham-8141​, love seeing how you are experimenting with code! You might also like to check out some of these member projects if you haven't already. 

    PS: I added an image to your post as well. Feel free to swap it for an alternative. 

  • DeanW's avatar
    DeanW
    Community Member

    Awesome work! You've done a great job of incorporating extra functionality into the interactions.

  • ronald-hicks's avatar
    ronald-hicks
    Community Member

    Good questions, Alex. I've been working in the same space — code blocks in Rise — and the audio limitation you hit is the one I keep running into too. It's the browser, not Rise: audio can't start without a user gesture, so any coded interaction that plays sound has to be wired to a click or tap. In a custom block that usually means a visible play/start control, which changes the design more than you'd expect.

     

    On responsiveness: code blocks reflow with the page, but your HTML inside has to do its own work. I test every interaction at 360px wide and check that nothing needs horizontal scrolling — fixed pixel widths inside a code block are the usual breakage.

     

    On accessibility, three things I'd add:

    - Keyboard operability: every control in the interaction needs to be reachable and operable by keyboard, not just clickable divs.

    - ARIA live regions for feedback: if the interaction gives visual feedback (correct/incorrect, scores), announce it in a live region so screen reader users get the same information.

    - prefers-reduced-motion: if you're animating, respect it. A media query check in your CSS is a few lines.

     

    Do I see coded interactions becoming bigger? Honestly, yes for bespoke one-off moments, no as a default pattern. The maintenance cost is real — every coded interaction is code you own forever, including when Rise updates around it. I use them where nothing native can do the job, and native blocks everywhere else.