[ormsbee]

This describes the high level plan for breaking up the current course experience into components that could be reconfigured to provide more flexible learning content experiences.

[bradenmacdonald]

Great job writing this up :) 👍🏻

[ormsbee]

Maybe this should be "Item" instead, to differentiate it more from structural XBlocks, and to be more in line with QTI terminology?

[kdmccormick]

Item is a little vague, but ultimately suitable. It overlaps with the use of "item" in modulestore, but hopefully the few people who need to work within modulestore will understand the distinction.

Block is a great word for this concept, but obviously it risks confusion with XBlock. If you are considering this name, I would ask you: Is it reasonable to believe that all XBlocks eventually be proper Blocks? If the answer is "yes", then I Block could be a good choice of name, even though there will be some confusion during the migration years. If the answer is "no" (that is, if any structural/container blocks might stick around in the long-term), then I would avoid calling this concept Block, for fear that every new content core developer will need to understand that "a VerticalBlock is an XBlock but not a Block", etc.

Personally, I am still partial to Atom: it doesn't overlap with any Open edX term I can think of, and its name makes it very clear that "It is not a container for other content, and has no child elements."

[ormsbee]

Block is a great word for this concept, but obviously it risks confusion with XBlock. If you are considering this name, I would ask you: Is it reasonable to believe that all XBlocks eventually be proper Blocks? If the answer is "yes", then I Block could be a good choice of name, even though there will be some confusion during the migration years. If the answer is "no" (that is, if any structural/container blocks might stick around in the long-term), then I would avoid calling this concept Block, for fear that every new content core developer will need to understand that "a VerticalBlock is an XBlock but not a Block", etc.

Yeah, that's my concern for the long term. We're removing the notion of container XBlocks from the LMS but not from Studio. That might take a while longer.

Also, an xAPI notion of a Block is almost entirely opposite ours. 😞

One thing I realized about Atom is that if we have a project about Atomic Learning Units and adopt that language, it's going to be painful because Atoms in the data model would actually be one or two layers more granular than what we're presenting to the user.

[kdmccormick]

One thing I realized about Atom is that if we have a project about Atomic Learning Units and adopt that language, it's going to be painful because Atoms in the data model would actually be one or two layers more granular than what we're presenting to the user.

@ormsbee You're right, that'd be an unfortunate mismatch in terminology. We should call the blocks Hadrons (just kidding :).

This has me questioning the name of the project now! "Atom" comes from the Greek word "indivisible". The name "Atomic Learning Units" implies a system of pieces learning content that cannot be broken down further, but doesn't speak the intended outcome of the project (which is to have "Composable" or "Modular" learning units, right?).

[ormsbee]

Yeah, I feel like it's a really crowded namespace of terminology. I'm going to declare figuring out a better name for that project to be out of scope for this ADR PR though. 😛

[kdmccormick]

Yeah that's fair!

[kdmccormick]

Unsurprisingly, the plan here sounds great :) Just some minor comments on wording and naming.

[kdmccormick]

Item is a little vague, but ultimately suitable. It overlaps with the use of "item" in modulestore, but hopefully the few people who need to work within modulestore will understand the distinction.

Block is a great word for this concept, but obviously it risks confusion with XBlock. If you are considering this name, I would ask you: Is it reasonable to believe that all XBlocks eventually be proper Blocks? If the answer is "yes", then I Block could be a good choice of name, even though there will be some confusion during the migration years. If the answer is "no" (that is, if any structural/container blocks might stick around in the long-term), then I would avoid calling this concept Block, for fear that every new content core developer will need to understand that "a VerticalBlock is an XBlock but not a Block", etc.

Personally, I am still partial to Atom: it doesn't overlap with any Open edX term I can think of, and its name makes it very clear that "It is not a container for other content, and has no child elements."

[ormsbee]

@kdmccormick: Updated based on your feedback.

[kdmccormick]

One suggested update, but otherwise, 🚀 !