古腾堡发布的事后回顾,所以我们可以拥抱古腾堡的产品

已发表: 2022-03-10
快速总结 ↬尽管古腾堡目前处于有史以来最好的状态,但许多人仍然不欢迎它进入他们的项目,因为它在 WordPress 5.0 启动时遭受了令人沮丧的体验。 这是不幸的,因为作为一个产品,古腾堡是杰出的。 让我们回顾一下 Gutenberg 推出时出了什么问题,以便让我们自己接受 Gutenberg 作为产品。

在作为 WordPress 的新默认编辑器发布 10 个月后,Gutenberg 仍然被来自 Web 开发社区的相当多的人不屑一顾,他们经常引用它缺乏可访问性支持作为无视它的理由(尽管已经采取了重大的可访问性改进)地方),它有多慢(即使它现在运行得更快),以及其他一些不满。 这种对古腾堡的悲观反应在展示古腾堡能力的在线文章中最为明显,这些文章没有引起读者的积极反应,而是引起了蔑视(反映在一系列负面评论中)。

许多人似乎对“古腾堡”感到愤怒(我们稍后会看到古腾堡到底是什么),表示古腾堡不应该发生,或者至少不应该作为其默认体验集成到 WordPress 核心中,或者至少没那么快。 不同的人有不同的理由反对古腾堡,其中一些理由比其他人更具有个人意义。 例如,一些人已经看到他们的生计受到威胁,他们努力专注于某个解决方案,由于古腾堡的到来,该解决方案正处于消失的危险中(例如与这个品牌或那个品牌的页面构建者合作的任何人)。 我能真正理解为什么这些人对古腾堡感到愤怒,我很同情他们。

然而,我也相信,被古腾堡无休止地激怒并忽略它——甚至不考虑它是否值得使用——并不是一个明智的方法。 刚推出的时候,我是挺反对古腾堡的,认为它还没有准备好,这个立场持续了几个月。 然而,我最近发现自己越来越多地使用古腾堡,我什至可以声称,如今,我真的很享受它。 虽然一开始我自己也对“古腾堡”感到有点生气,但我让我的愤怒消失了,现在我实际上可以从中受益。

通过这篇文章,我将尝试改变最常描绘古腾堡的叙述方式。 我将列举过去出了什么问题,并描述古腾堡曾经是什么以及它是什么,从中我可以信心十足地以有利的眼光来介绍古腾堡。 我还将争辩说,古腾堡已经是一股积极的力量,因此,它值得再给一次机会(如果你还没有这样做的话)。

跳跃后更多! 继续往下看↓

古腾堡实际上是什么

在我看来,古腾堡没有被广泛接受的最重要原因是,当人们谈论古腾堡时,他们将其等同于不是一个而是实际上是两个实体(它们相互混淆),即:

  1. 古腾堡,发射;
  2. 古腾堡,产品。

Gutenberg 作为“产品”就是插件/功能本身。 Gutenberg 作为“发布”是涉及 Gutenberg 最初开发和发布的过程,可能从 WordPress 创始人 Matt Mullenweg 在 2017 年 6 月 WordCamp Europe 2017 期间向更广泛的受众介绍 Gutenberg 开始,到 2018 年 12 月初 WordPress 5.0 发布时结束与古腾堡合并发布。

(一旦发布结束,一个新的阶段就开始了,一直持续到今天:“Gutenberg 持续交付周期”。但是,这个阶段与“Gutenberg 发布”非常不同,因为它没有严重的问题,并且作为这样就不会对“古腾堡这个产品”产生任何误解。因此,本文没有必要谈论它。)

我们必须区分“发布”和“产品”这两个实体。 因此,从现在开始,我希望当我们提到“Gutenberg”时,它总是意味着“Gutenberg the product”,如果我们想引用“Gutenberg the launch”,那么我们必须明确命名它(可能使用它的任何变体,例如“Gutenberg 的初始开发/发布”或类似短语)。 最重要的是,我们必须避免将发布和产品混为一谈:提及任何导致 Gutenberg 令人失望的发布的因素作为不在我们的项目中使用 Gutenberg 的理由都应该被淘汰,而 Gutenberg 作为产品应该被评判只反对它自己的品质。 这对古腾堡的产品是公平的。

我相信,虽然“Gutenberg 的发布”受到了公正的批评,但针对 Gutenberg 产品的持续蔑视是不公平的(即使它是合理的),而且 Gutenberg 产品本身就是被赋予的污点声誉的受害者在令人沮丧的发布期间,将其命名为“古腾堡”。 例如,在 WordPress 插件目录中搜索“Gutenberg”时,由于决定插件排名的算法会影响插件评级,因此 Gutenberg 仅出现在第 10 位左右。 但是,如果没有将 Gutenberg 并入核心,许多 1 星评级就不会发生。 如果它最初仅作为插件发布,并等到最重要的错误和问题(例如缺乏可访问性)得到解决后再合并到核心,那么它今天的评级会更高。

如果我们能够将两个实体(发布和产品)分开并分别处理它们,那么一方面,我们可以对 Gutenberg 发布期间出现的问题进行事后分析,并将这些知识反馈到当前的持续交付中循环,这样就不会重复同样的错误(事实上,这似乎已经发生了,我将在下面描述); 另一方面,我们可以让自己欣赏古腾堡作为一种产品,将其添加到我们的堆栈中,并希望从中受益。

从我自己的角度来看,我会这样做。

古腾堡推出期间出了什么问题

一句话,领导这个过程的团队把事情搞砸了(这是礼貌的说法)。

与 Gutenberg 合并的 WordPress 5.0 于 2018 年 12 月初推出,就在 WordCamp US 之前。 当时推出它是一个错误的决定,原因很简单:古腾堡还没有准备好。 特别是可访问性情况非常糟糕,Gutenberg 通过屏幕阅读器等可访问性设备几乎毫无用处,有效地使依赖此类设备的任何人都无法使用 WordPress 编辑器。 而且由于 WordPress 社区在保护每个人(实际上是每个人)能够访问 Internet 的权利方面非常直言不讳,因此这个仓促的发布并没有受到好评。

Matt Mullenweg(负责发布过程)可能有充分的理由坚持在该日期发布,例如,从商业角度来看,这可能是有道理的。 但是,从社区的角度来看,这当然没有意义。 事实上,许多社区成员都感到被背叛了,他们抱怨说即使他们在度假,他们也必须赶紧测试客户的网站。 我们可以有把握地说,对于许多人来说,这样的过早发布被认为是一场灾难(即使软件运行正常,所以实际上没有发生 Y2K),这造成了不必要的不​​满,而这完全可以通过推迟来避免发布,或者首先将 Gutenberg 作为插件发布,以便在以后更稳定的阶段合并到核心中。

对社区造成的痛苦、沮丧和失望真的值得付出代价吗? 我相信大多数人会说不是。 我绝对认为不是。 在我看来,这种违背大多数社区成员意愿采取行动的情况今后必须避免(除非确实有充分的理由,即使不是每个人都同意;如果我不知道 Gutenber 的发射就是这种情况,因为我不知道有什么真正好的理由来证明它的合理性)。

在同一次美国 WordCamp 的演讲中,Matt Mullenweg 确实承认在推出古腾堡期间犯了错误,并且他已经吸取了教训,因此希望这些错误不会重演。 我认为我们可以接受他的道歉,并相信他的决定下次会是正确的(尽管从那时起就同样重要的话题发生了新的争吵)。 然而,损害已经造成:伤口已经打开,可能需要时间才能愈合,因此在完全恢复对 WordPress 领导层的信心之前,社区的信任度会降低。

为什么现在情况似乎好多了

好消息来了:事态似乎大多朝着积极的方向发展,下面列出的改进已经发生。

改善沟通

关于古腾堡发射的最大抱怨之一是领导层缺乏沟通。 由于没有适当的渠道来管理项目并传达其决策(至少不是以全面的方式),因此很难准确了解整体情况。 (例如,不同作者或团队的信息通过不同渠道发布,包括非官方渠道,例如个人博客。)

这种担忧得到了很大改善。 特别是,制作博客中的信息量(不同社区互动以针对不同领域做出有关 WordPress 的决定,例如核心、可访问性、设计、国际化等)以及信息更新的频率增加,每个团队都会定期举行基于 Slack 的会议(主要是每周或每两周举行一次),任何拥有 WordPress.org 用户帐户的人都可以参加。 正如一些社区成员所体验的那样,现在可以可靠地跟踪某些主题的发展,并拥有足够的信息来参与其中。

Gutenberg 推出的影响也促使 Matt Mullenweg 以两个新角色扩大 WordPress 的领导地位:执行董事,负责监督和指导所有贡献者团队的工作以构建和维护 WordPress,以及营销和传播主管,领导营销团队并监督改进 WordPress.org、相关网站及其所有网点(不幸的是,分配此角色的人不久之后就辞职了,所以必须找到其他人来接替这个职位)。

成立分诊小组以解决未解决的问题

在 Gutenberg 的初始开发阶段,有几个人抱怨说,在冒险为 WordPress 添加新功能之前,应该修复已经累积到数千个的现有错误。

今年 3 月,成立了一个分类小组来清理 WordPress Trac 错误跟踪器中的未解决问题。 这是多年来一直需要的艰苦工作。 如果完成,WordPress 将有机会从 Trac 切换到更现代的错误跟踪器,例如 GitHub。

可访问性正逐渐成为一个非问题

每个新的 Gutenberg 版本都在解决可访问性问题,6.3 版提供了最大的改进。 按照目前的改进速度,最突出的可访问性问题(如古腾堡可访问性审计中所报告的)应该很快就会成为过去的一部分。

根据自己的优点判断古腾堡

现在我们已经将 Gutenberg 与 Gutenberg 产品的发布分开了,我们可以继续将 Gutenberg 作为产品进行分析,并仅根据其自身的优点和缺点来决定是否值得将其添加到我们的应用程序堆栈中。 许多人确实正确地指出古腾堡的问题是不信任它的原因(而不是专注于失败的发布)。 然而,古腾堡一直在突飞猛进,许多被诟病的问题可能已经解决,也可能处于解决的边缘。 因此,负面评估应该有一个到期日期并重新评估。 如果我们可以给古腾堡一个新的尝试,看看它现在的位置,我们可能会明白,毕竟它还不错。 在我看来,古腾堡应该得到比现在更热烈的欢迎。

我很惊讶 Gutenberg 仍然与以前在 WordPress 中编辑内容的方式(主要是通过 tinymce,还有短代码、小部件等)进行比较,认为通过 Gutenberg 进行编码更加困难。 这可能是真的,但它也忽略了一点:古腾堡不是为了提供一种新的方式来编写我们的应用程序,产生与过去相同的功能; 相反,它可以极大地增强可以做的事情,为我们的应用程序添加过去只能梦想的功能。 此外,古腾堡不是另一个页面构建器。 事实上,将 Gutenberg 与 Divi 或 Beaver Builder 进行比较同样没有抓住重点,因为这就像将 Victorinox 与普通刀进行比较:是的,您可以使用 Gutenberg 进行站点/页面构建(实际上还没有,但它已经在进步),但这只是它的众多用途之一; 还有一些其他用途最初是隐藏的,但是一旦您将它们从隔间中取出并了解它们的工作原理,就会发现一个充满可能性的新世界。 下面,我将描述古腾堡带来的一些新可能性。

首先,让我们讨论一下古腾堡的不足之处。 我认为 Gutenberg 真正被认为有害的一件事是 React 的陡峭学习曲线(这是 Gutenberg 编码的 JavaScript 库)。 WordPress 一直非常具有包容性,使来自任何背景的人(不仅是程序员,还包括博主、营销人员、销售人员等非技术人员)都可以创建主题或插件或启动网站。 毫无疑问,现在已经不是这样了,期望每个人都必须学习 React 来创建 Gutenberg 块是不公平的(不一定是这样,因为我们也可以使用其他 JavaScript 库创建块,甚至不使用 JavaScript ,例如通过 ACF 块,但是使用 React 是最合乎逻辑的选择,如果只是因为 Gutenberg 是用它编码的)。 唯一可以证明这种劣势的论据是它是否能让用户的体验更好。 让我们看看是否可以考虑这种情况。

正如我在之前的一篇文章中所说,Gutenberg 的基于块的架构从根本上改变了构建应用程序的方式:我们现在可以将组件视为构建网站的单元,而不是考虑 HTML 代码。 这种架构更具可维护性和弹性,因为每个组件(或块)都可以独立开发和测试,并且由于它易于重用,因此可以降低开发多个应用程序的成本。 事实上,Vue 和 React 等 JavaScript 库最近的流行很大程度上归功于它们对组件的支持。 这是开发人员喜欢的一个很棒的功能,我相信,一旦你开始编码,就没有回头路了。

在同一篇文章中,我还描述了 Gutenberg 如何支持“一次创建,随处发布”策略(也称为“COPE”),从而能够生成单一的真实内容来源,以提供给我们所有的应用程序,无论哪种方式他们运行的媒介或平台:网络、电子邮件/时事通讯、iOS/Android 应用程序、VR/AR、家庭助理(如亚马逊 Alexa)等。 因为它使整体内容管理更加简单,所以 COPE 还能够降低为不同平台制作内容的成本。 当我第一次写我的文章时,我认为这是可以做到的。 然而,我最近为 WordPress 实现了 COPE,它就像一个魅力! (请继续关注另一篇文章,我将在其中详细解释它的工作原理。)

COPE 和 WordPress API(WP REST API、WPGraphQL 和我自己的 PoP API)的结合将为通过 WordPress 管理我们所有应用程序的所有内容提供一个令人信服的理由。 另一个令人信服的原因是 Gutenberg 的易用性(它还没有完全实现,但按照目前的发展速度,迟早会到来),使最终用户能够以非常简单的方式创建复杂的内容。

我们已经可以使用很棒的新功能,例如内容外观的实时预览、从 Google Docs 以完美格式复制/粘贴、创建内部嵌套元素的复杂网格层等等。 我们还可以期待新的区块能够提供我们从未想象过的完全出乎意料的功能。 我敢打赌,通过古腾堡,WordPress 有望成为网络的数字资产管理器。 (我已经写了一篇文章,很快将在 Smashing Magazine 上发表关于这个主题的文章以及我对这个大胆声明的理由。)

此外,Gutenberg 允许将代码与其他 CMS 或框架(例如 Drupal 和 Laravel)重用,因此 WordPress 的编码不再需要仅限于 WordPress,再次允许我们降低开发库的成本需要在尽可能多的系统中运行(例如,为许多不同平台和语言(例如 Stripe)提供其 API 集成的公司可以从中受益)。 目前,似乎只有客户端代码(JavaScript 和 CSS)可以重用,但是服务器端 PHP 代码也可以重用。 (我将再次发表一篇关于 Smashing 的文章,解释如何做到这一点。)

这些功能已经成为现实,我们可以期待 Gutenberg 在未来几年为其存在提供更多令人信服的理由(根据 Matt Mullenweg 的说法,Gutenberg 目前仅实现了其潜力的 10% 左右)。

我们终于可以尝试对 Gutenberg 产品做出判断:我的立场是,它为 WordPress 设置了更高的进入门槛,这令人遗憾,然而,它也是一款设计精美的软件,它赋予了 WordPress 真正的新功能,并且,由于 WordPress 的突出地位,在整个 Web 开发世界中。 在成本和收益之间的这种权衡之间,我相信将古腾堡作为 WordPress 的一部分是值得的。 我希望你能同意我的意见,或者如果不同意,至少反对它的理由可以完全基于古腾堡作为产品的特性。

结论

古腾堡目前处于最佳状态——已经开始提供以前 WordPress 无法提供的令人愉悦的用户体验。 然而,并不是每个人都知道这个事实,因为不是每个人都能接受古腾堡。 这是一个不幸的情况,因为古腾堡(作为产品)不应该因为古腾堡推出期间发生的错误而受到指责。 如果我们能够将这两个实体分开并独立对待每个实体,那么我们就可以令人信服地要求人们再给古腾堡一次机会,这表明古腾堡作为一个产品是值得拥有的,即使古腾堡的发布是一个失败的过程。

在本文中,我根据自己对事件的理解,对失败的古腾堡发射进行了事后分析。 进行这样的事后分析可以帮助社区和领导确保那些不幸的错误不再发生。 事后分析后,我根据自己的优点对 Gutenberg 进行了评估,并表明了我的立场:我相信 Gutenberg 是一个很棒的工具,WordPress 社区当然可以从中受益。 而且因为它只会越来越好,古腾堡甚至可以为 WordPress 开启一个新的黄金时代。