面白いアイデア@melchoyce。

私の最初の反応は、それらを一番下に移動することで、ブロックがより「ブロック状」になる方法でした。これは奇妙なことですが、これは私に感じさせます。 クリックまたはホバーで境界線が表示されていますか？ ホバーしている場合よりもクリックした場合の方が問題が少ないと思います。 別の興味深いビジュアルは、少なくともあなたの例をポラロイド画像のように見せます。私の脳がそこにどのように進んだかは非常に興味深いものです。

それが私の最初の反応ですが、もう少し掘り下げると、ブロック上のインタラクションアイコンの別の位置を探索するメリットがあると思います。 彼女が得たものは、絶対にすべての画面でうまく機能する方法だと思います。さらなる調査が行われるときに、ガイドとして保持する必要があります。

私たちは相互作用の文脈を失うと思います。 たとえば、プレースホルダーが高いブロックでは、これらの相互作用が直接表示されません。 それは、発見可能性を低下させる可能性のある問題になると思います。

とはいえ、私たちが今持っているものが前進するべきだとは絶対に言っていません。 あなたは繰り返して、多分もっと探求するつもりですか？ 私は本当にあなたがそうであることを望みます。

視覚的にはこれはいいと思います。 これは基本的に、デスクトップブレークポイント上のモバイルUIであり、サイドUIが機能しなかった場合、またはネストされたコンテキストの場合は、プランBと見なしたものです。

それ以来、私たちは両方ともサイドUIで進歩を遂げ、最近ではhttps://github.com/WordPress/gutenberg/pull/6141で、ネストされたコンテキストでも適切に機能するようになりました。アスペクトにはまだ愛が必要です。

Althougnはそれほどきれいではありませんが、このUIを側面に配置することの主な利点は、

1. ホバーに表示できること
2. ブロックのフットプリントを拡大しません

1は特に重要です。最初から、ドラッグアンドドロップが_additive_であることを確認することが明確な目標であり、ブロックの配置、並べ替え、並べ替えとの主要な相互作用ではないためです。 それらをブロックの下に配置すると、おそらくクリック時に表示され、ドラッグアンドドロップの二次的なものになり、常にホバーで機能します。

2は、ネストされたコンテキストでサイドUIをどのように処理するかによっては重要になる可能性があります。 現在、 https： //github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863でいくつかの課題に直面しています。これらは解決できると確信していますが、フットプリントが解決しないという事実変更しないでください。

これはすべて、「機能しない」と言っているのではありません。非常にうまく機能する可能性があります。 昔のモックアップでは、このUIが隅のオーバーレイとして使用されていました。

全体として、良いアイデアであり、リリースごとに受け取ったフィードバックに応じて探索できる手段として、それらをヌードルに保持するのは良いことです。

クリックまたはホバーで境界線が表示されていますか？

クリックするだけです。 ホバーは、現在の動作と似ています。

あなたは繰り返して、多分もっと探求するつもりですか？ 私は本当にあなたがそうであることを望みます。

常に👍

ブロックのフットプリントを拡大しません

ええ、間違いなくこのアイデアの問題です。 このプロトタイプでも、サイズが変更されたためにジャンプすることがあります。

全体として、良いアイデアであり、リリースごとに受け取ったフィードバックに応じて探索できる手段として、それらをヌードルに保持するのは良いことです。

👍👍

私たちは相互作用の文脈を失うと思います。 たとえば、プレースホルダーが高いブロックでは、これらの相互作用が直接表示されません。 それは、発見可能性を低下させる可能性のある問題になると思います。

Althougnはそれほどきれいではありませんが、このUIを側面に配置することの主な利点は、

1. ホバーに表示できること
2. ブロックのフットプリントを拡大しません

これらの問題を解決する1つの方法は、ブロックツールツールバーを下のブロックの上に表示し、ブロックがエディターで実際に占めるスペースを増やさないことだと思います。 背の高いブロックでの発見可能性については、上にスクロールしてもツールバーが画面から消えないように、ツールバーを粘着性にすることができます。 （もちろん、ブロックにカーソルを合わせないと消えます。おそらく、サイドコントロールが現在機能しているのと同じように、現在表示されているブロックの下部にカーソルを合わせると表示される可能性があります。）この号のメインポストのモックアップのように、すべてのボタンを表示するために必要なだけのスペースを確保し、2セットのコントロール間の空のスペースの行全体を占有しないようにします。

+1これは、ブロック周辺のUIコントロールのタブ順序を改善するのにも役立つ可能性があることに注意してください。 https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531で説明されているように、モバイルUIには、より論理的な方法で配置された「サイドコントロール」があります。 タブの順序を示すアニメーションGIFを参照してください。前のコメントで、デスクトップビューのタブの順序で前のGIFと比較でき

また、考慮に入れるために：

3976は、ブロックツールバー（フォーマットツールバー）をブロックの下に配置する3番目のオプションを提案しています。 ブロックツールバーとブロックの下に配置されたサイドコントロールの両方を備えたデザインを検討して、それが機能するかどうかを確認するのは素晴らしいことです。

タブ順序の一貫性に関する一般的な問題としての1934年

これは、＃6272で提起された問題のいくつかの解決にも影響を与える可能性があります。

背の高いブロックでの発見可能性については、上にスクロールしてもツールバーが画面から消えないように、ツールバーを粘着性にすることができます。

はい、それは上部の書式設定ツールバーでも起こります。

ここですべての素晴らしいフィードバックを読むと、これにより、今後および今日のアクセシビリティに関する多くの問題が解決されるようです。 そのことを念頭に置いて、ここでいくつかのイテレーションに取り組み、PRに移行してプロトタイプを作成する必要があると思います。 @melchoyceをやってみませんか？

ええ、私は別の見方をすることができます。

これを試してみると+10。

これは、ブラウザウィンドウの幅を縮小したときのブロックUIの外観です。 （もう少し縮小すると、ブロックツールバーがブロックの下に移動しますが、それは私が提案していることとは関係ありません。）

ブロックインサーターが上下の動きのコントロールの横に表示されていることに気づきました。 この問題が提案しているように、この種のUIがすべての画面サイズに使用された場合、ネストされたブロックコンテキストから現在のブロックアペンダーを削除して、常に存在する余分なスペースを削除することで、エディターをフロントエンドのように見せることができます。ネストの各レベルのすべてのブロックアペンダーによって。 （＃6834のappender-eating-up-spaceの問題に対する代替ソリューションも提案しました。）

また、これは単なる補足ですが、[削除]ボタンは[その他のオプション]ボタンの右側にあるはずですか、それとも左側にある必要がありますか？ ほとんどのUIデザインでは、省略記号メニューは右端に配置されています。

別のアイデア：

これらのブロックコントロールをホバーの下部に表示しますが、この状態では、ページ上のスペースを占有せず、代わりに、ホバーされたブロックの下にあるものの上に表示されます（ブロックツールバーが現在の上のブロックに対して行うのと同じように） 1）またはホバーされたブロックの上に。 下部のブロックコントロールも、ホバー時に途切れのない白いバーではなく、ブロックツールバーと同様に、コントロールが占めるスペースを減らし、カバーしすぎないようにするために、両側に2つの小さなバーにする必要があります。

ブロックを選択すると、下部のブロックコントロールがスペースを占有し、ブロックの視覚的なフットプリントが増加し、下のブロックが邪魔にならないように押し出されます。たとえば、画像ブロックを選択すると、キャプションプレースホルダーが表示されます。 これにより、1行の段落ブロックのように垂直方向に短いブロックの場合、下のブロックを簡単に選択できます。

このアプローチにより、現在のホバーコントロールの利点を維持し、最初にブロックを選択せず​​にブロックを簡単に移動/削除できるようにすると同時に、ブロックの編集時にコントロールが何も隠さないようにすることができます。その後、別のブロックを選択する方が簡単です。

もう1つのアイデア：

ブロックコントロールバー全体（およびブロックツールバー）がドラッグハンドル（GTKヘッダーバーの動作などのボタンを含む）を兼ねることができます。 これにより、ドラッグアンドドロップによる検出可能性の問題がほぼ解決されると思います。特に、選択したブロックのコンテキストでは、下部のコントロールバーが最初の投稿のモックアップのブロックの一部であるように見えるため、ユーザーはおそらくドラッグハンドルとして使用しようと考える可能性が高くなります。

ブロックの側面がブロックの一部であるように見えない現在の状況とは対照的に、したがって、それらがドラッグハンドルとして機能できることはそれほど明白ではなく、単一行の段落ブロックの問題もあります。ドラッグするための空きスペースが側面にほとんどありません。 （現在、サイドコントロールボタンは無効にしない限りドラッグハンドルとして使用できないため、問題はさらに悪化します。）

これに関する素晴らしい議論がたくさんあります。@ melchoyceでイテレーションに移行するための何かを提供できるように、要約フィードバックを提供できるかどうかを見てみましょう。

全体的に、私はプロトタイプでこれを感じる必要があると思います、そして私が思う多くの私の考えはそれで和らげることができると思います。 ただし、モックを作成したいいくつかの考慮事項があります。

• 背の高いブロックのソリューション。
• 「ブロック感」が少ない：これは、プレースホルダーの状態をモックで示しているだけかもしれません。これらの変更により、より明白なものとして読んでいます。
• これがネストでどのように機能するかを示します。

これがさまざまなデバイスにもどのように適応するかを見てみたいと思います。バリエーションが少なく、それは素晴らしいことだと思います。

@SuperGeniusZebあなたがそこに持っているいくつかの興味深い考え。 Melが上記の反復でどこに到達するかを確認したいと思います。 ハンドルをドラッグするためにUIを2倍にすることは、今のところ避けるべきことだと思います。そこに入れたいネストの変更が行われています。 繰り返さないと言っているわけではありませんが、このUIは特にそのためのものではありません。 また、視覚的に明示しなくても所属を推測できると思います。それが明確になりすぎるのは、ブロックの否定的な感覚が入り込むところです。それは、近すぎて制限しすぎているように感じます。

私は＃7211をうなずいていて、その作業のコンテキストで＃7646を発見しました。それにより、このアイデアに戻りました。これは、多くの問題に対する最善の解決策のように感じます。

このチケットは、直接的または間接的に、多くのことを修正します。

• ＃7646→コントロールが上下に配置されているので、サイドUIの調整について心配する必要はありません
• ＃7182→このチケットのモックアップにあるようなコントロールはブロックに直接接続されており、ネストレベルに関係なく一貫したUIを持ちます
• ＃6451→上部/下部ツールバーの背景が塗りつぶされている場合、暗い背景でコントロールを表示する方法を考える必要はありません。
• ＃7114 /＃6265→上記のモックアップのように全幅ツールバーを使用する場合は、空の領域をドラッグアンドドロップに使用できます。

とはいえ、これほど大きな変化がグーテンベルクに上陸する可能性がまだあるのなら、それは多くの問題を解決し、多くのことをより簡単にすることができると思います:)私は楽しみに参加して取り組むつもりですうまくいけば今週末にいくつかのモックアップ/コンセプト。

@chrisvanpattenパースペクティブを追加する

タブの順序が大幅に改善されるので、これを試すことに完全に賛成です。 クイックアップデート：「ごみ箱」の削除ボタンが省略記号メニュー内に移動しました。 また、コントロールのすることをお勧めします。 なぜこれまで右に留まるべきなのかわからない：

@aferciaは異なるコントロールであるため、右側に省略記号を

背の高いブロックのソリューション。
「ブロック感」が少ない：これは、プレースホルダーの状態をモックで示しているだけかもしれません。これらの変更により、より明白なものとして読んでいます。
これがネストでどのように機能するかを示します。

これらのポイントは、この有望なポイントからのルートを決定するために探索する必要があります。

@karmatosed私は紛らわしい用語を使用していました-私はツールバーではなくコントロールを意味しました。 ツールバーはすでに上にあります-そこで変更するものは何もありません:)

ブロックの下に置くと、ブロックツールがどのように見えるかをモックアップしました。 これらのモックアップでは、ブロックツールがスペースを占有することはなく、デスクトップのブロックツールバーのようにオーバーレイとしてのみ機能することに注意してください。 これらのモックアップでは、ブロックも選択されています。 ブロックにカーソルを合わせるだけの場合、上部のブロックツールバーは表示されません。 また、下部のコントロールは、現在のサイドコントロールのように、近くにカーソルを合わせた場合にのみ表示される可能性があることにも注意してください。

正常：

ブロックの下部が画面外にある場合：

（補足：画像ブロックツールバーは、ブロックツールバーにさまざまなオプションがあるため、これらのモックアップのツールバーとは一致しません。）

ブロックツールが側面にあるという問題と、それらを下部に配置することのいくつかの利点を考えると、私は今、それらを下部に配置することが進むべき道であると確信しています。

@SuperGeniusZebこれは基本的に私が考えていたものですが、[その他のオプション]ボタンを、結合されたツールバーとして、右ではなく上/下矢印で配置する予定でした。

@chrisvanpattenええ、コントロールが分離されていてもいなくてもかまいません。

ここにいくつかのモックアップがあります：

ホバー：

モバイルのように（単なるオーバーレイではなく）スペースを占有し、ドラッグハンドルとしても使用できる全角バーで選択されます。

私たちはこれがブロックになりすぎる危険性があると思うと言わなければなりません...これはこれを説明する奇妙な方法ですが、それと一緒に行きます:)たとえば、最後のモックで示されたホバーは非常に激しいです。 境界線が1つ少ない最初の画像でメルが示したものについては、これをもっと見なければならないと思います。それがないのは本当に助かります。

私は最初のモックを取り、ゴミ箱を取り外して、進行するのに最適だと思うものを取得しました。

余分な境界線は必要ありませんし、ウェイトを追加する必要もありません。 このようにして、異常なホバリングアウトラインなしで簡単にドラッグできます。

@karmatosedモックアップを変更して、ブロックに

そして、ここにブロックが選択され、ブロックツールバーが表示されています。

（また、画像ブロックのプレースホルダーを更新して、グーテンベルクの現在のプレースホルダーと一致させました。）

コントロールに上部の境界線がないことについて私を混乱させるようなものがあります。コントロールはまだ白い背景にありますか？ これは、ブロック全体の背後に白い背景があることを意味しますか？ 選択（および/またはホバー）するとブロックの背景が変化し、非常に不快に見えるため、ブロックが暗い背景のコンテナにネストされているネストされたコンテキストで問題が発生するようです。

コントロールに上部の境界線がないことについて私を混乱させるようなものがあります。コントロールはまだ白い背景にありますか？ これは、ブロック全体の背後に白い背景があることを意味しますか？

ありますが、コントロールにはターゲットがあります。 表示する価値があり、ブロックの視覚的な問題を回避できると思います。 これは、ネストを検討する必要がありますが、背景がないと、視覚的にネストするとさらに悪化します。

ありますが、コントロールにはターゲットがあります。 表示する価値があり、ブロックの視覚的な問題を回避できると思います。 これは、ネストを検討する必要がありますが、背景がないと、視覚的にネストするとさらに悪化します。

同意し、背景を持つことで＃6451も解決します。

最後のモックアップでホバーに大きな空のバーを表示するのは好きではありません。 理想的には、ホバー時に周囲のブロックをできるだけカバーしないようにしますが、これは下のブロックのかなりの部分をカバーします。 このようなものはどうですか？

前に提案したように、矢印ムーバーと省略記号はドラッグハンドルを兼ねたり、ホバータイトルをドラッグハンドルにすることができます。 （＃7114を参照してください。）

@SuperGeniusZebこの場合のポイントは理解していますが、ブロックの輪郭を

選択したブロックの後ろに白い背景が表示されることに気付いたことがあります。暗い色の領域（Containerブロックなどによって提供される）に表示されることを意図した白い（または明るい色の）テキストカラーのブロックはどうですか？ この場合、ブロック全体の背景を白にすることはできません。

背景は、常にこれらのコントロールを持つツールバーの周りにあります。

@SuperGeniusZebええ、白い背景がブロック自体に影響を与えているのではなく、コントロールだけに影響を与えています。 実際には、次のようになります。

または、パディングが削除される可能性があります（私はこのアプローチが本当に好きですが、ドラッグアンドドロップで影響を与えるより大きな質問です。それでも検討する価値があると思います）：

@chrisvanpatten最後のモックアップが好きです。 下部のバーがドラッグハンドルとして機能する可能性があるため、ドラッグアンドドロップが問題になるとは思いません（バーのボタンも1つとして機能する可能性があります）。 ホバーの下部のバーにドラッグハンドルアイコンを追加することも、それを使用してブロックをドラッグできることを示すために常にアイコンを表示することもできます。

このアプローチでは、ドラッグ可能な領域をブロックの境界近くに維持する理由がわかりません。 そのパディングを削除すると、ブロックのホバー/選択したアウトラインをブロックの実際の境界に近づけることができます。これは、ドラッグスペースを考慮する必要がなくなり、実際のブロックよりも大きくなるように調整するだけでよいためです。親ブロックの選択を容易にするためのネストの場合。 （＃6459のこのコメントのモックアップのようなものが実装されていれば、親ブロックの選択はそれほど問題になりません。）

@SuperGeniusZeb

ホバーの下部のバーにドラッグハンドルアイコンを追加することも、それを使用してブロックをドラッグできることを示すために常にアイコンを表示することもできます。

素晴らしいアイデア💡

ドラッグ可能な領域を片側に残して、これを実装しましょう。 これが解決していることを最初に解決することに集中することが重要です。 アイコンが正しいアプローチであるかどうかはわかりませんが、それなしでこれを実装したら、もう一度見てみましょう。

@karmatosed

ドラッグ可能な領域を片側に残して、これを実装しましょう。

これが何を意味するのかよくわかりませんか？ どちら側？

これが起こるのを見てうれしいです。 視覚的な配置だけではないことを簡単に思い出してください。 a11yの場合、視覚的な順序とタブの順序（DOMの順序）が一致する必要があるため、これらの「ブロックツール」は、実際にはマークアップのブロック編集可能領域の後に移動する必要があります。

ブロックの下のコントロールに切り替えることの優れた利点の1つは、サイドスペースが開いて、現在のデザインで問題が発生した場合に兄弟インサーターをSquarespaceのようなものに再設計できることです。 現在のサイドコントロールはこの種のインサーターと重なっていて雑然と見えますが、コントロールを下に移動すると、これは問題ではなくなります。

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-points

＃7500でこれについてコメントしました。 このデザインでは、連続する段落がどのように見えるのだろうかと思っていました。 下部にバーがあると、段落間にかなり大きなギャップが生じると思います。

@ talldan ＃7500から自分自身を引用：

ブロックコントロールはホバー時にスペースを占有しません（ブロックツールバーが現在スペースを占有しないのと同じように）。私が知る限り、選択したブロックでスペースを占有するかどうかはまだ決定されていません。 そしてもちろん、コントロールは、選択されているか、ホバーされているブロックに対してのみ表示されます。 ブロック間の標準距離は、変更の影響を受けないはずです。 選択したブロックのみが影響を受ける可能性があります。

これは本当に良さそうです、私はそれですべてです。

これで考慮すべきことの1つは、これまでにないことです。 長いブロックはどうですか？ それらとブロックのあるエディター画面の下部はどうなりますか？

ブロックが長すぎてスクロールして見えなくなるということですか？ それが起こる前に、人々はそれがどのように機能するかを見て、どこでそれを見つけるかを知っていると思います。 小さな画面に長い段落をたくさん書くと、それが煩わしくなるかどうかをテストする必要があります。 しかし、私はそれがモバイル体験をよりよく反映しているのが好きです。 投稿の最後のブロックについて、どのような懸念がありますか？

最初のブロックが本当に長いブロックであるかどうかをどのように確認しますか？

少なくともそれについてのNUXのヒントを追加する必要があります;）しかし、あなたが心配しているのは、誰かが1つの長い段落であるか、ブロックに正しく変換されていない既存の投稿を開いた場合です。 それは可能です...彼らが新しい投稿を開始した場合、彼らはほぼ確実に最初のプレースホルダーブロックにそれを見るでしょう？

これについて考えると、ここでは、コントロールをブロックの上部に配置するという調査は見当たりません。これはオプションになる可能性があります。 そのための簡単なモックアップを行いました。 （バーの組み合わせについてもここで説明します）

ブロックが高すぎる場合、上部のコントロールが上部に固定される方法や、モバイルでどのように機能するかなど、下部のコントロールが画面の下部に固定されませんか？

@hedgefield私はそれがとても好きですが、狭いコンテキスト（列ブロックなど）や長いツールバーではうまく機能しません。

@hedgefield @chrisvanpatten幅が薄い場合、矢印/省略記号コントロールが書式設定コントロールの下（または上）に移動する可能性がありますか？

@karmatosedコントロールは粘着性があり、画面の下部に表示されたままになる可能性があります。 ただし、これにより、書き始めるたびに段落に書き込もうとしている行をカバーするコントロールのこの問題が発生します（おそらく、現在のように入力中に非表示になります）。 しかしとにかく、その解決策は疑わしいようです。

ただし、 @ hedgefieldによるモックアップに戻ると、

アクセシビリティの懸念もあります。 @hedgefieldによるモックアップには、視覚的にブロックの前にあるすべてのコントロールがあります。 理想的には、マークアップのブロックの後に来る必要があります。 理論的には、CSSを使用して、コントロールをマークアップのブロックの後に配置し、視覚的にはその上に表示することができます。 ただし、これを実際に実装するのがどれほど難しいかはわかりません。また、外観とソースの順序の間に矛盾が発生するかどうかもわかりません。 個人的には気にしません。マークアップのブロックの後にすべてのブロックコントロールが表示されるため、キーボードからコントロールを見つけるのがはるかに直感的になります。これは、後方に移動するのではなく、前方にタブで移動できるためです。

外観とソースの順序の不一致が望ましいかどうかはわかりません

そのための特定のWCAG成功基準がある時点では望ましくありません：
https://www.w3.org/TR/WCAG21/#focus -order

コントロールは粘着性があり、画面の下部に表示されたままになる可能性があります。 ただし、これにより、書き始めるたびに段落に書き込もうとしている行をカバーするコントロールのこの問題が発生します（おそらく、現在のように入力中に非表示になります）。 しかしとにかく、その解決策は疑わしいようです。

実際、もう少し考えてみると、段落が画面の下部のすぐ隣にない限り、コントロールは実際には段落の最後の行をカバーしないので、＃353はこれを問題にしない可能性があります。 また、＃353がなくても、下にスクロールするだけで済み（とにかくほとんどの人が行うことです）、前述のように、コントロールはマウスを動かしたときにのみ表示されます。 気が変わった。 これはうまくいくかもしれません！

幅の広いブロックの場合はどのようになりますか：

薄いブロックの場合はどのようになりますか：

さらに薄いブロック（8列か何かを考えてください）：

私はこのデザインが本当に好きになり始めていると思います。 幅の広いブロックの場合、矢印ムーバーコントロールをフォーマットコントロールの左側に配置するか、右側に配置するかはわかりません。

探索に感謝しますが、すべてを1行にまとめると、さまざまなアクションが1つの場所にマージされます。 それが理にかなっているのかわかりません。 また、誰かがツールバーを上部に貼り付けたときに何が起こるかについても考慮します。彼らは「所定の位置に」何かを持たないことを選択しており、現在はコントロールがあります。 ツールバーにブロックコントロールを設定できないため、これは経験に満たないように感じます。これは非常に奇妙な経験です。

ただし、すべてを1行にまとめると、さまざまなアクションが1か所にマージされます。

悪魔の代弁者を演じるのは、定義上、ツールバーの目的ではありませんか？

さらに付け加えると、特定のコントロールを分離する背後にある考え方は理解できますが、この場合、それについて説得力のある十分な議論があるかどうかはわかりません。 ツールバーはツールバーです。 特定のツールが特定の場所に属し、他のツールが他の場所に属し、プラグインがとにかく無視するというあいまいな理由を考え出すのではなく、特定のブロックのすべてのコントロールを1つの場所に配置することは論理的に理にかなっています。

@karmatosedコントロールを色で分離するのはどうですか？

@SuperGeniusZeb残念ながら、それは私の他のポイントを解決しません。そして、それが機能するかどうかは

この場合は、うまくいくと思われるデザインに合わせようとする場合だと思います。 一歩下がって、私が提起した他の点を考慮してみませんか？

@chrisvanpattenツールバーは、定義上、すべてを配置する場所ではありません。便利なツールバーには、コンテキストと順序が必要です。 ユーザーとして、正しいオプションがあることを期待する必要があります。 単数形の単語の意味についてはしばらく議論することができますが、それを行うのは楽しいことですが、これが一度に非常に多くのことを組み合わせて、より多くの人々にとって問題になるという事実を見失うことはできません。

@karmatosedそれでは。 編集ツールバーを上に戻すことに戻りましょう。

（バーの上の青い線がそこにあるべきかどうかはわかりません。）

このデザインに何か問題はありますか？ 編集ツールバーは、アクセシビリティのためにソース順でブロックの後に表示されるようにすることができます。 理想的ではありませんが、編集ツールバーをブロックの下に配置することは実行可能なオプションではないように思われるため、私たちにできることはそれだけのようです。

また、私はちょうど考えを持っていました：下部のバーがホバー時に部分的に透明である場合はどうなりますか？ それで軽く感じますか？

@SuperGeniusZebビューを取得するためだけに、カラフルなモックを少なくすることを提案できますか？ 提案されていることは理解していますが、インターフェイスを独立させることは、視覚的な複雑さなしに簡単になります。

次のステップのモックを取得するためだけに。 @SuperGeniusZeb画面（通常のデスクトップサイズ）と非常に長いブロックのコンテキストで、上記はどのように見えますか？ 一番下にブロックがあるとどうなりますか？ 理想的には、少し透明度を確保し、今回は色ではなくUIに焦点を当てることについての私のコメントを検討しましょう。

いくつかのモックアップ：

コントロールバーの上部に境界線があります

コントロールバーの上部に境界線なし

ツールバーはホバー時にスペースを占有しませんが、ブロックが選択されている場合はスペースを占有することに注意してください。

これらのモックアップを作成しているときに、私は何かに気づきました。このような状況で何をすべきか？

ここでは、選択したブロックの書式設定ツールバーとホバーしたブロックの下部のコントロールの両方を表示することの間に矛盾があります。 書式設定ツールバーが下部にある場合（またはブロックコントロールがすべて上部にある場合）、これは問題にはなりませんが、ここでは、下に示すコントロールと上に示すコントロールの組み合わせが問題を引き起こします。

私が考えることができる最善の解決策は、ホバーされたブロックとそのツールバーのz-indexを高くし、下のブロックとその書式設定ツールバーの上に表示することです。 ただし、これが正しいアプローチかどうかはわかりません。 これがどのように見えるかのモックアップは次のとおりです。

また、下部のバーとブロックコンテンツの間に境界線がない場合：

ホバーされたブロックが選択されたブロックと重なるという考えはあまり好きではありませんが、そうでなければ、選択されたブロックの真上にあるホバーされたブロックの下部のバーを使用する方法がわかりません。 少なくともデスクトップでは、すべてのコントロールを上部または下部の1つのバーに配置する方がよいとは限りませんか？ それは確かにこのような問題を防ぐでしょう。

@SuperGeniusZeb私はどういうわけかそれらのモックアップを見逃していました。 それらを作ってくれてありがとう！

それは私が考えていなかった本当に素晴らしいポイントです（選択したブロックの上にブロックを置く）。 それは間違いなく問題です。 常駐ページビルダーの専門家として、このような階層化されたツールバーを備えた他のページビルダーに同様のパターンはありますか？

また、その価値については、ツールバーを常にホバーするか、選択するかどうかを選択する必要があると思います。 スペースをとることが_時々_あると、コンテンツがジャンプし、全体的に厄介な体験になります。

@chrisvanpatten私が見たすべてのページビルダーには、モジュール/ウィジェットの上部に表示されるコントロール（兄弟

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

ビデオには表示されていませんが、モジュール内のテキストをクリックするとDiviの書式設定ツールバーが表示され、書き込んでいる行の上に小さなポップアップが表示されます。

Elementorはほぼ同じことをします。

Beaver Builderで、ウィジェット内のテキストをクリックすると、マウスがウィジェットの境界の外側に移動するまで、ブロックコントロールツールバーがフォーマットツールバーに置き換えられます。これにより、次にウィジェットにカーソルを合わせると、標準のブロックコントロールが表示されます。 、ただし、ウィジェットに入力することはできます。 テキストをもう一度クリックすると、書式設定ツールバーが標準ツールバーに置き換わります。

また、その価値については、ツールバーを常にホバーするか、選択するかどうかを選択する必要があると思います。 時々スペースをとることは、全体的にもっと厄介な経験であるジャンプするコンテンツにつながります。

本当ですが、これがクリーンなUIを持つことへの影響について心配しています。 上記のコンテンツの一部と重複する書式設定ツールバーがある場合は、問題ありません。 しかし、ブロックの下部に全幅のバーを追加すると、他の多くのコンテンツが重なってしまいます。

理想的には、すべてのコントロールをブロックの上部または下部に配置する必要があります。 これにより、ほとんどの場合、ツールバーが互いに重なり合うのを防ぐことができます。 アクセシビリティのために、コントロールを下部に配置するのが理想的です。 ただし、ツールバーが段落ブロックのようなもので書いているコンテンツと重なっているという問題が発生する可能性があります。 ただし、矢印ムーバーと省略記号はほとんど頻繁に使用されるものではないため、常に表示する必要があるのは書式設定ツールバーのみであることに注意してください。 また、ブロックのコンテンツの現在編集中の部分が画面の下部から十分に離れている場合は、書式設定ツールバーを重ねる必要はありません。

コントロールを下に配置するのが面倒だと感じる場合は、次善の策はすべてを上に配置することだと思われます。 もちろん、コントロールが薄いブロックを探しにくいという潜在的な問題があります。

デスクトップとモバイルの場合、通常はツールバーの位置を変更することで回避できます。 現在、フォーマットツールバーとその他のコントロールはすべて、現在選択されているブロックの下に表示され、モバイルでスペースを占有します。

ただし、幅の広いブロックと薄いブロックの場合、薄いブロックのコントロールを移動すると、扱いにくいと感じることがあります。 最も一貫性のある外観は、上部に書式設定ツールバーを、下部に他のコントロールを配置することです。 しかし、それはツールバーの重複とコンテンツの重複量の増加の問題に戻ります。

グーテンベルクは、選択したブロックの外観が編集用に最適化されるという考えに基づいて設計されているため、ブロックを選択することで、ブロックの周りのものだけを移動し、移動しない限り、ツールバーに物理的なスペースを占有させることはそれほど悪くないと思います。選択したブロック自体。

結局、これらのモックアップはまだかなり良い選択肢だと思います。 完璧ではありませんが、アクセシビリティの観点からは理にかなっています。見た目も悪くなく、モバイルとの一貫性があり、ツールバーが重なることはめったにありません。

これがどのように機能するかについてのいくつかのメモ：

コントロールはホバー時にスペースを占有しませんが、ブロックが選択されている場合はスペースを占有します。 ブロックにカーソルを合わせると、矢印ムーバーと省略記号のみが表示されますが、ブロックを選択すると、書式設定ツールバーが表示され、他のコントロールが下に押し出されます。 これはおそらくこの設計の最大の問題です。 これを最適に機能させるには、ムーバー/省略記号ツールバーをクリックしてブロックを選択するときにブロックのコンテンツを上に押し上げたいと思いますが、コンテンツ領域をクリックしてブロックを選択した場合はツールバーを移動する必要があります。

ブロックがコンテンツ領域の下に伸びると、矢印ムーバーと省略記号は画面外に表示されますが、書式設定ツールバーは表示されたままになり、画面の下部（またはコンテンツエディター領域）に固定されます。

これが最善の解決策ではない場合は、基本的に同じことを行いますが、コントロールがすべて上にあり、ムーバー/省略記号が薄いブロックの書式設定ツールバーの上に表示され、おそらくの書式設定コントロールの左側に表示されます広いブロック。 モバイルは今でもそう見えるかもしれません。

別の考え：ホバー時にコントロールを表示しなかった場合は、シフトコントロールの問題とツールバーが互いに重なっている問題の両方を取り除くことができます。 これにより、ブロックの上部と下部の両方にツールバーを表示することはそれほど問題になりません。 ただし、もちろん、ホバーにコントロールを表示するメリットは失われます。 それが誰もが行きたい方向かどうかはよくわかりませんが、それが必要かどうか疑問に思い始めています。

ホバーされたブロックが重なるという考えも、私が好きなものではないと言わざるを得ません。 これにはもう少し考えが必要だと思います。 コントロールがホバー時に異なるスペースを占める可能性があるという考えは、少し厄介な感じがします。

コントロールはホバー時にスペースを占有しませんが、ブロックが選択されている場合はスペースを占有します。 ブロックにカーソルを合わせると、矢印ムーバーと省略記号のみが表示されますが、ブロックを選択すると、書式設定ツールバーが表示され、他のコントロールが下に押し出されます。 これはおそらくこの設計の最大の問題です。

これはモックの大きな問題だと思います。 他に何が起こる可能性がありますか？

ページビルダーを見ることは1つの側面ですが、他のアプリや製品についてはどうでしょうか。 これはどこかで解決されていますか？

@karmatosed

ページビルダーを見ることは1つの側面ですが、他のアプリや製品についてはどうでしょうか。 これはどこかで解決されていますか？

グーテンベルクが行うすべてのことを説明する必要はほとんどないため、グーテンベルクが使用できるUIの類似の例を見つけることは困難です。

すべてのコンテンツ編集はモーダルまたはサイドバーで行われるため、多くのより単純な/古いページビルダープラグインは、ブロックに相当するコンテンツを隠すことを心配する必要はありません。 これにより、モジュールコントロールがコンテンツとオーバーラップできるように解放されます。

モーダル/サイドバーを開かずにテキストを編集できるDiviやBeaverBuilderのような場合でも、モーダル/サイドバーが主な編集方法です。 DiviとBeaverBuilderはどちらも、フロントエンドの本質的に完全なレプリカであり、テキストエディターとして使用したり、主要なブロックコンテンツの大部分をインラインで編集できるようにするなどの最適化を心配する必要はありません。ブロック。

さらに、ページビルダーと他のビルダー風のUIの両方で、ネストできるものに制限があるため、ネストの問題ははるかに少ない傾向があります。 Diviには、厳密なセクション→行（列が組み込まれている）→モジュールのセットアップがあります（ただし、いくつかの一般的なネストされた列の状況のた​​めにいくつかの特殊セクションが考案されています）。 Beaver Builderでは、Elementorと同様に、列を列にネストすることのみが許可されています。 これらは、複数のネストレイヤーを持つことができる唯一の種類のオブジェクトを制御します。 デフォルトでは、すべてが1行のセクションにあります。 ネストされたブロックの無制限のレイヤーはなく、さまざまな目的やグーテンベルクが許可するようなさまざまなスタイルでネストを使用するカスタムブロックの任意の組み合わせの可能性があります。

Diviは厳密な構造を持ち、セクションまたは行として機能するカスタムモジュールがないため、セクション、行、およびモジュールのコントロールを色分けできます。 （これにより、同じ行に複数の挿入ボタンを表示することもできますが、それぞれが何をするかを区別するために異なる色で表示されます。）ほとんどのビルダーでは、モジュールはレイアウト要素から分離されています。 モジュールとレイアウト要素が分離されているため、BeaverBuilderは同様のことを実行できます。

テキストエディタのように、ページビルダーではないものを見ると、ページビルダーが処理しなければならないすべてのことを心配する必要がないことがわかります。 ほとんどのページビルダーを見ると、直接インラインWYSIWYGコントロールを介してテキストエディターのものを処理していません。

グーテンベルクがやろうとしていることは独特です。 これは、完全なテキストエディタでもある、編集用に最適化された選択ブロックを除くWYSIWYGを目指しており、セクションから列、ウィジェットまですべて同じ種類です。オブジェクトの：ブロック。

基本的に、これは複雑な問題です。グーテンベルクは、他には何もしようとしていないように見える、いくつかの異なることを同時に行おうとしているからです。 ：stuck_out_tongue：

とにかく、ブロック/モジュール/ウィジェットのUIをどのように処理するかを確認するために確認できるもののリストを次に示します。

WordPressプラグイン/テーマ

• Avada（Fusion Builder）
• BeTheme（Muffin Builder）
• ビーバービルダー
• Divi（Divi Builder）
• Elementor
• 酸素
• SiteOriginページビルダー
• 繁栄する建築家
• Visual Composer
• X＆Pro by Themeco

WordPress以外のウェブサイトビルダー

• Drupal
• Squarespace
• Weebly
• Wix

ページビルダーではないものの、似たようなもの

• MailChimp
• 概念

私が今知っているのはこれらだけです。

兄弟インサーターには問題があります。選択したブロックのコンテンツと常にオーバーラップします。 この問題は、グーテンベルクをよりWYSIWYGにするために、各ブロックの自動マージンなどを取り除こうとするとさらに悪化します。

ソリューション？ ブロックの下部にバーを追加する場合は、兄弟インサーターもそのバーに投げてみませんか？

また、ホバーされたバリアントの境界線を少し不快に見せないようにする方法を思いついたところです。 ブロックの内容を下のバーから分割する境界線の色を変更するだけです！

利点は次のとおりです。

• 兄弟インサーターは、選択したブロックのコンテンツと重複することはありません。 これは、上にスクロールするか、入力してマウスを動かさない場合にコンテンツをカバーしないスティッキーフォーマットツールバーを除いて、選択したブロックのコンテンツと重複するUIがないことを意味します。
• 兄弟インサーターは、HTMLタブの順序と同じ順序で表示されるようになりました。これは、アクセシビリティに適しています。
• 兄弟インサーターがブロックの上ではなく下に表示されるようになりました。 私の意見では、これはより理にかなっています。
• 選択したブロックの兄弟インサーターは常に表示されます（コントロールが現在のように非表示になっている場合を入力する場合を除く）
• モバイルUIとの一貫性。
• ブロックのすべての余白と内側のパディングを削除し、ブロックのUIがブロックのコンテンツの邪魔になることなく、ブロックの境界線をブロックの実際のサイズに戻すことができます。

空の段落ブロックを挿入するのではなく、兄弟インサーターを変更してインサーターメニューを直接開く場合（＃7271で説明）、ボーナスポイント。

もちろん、選択したブロックの上にブロックを置いたときに何が起こるかという問題は依然として問題です。 しかし、これはそれほど気にならないと思います。 ブロックをクリックして選択し、コントロールを表示するだけです。現在選択されているブロックの下にホバーコントロールが表示されている場合は、選択されたブロックがフォーカスになっているため、問題ありません。

これは前進するのに良いデザインだと思います。 私はすべてのポジティブがネガを上回っていると思います、そして私はそれが現在存在するものより間違いなく良いと思います。 皆さんはどう思いますか？

上部と下部の両方のツールバーが重なっている場合にこれがどのように見えるか、およびホバーされたブロックが選択されたブロック上で常に最高のz-indexを取る場合にどのように見えるかをモックアップしました。

私はこれが大好きですが、小さな問題が1つあります。単一のラインブロックは、下部のコントロールバーの下にほぼ完全に隠れてしまうため、運が悪いです。

@chrisvanpattenブロックを選択すると、下のバーが実際にスペースを

また、何かと重なると、下のバーの下に影ができるはずです。

@SuperGeniusZeb下部のバーにスペースを

（編集：詳しく説明すると、ある瞬間から別の瞬間に同じ場所にあるものに本当に頼ることができないため、マウスユーザーにとっては非常に困難になります。それは多くの厄介さを引き起こします。）

@chrisvanpatten

私は主に、投稿を書くという文脈では、入力している段落の下の段落を隠したくないと考えています。現在、選択した段落の下の段落ブロックの最初の行が欠落しているようです。 現在編集しているブロックの後にブロックの上部が表示されないようにするよりも、ブロックを選択したときに周囲のブロックが少しジャンプする方がいいと思います。 個人的には、飛び回るのはあまり気になりません。

グーテンベルクでは、画像キャプションプレースホルダー、引用引用プレースホルダー、ギャラリー内のプレースホルダー/インサーター、再利用可能なブロックなど、選択したときにサイズが変わることはかなり一般的です。 グーテンベルクは一般に、ブロックが選択されたときに編集用にブロックの外観を最適化する必要があるという考えに基づいて設計されています。 ボトムバーがスペースをとるので、ブロックの高さを高くしても大丈夫だと思います。

あるいは、下部のバーを半透明にして、その下にブロックがあることをもう少し明確にすることもできますか？ それはどのように聞こえますか？ 私はそれで大丈夫だと思います。

唯一の問題は、透明度がグーテンベルクUIの他の場所で使用されていないことです。 使用すべきではないということではありません...既存の例がないため、UIデザインの不整合が発生する可能性があります。

左右のコントロール間の空きスペースをなくすというアイデアもありますが、UIが「ブロック」になりすぎたため、チケットの早い段階で削除されました。

@chrisvanpattenそうは言っても、私はます。 次のブロックの最初の行が消えるように見える問題は、いずれかのモックアップで修正されるすべてのものと比較して軽微です。

@SuperGeniusZebこの場合、特に厄介なのは、ホバーするとコントロールが表示されることだと思います。 ジャンプコントロールの他のすべての例では、少なくともホバーするとそこにはなく、選択したときにのみ表示されます。

ホバー/選択/ジャンプ/単一行の段落の問題のため、これを放棄する価値はないと思いますが、間違いなくもう少し考える必要があります。

私はまだここのどこかに解決策があると確信しています…ただ繰り返し続ける必要があります！

@chrisvanpatten

この場合、特に厄介なのは、ホバーするとコントロールが表示されることだと思います。 ジャンプコントロールの他のすべての例では、少なくともホバーするとそこにはなく、選択したときにのみ表示されます。

ええと...ホバーにコントロールを表示することはできませんが、誰もそれを本当に望んでいないと考えるのは安全だと思います。 私は確かにホバーで利用できるコントロールが好きだと知っています。

とにかく、透明性はどうですか？

そして、少し夢を見て、 backdrop-filterがすべての主要なブラウザに実装されることを望む場合は、いくつかのぼかしを追加することができます。

ちなみに、これは60％の不透明度です。

不透明度は間違いなく役立ちますが、方程式に不透明度を導入するかどうかはわかりません。 それは少し浮気のように感じます。

@chrisvanpatten確かに、それは少し浮気のように感じます...しかし、他にどのようなオプションがありますか？

コントロールを横に置くことができないため、この問題はそもそも存在します。

コントロールをブロック内に配置することはできません。コンテンツが隠蔽されるためです。

書式設定バーがすでに存在し、薄いブロックで問題が発生するため、コントロールを上に配置できません。

コントロールを下部に配置することは、アクセシビリティに優れており、兄弟インサーターとドラッグハンドルの両方を投入してそれらに関連する問題を解決するのに便利な場所を提供し、モバイルとの一貫性が高く、シンに最適であるため、最も理にかなっています。ブロック。

下部のバーが占めるスペースを減らすために、実際にできることはほんのわずかです。

• バーの高さを下げます。
• インサーター/ムーバー/ドラッグハンドルと省略記号の間の空きスペースを削除します。
• 省略記号を左に押して、右側の余分なスペースを削除します。
• 選択時にスペースをとるようにします。 （しかし、これは必要ありません。）

それ以外にできることは、半透明にして視覚的に軽く感じさせ、その下にあるものが見やすくすることだけです。

別の考え：おそらく、両方のツールバーが下部のツールバーだけでなく透明である場合、透明性のことは不正行為のように感じられないでしょう。

上記のいくつかを試すために、さらにいくつかのモックアップを作成しました。

透明ツールバー：

透明性なし：

私は実際には透明性のを好むと思います。 どう思いますか？ ボトムバーの幅を縮小することで、次のブロックの開始が重なる問題が解決したと思います。 もちろん、それはまだ狭い幅で発生します...しかし、それはとにかくフォーマットツールバーですでに発生しているので、ここでは実際には問題ではないと思います。

また、ドラッグハンドル用に少しスペースを残したことにも注意してください。 アプリでドラッグハンドルを表すためによく使用される灰色のドットが少し付いている場合や、ホバーまたは常時にドラッグアイコンが表示されている場合があります。 または、空白のままにすることもできます。 技術的には少し薄くすることもできますが、快適さのためにボタンの幅のままにしました。

これでいいの？ これは、現在の反復を置き換えるのに十分な反復でしょうか？ _（「はい」と言ってください。：stuck_out_tongue：）_

ここで行われたすべての調査に感謝します。 半透明が理想的ではないもう1つの理由を追加するためだけに飛び込む：アイコンの背景とのコントラスト比は4.5：1でなければなりません。 半透明を使用すると、それは不可能になります。一般的な暗い色の画像、暗い背景の段落、または暗い背景のテーマを考えてみてください。

ここで素晴らしい議論をしてくれてありがとう。 この挑戦に取り組む情熱を見るのは心強くて嬉しいことです。

ブロックの初期構成を設計して、少し遠くから見てきました—ドッキングされたツールバー、側面に上下の矢印、そして最終的には右側に省略記号があります。 材料を追加したのは、ドラッグアンドドロップの代わりに引っ越し業者にプライム不動産を提供することが非常に便利であると感じたためです。

これがネストされたブロックにもたらす課題を完全に認識しており、長い間、最善の解決策は何かと考えてきました。 マスターの内容（ネストされている場合でも左右にオーバーレイする）は機能しますが、どちらも優れていません。 もう1つのオプションは、モバイルUIを使用することです。選択するとブロックの下にUIを表示します。これは、ここではさまざまなバリエーションでモックアップされており、特にモバイルで機能します。 しかし、デスクトップでは、段落を選択して小さな編集を行い、すべてがジャンプする場合、非常に混乱し、ジャンプする可能性があります。 同様に、ツールバーが最新バージョンのようにオーバーレイされると、書き込みエクスペリエンスからレイアウトエクスペリエンスに傾いているように感じます。 これは私たちが達成しようとした一定のバランスです。

2番目のオプションは、私が持っていた古いモックアップに戻ることです。これは次のとおりです。

おそらくいくつかの調整を加えると、次のようになります。

しかし、私はそれが好きではありません。 そして、これにより、ブロックがホバーされたときにのみムーバーが表示されるようになります。または、処理を少し調整したいと思います。 また、ボタンのヒット領域が数ピクセル小さくなり、使い勝手が悪くなります。

そのため、これらのバリアントは、私たちが持っていたものよりも優れているとは感じられなかったため、これまで検討されていません。 しかし、彼らがそれを機能させるための治療を刺激することができる場合にかかわらず、ここに投稿してください。

ブロックツールとホバーラベルを組み合わせた場合の最大の問題は、選択したブロックのラベルも表示し始めない限り、選択したブロックとホバーしたブロックの間に不整合が生じることです。 その場合、ラベルはブロックの境界内ではなく、ブロックの外側に配置する必要があります。

しかし、それを行ったとしても、ブロックの上部にあるコントロールが多すぎて、幅の広いブロックと薄いブロックの両方で一貫性を保つ方法を理解する必要があるという問題が発生します。

画面に表示されたままのスティッキーツールバーを除いて、標準で選択されたブロックUIがそのブロックのどの部分も覆ってはならないと固く思います。

下部にブロックツールがあると、兄弟インサーターを配置するのに適した場所になります。これは、上記の重複しない目標を達成するのに役立つと同時に、兄弟インサーターをより見やすくし、重複する問題を解決します。 （兄弟インサーターが重複しているため、Quoteブロックへのネストされたブロックの更新はまだ行われていないと思います。）

兄弟インサーターとアクセシビリティの利点があるため、ブロックの下にあることがブロックツールを配置するのに最適な場所だと思います。

もちろん、コントロールを小さくすると使いにくくなる可能性があるので、コントロールをもっと小さくすることはテーブルにあるとは思いませんでした。 しかし、あなたはそれに反対しているようには見えないので、それならそれを試してみませんか？

これはどのように？

下部のバーのボタン（アイコンは除く）のサイズが38pxから32pxに縮小され、以前のモックアップのムーバーコントロール間の間隔の不一致が修正されました。 省略記号ボタンが他のボタンよりも薄い場合（エディターのトップバーにあるボタンのように）、水平方向に少し小さくすることができることに注意してください。

空のドラッグハンドル領域のサイズを小さくして、バーが占めるスペースをさらに少なくすることもできます。 これは、GNOMEのウィンドウの上部バーがどのように機能するかなど、バーのすべてのコントロールがドラッグハンドルとしても機能する場合にさらに実行可能になります。

モバイルでは、コントロールはおそらくmaster場合とほぼ同じように見えます。ここでは、バーがスペースを占めるため、バーを大きくすることは問題ではありません。 このサイズの縮小はデスクトップユーザーにのみ影響するはずであり、コントロールはこのサイズでもタッチで使用できます。

また、コントロールを上部のツールバーに移動して、1セットの問題を解決する小さな調査も行いました。しかし、ブロックを選択すると、狭いコンテキストでは機能しないすべてのツールバーに戻ります。そもそもこの調査の重要な理由。

私はまだそれらの最後のモックアップについて私がどのように感じているかを理解しようとしています。 底からぶら下がっているコントロールは、私にはちょっとぎこちなく感じます。 もっと良いアイデアがあるかどうかはわかりませんが、 @ karmatosedが避けたかったそのようなブロック状/断片化された感覚に

ここでのすべての作業に感謝します。 私はいくつかのフィードバックをしようとしていますが、今のところ、これがプロトタイプに移行する準備ができているとは感じていません。 ネスティングや解決すべきさまざまなデバイスにまだ問題があると思いますが、前のコメントで述べたように、現在のトラックは正しいとは思いません。 私たちもまた、私たちがこれで避けることをすでに提案した領域に戻っているのは確かだと思います。

探索を思いとどまらせたくはありませんが、今は別の提案を検討することをお勧めします。 大きな問題は、下部に半分のタブを追加すると、ゲインなしで視覚的な密度が増加することです。 ここで私たちが解決しようとしていることについて考えてみましょう：

• さまざまなデバイスで何が起こるか。
• 兄弟の挿入（これは他の問題で修正される可能性がありますが）または少なくともそれがどのように相互作用するか。
• ネストの可視性と相互作用の容易さ。

これらすべての主な推進力は、それがどのように応答し、ネストするかでした。

使いやすさを向上させるのか、低下させるのかを考えてみましょう。 たとえば、透明度やレイヤーなどを使用しても、通常の視力を持つ人には問題ありませんが、他の多くの人にとってはそれを改善することはできません。 複雑なレイアウト、ビデオやたくさんの画像を含むレイアウトを考えてみてください。 この密集した情報構造では、提案されていることは維持されません。

複雑なレイアウト、ビデオやたくさんの画像を含むレイアウトを考えてみてください。 この密集した情報構造では、提案されていることは維持されません。

ええ、これが最大のポイントだと思います。その密度を小さなスペースに実際に_化合物_追加します。これは別の課題です。 ネストされたブロックは通常、ネストされていないブロックと同じコントロールをすべて必要としますが、スペースの一部で、理想的には一意でない方法で行う必要があります（たとえば、ネストされたブロックは通常、ネストされていないブロックに似ている必要があります。一貫性が生まれます。使いやすさ）。

製図板に戻る…🙂

私のモックアップが現在のUIよりも優れていると思う理由

ブロック状に見えないようにしたいという願望は理解していますが、ブロック状に見えないものはまだ見つかりませんが、それでも同じように機能します。 問題は、作業しているブロックのエッジを知る必要があり、コントロールがブロック内のコンテンツを隠さないようにするだけでなく、ブロックの外側を少しでも覆うようにする必要があることです。 それはかなりブロック状の外観を保証します。

この号の上部にあるスクリーンショットを見るだけで、ある時点でグーテンベルクが非常にブロックされていないブロックUIを持っていたことがわかります。 しかし、そのUIの問題は、ブロックのエッジがどこにあるかを判断するのが難しいことでした。 これが、現在のUIがある理由です。

そして、兄弟インサーターで問題を投げかけると、兄弟インサーターボタンをブロックのコンテンツ境界の外側に配置する必要があることに気付きます。 それを、通常は現在のブロックの後に（以前ではなく）ブロックを挿入したいという点と、アクセシビリティを向上させたいという願望を組み合わせると、私の最新のモックアップのようなものが必要になります。

個人的には、最初のモックアップのように見えるものよりも、このブロック状のUIの方が好きです。 これらの最初のモックアップは、コンテンツとコントロールの境界がないために混乱しているように見え、バーは不要なスペースを大量に消費します。 UIをジャンプさせたくないので、下部のバーは選択したブロックの外側のコンテンツの上にオーバーレイする必要があります。そのため、できるだけ小さくする必要があります。

さらに、私のモックアップは、現在のものよりもネストされたコンテキストで間違いなく優れていると思います。 以下で説明するように、このUIでは、ツールバー/コンテンツの重複状況が前のUIよりも優れています。 また、ネストされたコンテキストでは、ブロックの境界をさらに知る必要があるため、この状況では、ややブロック状の外観が実際に役立ちます。

重複するツールバーは、小さな画面で水平方向に小さい可能性と比較して、垂直方向に小さい可能性がはるかに低いため、混乱が少なく、問題になる可能性

ネストされたコンテキストでは、現在のブロックの上にあるブロックにカーソルを合わせると、下のブロックのすべてのコンテンツがカバーされることはほとんどありません。これは、ブロックの幅が十分に広く、下部のバーですべてがカバーされないか、ブロックがかなり広くなるためです。背が高いので、それを選択する余地はまだあります。

さらに、ブロックの下部のバーは、マウスがブロックの近くにあるときだけでなく、ブロックにカーソルを合わせたときにのみ表示されます。 ブロックの側面にある奇妙で目に見えないドラッグハンドルのため、現在のUIには当てはまりません。

上記のポイントに追加すると、選択したブロック内のすべてをカバーできるのは、現在のブロックの上のブロックのみです。 水平方向に隣接するブロックにカーソルを合わせると現在のブロックは何も覆われず、カーソルを合わせたブロックの上にはUIがないため、他の3つの側面は完全に問題ありません。したがって、選択したブロックの下にカーソルを置くことも問題ありません。

さらに、ホバーされたブロックが現在選択されているブロックを覆わないようにすることを選択できます。これにより、ネストされたコンテキストで選択されたブロックとの重複する問題が文字通りゼロになります。 ホバーされたブロックの下部にはバーしかないため、現在のブロックの下にあるブロックが選択したブロックと重なることはありません。 この状況で諦めるのは、選択しない限り、現在のブロックより上のブロックのブロックツールにアクセスできることだけです。

さらに別のアイデア：カーソルを別のブロックに合わせると、下部のバーが自動的に非表示になります。 カーソルがブロックの境界に再び移動するまで、それは戻りません。 これは、ネストされたコンテキストでさらに役立つ可能性があります。

さらに、ネストされたコンテキストでのオーバーラップの問題をさらに少なくしたい場合は、書式設定ツールバーをエディターのトップバーにドッキングできます。 （これはモバイルには影響しませんが、モバイルではバーがスペースを占有し、何もオーバーラップしないため、そもそもオーバーラップの問題はありません。）

全体として、最近のモックアップによって改善された状況は、悪化した状況よりも多いと思います。

現状では、私のモックアップ（またはそれに近いもの）のようなものは、それが作成するよりもはるかに多くの問題を解決すると思います。 上記に加えて、次のようなメリットがあります。

• すべてのブロック幅で機能します。
• 兄弟インサーター、移動コントロール、および省略記号のアクセシビリティが向上しました。
• 兄弟インサーターとドラッグハンドルの視認性と発見性が向上しました。
• ブロックの側面にあるドラッグ領域は削除でき、ホバーラベルはドラッグハンドルになる必要はありません（とにかく小さいです）。
• 兄弟インサーターはブロックの下にあり、通常はここで使用します（上ではなく）。
• 個別の兄弟インサーターUIが不要で、複雑さが軽減されます。
• 兄弟インサーターには、ネストされたコンテキストでのオーバーラップの問題がなくなりました。 （それが＃6520がまだ起こっていない理由だと思います。）
• ブロックを囲むブロックUIは、そのブロックのコンテンツと重複することはありません。
• ブロックの自動マージンを削除したり、ブロックに内部パディングを含めたり、ブロックUIの境界線を実際のコンテンツの境界線に戻したりすることはできますが、ブロックのコンテンツ内の何もコントロールによってオーバーラップすることはありません。 この種のエッジケースはカスタムブロックで発生するため、それらを考慮することをお勧めします。
• すべてのブロックツールはかなり接近しているため、ブロックの反対側にある省略記号と矢印ムーバーの以前の状況と比較して、すべてに到達してすべてを発見するのが簡単になります。
• ネストされたコンテキストで現在のコントロールでよくある混乱と比較して、コントロールがどのブロックにアタッチされているかは非常に明確です。
• コントロールはモバイルとより一貫性があります。

そうですね、私のモックアップはネストされたコンテキストで実際にうまく機能すると思います。ブロック状のUIは、得られるものと比較してほとんど重要ではないと思います。 どう思いますか？ 同意しない場合は、モックアップが現在のUIよりも大幅に悪く、前述の提案のいずれもそれを解決できない状況を指摘できますか？

あります...別の...〜スカイウォーカー〜のアイデア

他のすべてが失敗した場合、私はすべての主要な問題を技術的に修正する1つのアイデアを持っています。 書式設定ツールバーがGutenberg1.6に戻ったときのように常に上部にドッキングされていたが、今回は移動コントロールと省略記号が横ではなくブロックの上に表示される場合はどうなりますか？ （代わりに、私のモックアップのように下部に配置することもできます。）

この概念では、エディターのトップバーにあるインサーターが同じ機能を提供するため、兄弟インサーターは存在しません。このコンテキストでは、書式設定ツールバーが同じ領域にあるため、リーチが近くなります。

モバイルUIは、現在とまったく同じになります。 この変更は、デスクトップ（およびおそらくタブレット）ユーザーにのみ影響します。

しかし、待ってください、もっとあります！

実際、考えてみれば、このアイデアと、モックアップを作成して[ツールバーを上に修正]を有効にすることの違いは何ですか？ インラインフォーマットツールバーをモバイルから完全に削除することで得られる唯一のことは、移動コントロールと省略記号をブロックの下ではなく上に表示できることです。 そして技術的には、それはツールバーを一番上に修正するオプションの一部である可能性があります。

サイドUIがまだ2つのサイドに分割されており、紛らわしい非表示のドラッグハンドルがまだ存在し、兄弟インサーターがネストされたコンテキストでオーバーラップしているため、[ツールバーを上に

テキストの各段落が別々のブロックであることが将来に向けて確実に決定されていますか？ もしそうなら、ブロックツールの表示は複数のテキストブロックの選択を考慮に入れる必要があります（これはある段階で来ると私は信じています）。

@padraigobeirnそれは私が忘れていた良い点です。

特に、現在のUIのコントロールは、長い選択を考慮していません。 移動コントロールと省略記号は、選択範囲の最初のブロックの左上と右上に留まります。 書式設定ツールバーでさえ、選択範囲の最初のブロックにのみ固定されます。 ＃7962を参照してください。

私のモックアップの下部のバーについては、上にスクロールしたときに画面の下部に固定されるようにすることで、理論的には複数の選択で機能させることができます。 ただし、このスティッキーな動作は、選択したブロックに対してのみ望ましい場合があります。

あなたが知っている、私は本当にツールバーを上に修正することがデフォルトでオンになっているべきだと思い始めています。

現状では、ブロックの周りに非常に多くのコントロールを収めるためにできることは本当にたくさんあります。私の最新のモックアップを使用しても、UIが混雑していると感じる場合があります。 UIがブロックされすぎているという懸念もあります。

これらの問題を解決するには、書式設定ツールバーを上部にドッキングすることがデフォルトである必要があると思います。 これにより、ブロックの多くの周囲のスペースが節約され、可能なコントロールのオーバーラップの量が大幅に削減されます。

私はまだ移動コントロールと省略記号を下に配置することを好むと思いますが、書式設定ツールバーがドッキングされているときにそれらを上に移動することもできます。 書式設定ツールバーがブロックにアタッチされていない場合、ブロックツールバーを右下または右上に配置できます。見苦しくしたり、スペースを使いすぎたりすることはありません。

でも、左下か右下のどちらかがいいと思います。 そうすれば、コントロールは視覚的にもタブ順にもブロックの後に来るので、私にとって最も理にかなっています。 ブロックの前に兄弟インサーターを挿入する方が、ブロックの前に表示するよりも理にかなっています。

補足：最近、Infusionsoftのメールビルダーには実際には独自の「ブロック」の概念があり、右上のブロックの上にブロックツール（複製と削除）が表示されていることに気付きました。 カーソルがテキスト領域に入ると、エディタ上部のバーに書式設定コントロールが表示されます。

最近、Infusionsoftのメールビルダーには実際には独自の「ブロック」の概念があり、右上のブロックの上にブロックツール（複製と削除）が表示されていることに気付きました。 カーソルがテキスト領域に入ると、エディタ上部のバーに書式設定コントロールが表示されます。

そのインターフェース@SuperGeniusZebのスクリーンショットをいくつかクリップしていただけますか？

グーテンベルクを最初に使い始めたとき、私は間違いなく「ツールバーを一番上に固定する」人でしたが、しばらく使っていたので、戻りたいかどうかはわかりません。 ツールバーはさまざまな点でこれらすべての問題の原因であることを完全に認識しています。ネストされたコンテキストで切り取られ、サイドコントロールに使用できるスペースを占有するものがたくさんある可能性が高いですが、ブロックと組み合わせるとすっごくいいです。 必要なものがすべて一か所にまとめられ、目の動きやマウスの動きなどが少なくなります。今は驚きですが、それなしでは生きていけないと思います。

そのインターフェース@SuperGeniusZebのスクリーンショットをいくつかクリップしていただけますか？

@chrisvanpattenいいえ、誰かを助けている間だけ一時的にアクセスできました。

固定/非固定の書式設定ツールバーについては、どちらの方法もあまり強く感じませんが、ブロックの周りの視覚的な混乱を減らすのに役立つため、固定に傾倒します。 ユーザーのフィードバックに基づいて、他の人は何を好み、その理由は何ですか？

@chrisvanpatten誰かがInfusionsoftのメールビルダーについて話し、そのビデオを持っている記事を見つけました：

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpattenああ、チェックしたところ、そのビデオは古くなっているようです...当時、グーテンベルクが行っているように、フォーマットツールバーがブロックにアタッチされていたようです。 しかし、彼らがそれを変えたことは興味深い。

いくつかの考え：

投稿の途中にブロックを挿入する場合は、通常、選択したブロックの_後に_挿入しますよね？ 通常、選択したブロックの_前_に挿入する必要はありません。 ブロックの後に挿入することは、アクセシビリティの観点からも意味があります。 誰かがこれに同意しませんか？ 私には、これは兄弟インサーターをブロックの下部近くに表示することを支持する強力な議論のように思えます。

兄弟インサーターは、選択したブロックのコンテンツと重複してはなりません。 選択したブロックのコンテンツと永続的に重複するものはありません。 誰かがこれに同意しませんか？ これにより、兄弟インサーターは選択したブロックのコンテンツの外側に配置する必要があると思います。

これを指摘するのは、移動コントロールと省略記号をどこに配置するかに関係なく、兄弟インサーターは、それ自体であるか、ツールバーにある場合でも、選択したブロックの下の一種のツールバーに表示される必要があるように思われるためです。境界線/背景はありません。 今とほぼ同じように見えるかもしれませんが、下にシフトして、ブロックの上ではなく下に表示されるように変更されました。

別の考え：省略記号を移動矢印と同じ側に配置することはmasterよりも改善されるのでしょうか、またはその逆でしょうか。 これにより、ネストされたコンテキストでコントロールが重複するという多くの問題を解決できますが、ブロックの左側（または右側）にブロックUIの量が多くなります。

＃8836を試してみました。 マージされた場合、このチケットの多くのUIデザインにあると思われる重い/ブロック状のUIの問題を減らすのに役立つと思います。

チケット＃9074と＃9075では、状況を緩和および改善するために、この議論に触発された2つのベビーステップを提案しています。 最初の提案では、省略記号/その他のボタンをツールバーに移動するため、サイドUI（ムーバー）は1つしかありません。もう一方の提案では、ブロックツールバーのセットを折りたたんでより適切に収まるようにする提案があります。薄いコンテキスト。

それらを最新の状態に保つために、 @ jasmussenのチケットによって提案された変更と3.6での最近のUIの変更を考慮して、モックアップを更新しました。

実際、＃9074と＃9075が実装されていれば、矢印ムーバーをブロックの下に移動する必要はもうないかもしれません。 隣接するブロックの省略記号が列などで重ならないため、ブロックの側面にとどまると問題ない場合があります。 ＃8880、＃8881、および＃8883のソリューションが発生し、＃8836および＃8920が実装されている場合、ネストされたコンテキストのUIはすでに問題ないでしょう。 上下の矢印がブロックの左側に留まっても大丈夫であることに傾倒し始めています。

そうは言っても、兄弟インサーターは間違いなくブロックの下に属していると思いますが、兄弟インサーターをブロックの下に単独で表示させることもできます。 おそらく、現在の兄弟インサーターのように中央に配置できますが、上下の動きのコントロールのように動作し、ブロックの下部にカーソルを合わせると、ブロックの下にフローティングボタンとして表示されます。

@jasmussenが＃9074と＃9075で取り組んでいるイテレーションを取得することに焦点を当てましょう。それから、次のステップを検討できます。 私は完全に多くのことを変えたいと思うようになりますが、バランスを取りましょう。

前述の＃9074と＃9075、および＃8920と＃9197のような他の問題とPRのおかげで、ブロックの下に矢印ムーバーを移動しても多くの利点がなくなったと判断しました。

代わりに、兄弟インサーターだけをブロックの下に移動し、上下のムーバーと同様にフローティングコントロールとして機能して表示することを提案しています。 ＃9202を参照してください。

これや他の議論から多くの改善が表面化したので、今のところこれを閉じましょう。 行うべき最後のいくつかの改良は、後続のインサーターの周りです。