Gutenberg: 子/親ブロックを選択するためのツールを強化する

私はパンくずリストのアイデアが好きです。 （実際、4月の＃6459でかなり似たようなものを提案しました。）統合ツールバーを有効にすると、ブレッドクラムはどうなりますか？

クリックスルーのアイデアも良いと思います。すでにモバイルで使用されているので、一貫性が増します。 ただし、パススルーのアイデアについてはよくわかりません。 ブロック間での動作が異なるため、混乱が生じる可能性があると思います。

私はパンくずが好きですが、統合ツールバーも好きです。 ブレッドクラムの別の位置を見つけることができますか:)

また、私は個人的に親ブロックの周りの境界線が好きではありません。 しかし、それらを保持する場合、複数選択をどのように処理しますか:)。 複数選択されたブロックの親の周囲に境界線を表示する必要がありますか？

クリックスルーオプションが好きです。 これには、「パススルー」ブロックでいくつかの追加作業が必要になります（たとえば、個々の「列」はクリックスルーするレイヤーとは見なされません）が、それは非常に理にかなっていると思います。

統合ツールバーが有効になっている場合、ブレッドクラムはどうなりますか？
私はパンくずが好きですが、統合ツールバーも好きです。 ブレッドクラムの別の位置を見つけることができますか:)

良い質問。 迅速で汚いモックアップ：

はい、スイッチャーのアイコンが重複しているという課題があります。 これを考え続けるのは良いことだと思います。 また、このデザインでは、＃4287でブロックされているドキュメントのアウトラインが省略されていることに注意してください。

また、私は個人的に親ブロックの周りの境界線が好きではありません。 しかし、それらを保持する場合、複数選択をどのように処理しますか:)。 複数選択されたブロックの親の周囲に境界線を表示する必要がありますか？

内側のブロックが親グループの一部であることを示すものとしてそれらを示すことが重要だと思います。 それらは内部ブロックを_アンカー_します。

現在、これは複数選択の仕組みです。

そして、これは、2つの子ブロックを選択したときに起こることです。

言い換えると、マスターではすでに親の境界線があり、子ブロックを複数選択するときに親の境界線を非表示にします。 実際には、複数選択の場合でも、親の境界線を常に表示することは、_子ブロックのみを選択している場合_に意味があると思います。 ただし、_parent_ブロックが複数選択されている場合は、複数選択を異なるものにする必要があります。 したがって、追加のレイヤー効果ですべての子ブロックを強調表示する代わりに、親ブロックのみを強調表示します。 それはうまくいくでしょうか？

クリックスルーオプションが好きです。 これには、「パススルー」ブロックでいくつかの追加作業が必要になります（たとえば、個々の「列」はクリックスルーするレイヤーとは見なされません）が、それは非常に理にかなっていると思います。

はい、現在、_column_子ブロックにはいくつかのUIの課題があります。 たとえば、その前にブロックを挿入することはできませんが、なぜそれを選択できるのでしょうか。 しかし、それは非常に難しい技術的課題であり、それに伴う課題を理解しています。 だから私はこれが簡単だとは言っていません。

https://github.com/WordPress/gutenberg/pull/9653で作業していたときに、階層をナビゲートするためにすでに存在する矢印キーナビゲーションに気付きました（列を選択して親を選択するときに矢印キーを上に使用します） 、つまり列ブロック）は本当にうまく機能しています。 実際、Windowsファイルエクスプローラーの「親フォルダーに移動」のように、この機能を「上へ」ボタンとして表示するだけで、完全なパンくずリストではなく、十分である可能性があります。

これがどのように見えるかです。 上部のツールバー：

ブロックツールバー：

CC： @youknowriad

いくつかの考え

パン粉

私はブレッドクラムソリューションが好きですが、あいまいさがあり、アイコンのみのインターフェイスに問題があり、アイコンにカーソルを合わせてアイコンが何であるかを確認したり、ブレッドクラムをブレッドクラムではなくオプションのツールバーと混同したりすることがあります。

したがって、おそらく上部のツールバーはそれを表示するのに最適な場所ではなく、おそらく他の場所のパンくずリストからのいくつかの手がかりが役立つでしょう。 たとえば、現在使用しているファイル->クラス->メソッド/関数を表示するPHPStormの階層ツールバー、またはMacOSFinderとWindowsエクスプローラーのフォルダーツールバー？

クリックスルー

クリックスルーは非表示のUIになります。人々は、含まれている列ブロックが選択されていることを見つけるためだけに画像ブロックを選択することを期待しているため、多くの誤解や混乱が見られます。 通常、AdobeソフトウェアのクリックスルーUIはモードを導入するため混乱を招き、特にネストがある場合は、現在地と終了方法を判断するのが困難です。 たとえば、ダブルクリックして子ブロックに入る場合、どのようにして親ブロックに戻り、UIはブロック内にいることをどのように示しますか？

モードについては多くの研究とガイドラインがありますが、IllustratorやPhotoshopに存在するため、良いと見なすべきではありません。適切なソリューションになる前に、クリックするだけでなく、さらに多くの作業を行う必要があります。

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

これは、これが台無しにするすべてのアクセシビリティ要因も無視しています。

上ボタン

上ボタンのアイデアは素晴らしいです。 私の懸念は、それを押すと、下ボタンが表示され、ブロックが上に移動することを意味します。それはあいまいで、ブレッドクラムブロックと同じ問題が発生します。

再利用可能なブロックパターン

現在、再利用可能なブロックには、フロントエンドに表示されていないブロックインターフェイスにクロムを追加するUIパターンがすでにあります。 列は同じことをすることができませんでしたか？

または私が意味するものの超ゴミのモックアップ

したがって、columnsブロックのクロムは、それを選択するために使用されるものであり、マウスを狙う視覚的なものを提供します。

ここで使用できるツールバーモデルに適合する可能性のあるUXパターンの1つは、OS Xフォルダートラバーサルボタンです： https ：

ユーザーはクリックして選択することで子/親ブロックを視覚的に選択できることを期待していると思いますが、それを正しく行うには明らかに多くの複雑さがあります。 上記のトラバーサルパターンは良い最初のステップであり、フェーズ2でよりエレガントなソリューションの開発についてさらに深く掘り下げることができます。

私はその概念Alexisを、特にあなたが言及したより複雑なブロックのために_崇拝_します。 私はそれがとても好きで、すぐにそれを実行し、あなたのアイデアを説明するためにいくつかのモックアップをリミックスしました。

選択なし：

選択したブロック：

選択された内部のネストされたブロック：

フォルダトラバーサルボタンのポップアウトが開きます：

☝️私はその概念が好きです。このスレッドで共有されているすべてのアイデアとフィードバックが溶け合って、反復するための_solid_ベースラインになっているように感じます。 その新鮮な視点をもたらしてくれてありがとう！

ビジュアルツリーのドロップダウンが大好きです。この形式でドキュメント全体を表示することも役立つと思います。また、物事を並べ替えるのに便利な方法も提供します。

しかし、さらに考えてみると、すでにこのような選択メカニズムがあり、情報パネルにドキュメントの概要があることに気づきました。

これは、モックアップのスタイリングで強化でき、追加の選択記号として機能します。 現時点ではタイトルのみが表示されますが、完全なブロックツリーと選択インジケーターを備えたバージョンは非常に便利です

私の唯一の悩みは、ツールバーアイコン自体です。 これは矢印の付いたもう1つの謎のアイコンであり、ツールバーをカスタマイズしない限り、デフォルトではMacOSのFinderにはないボタンです。 アイコンが見えず、アイコンを簡単に区別できない私たちにとって、それは問題があります

テキストラベルを使用すると、より明確になりますが、テキストラベルがないと、クリックしないと何が行われたかがほとんどわかりません。

見栄えが良い:)読みやすくするために、アイコンを少し単純化してみてください。 たぶん、4行ではなくもう少し間隔を空けた3行ですか？

テキストラベルを使用すると、より明確になりますが、テキストラベルがないと、クリックしないと何が行われたかがほとんどわかりません。

ツールチップもあります。

re： @tomjnのコメントでは、これを別の場所を作成するのではなく、ドキュメントツリー全体に統合できるかどうかも検討する価値があると思います。 そこでの課題は、より多くのレベルのものに対応しながら、ツリーの単純さとスキャン可能性を維持することです。 しかし、それはSketchやPhotoshopのレイヤーパネルのようになる可能性があり（デザインではなく機能的に！）、ページ構造全体の唯一の正しい情報源になります。 うまくやるのは難しいですが、探索する価値はありますか？

繰り返しますが、これは私たちが繰り返すものである可能性が高いので、より洗練されたものに成長できる最も有用なMVPは何ですか？

ツールチップもあります。

それだけでは不十分だと思いますが、これは別のディスカッションと機能のリクエストだと思います。新しいチケットを開きます

読みやすくするために、アイコンを少し単純化してみてください。 たぶん、4行ではなくもう少し間隔を空けた3行ですか？

私はすきです：

しかし、さらに考えてみると、すでにこのような選択メカニズムがあり、情報パネルにドキュメントの概要があることに気づきました。

また、別の場所を作成するのではなく、これをドキュメントツリー全体に統合できるかどうかを検討する価値があると思います。

私はそれがうまくいくと思います。 以前、アイテムをプラグインとして書き直して、右側に表示されるようにすることを提案しました（＃4287を参照）。 しかし、私はこれをドキュメントツリーに転用するのが好きです。

ラベルに関しては、ラベルが好きですが、ブロックツールバーを上部にドッキングするオプションを考慮する必要があります。

このディスカッションは、＃9053（CC：@westonruter）を思い出させます— https://github.com/WordPress/gutenberg/issues/9628#issuecomment-429012989に示されているAlexisの提案が気に入ると思います。

これが進むのを見るのは素晴らしいことであり、コンセプト@alexislloydに感謝します。 @jasmussen私はこれらのモックが本当に好きで、反復できる素晴らしいポイントがあると思います。

では、より洗練されたものに成長できる最も有用なMVPは何でしょうか。

これをより単純なトラバーサルコントロールとして構築し、後で見て、選択に基づいてドキュメントコンテンツボックスと組み合わせることが理にかなっているかどうかを確認します。

＃10767の説明に従って、これを再度開いて繰り返します。

＃11159で提案されている追加のアイデアも参照してください。

複雑なブロックの操作を簡単にするためのもう1つのアイデアは、_選択されていないブロックはプレビュー_であり、_選択されたブロックは追加の編集コントロールを表示できる_ことを覚えておくことです。

そのアイデアを活用して、columnsブロックの要素を簡単に選択できるようにすることができます。 たとえば、columnsブロックまたはその子が選択されると、コンテナのパディングがアニメーション化され、子要素を選択するためのスペースが確保されます。 これにより、サイドUIにもアクセスできるようになります。 親ブロック（パディングが展開されているブロック）の周囲に、たとえば破線などの境界線を表示したいと思います。

子が選択されている場合でも、最上位ブロックの.is-selectedクラスを復元​​した場合、これを実装するのは比較的簡単なようです。 しばらく前に、hasSelectedInnerBlocksプロペラを使用してこれを行いました。

これは、列ブロックのセルにカーソルを合わせると表示されます。

Media＆Textブロックのセルにカーソルを合わせます。

内側のブロックと外側のブロックが見えます。
列->段落など。 列-> YouTube。 メディアとテキスト-> YouTube

ホバー情報のブレッドクラム情報（内側と外側のブロック）をクリック可能にするとよいでしょう。 [列]をクリックして親を選択するか、[段落]をクリックして子を選択します。

今これを試してみると、親列ブロックを選択する最も簡単な方法は、親ブロックの右/左に提供する余分な非表示のヒット領域を利用することです。

この追加のヒットエリアはブロックの上部と下部では利用できないため、その方法を選択するのは非常に困難です。

複雑なブロックの操作を簡単にするためのもう1つのアイデアは、選択されていないブロックはプレビューであり、選択されたブロックは追加の編集コントロールを表示できることを覚えておくことです。

そのアイデアを活用して、columnsブロックの要素を簡単に選択できるようにすることができます。 たとえば、columnsブロックまたはその子が選択されると、コンテナのパディングがアニメーション化され、子要素を選択するためのスペースが確保されます。 これにより、サイドUIにもアクセスできるようになります。 親ブロック（パディングが展開されているブロック）の周囲に、たとえば破線などの境界線を表示したいと思います。

これが@jasmussenが上記で示唆していることであるかどうかは100％

誰かがブロックを出ると、その余分なパディングが消えて、ブロックのより正確な表現を示すことができます。

この追加のヒットエリアはブロックの上部と下部では利用できないため、その方法を選択するのは非常に困難です。

この問題に関するチケットがあったことを確認できました。これは、兄弟インサーターの動作にも関連しています。 現在は見つかりませんが、この問題は修正できるはずです。 @aduthはベルを鳴らします、コメントにあなたがいたことを誓うことができますか？

これが@jasmussenが上記で示唆していることであるかどうかは100％

それは多かれ少なかれ私が意味したことであり、私ができるよりも美しく視覚化されただけです。

これが私が何を意味するかを説明するための追加のクレヨンスケッチです。 列ブロック：

本質的にあなたが持っているもの、Kjell —おそらく破線が少し暗くなっています。 また、columnsブロックのさらなる開発がどのように進むかに応じて、_column_ブロックもあることに注意してください。 つまり、階層は現在_Columns→Column→Image_です。 私たちは激しいCSSウィザードを使用して、第2レベルを多かれ少なかれ見えなくしていますが、将来それを選択して、たとえばCSSクラスを適用したり、個々の列に必要なその他のオプションを適用したりする場合は、検討する価値があります。

スライドショーブロック：

明確にするために：スライドショーブロックは計画されていません。 これは純粋に落書きであり、ブロックのプレビューモードと編集モードが_大きく_異なる可能性があるという点を示しています。 ブロックを選択および選択解除するだけで2つのモードを切り替えるのは非常に簡単で、驚くほど中断がないので、ブロックに傾倒して機会について創造的になる必要があります。

スライドショーブロックの場合、ほぼ定義上、コンテンツは画面/ブロックの外側には表示されません。 しかし、それを編集しているときである必要はありません。 ブロックを選択するだけで、編集可能なキャプション付きのサムネイルが表示されます。 次に、ブロックの選択を解除して結果をプレビューします。

この問題に関するチケットがあったことを確認できました。これは、兄弟インサーターの動作にも関連しています。 現在は見つかりませんが、この問題は修正できるはずです。 @aduthはベルを鳴らします、コメントにあなたがいたことを誓うことができますか？

最も近いのは＃8883、＃8881、＃5180のいずれかだと思いますか？

ドキュメントツリーは役に立ちますが、それでも、操作しようとしているものからフォーカスを変更する必要があります。 実際のブロックとネストされたブロックを直接クリックするためのより良い方法が本当に欲しいです。 @jasmussenが上記で概説したクリックスルー方法は、さらに検討する価値があると思います。

私がよく経験する問題は次のとおりです。

ユーザーとして、私は画面上の別の場所にある別の解決策を見つける前に、少なくとも1分間これと戦います。 😉

* _このコメントを追加すると、他にもたくさんのコメントが表示されました。 今はそれほど関連性がないかもしれませんが、闘争を記録するためにここに保管しています。_

ただし、編集モードでパディングと親ブロックの視覚的インジケータを追加すると、ここで大きな助けになる可能性があります。 そうすれば、親を選択する場合にクリックする必要がある場所が明確に示されます。

このソリューションに関する私の懸念は、周囲のブロックとの関係でパディングがどのように機能するかです。

1. 親ブロックのパディングはフロントエンドに反映されていますか？ それとも、エディターでさらにパディングしますか？

2. このように、ブロックが選択されると、パディングは動的に追加されますか？

1. または、このように、パッド付きの親が周囲のブロックの上に表示される可能性がありますか？

この概念をさらに掘り下げようとしているだけです。 それについてのいくつかの考えが大好きです。

@aduthに感謝します、あなたは私に少なくとも正しい方向に行くチケットを見つけさせました。 ＃9229のGIFは、問題を説明しています。そのGIFの黄色の領域は、兄弟インサーター用に「予約」されています。 これが、ブロックの上または下のパディングをクリックしてブロックを選択できない原因です。 それが@kjellrのコメントに対する答えです：

この追加のヒットエリアはブロックの上部と下部では利用できないため、その方法を選択するのは非常に困難です。

さらに明確にするために、その黄色の領域は、兄弟の挿入ボタンを表示するためだけにあります。 したがって、インターセプトする必要があるのは、実際には_ホバー_アクションだけです。 クリックがまだその黄色いバーを介して伝播し、下のブロックを選択できるようになっていると便利です。

ドキュメントツリーは役に立ちますが、それでも、操作しようとしているものからフォーカスを変更する必要があります。 実際のブロックとネストされたブロックを直接クリックするためのより良い方法が本当に欲しいです。 @jasmussenが上記で概説したクリックスルー方法は、さらに検討する価値があると思います。

現在の実装が少し中途半端な場合でも、実際にこれを今すぐテストできます。

• グーテンベルク、任意のバージョンを実行します。
• コンテンツを含む列ブロックを挿入します。
• ウィンドウのサイズを600pxのブレークポイントより下に変更してから、を選択します。

これはモバイル用に実装されています。つまり、親ブロックをより簡単に選択できるようになっています。

GIF：

現在の実装の問題は、最も深いレベルにドリルダウンすると、「状態」がリセットされることです。 つまり、同じ段落を2回選択しただけでも、[列]> [列]> [段落]、[列]> [列]> [段落]になります。 試してみるその問題の明らかな解決策は、目的のレベルに「ドリルダウン」した後、ブロックを再度選択解除するまでそのレベルに_とどまる_ようにすることです。 つまり、列>列>段落、段落、段落、選択解除、巻き戻しなど。

また、_some_ブロックの場合、このクリックスルー方法が非常に重要になると思います。 特に、あらゆる種類のネストされたコンテンツを含む可能性のあるページテンプレートを検討し始めると。

クリックスルーが素晴らしいときにどのように機能するかについてのインスピレーションは、Keynoteでも試すことができます。 いくつかの図形を挿入すると、それらを直接クリックできます。 2つの図形をグループ化するとすぐに、移動しやすい新しい図形になります。 ただし、グループのコンテンツを編集するには、ダブルクリックする必要があります。

https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172であなたの良い質問に答えるには：

親ブロックのパディングはフロントエンドに反映されていますか？ それとも、エディターでさらにパディングしますか？

いいえ、このパディングはエディター内でのみ、_ブロックが選択されている場合のみ_です。 これは、ブロックがインターフェースの原則であることに基づいており、エディターでは次のように述べています。

• 選択されていないブロックはプレビューです。 できるだけフロントエンドに見える必要があります
• 選択されたブロックは本質的に「ブロック編集モード」であり、この状態では、ブロックは追加のコントロールを出力でき、まったく異なって見えることさえあります。

これは、上記のスライドショーブロックの落書きの例で強調表示しようとしたものです。スライドショーブロックが選択されていない場合、それはスライドショーです。 選択すると、_スライドショー編集モード_になり、すべてのスライドのサムネイルグリッドが表示されるため、キャプションの編集や再配置などを簡単に行うことができます。

このように、ブロックが選択されると、パディングは動的に追加されますか？

はい、多かれ少なかれ。

これは、よりよく説明し、その感触をつかむために、プロトタイピングする価値があると思います。

最終的に、この機能はおそらくブロック自体の小道具であり、ブロックが使用することを選択できるものです。 たとえば、段落がネストされたブロッククォートは、おそらくこのインターフェイスを使用しないでください。ただし、列を編集する場合は、ある程度完璧な場合があります。

簡単なcodepenプロトタイプは次のとおりです： https ：//codepen.io/joen/pen/exmMQv？editors = 1100

それはちょっと静的ですが、うまくいけば、それは意味を理解します。

簡単なcodepenプロトタイプは次のとおりです： https ：//codepen.io/joen/pen/exmMQv？editors = 1100

それはちょっと静的ですが、うまくいけば、それは意味を理解します。

それは本当にポイントを伝えるのに役立ちます。 少し編集したので、クリックすると破線の境界線がどのように表示されるかを確認できます。

https://codepen.io/kjellr/pen/jdEJQb?editors=0110

これは完璧です、ありがとうKjell！ それがまさに私が言いたいことです。 おそらく、実装のいくつかの側面を調整し、直接の親（単一の列）がパディングを取得する場合の外観に対処する必要があると思います。 しかし、これはかっこいいです！ 私はそれがうまくいくと思います。

私は本当にこれが好きです。
より多くのブロックとコンテンツでテストするためのPRの作成に移るべきですか？
これが影響するブロックを特定する必要がありますか？

私も掘ります。

今のところ、これをColumnsブロックでプロトタイプ化することはできますが、着陸するには、この_method_が両方とも汎用である必要があるため、他のブロック（あなたが言うように）がこれを使用できますが、ブロックができるように小道具も使用できますこれにオプトインすることを選択します。 ネストされたブロックを受け取ると、Quoteブロックがこれを持っていると混乱する可能性があります。

@gziolo何か考えはありますか？ 特に、 https： //github.com/WordPress/gutenberg/issues/9628#issuecomment-456811415でKjellによって落書きされたアプローチについて

@gziolo何か考えはありますか？ 特に、＃9628（コメント）でKjellによって落書きされたアプローチについて

素晴らしく見える。 最終的に、必要に応じて親ブロックを簡単に選択できるようになります。 私の唯一の質問は、他の列を狭くする代わりに、列の幅を元のサイズに近づけることについてどう思いますか。 現時点では、いずれかの列が選択されるとすべての列が縮小されます。これは、3つ以上の列がある場合は最適ではない可能性があります。 @jasmussen他に質問がありますか、答える必要がありますか？

私の唯一の質問は、他の列を狭くする代わりに、列の幅を元のサイズに近づけることについてどう思いますか。

これは、おそらく実装において、微調整してバランスを取る必要があるものであることに同意する傾向があります。 子供のサイズを縮小しないように、親の幅/高さを拡張することも検討できますが、それはおそらく技術的にはより困難です。

他に質問がありますか、答える必要がありますか？

基本的に、ここで説明しているインターフェイスは次のとおりです。子ブロックが選択されたときに親ブロックにパディングを追加して、選択しやすくします。 これは、KjellのColumnsブロックのプロトタイプで「良い感じ」です。 Sectionブロックなどの他のブロックや、子コンテンツが内部の利用可能なすべてのスペースを埋める可能性が高い他の多くのブロックでは、おそらく非常に歓迎されます。 しかし、Quoteブロックのように、まだネストを使用していないことは確かですが、将来的には使用する可能性が高いため、おそらくそれほど良いことではありません。

したがって、この親選択インターフェースを、すべてのブロックに対して_generic_、デフォルトでは_off_である方法で構築するとよいでしょうが、ブロックが小道具を使用することを選択できるものです。

それに最善のアプローチをする方法について何か提案はありますか？

ネストされたブロック（現時点では列、メディア、テキスト）を含むすべてのブロックは、 .editor-inner-blocksクラスをレンダリングするこのInnerBlocksコンポーネントをレンダリングします。
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
これは、ネストされたすべてのブロックで機能する一般的なソリューションを考え出すのに役立つ場合があります。 ただし、 .is-selectedが子孫要素の1つに適用されるため、注意が必要な場合があります。

Edit: CSSだけで機能しない場合。 親の状態を更新して、ネストされたブロックの1つが選択されているという情報を公開する方法をいつでも見つけることができます。 @jorgefilipecostaと@aduthは、ネストされたブロックで多くの時間を費やしたので、それについてより多くの洞察を持っているかもしれません:)

したがって、すべてのブロックに一般的な方法でこの親選択インターフェイスを構築すると便利ですが、デフォルトではオフになっていますが、ブロックが小道具を使用することを選択できます。

ネスティングを使用しないこのアプローチでは、どのブロックを検討しますか？ そもそもなぜネストを使わないのかと思いました。 GalleryをネストされたImageブロックを持つコンテナに変換するとします。 この動作は無料で取得できますが、ボーナスとして並べ替えることもできます。

ネスティングを使用しないこのアプローチでは、どのブロックを検討しますか？

ギャラリーは面白いものです。

正直なところ、私は主に、グリッドレイアウトブロック、タブグループブロック、または他の同様の「ページ構築」ブロックなど、より高度なレイアウトブロックについて考えています。 コンテンツ固有のものは、おそらくこのインターフェイスを使用しないでください。

正直なところ、私は主に、グリッドレイアウトブロック、タブグループブロック、または他の同様の「ページ構築」ブロックなど、より高度なレイアウトブロックについて考えています。 コンテンツ固有のものは、おそらくこのインターフェイスを使用しないでください。

それらはすべてコンテナブロックカテゴリに当てはまると思います。つまり、実装の詳細としてInnerBlocksを使用する必要があるため、このカテゴリに当てはまるはずです。 ブロック定義にsupportsグループがある他の機能の場合と同様に、オプトアウトを提供できます。

それらはすべてコンテナブロックカテゴリに当てはまると思います。つまり、実装の詳細としてInnerBlocksを使用する必要があるため、このカテゴリに当てはまるはずです。

しかし、Quoteブロックは、ネスト機能を受け取った場合、内部ブロックも使用しませんか？

しかし、Quoteブロックは、ネスト機能を受け取った場合、内部ブロックも使用しませんか？

はい、Quote、List、Cover-これら3つは、過去にネストされたブロックに変換されたと見なされていました。

1つの懸念（実験をブロックするべきではありませんが、注目に値するだけです！）は、列ブロックがどれだけ狭くなるか、そしてそれが編集モードツールにどのように影響するかという点ですでにいくつかの問題があることです。 この提案により、編集操作中に列が効果的にさらに_狭く_なり、これらの狭さの問題が再浮上する可能性があります。

また、1対1の編集/表示パリティからさらにプッシュします。これは問題になる場合と問題にならない場合があります。 確かに、InnerBlocksを使用してカスタムブロックでこれと同様のこと（選択時の追加のパディング）をすでに実行しており、うまく機能しますが、編集ビューが正確ではないことを意味します。

したがって、すべてのブロックに一般的な方法でこの親選択インターフェイスを構築すると便利ですが、デフォルトではオフになっていますが、ブロックが小道具を使用することを選択できます。

Jetpack Formブロックを構築するときに、このようなものをオプトインできることは素晴らしいことでした。

また、1対1の編集/表示パリティからさらにプッシュします。これは問題になる場合と問題にならない場合があります。

これは、特にUXを改善している場合は、

また、ブロックを3つの深さでネストするとどうなりますか？ 2番目のレベルも親ブロックである場合、パディングオプションは2番目のレベルに拡張されますか？

@mapk

また、ブロックを3つの深さでネストするとどうなりますか？ 2番目のレベルも親ブロックである場合、パディングオプションは2番目のレベルに拡張されますか？

影響を受けるすべてのレベルのネストのパディングは、深くネストされたブロックを選択するときに、大きなサイズの増減を引き起こす可能性があるように聞こえます。たとえば、セクションの行の列の引用符の段落。 理想的には、ブロックを選択しても、他のすべてのブロックの外観が大幅に変わることはないはずです。そのため、直接の親の間隔を変更するだけで十分だと思います。

直接の親を選択できる限り、親を選択するとその親が簡単に選択できるようになるため、階層を上に向かって進むことができます。 ブロックナビゲーションメニューを使用すると、すばやくアクセスできます。また、以前に提案されたように、ピン留め可能なサイドバーにして、すばやくアクセスできるようにすることもできます。 （＃11408および＃11688を参照してください。）

パディングの変更は、選択したブロックと直接の子孫にのみ影響することをいつでもお勧めします。

これがこの作業に影響を与える場合に備えて、列ブロックに垂直方向の配置を追加するために着陸させたい作業によって、_個々の_列が選択可能になることをすぐに明らかにできますか（以前は選択できませんでした）

https://github.com/WordPress/gutenberg/pull/13899

列ブロックに垂直方向の配置を追加するために着陸したいと思っている作業により、_individual_列が選択可能になります（以前は選択できませんでした）

ここでそれを指摘してくれてありがとう。 それが、この相互作用を後でではなく早く片付ける理由です。

ブロックの境界に関して、今日@jasmussenと話し合ったことを共有したかっただけです。

これは上記のモックアップのいくつかで少し見られ

この例では、フォーカスされた状態に暗い境界線を使用しています。 ブロックが親または子ブロックである場合、他の関連アイテムの周りに点線の明るい境界線（およびいくつかの追加のパディング）を含めました。 これにより、ユーザーはブロック階層のどこにいるかを明確に視覚化できると同時に、クリックして他のネストされたブロックを選択できる場所を明確に把握できます。

@kjellr私は本当にそれが好きです。 それは構造が何であるかを非常に明確にします。

しかし…点線のコントラストの問題に再び遭遇すると思います。 はっきりとは言えませんが、点線を導入するということは、アクセシビリティの基準に従う必要があるのではないかと疑っています。 そして、コントラストをはるかに高くすると、視覚的に重くなり、メリットが失われる可能性があると思います…

少し大声で考えてみてください。 見栄えの良いユーザーとしての見た目は本当に好きですが、私の好みでは十分ではないので、a11yのフィードバックを聞いてみたいと思います:)

画面には、最初は点線すら見えませんでした。 画面を少し傾けると、ほとんど見えなくなります。

アクセスしにくくなる場合は、コントラストをそれほど下げる必要はありません。 _少し_軽く、別のborder-styleを使用している限り、問題なく動作すると思います。

申し訳ありませんが、元のコメントでもっと明確にすべきでした。Joenと話しているときに、ほんの数分でそのモックアップを作成しました。 当時画面に表示されていたグレーからランダムに色を選んだだけだと思います。 😄正確な色合いは、最終的な解決策を伝えることを意図したものではなく、一般的なアプローチにすぎません。

親ブロックにパディングを追加すると、内部ブロックがフロントエンド（＃14148＃14169）と矛盾するという懸念に応えて、私は別のアイデアを考案しました。

これを実現するにはさらに開発が必要ですが、良い選択肢かもしれません。

基本的に、親ブロックをクリックすると、展開して（通常のブロックよりも大きくなり）、子/親を簡単に選択するために必要なパディングを提供します。 これにより、内部ブロックの視覚的な一貫性がフロントエンドに保たれます。

スクリーンキャスト

InVisionプロトタイプ

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

長所

1. 内側のブロックは適切な幅のままです。
2. 内側のブロックは、フロントエンドと視覚的に一貫性を保ちます。
3. 選択したブロック変更サイズは、すでに使用されているパターンです。

短所

1. 通常のブロック選択を超えてブロック選択（幅）を拡張することは、新しいパターンです。
2. ブロックが全角に設定されている場合、これがどのように機能するかわかりません。

基本的に、親ブロックをクリックすると、展開して（通常のブロックよりも大きくなり）、子/親を簡単に選択するために必要なパディングを提供します。 これにより、内部ブロックの視覚的な一貫性がフロントエンドに保たれます。

それを掘る。 ブロックツールバーを左の境界線と同じ高さに保ちたいのですが、それは実装の詳細です。

それが実際に大きくなることができないとき、それはより小さな画面で挑戦になるでしょう、しかしこれはまた何か解決可能なもののように感じます。

特に、そのアプローチは、選択が可能な限り妨げられないようにする必要があるような基本的なテキストブロックであるQuoteブロックでさえ、内部ブロックを持つ_any_ブロックに拡張できるように感じます。

本当に、本当にあなたの仕事を掘り下げてください、Kjell —それはマークのアイデアで目に見えないように機能するだけでなく、_必要なときに_ドキュメントの構造を強調するのに役立ちますが、書きたいときに流れを壊すことはありません。 それは確かな方向性のように感じます、そして私たちが必要としているのはこれに関する強力な開発者です。

実装上の注意—破線の親は、理論的には選択したブロックと同じ色になる可能性がありますが、破線のおかげで、まだセカンダリに見えます。 親にカーソルを合わせると、アウトラインが実線になり、_child_（ホバーしているときに選択したもの）が破線になり、クリックしたときに何が起きようとしているのかを示すことができます。

実装上の注意—破線の親は、理論的には選択したブロックと同じ色になる可能性がありますが、破線のおかげで、まだセカンダリに見えます。 親にカーソルを合わせると、アウトラインが実線になり、_child_（ホバーしているときに選択したもの）が破線になり、クリックしたときに何が起きようとしているのかを示すことができます。

はい！ それも完全にうまくいくと思います。 ＃14145がどこで解決するかを見て、そこから治療法を見つけましょう。 👍

また、単一の列を選択可能にしたが、PRの範囲外として削除したときに、境界線をいじくり回しました。 間違いなくUXの改善のように感じました。 これが向かっている道を愛する！

ちょっと注意してください：私は上記のアイデアを別の簡潔な問題にまとめて調査しています。 ここに従ってください：

https://github.com/WordPress/gutenberg/issues/14935

子が選択されたときに誰かが親ブロックにhas-child-selectedクラスを追加するために参加できる場合、それがそれを開始するための唯一のブロッカーです。

私が見つけた関連する問題は、新しく導入されたグループブロックをテストしました。

現時点で混乱しているのは、Groupブロックを挿入すると、実際に表示されるのはParagraphブロックであるということです。

少なくとも次のようなことはできますか？

または、 @ mtiasがプライベートチャットでブロックナビゲーション機能のビットを再利用して提案したこと：

_これらは決して最終的な設計提案ではありません😃_

@gzioloその問題は＃14241によって解決されることを意図しています。 私はあなたに同意します、ところで、それですぐにそれを出荷するのは素敵でしょう:)

@gzioloその問題は＃14241によって解決されることを意図しています。 私はあなたに同意します、ところで、それですぐにそれを出荷するのは素敵でしょう:)

まあ、部分的に言うと思います。 この新しいカスタムインサーターを使用して段落を挿入すると、正方形に戻ります🤷‍♂️

ここでも＃14935が役立つと思います。 また、サイドバーのいくつかのオプションを調べて、現在選択されているブロックがネストされていることを確認する方法を増やす必要があります。

そうそう。 ここにあるように、サイドバーのブレッドクラムを復活させることを考えていました。

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

シンプルで比較的エレガントで、この問題（9628）にも役立ちます。

上記のアイデアのいくつかについて繰り返しを投げます：

ブロックの変換/スタイルを独自の専用アイテムに移動し、ブロックアイコンを独自の「ブロックツリー」パネルにした場合はどうなりますか？

これにより、ブロックの変換/スタイルの可視性が向上すると同時に、他のネストされたブロックに移動するのが少し明確になる可能性があると思います。 より複雑な例のモックアップを次に示します。

（どちらのコンプも＃14961のアウトライン/パディングを使用しています）

それは非常に興味深いKjellに見えます！ 次に、ブロックナビゲーション領域と連携して、それらの間に一貫性を作成します。 ブロックナビゲーションの使用法を学ぶと、同じ学習でネストされたブロックを選択し続けることができます。

私は概念レベルでのモックアップが本当に好きですが、実行についての何かが少し密に感じます。 必ずしももっと良いアイデアがあるかどうかはわかりませんが、これを少し軽く感じる方法があるのではないかと思います。

ブロック構造の概要を簡単に見つけるのに苦労していることはわかっているので、この概念はこれを解決するための優れたアイデアです。

ここでの私の懸念は、 @ chrisvanpattenのを模倣しています。 それはよく考えられていますが、それはたくさんのように感じます。

1. 特定のコンテキストの一部のブロックには、ドロップダウンを表示するさまざまな方法があります。

ミックスに別のシェブロンを追加すると（灰色で右向きですが）、解析がさらに難しくなる可能性があると思います。

1. もう1つの懸念は、ツールバーが長くなっていることです。 これは大したことではないかもしれませんが、アイコンhttps://github.com/WordPress/gutenberg/issues/10524とhttps://github.com/WordPress/gutenberg/issues/のラベルを含めるとそうなる可能性があり

これを探求している間、熟考するためのいくつかの考え。 これは、何が起こっているのかを伝える最も簡単なアプローチかもしれません。

これを少し軽く感じる方法があるのだろうか？

ええ、それはそこの階層の欠如と関係があると思います。 最初のツールバー項目は、接地要素のように少し感じ、他の項目はブロックの2番目のオプションのように感じるはずです。 なんらかの分離が必要です。 これは正しい解決策ではありませんが、会話のために、これは少しだけ役立つと思います。

特定のコンテキストの一部のブロックには、ドロップダウンを表示するさまざまな方法があります。 ミックスに別のシェブロンを追加すると（灰色で右向きですが）、解析がさらに難しくなる可能性があると思います。

そうかもしれません。 これを表現する別の方法がありますが、私も考えていません。 正直なところ、これはツールバーのより単純な追加の「ブロックツリー」アイコンであり、親要素または子要素に自動的に追加されます。

もう1つの懸念は、ツールバーが長くなっていることです。 これは大したことではないかもしれませんが、アイコン＃10524と＃15311のラベルを含めるとそうなる可能性があります。

同意しました。 これが方向性であるかどうかにかかわらず、とにかく非常に長いツールバーの解決策を整理する必要があります。 https://github.com/WordPress/gutenberg/issues/のようなツールバー階層のより包括的な再考と同様に、 https：//github.com/WordPress/gutenberg/pull/16557のような取り組みがこれに少し役立つと思います。 15096。

ツールバーボタンとしてのブロックツリーのアイデアについて私が驚いたことの1つは、ブロック自体に固有のものを参照せず、ブロックがどのように関連しているかについて、ブロックツールバーアイテムであるという点で独特であるということですドキュメントの残りの部分。

これは何よりも面白味がありますが、グラフィックアプリからの類推を使用すると、このタイプの「階層化」および「グループ化」UIは通常（私が間違っていることを証明する例があると確信しています）、_ document_レベルでのみ存在します。ブロックレベルでアクセスできるのではなく。

ブロックとドキュメントレベルのツールの間の「ギャップ」にはさまざまなアクセシビリティの問題があることを私は知っています。ブロックレベルでそれを使用すると、ナビゲーションが簡単になる場合があります。

これは何よりも面白味があります…このツールの何かは、ブロックを他のコンテキストに関連付ける方法に関して、ツールバーで使用可能な他のツールとはかなり異なっているように感じます。

これは何よりも面白味があります…このツールの何かは、ブロックを他のコンテキストに関連付ける方法に関して、ツールバーで使用可能な他のツールとはかなり異なっているように感じます。

ええ、私も同じ気持ちです。

現在、上部のツールバーにそのコントロールがありますが、これはブロック自体から離れすぎているようです。 たぶん、サイドバーは実際にそれのための最高の場所ですか？ コントロールはブロックに関連付けられているように見えますが、独自の個別のツールバーとして使用されますが、別のツールバーを追加することは絶対に避けたいと思います。 😄

現在、上部のツールバーにそのコントロールがありますが、これはブロック自体から離れすぎているようです。

また、これはグーテンベルクのデフォルト設定でのみ当てはまると付け加えておきます。 誰かが[トップツールバー]オプションを選択してすべてのブロックツールバーをトップツールバーに移動した場合、これは間違いなく当てはまりません。 しかし、そうは言っても、大多数のユーザーがその設定を変更するのではないかと思います。

別の注意点として、グーテンベルクのデフォルト設定であるトップツールバー設定に人々がどのように反応するかを本当に知りたいと思います。 これは、クラシックエディターとの整合性が高く、新しいグーテンベルクユーザーにより親しみやすいものになります。

このツールバー設定は多くの調査が行われ、かなりのテストを行った後、最適なデフォルトが決定されました。 探索の詳細については、 https ：

大多数のユーザーがその設定を変更するのではないかと思います。

ツールバーの位置は非常に個人的な設定であることがわかりました。 テストのフェーズ1で、WordPressを使い始めた人がブロックに好まれ、経験豊富な人が一番上にいることがわかりました。 ツールバーは両方の場所でデフォルト設定されており、これが現在の最良のオプションです。 また、これがおそらく、クラシックエディタとの整合性が高いと感じる理由です。 個人的には、デフォルトを変更しないことをお勧めします。

@ jasmussen ＃17088を優先してこれを閉じる必要があります

はい、できると思います。 このチケットは発散的に探索されましたが、他のチケットは現在、いくつかのアイデアを洗練しています。 このチケットは、新しいチケットのThanks Riadの参照に従えば、引き続き見つけることができます。