Visually Configure Course Components
- Marco Morales
- Dave Ormsbee (Axim)
Status | READY FOR REVIEW |
|---|---|
Contributing Team | @Marco Morales , @Sam Daitzman |
Earlier Discovery | N/A |
Linked Initiatives | N/A |
Overview | Visually configuring course blocks should dramatically increase the visibility of existing blocks already enabled, as well as options to configure course level blocks centrally. We hope this work helps encourage the usage of a wider range of existing Xblocks. Advanced settings page configuration for configuring xblocks would be deprecated (eventually) in favor of configuration tools in the Pages & Resources area of Studio. |
Overview
Visually configuring course blocks should dramatically increase the visibility of existing blocks already enabled, as well as options to configure course level blocks centrally. We hope this work helps encourage the usage of a wider range of existing Xblocks. Advanced settings page configuration for configuring xblocks would be deprecated (eventually) in favor of configuration tools in the Pages & Resources area of Studio.
- 1 Overview
- 1.1 Abstract
- 1.2 Context & Background
- 1.3 Scope & Approach
- 1.4 Value & Impact
- 1.5 Concept Sketches
- 1.6 Milestones and / or Epics
- 1.6.1 Initiative 1: Default On Advanced Components in Studio Unit Pages
- 1.6.2 Initiative 2: Course Components Page in Studio (+ Add Advanced workflow)
- 1.6.3 Initiative 3: Documentation Review - Course Components
- 1.6.4 Initiative 4: Revisit Unit Page Add Components UI
- 1.6.5 Initiative 5: Common Block Configuration at Course Level
- 1.6.6 Initiative 6: LTI Block Configuration at Course Level
- 1.6.7 Initiative 7: Layout and Data Improvements to Component Configuration
- 1.6.8 Initiative 8 + Other topics include:
- 1.7 Named Release
- 1.8 Timeline
- 1.9 Proposed By
- 1.10 Discovery: XBlocks installed into Open edX by default
- 1.11 Archived Concept Sketches
This document was created using the OE Roadmap Submission item template , but it likely will benefit from being represented in the roadmap as a series of smaller efforts to make it easier to provide visibility on whatever fraction of this set of initiatives moves forward.
Abstract
We should find the lowest effort path to migrate away from XBlock configuration in the Advanced Settings page in Studio. Initial thinking here is pointing toward adding configuration of XBlocks available in your course to being accessed from the Pages & Resources view in Studio. This lets us move to listing patterns for Core Blocks, Advanced Blocks, and potentially also LTI Blocks.
Context & Background
It has been too many years that we have asked course educators to use JSON to enable advanced content blocks, and we can do better using newer platform tools. (MFEs + Paragon)
We would like to surface existing platform flexibility and configuration power even as we look toward larger directory efforts to further enrich these capabilities.
From initial conversations, this seemed like an opportunity to explore surfacing configuration defaults for common content blocks (ex: Video settings, Capa problem defaults to unlimited attempts), advanced blocks (goodbye Advanced Settings config), as well as LTI blocks.
Scope & Approach
The team at Schema has only just started scope and approach discovery review based on discussion from the Open edX 2024 Conference regarding Xblocks + Flexibility / Configuration themes in State of Open edX keynote.
We are interested in collaborating with the community on next steps for this project, including product and design definition, as well as eventually potential sequencing & funding options.
A new Content Blocks card within the Pages & Resources area in Studio could be the right place to show all content block details and configuration options.
Common - Basic course content blocks: Video, Problems, Drag Drop, ORA, Text / HTML, (others?)
Advanced - This would take all site level xblocks and make them all visible by default within the “Advanced” card on Unit pages. They could be disabled at the site / org level in the future. This intersects with a future XBlock directory for the community, but can be delivered incrementally with a focus on improved educator configuration and visibility to start.
LTI - We could also move to having course levle configuration for LTI blocks, with course level configuration workflows similar to Canvas and other tools. This would make that block more easily selected from the Unit page. This work may need several increments as it intersects with both configuration needs and a future LTI directory.
As a result of this work we would ideally be able to remove the Advanced Module List area in Advanced settings and mark that setting field deprecated.
Value & Impact
We should be able to remove the painful experience of configuring xblocks through a JSON block in advanced settings, and recognize that course educators deserve to spent time in an easy to use authoring environment not an administrator like tool experience.
We hope this encourages broader review and use of existing XBlocks and encourages educators to explore other blocks already enabled at the instance level that they may not know exist because of the advanced settings configuration pre-requisite to seeing these blocks on Unit pages.
This would make incremental progress toward course level common xblock default settings, and also provide a home for LTI configuration and visibility at the course level.
Concept Sketches
These are v1.1 updates to the original visuals for this effort. What is included in the next design is still TBD, but this shows some of the patterns being echoed from the content libraries work in development currently around content block cards.
Figma collateral for input and feedback as well: https://www.figma.com/design/9ucY7R9hOfRmQWLgnJsLyF/Visual-XBlock-Configuration?node-id=26-6912&t=5tUFP5AWC2uNVNxl-1
Milestones and / or Epics
Initiative 1: Default On Advanced Components in Studio Unit Pages
Goal: Default all advanced components (after review) to be visible within the Advanced card on Studio Unit pages from the list of xblocks enabled automatically in the open edx platform.
We would like to review the list of xblocks enabled by default in the Open edX platform, and mark which ones should be visible by default as “Advanced” components, and which should be “Common” blocks shown as a dedicated card on Unit pages within Studio.
In configuration for XBlocks, we would be adding a way to denote which ones are default enabled in courses, and possibly other fields to be considered at this time (Support Level, Documentation URL, etc). This could be a way also for sites that enable custom xblocks to mark them as “default enabled” within their instances.
In this small initial scope we are hoping to deliver visibility of components even if improved configuration isn’t yet possible.
Screens:
Initiative 2: Course Components Page in Studio (+ Add Advanced workflow)
Goal: Introduce new central location to review course level components, to eventually contain Common, Advanced, and LTI blocks. As a starting point this version would show Common + Advanced blocks, as well as the ability to “Add Advanced Component” which would let you more easily configure non-default advanced blocks.
This initiative would introduce a basic “Course Components” card in Studio within the Pages & Resources area that shows a list of all common and advanced blocks in the course.
The ability to “Add Advanced Component” from this view would let you specify the name of a block, allowing a course to enable advanced xblocks that are installed but not shown by default.
By adding this we can fully deprecate the Advanced Settings “Advanced Modules” list since we will have a mechanism for enabling non-default blocks at the course level.
Screens:
Initiative 3: Documentation Review - Course Components
Goal: Identify plan to update documentation to match reduced configuration requirements and new way to enable non-default xblocks for a future named release.
We should determine the path forward for updating documentation to match the changes in Initiative 1 and 2. Both these first initiatives lay the foundation for future updates, but enough will have changed that we should do a full documentation revamp for components at this point.
Initiative 4: Revisit Unit Page Add Components UI
Goal: Review the UI for adding components to a unit page, and take the findings of recent efforts around LTI Redesign Project , the Brief: A Vision for Content Libraries work, and more to account for secondary selection lists for LTI + Advanced Blocks.
Initiative 5: Common Block Configuration at Course Level
Goal: Augment listing of common blocks in “Course Components” area to support block level defaults at the course level.
There are a number of advanced settings that set course level defaults for blocks like the Text, Video, and Problem blocks. By putting configuration for thse into the new course components area we can ALSO mark these settings deprecated.
List of Advanced Settings that would move into Common Components - configuration views
Maximum attempts - Problem configuration
Randomization - Problem configuration
Show Answer - Problem configuration
Video sharing options - Video configuration
Force flexible grading for peer oras - ORA configuration
Enable latex compiler - text / html blocks (is this still alive and usable?)
Initiative 6: LTI Block Configuration at Course Level
Goal: Connect LTI configuration and review to be possible at the course level in the same place as other course components.
Initiative 7: Layout and Data Improvements to Component Configuration
Goal: Update the Course Components page to include both a table listing and card view, with the incorporation of course usage data to help visualize to educators which blocks are being used in their course.
This is an opportunity to help order blocks based on active course usage, and potentially find a way to designate which blocks are mobile friendly as well. The grid and card layouts would echo patterns we are exploring in the Content Library project.
Initiative 8 + Other topics include:
Full XBlock Directory / Publishing Workflow
Open edX LTI Directory / Publishing Workflow
Org / Site Level LTI Configuration → This is being covered by , should review pattern similarity.
LTI Block Add on Unit Page → This is being covered by , should review pattern similarity.
Instance / Site / Org Level Controls for Components (echoing the work done for LTI in LTI Redesign Project with this being available at the site level.) This would let there be site / platform / org level ways to confgiure block dfautls or allow / disallow certain blocks further down at the course level, giving for example and Org the ability to default enable a tool that we would otherwise not want enabled for other orgs by default.
Named Release
This is TBD based on community interest and funding.
Timeline
TBD
Proposed By
@Marco Morales , and team @ Schema Education
Discovery: XBlocks installed into Open edX by default
(Dave Note): I still need to finish this. There’s a lot of “customtag” related stuff that I should explain better. It was designed as an XML-author power-user feature to allow individual courses to define their own tags and simple templating behaviors of those tags. I’m not sure if it’s ever actually worked in Studio, and it doesn’t appear to work now.
Tag | Class | In Unit? | Default On? (Proposed) | Category (Proposed) | Description | Notes |
|---|---|---|---|---|---|---|
acid |
| NO | -- | -- | Technically a component, and technically could go into a Unit, but it has no pedagogical value–it exists only to test XBlock functionality. |
|
acid_parent |
| NO | -- | -- | Exists only to test XBlock container functionality. |
|
| YES | No | Advanced | In an annotation problem, you highlight specific text inside a larger text block and then ask questions about that text. The questions appear when learners move their cursors over the highlighted text. The questions also appear in a section below the text block, along with space for learners’ responses. | No editor. | |
book |
|
| -- | -- |
|
|
chapter |
| NO | -- | -- | This is a Section. |
|
| YES | Yes (if UI) No | Advanced | Intended to gate access to some piece of content through some code-level conditions, e.g. “they attempted this other problem first”. | There’s a GUI here, but it seems half-baked. I think it would need more work before we turn it on by default. | |
course |
| NO | -- | -- | This is the root of a Course. Also where all the advanced settings live. |
|
course_info |
| NO | -- | -- | This is what goes in the “About the Course” blurb if you’re using edx-platform’s built-in enrollment/marketing views. |
|
| YES | No | Advanced | The Crowdsource Hinter serves to provide students with hints when they incorrectly answer a problem within a course. The hinter is compatible with numerical input and text input type problems. | No editor. Prototype. Will not scale to large classes. | |
custom_tag_template |
|
| -- |
|
|
|
customtag |
|
| -- |
|
|
|
discuss |
|
| -- |
|
|
|
discussion |
| YES | No | Advanced | Inline discussion block. I can’t find an explicit DEPR for this, but this component has largely been sidelined in favor of marking the Unit discussable and putting those discussions in the right-hand context panel. | We’re moving away from this. |
done |
| YES | No | Advanced | This is titled “Completion” in the UI. A simple way to let students mark and track that they’ve completed something, but it doesn’t actually interact with our completion API (i.e. the thing that marks a Unit “complete” and gives you a check mark). (Dave’s opinion): I think we should eventually fold this into the Unit itself, like how we did for discussions. The heuristics we use to estimate completion in the Completion API are not always reliable, and run into edge cases that it can’t really handle gracefully. We can keep the heuristics, but I’d like to have an override where someone can say, “Yeah, I did this. Really. Now let’s move on.” |
|
drag-and-drop-v2 |
| YES | Yes | Common | Our supported Drag and Drop component. | On by default. |
edx_sga |
| YES | Yes |
| Staff Graded Assessment, maintained by MIT ODL. |
|
error |
| NO | -- |
| This is what the LMS renders when something goes wrong while trying to render other XBlock types. |
|
google-calendar |
| YES | Yes | Advanced | Iframes a specified Google Calendar. Workaround from the time before Dates tab existed. Any usefulness it has in a course likely points to areas where the Dates tab needs to be improved. |
|
google-document |
| YES | Yes | Advanced | Works for any Google Drive document, not just word processing–so slides can show up here, for instance. Also works via iframe embed. |
|
hidden |
| NO | -- |
| This is what the system uses when it can’t find an XBlock class to match a given tag in the data. Usually this happens because you’ve imported a course into a new site that doesn’t have that particular XBlock installed. |
|
html |
| YES | Yes | Common | This is the component created when you create a new “Text” component. Already on by default. |
|
image |
|
| -- |
|
|
|
library |
| NO | -- |
| This is the root XBlock for a ModuleStore-based (v1) Content Library. |
|
library_content |
| YES | Yes | Common | XBlock used for adding library content to a course. |
|
lti |
| YES | No | -- | Our unsupported LTI XBlock. |
|
lti_consumer |
| YES | Yes | Common | Our supported LTI XBlock. I believe there are still one or two things that the old version does that this one doesn’t support, which is part of why we haven’t managed to kill the old one yet. |
|
openassessment |
| YES | Yes | Common | Open Response Assessment, i.e. self/peer/staff grading of short essay responses. One of the most complex XBlocks. | On by default. |
| YES | Yes | Advanced | Supported Polling XBlock. |
| |
| YES | No | -- | Unsupported Polling XBlock. | No editor. | |
problem |
| YES | Yes | Common | The most important assessment type with a variety of advanced input and response types ranging from multiple choice to schematic editors. | On by default. |
randomize |
| YES | ? | Advanced | Selects exactly one child item to display to a given student. | Has GUI |
| YES | No | Advanced | The recommender provides learners with a list of online resources related to the course content. These resources are jointly managed by course team members and the learners. | Not supported. Scaling concerns. Not very polished. | |
scorm |
| YES | Yes | Advanced | Needs a license to be enabled, might not be possible to default on |
|
sequential |
| NO | -- |
| This is a Subsection. |
|
slides |
| -- | -- |
|
|
|
| YES | Yes | Advanced | This is a Content Experiment to show different groups of people different content. It works by essentially making two mini-units inside the main Unit. |
| |
| YES | No | Advanced | Pre-cursor to |
| |
static_tab |
| NO | -- | -- | This lets you put HTML as a custom tab in the courseware, alongside things like Dates and Progress. |
|
| YES | Yes | Advanced | A more sophisticated polling, and lives in the same repo as the |
| |
unit |
| NO | -- |
| Similar to Vertical in principle, but intended to be simpler and better decoupled from the LMS ( |
|
vertical |
| NO | -- |
| Representation of a Unit in a Course. |
|
video |
| YES | Yes | Common | Videos. | On by default. |
videoalpha |
| YES* | -- | -- | Just an alias for the normal video tag. The backstory on this is that the VideoAlpha XBlock was created to add some new features that the VideoModule didn’t have, like HTML5 video playback. That code was eventually merged into the VideoModule, which eventually became VideoBlock. This alias was maintained so that those few courses that did use This alias costs basically nothing to maintain since the attributes were designed to be fully compatible. But there’s no good reason to ever use it on new content. |
|
videodev |
| -- | -- |
|
|
|
| YES | Yes | Advanced | Our surprisingly popular “have everyone type some words and graphically demonstrate which things came up the most often” XBlock. |
| |
wrapper |
| NO | -- |
| This is a weird subclass of VerticalBlock for layout purposes. Technically STRUCTURAL, but sort of SYSTEM in the sense that nobody should be using this in their OLX. |
|
Using only the items marked “In Unit” above, here is a candidate list (still draft) for advanced blocks to default on for instances.
Common (6) | Advanced ( 8 ) |
|---|---|
HTML / Text, LTI, Problem, Video, Open Response Assessment, Library Content | Scorm, Google Calendar, Google Drive, Poll, Randomize, Split Test, Survey, Word Cloud, |
Seeing this list makes me think we may want to consider a process through which we can update the default list of advanced blocks that we include here, since there are many more xblocks that are actively maintained and supported.
It is helpful to know the starting list for what is enabled today and we can start here, but the list of Advanced blocks can likely grow in the near future.
Archived Concept Sketches
Included below are visually originally generated for the proposal, but pushed down into this area in favor of current visuals highlighted above.