Model omnichannel content
The journey into Omnichannel Content (OCC) starts with content type. Designing content types is similar to designing models for database object-relational mappings (ORMs) or View models in the context of model-view-controller (MVC).
Model content from domain space
When you design models for ORM, you must understand the problem's data requirements before designing the content types. Little consideration is given to how the data is rendered, decoupling it from its presentation. This approach is most common and effective when the problem space is well-explored and has a data schema that is largely agreed upon, such as a schema for ecommerce products, a schema for a blog, a schema for a podcast, and so on.
Model content from design
You can derive a content model from the design of how a component is rendered or presented. You may take this approach in the following ways:
- Existing situations – You may work with content tied to an existing website or application. In this case, designs are available first, and you must build backward.
- Iterative feedback loops – Designs and content models often iteratively influence each other. Starting with an existing design can act as a launching point or inspiration for model development
- Visual-heavy content – In fields such as marketing or UI-centric products, the appearance may take precedence, requiring you to create models that can support design needs.
Existing design considerations
Consider the following approaches for existing designs.
- Deconstruct designs
- Break it down – Analyze each design element. Is it text, image, video, or a user input field? Treat these as potential building blocks.
- Identify variations – Look for distinct patterns in how content is laid out or typeset. These may map to content model variations.
- Note implicit data – Does the design hint at attributes not explicitly visible? For example, an event listing implies location and date data.
- Map content properties
- Match elements to fields – Assign appropriate field types to the elements you identified, such as text areas, image fields, dropdowns, and so on.
- Do not force the fit – For complex design components, create custom content types and their sub-fields rather than trying to cram everything into predefined options.
- Mind your metadata – Consider fields needed for publication management (author, date), internal organization (tags, categories), and search optimization (SEO-specific fields).
- Consider relationships
- How do parts relate? – Analyze how designs link or potentially should link together. Do recipes link to ingredients? Do categories group products?
- Hierarchical or linked? – Design organization gives clues about the relationships you need to create in your model.
- Future-proof for flexibility
- Beyond the immediate design – Anticipate how your content could be repurposed. Add fields or optional components to enable future use cases.
- Modularity – If a layout has a repeating pattern, make that a reusable content component instead of hard-coding it into a single content type.
New design considerations
When integrating content models with new designs, organizations typically choose a design system or component library. These resources ensure consistency, enhance efficiency through reusability, and enable faster and more dynamic design evolution by centralizing the changes.
Consider the following approaches for new designs.
- Analyze your design system
- Component inventory – List your available design components (atoms, molecules, organisms). Note their variations and possible states (active, disabled, and so on).
- Map data inputs – For each component, identify what content is required (headline, image, call to action text, and so on).
- Identify relationships – Explore any implied relationships between components within the design system, such as items belonging to a carousel.
- Connect components to content types
- Granularity – Assess if design components map directly to individual content types or become fields within larger content types.
- Simple components, simple fields – Basic text blocks likely become standard text fields.
- Nesting levels – Complex components or layouts may warrant a hierarchy of custom content types to mirror their composition.
- Refine models with system context
- Component variations – Ensure your model can handle variants defined in the design system (button types, image aspect ratios, and so on).
- System constraints – Respect restrictions in the design system and translate them to content validations, such as an allowed number of items in a carousel.
- Expand beyond the visual
- Metadata – Add administrative and SEO metadata fields necessary for content governance.
- System properties – Check for existing metadata elements in your design system. Map those to your model; for example, UI-specific tags to control component variations.
- Anticipate reuse and flexibility
- Cross-component potential – Spot where you can use the same content element in different system parts. Design once, reuse many times.
- Growth potential – Do not strictly lock yourself into the current design system. Make the model adaptable to future additions.
Model content with a hybrid approach
When designing a content model, you may be in situations where you cannot decouple pure content from the rendered version of that content. So, in such situations, take a hybrid approach. Consider the following:
- Try to decouple content from design.
- If you incorporate design elements, try to keep them channel-agnostic.
- Instead of combining channel and content information in the same content type, have Pure Content as an independent content type and create a channel-specific content type that has a composition with the Pure Content.
Leverage source and source metadata
Additional metadata fields are available when you create a content type with the API:
- Content type level
- Source – A name from which system this content type is derived.
- Source ID – ID of the content type at its source.
- Source Metadata – Additional metadata to store that is only readable by API consumers does not have to be understandable to CMP.
- Field level
- Source ID – the ID of the field in the source system.
- Source Metadata – Additional metadata to store that is only readable by API consumers does not have to be understandable to CMP.
For example, if you want to import a content type from some other headless CMS:
- Content type level
- Source – Name of the external system.
- Source ID – ID of the content type on that system.
- Source Metadata – likely nothing.
- Field level
- Source ID – Key of the field in the downstream system.
- Source Metadata – Metadata around what field this was created from; for example, the field type in the downstream system it was created from to use when doing a reverse conversion.