Background

When a WCH user creates an email or a webpage or a component such as a slideshow or content such as an article, the user has a conceptual concept of what is integral or 'embedded' in the email/webpage/slideshow/article, and what is shared between multiple emails/webpages/components/content.

Take a user creating an email as an example. The user would likely expect that the layout and text of an email are embedded in the email itself, whereas the images are shared. There are other aspects of the email that may be useful to share. The header and footer of the email are obvious examples, but other content such as banners or CTAs may also be usefully shared.

What does 'shared' mean here? It means that the same content or image can be used in multiple emails and across other channels. It will often also mean that updates of the content or image are reflected in all emails and other channels that use the content or image.

To provide a good user experience, the way that WCH presents the embedded and shared parts of the email should align with the user's expectations.

For example,

- When editing parts of the email that are shared, the UX should indicate that these edits may affect many places, and perhaps provide a preview of all such impacts. If the user is editing parts of the email that are embedded, the UX does not require this and should be presented in a much more straightforward manner.
- When viewing a list of content items in the hub, a user would expect to see a single content item for each of the emails, and a single content item for each of the shared content, such as the available headers and footers. They do not expect to see all the spacer/image/text etc. blocks as separate content items.

- When viewing the associations of a given image or shared header or footer, the user would expect to see the emails listed, rather than something like "Image block 3 in email X".

- When restoring a previous version of an email, the user would expect to restore the embedded parts of the email. Shared parts of the email should be treated differently - the user may expect the previous version of the email to still show the current versions of the shared content and images, or may want to also restore the shared content and images.

- The same applies when these items are created, copied, deleted, added to a project, sent for review, approved and published, and also when access control is applied to these items. In all aspects of the CMS, the user expects to view and manage the 'embedded' part of the email as a single content item and the shared parts of the email as separate items in the CMS.

The exact same UX requirements apply to webpages/components/content and all other channels.

Proposal

The proposal is to enhance WCH's support for embedding complex components into a single content item such that the part of an email/webpage/component/content that the user conceptualises as a single item is indeed a single content item in WCH.

Specifically,

- Add the ability for an embedded element in a content item to be any one of a variety of types. For example, an email can contain any number of embedded image/text/button/video/link bar/etc 'blocks'.

- Add the ability for such embedded elements to contain configuration elements. For example, the font and background color of a text block can be marked as configuration elements.
- An API whereby such complex content is simply expressed to allow for easy consumption by the customer's developers who write templates that display the content.

With these enhancements to the WCH Type and Content system, all the user's expectations as described above are met.