Gutenberg: wp-adminのウィジェットブロック画面

現在のウィジェットビューは間違いなくサイドバーを念頭に置いて設計されていますが、ウィジェット領域（現在はブロック領域）もフッターやヘッダーなどである可能性があります。これは、このページを更新するときに考慮すべきことの1つだと思います。

すべてのウィジェット/ブロック領域を1つのページで編集できるようにすると、奇妙に感じます。 この画面は、カスタマイザーのウィジェットエリアエディターのように機能するはずだと思います。 特に、現在のwp-adminウィジェットページの利点の1つは、ウィジェットをあるウィジェット領域から別のウィジェット領域にドラッグアンドドロップできることです。 ウィジェット画面がカスタマイザーのようになった場合、この機能をどのように複製するかはわかりません。 おそらく、ウィジェット領域はトップバーまたはサイドバーにタブとして表示され、これらのタブ上でブロックをドラッグすると、ビューがそのブロック領域に切り替わります...テキスト/画像をあるタブから別のタブにドラッグする方法のようなものですほとんどのOSでは、Webブラウザーで、または1つのアプリから別のアプリに。

そして、非アクティブなウィジェット領域を忘れないでください...それはこれらすべてにどのように適合しますか？ 私はその目的を理解していますが、グーテンベルク化されたウィジェット画面のコンテキストで持つのは奇妙なことのように感じます。

さらに、左側のブロック選択は少し奇妙に思えます。 ポストエディターのブロックインサーターとカスタマイザーウィジェットインサーターを組み合わせたものに変更する必要があると思います。 そういえば、これはブロックインサーターにドラッグアンドドロップ挿入を追加する良い機会のようです。 wp-adminとカスタマイザーの両方の現在のウィジェットエリアエディターにはドラッグアンドドロップ挿入がありますが、ポストエディターのブロックインサーターには現在ありません。 ＃1511を参照してください。

また、このモックアップはブロックインスペクターを考慮していないようです。 おそらく、投稿エディタのように画面の右側に表示されるはずです。

一般的に、 wp-adminのウィジェットページは奇妙に感じられ、現在のモックアップではさらに奇妙に感じられます。

ウィジェットとブロックを混在させるのでしょうか、それとも本質的にウィジェットを非推奨にするのでしょうか？

彼らはウィジェットを「ウィジェットブロック」（ブロックとウィジェットの間の何か）に置き換えたいと思っていると思います。
そして、おそらくテーマはグーテンベルクのページビルダーツールに置き換えられるでしょう、時間がわかります...

@nicholasio現在の計画では、ウィジェット領域がブロック領域になり、古いウィジェットをブロック領域に埋め込むことができる「レガシーウィジェット」ブロックがあると思います。 （おそらく、「レガシーウィジェット」ブロックはどこでも使用できます。つまり、投稿やページでウィジェットを実際に使用できます...以前は不可能でした。）すべてではないにしても、ほとんどのコアWordPressウィジェットは非推奨になり、次のように置き換えられます。同等の新しいブロック。

したがって、基本的にウィジェットは非推奨になっていますが、ブロックと一緒に使用することはできます。

現在のウィジェットビューは間違いなくサイドバーを念頭に置いて設計されていますが、ウィジェット領域（現在はブロック領域）はフッター、ヘッダーなどにすることもできます。

それらの「エリア」がページ自体にどのように表示されるかを探ることができるでしょうか。 すなわち。 サイドバー領域の場合は現在と同じように表示されますが、フッターまたはヘッダーの場合は、ヘッダー/フッターがある場所に表示されます。 そのため、ページ自体の大まかなレイアウトになります。 何かをモックアップします。

さらに、左側のブロック選択は少し奇妙に思えます。

アコーディオンとして、これはおそらく崩壊し、それほど圧倒されることはないでしょう。

また、このモックアップはブロックインスペクターを考慮していないようです。 おそらく、投稿エディタのように画面の右側に表示されるはずです。

私はあなたがここにいると思います。 より多くの会話を進めるために、いくつかのモックアップを作成します。

さらに、左側のブロック選択は少し奇妙に思えます。

アコーディオンとして、これはおそらく崩壊し、それほど圧倒されることはないでしょう。

気になるのは、投稿エディタのインサーターのようには見えないことです。 インサーターをウィジェットページでは常に表示されるサイドバーであるのに、投稿エディターではポップアップにする必要があるのはなぜですか？ 一方、おそらく投稿エディタはウィジェットライブラリのサイドバーのような側にドッキング可能である必要がありますか？ いずれにせよ、ブロックインサーターがさまざまなコンテキストでどのように表示されるかと一貫性を保つ必要があると思います。

ウィジェット/ブロックライブラリのデザインは、ポストエディターのインサータースタイルと比較して、モバイルではうまく機能しないことに注意することも重要です。 おそらく、ドッキングされたサイドバーインサーターは、モバイルではポップアップインサーターに変わるはずですか？

私はいくつかのプロトタイピングにFigmaを使おうとしました。 これが私がまとめたコンセプトです。 「ウィジェットエリア」を積み重ねるのではなく、コンテキストで表示できる別の方法があるかどうかを確認したかったのです。 これにより、wp-adminの/widgets.phpが置き換えられます。

プロトタイプ

https://www.figma.com/proto/O6SyONtxLjcUxsHq59EfStPs/integration-widgets?node-id=0%3A1&scaling=min-zoom

ビデオ

考え？

@mapkそのモックアップが実際にどのように実装されるかはわかりません。 ウィジェット領域は、ページテンプレートに応じて異なる場所に表示される可能性があり、もちろん、一部のウィジェット領域は特定のページテンプレートにのみ表示されます。 一度に1つのページテンプレートのレイアウトのみを表示しようとしている場合を除いて、すべてのウィジェット領域を意味のある方法で1つの画面に収めようとすると、実装が困難になります（それらを切り替える機能を使用）。

ウィジェット画面の「ライブプレビューで管理」ボタンのアドバイスに耳を傾ける方が生産的だと思われます。 このリンクは、ライブプレビュー付きのカスタマイザーバージョンを優先して管理画面を廃止する最初のステップでした。 ウィジェットの管理画面は、ウィジェット領域が実際に機能する方法とは根本的に切り離されています。画面のさまざまな部分に、場合によってはサイトのさまざまな部分にさまざまな領域が表示されます。

ユーザーが理解できるように、この画面にフロントエンドのページ構造を明確に反映することは非常に困難です。 カスタマイザーでこのエクスペリエンスへのコンテキストアプローチを試すことで、この基本的な問題を解決するための多くの機会が提供されます。 すでにコアにある表示可能な編集ショートカットから始めて、改良されたウィジェットは、（カスタマイズプレビューの）フロントエンドで直接編集することも、特定の画面の表示に直接関連するオーバーレイで編集することもできます。 カスタマイズプレビュー内でサイトのさまざまな部分に移動する機能により、この画面では対処できない問題が解決されます。

この提案を放棄し、＃13205を支持してこの問題を閉じることをお勧めします。

意味のある方法ですべてのウィジェット領域を単一の画面に収めようとすると、実装が困難になります

同意しました。 私にとって、プロトタイプはそれをもっと蒸留する方法だったと思います。

ウィジェットの管理画面は、ウィジェット領域が実際に機能する方法とは根本的に切り離されています

これは真実であり、上記の調査の理由です。 全くもって同じ意見です！

この提案を放棄し、＃13205を支持してこの問題を閉じることをお勧めします。

この画面はフェーズ2のフォーカスエリアなので、そうなるとは思いません。 それを「ブロック」に切り替えることの背後にある目的は、ユーザーがすべてがブロックになるというパラダイムシフトを理解できるようにすることだと思います。

この画面は将来的に非推奨になりますが、特にサイトの多くがグーテンベルクに構築されているため、私たち全員をそこに集めるために必要な「ベビーステップ」です。 おそらく最良のことは、既存のレイアウトを維持することですが、アコーディオンコンテンツ領域内のすべてのブロックの使用を許可するだけですか？ これにより、最初の投稿のモックアップにいくつかの調整を提案するだけで、この特定の部分に対するリソースと投資を最小限に抑えることができます。 また、カスタマイザーにすばやく移動できるようになります。

この提案を放棄し、＃13205を支持してこの問題を閉じることをお勧めします。

メニュー画面についても同じ考慮事項があります。https： //github.com/WordPress/gutenberg/issues/13206#issuecomment-455452477を参照して

また、ウィジェット画面には代替の「アクセシビリティモード」があることを皆さんに思い出させたいと思います（右上のリンクをクリックするだけです）。 新しい管理画面が最初からアクセシビリティを念頭に置いて構築されている場合は、アクセシビリティモードを削除することに完全に賛成です。 つまり、最初に、派手なことはせず、できるだけシンプルにしてください。

_視覚的なモックアップの前に_アクセシビリティへの取り組みを開始する良い方法は、最初に情報アーキテクチャを設計することです。 この画面は、主要なセクションとタスクを識別し、論理的に関連するコントロールをグループ化し、コンテンツを線形化された方法でナビゲートするときに認識される情報が意味をなすようにするために、情報を見出しで整理する必要がある空白のドキュメントと考えてください。

Re：左側のブロック選択：

アコーディオンとして、これはおそらく崩壊し、それほど圧倒されることはないでしょう。

左側のセクション全体が本当に必要ですか？ メニュー画面の＃13206で提案されたデザインとの一貫性が重要だと思う傾向があります。 何かが足りないかもしれませんが、インサーター付きのウィジェット領域だけがあると、ユーザーインターフェイスが大幅に簡素化されます。 また、左右のセクション間のドラッグアンドドロップを取り除くことができ、アクセシビリティの向上につながります。

そうは言っても、私の理解では、すべてのコアウィジェットはブロックになります。 ただし、プラグインやテーマによって追加されたカスタムウィジェットはどうなりますか？ それらのすべてがブロックにすぐに更新されるわけではありません。 メタボックスの場合のように、いくつかの下位互換性メカニズムが必要ですか？ / Cc @youknowriad

そうは言っても、私の理解では、すべてのコアウィジェットはブロックになります。 ただし、プラグインやテーマによって追加されたカスタムウィジェットはどうなりますか？

アイデアは、任意のウィジェットの編集とプレビューをレンダリングできるクラシックなウィジェットブロックを構築することです（今のように） https://github.com/WordPress/gutenberg/issues/4770

また、左右のセクション間のドラッグアンドドロップを取り除くことができ、アクセシビリティの向上につながります。

技術的に言えば、現在のようにドラッグアンドドロップをサポートしない方が簡単/迅速です。複数のエディターを対象とする単一のインサーターを使用することはできません。

アイデアは、任意のウィジェットの編集とプレビューをレンダリングできるクラシックなウィジェットブロックを構築することです（今のように）＃4770

+100
これはまさに私たちにも必要なものです。 すでにこれを念頭に置いていただきありがとうございます！

サイトのさまざまな部分でウィジェットをさまざまに表示する方法を試すこともどうですか？ https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2/#comment-35058でいくつかの検索のユースケースについて言及しました

この投稿では、ユーザーが表示しているページの種類（ホームページ、単一ページ、単一投稿）に応じてレイアウトが異なるいくつかの使用例も示しています。 アーカイブページや404などもすべて重要なケースだと思います。

すべてのウィジェット/ブロック領域を1つのページで編集できるようにすると、奇妙に感じます。

これは、カスタマイザーに対する最大の利点の1つです。 すべてのエリアに割り当てられているすべてのウィジェットを一度に表示できます。 私にとって、カスタマイザーは非常に制限があります。

現在のwp-adminウィジェットページの利点の1つは、ウィジェットをあるウィジェット領域から別のウィジェット領域にドラッグアンドドロップできることです。

この能力を失いたくない！ 私はそれをよく使います、そして私が書いたテーマはこれをすることの容易さに基づいています。 これには、非アクティブなウィジェットが含まれます。 アコーディオンを使用したり、一部のウィジェット領域を非表示にしたりすると、カスタマイザーのように調整可能性が制限されます。

そして、非アクティブなウィジェット領域を忘れないでください

これを捨てないでください。 プログラムで発生する可能性のあるテーマの切り替えにとって重要です。 ただし、別のテーマを使用したときに入力された可能性のある情報を取得できるようにするためにも重要です。 非アクティブなウィジェットにアクセスできないことは、ウィジェットにカスタマイザーを使用する際の最大の問題です。

ウィジェットをブロックに変更する必要があるのはなぜですか？ それらはすでに一種のブロックではなく、新しいブロックはちょうど今それらに追いついていますか？ すでに定着しているAPIを取り除くのはなぜですか？ ウィジェット領域とコンテンツがすでにあるのに、なぜ「コンテンツ領域」の定義に切り替えるのですか？ 新しい子供が既存の子供に簡単にフィットできるのに、なぜ「新しい子供」のためにすべてをやり直すのですか？

ウィジェットをブロックに変更する必要があるのはなぜですか？ それらはすでに一種のブロックではなく、新しいブロックはちょうど今それらに追いついていますか？

あなたは正しいです、@ joyously。 ウィジェットはすでに一種のブロックのようなものです。 ただし、特にグーテンベルクでは、ページのどこにも簡単に追加することはできません。 それらをブロックに変換すると、これが解決されます。 ウィジェット-ブロックは他のブロックと同等に扱われるようになり、グーテンベルク内のどこにでも追加できます。 wp-adminのウィジェット画面は、これを反映し、誰もがブロックのパラダイムを理解できるように変更されています。

これがこの画面のプロトタイプです。 フィードバックをお寄せください。

1. シフトを伝えるのに役立つように、単語を「ウィジェット」から「ウィジェットブロック」に変更します。
2. 現在のウィジェット画面の機能を保持します。
3. 吹き飛ばされたパネルでグーテンベルクブロックインサーターを使用します。 明らかな変更であり、グーテンベルクのブロック挿入器を模倣するために、この白を維持しました。
4. ウィジェットブロック領域は通常どおり表示されますが、グーテンベルクエディターと同様に_blocks_を反映します。 実際、彼らはミニグーテンベルクのようなものです。 😉
5. 私はこれらからインスペクター（グーテンベルクサイドバー）を見逃しています。 ウィジェット画面にグーテンベルクがブロック（ツールバー、インサーター、インスペクター）と対話するために行うすべてのものが含まれる場合、これはおそらくこれをすべて可能にするより大きなグーテンベルク画面になります。

プロトタイプ：

https://wp.invisionapp.com/share/VYQ6PWPWTH3

プロトタイプのビデオ：

アクセシビリティ

これらの考えのa11yレビューをお願いします。 グーテンベルクのブロックインサーターはa11yのニーズを満たしていますか？ もしそうなら、このプロトタイプはa11yに関して機能しますか？ ユーザーは、ウィジェット領域から直接ブロックを挿入できるようになりました。これは新しいものです。

ウィジェットブロックとブロックを混在させるのはなぜですか？
それらは分離されるべきだと思います...

段落や見出しのように-ウィジェットではありません-ブロック...
代わりに、これらすべてのブロックを内部に含むテキストエディターまたはグーテンベルクエディターウィジェットブロックを作成しないのはなぜですか...？

ウィジェットブロックとブロックを混在させるのはなぜですか？

それはここで素晴らしいことです！ より多くのWordPressがGutenbergインターフェース内で編集可能になると、好きな場所にブロックを追加できるようになります。 これに移行するために、「widget-blocks」という表現を使用しています。 最終的には、「ウィジェット」という用語はまったく使用されなくなり、すべてがブロックになります。 それはまだ方法です。

しかし、おそらくこのように表現すると、さらに混乱が生じる可能性がありますか？

代わりに、これらすべてのブロックを内部に含むテキストエディターまたはグーテンベルクエディターウィジェットブロックを作成しないのはなぜですか...？

フォローするかどうかはわかりませんが、開発中のクラシックウィジェットブロック（＃4770）があり、ブロックのように機能しますが（Gutenbergインターフェイス内のどこにでも追加できます）、まだブロックに変換されていないウィジェットが含まれています。

あなたのモックアップのコンテキストは何ですか？ （プレビューがないため、管理ページと見なします。）現在、管理ページでは、構成を必要としないウィジェットをフロントエンドですぐに表示できます。 それはあなたのモックアップで何が起こっているのですか？ そうでない場合、[保存]ボタンはどこにありますか？ 現在、ウィジェットごとに[保存]ボタンがあります。

非アクティブなウィジェットはどこにありますか？ ウィジェットをある領域から別の領域に移動できますか？

ウィジェットに定義できる説明はどこにありますか？

左側の列でブロックをクリックすると、ブロックが最初のウィジェット領域に移動するのはなぜですか？ 2つのウィジェット領域が開いていますが、どこに行くのかをどのように判断しますか？ +はGBブロック専用ですか？ それとも、左側にあるすべてのもののためですか？

[保存]ボタンはどこにありますか？ 現在、ウィジェットごとに[保存]ボタンがあります。

これは、グーテンベルクと同様に自動保存されます。 ウィジェットには保存ボタンがあることに気付きましたが、これらはもはやウィジェットではなく、ブロックであり、現在のグーテンベルクのブロックと同じように機能することを覚えておいてください。

非アクティブなウィジェットはどこにありますか？ ウィジェットをある領域から別の領域に移動できますか？

良いキャッチ。 非アクティブなウィジェットは、まだ考える必要があるものです。 これらのウィジェット、およびブロックに変換されていない他のウィジェットをどのように表示しますか？ 多分これを含むセクションがありますか？

ウィジェットに定義できる説明はどこにありますか？

これらはウィジェットではなくブロックですが、現在グーテンベルクにあるため、説明はおそらくインスペクターで定義されます。 ここで＃5で検査官について言及し

左側の列でブロックをクリックすると、ブロックが最初のウィジェット領域に移動するのはなぜですか？ 2つのウィジェット領域が開いていますが、どこに行くのかをどのように判断しますか？

プロトタイプソフトウェア内にドラッグアンドドロップインターフェイスを作成する方法がわかりませんでした。 そのため、「クリック」参照を使用して、アクションを伝えようとしました。 完璧ではありませんが、 「現在のウィジェット画面の機能を維持する」と言ったとき、みんなが途中で会えることを本当に望ん

+はGBブロックのみですか？ それとも、左側にあるすべてのもののためですか？

左側のすべてがブロックです。 前述のように、フェーズ2の焦点の1つは、ウィジェットをブロックに変換することです。

説明がお役に立てば幸いです。

そのGIFを見ているときにドラッグアンドドロップしたいという強い衝動があります。さらに、ブロックがクリックされたときにブロックがどのサイドバーに追加されるかが明確ではありません。 左側がフルハイトなのが好きですが

最初の説明は次のとおりです。

フェーズ2の最初のステップでは、ウィジェットUIをアップグレードして、グーテンベルクでのページや投稿の編集方法と一致する最新のブロックエディターを組み込みます。

これは見当違いだと思います。 まず、タスクが大きく異なる場合にすべてが同じように見えるのは混乱を招きます。 また、ウィジェットは投稿やページの編集と同じものではありません。 すでにそうであるように、異なって見えるはずです。
第二に、基礎となるアーキテクチャに取り組んでいません。 ウィジェットの実行方法を変更したい場合、ウィジェットの保存方法を変更しますか？ それらの書き方を変えていますか？ テーマがそれらを出力する方法を変更していますか？
コアウィジェットはすでにブロックになっています。 ブロックはウィジェットになる必要はありません。
ここでの本当の目標は何ですか？ ウィジェットページをエディタページのように見せたいだけなら、それは悪い考えだと思います。 物事を違うものにするためだけに並べ替えたいのなら、それはリソースの有効活用ではないと思います。 フェーズ2が本当にカスタマイザーに関するものである場合は、おそらくこのウィジェットページをそのままにして、カスタマイザーの新しいインターフェイスの設計を目標にする必要があります...しかし、同じ質問があります。

グーテンベルクのブロックインサーターはa11yのニーズを満たしていますか？

ある種。 グーテンベルクのUIは、優れたアクセシビリティにつながらなかった多くのトレードオフの結果です。

ウィジェット領域でインサーターを使用する場合、左側の列全体がまだそこにある必要がある理由がわかりません。 私には、UIが重複しているように見えます。

また、グーテンベルクで使用されているパターンの一部は、アクセシビリティに特に適していないため、盲目的に再利用しないことを検討することをお勧めします。 グーテンベルクでは、主にUIの一部のスペースが非常に限られているため、多くのトレードオフがあります。

代わりに、この画面では、スペース不足による制限はありません。 具体的には、最初の考慮事項として：

• アイコンのみを使用するボタンには問題があります。この画面で「+」ボタンを使用する理由はありません。テキスト付きのボタンを使用するのに十分なスペースがあります。
• 左側の列が残っている場合：検索フィールドでは、プレースホルダーを表示ラベルの代わりに使用しないでください。これは非常に物議を醸すパターンであり、デザイナーはアクセシビリティの障壁が生じることに注意する必要があります。

余談ですが、上部の「ライブプレビューで管理」はいつも私の気持ちを傷つけました🙂これはそれを再考する良い機会になるかもしれません。

今朝、これについて考えて数分過ごしました。さらに議論するために、別のハイブリッドモックアップを共有したいと思いました。

プロトタイプ
https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen?node-id=14%3A297&viewport=-818%2C1575%2C0.5&scaling=min-zoom

GIF

_誰かがこのアイデアを拡張したい場合に備えて、Figmaのリンクを次に示します。_

• グーテンベルクの上部のツールバーとサイドバーが表示されたままになるため、ブロックの追加と編集はおなじみです。 通常のグーテンベルク自動保存表示などを含めることもできます。
• 編集フレームは非常にグーテンベルクのようですが、皆さんはいつものように小さなウィジェットコンテナで編集しています。
• 標準の小さなブロック[ + Add block ]サーターボタンを使用するのではなく、各コンテナー内に大きくてわかりやすい
• 非アクティブなウィジェット領域も含まれます。

@kjellrモックアップはかなり良いと思います。 追加/変更するものは次のとおりです。

インスペクターの「ウィジェットエリア」部分は正確に何に使用されますか？ どちらかといえば、一度にすべてのウィジェット領域のタブではなく、「ウィジェット領域」タブを期待するかもしれません。

私が今指摘したことに結び付けて、各ウィジェット/ブロック領域が別々に編集された方がいいと思います。 このようにして、コンテンツの幅を各ブロック領域に一致するように調整できるため、より多くのWYSIWYGエクスペリエンスが提供されます。 ブロックの流れの方向（サイドバーの場合は垂直、ヘッダーとフッターの場合は水平）もカスタマイズできます。

非アクティブなブロックは、ポストエディタの下部にメタボックスが表示されるのと同じように、下部に表示される可能性があります。 ただし、グーテンベルクのコンテキストでの非アクティブなウィジェット/ブロック機能の有用性には疑問があります。 再利用可能なブロックシステムは、事前に構成されたブロックの一種のストレージとしてすでに機能している可能性があるため、非アクティブなウィジェットのアイデア全体を再評価する必要があります。

インサーターをデスクトップの横にフルハイトのサイドバーとしてドッキングし、現在のウィジェット画面のウィジェットライブラリと同じように使用できれば便利だと思います。 （もちろん、このドッキング機能は投稿エディターにも存在する必要があります。）

さらに、 @ aferciaが述べたように、

「ブロックを追加」プレースホルダー/ボタン-私の意見では何かが大きすぎます。 「ブロックの追加」を「ブロックの追加」に短縮して、アイコンの右側に移動することができます。 実際、投稿エディターの非段落ブロックアペンダーは、新しいウィジェットUIで使用されることになるアペンダーデザインと同じデザインを共有する必要があると思います。

トップバーのインサーターアイコン（モックアップには表示されていませんが、おそらくそこにあります）の横にラベルが付いているはずです。 実際、そこにあるすべてのボタンにはラベルがあり、オプションモーダルにラベルを表示/非表示にするオプションがあります。 （もちろん、これは投稿エディターにも存在するはずです。）

さらに、 @ aferciaが述べたように、

これに問題はありますか？ ここではなく、グローバルレベルで取り組む必要があるように思えます。

トップバーのインサーターアイコン（モックアップには表示されていませんが、おそらくそこにあります）の横にラベルが付いているはずです。 実際、そこにあるすべてのボタンにはラベルがあり、オプションモーダルにラベルを表示/非表示にするオプションがあります。 （もちろん、これは投稿エディターにも存在するはずです。）

同じ質問。

インスペクターの「ウィジェットエリア」部分は正確に何に使用されますか？ どちらかといえば、一度にすべてのウィジェット領域のタブではなく、「ウィジェット領域」タブを期待するかもしれません。

よくわかりません！ たぶん、すべてのウィジェット領域のクリック可能なリストです（画面に収まらない場合）。 この時点でそれを含める主な理由は、投稿/ページエディタで使用する階層であるドキュメント/ブロックをミラーリングするためでした。

「ブロックを追加」プレースホルダー/ボタン-私の意見では何かが大きすぎます。 「ブロックの追加」を「ブロックの追加」に短縮して、アイコンの右側に移動することができます。 実際、投稿エディターの非段落ブロックアペンダーは、新しいウィジェットUIで使用されることになるアペンダーデザインと同じデザインを共有する必要があると思います。

これは間違いなく繰り返されます。 （私が推測しているように）人々はここにさまざまな種類のコンテンツを追加する可能性が高いため、一般的な考え方は、テキストベースではないインサーターを使用することです。

いずれにせよ、ここで別のタイプのインサーターを使用する場合は、確固たる理由が必要であり、誤用を防ぐためにどちらか一方を使用するための明確なガイドラインを考え出す必要があります。

おそらく、ラベルは最初はプレースホルダーのようにスタイル設定できますが、検索バーにフォーカスがあると、GoogleのログインUIの入力フィールドがどのように機能するかのように、入力領域の上に移動しますか？

私はそれに反対することをお勧めします。 「フローティングラベル」アニメーションは、特にアクセシビリティを必要とするユーザーにとって、方向感覚を失い、予期しないものです。 また、このパターンでは垂直方向のスペースは節約されません。フィールドの上にスペースを確保する必要があります。 それは基本的にその主な目的を打ち負かします。

いくつかのリソース（賛成と反対）：

• https://medium.com/simple-human/floating-labels-are-a-bad-idea-82edb64220f6
• https://medium.com/@mds/are -float-labels-really-that-problematic-after-all-da7ffe7d5417
• https://joshuawinn.com/ux-input-placeholders-are-not-labels/
• https://feedbackguru.com/articles/form-without-labels-dont-use-placeholder-text/

プレースホルダーの代わりに実際の目に見える<label>要素の使用法に従って、関連するTracチケットhttps://core.trac.wordpress.org/ticket/40331にリンクされているリソースを参照して

問題の目的に焦点を合わせて議論を続けることができますか。 @kjellrは正しい方向への良い一歩のようです。

本当にモックアップが大好きです、@ kjellr！ これを考えてくれてありがとう。

1. 私はグーテンベルクのインターフェースが好きで、インスペクター（サイドバー）がまとまって含まれているので、この画面でこのジャンプを喜んで行います。 それは必要な動きです。
2. ウィジェット領域を現在の使用方法と同じように積み重ねておくと、そのレベルの親しみやすさが維持されます。これは、現在既存のユーザーにも必要だと思います。
3. トップバーから「ウィジェット」という単語を削除してみましょう。おそらく今のところ、インスペクターは単なる「ブロック」インスペクターです。 そこで、そこから「ウィジェットエリア」を削除します。 この時点で、視覚的な方法でブロックに確実に移行しています。
4. wp-adminナビゲーションは引き続き「ウィジェット」の命名規則を保持していますか？ 私は今、「はい」に傾いています。
5. ブロックインサーターが好きです。 私の唯一の提案は、ギャラリーブロックのインサーターがタイトルケースではなくセンテンスケースを使用することです。 たぶん、これはそれを模倣する必要がありますか？ 「ブロックを追加」

@mapk

トップバーから「ウィジェット」という単語を削除してみましょう。おそらく今のところ、インスペクターは単なる「ブロック」インスペクターです。 そこで、そこから「ウィジェットエリア」を削除します。 この時点で、視覚的な方法でブロックに確実に移行しています。

同意しました。

wp-adminナビゲーションは引き続き「ウィジェット」の命名規則を保持していますか？ 私は今、「はい」に傾いています。

長期的には、このページの名前を「ブロックエリア」などに変更する必要があると思いますか？ ナビゲーションでは、最初は「ブロックエリア（ウィジェット）」と呼ぶこともあります。

トップバーから「ウィジェット」という単語を削除してみましょう。おそらく今のところ、インスペクターは単なる「ブロック」インスペクターです。 そこで、そこから「ウィジェットエリア」を削除します。 この時点で、視覚的な方法でブロックに確実に移行しています。

そのラベルを上部に追加した主な理由は、ここに何らかのページタイトルまたはH1を含めることでした。 私はそれを他の場所に置くことができると思います。 たぶん、「ウィジェット領域」の上か、サイドバーのどちらかです。

ブロックインサーターが好きです。 私の唯一の提案は、ギャラリーブロックのインサーターがタイトルケースではなくセンテンスケースを使用することです。 たぶん、これはそれを模倣する必要がありますか？ 「ブロックを追加」

うん。 Figmaファイル/プロトタイプでこれを更新しました。 👍

グーテンベルクのトップツールバーとサイドバーを表示し続けます

グーテンベルクに関するアクセシビリティチームのレポートで指摘されて

そもそもなぜトップバーが必要なのですか？ 何があるべきですか？

グーテンベルク開発の初期段階では、[保存/公開]ボタンの配置について長い議論がありました。 それを上に置くことは、アクセシビリティにとって理想的ではありません。 それについてのコンセンサスはありませんでしたが、残念ながら、それは通過しました。 このページで繰り返すのが理想的とは言えないパターンが最善の道であるかどうかはわかりません。

コンテンツの線形化は、優れた情報アーキテクチャの基本原則です。

多くのユーザーは、DOMの順序に従って、線形化された方法でコンテンツを認識します。 これは、すべてのキーボードユーザーとスクリーンリーダーユーザーに当てはまります。 線形化されたときに意味のある方法で情報を整理することは、優れたアクセシビリティにとって最も重要です。

自然で最も明白な論理フローは通常、次のとおりです。

• 物事を行う、フィールドに入力するなど、設定を設定するなど。
• そして_その後_保存

「保存」ボタンが必要かどうかさえわかりませんが、必要な場合は、ボタンとその他の「グローバル」コントロールを線形化されたナビゲーションエクスペリエンスの最後（ページの下部）に配置する必要があります。

注目に値するのは、コンテンツの線形化は、ユーザーの手がデバイスの下部にあるモバイルUIを管理する原則でもあります🙂

サイドバー：それが必要かどうかはわかりません。

[ウィジェット領域]タブにはどのようなコントロールまたは設定が必要ですか？

[ブロック]タブのコントロールは何ですか？ サイドバーのブロック設定については以前に議論されてきました。ブロックを「選択済み」状態に保ち、サイドバーにジャンプしてそこに配置されたブロック設定を操作することは非常に困難です。 これは絶対に避けてください。

最後に：見出し。 これらは、ページ内の情報を検索するために使用される主要なメカニズムです。 見出しを使用すると、支援技術のユーザーはページ内のさまざまなセクションにジャンプできます。 最終的なデザインによっては、ページの主要なセクションを識別するために見出しを使用する必要があります。

このすべての調査により、とにかく投稿エディタを修正する必要があることが明らかになったと思います。 ウィジェットページを投稿エディターのように変更する際の問題のほとんどは、ウィジェット/ブロック領域だけでなく、あらゆるコンテキストでのグーテンベルクエディターの問題です。

この機会に、1つの石で2羽の鳥を殺し、現在のグーテンベルクエディターを改訂して、現在のウィジェット画面を適切に置き換え、一般的に使いやすくアクセスしやすくすることで、投稿/ページ編集に適したものにする必要があると思います。

いずれにせよ、私は@aferciaを使用しており、投稿エディターで同じ問題がウィジェットページに複製されるのを見たくありません。

私の考えでは、すべての提案は完全に使用可能なページを壊したばかりであり、何のメリットもありません。

上記の方向へ

プロトタイプ：

https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen-Exploration?node-id=14%3A297&viewport=2639%2C1532%2C0.5&scaling=min-zoom

GIF：

• @mapkのメモ
• ページタイトルをコンテンツ領域に移動しました。
• 「ブロックエリア」のグローバルサイドバーを保持して、それらが何であるかを説明し、各サイドバーを編集するためのクイックリンクを提供しました（プロトタイプで後で示すように、画面からスクロールした場合）。
• ＃8589から@jasmussenの代替ブロック

^余談ですが、これがnav-menus.php変換されるの

素敵なモックアップ、@ kjellr; 現在の投稿エディタのUIに基づいている場合、新しい[ブロック領域]ページがどのように表示されるかにかなり近いように見えると思います。 ただし、前述のように、現在のウィジェットページを置き換える前に、グーテンベルクエディターをよりアクセスしやすくする必要があると思います。

特に、ウィジェットページのオーバーホールの前に、次の点に確実に対処する必要があると思います。

• ＃3976
• ＃10519
• ＃10524
• ＃11581
• ＃12254
• ＃13309

また、サイドバーの「ブロック領域」の部分の説明は、おそらく次のようになります。

（以前の「ウィジェットエリア」）

それらがウィジェット領域と呼ばれなくなったことを明確にするため。

また...単に「ブロックエリア」ではなく「グローバルブロックエリア」と呼ぶべきでしょうか？ 技術的には、 post_contentすべてのインスタンスは「ブロック領域」であるため、「グローバル」という用語は、何が参照されているかを明確にするのに役立つ場合があります。

実際、今考えてみると...グローバルブロックエリアは再​​利用可能なブロックとほぼ同じではありませんか？ これを想像してみてください。将来的には、ヘッダー、フッター、サイドバーに再利用可能なブロックを使用して、グーテンベルクでページテンプレートを作成できるようになります。

これは実際には＃13519に結びついていますね。 将来的には、（グローバル）ブロック領域は再利用可能なブロックにすぎず、「ブロック領域」ページはまったく存在せず、再利用可能なブロックのリストを含むページと、ページテンプレートのリスト...すべてGutenbergで編集できます。

長期的には、「（グローバル）ブロックエリア」ページも存在しないと思いますが、ページテンプレートの作成/編集はまだ行われているため、 @ kjellrのモックアップはおそらく短期的に発生するものに近いでしょう。遠い将来。

@ZebulanStanphillに同意します。視覚的なモックアップの最初に考慮される他の問題、特に＃11581で概説されているキーボードアクセシビリティの計画を確認したいと思います。 これらの提案はグーテンベルクで考えられたものですが、ここでもいくつかの点が当てはまります。

ただし、特別なキーボードショートカットや特別なメカニズムを使用する前に、できるだけシンプルにすることを検討してください。 前のコメントで説明したように、コンテンツの線形化を考慮してください。

ここでの努力と調査に本当に感謝していますが、アクセシビリティの主な懸念事項であるトップバーとサイドバーについてはまだ確信が持てません。 カスタマイザーには完全にアクセスできないため、このページが_すべてのユーザー_がウィジェットを管理できる唯一の場所になることを皆さんにお知らせしたいと思います。

このページは、アクセシビリティを必要とするユーザーのウィジェットを管理する唯一の機会であるため、現在のページと比較してアクセシビリティの低下はないはずです。 代わりに、私たちはそれをより良くするよう努めるべきです🙂

見出し
メインのh1は、ページ内の他の何よりも先に、メインコンテンツの最初のものである必要があります。 上記のプロトタイプではこれは見られません。

保存
新しいブロックウィジェットが自動保存されるかどうかはまだわかりません。 現在のウィジェットは1つずつ保存する必要があります。つまり、[保存]ボタンをどこかに配置し、アクセシビリティ上の理由から、ブロックの_後_にする必要があります。 代わりに、自動保存メカニズムがある場合は、[保存]ボタンは必要なく、トップバーも必要ないと思います。

さておき
このページの現在のヘルプパネルの内容を検討した人はいますか？ そこにはいくつかの重要な情報があります。 すべてを削除するのではなく、どの部分を残す必要があるかを評価する価値があります。

デザインの観点から何かを提案できる場合：ページにテキストを入れることを恐れないでください🙂タイポグラフィは巧妙に作成されていれば美しく、ページ内のテキスト情報が大いに役立ちます。

@afercia

アクセシビリティの主な懸念事項であるトップバーとサイドバーについては、まだ確信が持てません。

上部のバーを下部に配置し、デフォルトでボタンラベルを付けることができますが、サイドバーのないブロックのインスペクター設定をどのように処理しますか？ ブロックインスペクター設定の代替UIについて何かアイデアはありますか？

カスタマイザーには完全にアクセスできないため、このページがすべてのユーザーがウィジェットを管理できる唯一の場所になることを皆さんにお知らせしたいと思います。

興味があります。カスタマイザーのどの部分に適切にアクセスできないのですか？

このページは、アクセシビリティを必要とするユーザーのウィジェットを管理する唯一の機会であるため、現在のページと比較してアクセシビリティの低下はないはずです。 代わりに、少しだけ良くするように努力する必要があります_smiling_face

これは百回。 WordPress 5.0の処理方法に関する私の最大の問題は、クラシックエディターで正常に機能していたいくつかのことが、必要のないときにグーテンベルクで後退したことでした。 同じ過ちが二度と起こらないようにしたいと思います。

新しいブロックウィジェットが自動保存されるかどうかはまだわかりません。 現在のウィジェットは1つずつ保存する必要があります。つまり、[保存]ボタンをどこかに配置し、アクセシビリティ上の理由から、ブロックの後に配置する必要があります。 代わりに、自動保存メカニズムがある場合は、[保存]ボタンは必要なく、トップバーも必要ないと思います。

ブロックエリアに投稿やページのように元に戻す/やり直すことができれば本当にいいと思います。 しかし、それが今のところ範囲外であれば、[保存]ボタンは不要だと思います。 実際、元に戻す/やり直す場合でも、保存ボタンは必要ですか？ 投稿エディタに[下書きを保存]ボタンがあるのはなぜですか？

現在のモックアップの問題の1つは、投稿エディターが一度に1つの投稿を編集するように設計されていることです...複数ではありません。 元に戻す/やり直しボタンはバーにありますが、現在のモックアップのコンテキストでは、1つのブロック領域だけでなく、ページ上の任意のブロック領域に加えられたすべての変更を追跡する必要があります。 これが、再利用可能なブロックのリストページからアクセスする再利用可能なブロックのように（または文字通りとして）各ブロック領域を個別に編集したい理由の1つです。

今のところ、すべてのブロック領域を1つのページに配置する場合、保存ボタンや元に戻す/やり直しボタンを各ブロック領域のアコーディオンの下部に配置するのが最も理にかなっていると思います。

このページの現在のヘルプパネルの内容を検討した人はいますか？ そこにはいくつかの重要な情報があります。 すべてを削除するのではなく、どの部分を残す必要があるかを評価する価値があります。

同意する。 でも、正確にはどこに行けばいいのだろうか。 下部のバーを除いて、上部の[ヘルプ]ボタンからアクセスできますか？ または、ページタイトルの横または下に[ヘルプ]ボタンがありますか？ 情報はサイドバーに表示されますか、それともポップアップに表示されますか？

このスレッドが非常に長くなり、ほとんど管理できなくなることをお詫び申し上げます。 短くする必要があるかもしれませんが、この時点で、フェーズ1で発生した同じ間違いを回避するために、設計プロセスに関する専用の会議が価値があると思う傾向があります。

ビジュアルプロトタイプの前に、いくつかのこと（情報アーキテクチャ、コンテンツの線形化など）に対処する必要があります。そうしないと、フェーズ1の結果と比較してあまり進歩が見られないのではないかと思います。

@youknowriad et all：機会があれば、あなたの考えを教えてください。

それは言った：

トップツールバー
トップツールバーの内容はどうなっていますか？ 最後のプロトタイプでは、まだ定義されていないボタンがいくつか配置されているのがわかります。 投稿編集ページとの比較：

• 最初にウィジェット領域を選択する必要があるため、[ブロックの追加]ボタンはあまり意味がありません。
• 「元に戻す」と「やり直し」は、編集投稿のように「グローバル」にすることはできません。ウィジェットごとに行う必要があります。 @ZebulanStanphillが指摘したように、「投稿エディタは、一度に1つの投稿を編集するように設計されています...複数ではありません」
• このページでは、「コンテンツ構造」と「ブロックナビゲーション」は意味がありますか？ 私は違うと思います
• 保存/公開：まだ不明（前のコメントを参照）
• サイドバーを切り替えるために「設定」ボタンは必要ないと思います
• 省略記号「詳細」ボタン：このページに「ツールとオプション」があるかどうかわからない

最後のプロトタイプでは、ページ上部のメインのh1見出しと、ページ内の他の見出しが欠落しています。 以前のプロトタイプのいくつかは、この点で優れていました。

サイドバー：

サイドバーのないブロックのインスペクター設定をどのように処理しますか

どのウィジェットが最初に設定を必要とし、これらの設定がどうなるかを明確にする必要があると思います。
エディターのウィジェットブロックのようになる場合は、たとえば＃1464、＃1792、＃7941を参照してください。
次に、フェーズ1で行ったのと同じ間違いを繰り返します。前のコメントとアクセシビリティチームのレポートで説明した理由により、重要な設定をサイドバーに配置しないでください。

興味があります。カスタマイザーのどの部分に適切にアクセスできないのですか？

それらすべて？ :)ドキュメント構造から始めて、カスタマイザーUIではすべてがリストであり、見出しはすべてh3です。 スライドパネルは、スクリーンリーダーのユーザーにとってひどい体験です。 キーボードの操作は予期しないことが多く、タブを後方に移動する必要があります。 アイコンのみのコントロールが豊富。 他の多くのもの。
カスタマイザーは、アクセシビリティを念頭に置いて実際に設計されたわけではありません。 時が経つにつれて、私たち（アクセシビリティチーム）は最も重要なアクセシビリティの障壁にパッチを当てようとしましたが、カスタマイザーをアクセシブルにするにはまだ長い道のりがあります。 ただし、これは間違いなくこの問題の範囲外です。

保存：
UIと操作が簡単になるので、自動保存するウィジェットに傾倒します。 しかし、それは視覚的および聴覚的なフィードバックで非常に明確にする必要があります。 WordPress管理者全体の不一致の1つは、何がすでに保存されているのか、何が手動の保存アクションが必要なのかがわからないことです。

このスレッドで良い考え。

ここに少し戻って、全体像を見てみましょう。 機能を個別にレビューする場合、_destination_を無視する傾向があります。 目的地へのステップと目的地自体の両方が重要ですが、後者は前者に通知する必要があります。

この場合、フェーズ2の目標の1つは、ブロックを使用できる場所を

その意味で、（Kjellが調査したように）ウィジェット画面のエディターを使用すると、完全に異なるレイアウトの2つの画面をサポートすることに努力を分割する代わりに、単一のインターフェイスを改善できます。

エディターに問題がある場合は、エディター用に修正して、薄く広げるのではなく、2つの画面を改善しましょう。 さらに、追加のブロック領域をエディターに直接表示する方法を引き続き検討しているため、これら2つのインターフェイスはさらに収束し、エディターに慣れている人が両方でくつろげるようになります。

@jasmussenありがとう、私は全体像を見るためにあなたの提案に本当に感謝します。

エディターに問題がある場合は、エディターの問題を修正して2つの画面を改善しましょう。

ただし、エディターの一般的なレイアウトに基本的なアクセシビリティの問題があり、解決するには適切な再考が必要であることに気付いていないようです。 これは、_October_のアクセシビリティチームレポートで詳しく説明され

上記の理由により、ウィジェットページでのアクセシビリティの低下は受け入れられないのではないかと思います。 このページが現在のようにエディターレイアウトを採用しようとすると、リグレッションが発生します。

State of the Wordで発表されたフェーズ2の目標の1つは、WordPress全体のさまざまなチームの連携を改善することでもあります。 デザイン、アクセシビリティなどはすべて、最初から統合する必要がある要素です。

その意味で、新機能の設計プロセスの開始以来、アクセシビリティチームの推奨事項が検討されていることを望んでいます。 デザインの前にデザインする必要があるものがあります🙂

私は間違いなく両方の画面を改善することに同意します。 これには、誰もが心を開いたままにし、私たちが今持っているものを変えることができないと思い込まないようにする必要があります。 あなたが言ったように、_destination_には、最初からアクセシビリティに対処できる設計プロセスも含まれています。

ここでこの一般的な議論を続けることが最も適切な場所であるかどうかはわかりません。そのため、専用の会議を提案しました。

質問：ウィジェットの設定がエディターで行われるようにサイドバーにあると仮定します（注：上記で説明したように、私見ではお勧めできません）。例：

＃1594の最近の投稿ブロックのスクリーンショット（そこにはたくさんの設定があります...）

現在の最新コメントブロックのスクリーンショット：

次に、これらすべての設定はカスタマイザーのどこにありますか？ そこには設定サイドバーはありません。追加の「スライドサイドバー」が表示されないようにしたいと思います。 関連する問題＃13205のスクリーンショット

ウィジェットブロックの設定の量が限られているようにすることを検討することを強くお勧めします：ウィジェット内。

このスレッドが非常に長くなり、ほとんど管理できなくなることをお詫び申し上げます。 たぶん私たちはもっと短く滞在しようとすべきです

私はここで心から同意します。 役立つことの1つは、問題に直接関連するすべてのコメントを保持することです。

アクセシビリティの主な懸念事項であるトップバーとサイドバーについては、まだ確信が持てません。

たぶん、ここでの解決策は、この画面からトップバーを完全に削除することですか？ この画面の目的でトップバーは必要ですか？ 私がその目的のために見る主な理由は、自動保存のためです。 代わりにインスペクターで処理できますか？ そして多分今のところブロックごとに？ これが私たちが紹介したいパターンであるかどうかはわかりませんが、特にa11yを支援するために調査する価値があります。

どのウィジェットが最初に設定を必要とし、これらの設定がどうなるかを明確にする必要があると思います。

私はここで同意しません。 この画面は、ブロックを以前のウィジェットのコンテンツ領域に統合することに関するものです。 すべてのブロックはこのインターフェースを介してアクセスされるため、設定は当然その一部です。

前のコメントとアクセシビリティチームレポートで説明されている理由により、重要な設定をサイドバーに配置しないでください。

これはブロック固有の関連コメントであり、実際にはそれらのブロック固有の問題に委任する必要があります。

カスタマイザーは、アクセシビリティを念頭に置いて実際に設計されたわけではありません。

ウィジェット/ブロックに関連するカスタマイザーのコメントも、その特定の問題に委任する必要があります[＃13205]。

@afercia私はあなたのコメントをターゲットにする

@kjellrのプロトタイプをリフして、いくつか編集しました。
トップバーをクリーンアップして、a11yで必要なH1と、すべてのウィジェット領域を保存するSaveボタンだけが表示されるようにしました...自動保存も示します。

これは新しいトップバーのパターンだと思いますので、いくつかの考えを聞いてみたいと思います。 グーテンベルクにはまだ馴染みがありますが、これは現在、完全なサイト編集体験に向けた中間段階であるため、問題ないと思います。

フィグマプロトタイプ

https://www.figma.com/proto/R0KYBQGGpdCsqgW2EWFDtK/Gutenberg-Widgets-Admin-Screen-Exploration-v2?node-id=14%3A297&scaling=min-zoom

ウィジェットページのブロック化が進む2つの方法を探るために、いくつかの簡単なモックアップを作成することにしました...

1つ目は、すべてのブロック領域を1つのページに表示することです。

アクセシビリティを向上させるために、トップバーを下に移動しました。 ほとんどのボタンは通常、単一のブロック領域を編集する場合にのみ意味があるため、ほとんどがむき出しになっています...複数ではありません。

また、アクセシビリティを向上させるために、バーのボタンにラベルを追加しました。 おそらく、これらのラベルはワイドスクリーンにのみ表示され、＃10524のように、表示を切り替えるオプションがあります。

このモックアップは、すべてのブロック領域の自動保存も想定しているため、「公開」ボタンがありません（複数のブロック領域に適用した場合も意味がありません）。

おそらく、スポットライトモードやフルスクリーンモードなどのオプションは、投稿エディタのように[その他のオプション]メニューにあります。

この2番目のモックアップは私の好みです。各ブロック領域は投稿/ページのように個別に編集されます。 これは、既存のウィジェット画面のユーザーにはあまり馴染みがありませんが、投稿エディターのユーザーにはより馴染みがあります。

ブロックエリアリストページ（基本的には/wp-admin/edit.php?post_type=block_area ）からさまざまなブロックエリアにアクセスできます。 テーマは通常どおりコンテンツの幅を制御するため、ヘッダー/フッターは広く表示され、サイドバーは短く表示されます。

グローバルブロック領域のコンテキストではほとんど意味がなく、プラグインサイドバー/モーダルとして実装する必要があると思うため、このモックアップからドキュメントアウトラインを省略しました（したがって、[その他のオプション]で非表示にすることができます）。メニュー）とにかく。

両方のモックアップの[ヘルプ]ボタンが何をするのか完全にはわかりません。 ポップアップモーダルが表示され、現在のウィジェットページの[ヘルプ]ボタンと同じ情報が表示されると思います。

[ヘルプ]ボタンも下部のバーにある場合があります（[ライブプレビューで管理]ボタンと同じ）...どちらがどこに属しているかはわかりません。

一度に1つのウィジェット領域のみを表示すると、いくつかの問題が発生します。

• あるエリアから別のエリアに物を移動するのは難しいです。
• 一度に1つしか見ることができない場合、サイトにすでに何があるかを把握することは困難です。
• ページの編集に非常に似ています（ユーザーの混乱）。

コンテンツをレンダリングする必要はありますか？ 現在ウィジェットページにあるので、サイト構成があるのは素晴らしいことだと思います。 すべてのウィジェットを簡単に確認して再配置できます。 構成の表示を妨げる​​実際のコンテンツに煩わされる必要はありません。 それらがどのようにレンダリングされるかを確認したい場合は、Custimzerを使用できます。この場合、準備が整うまで変更は公開されず、一度に1つのウィジェット領域に制限され、領域間でウィジェットを移動できません。

一度に1つのウィジェット領域のみを表示すると、いくつかの問題が発生します。

• あるエリアから別のエリアに物を移動するのは難しいです。
• 一度に1つしか見ることができない場合、サイトにすでに何があるかを把握することは困難です。
• ページの編集に非常に似ています（ユーザーの混乱）。

良い点、@ joyously。 短期的に前進するための最良の方法は、実際、すべてのブロック領域を1つのページから編集することだと思います。

将来的には、同じことが可能になると思いますが、まったく同じではありません。 ページテンプレート編集を介して、同じページテンプレートにすべて表示される複数のブロック領域を編集できるはずです...ブロック領域は、その場で（または必要に応じてエディターのスタンドアロンインスタンスで）編集できる再利用可能なブロックになります。 、再利用可能なブロックがすでに機能しているのと同じように。 これにより、GutenbergエディターのWYSIWYGの利点を維持しながら、上記のすべての問題を解決できます。 この時点では、現在のウィジェットページのようなページは必要ありません。 しかし、明らかに、私たちはまだその点から遠く離れています。

コンテンツをレンダリングする必要はありますか？ 現在ウィジェットページにあるので、サイト構成があるのは素晴らしいことだと思います。 すべてのウィジェットを簡単に確認して再配置できます。 構成の表示を妨げる​​実際のコンテンツに煩わされる必要はありません。

グーテンベルクの設計原則の1つは、選択されていないブロックはフロントエンドと同じように見えるプレビューを表示し、選択されたブロックは編集用に最適化する必要があるということです。 したがって、理想的には、コンテンツが構成を妨げないようにする必要があります。 残念ながら、既存のウィジェットに相当するブロックは、実行すべきことのほぼ完璧な例です。

ParagraphやHeadingブロックとは異なり、LatestPostsブロックのようなコンテンツを直接編集することはありません。 残念ながら、これにより、重要なコントロールのほとんどがインスペクターにスローされます。インスペクターは、セカンダリ/アドバンスドオプション用に設計されています。 そのようなブロックは、選択するとコンテンツプレビューの上にオーバーレイで重要なコントロールが表示されるように修正する必要があると思います。そうしないと、ブロックを選択するとプレビューが完全に消えます。 技術的には、ブロックの選択された編集可能なフォームが、選択されていないフォームと完全に異なって見えることを妨げるものは何もありません。

さらに、ブロックの並べ替えを簡単にするために、[ブロックナビゲーション]メニューをプラグインサイドバーとして再実装し、UIからブロックをドラッグアンドドロップで並べ替えることができるようにする必要があると思います。 ＃11408を参照してください。

たぶん、ここでの解決策は、この画面からトップバーを完全に削除することですか？

ウィジェットが主にエディター自体から管理される未来を想像することができます。 トップバーを維持することで、両方ともエディターの認識可能性を維持します—単一のインターフェースを学習します—そしてそれは、画面ごとに修正するのではなく、根本でアクセシビリティの問題を調べて、それらを_全体的に_修正することを強制します。インターフェイスアーキテクチャの断片化。

そのモックアップ@ZebulanStanphillを追加していただきありがとうございます。 間違いなく私が視覚化するのに役立ちます。

以前のユーザーテスト（23ページ）でわかったことの1つは、公開バーが画面の下部にある場合、人々は公開バーに気付かないということです。 それを思い出したときでさえ、人々はそれがそこにあったことを忘れていました。 ブラウザのクロムのように見えると考える人もいました。 ボトムドック広告が多発するモバイルウェブでは、その問題が深刻化していることがわかります。

以前のユーザーテストで発見しました（23ページ）

申し訳ありませんが、議論する気はありませんが、ユーザーテストには、キーボードユーザー、スクリーンリーダーユーザー、視野が限られているユーザーなど、アクセシビリティを必要とするユーザーが含まれていなかったのは事実です。

グーテンベルクの[保存]ボタンの位置については、数か月前にすでに議論されており、コンセンサスは得られていません。 _視覚的に_一部のユーザーは上部のボタンを好むことを理解しています。 ただし、線形化されたナビゲーションエクスペリエンスでは、現在のボタンの位置は、ユーザーがインターフェイス全体を後方にタブ移動する必要があるため、理想的とは言えません。

カスタマイザーで同じパターンが使用されているため、グーテンベルク以前でも既知の問題です。

論理フローでは、どのWebアプリケーションでも、保存アクションはフローの最後にあります。 下部の公開バーが解決策であると言っているわけではありませんが、これはすべてのユーザーにとって適切な解決策を必要とする問題です。

トップバーを維持することで、私たちは両方ともエディターの認識可能性を維持します—単一のインターフェースを学習します—そしてそれは私たちに、画面ごとに修正するのではなく、根本でアクセシビリティの問題を調べて全体的に修正することを強制します、インターフェイスアーキテクチャの断片化。

@jasmussenこれは公正であり、a11yに対する全体的なアプローチに同意します。 私の希望は、将来廃止される可能性のあるこの画面に多くの時間を費やさないことです。 そして、トップバーの周りのa11yには間違いなく問題が割り当てられているはずです。

プロトタイプにトップバーを含めることになりましたが、この画面で機能しない可能性のある多くの機能を削除しました。 これは良い解決策だったと思いますか、それとも削除された他の部分がここで役立つと思いますか？

プロトタイプにトップバーを含めることになりましたが、この画面で機能しない可能性のある多くの機能を削除しました。 これは良い解決策だったと思いますか、それとも削除された他の部分がここで役立つと思いますか？

確かに、ウィジェット画面に意味をなさないボタンは絶対に削除する必要があります。

@melchoyce
@aferciaが言ったことに加えて、Crazyhorse Demoの下部のバーの問題の一部は、ポップアップまたはブラウザのクロムのように見えることです。

エディターの他の部分と衝突する背景色を使用しており、左側のナビゲーションもオーバーレイします。 どちらも、それがエディターの一部ではないため、関連性がないことを意味します。 また、間違いなく高すぎます。 これをグーテンベルクの現在のトップバーと比較してください。これは間違いなくエディターの他の部分とのつながりを感じます。

ボトムドック広告が多発するモバイルウェブでは、その問題が深刻化していることがわかります。

私はこれが問題であるとは本当に思っていません。 Spotify、Twitter、Instagramなど、多くのアプリが画面下部のバーにコントロールを配置します。 Gutenberg Mobileでさえ、すでにいくつかのコントロールを下部に配置しています。

クレイジーホースデモとグーテンベルクの大きな違いを考えると、この2つはほとんど比較できないと思います。 しかし、とにかくその古いユーザーテストを指摘してくれてありがとう。 以前はその存在に気づいていませんでした。

@mapk

...私はa11yに向けた全体的なアプローチに同意します。 私の希望は、将来廃止される可能性のあるこの画面に多くの時間を費やさないことです。

これは大きな問題です。 既存のウィジェットページのデザインにブロックをドロップすることはできません。 新しい[ブロック領域]ページのためだけに個別のUIデザインを作成するべきではありません。 しかし、投稿エディタにはまだいくつかの大きな欠陥があるため、それを再利用することもできません。 したがって、最終的には、ウィジェットページのオーバーホールは、改善が必要な投稿エディタによってブロックされます。

そして、トップバーの周りのa11yには間違いなく問題が割り当てられているはずです。

同意する。

@jasmussen

確かに、ウィジェット画面に意味をなさないボタンは絶対に削除する必要があります。

複数のブロック領域を一度に表示するページの場合、トップバーのほとんどのコントロールは意味をなさなくなりました。 それでも、[設定]サイドバーと[その他のオプション]メニューだけが意味をなします。 さらに、Yoast SEOのようなプラグインは、複数のブロック領域がある画面に適用すると機能しなくなる可能性があるため、プラグインは[ブロック領域]ページをサポートするためにオプトインする必要がありますか？

下書き、スケジュールされた更新、元に戻す/やり直しをサポートするようにブロック領域を更新した場合、[元に戻す]、[やり直し]、[下書きとして保存]、[更新]ボタンが各ブロック領域の下に表示される可能性があります。 しかし、長期的には、ページテンプレートが登場すると、ブロック領域ページが完全に存在しなくなる可能性があることを考えると、その追加機能を実装する価値があるかどうかはわかりません。

さらに、ブロック領域を個別に編集する機能を追加して、ブロック領域を編集するフォールバック方法を可能にする必要があると思います。YoastSEOのような、単一のブロック領域エディターでのみ意味のあるプラグインを必要に応じて使用できます。 。

これは大きな問題です。 既存のウィジェットページのデザインにブロックをドロップすることはできません。 新しい[ブロック領域]ページのためだけに個別のUIデザインを作成するべきではありません。 しかし、投稿エディタにはまだいくつかの大きな欠陥があるため、それを再利用することもできません。 したがって、最終的には、ウィジェットページのオーバーホールは、改善が必要な投稿エディタによってブロックされます。

私は懸念を理解し、ここのほぼすべてに同意します。 ただし、トップバーとインスペクターのa11yをさらに改善するために作業を進めているので、このコメントに示されているプロトタイプを同時に進めることができると思います。

https://github.com/WordPress/gutenberg/issues/13204#issuecomment -459175233

@youknowriad 、これを

まだまだですが、このPR＃13088はここでの要件であり、着陸したらすぐに調査を開始します。

また、ここで説明するa11yの問題に対処するための問題が作成されていることにも注意してください[＃13663]。

私が抱えている大きな懸念の1つは、単一の保存ボタンと単一のドラフト/公開機能です。 ウィジェット領域は、サイト全体のさまざまなページに分散しており、さまざまな懸念事項があります。 それらに変更を個別にデプロイできる方がはるかに論理的であるように思われます。

このウィジェット領域の再想像は、ユーザーが各ウィジェット領域への変更を個別にスケジュールできるように、ウィジェット領域を適切に分離する絶好の機会です。

サポートフォーラムで、テーマの切り替え後に非アクティブなウィジェットをサイドバーに移動する方法についての質問に答えていたところ（iPadを使用）、このウィジェットページにユーザー補助モードの画面オプションがあることに気付きました。 これを使用すると、一度に1つのウィジェットのみが表示されますが、ユーザー補助モードなしで新しいウィジェットをクリックしたときに表示されるのと同様に、ウィジェットを配置するサイドバーを選択できます。
再設計で失われないように、他の人がこれを認識していることを確認したかったのです。

グーテンベルクで使用されているのと同じモーダルコードであるモーダルボックスでブロック設定を開くのはどうですか？
アクセシビリティの面で非常に複雑になるでしょうか。

個人的には、ウィジェットの純粋な投稿編集画面のデザインと外観を複製しようとすると、大きな間違いを犯すと思います。 あなたは将来あなた自身のために多くの問題を起こすでしょう。

参考までに、これはフェーズ2の間にFrontenbergに押し込む必要があるUIですか？ :)

はい、 @ tomjn 、これはUIです： https ：

それは大丈夫です。フロントエンドで実行するのが悪夢にならないように、管理ページ自体が適切でモジュール式であることを確認してください。そうすれば、バージョンごとに書き直されることなく、好きなように実行できます。

ここに、異なるユーザーが同時にウィジェットを編集する際の問題を指摘するtracチケットが発生し、ロックシステムを提案しているというメモを追加します。
https://core.trac.wordpress.org/ticket/12722

新しいウィジェット画面がロックソリューションをサポートしていることを確認することをお勧めします。

ここに、異なるユーザーが同時にウィジェットを編集する際の問題を指摘するtracチケットが発生し、ロックシステムを提案しているというメモを追加します。

次のチケットはWebRTCを使用した共同編集に関するものですが、多くのアイデアとデザインがプロセスに取り入れられており、概念は同じです。つまり、ブロックを編集するユーザーにロックします。 したがって、参照アイデアについては、そのUIを確認する価値があるかもしれません。
https://github.com/WordPress/gutenberg/issues/1930#issuecomment -333455412

ウィジェット領域のブロックエディターを取得するための残りの主なタスクのPRを要約した簡単なコメントを共有しています。

• 最優先のPR：ウィジェット領域をブロックとして抽象化する残りのエンドポイントの実装。 https://github.com/WordPress/gutenberg/pull/15015
  -（進行中）ごく最近のレビューに対するいくつかの更新は保留中ですが、PRはレビューの恩恵を受けることができます。
• 優先度が最も高い2番目のPR：ウィジェットのエンドポイントをウィジェット画面のブロックエディターに接続します。
  https://github.com/WordPress/gutenberg/pull/15074
  --https ：//github.com/WordPress/gutenberg/pull/15015に依存し
  -（進行中）レビューは保留中です。
• Webサイトフロントエンドのpost_idを参照するウィジェット領域をレンダリングします。
  --https：//github.com/WordPress/gutenberg/pull/15074。
  -（進行中）レビューは保留中です。

チェーン内で相互に参照する3つのPRをマージすると、ウィジェット画面のブロックエディターのエンドツーエンドのデモを行うことができます。

並行して、ウィジェット画面でブロックが期待どおりに機能するようにするには、他の改善が必要です。

コアブロックからワードプレス/エディターの使用法を削除します（ワードプレス/エディターはウィジェット画面では使用できません）。

• https://github.com/WordPress/gutenberg/pull/15635
• https://github.com/WordPress/gutenberg/pull/15572
• https://github.com/WordPress/gutenberg/pull/15521

画面が期待どおりに機能しない、または画面のエクスペリエンスが最適ではなくなるUIの問題を修正します。

• https://github.com/WordPress/gutenberg/pull/15472
• https://github.com/WordPress/gutenberg/pull/15470

その他のUIの問題は、ソリューションがまだ実装されていないウィジェット画面に影響を与えています。 主な問題は次のとおりです。

• ブロックポップオーバーが正しい位置に表示されていません。
• ブロックインスペクターはまだ利用できません。
• グローバルインサーターに相当するものはありません。兄弟インサーターと「/」オートコンプリートインサーターを使用してのみブロックを挿入できます。 ウィジェット領域ごとにグローバルインサーターが必要なのかもしれません。

前回のウィジェットの動作更新からしばらく時間が経過したことを踏まえて、前回の更新以降の開発を含む新しいウィジェットを共有します。
ウィジェットエンドポイントをウィジェット画面に接続するPRがマージされ、Webサイトのフロントウィジェット領域でブロックをレンダリングするPRもマージされました。
画面はまだ最適ではないエクスペリエンスを提供し、多くの機能強化が進行中です。

マージされたPRの（メイン画面の作業に関連する）： https://github.com/WordPress/gutenberg/pull/15015 、 https://github.com/WordPress/gutenberg/pull/15074 、 https://github.com / WordPress / gutenberg / pull / 15651

レガシーウィジェットブロックが既存のウィジェットを参照できるようにするPRがhttps://github.com/WordPress/gutenberg/pull/15801で提案されました

レガシーウィジェットはまだウィジェット画面で期待どおりに機能しません。そのため、ユーザーのサーバー側レンダリングコンポーネントをその画面https://github.com/WordPress/gutenberg/pull/15635に配置できることを確認する必要があります。 PRは以前にhttps://github.com/WordPress/gutenberg/pull/15801を参照しました

コアブロックからワードプレス/エディターの使用法を削除する作業について：
https://github.com/WordPress/gutenberg/pull/15572がマージされました。 https://github.com/WordPress/gutenberg/pull/15635は再レビューを保留しており、レビューに対応するためにhttps://github.com/WordPress/gutenberg/pull/15521を間もなく更新します。

画面が期待どおりに機能しない、または画面のエクスペリエンスが最適ではないUIの問題を修正する作業について： https ：
https://github.com/WordPress/gutenberg/pull/15470は議論中であり、決定を待っています。

私が抱えている大きな懸念の1つは、単一の保存ボタンと単一のドラフト/公開機能です。

これは間違いなく懸念の高まりです。 これについてさらに詳しく調べ、このボタンをブロックエリア固有に移動する方法を見ていきます（モックアップは近日公開予定）。 実際のブロックに移動する必要はないと思います。

別の更新。
短期プロジェクトボードはhttps://github.com/WordPress/gutenberg/projects/27で入手でき

私たちは、マージされ、他の二つの重要なPRのhttps://github.com/WordPress/gutenberg/pull/15521 、 https://github.com/WordPress/gutenberg/pull/15396

レビューが必要なPR

優先度の高い次のPRは
https://github.com/WordPress/gutenberg/pull/15801これをマージすると、ウィジェット画面でレガシーウィジェットを使用できるようになります。

https://github.com/WordPress/gutenberg/pull/15548は実質的に準備ができており、最終的な承認が必要です。

https://github.com/WordPress/gutenberg/pull/15948が更新され、最終承認も必要です。

PHPコードでいくつかの問題/潜在的な機能強化が見つかり、2つのPRが提出されました。 それは彼らにいくつかの追加の目になるでしょう：
https://github.com/WordPress/gutenberg/pull/15981
https://github.com/WordPress/gutenberg/pull/15983

これらのPRの1つに最初のレビューを行ってくれた@TimothyBJacobsへの小道具。

保留中の更新/ディスカッション

https://github.com/WordPress/gutenberg/pull/15635が議論され、可能な解決策に到達したようです。 私は、 ServerSideRenderProviderを持つという@gzioloによって提供された提案が好きでした。 私は次の数時間でそれを実装するつもりです。

https://github.com/WordPress/gutenberg/pull/15470 @aduthは、BlockEditorProviderだけでなく、ブロックエディターから期待されるいくつかのアーティファクト（書き込みフローなど）を含む新しいコンポーネントを公開する代替アイデアを提供します。 そのアプローチに関して誰も心配していなかったとしたら、最善の方法はそのコンポーネントを実装し、 https：//github.com/WordPress/gutenberg/pull/15470を更新してそれを使用することだと思います。

その他の更新

@aduthによって提案されたhttps://github.com/WordPress/gutenberg/pull/15988は、ウィジェット画面でのポップオーバー位置の問題のブロックを解除します。数時間以内に確認します。

この問題は1年間活動していません。 ウィジェット画面に別の概要の問題はありますか？

そうは思いません、@ ellatrix。 これを終了したい場合は、問題のリストもあるプロジェクトボードがあります。

この古い問題はプロジェクト委員会にもリンクしているので、開いたままにしておくと便利です。 また、誰かがこの問題に再び戻る時間があるときに更新することもできます。

プロジェクトボードには動きがなく、この問題に関する動きもないので、WP5.5ボードから削除します。

@ellatrixこの機能のステータスが

ホルヘがここで言及したすべてのPR： https ：
合併されました。

ねえアスラン。 @jcklpe

この機能のステータスは、wp-adminの[ウィジェット]画面で長時間作業していないため、WP5.5プロジェクトボードから削除されます。 作業が行われないという意味ではなく、5.5の優先事項ではないということだけです。

今日は歴史的な文書を表すだけなので、この大きな問題を閉じます。