无头CM的问题
#javascript #网络开发人员 #cms #headless

内容管理系统(CMS)长期存在,以使组织中的每个团队能够协作创建和修改数字内容。虽然在纸面上听起来很棒,但开发人员和业务团队都有营销,内容,商品,数字产品以及更多的工作,以在网站和应用程序中创建和更新内容,但实际上,大多数无头CMS都随附一个很大的缺陷:您仍然必须知道如何编码以使最基本的更新甚至最基本。这意味着业务团队必须不断依靠开发人员,而开发人员想要负责的最后一件事是内容更新。
An image showing the pros and cons of a headless CMS. Cons: tiny changes require tickets/code/deploy, limited data structure, unintuitive editor experience, components (with wrong execution). Pros: headless API-driven and performant, plugins and extensions, roles and permissions, components (with right execution).

一个简单的解决方案:无头CMS

Side by side image. On the left side, code example that mimics a component built with data from a CMS. on the right side, an example of form fields from a CMS.

在这里,CMS提供商具有一个UI,允许内容创建者以表单填充字段(图像,标题,字幕,文本)。开发人员负责将这些字段刻板编码为应用程序。

此解决方案有两件事:

  1. 这很简单。开发人员立即了解其工作原理。
  2. 这是普遍的。因为它基于API和简单的数据结合,它可以与任何技术堆栈和渲染技术一起使用,并且本质上应该是表现

但是,无头CMS方法并非没有缺点。由于模式实施和管理,其中最大的归结为组成,有两个原因:

  1. 恒定压力和对开发人员的依赖。无头CMS具有字段模式。开发人员需要在网站代码库中实现这些字段。没有开发人员的工作,一个新领域将无助。这给开发人员构成了不断的压力,要求实施新领域和新模式。

  2. 不直觉的内容编辑体验。无头CM不知道内容是如何渲染的。它只是将内容视为内容编辑器需要在基于表单的UI中填充和更新的字段的数据。

虽然无头CMS可以表现出色和定制以满足大多数需求,但它们给开发人员带来了沉重的负担,并且不使业务团队能够快速启动新的广告系列,这主要是因为它只是在数据库上的薄层。

田野的悖论

没有足够的字段»»

该解决方案的主要问题是,无论您拥有多少个模式和领域,业务团队仍然需要更多的方法来完成工作;也就是说,发展业务。团队需要迭代多个CTA,旋转木马,多列布局,粗体单词,不同字体/颜色,多个图像等功能。这种方法是一场永无止境的鼠标竞赛,可以添加更多的模式和字段,并将所有内容都用于网站或应用程序中。是的,这是对没有CMS或单片的改进,但对于现代技术堆栈或大型数字业务而言,它不是一个完整的解决方案。

a video of scrolling through various CMS fields.

太多字段

添加到系统中的每个新模式和字段都会创建需要编码,记录,解释,训练和测试的复杂性。

对于大型项目,这是一项非平凡的工作。复杂的模式通常会导致内容编辑器必须填写的这些嵌套,复杂的形式。处理模式并不是非发育者自然而然的事情,因此他们需要接受培训才能以这种方式思考和工作。这就是为什么一些无头CMS吹嘘他们的视觉编辑器,它提供了最小的内容更改的实时预览 - 他们知道这比纯粹处理基于表单的UIS(尽管许多无头CMS都可以甚至提供此功能)。

除了无头CM中需要发生的事情之外,内容模型的任何更新都要求开发人员对其代码进行更改,以接收和解释结构化数据,以将其渲染为“标记为内容”。这导致开发人员的积压溢出的内容票证必须等待开发释放周期发货。

领域的悖论是,新的字段和模式提供了无限的灵活性,但是灵活性给开发人员带来了更大的压力,更难使用,并且减慢了内容开发过程。对开发人员的严重依赖不仅使整个组织都退缩了,而且还影响了仅限于结构化数据和僵化模板的业务关键团队的创造力。

我们需要的是一个易于使用但灵活的系统。

更好的解决方案:组件

存在无头CMS以支持任何技术堆栈上的内容。这就是为什么所有内容都默认为数据的原因。这是最低的公共分母,但是用于管理内容的错误抽象层。

组件是设计应用程序时开发人员的首选解决方案,那么为什么不创建内容呢?它们完全封装,可扩展,可重复使用并具有行为。

内容管理的关键创新不仅仅是提供平坦的字段列表,例如在数据库或电子表格中,您可以将物品分解为组件 - 例如英雄横幅,产品旋转木马或注册表格 - 这可以用简单的输入和输出封装数据(例如,电子商务后端),由业务团队在层次和直觉上组成。对于开发人员来说,这是一个自然的工作流程,以利用现代的前端框架,因为他们已经在构建和维护设计系统和组件库。这使业务用户不仅可以更改字段的输入(即数据),还可以完全控制页面结构,布局等。

an illustration of dragging a react component that is built from registered Builder components.

那么,为什么所有无头CMS都不适用于组件而不是纯粹的数据?简短的答案:很难。

基于组件的无头CMS不足

为每个框架构建和维护不同的框架SDK,乍一看似乎并不可持续。为了解决这个问题,支持基于组件的方法的无头CMS在其实施中具有规定性,要求开发人员修改和操纵其组件以符合CMS。这打破了基于组件的方法的主要好处之一:平稳的开发人员体验。这些CMS要求开发人员符合外部系统,而不是能够符合开发人员自己的系统。这是一个严重的局限性,但仍然对“简单”但复杂的领域和图架的世界有所改善。

单独的组件还不够

虽然组件比数据更有效,更有效地解决了内容管理,但它们本质上具有类似的缺陷:它们完全取决于开发人员。领域和图架必须由开发人员编码和管理,组件也必须如此。当您没有所需的字段时,开发人员就在挂钩上。当您没有所需的组件时,开发人员就在挂钩上。

组件比纯数据是开发过程中更自然的部分,但是它们仍然由开发人员完全撰写和管理。当业务团队试图通过新的内容和经验推动增长时,他们需要新的组件,这取决于开发积压。这导致开发人员不受工作的不知所措,他们不喜欢推动像素,这会减慢公司的构建,测试和迭代的能力。

理想的解决方案:视觉CMS

最终,管理内容和构建数字体验并不是一定程度的。您的CMS需要更灵活,适用于不同类型的内容和组织中的所有团队。它不应该是或。

Graphic with two ways of working with the title, "It shouldn't be either-or".

当管理需要刚性的内容时,尤其是在大量卷中,例如产品信息,食谱成分以及标头,页脚和导航链接时,结构化数据很有意义。对于站点或应用程序中的构建页面,组件应为基础;起点。开发人员可以通过为CMS内的设计系统和组件库作为基础构建块提供访问权限,从而增强业务团队的能力。但是,开发人员不应该希望所有事物都有一个组成部分,也不应涉及一切。

视觉CMS不仅通过结构化数据和组件提供内容管理,而且还通过启用了可组合的视觉开发。那些具有适当权限的用户(例如,设计师)可以通过拖动和删除原始元素(例如文本,图像,视频,旋转木马,手风琴,按钮等)来创建定制体验 - 在视觉编辑器中有效定制组件。画布。这类似于流行的Wysiwyg网站建设者,例如WebFlow,Wix和Squarespace,但不限于一个平台,前端框架或后端服务。它是真正的组合,而且是技术堆栈不可知论。

开发人员可以继续投资于强大的设计系统和组件库,并将其作为内容构建块提供给业务团队。业务团队可以利用这些团队,但不受他们的限制。他们还可以迅速拖放并在视觉上建立数字体验而不经常依靠开发人员,并专注于推动企业的增长,同时大大释放开发积压,使开发人员能够解决更多的高影响力项目。

每个团队都可以完全控制内容开发过程,以更快地构建和更快地推动增长。这就是真正提供整个组织易用性和灵活性的平衡。这是一个视觉CMS。