Abstract

This proposal outlines the development of a Learning Materials Review feature in Open edX Studio. The aim is to introduce a structured, collaborative review process for course authors, instructional designers, subject matter experts (SMEs), and institutional stakeholders. The feature would allow draft course content to be shared, annotated, and iteratively improved within the Open edX authoring environment, thereby eliminating reliance on external tools like Google Docs or Word documents and significantly improving feedback quality, version control, and content development efficiency.

Context & Background

Despite Open edX Studio’s robust content creation capabilities, many educators and instructional designers avoid building course materials directly in the LMS during early-stage development. Instead, they rely on external storyboards, text-based drafts, or slides to iterate with stakeholders. This results in several pain points:

• Fragmented collaboration: Feedback is scattered across platforms (email, PDFs, Word) and difficult to track.

• Redundant work: Final content must be re-entered into Studio after the storyboard is approved.

• Poor visibility for reviewers: Stakeholders without Studio experience often can’t visualize how the written content will appear on the platform. This creates confusion, miscommunication, and misaligned expectations.

• Limited Studio adoption: The authoring tool is used as a final input step rather than a collaborative design space.

These issues are especially acute in environments where:

• Multiple reviewers must sign off on course content

• Institutional approval is required before launch

• Courses are localized into multiple languages

• Projects involve distributed or cross-functional teams

Use Cases

Instructional Designer + SME collaboration
An ID builds a draft unit in Studio and shares it with an SME for review. The SME highlights unclear terminology, suggests rephrasing, or flags inaccuracies, all directly within the course view.

Stakeholder sign-Off
A high-level stakeholder needs to approve a course before it is published. Instead of exporting or emailing documents, the stakeholder receives a link to the module, reviews it in context, and leaves feedback.

Localization and translation review
A course is translated into multiple languages. Translators can leave in-line comments where content needs clarification, cultural adaptation, or formatting adjustments.

QA and accessibility checks
A QA specialist reviews a near-final draft and flags blocks with accessibility or usability issues directly in the LMS, enabling the content team to resolve them quickly.

Course iteration post-launch
A course has already been published. A course team plans improvements for the next cohort. They mark sections for revision based on user feedback or analytics.

Visualizing course layout for non-technical stakeholders
When a stakeholder, client, or SME reviews a course draft via Google Docs or Word, they often ask, “What will this look like to learners?” The layout, interactions, and media placement are not apparent. A Review Mode in Studio provides a realistic preview of the final learner experience, bridging the gap for stakeholders unfamiliar with LMS structures.

Scope & Approach

We propose introducing a Review Mode in Open edX Studio, enabling realistic course previews and collaborative feedback workflows. This would:

• Allow stakeholders to experience the course as learners would, without needing Studio access or training.

• Eliminate guesswork caused by abstract storyboards or text-only documents.

• Provide context-aware commenting, making it easier to give actionable feedback.

The approach includes the following components:

Review Mode toggle
Course authors can activate "Review Mode" on draft units or subsections. This generates a Review Link that provides a read-only view of the course content.

Inline commenting
Reviewers can click on specific content blocks (text, video, quiz, etc.) and leave comments. Comments appear in context, much like Google Docs or Figma’s comment layers.

Comment panel
All comments are listed in a sidebar or overlay, grouped by block. Threads allow back-and-forth discussion. Comments can be marked as “resolved.”

Roles and permissions
Only reviewers with appropriate permissions (assigned via email or user role) can view or leave comments. Admins can set whether links are public or private.

Notifications and version history
Optional email or in-app notifications alert authors to new comments. Comments are saved with time stamps and optionally associated with a unit version for historical traceability.

Supporting Market Data

• 30% of instructional designers surveyed by Synthesia in 2024 reported that delays in SME collaboration significantly slow down design workflows (source)

• 64% of employees in workplace studies report losing at least 3 hours weekly due to redundant feedback processes and inefficient collaboration – a proxy for the time lost in external storyboard review cycles (source)

• Articulate Review 360 is widely used because it enables in-context stakeholder comments without requiring platform access providing a seamless, real-time feedback loop embedded directly within course content

Proposed Solution

The feature can be developed as a modular extension to Studio with minimal changes to core authoring workflows. It would include:

Other Approaches Considered

Competitive Research

The opportunity is clear: Open edX can lead among open-source LMS platforms in this space by offering integrated, flexible review workflows.

Implementation Plan

Phase 1: Research and community feedback (1 month)

• Conduct interviews with educators, IDs, and partners

• Validate user stories and preferred UX flows

• Define MVP scope with input from Open edX Product Working Group

Phase 2: Prototype (2 months)

• Develop commentable block wrapper components 

• Create review links and view-only preview interface

• Implement comment threading and resolution logic

• Develop permissions system (basic reviewer roles)

Phase 3: Testing and pilot (1 month)

• Test feature in Devstack and Tutor environments

• Run pilots with 2–3 partners (e.g., universities, NGOs)

• Gather and implement feedback

Phase 4: Community contribution (1–2 months)

• Document code for PR submission

• Align with Open edX governance and release process

• Host a demo during the Open edX community call

Estimated resource needs:

• 1 UX Designer

• 2 Front-End Engineers (React, Studio)

• 1 Back-End Engineer (Django, Studio permissions)

• QA Support and Pilot Coordinator

Proposed By

Raccoon Gang