Interessante Idee @melchoyce.

Meine erste Reaktion war, wie durch das Verschieben nach unten der Block „blockiger“ wird - was seltsam zu sagen ist, aber etwas, das mich fühlen lässt. Wird der Rand beim Klicken oder beim Schweben angezeigt? Ich glaube, ich habe beim Klick weniger Probleme damit als beim Schweben. Ein weiteres interessantes Bild, das zumindest Ihre Beispiele wie ein Polaroid-Bild aussehen lässt, super interessant, wie mein Gehirn dorthin gelangt ist.

Das ist jedoch meine erste Reaktion. Ich denke, es ist sinnvoll, eine andere Position für die Interaktionssymbole in einem Block zu erkunden. Ich denke, was sie gewonnen hat, ist absolut ein Weg, der auf allen Bildschirmen besser funktioniert, den wir als Leitfaden halten sollten, wenn weitere Erkundungen stattfinden.

Ich denke, wir verlieren etwas Kontext durch die Interaktionen. Bei einem Block mit einem größeren Platzhalter wären diese Interaktionen beispielsweise nicht direkt sichtbar. Ich denke, das wird ein Problem sein, das zu weniger Auffindbarkeit führen könnte.

All dies sagte, ich sage absolut nicht, was wir jetzt haben, sollte der Weg nach vorne sein. Bist du bereit zu iterieren und vielleicht mehr zu erforschen? Ich hoffe wirklich, dass Sie es sind.

Ich finde das optisch schön. Es handelt sich im Wesentlichen um die mobile Benutzeroberfläche auf dem Desktop-Haltepunkt, und ich habe beide als Plan B betrachtet, wenn die seitliche Benutzeroberfläche nicht funktioniert hat, oder möglicherweise für verschachtelte Kontexte.

Seitdem haben wir beide Fortschritte mit der seitlichen Benutzeroberfläche gemacht, zuletzt unter https://github.com/WordPress/gutenberg/pull/6141 , und wir haben dafür gesorgt, dass sie auch in verschachtelten Kontexten anständig funktioniert Aspekt braucht noch etwas Liebe.

Obwohl nicht so hübsch, sind die Hauptvorteile dieser Benutzeroberfläche,

1. dass sie beim Schweben erscheinen können
2. Sie erweitern nicht die Grundfläche des Blocks

1 ist besonders wichtig, da es von Anfang an ein explizites Ziel war, sicherzustellen, dass Drag & Drop _additiv_ ist und nicht die primäre Form der Interaktion beim Platzieren, Neuordnen und Sortieren von Blöcken. Wenn wir sie unter dem Block platzieren, werden sie vermutlich beim Klicken angezeigt, was das Ziehen und Ablegen sekundär macht, was beim Schweben immer funktioniert.

2 kann wichtig sein, je nachdem, wie wir mit der seitlichen Benutzeroberfläche in verschachtelten Kontexten umgehen. Im Moment stehen wir vor einigen Herausforderungen in https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863, und obwohl ich sicher bin, dass wir diese lösen können, ist die Tatsache, dass der Footprint dies nicht tut Nicht ändern hilft.

All dies bedeutet nicht "kann nicht funktionieren" - es könnte sehr gut funktionieren. Ein altes Modell hatte diese Benutzeroberfläche als Überlagerung in der Ecke:

Alles in allem also gute Ideen und gut, um sie als Wege in der Nudel zu halten, die je nach dem Feedback, das wir von Release zu Release erhalten, erkundet werden können!

Wird der Rand beim Klicken oder beim Schweben angezeigt?

Einfach auf klicken. Hover wäre ähnlich wie jetzt.

Bist du bereit zu iterieren und vielleicht mehr zu erforschen? Ich hoffe wirklich, dass Sie es sind.

Immer 👍

Sie erweitern nicht die Grundfläche des Blocks

Ja, definitiv ein Problem mit dieser Idee. Selbst in diesem Prototyp können Sie aufgrund der Größenänderung einige Sprünge sehen.

Alles in allem also gute Ideen und gut, um sie als Wege in der Nudel zu halten, die je nach dem Feedback, das wir von Release zu Release erhalten, erkundet werden können!

👍 👍

Ich denke, wir verlieren etwas Kontext durch die Interaktionen. Bei einem Block mit einem größeren Platzhalter wären diese Interaktionen beispielsweise nicht direkt sichtbar. Ich denke, das wird ein Problem sein, das zu weniger Auffindbarkeit führen könnte.

Obwohl nicht so hübsch, sind die Hauptvorteile dieser Benutzeroberfläche,

1. dass sie beim Schweben erscheinen können
2. Sie erweitern nicht die Grundfläche des Blocks

Ich denke, eine Möglichkeit, diese Probleme zu lösen, besteht darin, die Symbolleiste der Blockwerkzeuge über den Blöcken unten anzuzeigen und nicht den Platz zu vergrößern, den der Block tatsächlich im Editor einnimmt. In Bezug auf die Erkennbarkeit bei hohen Blöcken kann die Symbolleiste klebrig gemacht werden, sodass die Symbolleiste beim Scrollen nicht vom Bildschirm abweicht. (Es verschwindet natürlich immer noch, wenn Sie nicht mit der Maus über den Block fahren, und möglicherweise kann es nur angezeigt werden, wenn Sie den unteren Teil des Blocks bewegen, der derzeit sichtbar ist, ähnlich wie die seitlichen Steuerelemente derzeit funktionieren.) Es kann auch einfach so aufgenommen werden Nach Bedarf viel Platz, um alle Schaltflächen anzuzeigen, und nicht wie im Modell im Hauptbeitrag dieser Ausgabe eine ganze Reihe leeren Raums zwischen zwei Steuerelementen einnehmen.

+1 Nur um zu beachten, dass dies auch dazu beitragen kann, die Tabulatorreihenfolge der UI-Steuerelemente um die Blöcke zu verbessern. Wie unter https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531 erwähnt, sind auf der mobilen Benutzeroberfläche die "Seitensteuerelemente" logischer angeordnet. Sehen Sie sich das animierte GIF an, das die Tab-Reihenfolge darstellt. Sie können es mit dem vorherigen GIF mit der Tab-Reihenfolge in der Desktop-Ansicht in einem vorherigen Kommentar vergleichen. Https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

Auch zu berücksichtigen:

3976 schlägt eine dritte Option vor, um die Blocksymbolleiste (die Formatierungssymbolleiste) unter dem Block zu platzieren. Es wäre großartig, ein Design mit der Block-Symbolleiste und den seitlichen Steuerelementen unter dem Block in Betracht zu ziehen, um zu sehen, ob dies funktionieren könnte.

1934 als allgemeines Problem zur Konsistenz der Tabulatorreihenfolge

Dies könnte sich auch auf die Lösung einiger der in # 6272 angesprochenen Probleme auswirken.

In Bezug auf die Erkennbarkeit bei hohen Blöcken kann die Symbolleiste klebrig gemacht werden, sodass die Symbolleiste beim Scrollen nicht vom Bildschirm abweicht.

Ja, das passiert auch mit der oberen Formatierungssymbolleiste:

Wenn man all die großartigen Rückmeldungen hier durchliest, scheint dies eine Reihe von Problemen zu lösen, die in Zukunft und heute mit Zugänglichkeit verbunden sind. Vor diesem Hintergrund denke ich, wir sollten hier vielleicht an einigen Iterationen arbeiten und dann in eine PR zum Prototyp übergehen. Würdest du das @melchoyce machen?

Ja, ich kann noch einen Blick darauf werfen.

+10 für das Ausprobieren.

So sieht die Block-Benutzeroberfläche aus, wenn ich die Breite meines Browserfensters verkleinere. (Wenn ich es weiter verkleinere, wird die Block-Symbolleiste unter den Block verschoben, aber das ist für das, was ich vorschlage, nicht relevant.)

Ich habe festgestellt, dass der Block-Inserter neben den Aufwärts- / Abwärtsbewegungssteuerungen angezeigt wird. Wenn diese Art von Benutzeroberfläche für alle Bildschirmgrößen verwendet wird, wie in diesem Problem vorgeschlagen, könnte der aktuelle Block-Appender möglicherweise aus verschachtelten Blockkontexten entfernt werden, sodass der Editor eher wie das Front-End aussieht, indem der immer vorhandene zusätzliche Speicherplatz entfernt wird von jedem Block-Appender für jede Verschachtelungsebene. (Ich habe in # 6834 auch eine alternative Lösung für das Problem vorgeschlagen, dass Appender Platz verbraucht.)

Dies ist auch nur eine Randnotiz, aber soll sich die Schaltfläche Entfernen rechts neben der Schaltfläche Weitere Optionen befinden , oder sollte sie sich links befinden? In den meisten UI-Designs befinden sich Ellipsenmenüs ganz rechts.

Eine andere Idee:

Zeigen Sie diese Blocksteuerelemente beim Hover unten an. In diesem Zustand belegen sie jedoch keinen Platz auf der Seite und werden stattdessen über dem angehaltenen Block angezeigt (genau wie die Blocksymbolleiste für Blöcke über dem aktuellen Block eins) oder vielleicht oben auf dem schwebenden Block. Die Blocksteuerelemente auf der Unterseite sollten auch kein ununterbrochener weißer Balken beim Schweben sein, sondern 2 kleinere Balken auf jeder Seite, ähnlich der Blocksymbolleiste, damit die Steuerelemente weniger Platz beanspruchen und nicht so viel verdecken.

Wenn Sie einen Block auswählen, beanspruchen die Blocksteuerelemente unten Platz, wodurch der visuelle Platzbedarf des Blocks vergrößert und die darunter liegenden Blöcke aus dem Weg geschoben werden, z. B. wenn Sie einen Bildblock auswählen, wird der Platzhalter für die Beschriftung angezeigt. Dies würde es einfacher machen, den folgenden Block auszuwählen, wenn es sich um einen vertikal kurzen Block wie einen einzeiligen Absatzblock handelt.

Dieser Ansatz ermöglicht es Ihnen, die Vorteile der aktuellen On-Hover-Steuerelemente beizubehalten, sodass Sie Blöcke einfach verschieben / löschen können, ohne sie vorher auszuwählen, und gleichzeitig sicherstellen, dass die Steuerelemente beim Bearbeiten des Blocks nichts verdecken einfacher, dann einen anderen Block auszuwählen.

Noch eine Idee:

Lassen Sie die gesamte Blocksteuerungsleiste (und die Blocksymbolleiste) als Ziehpunkt fungieren (einschließlich der Schaltflächen, z. B. der Funktionsweise der GTK-Kopfleisten). Ich denke, dies würde das Problem der Auffindbarkeit per Drag & Drop so gut wie lösen, insbesondere im Zusammenhang mit ausgewählten Blöcken, bei denen die untere Steuerleiste so aussieht, als wäre sie Teil des Blocks in den Modellen im ersten Beitrag, und daher würden Benutzer dies wahrscheinlich tun Denken Sie eher daran, es als Ziehpunkt zu verwenden.

Vergleichen Sie dies mit der aktuellen Situation, in der die Seiten des Blocks nicht so aussehen, als wären sie Teil des Blocks, und es daher nicht so offensichtlich ist, dass sie als Ziehpunkte fungieren können, und es gibt auch das Problem, dass einzeilige Absatzblöcke Sie haben kaum freien Platz an den Seiten, aus dem sie ziehen können. (Und da die Seitensteuerungsschaltflächen derzeit nur dann als Ziehpunkte verwendet werden können, wenn sie deaktiviert sind, wird das Problem noch verschlimmert.)

Viele tolle Diskussionen darüber, mal sehen, ob ich ein zusammenfassendes Feedback geben kann, um Ihnen hoffentlich etwas zu geben, das Sie mit @melchoyce in die Iteration bringen können.

Insgesamt denke ich, dass ich dies in einem Prototyp spüren muss, und viele meiner Gedanken, die ich denke, können damit gelindert werden. Es gibt jedoch einige Überlegungen, die ich gerne zu einem Mock gemacht hätte:

• Eine Lösung für hohe Blöcke.
• Ein weniger "blockiges" Gefühl: Dies zeigt möglicherweise nur die Platzhalterzustände in einem Schein. Ich lese es als offensichtlicher mit diesen Änderungen.
• Zeigen, wie dies mit der Verschachtelung funktioniert.

Ich würde gerne sehen, wie sich dies auch an verschiedene Geräte anpasst. Ich denke, es gibt weniger Variationen und das könnte eine großartige Sache sein.

@ SuperGeniusZeb einige interessante Gedanken, die Sie dort haben. Ich würde gerne sehen, wo Mel mit den obigen Iterationen hinkommt. Ich denke, das Verdoppeln der Benutzeroberfläche zum Ziehen von Ziehpunkten sollte vorerst vermieden werden. Es werden Verschachtelungsänderungen bearbeitet, an denen ich gerne arbeiten würde. Ich sage nicht, dass wir nicht iterieren werden, aber diese Benutzeroberfläche ist nicht speziell dafür. Ich denke auch, dass man auf Zugehörigkeit schließen kann, ohne visuell explizit zu sein, und wo es zu explizit wird, kommt das negative Gefühl von Blockaden ins Spiel - es fühlt sich eng und zu einschränkend an.

Ich habe auf # 7211 herumgenudelt und im Rahmen dieser Arbeit # 7646 entdeckt, und das brachte mich zurück zu dieser Idee, die sich wirklich als die beste Lösung für eine Reihe von Problemen anfühlt.

Dieses Ticket würde direkt oder indirekt eine ganze Reihe von Dingen reparieren:

• # 7646 → Wenn die Steuerelemente über / unter positioniert sind, müssen Sie sich keine Gedanken über die Anpassung der seitlichen Benutzeroberfläche machen
• # 7182 → Steuerelemente wie die in den Modellen auf diesem Ticket sind direkt mit dem Block verbunden und haben unabhängig von der Verschachtelungsebene eine konsistente Benutzeroberfläche
• # 6451 → Wenn die oberen / unteren Symbolleisten einen soliden Hintergrund haben, müssen Sie sich keine Gedanken darüber machen, wie Steuerelemente auf dunklem Hintergrund sichtbar gemacht werden
• # 7114 / # 6265 → Wenn Sie eine Symbolleiste mit voller Breite wie in einigen der oben genannten Modelle verwenden, können Sie den leeren Bereich zum Ziehen / Ablegen verwenden

All dies, um zu sagen, dass, wenn es immer noch eine Chance gibt, dass eine so große Veränderung in Gutenberg landen könnte, ich denke, dass sie viele Probleme lösen und viele Dinge einfacher machen könnte :) Ich werde mich dem Spaß anschließen und daran arbeiten einige Modelle / Konzepte hoffentlich dieses Wochenende.

@chrisvanpatten Nur um die Perspektive hinzuzufügen. In diesem Problem geht es um Steuerelemente, bei denen die Symbolleiste nicht nach unten verschoben wird. Das würde viel mehr Probleme mit der Benutzerfreundlichkeit verursachen. Nur überprüfen, wie einige Probleme, die Sie verknüpfen, in der Nähe von Symbolleisten zu sein scheinen.

Ich wäre voll und ganz dafür, dies zu versuchen, da es die Tab-Reihenfolge erheblich verbessert. Ein schnelles Update: Die Schaltfläche "Papierkorb entfernen" wurde im Auslassungsmenü verschoben. Ich würde auch vorschlagen, zu versuchen, das Prinzip der Nähe der Steuerelemente zu erfüllen, und den Auslassungsknopf unmittelbar rechts von den Bewegern zu platzieren. Ich bin mir nicht sicher, warum es so weit rechts bleiben soll:

@afercia, da es sich um verschiedene Steuerelemente handelt. Ich denke, die Auslassungspunkte rechts sind sinnvoll. Lassen Sie uns das als ersten Schritt untersuchen. Wir müssen uns auf Folgendes konzentrieren:

Eine Lösung für hohe Blöcke.
Ein weniger "blockiges" Gefühl: Dies zeigt möglicherweise nur die Platzhalterzustände in einem Schein. Ich lese es als offensichtlicher mit diesen Änderungen.
Zeigen, wie dies mit der Verschachtelung funktioniert.

Diese Punkte müssen erkundet werden, um die Route von diesem vielversprechenden Punkt aus zu bestimmen.

@karmatosed Ich habe verwirrenden Jargon verwendet - ich meinte Steuerelemente, keine Symbolleisten. Die Symbolleisten sind bereits oben - da gibt es nichts zu ändern :)

Ich habe nur ein paar Modelle gemacht, wie die Blockwerkzeuge aussehen könnten, wenn sie unter den Block gestellt würden. Beachten Sie, dass in diesen Modellen die Blockwerkzeuge niemals Platz beanspruchen und nur als Überlagerungen wie die Blocksymbolleisten auf dem Desktop fungieren. Die Blöcke werden auch in diesen Modellen ausgewählt. Wenn Sie nur mit der Maus über einen Block fahren, werden die Block-Symbolleisten oben nicht angezeigt. Beachten Sie auch, dass die unteren Steuerelemente immer noch nur angezeigt werden können, wenn Sie wie die aktuellen seitlichen Steuerelemente in ihrer Nähe schweben.

Normal:

Wenn sich das Ende eines Blocks außerhalb des Bildschirms befindet:

(Randnotiz: Die Bildblock-Symbolleiste stimmt nicht mit der in diesen Modellen überein, da die Block-Symbolleiste verschiedene Optionen enthält.)

Angesichts der Probleme mit den Blockwerkzeugen an den Seiten und der verschiedenen Vorteile, die es mit sich bringt, wenn sie unten sind, bin ich jetzt davon überzeugt, dass es der richtige Weg ist, sie unten zu haben.

@SuperGeniusZeb Das ist im Grunde genau das, was ich dachte, außer dass ich die Schaltfläche mit den mehr Optionen mit dem Aufwärts- / Abwärtspfeil anstelle von rechts als kombinierte Symbolleiste positionieren wollte.

@chrisvanpatten Ja, es würde mir auch nichts

Hier sind einige weitere Modelle:

Schweben:

Ausgewählt mit einer Leiste mit voller Breite, die wie auf Mobilgeräten Platz beansprucht (anstatt nur eine Überlagerung zu sein) und als Drag-Handle fungieren kann:

Ich muss sagen, ich denke, wir sind in der kleinen Gefahr, dass dies zu blockig wird ... das ist eine seltsame Art, dies zu beschreiben, aber damit zu tun :) Zum Beispiel ist der im letzten Mock gezeigte Schwebeflug ziemlich intensiv. Ich denke, wir müssen sehen, dass dies mehr für das geht, was Mel im ersten Bild gezeigt hat, das einen Rand weniger hat, und es hilft wirklich, das nicht zu haben.

Ich nahm die ersten Verspottungen und entfernte den Mülleimer, um das zu bekommen, was ich für am besten halte:

Wir brauchen keine zusätzlichen Ränder und wir brauchen kein zusätzliches Gewicht. Auf diese Weise können Sie problemlos ziehen, ohne die ungewöhnlichen Umrisse zu schweben.

@karmatosed Ich habe Ihr

Und hier ist es mit dem ausgewählten Block und der angezeigten Block-Symbolleiste:

(Ich habe auch den Platzhalter für den Bildblock so aktualisiert, dass er mit dem aktuellen Platzhalter in Gutenberg übereinstimmt.)

Etwas, das mich verwirrt, weil die Steuerelemente keinen oberen Rand haben: Befinden sich die Steuerelemente immer noch auf einem weißen Hintergrund? Bedeutet dies, dass der gesamte Block einen weißen Hintergrund hat? Das hört sich so an, als würde es Probleme in verschachtelten Kontexten verursachen, in denen ein Block in einem Container mit dunklem Hintergrund verschachtelt ist, da das Auswählen (und / oder Schweben) dazu führen würde, dass sich der Hintergrund des Blocks ändert, was ziemlich irritierend aussehen würde.

Etwas, das mich verwirrt, weil die Steuerelemente keinen oberen Rand haben: Befinden sich die Steuerelemente immer noch auf einem weißen Hintergrund? Bedeutet dies, dass der gesamte Block einen weißen Hintergrund hat?

Es tut, aber die Kontrollen haben Ziele. Ich denke, es lohnt sich zu zeigen und vermeidet die visuellen Blockprobleme ohne. Dies muss unbedingt beim Verschachteln untersucht werden, aber ohne den Hintergrund würde es beim visuellen Verschachteln noch schlimmer werden.

Es tut, aber die Kontrollen haben Ziele. Ich denke, es lohnt sich zu zeigen und vermeidet die visuellen Blockprobleme ohne. Dies muss unbedingt beim Verschachteln untersucht werden, aber ohne den Hintergrund würde es beim visuellen Verschachteln noch schlimmer werden.

Einverstanden, und mit dem Hintergrund löst auch # 6451.

Ich mag es nicht, wenn diese große leere Leiste in diesen letzten Modellen auf dem Schwebeflug angezeigt wird. Idealerweise möchten Sie beim Schweben so wenig wie möglich von den umgebenden Blöcken verdecken, dies deckt jedoch einen Großteil des darunter liegenden Blocks ab. Wie wäre es mit so etwas?

Wie bereits erwähnt, können die Pfeilbeweger und Auslassungspunkte als Ziehpunkte dienen, und / oder der Schwebetitel kann ein Ziehpunkt sein. (Siehe # 7114.)

@SuperGeniusZeb, obwohl ich Ihre Punkte in diesem Fall verstehe, ist es optisch nicht großartig, wenn die Blöcke umrissen sind. Bleiben wir bei dem Modell, das ich basierend auf Mels großartiger Arbeit gemacht habe, um daraus einen Prototyp zu machen.

Etwas, das mir gerade klar wurde, dass hinter ausgewählten Blöcken ein weißer Hintergrund angezeigt wird: Was ist mit Blöcken mit einer weißen (oder anderweitig hellen) Textfarbe, die in einem dunklen Bereich angezeigt werden sollen (bereitgestellt durch etwas wie den Containerblock)? Ein weißer Hintergrund für den gesamten Block würde in diesem Fall nicht funktionieren.

Der Hintergrund befindet sich um die Symbolleiste, die immer diese Steuerelemente enthält.

@SuperGeniusZeb Ja, ich sehe nicht, dass der weiße Hintergrund den Block selbst beeinflusst, sondern nur die Steuerelemente. Praktisch könnte es so etwas sein:

Oder die Polsterung könnte möglicherweise entfernt werden (ich mag diesen Ansatz wirklich, aber es ist offensichtlich eine größere Frage, die Auswirkungen auf Drag & Drop hat. Ich denke immer noch, dass es sich lohnt, darüber nachzudenken):

@chrisvanpatten Ich mag das letzte Modell. Ich denke nicht, dass Drag & Drop ein Problem darstellen würde, da die untere Leiste als Drag-Handle dienen könnte (und möglicherweise auch die Schaltflächen in der Leiste als solche funktionieren würden). Sie können beim Schweben sogar ein Drag-Handle-Symbol in die untere Leiste einfügen oder einfach immer ein Symbol haben, um anzuzeigen, dass Sie den Block damit ziehen können.

Bei diesem Ansatz sehe ich keinen Grund, den ziehbaren Bereich in der Nähe der Blockränder zu halten. Das Entfernen dieser Auffüllung könnte auch dazu beitragen, dass der Block über ausgewählten Blöcken näher an den tatsächlichen Rändern des Blocks schwebt, da sie diesen Ziehraum nicht mehr berücksichtigen müssen und sich nur anpassen müssen, um größer als der tatsächliche Block zu sein Verschachtelungsfälle, um die Auswahl übergeordneter Blöcke zu vereinfachen. (Die Auswahl übergeordneter Blöcke wäre weniger problematisch, wenn Dinge wie das Modell in diesem Kommentar in # 6459 implementiert würden.)

@ SuperGeniusZeb

Sie können beim Schweben sogar ein Drag-Handle-Symbol in die untere Leiste einfügen oder einfach immer ein Symbol haben, um anzuzeigen, dass Sie den Block damit ziehen können.

Tolle Idee 💡

Ich denke, lassen wir den ziehbaren Bereich beiseite und implementieren dies. Es ist wichtig, sich darauf zu konzentrieren, das zu lösende Problem zuerst zu lösen. Ich muss sagen, dass ich nicht sicher bin, ob ein Symbol der richtige Ansatz ist. Lassen Sie uns noch einmal darüber nachdenken, sobald wir dies ohne das implementiert haben.

@ karmatosed

Ich denke, lassen wir den ziehbaren Bereich beiseite und implementieren dies.

Ich bin mir nicht ganz sicher, was das bedeutet? Welche Seite?

Ich bin froh zu sehen, dass dies passieren wird. Nur eine kurze Erinnerung daran, dass es nicht nur um visuelle Platzierung geht. Für a11y sollten die visuelle Reihenfolge und die Tabulatorreihenfolge (DOM-Reihenfolge) übereinstimmen, sodass diese "Blockwerkzeuge" tatsächlich nach dem bearbeitbaren Blockbereich im Markup verschoben werden sollten.

Ein netter Vorteil des Wechsels zu Steuerelementen unterhalb des Blocks besteht darin, dass der Seitenraum geöffnet wird, damit der Geschwister-Inserter auf etwas wie das in Squarespace umgestaltet werden kann, wenn das aktuelle Design auf Probleme stößt. Die aktuellen seitlichen Steuerelemente hätten diese Art von Inserter überlappt und würden überladen aussehen, aber wenn die Steuerelemente nach unten verschoben werden, ist dies kein Problem mehr.

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

Ich habe dies gerade auf # 7500 kommentiert. Ich habe mich gefragt, wie aufeinanderfolgende Absätze mit diesem Design aussehen würden. Ich denke, der Balken unten würde zu einer ziemlich großen Lücke zwischen den Absätzen führen.

@talldan Zitiert mich aus # 7500:

Die Blocksteuerelemente würden beim Hover keinen Platz beanspruchen (genau wie sie und die Block-Symbolleiste jetzt keinen Platz beanspruchen), und soweit ich das beurteilen kann, ist noch nicht einmal entschieden, ob sie Platz für einen ausgewählten Block beanspruchen würden. Und natürlich werden die Steuerelemente nur für Blöcke angezeigt, die entweder ausgewählt sind oder über denen der Mauszeiger bewegt wird. Der Standardabstand zwischen Blöcken sollte von der Änderung nicht beeinflusst werden. Es kann nur der ausgewählte Block betroffen sein.

Das sieht wirklich gut aus, ich bin alles dafür.

Eine Sache, die wir dabei nicht berücksichtigen sollten. Was ist mit langen Blöcken? Was passiert mit diesen und dem unteren Rand des Editorbildschirms mit Blöcken?

Sie meinen, wenn der Block so lang ist, dass er nicht mehr sichtbar ist? Ich würde sagen, bevor das passiert, werden die Leute gesehen haben, wie es funktioniert und wissen, wo es zu finden ist. Wir müssten nur testen, ob das ärgerlich wird, wenn Sie viele lange Absätze auf einem winzigen Bildschirm schreiben. Aber ich mag es, dass es das mobile Erlebnis besser widerspiegelt. Welche Bedenken haben Sie für den letzten Block in einem Beitrag?

Wie würden sie sehen, wenn ihr erster Block ein wirklich langer Block wäre?

Wir sollten zumindest einen NUX-Tipp dazu hinzufügen;), aber was Sie befürchten, ist der Fall, dass jemand einen vorhandenen Beitrag öffnet, der möglicherweise einen langen Absatz enthält oder nicht korrekt in Blöcke konvertiert wurde? Es ist möglich ... Wenn sie einen neuen Beitrag beginnen, werden sie ihn mit ziemlicher Sicherheit auf dem ersten Platzhalterblock sehen, oder?

Wenn ich darüber nachdenke, sehe ich hier keine Untersuchung, wie die Steuerelemente oben im Block platziert werden könnten, was eine Option sein könnte. Habe ein kurzes Modell dafür gemacht. (Das Kombinieren der Balken wird auch hier erwähnt )

Wenn ein Block zu hoch ist, bleiben die unteren Steuerelemente nicht am unteren Bildschirmrand hängen, z. B. wie die oberen Steuerelemente am oberen Rand hängen bleiben oder wie sie in Mobilgeräten funktionieren.

@hedgefield Das gefällt mir sehr gut, aber es funktioniert nicht gut in engen Kontexten (wie einem

@hedgefield @chrisvanpatten Vielleicht können sich die Pfeil- /

@karmatosed Ich würde sagen, die Steuerelemente könnten klebrig sein und am unteren Bildschirmrand sichtbar bleiben. Dies führt jedoch zu diesem Problem mit den Steuerelementen, die die Zeile, die Sie in einen Absatz schreiben möchten, jedes Mal verdecken, wenn Sie mit dem Schreiben beginnen (vermutlich werden sie beim Tippen ausgeblendet, so wie es jetzt funktioniert). Trotzdem scheint diese Lösung fraglich.

Zurück zum Modell von bleiben , ohne sich in die Quere zu kommen. Natürlich müsste die Symbolleiste reagieren und die Pfeilbeweger und Auslassungspunkte sollten sich für dünne Blöcke idealerweise unter / über / irgendwo bewegen.

Es gibt auch die Sorge um Zugänglichkeit. Das Modell von

und ich weiß nicht, ob eine Inkonsistenz zwischen visuellem Erscheinungsbild und Quellreihenfolge wünschenswert ist

Es ist an einem Punkt nicht wünschenswert, dass es dafür ein bestimmtes WCAG-Erfolgskriterium gibt:
https://www.w3.org/TR/WCAG21/#focus -order

Ich würde sagen, die Steuerelemente könnten klebrig sein und am unteren Bildschirmrand sichtbar bleiben. Dies führt jedoch zu diesem Problem mit den Steuerelementen, die die Zeile, die Sie in einen Absatz schreiben möchten, jedes Mal verdecken, wenn Sie mit dem Schreiben beginnen (vermutlich werden sie beim Tippen ausgeblendet, so wie es jetzt funktioniert). Trotzdem scheint diese Lösung fraglich.

Wenn man noch etwas darüber nachdenkt, würden die Steuerelemente die letzte Zeile in einem Absatz nicht verdecken, es sei denn, der Absatz befindet sich direkt neben dem unteren Bildschirmrand, sodass # 353 dies zu einem Nicht-Problem machen könnte. Und selbst ohne # 353 könnten Sie immer noch nach unten scrollen (was die meisten Leute sowieso tun), und wie bereits erwähnt, werden die Steuerelemente auch nur angezeigt, wenn Sie Ihre Maus bewegen. Ich habe meine Meinung geändert. Das könnte funktionieren!

Wie es für breite Blöcke aussehen würde:

Wie es für dünne Blöcke aussehen würde:

Noch dünnere Blöcke (denken Sie an 8 Spalten oder so):

Ich denke, ich fange wirklich an, dieses Design zu mögen. Bei breiteren Blöcken bin ich mir nicht sicher, ob die Pfeilbewegungssteuerelemente links von den Formatierungssteuerelementen oder rechts angezeigt werden sollen.

Vielen Dank für die Erkundungen. Wenn Sie jedoch alles in einer Zeile kombinieren, werden verschiedene Aktionen an einem Ort zusammengeführt. Ich bin mir nicht sicher, ob das Sinn macht. Wir haben auch die Überlegung, was passiert, wenn jemand eine Symbolleiste nach oben klebt - er entscheidet sich dafür, dass nichts "an Ort und Stelle" ist, und jetzt sind die Steuerelemente. Das fühlt sich weniger als eine Erfahrung an, da wir keine Blocksteuerelemente in der Symbolleiste haben können - das wäre sehr seltsam zu erleben.

Wenn Sie jedoch alles in einer Zeile kombinieren, werden verschiedene Aktionen an einem Ort zusammengeführt.

Ist es nicht per Definition der Zweck einer Symbolleiste, Devil's Advocate zu spielen?

Obwohl ich die Idee hinter der Trennung bestimmter Steuerelemente verstehen kann, bin ich mir nicht sicher, ob es in diesem Fall ein überzeugendes Argument dafür gibt. Eine Symbolleiste ist eine Symbolleiste. Es ist logisch, alle Steuerelemente für einen bestimmten Block an einem Ort zu platzieren, anstatt unscharfe Gründe dafür zu finden, warum bestimmte Tools an bestimmte Orte gehören, während andere Tools an andere Orte gehören, die Plugins ohnehin zwangsläufig ignorieren.

@karmatosed Wie wäre es, die Steuerelemente über Farbe zu trennen?

@ SuperGeniusZeb leider löst das meine anderen Punkte nicht nein und ich bin mir nicht sicher ob es funktioniert.

Ich denke wirklich, in diesem Fall geht es darum, ein Design zu finden, von dem angenommen wird, dass es besser funktioniert als das, das funktioniert. Wie wäre es, einen Schritt zurückzutreten und die anderen Punkte zu berücksichtigen, die ich angesprochen habe?

@chrisvanpatten Eine Symbolleiste ist per Definition kein Ort, an dem alles abgelegt werden kann. Um nützlich zu sein, muss eine Symbolleiste Kontext und Reihenfolge haben. Sie müssen als Benutzer erwarten, dass es die richtigen Optionen gibt. Während wir für eine Weile darüber diskutieren können, was die Bedeutung eines einzelnen Wortes ist - es macht Spaß, das zu tun -, können wir nicht aus den Augen verlieren, dass dies viel zu viele Dinge gleichzeitig kombiniert und ein Problem für mehr Menschen wäre.

@ karmatosed Okay dann. Kehren wir zur Bearbeitungssymbolleiste zurück:

(Ich bin mir nicht sicher, ob diese blaue Linie über dem Balken vorhanden sein soll oder nicht.)

Stimmt etwas mit diesem Design nicht? Die Bearbeitungssymbolleiste kann so erstellt werden, dass sie nach dem Block in der Quellreihenfolge angezeigt wird, um die Barrierefreiheit zu gewährleisten. Es ist nicht ideal, aber da das Platzieren der Bearbeitungssymbolleiste unter dem Block keine praktikable Option zu sein scheint, scheint es das einzige zu sein, was wir tun können.

Außerdem hatte ich gerade eine Idee: Was wäre, wenn die Leiste unten beim Schweben teilweise transparent wäre? Würde es sich dadurch leichter anfühlen?

@SuperGeniusZeb nur um Ansichten zu bekommen, kann ich vorschlagen, dass wir weniger bunte Mocks haben? Ich verstehe, was vorgeschlagen wird, aber die Benutzeroberfläche alleine stehen zu lassen, wäre ohne die visuelle Komplexität einfacher.

Nur um einen nächsten Schritt zu verspotten. @SuperGeniusZeb Wie sieht das oben genannte im Kontext eines Bildschirms (normale Desktop-Größe) und eines sehr langen Blocks aus? Wie sieht es auch mit einem Block ganz unten aus? Lassen Sie uns im Idealfall ein wenig die Transparenz parken und meinen Kommentar über die Fokussierung auf die Benutzeroberfläche und nicht auf die Farben dieses Mal berücksichtigen. Dies sollte uns allen helfen, zu messen.

Einige Modelle:

Mit Rand oben in der Steuerleiste

Ohne Rand oben in der Steuerleiste

Beachten Sie, dass die Symbolleiste beim Hover keinen Platz einnimmt, dies jedoch, wenn der Block ausgewählt ist.

Während ich diese Modelle machte, bemerkte ich etwas: Was sollte in solchen Situationen getan werden?

Hier besteht ein Konflikt zwischen der Anzeige der Formatierungssymbolleiste des ausgewählten Blocks und der unteren Steuerelemente des schwebenden Blocks. Wenn sich die Formatierungssymbolleiste unten befindet (oder wenn sich alle Blocksteuerelemente oben befinden), ist dies kein Problem, aber hier verursacht die Kombination der unten gezeigten Steuerelemente und der oben gezeigten Steuerelemente ein Problem.

Die beste Lösung, die ich mir vorstellen kann, wäre, den schwebenden Block und seine Symbolleiste einen höheren Z-Index zu haben und über dem Block unten und seiner Formatierungssymbolleiste zu erscheinen. Ich bin mir jedoch nicht sicher, ob dies der richtige Ansatz ist. Hier ist ein Modell, wie dies aussehen würde:

Und wieder ohne den Rand zwischen der unteren Leiste und dem Blockinhalt:

Ich mag die Idee, dass der schwebende Block den ausgewählten überlappt, nicht wirklich, aber ansonsten sehe ich keine Möglichkeit, die unteren Balken von schwebenden Blöcken direkt über den ausgewählten zu verwenden. Sind Sie sicher, dass es nicht besser wäre, alle Steuerelemente in einer einzigen Leiste oben oder unten zu haben, zumindest auf dem Desktop? Es würde sicherlich solche Probleme verhindern.

@ SuperGeniusZeb Ich hatte diese

Das ist ein wirklich großartiger Punkt, über den ich nicht nachgedacht hatte (den Block über dem ausgewählten Block schweben lassen). Das ist definitiv ein Problem. Gibt es als Resident Page Builder-Experte andere ähnliche Muster in anderen Seitenerstellern mit überlagerten Symbolleisten wie diesen?

Außerdem denke ich, dass die Symbolleisten für das, was es wert ist, immer schwebend, ausgewählt oder nicht sein sollten. Wenn es manchmal Platz beansprucht, führt dies zu nervösen Inhalten, was insgesamt eine unangenehmere Erfahrung ist.

@chrisvanpatten Alle Seitenersteller, die ich gesehen habe, haben nur Steuerelemente (außer vielleicht einem Geschwister-Inserter), die oben in einem Modul / Widget angezeigt werden. Divi ist meiner Meinung nach eines der besten Beispiele:

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

Die im Video nicht gezeigte Formatierungssymbolleiste in Divi wird angezeigt, wenn Sie auf den Text in einem Modul klicken, und in einem kleinen Popup über der Zeile, die Sie schreiben.

Elementor macht fast das Gleiche.

Wenn Sie in Beaver Builder auf den Text in einem Widget klicken, wird die Symbolleiste für Blocksteuerelemente durch die Formatierungssymbolleiste ersetzt, bis sich Ihre Maus außerhalb der Ränder des Widgets bewegt. Dadurch werden die Standardblocksteuerelemente angezeigt, wenn Sie das Widget das nächste Mal bewegen Sie können das Widget jedoch weiterhin eingeben. Wenn Sie erneut auf den Text klicken, wird die Formatierungssymbolleiste die Standardsymbolleiste wieder ersetzen.

Außerdem denke ich, dass die Symbolleisten für das, was es wert ist, immer schwebend, ausgewählt oder nicht sein sollten. Wenn es manchmal Platz beansprucht, führt dies zu nervösen Inhalten, was insgesamt eine unangenehmere Erfahrung ist.

Stimmt, aber ich mache mir Sorgen über die Auswirkungen, die dies auf eine saubere Benutzeroberfläche hat. Wenn die Formatierungssymbolleiste einige der oben genannten Inhalte überlappt, ist dies in Ordnung. Wenn Sie jedoch am unteren Rand des Blocks eine Leiste in voller Breite hinzufügen, überlappen Sie jetzt viele andere Inhalte.

Idealerweise sollten sich alle Steuerelemente oben oder unten im Block befinden. Dies würde in den meisten Fällen verhindern, dass sich Symbolleisten überlappen. Aus Gründen der Zugänglichkeit wäre es ideal, die Bedienelemente unten anzubringen. Es kann jedoch zu Problemen kommen, bei denen sich die Symbolleisten mit dem Inhalt überschneiden, den Sie in einem Absatzblock schreiben. Es sollte jedoch beachtet werden, dass nur die Formatierungssymbolleiste wirklich benötigt wird, um jederzeit sichtbar zu sein, da die Pfeilbeweger und Auslassungspunkte nicht annähernd so häufig verwendet werden. Wenn der aktuell bearbeitete Teil des Inhalts eines Blocks weit genug vom unteren Bildschirmrand entfernt ist, muss sich die Formatierungssymbolleiste nicht überlappen.

Wenn es zu umständlich ist, die Bedienelemente unten anzubringen, ist es anscheinend die nächstbeste Option, sie alle oben anzubringen. Natürlich gibt es das potenzielle Problem, dass die Steuerelemente nach dünnen Blöcken umständlich suchen.

In Fällen von Desktop oder Mobile können Sie normalerweise die Position von Symbolleisten verschieben. Derzeit werden die Formatierungssymbolleiste und andere Steuerelemente unterhalb des aktuell ausgewählten Blocks angezeigt und belegen Speicherplatz auf Mobilgeräten.

In Fällen von breiten Blöcken gegenüber dünnen Blöcken kann es jedoch unangenehm sein, die Steuerelemente für die dünneren Blöcke zu bewegen. Am konsistentesten ist es, wenn die Formatierungssymbolleiste oben und die anderen Steuerelemente unten angezeigt werden. Dies bringt uns jedoch zurück zum Problem überlappender Symbolleisten und der zunehmenden Überlappung von Inhalten.

Gutenberg basiert auf der Idee, dass das Erscheinungsbild des ausgewählten Blocks für die Bearbeitung optimiert ist. Daher ist es meiner Meinung nach nicht so schlecht, wenn Symbolleisten physischen Platz beanspruchen, solange Sie bei der Auswahl des Blocks nur Inhalte im Block verschieben und nicht verschieben der ausgewählte Block selbst.

Am Ende denke ich, dass

Einige Hinweise dazu, wie dies funktionieren würde:

Die Steuerelemente belegen beim Hover keinen Platz, belegen jedoch Platz, wenn der Block ausgewählt ist. Wenn Sie den Mauszeiger über einen Block bewegen, werden nur die Pfeilbeweger und Auslassungspunkte angezeigt. Wenn Sie jedoch den Block auswählen, wird die Formatierungssymbolleiste angezeigt, die die anderen Steuerelemente nach unten drückt. Dies ist wahrscheinlich das größte Problem bei diesem Design. Ich denke, damit dies am besten funktioniert, möchten Sie, dass der Inhalt des Blocks beim Auswählen eines Blocks durch Klicken auf die Symbolleiste "Mover / Ellipsen" nach oben verschoben wird. Sie möchten jedoch, dass sich die Symbolleisten verschieben, wenn Sie den Block durch Klicken auf den Inhaltsbereich auswählen.

Wenn sich ein Block unterhalb des Inhaltsbereichs erstreckt, werden die Pfeilbeweger und Auslassungspunkte außerhalb des Bildschirms angezeigt, die Formatierungssymbolleiste bleibt jedoch sichtbar und bleibt am unteren Bildschirmrand (oder im Inhaltseditorbereich) hängen.

Wenn dies nicht die beste Lösung ist, würde ich im Grunde das Gleiche tun, aber mit den Steuerelementen oben, wobei die Mover / Ellipsen über der Formatierungssymbolleiste für dünne Blöcke und möglicherweise links von den Formatierungssteuerelementen für angezeigt werden breite Blöcke. Mobile könnte immer noch so aussehen wie jetzt.

Ein weiterer Gedanke: Sie könnten sowohl das Problem mit den Schaltsteuerelementen als auch die Symbolleisten, die sich überlappen, beseitigen, wenn Sie beim Hover einfach keine Steuerelemente anzeigen. Das würde das Anzeigen von Symbolleisten oben und unten in Blöcken weniger problematisch machen. Aber natürlich verlieren Sie die Vorteile, wenn Steuerelemente beim Schweben angezeigt werden. Ich bin mir nicht sicher, ob dies die Richtung ist, in die jemand gehen möchte, aber ich frage mich, ob dies notwendig ist.

Ich muss sagen, dass mir die Idee, dass sich der schwebende Block überlappt, auch nicht gefällt. Ich denke, das braucht noch etwas Nachdenken. Die Idee, dass Steuerelemente beim Schweben möglicherweise unterschiedlichen Platz einnehmen, ist etwas umständlich.

Die Steuerelemente belegen beim Hover keinen Platz, belegen jedoch Platz, wenn der Block ausgewählt ist. Wenn Sie den Mauszeiger über einen Block bewegen, werden nur die Pfeilbeweger und Auslassungspunkte angezeigt. Wenn Sie jedoch den Block auswählen, wird die Formatierungssymbolleiste angezeigt, die die anderen Steuerelemente nach unten drückt. Dies ist wahrscheinlich das größte Problem bei diesem Design.

Ich denke, das ist ein großes Problem mit den Verspottungen. Was könnte sonst noch passieren?

Was ist mit anderen Apps und Produkten, wenn man sich Seitenersteller ansieht? Ist das woanders gelöst?

@ karmatosed

Was ist mit anderen Apps und Produkten, wenn man sich Seitenersteller ansieht? Ist das woanders gelöst?

Es ist schwierig, analoge Beispiele für die Benutzeroberfläche zu finden, die Gutenberg verwenden könnte, da fast nichts für all die Dinge verantwortlich sein muss, die Gutenberg tut.

Viele einfachere / ältere Plugins für den Seitenersteller müssen sich nicht darum kümmern, den Inhalt ihres Äquivalents eines Blocks zu vertuschen, da die gesamte Inhaltsbearbeitung in einer Modal- oder Seitenleiste erfolgt. Dadurch werden sie frei, damit ihre Modulsteuerelemente den Inhalt überlappen können.

Selbst in Fällen wie Divi oder Beaver Builder, in denen Sie den Text bearbeiten können, ohne eine Modal- / Seitenleiste zu öffnen, ist die Modal- / Seitenleiste immer noch die primäre Bearbeitungsmethode. Divi und Beaver Builder zeigen beide, was im Wesentlichen eine perfekte Nachbildung des Frontends ist, ohne sich Sorgen machen zu müssen, dass sie beispielsweise als Texteditor verwendet werden müssen oder dass der Großteil des Hauptblockinhalts inline bearbeitet werden kann der Block.

Darüber hinaus ist das Verschachteln sowohl in Seitenerstellern als auch in anderen Builder-ähnlichen Benutzeroberflächen aufgrund von Einschränkungen bei der Verschachtelung weitaus weniger problematisch. Divi hat einen strengen Abschnitt → Zeile (mit integrierten Spalten) → Modul-Setup (allerdings mit einigen speziellen Abschnitten, die für einige häufig verschachtelte Spalten-Situationen entwickelt wurden). Mit Beaver Builder können Spalten nur in Spalten verschachtelt werden, ebenso wie Elementor. Sie steuern die einzige Art von Objekt, die mehrere Verschachtelungsebenen haben kann. Alles befindet sich standardmäßig in einem Abschnitt mit einer einzelnen Zeile. Es gibt keine unbegrenzten Ebenen verschachtelter Blöcke mit dem Potenzial für eine Kombination von benutzerdefinierten Blöcken, die die Verschachtelung für verschiedene Zwecke und verschiedene Stile verwenden, wie dies Gutenberg zulässt.

Divi kann seine Steuerelemente für Abschnitte, Zeilen und Module farblich kennzeichnen, da es eine strikte Struktur aufweist und es kein benutzerdefiniertes Modul geben kann, das einen Abschnitt oder eine Zeile fungiert. (Auf diese Weise können auch mehrere Inserter-Schaltflächen in derselben Zeile angezeigt werden, jedoch mit unterschiedlichen Farben, um zu unterscheiden, was die einzelnen Funktionen tun.) In den meisten Buildern sind Module von Layoutelementen getrennt. Beaver Builder kann aufgrund der Trennung von Modulen und Layoutelementen ähnliche Aufgaben ausführen.

Wenn Sie sich Dinge ansehen, die keine Seitenersteller sind, wie z. B. Texteditoren, können Sie feststellen, dass sich diese nicht um all die Dinge kümmern müssen, mit denen sich Seitenersteller befassen müssen. Wenn Sie sich die meisten Seitenersteller ansehen, verarbeiten sie keine Texteditoren über direkte Inline-WYSIWYG-Steuerelemente.

Was Gutenberg versucht, ist einzigartig. Es wird versucht, ein WYSIWYG-System zu sein, mit Ausnahme des ausgewählten Blocks, der für die Bearbeitung des Seitenerstellers optimiert ist und gleichzeitig ein Volltexteditor ist. Von Abschnitten über Spalten bis hin zu Widgets ist alles gleich des Objekts: Blöcke.

Grundsätzlich ist dies ein kompliziertes Problem, da Gutenberg versucht, mehrere verschiedene Dinge gleichzeitig zu tun, was anscheinend nichts anderes zu tun versucht. : stick_out_tongue:

Wie auch immer, hier ist eine Liste von Dingen, die betrachtet werden könnten, um zu sehen, wie sie mit der Block- / Modul- / Widget-Benutzeroberfläche umgehen:

WordPress Plugins / Themes

• Avada (Fusion Builder)
• BeTheme (Muffin Builder)
• Biberbauer
• Divi (Divi Builder)
• Elementor
• Sauerstoff
• SiteOrigin Page Builder
• Gedeihender Architekt
• Visual Composer
• X & Pro von Themeco

Website-Ersteller außerhalb von WordPress

• Drupal
• Platz
• Weebly
• Wix

Dinge, die keine Seitenersteller sind, aber denen ähnlich sind

• MailChimp
• Begriff

Das ist alles, was ich gerade weiß.

Es gibt ein Problem mit dem Geschwister-Inserter: Er überlappt immer den Inhalt des ausgewählten Blocks. Dieses Problem wird noch schlimmer, wenn Sie versuchen, Dinge wie die automatischen Ränder auf jedem Block loszuwerden, um Gutenberg mehr WYSIWYG zu machen.

Die Lösung? Wenn wir am unteren Rand der Blöcke eine Leiste hinzufügen, warum nicht auch den Geschwister-Inserter in diese Leiste werfen?

Außerdem habe ich mir gerade eine Möglichkeit ausgedacht, die Umrandung der schwebenden Variante etwas weniger störend wirken zu lassen. Ändern Sie einfach die Farbe des Rahmens, der den Blockinhalt von der unteren Leiste trennt!

Zu den Vorteilen gehören:

• Geschwister-Inserter überlappen niemals den Inhalt des ausgewählten Blocks. Dies bedeutet, dass es jetzt keine Benutzeroberfläche geben sollte, die jemals den Inhalt des ausgewählten Blocks überlappt, mit Ausnahme der Symbolleiste für die klebrige Formatierung, die den Inhalt nicht abdeckt, wenn Sie nur nach oben scrollen oder nur tippen und die Maus nicht bewegen.
• Der Geschwister-Inserter wird jetzt in derselben Reihenfolge wie die HTML-Tab-Reihenfolge angezeigt, was für die Barrierefreiheit gut ist.
• Der Geschwister-Inserter erscheint jetzt unter den Blöcken anstatt über den Blöcken. Dies ist meiner Meinung nach sinnvoller.
• Der Geschwister-Inserter ist für den ausgewählten Block immer sichtbar (außer möglicherweise beim Tippen, wenn die Steuerelemente immer noch unsichtbar sind, wie sie jetzt sind).
• Konsistenz mit der mobilen Benutzeroberfläche.
• Alle Ränder und inneren Auffüllungen von Blöcken konnten entfernt werden, und die Blockränder konnten wieder auf die tatsächliche Größe des Blocks geändert werden, ohne dass die Block-Benutzeroberfläche den Inhalt des Blocks beeinträchtigte.

Bonuspunkte, wenn der Geschwister-Inserter geändert wird, um das Inserter-Menü direkt zu öffnen (wie in # 7271 beschrieben), anstatt einen leeren Absatzblock einzufügen.

Natürlich ist die Frage, was passiert, wenn Sie den Block über den ausgewählten bewegen, immer noch ein Problem. Ich denke jedoch nicht, dass mich das wirklich so sehr stört. Alles, was Sie tun müssen, ist auf den Block zu klicken, um ihn auszuwählen und die Steuerelemente anzuzeigen. Wenn die Hover-Steuerelemente unter dem aktuell ausgewählten Block angezeigt werden, ist dies in Ordnung, da der ausgewählte Block der Fokus sein soll.

Ich denke, dies ist ein gutes Design, um voranzukommen. Ich denke, alle positiven Aspekte überwiegen die negativen, und ich denke, es ist definitiv besser als das, was derzeit existiert. Was denkst du Leute?

Ich habe mich überlegt, wie dies aussieht, wenn sich die oberen und unteren Symbolleisten überlappen, und wie es aussehen würde, wenn der schwebende Block immer den höchsten Z-Index über einen ausgewählten Block nimmt.

Ich mag das sehr, aber es hat ein kleines Problem ... einzelne Zeilenblöcke haben kein Glück, weil sie fast vollständig unter der unteren Steuerleiste versteckt sind.

@chrisvanpatten Ich dachte, dass die untere Leiste tatsächlich Platz

Vielleicht sollte es auch einen Schatten unter der unteren Leiste geben, wenn er etwas überlappt.

@SuperGeniusZeb Ich bin wirklich stark dagegen, dass die untere Leiste Platz

(BEARBEITEN: Um es näher zu erläutern, macht es den Mausbenutzern die Dinge wirklich schwer, weil man sich nicht wirklich darauf verlassen kann, dass sich die Dinge von einem Moment zum anderen an derselben Stelle befinden. Dies verursacht eine Menge Unbeholfenheit.)

@chrisvanpatten

Ich denke hauptsächlich, dass Sie im Zusammenhang mit dem Schreiben von Posts den Absatz unter dem von Ihnen eingegebenen wahrscheinlich nicht vertuschen möchten. Im Moment sieht es so aus, als ob dem Absatzblock unter dem ausgewählten die erste Zeile fehlt. Ich denke, ich würde es vorziehen, wenn die umgebenden Blöcke ein wenig springen, wenn Sie einen auswählen, anstatt den oberen Rand des Blocks nach dem Block, den ich gerade bearbeite, nicht sehen zu können. Persönlich stört mich das Herumspringen nicht sehr.

In Gutenberg ist es ziemlich üblich, dass sich die Größe bei der Auswahl ändert: Platzhalter für Bildunterschriften, Platzhalter für Zitierzitate, Platzhalter / Einfüger in der Galerie und wiederverwendbare Blöcke, wie Sie bereits erwähnt haben. Gutenberg basiert im Allgemeinen auf der Idee, dass das Erscheinungsbild eines Blocks für die Bearbeitung optimiert werden sollte, wenn er ausgewählt wird. Ich würde sagen, dass es in Ordnung ist, die Blockhöhe zu erhöhen, da die untere Leiste Platz beansprucht.

Alternativ könnte die untere Leiste möglicherweise halbtransparent gestaltet werden, um etwas deutlicher zu machen, dass sich darunter ein Block befindet. Wie klingt das? Ich denke, ich könnte damit einverstanden sein.

Das einzige Problem ist, dass Transparenz nirgendwo anders in der Gutenberg-Benutzeroberfläche verwendet wird. Das heißt nicht, dass es nicht verwendet werden sollte ... nur, dass es keine Beispiele dafür gibt, also könnten wir eine Inkonsistenz des UI-Designs einführen.

Es gibt auch die Idee, den leeren Raum zwischen den Steuerelementen links und rechts zu entfernen, aber das wurde früher im Ticket abgeschossen, weil die Benutzeroberfläche zu "blockig" aussah.

@chrisvanpatten Alles in allem denke ich, ich würde Ihr Modell immer noch dem vorziehen, was gerade existiert . Das Problem, dass die erste Zeile des folgenden Blocks zu verschwinden scheint, ist im Vergleich zu all den Dingen, die eines unserer Modelle beheben würde, geringfügig.

@SuperGeniusZeb Ich denke, was es in diesem Fall besonders unangenehm macht, ist, dass die Steuerelemente vorhanden sind, wenn Sie den

Ich denke nicht, dass es sich lohnt, dies wegen der Probleme mit dem Hover / Select / Jump / Single-Line-Absatz aufzugeben, aber ich muss definitiv etwas mehr darüber nachdenken.

Ich bin immer noch zuversichtlich, dass es hier irgendwo eine Lösung gibt… ich muss einfach weiter iterieren!

@chrisvanpatten

Ich denke, was es in diesem Fall besonders unangenehm macht, ist, dass die Bedienelemente vorhanden sind, wenn Sie den Mauszeiger bewegen. Bei allen anderen Beispielen für Sprungsteuerungen sind sie zumindest beim Schweben nicht vorhanden, sondern nur bei Auswahl.

Nun ... Sie könnten keine Steuerelemente auf dem Schwebeflug anzeigen lassen, aber ich denke, es ist sicher anzunehmen, dass niemand das wirklich will. Ich weiß, dass mir die Steuerelemente, die beim Schweben verfügbar sind, auf jeden Fall gefallen.

Wie wäre es mit Transparenz?

Und wenn Sie ein bisschen träumen möchten und wünschen, dass backdrop-filter in allen gängigen Browsern implementiert ist, können Sie einige Unschärfen hinzufügen:

Das ist übrigens 60% Deckkraft.

Opazität hilft definitiv, aber ich bin mir nicht sicher, ob ich Opazität in die Gleichung einführen soll. Es fühlt sich ein bisschen wie Betrug an.

@chrisvanpatten In der Tat fühlt es sich ein bisschen wie Betrug an ... aber welche anderen Optionen haben wir?

Wir können die Steuerelemente nicht auf die Seite legen, daher besteht dieses Problem in erster Linie.

Wir können die Steuerelemente nicht in den Block einfügen, da dies den Inhalt verdecken würde.

Wir können die Steuerelemente nicht oben platzieren, da die Formatierungsleiste bereits vorhanden ist und Probleme auftreten, die bei dünnen Blöcken auftreten würden.

Das Anbringen der Bedienelemente an der Unterseite ist am sinnvollsten, da es für die Barrierefreiheit besser geeignet ist, einen bequemen Ort bietet, an dem sowohl der Geschwister-Inserter als auch der Ziehgriff eingesetzt werden können, um damit verbundene Probleme zu lösen, mit Mobilgeräten konsistenter ist und am besten für dünne Geräte geeignet ist Blöcke.

Um den Platzbedarf in der unteren Leiste zu verringern, können wir nur wenige Dinge tun:

• Verringern Sie die Höhe der Stange.
• Entfernen Sie den leeren Raum zwischen dem Inserter / Mover / Drag-Griff und den Auslassungspunkten.
• Schieben Sie die Auslassungspunkte nach links und entfernen Sie den zusätzlichen Platz rechts.
• Nehmen Sie Platz ein, wenn Sie ausgewählt sind. (Aber das willst du nicht.)

Abgesehen davon können Sie es nur halbtransparent machen, damit es sich optisch leichter anfühlt und leichter zu erkennen ist, was sich darunter befindet.

Ein anderer Gedanke: Vielleicht würde sich die Transparenzsache nicht nach Betrug anfühlen, wenn beide Symbolleisten transparent wären und nicht nur die unterste.

Machte einige weitere Modelle, um einige der oben genannten Dinge auszuprobieren.

Transparente Symbolleisten:

Keine Transparenz:

Ich glaube, ich bevorzuge es eigentlich ohne Transparenz. Was denken Sie? Ich denke, dass das Verkleinern der Breite der unteren Leiste das Problem des überlappenden Starts des nächsten Blocks gelöst hat. Natürlich wird es immer noch bei kleineren Breiten passieren ... aber das passiert ohnehin schon mit der Formatierungssymbolleiste, daher denke ich nicht, dass es hier wirklich ein Problem ist.

Beachten Sie auch, dass ich etwas Platz für einen Ziehgriff gelassen habe. Es kann kleine ausgegraute Punkte geben, die häufig in Apps zur Darstellung von Ziehpunkten verwendet werden, oder es kann ein Ziehsymbol angezeigt werden, das beim Schweben oder ständig angezeigt wird. Oder es könnte einfach leer bleiben. Es könnte auch technisch etwas dünner sein, aber ich habe es aus Komfortgründen die Breite eines Knopfes belassen.

Könnte es das sein? Könnte dies die Iteration sein, die gut genug ist, um die aktuelle zu ersetzen? _ (Bitte sagen Sie "Ja" .: Stuck_out_tongue :) _

Vielen Dank an alle für die hier gemachten Erkundungen. Nur um einen weiteren Grund hinzuzufügen, ist Halbtransparenz nicht ideal: Das Kontrastverhältnis der Symbole zum Hintergrund muss 4,5: 1 betragen. Die Verwendung von Halbtransparenz würde dies unmöglich machen. Denken Sie nur an ein Bild mit vorherrschenden dunklen Farben oder einen Absatz mit dunklem Hintergrund oder ein Thema mit dunklem Hintergrund:

Vielen Dank für die hervorragende Diskussion hier. Es ist ermutigend und erfreulich zu sehen, mit welcher Leidenschaft diese Herausforderung angegangen wird.

Ich habe ein bisschen aus der Ferne zugesehen, nachdem ich die anfängliche Konfiguration des Blocks entworfen hatte - mit einer angedockten Symbolleiste, den Aufwärts- / Abwärtspfeilen an der Seite und schließlich den Auslassungspunkten rechts. Ich habe die Zutaten hinzugefügt, weil ich der Meinung war, dass es sehr nützlich ist, den Umzugsunternehmen erstklassige Immobilien als Alternative zu Drag & Drop zu bieten, was oft fummelig und fehleranfällig ist, während die Umzugsunternehmen in ihrem Verhalten immer vorhersehbar sind.

Ich erkenne die Herausforderungen, die dies für verschachtelte Blöcke mit sich bringt, vollständig und habe lange darüber nachgedacht, was die beste Lösung war. Was im Master enthalten ist - links und rechts überlagern, auch wenn es verschachtelt ist - funktioniert, ist aber auch nicht großartig, das erkenne ich an. Eine andere Möglichkeit ist die Verwendung der mobilen Benutzeroberfläche. Zeigen Sie die Benutzeroberfläche unterhalb des Blocks an, wenn sie ausgewählt ist. Diese Funktion wird hier in verschiedenen Varianten nachgebildet. Dies funktioniert insbesondere für mobile Geräte. Auf dem Desktop kann es jedoch sehr störend und nervös werden, wenn Sie nur einen Absatz auswählen möchten, um eine kleine Bearbeitung vorzunehmen, und alles springt herum. Wenn die Symbolleiste wie in der neuesten Version überlagert wird, scheint sie sich zu weit vom Schreiberlebnis zum Layouterlebnis zu neigen. Dies ist das konstante Gleichgewicht, das wir versucht haben zu erreichen.

Eine zweite Möglichkeit besteht darin, zu den alten Modellen zurückzukehren, die ich hatte:

Vielleicht könnte es mit ein paar Änderungen folgendes sein:

Aber das liebe ich nicht. Und entweder würde dies die Mover nur sichtbar machen, wenn der Block schwebt, oder wir möchten die Behandlung ein wenig optimieren. Außerdem werden die Tastenbereiche um einige Pixel kleiner, was für die Benutzerfreundlichkeit nicht besonders gut ist.

Daher wurden diese Varianten bisher nicht berücksichtigt, da sie sich dem, was wir hatten, nicht überlegen fühlten. Allerdings hier posten, unabhängig davon, ob sie Behandlungen inspirieren können, damit es funktioniert.

Das größte Problem beim Kombinieren der Blockwerkzeuge mit dem Hover-Label besteht darin, dass eine Inkonsistenz zwischen einem ausgewählten und einem Hover-Block entsteht, es sei denn, Sie möchten das Label auch für ausgewählte Blöcke anzeigen. Und wenn Sie das tun, sollte sich das Etikett nicht innerhalb der Blockgrenzen befinden, sondern außerhalb davon.

Aber selbst wenn Sie dies tun, stoßen Sie einfach auf das Problem, zu viele Steuerelemente am oberen Rand des Blocks zu haben und herauszufinden, wie dies sowohl für breite als auch für dünne Blöcke konsistent gemacht werden kann.

Ich bin der festen Überzeugung, dass mit Ausnahme der klebrigen Symbolleisten, die auf dem Bildschirm angezeigt werden, keine der standardmäßig ausgewählten Block-Benutzeroberflächen einen Teil dieses Blocks verdecken sollte.

Wenn Sie die Blockwerkzeuge unten haben, können Sie den Geschwister-Inserter gut platzieren. Dies trägt zum Erreichen des oben genannten Ziels ohne Überlappung bei, macht den Geschwister-Inserter sichtbarer und löst seine eigenen überlappenden Probleme. (Ich denke, die Aktualisierung der verschachtelten Blöcke auf den Quote-Block ist aufgrund überlappender Geschwister-Inserter noch nicht erfolgt.)

Aufgrund der Vorteile des Geschwister-Inserters und der Barrierefreiheit denke ich, dass es der bestmögliche Platz ist, die Block-Werkzeuge unter dem Block zu platzieren.

Nun, ich dachte nicht, dass es auf dem Tisch liegt, die Steuerelemente viel kleiner zu machen, da sie natürlich schwieriger zu bedienen sein könnten, wenn man sie kleiner macht. Da Sie jedoch nicht dagegen zu sein scheinen, warum versuchen Sie es dann nicht?

Wie ist das?

Die Schaltflächen in der unteren Leiste (aber nicht die Symbole) wurden von 38 auf 32 Pixel verkleinert, und ich habe eine Inkonsistenz im Abstand zwischen den Mover-Steuerelementen aus den vorherigen Modellen behoben. Beachten Sie, dass Sie es horizontal etwas verkleinern können, wenn die Auslassungsschaltfläche dünner als die anderen ist (wie die in der oberen Leiste des Editors).

Sie können auch den leeren Ziehpunktbereich verkleinern, damit die Leiste noch weniger Platz beansprucht. Dies wäre sogar noch praktikabler, wenn alle Steuerelemente in der Leiste als Ziehpunkte fungieren würden, beispielsweise wie die oberen Leisten von Fenstern in GNOME funktionieren.

Beachten Sie, dass die Steuerelemente auf Mobilgeräten wahrscheinlich fast genauso aussehen wie in master , wo die Balken Platz beanspruchen und es daher kein Problem ist, sie zu vergrößern. Diese Größenreduzierung sollte nur Desktop-Benutzer betreffen, und die Steuerelemente können bei dieser Größe weiterhin durch Berühren verwendet werden.

Ich habe auch eine kleine Untersuchung durchgeführt, bei der die Steuerelemente in eine obere Symbolleiste verschoben wurden, wodurch eine Reihe von Problemen gelöst werden. Wenn Sie jedoch den Block auswählen, haben Sie wieder eine Alles-Symbolleiste, die in engen Kontexten nicht funktioniert ein wesentlicher Grund für diese Erkundung in erster Linie.

Ich versuche immer noch herauszufinden, wie ich mich zu diesen letzten Modellen fühle. Die Bedienelemente, die unten hängen, fühlen sich für mich etwas unangenehm an. Ich bin mir nicht sicher, ob ich eine bessere Idee habe. Es bringt uns nur zu dem blockigen / fragmentierten Gefühl zurück, das @karmatosed vermeiden wollte.

Vielen Dank an alle für die Arbeit hier. Ich werde versuchen, ein Feedback zu geben, aber ich muss jetzt sagen, dass ich nicht der Meinung bin, dass dies bereit ist, in den Prototyp überzugehen. Ich denke immer noch, dass es Probleme mit dem Verschachteln und auch mit verschiedenen zu lösenden Geräten gibt, aber wie ich in früheren Kommentaren erwähnt habe, denke ich nicht, dass der aktuelle Track richtig ist. Ich denke, wir kehren ja auch in das Gebiet zurück, von dem ich bereits vorgeschlagen habe, dass wir dies vermeiden.

Ich möchte nicht davon abhalten, etwas zu erkunden, aber im Moment würde ich vorschlagen, über alternative Vorschläge nachzudenken. Ein großes Problem ist, dass das Hinzufügen von halben Registerkarten am unteren Rand die visuelle Dichte ohne Verstärkung erhöht. Lassen Sie uns darüber nachdenken, was wir hier zu lösen versuchen:

• Was passiert auf verschiedenen Geräten?
• Einfügen von Geschwistern (obwohl dies in anderen Problemen behoben werden könnte) oder zumindest wie es interagiert.
• Verschachtelungssichtbarkeit und einfache Interaktion.

Der Hauptantrieb bei all dem war, wie es reagierte und verschachtelte.

Lassen Sie uns überlegen, was wir erstellen, wenn wir die Benutzerfreundlichkeit erhöhen oder verringern. Wenn Sie beispielsweise Transparentfolien und Ebenen verwenden, ist dies für Personen mit normalem Sehvermögen in Ordnung, für viele andere jedoch nicht. Denken Sie an komplexe Layouts, solche mit Videos und vielen Bildern. In dieser dichten Informationsstruktur hält das, was vorgeschlagen wird, nicht stand.

Denken Sie an komplexe Layouts, solche mit Videos und vielen Bildern. In dieser dichten Informationsstruktur hält das, was vorgeschlagen wird, nicht stand.

Ja, ich denke, dies ist der größte Punkt, und ich würde diese Dichte wirklich in kleineren Räumen hinzufügen, was ein weiterer Teil der Herausforderung ist. Verschachtelte Blöcke benötigen im Allgemeinen dieselben Steuerelemente wie nicht verschachtelte Blöcke, müssen jedoch mit einem Bruchteil des Speicherplatzes und im Idealfall auf nicht eindeutige Weise ausgeführt werden (z. B. sollten verschachtelte Blöcke im Allgemeinen nicht verschachtelten Blöcken ähneln; Konsistenz erzeugt Benutzerfreundlichkeit).

Zurück zum Zeichenbrett… 🙂

Warum ich denke, mein Modell ist besser als die aktuelle Benutzeroberfläche

Ich verstehe den Wunsch, einen blockartigen Look zu vermeiden, aber ich muss noch etwas finden, das nicht blockartig aussieht, aber dennoch genauso funktional ist. Das Problem ist, dass Sie die Kanten des Blocks kennen müssen, in dem Sie arbeiten, und dass die Steuerelemente sowohl den Inhalt des Blocks als auch möglichst wenig außerhalb des Blocks verdecken sollen. Das garantiert so ziemlich einen etwas blockigen Look.

Wenn Sie sich nur den Screenshot oben in dieser Ausgabe ansehen, können Sie sehen, wie Gutenberg zu einem bestimmten Zeitpunkt eine sehr unblockierte Block-Benutzeroberfläche hatte. Das Problem mit dieser Benutzeroberfläche war jedoch, dass es schwierig war zu sagen, wo sich die Kanten eines Blocks befanden. Deshalb haben wir die Benutzeroberfläche, die wir jetzt haben.

Und wenn Sie die Probleme mit dem Geschwister-Inserter einwerfen, stellen Sie fest, dass sich die Schaltfläche zum Geschwister-Inserter außerhalb des Inhaltsrahmens des Blocks befinden muss. Kombinieren Sie dies mit dem Punkt, an dem Sie normalerweise Blöcke nach dem aktuellen (und nicht vorher) einfügen möchten, und dem Wunsch nach verbesserter Zugänglichkeit, und Sie müssen so etwas wie mein neuestes Modell haben.

Persönlich würde ich diese blockige Benutzeroberfläche etwas vorziehen, das wie die ersten Modelle aussieht. Diese ersten Modelle sehen aufgrund der fehlenden Grenze zwischen Inhalten und Steuerelementen verwirrend aus, und die Balken verbrauchen viel unnötigen Platz. Da wir keine springende Benutzeroberfläche wünschen, muss die untere Leiste eine Überlagerung des Inhalts außerhalb des ausgewählten Blocks sein und sollte daher so klein wie möglich sein.

Außerdem denke ich, dass mein Modell in verschachtelten Kontexten definitiv besser ist als das aktuelle. Wie ich weiter unten erläutern werde, sind die überlappenden Symbolleisten / Inhaltssituationen mit dieser Benutzeroberfläche besser als mit der vorherigen. Und in verschachtelten Kontexten müssen Sie die Grenzen eines Blocks noch besser kennen, sodass ein etwas blockartiges Aussehen in dieser Situation tatsächlich hilfreich ist.

Überlappende Symbolleisten sind viel weniger verwirrend und weniger wahrscheinlich ein Problem, da Blöcke auf kleinen Bildschirmen viel weniger vertikal klein sind als auf kleinen Bildschirmen, was zu Problemen mit Dingen wie dem Spaltenblock führte . Wenn ein Textblock dünner wird, wird sein Text umbrochen und größer.

In verschachtelten Kontexten wird durch Bewegen des Mauszeigers über dem aktuellen Block fast nie der gesamte Inhalt des darunter liegenden Blocks verdeckt, da entweder der Block breit genug ist, damit die untere Leiste nicht alles abdeckt, oder der Block fair ist groß und so hätte es noch Platz, um es auszuwählen.

Außerdem sollte die untere Leiste eines Blocks nur angezeigt werden, wenn Sie mit der Maus über den Block fahren, und nicht nur, wenn sich Ihre Maus in der Nähe befindet. Aufgrund der seltsamen, unsichtbaren Ziehpunkte an den Seiten von Blöcken ist dies bei der aktuellen Benutzeroberfläche nicht der Fall.

Um den obigen Punkt zu ergänzen, kann nur der Block über dem aktuellen alles im ausgewählten Block verdecken. Die anderen 3 Seiten sind völlig in Ordnung, da das Schweben eines horizontal benachbarten Blocks nichts im aktuellen Block verdeckt und schwebende Blöcke keine Benutzeroberfläche darüber haben. Daher ist es auch in Ordnung, den Block unter dem ausgewählten Block zu bewegen.

Darüber hinaus können Sie einfach festlegen, dass schwebende Blöcke niemals den aktuell ausgewählten Block verdecken. Dies würde in verschachtelten Kontexten zu buchstäblich null überlappenden Problemen mit dem ausgewählten Block führen. Da schwebende Blöcke nur einen Balken unten haben, würde der unter dem aktuellen Balken niemals den ausgewählten überlappen. Das einzige, was Sie in dieser Situation aufgeben, ist die Möglichkeit, auf die Blockwerkzeuge für den Block über dem aktuellen zuzugreifen, sofern Sie diese nicht auswählen.

Noch eine Idee: Die untere Leiste könnte automatisch ausgeblendet werden, wenn Sie mit dem Cursor über einen anderen Block fahren. Es würde nicht zurückkommen, bis Sie den Cursor wieder in die Ränder des Blocks bewegen. Dies könnte in verschachtelten Kontexten noch mehr helfen.

Darüber hinaus können Sie die Formatierungssymbolleiste an die obere Leiste des Editors andocken, wenn Sie in verschachtelten Kontexten noch weniger Überlappungsprobleme wünschen. (Dies hat keine Auswirkungen auf Mobilgeräte, aber auf Mobilgeräten nehmen die Balken Platz ein und überlappen nichts, sodass es überhaupt keine Überlappungsprobleme gibt.)

Insgesamt denke ich, dass sich durch mein letztes Modell mehr Situationen verbessert haben als Situationen, die sich verschlimmert haben.

So wie es ist, denke ich, dass so etwas wie mein Modell (oder in der Nähe davon) weit mehr Probleme löst, als es schafft. Darüber hinaus umfassen die Vorteile:

• Funktioniert für alle Blockbreiten.
• Bessere Zugänglichkeit für Geschwister-Inserter, Bewegungssteuerung und Auslassungspunkte.
• Bessere Sichtbarkeit und Auffindbarkeit für Geschwister-Inserter und Drag-Handle.
• Die Ziehbereiche an der Seite des Blocks können entfernt werden, und die Hover-Beschriftung muss nicht zu einem Ziehpunkt werden (sie ist sowieso etwas klein).
• Der Geschwister-Inserter befindet sich unter den Blöcken, wo Sie ihn normalerweise verwenden möchten (im Gegensatz zu oben).
• Keine separate Benutzeroberfläche für Geschwister-Inserter erforderlich, wodurch die Komplexität verringert wird.
• Geschwister-Inserter haben in verschachtelten Kontexten keine Überlappungsprobleme mehr. (Ich denke, das ist der Grund, warum # 6520 noch nicht passiert ist.)
• Die Blockblock-Benutzeroberfläche, die einen Block umgibt, überlappt niemals den Inhalt dieses Blocks.
• Die automatischen Ränder von Blöcken könnten entfernt werden, und ein Block könnte keinerlei innere Auffüllung aufweisen, und die Blockoberflächenränder könnten wieder in die tatsächlichen Inhaltsränder geändert werden, und dennoch würde nichts im Inhalt des Blocks von Steuerelementen überlappt. Diese Art von Randfällen tritt bei benutzerdefinierten Blöcken auf, daher ist es gut, sie zu berücksichtigen.
• Alle Blockwerkzeuge sind ziemlich nahe beieinander, was es einfacher macht, sie alle zu erreichen und zu entdecken, verglichen mit der vorherigen Situation, in der sich die Ellipsen und Pfeilbeweger auf gegenüberliegenden Seiten des Blocks befinden.
• Es ist sehr klar, an welchen Block die Steuerelemente angehängt sind, verglichen mit der Verwirrung, die Sie häufig mit den aktuellen Steuerelementen in verschachtelten Kontexten erhalten.
• Die Steuerelemente sind konsistenter mit mobilen.

Also ja, ich denke, mein Modell funktioniert in verschachtelten Kontexten tatsächlich besser, und ich denke, dass die blockartige Benutzeroberfläche im Vergleich zu dem, was Sie gewinnen, kaum wichtig ist. Was denken Sie? Wenn Sie nicht einverstanden sind, können Sie auf Situationen hinweisen, in denen das Modell erheblich schlechter als die aktuelle Benutzeroberfläche wäre und keiner der zuvor genannten Vorschläge es lösen würde?

Es gibt ... eine andere ... ~ Skywalker ~ Idee

Wenn alles andere fehlschlägt, habe ich eine Idee, mit der alle wichtigen Probleme technisch behoben werden können. Was wäre, wenn die Formatierungssymbolleiste immer wie in Gutenberg 1.6 oben angedockt wäre, diesmal jedoch die Bewegungssteuerung und die Auslassungspunkte über den Blöcken anstatt seitlich angezeigt würden? (Alternativ können Sie sie auch noch wie mein Modell unten haben.)

In diesem Konzept würde der Geschwister-Inserter nicht existieren, da der Inserter in der oberen Leiste des Editors dieselbe Funktion erfüllen würde und in diesem Zusammenhang näher an der Reichweite wäre, da sich die Formatierungssymbolleiste im selben Bereich befinden würde.

Die mobile Benutzeroberfläche wäre genau die gleiche wie jetzt. Diese Änderung würde nur Desktop- (und möglicherweise Tablet-) Benutzer betreffen.

Aber warte, da ist noch mehr!

Wenn Sie darüber nachdenken, was ist der Unterschied zwischen dieser Idee und dem einfachen Modellieren und Aktivieren der Fix-Symbolleiste ? Das einzige, was Sie durch das vollständige Entfernen von Inline-Formatierungssymbolleisten von Mobilgeräten erhalten, ist die Möglichkeit, die Bewegungssteuerelemente und Auslassungspunkte über den Blöcken anstatt unter den Blöcken anzuzeigen. Und technisch gesehen könnte dies nur ein Teil der Option Fix Toolbar to Top sein .

Vergleichen Sie mit der aktuellen Benutzeroberfläche, in der Fix Toolbar to Top nicht alle überlappenden Steuerungsprobleme beseitigt, da die seitliche Benutzeroberfläche immer noch auf zwei Seiten aufgeteilt ist und die verwirrenden unsichtbaren Ziehpunkte immer noch vorhanden sind und sich die Geschwister-Inserter in verschachtelten Kontexten immer noch überlappen. und ETC.

Ist es definitiv in Stein gemeißelt für die Zukunft, dass jeder Textabschnitt ein separater Block ist? In diesem Fall müsste bei der Anzeige von Blockwerkzeugen die Auswahl mehrerer Textblöcke berücksichtigt werden (was meiner Meinung nach irgendwann eintritt).

@padraigobeirn Das ist ein guter Punkt, den ich vergessen hatte.

Insbesondere berücksichtigen die Steuerelemente in der aktuellen Benutzeroberfläche keine langen Auswahlen. Die Bewegungssteuerung und die Auslassungspunkte bleiben oben links und rechts vom ersten Block in der Auswahl. Auch die Formatierungssymbolleiste bleibt nur für den ersten Block in der Auswahl klebrig. Siehe # 7962.

Für die untere Leiste in meinen Modellen können Sie sie theoretisch mit mehreren Auswahlen verwenden, indem Sie sie beim Scrollen nach oben am unteren Bildschirmrand kleben lassen. Dieses klebrige Verhalten ist jedoch möglicherweise nur für die ausgewählten Blöcke wünschenswert.

Weißt du, ich fange wirklich an zu denken, dass Fix Toolbar to Top standardmäßig aktiviert sein sollte.

Es gibt wirklich nur so viel, was Sie tun können, um so viele Steuerelemente um einen Block herum anzubringen, und selbst bei meinen neuesten Modellen gibt es immer noch Fälle, in denen sich die Benutzeroberfläche überfüllt fühlen könnte. Es gibt auch Bedenken, dass sich die Benutzeroberfläche zu blockig anfühlt.

Um diese Probleme zu beheben, sollte das Andocken der Formatierungssymbolleiste an die Spitze die Standardeinstellung sein. Dies spart Platz um einen Großteil des Blocks und reduziert die Anzahl möglicher Überlappungen von Steuerelementen drastisch.

Ich denke, ich bevorzuge immer noch, dass sich die Bewegungssteuerelemente und Auslassungspunkte unten befinden, aber sie können auch nach oben verschoben werden, wenn die Formatierungssymbolleiste angedockt ist. Wenn die Formatierungssymbolleiste nicht am Block angebracht ist, kann die Blocksymbolleiste auch unten rechts oder oben rechts platziert werden, ohne umständlich auszusehen oder zu viel Platz zu verbrauchen.

Ich denke, ich würde jedoch entweder unten links oder unten rechts bevorzugen. Auf diese Weise kommen die Steuerelemente sowohl visuell als auch in Tabulatorreihenfolge nach dem Block, was für mich am sinnvollsten ist. Es ist sinnvoller, den Geschwister-Inserter nach einem Block dort hineinzuwerfen, als ihn vor einem Block erscheinen zu lassen.

Randnotiz: Ich habe kürzlich festgestellt, dass der E-Mail-Builder in Infusionsoft tatsächlich ein eigenes "Block" -Konzept hat und Block-Tools (Duplizieren und Löschen) über den Blöcken oben rechts angezeigt werden. Die Formatierungssteuerelemente werden in einer Leiste oben im Editor angezeigt, wenn der Cursor einen Textbereich betritt.

Ich habe kürzlich festgestellt, dass der E-Mail-Builder in Infusionsoft tatsächlich ein eigenes "Block" -Konzept hat und Block-Tools (Duplizieren und Löschen), die oben rechts in den Blöcken angezeigt werden. Die Formatierungssteuerelemente werden in einer Leiste oben im Editor angezeigt, wenn der Cursor einen Textbereich betritt.

Könnten Sie einige Screenshots dieser Schnittstelle @SuperGeniusZeb schneiden?

Als ich anfing, Gutenberg zu verwenden, war ich definitiv eine "Fix Toolbar to Top" -Person, aber nachdem ich es eine Weile benutzt habe, bin ich mir nicht sicher, ob ich zurückkehren möchte. Ich bin mir völlig bewusst, dass die Symbolleiste in vielerlei Hinsicht die Ursache all dieser Probleme ist - es ist am wahrscheinlichsten, dass viele Dinge in verschachtelten Kontexten abgeschnitten werden und Platz beanspruchen, den Sie für die seitlichen Steuerelemente verwenden könnten - aber sie haben gepaart mit dem Block ist einfach sooo schön. Es hält alles, was Sie brauchen, an einem Ort, vermeidet viele Augen- und Mausbewegungen usw. Ich bin überrascht, es jetzt zu sagen, aber ich denke, das wäre etwas, ohne das ich nicht leben könnte.

Könnten Sie einige Screenshots dieser Schnittstelle @SuperGeniusZeb schneiden?

@chrisvanpatten Nein, ich hatte nur vorübergehenden Zugriff darauf, während ich jemandem half.

Ich fühle mich bei festen / nicht festen Formatierungssymbolleisten in keiner Weise wirklich stark, aber ich würde mich zu festen neigen, da dies dazu beitragen würde, die visuelle Unordnung um Blöcke herum zu verringern. Was bevorzugen andere Menschen aufgrund des Feedbacks der Benutzer und warum?

@chrisvanpatten Es wurde ein Artikel gefunden, in dem jemand über den E-Mail-Builder in Infusionsoft spricht und ein Video davon hat:

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

@chrisvanpatten Argh, ich habe gerade nachgesehen und es sieht so aus, als ob das Video veraltet ist ... es sieht so aus, als ob die Formatierungssymbolleiste an Blöcke angehängt wurde, so wie es Gutenberg gerade tut. Interessant, dass sie es geändert haben.

Einige Gedanken:

Wenn Sie einen Block in die Mitte eines Beitrags einfügen möchten, möchten Sie dies normalerweise nach dem von Ihnen ausgewählten Block tun, oder? Normalerweise möchten Sie _vor_ dem ausgewählten Block nicht einfügen. Das Einfügen nach einem Block ist auch aus Sicht der Barrierefreiheit sinnvoll. Ist jemand damit nicht einverstanden? Für mich scheint dies ein starkes Argument dafür zu sein, dass Geschwister-Inserter irgendwo am Ende eines Blocks erscheinen.

Geschwister-Inserter sollten den Inhalt des ausgewählten Blocks nicht überlappen. Nichts sollte den Inhalt des ausgewählten Blocks dauerhaft überlappen. Ist jemand damit nicht einverstanden? Dies lässt mich glauben, dass Geschwister-Inserter außerhalb des Inhalts des ausgewählten Blocks positioniert werden sollten.

Ich weise darauf hin, weil ich denke, dass der Geschwister-Inserter unabhängig davon, wohin die Bewegungssteuerung und die Auslassungspunkte gehen sollen, in einer Art Symbolleiste unter dem ausgewählten Block erscheinen muss, selbst wenn dies alles für sich und / oder die Symbolleiste ist kein Rand / Hintergrund. Ich denke, es könnte fast genauso aussehen wie jetzt, aber nach unten verschoben und geändert, um unter Blöcken und nicht über ihnen zu erscheinen.

Ein anderer Gedanke: Wäre es eine Verbesserung gegenüber master , die Ellipse auf die gleiche Seite wie die Bewegungspfeile zu setzen oder umgekehrt? Dies könnte viele Probleme mit überlappenden Steuerelementen in verschachtelten Kontexten lösen, auf Kosten einer größeren Anzahl von Block-Benutzeroberflächen auf der linken (oder rechten) Seite eines Blocks.

Ich habe gerade # 8836 ausprobiert. Ich denke, wenn es zusammengeführt wird, könnte es helfen, die schweren / blockigen UI-Probleme zu reduzieren, die viele der UI-Designs in diesem Ticket zu haben scheinen.

In den Tickets Nr. 9074 und Nr. 9075 schlage ich zwei kleine Schritte vor, die von dieser Diskussion inspiriert sind, um die Situation zu entschärfen und zu verbessern. Im ersten Fall wird vorgeschlagen, die Schaltfläche "Auslassungspunkte / Mehr" in die Symbolleiste zu verschieben, sodass nur ein Teil der seitlichen Benutzeroberfläche (Mover) vorhanden ist. Im anderen Fall wird vorgeschlagen, die Einstellungen der Block-Symbolleiste zu reduzieren, damit sie besser passen dünne Kontexte.

Um sie auf dem neuesten Stand zu halten, habe ich meine @jasmussens Tickets vorgeschlagenen Änderungen und die jüngsten Änderungen an der Benutzeroberfläche in 3.6 zu berücksichtigen:

Das Verschieben der Pfeilbeweger unter Blöcke ist möglicherweise nicht mehr erforderlich, wenn # 9074 und # 9075 implementiert sind. Es könnte in Ordnung sein, wenn sie auf der Seite des Blocks bleiben, da die Auslassungspunkte benachbarter Blöcke sie in Dingen wie Spalten nicht mehr überlappen würden. Wenn Lösungen für # 8880, # 8881 und # 8883 auftreten würden und wenn # 8836 und # 8920 implementiert würden, wäre die Benutzeroberfläche möglicherweise bereits für verschachtelte Kontexte in Ordnung. Ich fange an, mich darauf zu lehnen, dass die Aufwärts- / Abwärtspfeile auf der linken Seite des Blocks bleiben.

Trotzdem denke ich immer noch, dass der Geschwister-Inserter definitiv unter Blöcke gehört , obwohl Sie definitiv nur den Geschwister-Inserter alleine unter Blöcken erscheinen lassen könnten. Vielleicht könnte es wie der aktuelle Geschwister-Inserter zentriert sein, aber wie die Auf- / Ab-Bewegungssteuerung wirken und aussehen und als schwebende Taste unter den Blöcken erscheinen, wenn Sie im unteren Teil eines Blocks schweben.

Konzentrieren wir uns darauf, die Iterationen in @jasmussen zu erhalten , an denen in # 9074 und # 9075 gearbeitet wird. Dann können wir die nächsten Schritte in Betracht ziehen. Ich möchte eine Menge Dinge ändern, aber lasst uns das Gleichgewicht halten.

Dank der oben genannten # 9074 und # 9075 sowie anderer Probleme und PRs wie # 8920 und # 9197 habe ich entschieden, dass das Bewegen der Pfeilbeweger unter den Block nicht mehr viele Vorteile hat.

Stattdessen schlage ich jetzt vor, dass nur der Geschwister-Inserter unter den Block bewegt wird, der als schwebende Steuerung ähnlich wie die Auf- / Ab-Mover fungiert und erscheint. Siehe # 9202.

Lassen Sie uns diesen vorerst schließen, da aus dieser und anderen Diskussionen viele Verbesserungen hervorgegangen sind. Die letzten Verfeinerungen betreffen den nachlaufenden Inserter.