There are use cases captured on T278311 that should be captured here as well.

In T338015#9054836, @RHo wrote:

There are use cases captured on T278311 that should be captured here as well.

@RHo added those and other use cases in this task's inventory.

during one of the past abstract/codex fortnightly we chatted about the possibility of me taking over this task as a codex external contributor. following @bmartinezcalvo suggestion, i'm sharing that i could work on this during the course of Q3 FY23-24. based on wikifunctions needs and priorities we might opt for a different component in the course of the next quarter.

Does this actually need to be a component? What if we provided guidelines or documented this as a pattern instead? I'm not sure what value creating a dedicated component for this brings that can't be done through a combination of existing tokens and components.

In T338015#9548726, @CCiufo-WMF wrote:

Does this actually need to be a component? What if we provided guidelines or documented this as a pattern instead? I'm not sure what value creating a dedicated component for this brings that can't be done through a combination of existing tokens and components.

I lean towards creating it as a Codex component. A Module or Content Box is a versatile container for different types of content. You can find some examples in this Figma inventory. I also explored how to handle all these use cases with a single Module component in this exploration where you can check how we could cover many the different use cases with one single component.

There are many benefits to building it as a component But in case we don't want to create it as a component for now, we can start by providing design guidelines. Later on, we can turn those guidelines into a component if we find more situations where it's useful.

Either way, we will need to define and document the following:

• What type of content can be included within a Module
• The paddings in the Module, according to the size of the Module (paddings will vary on small and large modules).
• Color and style
• How the Module's head will look like and what type of content will have (title, action?)
• Where to place any buttons or actions

In T338015#9556044, @bmartinezcalvo wrote:

In T338015#9548726, @CCiufo-WMF wrote:

Does this actually need to be a component? What if we provided guidelines or documented this as a pattern instead? I'm not sure what value creating a dedicated component for this brings that can't be done through a combination of existing tokens and components.

I lean towards creating it as a Codex component. A Module or Content Box is a versatile container for different types of content. You can find some examples in this Figma inventory. I also explored how to handle all these use cases with a single Module component in this exploration where you can check how we could cover many the different use cases with one single component.

There are many benefits to building it as a component But in case we don't want to create it as a component for now, we can start by providing design guidelines. Later on, we can turn those guidelines into a component if we find more situations where it's useful.

Either way, we will need to define and document the following:

• What type of content can be included within a Module
• The paddings in the Module, according to the size of the Module (paddings will vary on small and large modules).
• Color and style
• How the Module's head will look like and what type of content will have (title, action?)
• Where to place any buttons or actions

To help determine if this is a Pattern/Complex Component/Component or something else, I think we first need to complete the outstanding item to define what a Pattern is for Codex. There is an action that @mwilliams has taken over from me to run a follow-up to the offsite patterns sessions with designers and DST to resolve this.
Separately, it would make sense to work on higher prio planned components first.