New in Labs: Block Defaults

I would like to request an enhancement to the new Block Defaults functionality in Rise: the ability to globally manage the default state of audio playback locking for Audio blocks.

Specifically, it would be extremely valuable to allow course authors to:

• Set audio blocks globally to Locked by default
• Set audio blocks globally to Unlocked by default
• Ideally toggle this setting at the course level without needing to modify each individual audio block manually

For organizations producing larger Rise courses, this would solve a significant workflow and QA challenge.

A typical 1-hour course may contain:

• 3–5 lessons
• 3–5 modules per lesson
• 5–8 audio blocks per module

This can easily result in approximately 100 individual audio blocks within a single course.

Currently, if an organization wants audio locking enabled, each block must be configured manually. This creates several issues:

1. Significant Development Overhead

Manually configuring dozens or hundreds of audio blocks is time-consuming and increases the likelihood of missed or inconsistent implementation across a course.

2. QA and Testing Challenges

Because audio locking is managed at the individual block level, QA teams must verify each audio block separately.

Unlike other settings that can be spot-checked quickly, locked audio requires testers to sit through the entire playback before progressing to the next section. This turns otherwise efficient spot-check reviews into lengthy sequential review processes.

3. Troubleshooting and Revision Friction

During development or post-publish fixes, IDs and QA reviewers often need to temporarily disable locking to quickly navigate and validate content. Without a global control mechanism, teams must revisit potentially dozens or hundreds of audio blocks just to toggle settings on or off for testing purposes.

Why Block Defaults Would Help

If Block Defaults included a global audio-lock setting, organizations could:

• Maintain consistency across courses
• Reduce implementation errors
• Streamline QA workflows
• Temporarily disable or enable locking during testing cycles
• Save substantial development and maintenance time

Even better would be a course-level override or publishing option that could globally enforce or remove audio locking without requiring edits to every audio block individually.

This would make audio-lock functionality much more scalable and manageable for teams producing high-volume or highly-audio-driven Rise content.