在 Baklib Experience 中实现混合 CMS 架构

“还记得 CMS 主要用于在网页上布局内容吗？当时，这满足了网站管理需求。然而，行业正在发生变化，数字体验平台 Baklib Digital Content Experience 正在引领潮流。继续阅读以了解如何以及详细了解可用于确保全渠道成功的两个原则。”

Baklib

如上图所示，混合 CMS 的典型特点就是同样的内容，可以多渠道，多样式对外输出。保证内容一致性的情况下，实现了体验的个性化。本文将探讨 Baklib 是如何实现混合 CMS 内容站点设计的。

客户不再通过出色的网站找到公司。他们通过出色的内容发现公司、产品和服务。

人们是通过点击搜索结果中的链接并参与我们的网站找到这些内容的吗？不。他们通过百度搜索、微信公众号、 Google 搜索、信息面板、语音搜索和社交媒体中的内容找到这些内容。问问自己，您上次全神贯注于一篇您不想要的文章是什么时候？是在 LinkedIn 上吗？您上次需要查找某些内容是什么时候？您是否在片段或信息面板中找到了所需内容？毫无疑问，内容为王，有远见的组织必须管理人们参与的众多内容渠道的内容。

竞争性组织正在拥抱全渠道营销，并确保搜索机器人能够理解他们的内容，以支持AIGC、AI Chat、知识面板、摘要和语音用户界面。为实现这一目标，组织正在转向无头 CMS 解决方案或混合 CMS（如 Baklib 数字内容体验），它们同时支持无头 CMS 和传统 CMS 架构。但是，采用支持丰富结构化内容类型并提供强大 API 的 CMS（如 Baklib 数字内容体验）是不够的。

我从惨痛的经历中吸取了教训，那就是用我熟悉的设计系统方法来处理 CMS 解决方案可能会毁掉内容策略。我意识到，内容模型不能用来适应设计系统，而必须通过语义和连通性来满足内容策略的需求。在这里，我想举一个例子来说明如何在 Baklib 数字内容体验中实现内容模型时应用这两个原则，但首先，如果您没有阅读这篇文章，这里是这两个原则的总结：

内容模型必须定义语义而不是布局。语义内容模型使用的名称反映了内容的含义，而不是内容的显示方式。例如，非语义模型可能有诸如预告片、媒体块和卡片之类的类型，但语义内容模型将具有允许每个交付渠道理解内容的类型，例如产品、事件和推荐。
内容模型应该保留内容上下文，而不是为了适应设计系统而进行分割。良好的内容模型会将原本属于同一部分的内容连接起来，这样渠道在交付内容之前就不必知道如何将各个部分重新拼接起来。

一些明显的语义示例，例如事件、新闻稿和问题，如何创建提供每个内容项所需的所有字段的类型，从而使内容更易于管理和传递到各种内容渠道。例如，将填充事件所需的所有字段放在一个页面类型中，将使事件内容保持连通性、易于创作，并且易于任何平台使用。

Baklib通过 KB 知识库 + CMS 站点结合的形式，实现了内容与展示分离的混合 CMS 系统，更好的解决了知识、体验、语义的问题。

文章和常见问题解答项需要连接起来，作为独立的内容片段，这一点显而易见，但网站上还有许多其他内容片段，只有作为一个连接的整体，它们才能保留其全部价值。当这些内容被分解成亚原子片段时，它们的大部分可用性就会降低。无论内容项是小还是大，内容模型都应该连接属于一起的内容。在 Baklib Digital Content Experience 中，这通常意味着创建具有管理和交付可重复使用内容所需的所有字段的类型。关键是，如果内容属于一起，那么从内容创建到每个交付渠道，它们都应该保持在一起。

一个常见的例子

为了使语义和连接类型的概念更清晰，让我们研究一下如何将这些原则应用于 Baklib 数字内容体验中一个不太明显的例子。想象一下，一个网站需要提供下面卡片布局中显示的特色内容列表，并且必须在多个交付渠道（例如多个页面和电子邮件）中重复使用相同的内容，使用无头、以 API 为中心的模型。

如果您像我一样，习惯于思考设计原则，并会自然地将所见内容划分为设计组件，例如部分标题、号召性用语卡片和号召性用语按钮。这正是我们实现设计组件高效重用的方式。但是，这种设计系统思维可能会导致按设计边界划分内容，使内容更难管理和重用。如果试图使所有内容都可重用，则可能导致将内容划分为三种页面类型：部分标题、号召性用语卡片和简单号召性用语。作者可能需要在树中填充多个内容项，然后在三个单独的小部件中选择内容：部分标题、卡片布局和号召性用语按钮。您能想象这对内容作者来说有多么繁琐吗？在电子邮件中重复使用相同的内容会有多困难呢？

从设计系统的角度来看，这可能完全合理，但它存在几个问题：

如果您想在其他渠道（例如电子邮件）中重复使用此内容，您将很难获得所有内容。请注意，在上述解决方案中，内容仅在 Baklib 数字内容体验页面构建器中相关联。检索标题、描述、功能项和按钮内容需要从页面构建器的存储中提取所有这些信息。内容将很难重复使用。
即使可以提取所有内容组件，交付渠道也很难理解内容是什么。它们是新闻稿、视频、活动、文章还是手册？系统无法分辨，并且很难提供适当的用户体验或嵌入适当的 Schema.org 结构化数据。
创作体验非常繁琐。作者需要在内容树中创建八个不同的项目，然后添加和配置三个不同的小部件来显示它。在 CTA 卡中，作者可能会重新输入系统中已存在的内容的标题和描述。

应用原则

那么，如果我们应用这两个原则来确保内容具有语义性和关联性，会发生什么情况呢？我们可能会深入研究内容要求，发现 CTA 卡指向各种类型的内容，新闻稿、视频、活动和文章。更好的是，这些内容项目已经在系统中，因此，如果我们确保每个项目都提供标题、缩略图和简短描述，作者就不必在单独的 CTA 卡中重新输入相同的内容。目标项目可以提供自己的摘要内容。

当我们考虑连接内容时——即将原本属于同一部分的内容连接在一起——我们会意识到这个列表的标题和描述属于列表。它们是列表的标题和摘要，单独来看毫无意义。此外，底部的 CTA 按钮属于列表。它是获取更多资源（例如上方资源）的链接。

综合起来，我们意识到我们只需要一种页面类型，即具有以下字段的资源集合。