构建成功 CMS 的 4 个技巧

图片来源：

Opensource.com

在日常生活中，我是一名 Web 开发人员。或者，更准确地说，我经营一家为各种客户开发网站的企业，从小型企业到大型组织。这些网站都带有一些 CMS。我们使用哪个 CMS 来开发网站取决于许多因素，包括客户的需求、网站的规模和所需的功能。在本文中，我将介绍我们在开发开源 Bolt 内容管理系统时吸取的教训。

以客户为中心

通常在处理较大的站点时，您会与一个由不同职位描述和技能组合的小组一起工作。不同专业领域人员之间的这种重叠可能会在利益冲突时导致一些问题

编辑不想了解数据库结构。他们不在乎某些东西是 XML、JSON 还是 Mediumtext。
后端开发人员不应关心网站上使用的确切标记。<b> 或 <strong>，几乎是一样的，对吧？
前端开发人员不需要了解安排新文章或主编是否批准更改旧文章。

我坚信没有一个 CMS 适合运行所有网站，而且我总是惊讶于有很多 Web 开发机构对他们做的每个项目都使用相同的 CMS。如果我是一家这样机构的客户，我会怀疑我得到的 CMS 是否真的最适合我的网站，或者它只是恰好是他们为所有客户使用的 CMS。

因为这不是我们希望的工作方式，所以我们一直在寻找适合我们工作流程并同时互补的 CMS。这样我们就有了一些选择，可以更好地帮助我们的客户，而不会每次都退回到同一个系统。对于我们开发的大多数大型项目，我们使用 Drupal。这是一个功能强大的系统。正因如此，它也是一个相当复杂的系统（特别是对于最终必须每天在系统工作的编辑而言）。我们进行了大量研究，以找到一个可以补充它的系统：一个更简单、更轻量级的系统，适用于不需要 Drupal 提供的广泛功能的站点。

我们在寻找这个系统时评估的每个系统都存在一个或多个主要缺点。似乎每个 CMS 都是由某种人为某种人编写的。因为我们找不到真正满足我们自己和客户需求的系统，所以我们决定开发自己的系统。在这样做的过程中，我们学到了很多关于一个好的 CMS 应该做什么、不应该做什么，以及如何区分这两种选择。这促使我们开发了名为 Bolt 的 CMS，我邀请您查看一下。它非常棒，对我们来说，它肯定满足了我们日常工作中的需求。但这并不是本文的重点。

在开发我们的 CMS 时，我们发现 CMS 通常有三个主要的“受众”。广义上讲

开发人员： 这些是后端开发人员。安装 CMS、配置它并构建任何自定义功能的人员。
实施人员： 这些是“前端开发人员”。构建内容结构、设置内容类型并在 CMS 提供的模板语言中以 HTML/CSS 实施网站主题的人员。
编辑： 这些是每天在 CMS 中工作的人员。他们撰写新内容、编辑现有页面等。

还有一小群人稍微超出这个群体，即决策者。决定哪个 CMS 将用于项目，然后将其交给开发人员来实现的人员。这些人——虽然在过程中很重要——但实际上并不是站点或 CMS 的受众。

事实证明，大多数 CMS 都非常关注这些受众之一，从而在一定程度上忽略了其他受众。多年来，这一直困扰着我——大多数知名的 CMS 在这些领域之一表现出色，但从未在所有三个领域都表现出色。

经常处理内容的人通常是擅长文字的人——写作是他们的强项。通常，当 CMS 尽可能不干扰他们时，他们工作得最好、效率最高。他们需要采取的每个操作、需要单击的每个额外按钮以及需要做出的每个选择都可能会打断他们的工作流程。

与此同时，后端开发人员通常在技术上非常精通。这些人知道数据库的工作原理，并且对服务器上发生的事情有很好的理解。因此，这个群体对 CMS 底层发生的事情有很好的理解，他们更喜欢配置而不是约定。

进行实施的前端开发人员通常精通于构建优秀网站的要素——结构、导航、可用性——但他们通常也具备以适当的 HTML 和 CSS 实施设计的能力。

这些具有不同技能组合的人员需要协同工作，以构建一个连贯、稳固、美观、运行良好且易于导航的网站。将自己放在别人的角度思考通常非常困难，因此这需要纪律才能良好地工作。

根据定义，创建 CMS 的人员属于后端开发人员类别。事实证明，很多 CMS 显然是由程序员为程序员开发的。虽然这使得快速启动和运行站点变得容易，但可能会遭到编辑和前端开发人员的抵制。

同样，如果选择使用某个以最终用户为中心的界面而闻名的 CMS，则后端开发人员很可能会反抗，因为他们预测未来更新、可扩展性和自定义模块的开发会出现问题。

不要误会我的意思，这里没有人应该受到责备。只是我们不能期望每个用户都以相同的标准来评判一个系统。在一个人的系统判断中至关重要的东西，在另一个人看来可能完全无关紧要。

这就是构建 CMS 困难的原因：作为开发人员，您可能能够构建最安全、最可靠和代码最优雅的 CMS，但如果编辑不理解它的工作原理，它就不会被认为是成功的。

另一方面，如果您交付了有史以来最草率的代码，但它为编辑提供了他们真正需要的东西，他们会喜欢它。与此同时，您会觉得自己交付了一个糟糕的工作。诀窍在于在这些事情上找到一个好的平衡点，这引出了下一个重要的教训。

避免复杂性

我之前提到过：很多 CMS 都过于复杂。这个问题的根源在于，构建易于使用的东西真的非常非常困难。这听起来可能理所当然，但防止某事物变得过于复杂的最佳方法是刻意选择保持简单，并确保它保持这种状态。

当 CMS 发展时，它通常会带来更多的选项和更多的功能，这自然会导致用户必须做出更多选择并采取更多步骤来执行基本操作。

当您开发 CMS（或 CMS 的模块）时，您通常必须做出选择，如何为用户提供特定的功能。您可能会想说“让我们将其设为最终用户的选项”，但这会迫使用户做出选择。如上所述：每次您向用户呈现一个选择时，他们都必须停止他们正在做的事情一小段时间才能做出决定。他们有可能失去注意力，并且可能需要一小段时间才能重新进入状态。这是一个很好的例子，说明了作为开发人员，您认为您正在通过为用户提供选项来为他们提供服务。在很多情况下，最好自己选择更好的选项，以保持用户的工作流程更加直接。有关此的更多信息，您应该阅读你的应用让我变胖。

保持一致性

一致性在产品开发中非常重要。产品的一致性决定了它是感觉像一个精致、全面的体验，还是感觉像一个随时可能崩溃的东西。

这不是容易衡量或量化的东西，但您的用户会注意到它。

当您想保持产品一致性时，有三个重要的方面需要牢记

敢于说不。不要仅仅因为你_可以_就去做事情。对于每个新功能，您都应该问问自己，人们是否真的需要它，以及它是否不会为其他用户增加更多复杂性。
不要对用户想要或需要什么做出假设。如果他们想要什么，他们绝对会告诉您。交付一个让人们想要更多的产品，要比拥有永远不会使用的功能好得多。
拥有“明智的默认值”。这当然是一个非常模糊的概念，但总的来说：如果以某种方式做事是显而易见的，那就这样做。不要为某些晦涩难懂的东西添加选项，或者仅仅是为了古怪或与众不同。

准备好说“不”

简单来说：说不很重要。如果您说的不够“不”，您的产品将失去其焦点和它提供的功能的一致性。

在实践中，这种情况经常发生。不仅在 CMS 中，而且在软件开发的所有领域。例如，Spotify 曾经是一个非常好的音乐播放器，但多年来，引入了各种社交功能和其他愚蠢的东西。我不认识任何喜欢当前版本的 Spotify 而不喜欢旧版本的人。

为什么这种情况如此频繁地发生？CMS 开发人员经常忽略他们的目标受众之一。这可能是因为他们缺乏将自己放在其他群体的位置思考的能力，或者因为客户缺乏技术专业知识并要求错误的功能。或者也许市场营销部门的人员有非常令人信服的理由来包含一些愚蠢的功能。无论原因如何，您都应该始终尝试牢记大局：添加某个功能是否会使 CMS 作为一个整体更令人愉快且易于使用？如果答案是否定的，您应该重新考虑添加该功能。

与此同时，您应该始终尝试牢记那些不受特定功能或更改影响的人。如果您构建了一个新功能，该功能对团队的某个成员有利，但它以某种方式妨碍了不需要该功能的其他人，那就不好了。

说“不”通常非常困难。特别是如果您喜欢请求某些功能的人，或者仅仅因为您喜欢构建新东西胜过维护旧代码。所有软件开发人员都知道这种感觉。以下文章有很多好的论点，可以让您更容易地说“不”，而不会听起来像是一个固执的地下室居民：产品策略意味着说不