これらの概念は、主に次の影響を受けます。

• アトミックブロック
• WordPress.com
• デザインライブラリ

このインタラクションのUXフローを標準化することは、グーテンベルクとユーザーに利益をもたらすと思います。

これはサポートされていますが、次のロジックを使用して、ポストタイプごととテンプレートのみがロード時に適用されます。

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

しかし、私はその価値をあまり見ていません。あなたが今説明したようなものが欲しいです。

利用可能なパターンを誇示するための画面領域が多いため、オーバーレイアプローチの方が好きです。

この機能は、ブロック領域の作業と並行しています。 投稿用に作成されたパターンや、テンプレートまたはその他のブロック領域用に作成されたパターンが存在する可能性があります。 たとえば、テンプレートパターンを使用して、単一の投稿テンプレートをサイドバーのあるレイアウトにすばやく変更できます。

グーテンベルクはデフォルトを定義すべきではありませんが、デフォルトのテーマは間違いなくそれらに付属しているはずです。

私の最初の考えは、この追加されたブロックパターンはページ上のコンテンツを置き換えるのではなく、ブロックを下部に追加するだけだということです。 このようにして、ブロックパターンは、コンテンツの構築/書き込み中にいつでも追加できます。 これはAtomicブロックと同様のフローですが、他のすべてのブロックを含むブロックがないことを望んでいます。

ええ、あなたが言ったのと同じ理由で、私もそのようにそれが好きです。

このプラグインからも学ぶべき興味深いことがあるかもしれません。 https://wordpress.org/plugins/full-site-editing/ @obenlandは現在最新のプラグインですか？

過去数週間に追加したブロックプレビュー作業がありませんが、それ以外は機能しています。

右側の大きなテンプレートプレビューにblockPreviewを使用すると、現在の反復は次のようになります。

@epiquerasは書いた：

これはサポートされていますが、次のロジックを使用して、ポストタイプごととテンプレートのみがロード時に適用されます。

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

しかし、私はその価値をあまり見ていません。あなたが今説明したようなものが欲しいです。

ブロックテンプレートを置き換えるこの機能について誰かがアイデアを得る直前に、この機能は_非常に_価値があることに注意したいと思います。 これにより、開発者は特定の投稿タイプの構成を具体的に定義できます。 多くのコンテンツタイプが厳密に整理されている@meredithcorpでは、この機能を幅広く活用しています。

この「ブロックパターン」機能は素晴らしいアイデアだと思いますが、現在の投稿タイプのブロックテンプレート機能の完全な代替ではなく、「追加」と見なされるようにしたいです。

次のステップ：

1. @melchoyceも彼女の探求を伝えます。
2. Diverge： wpcomが業界の他の例（Squarespaceなど）と一緒に何をしているのかを探る
3. コンバージ：より強力なパターンを1つのまとまりのあるモックアップとUXフローにまとめます。
4. Figmaのモックアップとプロトタイプ。

昨年、私はグーテンベルクのページレイアウトのプロトタイプをいくつか調べました。 私の探索にはいくつかの部分がありました：

• CPTだけでなく、ページで機能するようにレイアウトを拡張します。
• テーマの作成者が複数のテンプレートを「宣言」する方法を作成します。
• テーマの作成者がこれらのテンプレートを分類する方法を作成します。
• レイアウトを選択するためのUIを作成します。

デスクトップ

プロトタイプを見る

_注：このプロトタイプは私が試した以前のラウンドのものであり、一部の要素は古くなっています。_

モバイル

プロトタイプを見る

内訳

グーテンベルクの他のすべてのように、レイアウトピッカーはブロックです。 これは、いくつかの要素で構成されています。

• ブロックのタイトル/説明。
• レイアウトタイプを分類するためのタブ（ブロックインサーターの後にスタイル設定）。
  
  
  
  • これらはテーマで定義されています。
  
  
  • レイアウトが2つしかない場合（たとえば、<5）、タブは表示されません。
  
  
  • 分類されたレイアウトがない場合、タブは表示されません。
  
  
• 利用可能なページレイアウトのリスト。
  
  
  
  • レイアウトグラフィックは、それらに含まれるブロックに基づいて自動的に生成される必要があります。
  
  
  • 画像は灰色のボックス、テキストは濃い灰色の線、ボタンは青色などです。すべてを単純な形に抽象化する必要があります。
  
  
• 最後に、レイアウト自体。
  
  
  
  • これらのモックアップでは、グーテンベルクに適用されたテーマスタイルを見ることができます。 テーマスタイルが宣言されていない場合、ブロックは一般的なグーテンベルクスタイルにフォールバックします。
  
  
  • また、ページのグローバル要素（この場合は、サイトのロゴ、ナビゲーション、フッター）に気付くかもしれません。 これらはプレゼンテーション用に存在しますが、この最初のバージョンのレイアウトでは編集できません。 それらは編集不可能で、40％の不透明度で表示されます。
  
  

レイアウトの変更

私はフローがどのように見えるかを調べました：

プロトタイプを見る

内訳

待ってください、私は複数のページレイアウトを持つことができますか？
うん！ それらを積み重ねて、好きなように組み合わせることができます。

ばかげてみませんか？
ええ、それは可能です。 ただし、ほとんどの場合、おそらくそうではありません。 上書きまたは追加のいずれかについて明示することは、人々がコンテンツを失う可能性が低いことを意味します。 ブロックの削除は簡単なので、追加して古いブロックを削除したい場合は、1、2回クリックするだけです。

コンテンツを上書きするつもりがなかった場合はどうなりますか？
「元に戻す」を応援してください。

機能画像やページタイトルなどのページ固有の要素はどうですか？
レイアウトを追加する場合は、ページ固有の要素を最も近い一般的な要素に変換する必要があります。 例えば：

• 注目の画像→画像
• ページタイトル→ヘッダー

重複ブロックはどうですか？
特定のブロック（最新の投稿など）が重複している場合は、それを許可する必要があります—人々は別のカテゴリの投稿の別のブロックを表示したい場合があります。

一般的なブロックは、心ゆくまで複製できます。

別のレイアウトを追加した後、レイアウトを何と呼びますか？
これを「カスタムレイアウト」と呼び、変更内容に基づいてプレビュー画像を再レンダリングする必要があります。

これらのモックは1年以上前のものであるため、古いものがたくさんありますが、いくつかの概念を再利用できる可能性があります。

ここで素晴らしい議論を始めてくれてありがとう。 これにより、ページレイアウトがさらにシンプルになると強く感じており、着陸するのが待ちきれません。

また、次の理由から、ブロックライブラリの横にボタンを追加するべきではないと強く感じています。

• それは、ページに何かを挿入するための唯一の場所として、ブロックライブラリを希釈して断片化します
• 挿入して学習し、モバイルとデスクトップ間でアクセス可能にして機能するためのUIを追加します
• すでに混雑している場所に追加されるので、追加するのではなく、間違いなく減らす必要があります。
• それは「パターン」を「ブロック」から分離し、おそらく同じである可能性がある場合に、異なるタイプのコンテンツを効果的に作成します

_ブロックUIを習得したら、すべてを実行する方法を習得します_。これは早い段階からの指針であり、まだ改良する必要がありますが、比較的適切に拡張されています。 ちょうど昨日、_site自体_をブロック（＃16998）として扱うことが、既存のUIを再利用するときにどのように役立つかについて説明しました。 「ブロックパターン」を新しい機能として扱うのではなく、_事前に設計され、子ブロックが内部にある別のブロック_として扱う場合、突然、それは新しい機能ではなく、_既存の機能の改良版_になります。これは、範囲的には実用的かつ賢明なようです。

私には、ブロックライブラリはこのインターフェイスの明らかな場所のようです。 ブロックパターンにうまく対応するために、どのような変更を加えることができますか？ それはすでに再利用可能なブロック、おそらくこれらのようなパターンの前兆を含んでおり、私たちが行う改善はそれらにも利益をもたらす可能性があります。 [ブロックパターン]タブはありますか？ ブロックライブラリの幅は広いですか？ブロックライブラリと新しいプレビューペインを合わせた幅と同じですか？ ブロックパターンには別のプレビューウィンドウが必要ですか、それともそのプレビューペインの余分なスペースを活用できますか？

もう1つの演習は、質問をひっくり返すことです。ブロックパターン用の新しいUIが必要であることを示唆する、現在存在するブロックライブラリについてはどうでしょうか。

別のインターフェース、そしてメルはこれに非常にエレガントに触れていますが、プレースホルダーインターフェースを利用することです。 Siteブロックで、デフォルトでベーステンプレートを選択できる場合はどうなりますか？

以下は、間違いなく明らかなように、例外的に考慮されたアイデアではなく、ブロックライブラリに「タイプセレクタ」ドロップダウンを追加して、ブロックとブロックパターンの両方を一緒に検索できるようにした場合の外観を示す簡単なスケッチです。 ：

私には、ブロックライブラリはこのインターフェイスの明らかな場所のようです。 ブロックパターンにうまく対応するために、どのような変更を加えることができますか？

ダイビングしてくれてありがとう、@ jasmussen！ その質問を理解することが重要です。 最近、Happiness Engineersは、一部のユーザーはブロックライブラリをスクロールして、前面と中央以外のブロックを見つけることすらしないと共有しました。 これは別の問題ですが、この非常に小さなインターフェイスに他のものを追加することに関して考慮すべきことがあります。

ブロックパターン用の新しいUIが必要であることを示唆する、現在存在するブロックライブラリについてはどうでしょうか。

そこにフルページのブロックパターンを追加するのが難しいのは、ブロックライブラリのサイズそのものだと思います。 現在、ユーザーはブロックアイコンとブロックの小さなプレビューを表示しています。 フォーカスされているのはページの小さな領域であるため、機能します。 ブロックパターンは、ユーザーがページの_ほとんど_と、これらのブロックがどのように共存しているかを確認できる場合に、はるかにうまく機能します。 ライブラリのサイズがこれを難しくしています。

「サイトブロック」の概念はかなり興味深いように聞こえます。 多くのブロックにはプレースホルダーがあるため、サイトブロックにもレイアウトオプション付きのプレースホルダーを含めることができる場合があります。 このアイデアは新しいページではうまく機能しますが、既存のコンテンツがあるページではあまり機能しません。 しかし、とにかくこれに関する簡単なモックアップがあります。

ブロックプレースホルダー（参照用）：

サイトブロックプレースホルダー：

これは、上記の@melchoyceのモックアップと本当に相性が

良い考え、ありがとう。

最近、Happiness Engineersは、一部のユーザーはブロックライブラリをスクロールして、前面と中央以外のブロックを見つけることすらしないと共有しました。

これは良い洞察であり、ブロックパターン用に作成した改善されたデザインとともにブロックライブラリを改善する理由はなおさらです。

そこにフルページのブロックパターンを追加するのが難しいのは、ブロックライブラリのサイズそのものだと思います。

それは真実です。 そのフィードバックに基づいて少し時間をかけてモックアップを試みましたが、これを単一のブロックライブラリのアイデアと組み合わせました。 このモックアップの忠実度の高さにあまり重きを置かないでください。これは私の快適ゾーンであり、「リアルに感じる」方法でもあります。 つまり、_完了_に見えるからといって、それ以上のフィードバックに基づいて拒否できないという意味ではありません。

ここに表示されているのは、 (+) Add Blockボタンを押したのと同じ単一のブロックライブラリです。 これにより、エディターバー、ドキュメントの最後、新しい段落を作成するとき、または兄弟インサーターを探すときに使用できるようになります。

UIは私たちが持っているものに基づいていますが、検索フィールドに加えて2つのタブが追加されています。

• [ブロック]タブがデフォルトであり、コンテンツは現在の内容です
• [ブロックパターン]タブはその横にあり、個別のプレビューペインを表示する代わりに、レンダリングされたプレビューをブロックパターンのサムネイルとして表示します。
  
  
  
  • _categoryドロップダウン_があります。これは、プラグインが提供物を分類するための良い方法です。
  
  
  • サムネイルの幅は固定されていますが（2列）、高さはさまざまで、石積みスタイルです。
  
  
  • ポップアウトウィンドウ全体が大きくなり、プレビューペインを表示しないことで、さらに多くのスペースを確保できます。 利用可能な画面の領域に応じてドロップダウンのサイズを変更するためのレスポンシブトリックを探索することもできます。
  
  
• 検索するときは、ブロックとブロックパターンの両方を検索します。
  
  
  
  • ブロック結果は個別にグループ化され、最初に表示されます
  
  
  • ブロックパターンの結果はその下に表示されます
  
  

繰り返しますが、これは忠実度が高いように見えますが、福音と見なすべきではありません。 単に会話を促進することを目的としています。 私はフルサイト編集のための@shaunandrewsの仕事のいくつかに触発されました、そして彼も共有する考えを持っていると確信しています。

お役に立てれば！ 考え？

さて、上記の調査に基づいて、これを2つのタスクに分解していることがわかります。

1. 新しいページを作成するときのページレイアウトのプレビューと選択
2. その後、インサーターを介して新しいブロックパターンを追加します

@jasmussenには、 https： //github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480にいくつかの優れたインサーター探索があり、インサーターに対して繰り返すことができます。

@shaunandrewsはまた、彼がWordPress.comのために取り組んでいるというこのアイデアを

新しいページを作成すると、レイアウトを選択するオプションが表示されます。 プレビューは、 @ mapkも私もまだ調べていない素晴らしい追加です。

私たちが考えるべき1つの質問：ページ全体のレイアウトは、投稿ではなくページに対して行われるべきですか？

フルページレイアウトは、投稿ではなくページに対してのみ発生する必要がありますか？

1つの側面はデフォルトであり、もう1つの側面は技術的な違いです。 つまり、内部的には同じであるため、おそらく技術的には些細なことです。したがって、何を許可するかを決定するだけの問題です。 どこでも許可することの利点は、どこでも同じである予測可能なフローであるということです。 欠点は、ブログホームページテンプレートを使用する新しい投稿を作成してほしくないことです。

おそらく、テンプレートは、登録されると、どの分類法を許可するかを自分で決定しますか？

おそらく、テンプレートは、登録されると、どの分類法を許可するかを自分で決定しますか？

良いアイデア—テンプレートは、カテゴリ/タグ、およびCPTにも使用できます。

（分類ページのテンプレートピッカーはかっこいいかもしれません！）

ブロックパターン（コンテンツのセクション）に正直に関連している友人は、兄弟インサーター、ブロック間のホバーに表示されるプラスについていくつかの考えを共有し、ブロックが選択されたときに常に表示されているとより使いやすくなると述べました。 現在これが当てはまらない理由は、テキストをクリックして編集したいだけでなく、スペーサーブロックとカバーブロックにあるサイズ変更コントロールと競合するためです。 ここで重要なのは、_すべてがブロック_であるということです。

GoDaddyサイトビルダーのスクリーンショットがいくつか共有されました。同様のインターフェイスが存在し、選択すると永続的に表示されます。 主な違いは、このUIが小さなブロック（テキスト、画像）と大きなセクションを区別し、後者でのみこのコントロールを表示することです。

ブロックパターンを続けていく中で、この概念が、より大きなセクションに機能を追加する際に、ベースUIをさらに簡素化するための扉を開くかどうかを考えるのは興味深いことです。

@jasmussen https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480のファイルを取得できますか？

はい、もちろん。 面倒なFigmaファイルにすばやくまとめたので、ここにコピーしました。

https://www.figma.com/file/VaSKQJDS70ov87XY1alOVs/Block-Library-w.-Block-Patterns?node-id=0%3A1

ありがとう！

いくつかのアイデアをいじっています：

ドロップダウンのアイデアから始めて、ブロックの単一のリストを試しました。

これに加えて、リスト内のパターンにサムネイルを使用して、パターンに2列と1列の両方を試しました。

それから私は検索が混乱している場所にあると判断し、一歩後退しました。 検索の横にドロップダウンを追加し、検索の下にタブを追加してみました。

検索の下にあるタブを使用して、横向きと縦向きの両方でパターンのサムネイルを表示してみました。

@joenがパターンのより興味深いレイアウトで行ったことを気に入っているので、それを使って簡単なモックアップも試しました。

素晴らしい探検。 検索の横にあるドロップダウンを使用すると、2つが結びついているように見えるため、タブはパターンとして少しうまく機能すると思います。たとえば、パターンまたはテンプレート内でのみ検索でき、1​​つを選択してビューを変更することはできません。

私はこの号を読むことを完全に楽しんだ、アイデアは読んで見栄えがする！

完全なサイト編集を可能にするために必要なブロックタイプとインフラストラクチャをそれぞれ提供することに焦点を当てている関連する問題＃15623と＃17512にフラグを立てたいと思います。

ここで説明するブロックパターンは両方のコンテキスト（個々の投稿とテンプレート全体）で意味がありますが、2つのタイプのテンプレートを区別する必要があると思います。

• テンプレートパーツ（たとえば、フルサイト編集プラグインが行うのと同様に、内部的にwp_template_part投稿タイプで実装されます）：
  
  
  
  • テンプレートパーツはさまざまな場所で使用できる必要があり、他のコンテンツに追加できる必要があります（前述のとおり）。
  
  
• テンプレート（たとえば、内部的にwp_template投稿タイプで実装されます。＃17513を参照してください）：
  
  
  
  • テンプレートは、HTMLドキュメントを構成するすべてのセマンティックマークアップを含む_全体_テンプレートを表すことになっています。 これらの配置方法にはいくつかの制限が必要です。たとえば、完全なテンプレートは個々の投稿コンテンツでは意味がありません。また、完全なテンプレートを別の場所に追加することはできません。完全なテンプレートは常に既存のコンテンツとその主な使用例は、グーテンベルクで新しいテンプレートを作成する最初の段階です（つまり、「開始点を選択する」）。
  
  
  • （前述の問題を介して）確実なセマンティックマークアップを一般的に奨励（実施？）する方法を理解する必要がありますが、ここでもこのシナリオを検討する必要があると思います。
  
  

これまでのところ、この問題は主にテンプレートパーツに焦点を当てているようで、それは理にかなっていますが、将来的にそれを完全なテンプレートに拡張する方法についても考えることができれば素晴らしいと思います。

これまでのところ、この問題は主にテンプレートパーツに焦点を当てているようで、それは理にかなっていますが、将来的にそれを完全なテンプレートに拡張する方法についても考えることができれば素晴らしいと思います。

1つの明確化—「ブロックパターン」の設定は、テンプレートパーツ（構造的に意味のあるもの）ではなく、より小さなブロックで作成された一般的な設計要素に関するものです。 挿入されると、それらは個別に保存されません。 たとえば、いくつかのブロックを組み合わせて特定の外観を実現する「カバー」画像は、そうでなければユーザーが達成するためにいくつかの作業を必要とします。 テーマテンプレートの再利用可能な部分を必ずしも表すことなく、どこにでも追加できるデザインのコレクションと考えてください。

@shaunandrews 'と@jasmussen 'のアイデアを取り入れて、ポップオーバーではなくモーダルに適用する、迅速で汚い探索：

私はタブと検索レイアウトを掘り下げますが、私は個人的にブロックライブラリの検索を_常に_使用していることを認めなければならないので、1つのデータポイントとして、最初に検索を好みます。

モーダルダイアログインサーターは間違いなくスペースをもたらします。 それは良い。 ただし、カーソルがどこにあるか、ブロックまたはブロックパターンが挿入される場所の視覚的なコンテキストも少し失われます。 さらに、これがブロックインサーターのグローバルな動作になるのか、たとえば、兄弟インサーターまたは上記の「セクションインサーター」のようなバリアントを使用したときに表示されるものになるのかという疑問が生じます。 そして、動作を_do_フラグメント化する場合、それは良いことですか？

そこでのあなたの探検、 @ melchoyceは本当に役に立ちます！ ありがとう！ 私はこれについていくつか考えています。

ある例では、モーダルは利用可能な多くのブロックを伝達します。これは、人々が現在探索するのに苦労していることです。 しかし一方で、このようにこれらすべてのブロックを見ると、少し圧倒されます。 モーダルはパターンには適していますが、個々のブロックには適していません。 ただし、モックアップにはアコーディオンが開いていることも示されているため、デフォルトのように1つだけ開いていると表示すると、完全に変わる可能性があります。

ダイアログバージョンの追加されたスペースが好きで、その上で眠っているのと同じくらい、それは私にとって正しいアプローチのようには感じません。 コンテンツからすべてのコンテキストを削除し、段落や画像などの単純なブロックを挿入するときに圧倒されます。 事前に作成されたブロック、またはブロックパターンについて、私はますます同じように感じています。これらは単なるブロックのコレクションであり、同じ方法で挿入する必要があります。

https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480が必ずしも進むべき道ではありませんが、カテゴリは無意味に感じ始め、多くのことが起こっています—私は_ブロックを改善していると感じています複雑なブロックに対応するためのライブラリ_（そしてモーダルダイアログを回避する）が進むべき道です。

複雑なブロックに対応するためにブロックライブラリを改善する（そしてモーダルダイアログを回避する）ことが道のりだと思います。

ライブラリ内により多くのスペースを提供するヘルプパネルができたので、おそらくそれを少し操作することができます。 パターンは個々のブロックから分離する別のタブかもしれませんが、プレビュー領域はヘルプパネル側に残り、必要に応じて垂直方向にスクロールできます。

「ブロックパターン」のアイデアは好きですが（「ブロックレイアウト」に変更する必要があるかもしれません）、ダイアログボックスを使用して新しいブロックを追加するのは好きではありません。気が散りすぎます。 （この方法でブロックパターンを追加する場合は、問題ありません。）

ブロックインサーターは（今日のように）小さなポップオーバーのままにすることをお勧めしますが、ブロックパターンは完全に異なるコンポーネントである必要があります-それぞれが使用されるコンテキストは非常によく異なる可能性があります：ページ（パターン）を構築するためのもの-ブロックを追加したり、それらのページを微調整したりするためのもう1つ。

インサーター内では機能する可能性がありますが、インターフェースがより複雑で混乱する可能性があります。言うまでもなく、インサーターは非常に小さいものです。 パターンの小さなプレビューを取り込むことは、最高のエクスペリエンスではない場合があります。 （ユーザーが選択できる適切なコンテキストを提供するために）複数のパターンを表示できる必要がありますが、プレビューを実際に表示できる大きさにする必要もあります。

おそらく、私たちは物事のやり方を少し微調整します。

ここで声を出して考えますが、今日のように左上にインサーターがあり導入するとどうなりますか？人々はブロックパターン/レイアウト（私たちがそれらと呼ぶもの）を追加できます。 これにより、現在ブロック間に存在するオンホバーブロックインサーター（+）が置き換えられ、表示されたままになります（ホバーされていないときに非表示になりません）。

これは、次のようなスクリーンショット（_実際のグーテンベルクのコンテンツを含む_）です。

正確にこれが引き継ぐ場所の背後にあるいくつかの考えが必要になるでしょう。 それはすべてのブロックの間にありますか？ よく分かりません。

パターンインサーターを開くと、ユーザーがページに追加する新しいパターンを選択できるモーダルが起動します。 これは、トップレベルのカテゴリ選択を使用したモーダルの調査ですが、これがどのようになるかについては100％ではありません。

このパターン（または少なくともその一部）は、GoDaddyのWebサイト+マーケティングオファリング、およびSquareSpace（および場合によっては他の場所）で見られます。 探索する価値があります。

ブロックとレイアウトは異なる必要があります。

レイアウトは、使用しているcssフレームワークを活用する必要があります。

レイアウトの例：

• 列行
• グリッド
• スライダー
• コンテナ
• タブ、アコーディオン

ブロックはレイアウト内に存在する場合と存在しない場合があります。

パターンはレイアウト+ブロックかもしれませんか？

Blocsアプリがこれを行う方法は次のとおりです。 それははるかに大きなインサーターを使用します。 より多くの研究を共有するだけです。

他の人がそこで何をしているのかをもっと見てください。

Qubelyは、トップツールバーのボタンを使用してモーダルを開きます。

素晴らしいシェア、マーク。

Qubelyのアプローチは避けるべきだと私が思うアプローチであり、他の多くのブロックコレクションが採用しているアプローチであることに注意してください。 このアプローチは、ユーザーがデスクトップ画面を使用していて、「トップツールバー」オプション、または将来の「すべてのアイコンのラベルを表示する」オプションを使用していないことを前提としています。 したがって、実際の個別のボタンを追加する場合は、ブロックインサーターの直接のコンテキストで追加する可能性があり、そのスペースに存在する他のボタンをどのように減らすことができるかを検討する必要があります。

そして、これがSquareSpaceがページアーキテクトとコンテンツ編集のために別々のインタラクションを持って、私の以前のコメントにコンテキストを提供します。

そして、これが昨日のデザインミーティングで話し合っ

私はパターンの相互作用とブロックの相互作用について多くのことを考えてきました。 ブロックを「追加/調整」インタラクションとして維持しながら、パターンを最上位の「構築」インタラクションとして移動します。 確かに、ブロックを使用して「パターン」を構築することはできますが、それは正確には単純ではなく、実行するにはさらに多くの対話が必要です。 では、ページアーキテクトとコンテンツアーキテクトの間に明確な違いがあったとしたらどうでしょうか。

それを共有してくれてありがとう、リッチ。 歩き方のバランスは、ユーザーがコンテンツの大きな役立つセクションを挿入して、必要なときにページをすばやく構築するのを簡単にすることと、必要なときに個々のブロックに簡単に直感的にアクセスできるようにすることのバランスにあるようです。

私にとって、Squarespace GIFからの重要なポイントは、2つのライブラリ間に二重性が存在する一方で、それは_contextuality_によって抑制されるということです。 しかし、2つの完全に異なる外観のブロックライブラリを回避するために、さらに改善できるかどうか疑問に思います。 たとえば、_Navigation Menu_ブロックを挿入すると、ブロックライブラリが_MenuItems_のみを内部に挿入するツールになるのは直感的です。 編集キャンバス自体でコンテキストを活用する同様の方法はありますか？

レイアウトを追加する方法については、おそらく[ドキュメント]タブの[設定]領域に、レイアウトが大まかにどのように見えるかをユーザーに示すグラフィックを含むレイアウトのリストがありますか？

Atomic Blocksにはしばらくの間、セクションとレイアウトのモーダルがありました。これまでに経験したことを共有できてうれしいです。

@mapkの質問について詳しく説明するには：

1. はい、ブロックエディタには、ブロックパターン/セクション/レイアウトまたはそれらを呼び出したいものを操作するための専用UIが必要です。 個々のブロックの後の次の論理的なステップは、それらを組み合わせてモダンで表現力豊かなレイアウトを作成する方法です。 このための標準化されたUIを作成することで、ユーザーと開発者はまとまりのあるエクスペリエンスを楽しむことができ、（すでに始まっている）車輪の再発明を何百万回も回避できます。 Atomic Blocksや他のいくつかのUIにはすでに専用のUIがありますが、これには標準の（ただし拡張可能な）UIを採用したいと思います。

コアがこのUIにデータを入力するためのブロックパターンを提供するかどうかは別の問題です。 コアテーマが、デザインを補完および拡張するための意見のあるブロックパターンを提供することは理にかなっています。

1. ここで提案されているUIのいくつかは素晴らしいスタートです。 私はここで@shaunandrewsと@melchoyceから見ているものが特に好きです。 ブロックインサーターがこのような機能には制限が多すぎるという

UIのセクションとレイアウトの違いを区別しました。セクションはページの一部であり、レイアウトはフルページレイアウトです。 これは意見の分かれる決定であり、現在の実装では理にかなっていますが、代わりにカテゴリまたはフィルタリングインターフェイスを使用して対処することもできます。

Atomic Blocksには、ユーザーが頻繁に使用するセクションやレイアウトを簡単にお気に入りに追加して再訪できるお気に入り機能もあります。 パターンの量が急速に増えるため、この種の機能が必要になります。 ユーザーに権限を与える別の方法は、ホワイトリストとブラックリストのパターンがパターンUIの出力を制御できるようにすることです。

ブロックエディターの力は、ブロックテンプレートやブロックパターンなどの機能で最も明白に検証されます。これらの機能は、WordPressでのWebサイトの構築方法を根本的に変えます。 また、カスタムWordPressインターフェースの西部を囲い込み、標準化により、よりまとまりのある予測可能なエクスペリエンスの提供を開始する機会もあります。

過去のアイデアに対処しようとする

次のモックアップでは、次の方法でこれに対処しようとしました。

• タブ付きの単一の統合ライブラリインターフェイスの作成
• エディタバーから開いたときに、このインターフェイスをポップオーバーとして表示します。フルハイトですが、モーダルではありません。
• 兄弟インサーターから開いたときに、デフォルトで[パターン]タブになっているダイアログとして表示します

_このUIは、＃18667で検討されている未完成のUIの概念を活用していることに注意してください。_

この構成では、ユーザーはさまざまなインターフェイスを調べなくてもブロックまたはパターンを挿入できますが、より大きなパターンの挿入を検討する場合は、より多くの画面スペースが必要になる可能性があることを認識しています。

このインターフェースは、ここで提案されている新しいカテゴリーの言い回しも活用してい

• 兄弟インサーターから開いたときに、デフォルトで[パターン]タブになっているダイアログとして表示します

私たちはここで何かに取り組んでいると思います！

@jasmussen 、パターンは/にも表示されますか、それともブロックだけで表示されますか？

それは素晴らしい質問です。 たぶん別々に分類された場合。 しかし、パターンには大きなプレビューがもっと必要なのでしょうか？ 「2つのパターンが見つかりました」はダイアログを呼び出すことができますか？

@jasmussen 、パターンは/にも表示されますか、それともブロックだけで表示されますか？

おそらく。 プレビューがない場合でも、 /内にそれらを含めることがどれほど役立つかはわかりません-非常に一意の名前が付けられていない限り（「約1」、「約2」など）または、ユーザーが適切と思われるタイトルを付けることができるかどうか（それについても100％確信が持てない）。

@mikemcalisterがこのスレッドの前半で述べたように、「お気に入り」機能を実装すると、おそらくお気に入りのパターンのみが表示されます（明確に識別できる限り）。 そして、それらを許可する場合、パターンには対応するアイコン（ブロックと同様）が必要ですか？ または、ブロックパターンを分類するためのデフォルトの「パターン」アイコンがありますか？

ねえ、私はただ頭を突っ込んで、これが向かっているところが大好きだと言いたかっただけです。 最新のモックアップと考え方は素晴らしいです。 これがネイティブモバイルGutenbergにどのように変換されるかを考えているので、 @ lumbermanによる最後のモックアップは

アコーディオン/ナビゲーション階層について

私がインサーターでいつも抱えていた問題の1つは、アコーディオンセクション（最もよく使われる、一般的なブロックなど）です。 最初のセクション「最も使用されている」は、最初は常に開いているため十分に明確ですが、追加のセクションが埋もれてしまい、特にモバイルでの検索が妨げられる傾向があります。

私は、最後のモックアップである@lumbermanで左側のサイドバーがどのように配置されているかが好きです。 左側のサイドバーのナビゲーション階層にリストアイテムとしてセクションを追加するのは理にかなっていると思いますか？ つまり、 Sections下のアイテムは、「最も使用されている」、「ヘッダー」、「フッター」など（またはグループの名前が最終的にどのようなものであっても）になりますか？ それは「埋もれたセクション」の懸念を解決し、アコーディオンの必要性を本質的に取り除くことを可能にするかもしれませんが、これは歴史的にブロックライブラリからの大きな相違であるため、他の人はこの提案を気に入らないかもしれません😄

「お気に入り」について

（ @mikemcalisterが最初に信じている）議論されている概念の1つは、「お気に入り」の概念です。 これは、ネイティブモバイルGBでしばらく前に検討したアイデアとほぼ同じです。ここでは、

ブロックライブラリ、Overwhelm、IAなど。

インサーター全般に関して私が繰り返し耳にすることが1つあります。それは、堅牢性を高めるにつれてさらに明確になります。 モバイルWebのユーザビリティテスト中に、私たち（Automatticのモバイルチーム）は、ブロックライブラリが圧倒的であるとよく耳にしました。 選択肢はたくさんあり、グループ化はすぐには明確ではありません。 ここで提案された新しいUIのアイデアは、もう少し「呼吸」するので役立つと思いますが、ブロックの数は依然として圧倒的であり、別のグループ（ブロックパターン）の導入によってのみ悪化します。 これをスケールアップすると（これは正しい方向だと思いますが、「お気に入り」タイプの能力がそれを軽減する可能性があると思います。

ページレイアウトに対するMobiriseのアプローチを検討する価値は十分にあります。 それらは、左側にキャンバスを提供し、右側に垂直パネル選択スライダーを提供して、自然な垂直ページ要素にセグメント化します...トップバー、トップメニュー、ビジネス機能ごとのボディパネルのいくつかのパネル選択（テーマとページタイプ（例：マップパネル、[会社概要]ページの場合は人パネル）、フッター、フッターバーの順に、パネルを右から左にドラッグアンドドロップするだけです。

警告：Gutenbergの寄稿者である場合は、Mobiriseの資料を熟読することを決定する前に、 Mobiriseの用語を読んで

お客様は、次のことを行わないことを表明および保証します。サービスのコピー、変更、派生物の作成、適合、リバースエンジニアリング、エミュレート、別のサービスへの移行、サービスの翻訳、コンパイル、逆コンパイル、または逆アセンブル。

さらに良いことに...彼らのウェブサイトにはまったくアクセスしないでください。

代わりに、MobiriseのYouTubeビデオを見ることを検討してください。 YouTubeがコンテンツアップローダーに要求するライセンスを超えて延長される用語の行き過ぎについては知りませんが、Caveat Emptor ...私は弁護士ではありません。

YouTubeビデオの視聴がグーテンベルクIPのリスクではないと思われる場合は、MobiriseYoutubeチャンネルがhttps://www.youtube.com/channel/UCt_tncVAetpK5JeM8L-8jyw/featuredにあります。 ドラッグアンドドロップパネルの動作により、テーマ固有のページ構築を確認できます。

@jasmussen 、ここのモックアップは見栄えがします。 😍可能であれば、以下の私の質問のいくつかに答えることができるかもしれない実用的なプロトタイプでそれらを見てみたいです。

@richtaborで示されている兄弟インサーターからパターンを追加するのではなく、誰かがツールバーからブロックを追加しているときのコンテキストを変更することは理にかなっています。 パターンのモーダルで余分なスペースが与えられるのが好きです！

次のステップ

1. 「既製のブロック」という用語は少しぎこちなく感じます。 そこで「ブロックパターン」を試すことはできますか、それとも同じようにぎこちなく感じますか？
2. トップツールバーのインサーターをクリックしてから[ブロックパターン]タブをクリックすると、どのように表示されますか？ ポップオーバーはモーダルに移行しますか？ ポップオーバーはサイズを変更しますが、同じ位置にポップオーバーのままですか？ 同じサイズと位置を維持し、パターンを表示するだけですか？
3. エディタ内の兄弟インサータをクリックしてから[ブロック]タブをクリックすると、インタラクションはどのようになりますか？ ここからモーダルのサイズや位置が変わりますか、それともモーダルのままですか？
   
   
   
   1. これらの質問に答えるプロトタイプを作成します。 ファイルをリンクしていただければ、喜んでお手伝いさせていただきます。
   
   

@lumbermanもモックアップをありがとう！ 彼らが既存のインサーターデザインをどのように利用し、その上に構築するかが本当に好きです。 👍アコーディオンの量を減らす方法はありますか？ スライドして開くことができるものがたくさんあるように感じます。 現在、ユーザビリティテストにより、人々は私たちがすでに持っているアコーディオンをクリックしていないことが明らかになりました。

「既製のブロック」という用語は少しぎこちなく感じます。 そこで「ブロックパターン」を試すことはできますか、それとも同じようにぎこちなく感じますか？

はい、間違いなくブロックパターンを試してみましょう。

個人的にはこの用語の方が扱いにくいと思いますが、デザインチャットなどで議論されており、プラグインで試してみるコストも少ないので、やめない理由はありません！ 完璧に感じるかもしれませんし、微調整が必​​要であると明らかになるかもしれません。もう一度説明します。

トップツールバーのインサーターをクリックしてから[ブロックパターン]タブをクリックすると、どのように表示されますか？ ポップオーバーはモーダルに移行しますか？ ポップオーバーはサイズを変更しますが、同じ位置にポップオーバーのままですか？ 同じサイズと位置を維持し、パターンを表示するだけですか？

シフトは起こりません。 それは大きなモーダルと同じですが、より小さく/より狭いスペースにあります。 おそらく、そこにはブロックパターンの単一の列のためのスペースしかありません。

しかし、UIが同じで、ブロックとパターンの両方が両方の場所で利用できるので、それでも価値があると思います。

エディタ内の兄弟インサータをクリックしてから[ブロック]タブをクリックすると、インタラクションはどのようになりますか？ ここからモーダルのサイズや位置が変わりますか、それともモーダルのままですか？

PR /プロトタイプが答えるかもしれない良い質問。 変化がないことを想像します。ブロックを見るスペースがもっとあるということです。

これらの質問に答えるプロトタイプを作成します。 ファイルをリンクしていただければ、喜んでお手伝いさせていただきます。

これがFigmaファイルです： https ： id = 85％3A6975 —少し面倒ですが、助けが必要な場合は私にpingできます。

これは、皆さんが共有してきた優れたアイデアに基づいたいくつかの調査です。 私は意図的に、現在のブロックインサーターによって提供されるスペース内で作業するように自分自身を制約しました。 私は2つの理由でこれを行いました：

1. これにより、このUIを小さな画面に簡単に変換できるようになります。
2. 平均的な画面サイズについては、現在のインサーターはすでに十分な画面領域を占めていると思います。 ですから、より大きな中心のモーダルはあまりメリットがないと思います。

**上記は1200x800で撮影したスクリーンショットです。

ブロックインサーターのサイズの制約があることを考慮して、使用可能なスペースを可能な限り活用する方法を模索しました。 ヘルプパネルはブロックに対しては正常に機能しますが、ブロックパターンに対してより大きなサムネイルを表示しようとすると邪魔になります。 だから私はその内容を削除

これは次のようになります。

ブロックにフォーカス/ホバーすると、それに応じて下部のヒント「バンド」の内容が変わります。

基本的に私は物事を動かしているだけです：

ブロックプレビューは、現在のボタンよりも実際にはそれほど多くのスペースを必要とせず、行ごとに3つ以上を表示できるようになりました。

小さいサムネイルも表示してみましたが、プレビューが読みづらいと感じました。

上記のすべてで、ブロックパターンタブは次のようになります。

インサーターで使用可能なスペースを最大限に活用する、ブロックとブロックパターンの両方に使い慣れたUIを使用できます。

このエンリケに取り組んでくれてありがとう！

私は意図的に、現在のブロックインサーターによって提供されるスペース内で作業するように自分自身を制約しました。 私は2つの理由でこれを行いました：

• これにより、このUIを小さな画面に簡単に変換できるようになります。
• 平均的な画面サイズについては、現在のインサーターはすでに十分な画面領域を占めていると思います。 ですから、より大きな中心のモーダルはあまりメリットがないと思います。

私はこれに同意しません。 モーダルを電話（フルスクリーン）に変換する良い方法があり、2列と3列の代わりに1列のパターンを表示できます。

自分のデザインとあまり変わらないデザインを模索したと言っているので、過去の自分にも反対です。

私が気付いたのは、広大な甘美なブロックパターンを表示するには、取得できるすべてのスペースが必要であるということでした。 これは、 MarkとRichによって輪郭が描かれた点をつなぐことで、これらのモックアップが作成されました（ Figmaファイル）。

＃19836で、使用可能なすべての垂直スペースを占有し、ヘルプテキストを削除し、プレビューウィンドウを切り離すブロックライブラリを突き刺しました。 これは、全体的なアイデアのプロトタイプとして機能します。

エンリケ前に示した背の高い縦型モックアップにあなたのフィネスの一部をもたらすためにあなたと一緒に働きたいです。 これがFigmaファイルです： https ： id = 85％3A6975 —特にデスクトップブレークポイントではうまく機能しますが、モバイルブレークポイントはまだ具体化されていません。 それがまったく役に立ったら、私はいつもチャットもしています。

ねえ@jasmussen！ 👋

これは、背の高い垂直モックアップといくつかのブロックパターンプレビューを組み合わせた簡単なモックアップです。

私はそれが好きです。 大きなプレビューはこのサイズで気持ちがいいです。 私が抱えている問題の1つは、プレビューがこれほど大きい場合に、アコーディオンカテゴリがナビゲーションと発見可能性にうまく機能するかどうかわからないことです。

代わりに、カテゴリを横に配置するというアイデアを検討することに時間を費やしました。

これにより、利用可能なカテゴリのスキャンが簡単になると思いますが、ブロックパターンのカテゴリが大幅に減少し、これが正しいと思うかどうかはわかりません。

どう考えているか教えてください。

これは、背の高い垂直モックアップといくつかのブロックパターンプレビューを組み合わせた簡単なモックアップです。

これは恒星です！ 特に、垂直インターフェイスでパターンを確認することは非常に啓発的であり、私が想定していたよりもわずかにうまく機能します。

側面のカテゴリも悪くはありませんが、左上のポップオーバーバージョンではドロップダウンとして機能する方がよいのではないかと思いますが、兄弟インサーターによって開かれたダイアログバージョンではうまく機能する可能性がありますか？

これありがとう！ 他の人にもチャイムを鳴らします。

最近のモックアップを繰り返して、さらにいくつかの調査を行います。

1.ブロックおよびブロックパターンのタブ+カテゴリのリスト

2.ブロックおよびブロックパターンのタブ+カテゴリのドロップダウン

1は正しいと思います。 カテゴリのリストが完全に表示される方法が好きで（発見しやすいように）、これは適切に拡張できるはずです。

2は整理整頓されているように感じますが、カテゴリのリストがクリックの背後に隠れており、発見可能性に影響を与えているのではないかと心配しています。

@jasmussen @mapk @shaunandrewsどう思いますか？

1は正しいと思います。 カテゴリのリストが完全に表示される方法が好きで（発見しやすいように）、これは適切に拡張できるはずです。

2は整理整頓されているように感じますが、カテゴリのリストがクリックの背後に隠れており、発見可能性に影響を与えているのではないかと心配しています。

格好良い@enriquesanchez！ ナンバー1もそうだと感じています。

いくつかの考え：

a。 カテゴリのリストが非常に多い場合に何が起こるかについてのメカニズムを理解する必要があります。

b。 カテゴリはどのように注文する必要がありますか？ テーマ、次にプラグインを介した優先順位はありますか？ アルファベット順？ または組み合わせ？

c。 テーマが異なるカテゴリのパターンを登録している場合、そのパターンは「テーマから」カテゴリと、各パターンの指定されたカテゴリに表示されますか？

リッチのコメントと質問の反響、素晴らしい要約。 よくやった！

考慮すべきことの1つは、現在の論文によれば、ライブラリは兄弟インサーターから開くと大きなダイアログとして表示され、逆に左上から開くと小さいということです。 レスポンシブチャレンジで指示された場合は、デフォルトでサイドのカテゴリをデフォルトにし、ドロップダウンに折りたたむことができます。

b。 カテゴリはどのように注文する必要がありますか？ テーマ、次にプラグインを介した優先順位はありますか？ アルファベット順？ または組み合わせ？

おそらく、上部にあるいくつかの「祝福された」ものの組み合わせになり、次にアルファベット順になります。 プラグインがカテゴリに__Sweet Blocksまたは1. Sweet Blocksという名前を付けるまで。 _今_を考えすぎるリスクがあるように思われます。将来的に調整するのは簡単なので、最も簡単な解決策を採用し、必要に応じて微調整することもできます。

@ richtabor @ jasmussenすばらしいフィードバックをありがとうございます。

a。 カテゴリのリストが非常に多い場合に何が起こるかについてのメカニズムを理解する必要があります。

同意しました。 ブロックライブラリに同様の何かが必要であるかどうか、そしてそれから学ぶことができるかどうかはよくわかりません。

b。 カテゴリはどのように注文する必要がありますか？ テーマ、次にプラグインを介した優先順位はありますか？ アルファベット順？ または組み合わせ？

Joenの提案を繰り返します。 いくつかの初期順序を確立し、システムが故障した場合の反復を検討する必要があります。

c。 テーマが異なるカテゴリのパターンを登録している場合、そのパターンは「テーマから」カテゴリと、各パターンの指定されたカテゴリに表示されますか？

私の最初の反応はイエスです。 いくつかのパターンが異なるカテゴリに表示されることを期待しています。 大丈夫だと思います。 「テーマから」のカテゴリを持つというアイデアは決して最終的なものではありませんが、人々が自分のサイトを「デモのように」見せるための簡単な方法だと思いました。

これを繰り返し続けます。 ライブラリのルックアンドフィールをよりよく理解するために、いくつかのプロトタイプに取り組みます。

私は、mobiriseアプローチが現場で実用的であることに気づきました。 2つのブロックパネル選択列があります... 1つは共通のページカテゴリ（ヘッダー、メニュー、コンテンツ、フッターなど）の下にブロックパネルのサムネイルをグループ化し、隣接するカテゴリインデックスを使用して、すべてのカテゴリを表示し、に直接ジャンプできるようにします。関心のあるカテゴリ。

これを「THE」ソリューションとしてプッシュしないでください。 私はあなたがそれを例として役立つと思うかもしれないと思って、それからあなたがそれについて好きなこと/嫌いなことをあなたが望むデザインに翻訳します。

ただの提案:-)

もう一度やってくれてありがとう、@ enriquesanchez！

私も1番に賛成です。 リストを表示することで、ユーザーは目的の結果を得るために一連のクリックをジャンプする必要がなくなります。 Joenがレスポンシブ画面について提案したように折りたたむのは非常に興味深いことです。

現在グーテンベルクで長いリストを処理するメカニズムを知らないので、それを検討する必要があります。 タブを使用してブロックをパターンから分離することは、すでに役立ちます。 その1つに称賛！

「テーマから」は少し変な感じがします。 たぶん「テーマパターン」または単に「テーマ」または「テーマ：[テーマ名]」。 たぶん、これらは一番上に優先されるべきですか？ それらを「テーマ」カテゴリの下にまとめて、関連するカテゴリの下に公開しても問題ありません。 たぶんこれは「コレクション」のようなものになりますか？ https://github.com/WordPress/gutenberg/issues/19873

モックアップで、[パターン]タブが強調表示されていても、検索フィールドにブロックとパターンを検索できると表示されていることに気付きました。 これは正解？ または、[パターン]タブでブロックパターンに制限する必要がありますか？

これは、Obenlandが共有したワイヤーフレームの組み合わせです。
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -536109796

エンリケの一番のワイヤーフレームの提案：
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -582673937

既存のブロック領域と追加のオプションは次のとおりです。

[ブロックバリエーション]タブを選択すると、次のように変更できます。

編集：既存のインターフェースを使用しますが、追加のオプションのためにそれを拡張すると、今日のブロックの選択方法に一貫性が保たれます。 それでも、同じインサーター領域に移動してブロックを選択します。 ただし、今回は、ブロック（単一ブロック）->ブロックバリエーション（複数ブロック）->ページレイアウト（テンプレート）->サイトセクション（ヘッダー、フッターなど）から選択することもできます。

考慮すべきことの1つは、検索ボックスの配置と、それが意味することです。 最新のデザイン@enriquesanchezでは、上部のタブ（ブロックとパターン）ごとに検索ボックスが繰り返されるため、一度に1つのグループしか検索できないと思います。 ここでの私の最初の希望は、単一の入力を使用して、両方のブロックとパターンを検索できるようにすることでした。

おそらくそれは誤った希望であるか、検索入力がどのように機能するのか理解していないのかもしれません。

モックアップで、[パターン]タブが強調表示されていても、検索フィールドにブロックとパターンを検索できると表示されていることに気付きました。 これは正解？ または、[パターン]タブでブロックパターンに制限する必要がありますか？

最新のデザイン@enriquesanchezでは、上部のタブ（ブロックとパターン）ごとに検索ボックスが繰り返されるため、一度に1つのグループしか検索できないと思います。

@mapk @shaunandrewsフィードバックをありがとう！ 理由はわかりませんが、最初はタブの上に検索ボックスがあったため、途中で検索ボックスを移動しました（https://github.com/WordPress/gutenberg/issues/17335#issuecomment-575835877を参照）。

@shaunandrewsに同意します。検索入力は、

検索入力は、インサーターの最初の要素である必要があると思います（現在のように）。 インサーターを開いた後、最初に焦点を当てるのは効率的でグローバルです。

これがどのように見えるかも調べることができますか？ 検索クエリがブロックとパターンの両方の結果を返す場合、それはどのように見えますか？

この問題で調査されたように、ブロックライブラリのより大きなモーダルを提示した場合にブロックがどのように表示されるかを調べることに時間を費やしました。

この前のコメントの最初の例のように、私はカテゴリの左側のリストを持つことに傾倒し続けています

では、同じパターンをブロックに対して行った場合はどうなるでしょうか。 これは、現在のようにアコーディオンを使用することから離れることを意味します。 これは、ほとんどのカテゴリで、未使用のスペースがたくさんあることも意味します。

明らかに、これは理想的ではありません。

別の反復により、すべてのブロックカテゴリの連続リストを作成し、左側のリストにリンクを配置して、対応する場所にスクロールするというアイデアが生まれました。 このようなもの：

（リンクの1つをクリックする代わりに）先に進んでスクロールを開始すると、左側のリストのアクティブ状態がそれに応じて更新され、位置を伝達すると思います。

このソリューションはスペースをより有効に活用し、私が気に入っているものをいくつか保持しています。

1. すべてのカテゴリのリストは常に表示されます。つまり、発見可能性と探索にメリットがあります。
2. カテゴリアコーディオンを開くためにクリックする必要がなくなり、すべてのブロックのリストがスクロール可能になったため、ナビゲーションが簡単になりました。

みんなどう思いますか？

@enriquesanchez私はこの探検が大好きです。

1. この種のシナリオでプレビューを削除しますか？ （私は必ずしもそれに反対しているわけではなく、ただ好奇心が強いです）
2. カテゴリが長すぎるとどうなりますか？ （例：https：//d.pr/i/DSsHTW）。 それはただ新しい行に折り返されるでしょうか？ その場合、混乱が生じないように、カテゴリ間のスペースが広くなるようにします。
3. アコーディオンではなく、連続スクロールが大好きです。

よさそうだ。 しかし質問。 「ブロックパターン」の「ブロック」を明確にする必要がありますか？

フィードバックをありがとう@jwoldと@richtabor👍

この種のシナリオでプレビューを削除しますか？

私はそれに傾いていますが、ブロックだけです。 プレビューはパターンに非常に役立つようです。 また、ブロック=小さなアイコン、パターン=大きなサムネイルの両方の視覚的な違いも気に入っています。

カテゴリが長すぎるとどうなりますか？

私は同意します、彼らは次のようなものをラップします：

アコーディオンではなく、連続スクロールが大好きです。

🙌

しかし質問。 「ブロックパターン」の「ブロック」を明確にする必要がありますか？

@richtaborそれは良い質問です。 では、「ブロック」と「パターン」を使用することをお勧めしますか？

ところで、パターンはバリエーションに名前が変更されたと思います。

ところで、パターンはバリエーションに名前が変更されたと思います。

バリエーションはパターンとは関係ありません。これはビルディングブロックの技術的な部分であり、UIで用語として公開されていません。

兄弟インサーター（ドキュメントの途中）から呼び出されたときのブロックライブラリのさまざまなバリエーションを調べました。

1.ポップオーバー

これは私たちが現在持っているものと非常に似ていますが、少し大きくなっています。

2.ビッグモーダル

パターンをナビゲートしやすくする必要があります。 それがその背後にあるコンテンツをカバーしているという事実が好きかどうかはわかりません。

3.スライドインパネル

@mapkによって提案されました。 サイズと配置の点でhttps://github.com/WordPress/gutenberg/issues/17335#issuecomment-585425675と非常によく似てい

これは、すべてをまとめた単純なクリックスルーのFigmaプロトタイプです。

上部のツールバーからブロックライブラリを開き、ブロックタブとブロックパターンタブを切り替えて検索してみてください。 最後に、ドキュメントインサーターの兄弟または途中からブロックライブラリを開いてみてください。

❗️_注：ブロックとパターンの挿入は、プロトタイプではまだ利用できません。_

ちょっとエンリケ@enriquesanchez

単純なFigmaプロトタイプを持つことは、本当に大きな違いを生みます。 完成したバージョンがどのように感じられるかを実際に感じさせるからです。

[ブロック]画面には、現在存在するものの概要が表示されます。 アコーディオンを開いてどのブロックが含まれているかを確認しなくても、使用可能なブロックを簡単に確認できます。 利用可能なスペースもあります。

土曜日の朝の目と心の運動... :)
心/目は、対称性とバランスを含む最も使用されている一般的なブロック領域に気づきながら動き回ります。

目が左にさまよっていると、リストが下に向かって「最も使用されている」から始まり、「埋め込み」で終わるのがわかります。

最もよく使われるのは青です。 その上には別の青い色があり、Blocksの太字のテキストの下に線が引かれています（Blocksの単語から遠く離れているため、青い線がなぜそこにあるのかわかりません。論理的には理由がわかります）。 右側には太字ではなく、下に線がないブロックパターン。 以下は、最もよく使用される太字のテキストです。 私の頭のさらに上には、ボックスの境界線の輪郭とその中の検索テキストが表示され、もう一度リラックスすることができます。

つまり、それぞれの小さな要素と、それらが近くにあるものとそれが含まれる全体的な領域とどのように関連しているかを調べることを意味します。

こんにちは。

ブロックパターンのテキストベースのプレゼンテーションのための余地がなければなりません。
すべてのユーザーがプレビュー画像の助けになるわけではありません。

フィードバック@paaljoachimと@carolinanをありがとう！ 🙏

ブロックパターンのテキストベースのプレゼンテーションのための余地がなければなりません。

仰るとおりです。 ホバー時のブロック/パターンの説明など、プロトタイプに忠実度を追加します。これらの説明がATに確実に伝達されるようにする必要があります。

2.ビッグモーダル

パターンをナビゲートしやすくする必要があります。 それがその背後にあるコンテンツをカバーしているという事実が好きかどうかはわかりません。

兄弟インサーターにとって、これは最も自然な感じですが、hi-fiモックアップは私たちがより良い判断をするのに役立つかもしれません。 おそらく、コアモーダルダークバックグラウンドを実行すると、モーダルに焦点を合わせるのに役立ちます（下の写真）。

ユーザーが個々のパターンを適切に理解するのに十分な表示スペースを提供します。これにより、ページに何が追加されるかをより明確に把握できます。 パターンを2列幅に保つこともできます。これにより、パターンが適切に表示されるようになります。

3.スライドインパネル

@mapkによって提案されました。 サイズと配置の点で＃17335（コメント）と非常に似ています。 スライドインがトップツールバーと兄弟インサーターの両方のデフォルトパターンになるのではないかと思います🤔

これは興味深いですが、兄弟のインサーターから切り離されすぎているように感じます。 とにかくその背後にあるコンテンツ/サイトの表示をブロックしている場合は、完全なモーダルを選択すると、スペースをより有効に活用できると思います。 この時点で、パターン/インサーターに注意を向ける必要があります。

また、これらはスクリーンショットではありませんが、スタイルのバリエーションが例をサポートする方法と同じように、「例」は正しいですか？

例の例：

@richtaborそれは良い質問です。 では、「ブロック」と「パターン」を使用することをお勧めしますか？

そうだと思います。

私はこれを小さな反復に分解し始め、問題の説明にToDoリストを追加しました。 これは完全なリストではなく、実装を進めるにつれて、おそらく物事を発見するでしょう。 これらの項目の一部は、この問題の一部として実装されていない可能性があります。

価値があるものについては、元のコメントを編集して簡潔に定義すると非常に役立ちます
ブロックパターンとは正確には何であり

これは、潜在的な貢献者をオンボーディングするプロセスを促進するのに役立ちます。
そして、この分野をブラッシュアップしてスピードを上げようとしているコアメンバーに思い出させてください。 そして、すべての寄稿者が同じページにいることを確認します（しゃれを意図しています）。

用語とテンプレートの使用法の矛盾について、既存のコアメンバー間で混乱が生じています（リンクされたコメントの直後のコメントも読んでください）。

最初のいくつかのコメントを読んだとき、「ブロックパターン」が内部テンプレートとどのように異なるのかわかりませんでした（複数の投稿タイプで再利用でき、ページの特定の部分に関連付ける必要はありません）。

私が集めたものから; ブロックパターンレイアウトである一連のブロック; しかし、ブロック内のコンテンツはまだユーザーによって定義されておらず、コンテンツは同じです
そしてそれらはtemplate.phpファイルを置き換えることを意図していますか？
（WordPressのテンプレートがページのほぼすべてを表すことができるか、3〜4個の追加のテンプレートファイル（内部テンプレート）の一貫性に抽象化できることは複雑です。

ブロックパターンは、「複数のブロックで構成されるコールアウトブロックが必要です：見出し（その見出しレベルはセマンティクスに基づいてカスタマイズできます）」のユースケースを解決しますか？
段落ブロック、およびイベントに登録するためのリンク "）？

パターンプレビュー

先日見ました。 これは、プレビューがカーソルの垂直位置に従う方法の例です。 切り離されたプレビューの方法をとる場合、これは調査する価値があるかもしれません。

プレビューがカーソルの垂直位置に従う方法の例。 切り離されたプレビューの方法をとる場合、これは調査する価値があるかもしれません。

実際、プレビューを固定位置にすると、リスト内のアイテムを_スクラブ_しやすくなる可能性があると思います。同じスペースに目を留めることができます。

ただの質問です。 ブロックパターンでロックされた領域を定義できるので、ユーザーはブロックパターンの基本構造を変更できませんか？ たとえば、添付されたブロックパターンのフィーチャ領域の数をロックして、追加または削除できないようにすることはできますか？ このユースケースを検討していますか？

こんにちは@mrleemon！

そのシナリオは考慮していません。 現在のところ、ブロックパターンは、ユーザーが必要に応じて追加および編集できるセクションを対象としています。 これは、コンテンツをニーズに適合させることも意味します。

共有したユースケースについてもう少し詳しく説明していただけませんか。 いつ、またはなぜそれを持っていることが有用でしょうか？

@enriquesanchez

特定の順序で一連のグループブロックを使用して、ユーザー（たとえば、編集者の役割を持つ）がそれらのブロックのコンテンツを変更できるが、ブロックを削除したり順序を変更したりできない1ページのデザインを考えています。ページ上部のメニューアンカーは、引き続きページ構造と一致します。

共有したユースケースについてもう少し詳しく説明していただけませんか。 いつ、またはなぜそれを持っていることが有用でしょうか？

過去のクライアントの仕事から、私はこの要求も聞いたことがあります。通常、特定の編集ワークフローを持つ大規模な組織からです。 通常、特定のタイプのコンテンツに対して承認されたレイアウトを提供し、レイアウト内のコンテンツ（画像、ビデオ、テキストなど）を編集できるが、レイアウト自体は変更できない作成者が必要です。 この背後にある理由は、多くの異なる人々がコンテンツを生成および編集している場合でも、通常、サイト全体でコンテンツの一貫したデザインとブランディングを維持することです。

レイアウト内のコンテンツ（画像、ビデオ、テキストなど）を編集できるが、レイアウト自体は変更できない作成者がいる

はい、基本的にレイアウトタイプのブロック（グループ、列など）をロックする機能があると便利です。

私はこれが以前に起こったことを知っています、そしてあなたがこれを達成することを可能にするテンプレートにいくつかのロックの側面があったことを誓うことができました、しかしそれは私を逃れます。 いずれにせよ、ユースケースは正当であり、解決するのが興味深いようです。

これは、テンプレートを作成するときに間違いなく利用できます。 下位レベルのAPIであるため、パターン作成レベルからはまだアクセスできません。

これは、Richの@richtaborからの最新のモックアップに基づく提案です。
ビッグモーダル2。https ： //github.com/WordPress/gutenberg/issues/17335#issuecomment -587951100

大きなモジュラスと小さなモジュラス。 インサーター画面を小さくするためのアイコンがどこかにある可能性があります。 小さいアイコンをクリックすると、ブロックインサーターが小さくなり、レイアウトのコンテンツに関連して使用を検討している1つのパターンに集中できます。

リッチのモックアップを続け、使用と編集とロックアイコンを追加しました。
これは、ユーザーがパターンまたは再利用可能なブロックを編集できることを意味します。
管理者がパターンをロックしている場合、編集は利用できません。
ユーザーは、[使用]、[パターンのタイトル]、またはパターン自体をクリックして、レイアウトに直接使用/挿入できます。 また、青い下線を選択した領域に近づけました。

代替。
設定girを使用して、[編集]（オブジェクトを編集できる場合）、[インポートとエクスポート]などを示すドロップダウンを作成します。

[編集]をクリックします。 パターン/再利用可能なブロックのみを編集するためのフォーカスされた領域。

これの初期バージョンが実行されます。 ここにはまだいくつかのフォローアップタスクがあります（検索、カテゴリ...）。ただし、この問題は＃21080であり、フォローアップのリストが充実しているので、この問題をクローズします。