グーテンベルクの死後の打ち上げ、それで私たちはグーテンベルクの製品を受け入れることができます
公開: 2022-03-10WordPressの新しいデフォルトエディターとしてリリースされてから10か月後、Gutenbergは、アクセシビリティサポートの欠如を無視する理由として頻繁に引用するWeb開発コミュニティのかなりの数の人々に肩をすくめられています（大幅なアクセシビリティの改善が行われていますが）場所）、それがどれほど遅いか（現在ははるかに速く実行されていますが）、および他のいくつかの不満。 グーテンベルクに対するこの悲観的な反応は、読者から肯定的な反応を引き出す代わりに、（否定的なコメントの流れに反映されているように）ほとんど軽蔑を引き付けるグーテンベルクの能力を示すオンライン記事で最も明白です。
多くの人が「グーテンベルクで」怒っているようで（グーテンベルクが実際に何であるかはしばらくするとわかります）、グーテンベルクは決して起こらなかったか、少なくともデフォルトのエクスペリエンスとしてWordPressコアに統合されたことはない、または少なくともそれほど早くはありません。 グーテンベルクに反対する理由は人によって異なり、その理由のいくつかは他の人よりも個人的に重要です。 たとえば、グーテンベルクの到着により消滅の危機に瀕している特定の解決策に特化するために一生懸命働いて、生計が危険にさらされているのを見た人もいます（このブランドまたはそのブランドのページビルダーで作業している人など）。 なぜこれらの人々がグーテンベルクに腹を立てているのか、私は本当に理解でき、彼らに同情します。
しかし、グーテンベルクに際限なく怒り、その全体を却下することは、結局のところ使用する価値があるかどうかさえ考慮せずに、賢明なアプローチではないと私は信じています。 それが最初に発売されたとき、私はそれが準備ができていないと思ってグーテンベルクにかなり反対しました、そしてこのスタンスは数ヶ月続きました。 しかし、最近グーテンベルクを使うようになり、今では実際に楽しんでいると言っても過言ではありません。 当初、私も「グーテンベルクで」少し怒りましたが、怒りをなくし、今では実際にその恩恵を受けることができます。
この記事を通して、私はグーテンベルクが最も一般的に描かれている物語を変えようと試みます。 過去に何が悪かったのかを列挙し、グーテンベルクが何であったか、そしてそれが何であるかを説明します。そこから、グーテンベルクを好意的に提示するための信頼を飛躍させることができます。 また、グーテンベルクはすでに前向きな力であり、そのため、もう一度チャンスを与える価値があると主張します（まだそうしていない場合）。
グーテンベルクが実際に何であるか
私の見解では、グーテンベルクが広く受け入れられていない最も重要な理由は、人々がグーテンベルクについて話すとき、それを1つではなく実際には2つのエンティティ（互いに混同されている）に等しいということです。
- グーテンベルク、打ち上げ。
- グーテンベルク、製品。
「製品」としてのグーテンベルクは、プラグイン/機能そのものです。 「ローンチ」としてのグーテンベルクは、グーテンベルクの初期開発とリリースを伴うプロセスでした。おそらく、WordPressの創設者であるマットマレンウェッグが2017年6月のWordCamp Europe 2017でグーテンベルクをより多くの人々に紹介し、2018年12月初旬にWordPress5.0がグーテンベルクと一緒にリリースされ、それにマージされました。
（打ち上げが終わると、今日まで続く新しいステージ「グーテンベルク継続的デリバリーサイクル」が始まりました。しかし、このステージは、深刻な問題がなかったため、「グーテンベルク打ち上げ」とは大きく異なります。そのため、「グーテンベルクの製品」に対する誤解は生じません。このため、この記事でそれについて話す必要はありません。）
「発売」と「製品」の2つのエンティティを区別する必要があります。 そのため、今後、「グーテンベルク」を指す場合は必ず「製品のグーテンベルク」を意味し、「グーテンベルクの発売」を指す場合は、明示的に名前を付ける必要があります（おそらくそのバリエーションのいずれかを使用して） 、「グーテンベルクの初期開発/リリース」または同様のフレーズなど）。 最も重要なことは、打ち上げと製品を同じバッグに混ぜることを控える必要があります。プロジェクトでグーテンベルクを使用しない理由として、グーテンベルクの期待外れの打ち上げに貢献した要因について言及することは段階的に廃止し、製品としてのグーテンベルクを判断する必要があります。それ自身の資質に対してのみ。 これは、製品のグーテンベルクにとって公平です。
「グーテンベルクの発売」は正当に批判されていますが、グーテンベルク製品を狙った絶え間ない軽蔑は（正当化されたとしても）不公平であり、グーテンベルク製品自体は、汚された評判の犠牲者であると私は信じていますその苛立たしい打ち上げの間に「グーテンベルク」という名前に。 たとえば、WordPressプラグインディレクトリで「Gutenberg」を検索する場合、プラグインのランク付けを決定するアルゴリズムがプラグインの評価に影響するため、Gutenbergは10位付近にしか表示されません。 ただし、グーテンベルクがコアに統合されていなかった場合、1つ星の評価の多くは行われなかったでしょう。 最初はプラグインとしてのみリリースされ、最も重要なバグや問題（アクセシビリティの欠如など）が解決されるまで待ってからコアにマージした場合、その評価は今日より高くなります。
2つのエンティティ（ローンチと製品）を分割して別々に処理できる場合は、一方の側で、グーテンベルクのローンチ中に問題が発生したことを事後分析し、この知識を現在の継続的デリバリーに提供できます。同じ間違いが繰り返されないように、サイクルします（実際、これは、以下で説明するように、すでに起こっているようです）。 反対に、グーテンベルクを製品として評価し、スタックに追加して、うまくいけばその恩恵を受けることができます。
私自身の観点から、これを正確に行います。
グーテンベルクの打ち上げ中に何が悪かったのか
一文で、プロセスをリードするチームはそれを台無しにしました（それはそれを言う丁寧な方法です）。
グーテンベルクが統合されたWordPress5.0は、WordCampUSの直前の2018年12月初旬に発売されました。 非常に単純な理由で、それを起動することは間違った決定でした：グーテンベルクはまだ準備ができていませんでした。 特に、アクセシビリティの状況は非常に悲惨で、グーテンベルクはスクリーンリーダーなどのアクセシビリティデバイスではほとんど役に立たず、そのようなデバイスに依存している人はWordPressエディターを使用できなくなりました。 また、WordPressコミュニティは、インターネットにアクセスできるすべての人（文字通りすべての人）の権利を保護することに非常に積極的であるため、この急いでの立ち上げはあまり受け入れられませんでした。
リリースプロセスを主導していたMattMullenwegは、その日にリリースすることに固執する正当な理由があった可能性があります。これは、たとえば、ビジネスの観点からは理にかなっている可能性があります。 しかし、それは確かにコミュニティの観点からは意味がありませんでした。 実際、多くのコミュニティメンバーは、休暇中であってもクライアントのサイトをテストするために急いでいる必要があると不満を漏らし、裏切られたと感じました。 多くの人にとって、このような時期尚早な起動は（ソフトウェアが正常に動作していても、Y2Kは実際には発生しなかったとしても）大破として認識され、不必要な不満を生み出し、どちらかを延期することで完全に回避できたと言っても過言ではありません。ローンチ、または後のより安定した段階でコアにマージされるプラグインとして最初にグーテンベルクをリリースすることによって。
コミュニティに与えられた痛み、欲求不満、失望は本当にコストに見合うものでしたか？ ほとんどの人はそうではなかったと言うでしょう。 絶対にそうではなかったと思います。 私の意見では、コミュニティメンバーの大多数の意志に反して行動がとられるこのような状況は、将来的に回避する必要があります（すべての人が同意しなくても、本当に正当な理由がない限り、そうであれば私はそれを正当化する本当に正当な理由を知らないので、私は知らないグーテンバーの打ち上げに関するケースでした）。
同じWordCampUSでのプレゼンテーションで、マット・マレンウェッグは、グーテンベルクの立ち上げ中に間違いがあったこと、そしてこれらの間違いが繰り返されないようにレッスンを学んだことを認めました。 私たちは彼の謝罪を受け入れ、彼の決定が次回正しいものになると信じることができると思います（それ以来、同様に重要なトピックに関する新しい争いが起こっていますが）。 ただし、被害はすでに発生しています。傷が開いて治癒に時間がかかる可能性があるため、WordPressのリーダーシップへの信頼が完全に回復するまで、コミュニティの信頼は低下します。
物事が今はるかに良くなっているように見える理由
さて、良いニュースがあります。状況はほとんど前向きな方向に進んでいるようで、以下にリストされている改善がすでに行われています。
コミュニケーションの改善
グーテンベルクの打ち上げに関する最も大きな不満の1つは、指導者によるコミュニケーションの欠如でした。 プロジェクトを管理し、その決定を伝達するための適切なチャネルが（少なくとも包括的にではなく）実施されていなかったため、全体的な状況を正確に把握することは困難でした。 （たとえば、さまざまな作成者またはチームによる情報は、個人のブログなどの非公式な方法を含め、さまざまな方法で公開されました。）
この懸念は大幅に改善されました。 特に、makeブログ（コア、アクセシビリティ、デザイン、国際化など、さまざまな分野でWordPressに関する決定を行うためにさまざまなコミュニティが相互作用する）の情報量と、情報が更新される頻度は増加し、すべてのチームが定期的なSlackベースの会議（主に毎週または隔週で開催）を開催し、WordPress.orgユーザーアカウントを持っている人なら誰でも参加できます。 一部のコミュニティメンバーが経験したように、現在、特定のトピックの進展を確実に追跡し、関与するのに十分な情報を得ることが可能です。
Gutenbergの立ち上げからのフォールアウトにより、Matt Mullenwegは、WordPressの構築と保守を行うすべての貢献者チームを監督および指示するエグゼクティブディレクターと、マーケティングチームを率いるマーケティング＆コミュニケーションリードという、2つの新しい役割でWordPressのリーダーシップを拡大するようになりました。 WordPress.org、関連するWebサイト、およびそのすべてのアウトレットの改善を監督します（残念ながら、この役割に割り当てられた人はすぐに辞めたので、他の誰かがこの位置を引き継ぐために見つけられる必要があります）。
未解決の問題に取り組むために結成されたトリアージチーム
グーテンベルクの初期開発段階で、WordPressに新しい機能を追加する前に、数千に蓄積された既存のバグを修正する必要があると不満を言う人が何人かいました。
今年の3月、WordPressTracバグトラッカーの未解決の問題をクリーンアップするためにトリアージチームが結成されました。 これは長年必要とされてきた大変な作業です。 終了した場合、WordPressはTracからGitHubなどのより最新のバグトラッカーに切り替える機会があります。
アクセシビリティは着実に問題になりつつあります
アクセシビリティの問題は、すべての新しいグーテンベルクのリリースで取り組まれており、バージョン6.3は改善の大部分を提供しています。 現在の改善のペースでは、（グーテンベルクアクセシビリティ監査で報告されているように）最も顕著なアクセシビリティの問題はすぐに過去の一部になるはずです。
グーテンベルク自身のメリットを判断する
Gutenbergを製品としてGutenbergから分割したので、Gutenbergを製品として分析し、それ自体の長所と短所のみに基づいて、アプリケーションスタックに追加する価値があるかどうかを判断できます。 多くの人々は、グーテンベルクの問題を（失敗した打ち上げに焦点を合わせるのではなく）それを信頼しない理由として正しく指摘しています。 しかし、グーテンベルクは飛躍的に進歩しており、批判された問題の多くは解決されたか、解決の危機に瀕している可能性があります。 そのため、否定的な評価には有効期限があり、再評価する必要があります。 グーテンベルクに新しい試みをして、それが今日どこにあるかを見ることができれば、結局のところ、それはそれほど悪くないことを理解するかもしれません。 私の意見では、グーテンベルクは現在よりも温かい歓迎を受けるに値します。
グーテンベルクがWordPressでコンテンツを編集する以前の方法（主にtinymceだけでなく、ショートコード、ウィジェットなど）と比較されていることに驚いています。グーテンベルクを使用してコーディングするのは、より難しいと主張しています。 これは真実かもしれませんが、要点も欠けています。グーテンベルクは、アプリケーションをコーディングするための新しい方法を提供するためにここにいるわけではなく、過去と同じ機能を生成します。 代わりに、これまで夢にしか見られなかった機能をアプリケーションに追加することで、実行できることを大幅に強化するためにここにあります。 また、グーテンベルクは別のページビルダーではありません。 確かに、グーテンベルクをディヴィやビーバービルダーと比較することは、ビクトリノックスを通常のナイフと比較するようなものであるため、同様にポイントを失っています：はい、グーテンベルクでサイト/ページの構築を行うことができます（実際にはまだですが、すでに作業中です進歩）、しかしそれはその多くの用途の1つにすぎません。 最初は隠されている他のいくつかの用途がありますが、それらをコンパートメントから引き上げて、それらがどのように機能するかを理解すると、可能性の新しい世界が明らかになります。 以下では、グーテンベルクがテーブルにもたらすこれらの新しい可能性のいくつかについて説明します。
まず、グーテンベルクのあまり良くないことについて話し合いましょう。 グーテンベルクが本当に有害であると私が信じていることの1つは、React（グーテンベルクがコード化されているJavaScriptライブラリ）の学習の急カーブにあります。 WordPressは常に非常に包括的であり、あらゆるバックグラウンドの人々（コーダーだけでなく、ブロガー、マーケティング担当者、セールスマンなどの非技術者）がテーマやプラグインを作成したり、サイトを立ち上げたりできるようにしています。 これはもはや事実ではないことは間違いありません。Gutenbergブロックを作成するためにReactを学ぶ必要があると期待するのは不公平です（他のJavaScriptライブラリを使用して、JavaScriptを使用しなくてもブロックを作成できるため、必ずしもそうとは限りません。 、ACFブロックなどを使用しますが、GutenbergがReactでコーディングされているという理由だけで、Reactを使用するのが最も論理的なオプションです）。 この不利な点を正当化できる唯一の議論は、それがユーザーのエクスペリエンスを改善するかどうかです。 これが事実であると考えられるかどうか見てみましょう。
以前の記事で論じたように、グーテンベルクのブロックベースのアーキテクチャは、アプリケーションの構築方法を根本的に変えます。HTMLコードで考える代わりに、コンポーネントの観点からWebサイトを構築するための単位として考えることができるようになりました。 このアーキテクチャは、各コンポーネント（またはブロック）を個別に開発およびテストでき、再利用が容易なため、複数のアプリケーションの開発コストを削減できるため、保守性と復元力が向上します。 実際、VueやReactなどのJavaScriptライブラリの最近の人気は、コンポーネントのサポートに大きく起因している可能性があります。 これは開発者が愛する素晴らしい機能であり、コーディングを開始すると後戻りすることはないと私は信じています。
この同じ記事では、Gutenbergが「CreateOnce、Publish Everywhere」戦略（「COPE」とも呼ばれる）をサポートし、コンテンツの信頼できる唯一の情報源を作成して、すべてのアプリケーションにフィードできるようにする方法についても説明します。それらが実行されるメディアまたはプラットフォーム：Web、電子メール/ニュースレター、iOS / Androidアプリ、VR / AR、ホームアシスタント（Amazon Alexaなど）など。 COPEを使用すると、コンテンツ管理全体がはるかに簡単になるため、さまざまなプラットフォーム向けのコンテンツを作成するコストを削減することもできます。 私が最初に自分の記事を書いたとき、私はそれができると理論づけていました。 しかし、私は最近WordPress用のCOPEを実装しました、そしてそれは魅力のように機能します！ （それがどのように機能するかを詳細に説明している別の記事をお楽しみに。）
COPEとWordPressAPI（WP REST API、WPGraphQL、および私自身のPoP API）の組み合わせは、WordPressを介してすべてのアプリケーションのすべてのコンテンツを管理するための1つの説得力のある理由を提供します。 もう1つの説得力のある理由は、グーテンベルクの使いやすさ（まだ完全にはここにありませんが、現在の開発ペースでは、遅かれ早かれ到着します）であり、エンドユーザーが非常に簡単な方法で精巧なコンテンツを作成できるようになります。
コンテンツがどのように見えるかのリアルタイムプレビュー、完璧なフォーマットでのGoogleドキュメントからのコピー/貼り付け、内部にネストされた要素を含む複雑なグリッドレイヤーの作成など、優れた新機能にすでにアクセスできます。 また、新しいブロックが、私たちが想像もしなかったまったく予期しない機能を提供することも期待できます。 私の賭けは、グーテンベルクを通じて、WordPressがウェブのデジタル資産マネージャーになる準備ができているということです。 （私はすでに、このトピックとこの大胆な発言の正当性に関して、Smashing Magazineにまもなく公開される記事を書いています。）
さらに、Gutenbergでは他のCMSまたはフレームワーク（DrupalやLaravelなど）でコードを再利用できるため、WordPressのコーディングをWordPressに制限する必要がなくなり、ライブラリの開発コストを削減できます。できるだけ多くのシステムで実行する必要があります（たとえば、Stripeなどの多くの異なるプラットフォームや言語にAPIの統合を提供している会社は、その恩恵を受ける可能性があります）。 現在、クライアント側のコード（JavaScriptとCSS）のみが再利用されているようですが、サーバー側のPHPコードも再利用できます。 （もう一度、これを行う方法を説明するSmashingに関する記事をすぐに公開します。）
これらの機能はすでに現実のものであり、グーテンベルクが今後数年間でその存在についてさらに多くの説得力のある理由を提供することを期待できます（マット・マレンウェッグによれば、グーテンベルクは現在、その可能性の約10％しか実装していません）。
私たちはついにグーテンベルク製品の評決に到達することを試みることができます：私のスタンスは、WordPressへの参入障壁を高くすることですが、それは残念ですが、WordPressに真の新しい力を与える美しく設計されたソフトウェアでもあります、WordPressの卓越性により、一般的にWeb開発の世界に。 そして、コストと利益の間のこのトレードオフの間で、WordPressの一部としてグーテンベルクを持つことはそうでないよりも価値があると私は信じています。 私の意見に同意していただければ幸いです。そうでない場合でも、少なくともそれに対する理由は、製品としてのグーテンベルクの特性のみに基づいている可能性があります。
結論
グーテンベルクは現在最高の状態にあります—以前はWordPressでは不可能だった楽しいユーザーエクスペリエンスを提供し始めました。 しかし、誰もがグーテンベルクを受け入れることができるわけではないので、誰もがこの事実を知っているわけではありません。 これは不幸な状況です。なぜなら、グーテンベルク（製品として）は、グーテンベルクの発売中に起こった間違いについて過ちを犯してはならないからです。 これら2つのエンティティを分割してそれぞれを独立して扱うことができれば、グーテンベルクにもう一度チャンスを与えるよう説得力を持って求めることができます。これは、グーテンベルクの立ち上げが失敗したプロセスであったとしても、製品としてのグーテンベルクは持つ価値があることを示唆しています。
この記事では、私自身の出来事の理解に基づいて、失敗したグーテンベルクの打ち上げの事後分析を行いました。 そのような事後分析を実行することは、コミュニティとリーダーシップがそれらの不幸な間違いが二度と起こらないことを確実にするのを助けることができます。 事後分析の後、私はグーテンベルクを独自のメリットに基づいて評価し、自分のスタンスを宣言しました。グーテンベルクは優れたツールであり、WordPressコミュニティは確かにそれから恩恵を受けることができると信じています。 そして、それはますます良くなるだけなので、グーテンベルクはワードプレスの新しい黄金時代を開始することさえできます。