Gutenberg: Erweitern Sie die Tools zur Auswahl von untergeordneten / übergeordneten Blöcken

Ich mag die Idee mit den Semmelbröseln. (Eigentlich habe ich im April in # 6459 etwas ziemlich Ähnliches vorgeschlagen.) Was würde mit den Breadcrumbs passieren, wenn die Unified Toolbar aktiviert ist?

Ich denke auch, dass die Click-through-Idee auch gut ist und bereits auf Mobilgeräten verwendet wird, um die Konsistenz zu erhöhen. Ich bin mir jedoch nicht so sicher über die Passthrough-Idee. Ich stelle mir vor, dass dies aufgrund unterschiedlicher Verhaltensweisen in verschiedenen Blöcken zu Verwirrung führen könnte.

Ich mag die Semmelbrösel, aber ich mag auch die einheitliche Symbolleiste. Können wir eine andere Position für den Brotkrumen finden :)

Außerdem mag ich persönlich die Ränder um den übergeordneten Block nicht. Aber wenn wir sie behalten, wie behandeln wir Multiselection :). Sollten wir Ränder um das übergeordnete Element der mehrfach ausgewählten Blöcke anzeigen?

Ich mag die Click-through-Option. Dies erfordert einige zusätzliche Arbeiten am 'Passthrough'-Block (so dass beispielsweise jede einzelne "Spalte" nicht als Ebene zum Klicken angesehen wird), aber ich denke, dass dies sehr sinnvoll ist.

Was würde mit den Breadcrumbs passieren, wenn die Unified Toolbar aktiviert ist?
Ich mag die Semmelbrösel, aber ich mag auch die einheitliche Symbolleiste. Können wir eine andere Position für den Brotkrumen finden :)

Gute Frage. Schnelles und schmutziges Modell:

Ja, ich sehe die Herausforderung des doppelten Symbols für den Umschalter. Ich finde es gut, weiter darüber nachzudenken. Beachten Sie auch, dass bei diesem Entwurf die Dokumentkontur weggelassen wird, die in # 4287 blockiert ist.

Außerdem mag ich persönlich die Ränder um den übergeordneten Block nicht. Aber wenn wir sie behalten, wie behandeln wir Multiselection :). Sollten wir Ränder um das übergeordnete Element der mehrfach ausgewählten Blöcke anzeigen?

Ich denke, es ist wichtig, sie als Hinweis darauf zu zeigen, dass die inneren Blöcke Teil der übergeordneten Gruppe sind. Sie verzweigen die inneren Blöcke.

Im Moment funktioniert die Mehrfachauswahl folgendermaßen:

Und das passiert, wenn Sie nur zwei untergeordnete Blöcke auswählen:

Mit anderen Worten, im Master haben wir den übergeordneten Rand bereits, und wir verstecken ihn, wenn wir untergeordnete Blöcke mehrfach auswählen. Ich denke tatsächlich, dass es sinnvoll ist, den übergeordneten Rand auch bei Mehrfachauswahl immer anzuzeigen, wenn Sie nur untergeordnete Blöcke auswählen. Aber vielleicht sollten wir die Mehrfachauswahl anders machen, wenn der _parent_-Block mehrfach ausgewählt ist. Anstatt jeden untergeordneten Block mit additiven Ebeneneffekten hervorzuheben, markieren wir nur den übergeordneten Block. Funktioniert das?

Ich mag die Click-through-Option. Dies erfordert einige zusätzliche Arbeiten am 'Passthrough'-Block (so dass beispielsweise jede einzelne "Spalte" nicht als Ebene zum Klicken angesehen wird), aber ich denke, dass dies sehr sinnvoll ist.

Ja, im Moment stellt der untergeordnete Block _column_ einige Herausforderungen an die Benutzeroberfläche. Sie können beispielsweise keinen Block davor einfügen. Warum können Sie ihn also auswählen? Es ist jedoch eine enorm schwierige technische Herausforderung, und ich verstehe die damit verbundenen Herausforderungen. Ich behaupte also nicht, dass dies einfach ist.

Als ich an https://github.com/WordPress/gutenberg/pull/9653 arbeitete , stellte ich fest, dass die bereits vorhandene Pfeiltastennavigation zum Navigieren in der Hierarchie vorhanden ist (verwenden Sie die Pfeiltaste nach oben, wenn eine Spalte ausgewählt ist, um das übergeordnete Element auszuwählen , dh der Spaltenblock) funktioniert wirklich gut. So gut, dass es möglicherweise ausreichen könnte, diese Funktion einfach als "Auf" -Schaltfläche anzuzeigen, ähnlich wie "Zum übergeordneten Ordner wechseln" im Windows-Datei-Explorer, anstatt die vollständigen Brotkrumen zu verwenden.

So könnte das aussehen. Obere Symbolleiste:

Symbolleiste blockieren:

CC: @youknowriad

Einige Gedanken

Semmelbrösel

Ich mag die Breadcrumb-Lösung, aber sie leidet unter Mehrdeutigkeiten. Eine Benutzeroberfläche nur für Symbole kann problematisch sein, und ich kann sehen, wie ich über Symbolen schwebe, um zu sehen, was sie sind, oder die Breadcrumbs für eine Symbolleiste mit Optionen und nicht für Breadcrumbs verwirren.

Vielleicht ist die obere Symbolleiste nicht der beste Ort, um sie anzuzeigen, und vielleicht würden einige Hinweise von Brotkrumen an anderer Stelle helfen. Zum Beispiel die Hierarchie-Symbolleiste in PHPStorm, die die Datei -> Klasse -> Methode / Funktion anzeigt, in der Sie sich gerade befinden, oder die Ordnersymbolleiste in MacOS Finder und Windows Explorer?

Durchklicken

Ein Klick wäre eine versteckte Benutzeroberfläche. Ich kann viele Missverständnisse und Verwirrungen feststellen, da die Leute erwarten, einen Bildblock nur auszuwählen, um festzustellen, dass der enthaltende Spaltenblock ausgewählt ist. Normalerweise ist das Klicken durch die Benutzeroberfläche in der Adobe-Software verwirrend, da sie Modi einführt, und es ist schwierig zu sagen, wo Sie sich befinden und wie Sie sie beenden können, insbesondere wenn es Verschachtelungen gibt. Wenn Sie beispielsweise doppelklicken, um einen untergeordneten Block einzugeben, wie gelangen Sie dann zum übergeordneten Block zurück und wie zeigt die Benutzeroberfläche an, dass Sie sich in einem Block befinden?

Es gibt viele Recherchen und Richtlinien zu Modi, und etwas sollte nicht als gut angesehen werden, da es in Illustrator oder Photoshop vorhanden ist. Es muss viel mehr Arbeit investiert werden, als nur durchzuklicken, bevor es zu einer geeigneten Lösung wird.

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

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

Dies ignoriert alle Zugänglichkeitsfaktoren, mit denen dies ebenfalls zu tun hat.

Die Schaltfläche Nach oben

Die Up-Button-Idee ist nett. Ich würde mir Sorgen machen, dass wenn Sie darauf drücken, eine Abwärtstaste angezeigt wird und der Block sich nach oben bewegt, mehrdeutig ist und dieselben Probleme hat wie der Breadcrumbs-Block

Das Muster für wiederverwendbare Blöcke

Derzeit haben wiederverwendbare Blöcke bereits ein UI-Muster, das der Blockschnittstelle Chrom hinzufügt, das im Frontend nicht sichtbar ist. Könnten Spalten nicht dasselbe tun?

Oder ein super Müllmodell von dem, was ich meine

Das Chrom des Spaltenblocks wird also zur Auswahl verwendet, und es bietet etwas Visuelles, auf das die Maus zielen kann.

Ein potenzielles UX-Muster, das wir hier verwenden könnten und das zu unserem Symbolleistenmodell passt, ist die Schaltfläche zum Durchlaufen des OS X-Ordners: https://cld.wthms.co/avtQLO

Ich würde bemerken, dass ich denke, dass Benutzer erwarten können, dass sie untergeordnete / übergeordnete Blöcke visuell durch Klicken und Auswählen auswählen können, aber es ist offensichtlich sehr komplex, dies richtig zu machen. Das obige Durchquerungsmuster könnte ein guter erster Schritt sein, und wir könnten in Phase 2 tiefer in die Entwicklung einer eleganteren Lösung eintauchen.

Ich liebe dieses Konzept Alexis, insbesondere für die komplexeren Blöcke, wie Sie erwähnen. Ich liebe es so sehr, dass ich sofort damit lief und einige der Modelle neu mischte, um Ihre Idee zu veranschaulichen.

Keine Auswahl:

Block ausgewählt:

Verschachtelter Block innerhalb ausgewählt:

Das Popout der Schaltfläche zum Durchlaufen von Ordnern wird geöffnet:

☝️ Ich bin ein bisschen verliebt in dieses Konzept. Es fühlt sich so an, als würde es alle Ideen und Rückmeldungen, die in diesem Thread geteilt werden, zusammenführen, sodass eine solide Basislinie entsteht. Vielen Dank für diese neue Perspektive!

Ich mag das Dropdown-Menü mit dem visuellen Baum. Ein Teil von mir ist der Meinung, dass es auch hilfreich wäre, das gesamte Dokument in diesem Format zu sehen, und bietet sogar eine nützliche Möglichkeit, Dinge neu zu ordnen.

Beim weiteren Nachdenken wurde ich jedoch daran erinnert, dass wir bereits einen solchen Auswahlmechanismus und eine Dokumentübersicht im Infofenster haben:

Dies könnte durch das Styling in Ihrem Modell verbessert werden und als zusätzlicher Auswahlkennzeichen dienen. Im Moment werden nur Titel angezeigt, aber eine Version mit einem vollständigen Blockbaum und einem Auswahlindikator wäre sehr nützlich

Mein einziges Problem ist das Symbolleistensymbol. Es ist ein weiteres Mystery-Symbol mit einem Pfeil und eine Schaltfläche, die unter MacOS standardmäßig nicht im Finder enthalten ist, es sei denn, Sie passen die Symbolleiste an. Für diejenigen von uns, die symbolblind sind und nicht leicht zwischen Symbolen unterscheiden können, ist dies problematisch

Mit dem Textetikett ist es klarer, aber ohne es würden die meisten nicht wissen, was es getan hat, ohne darauf zu klicken:

Sieht gut aus :) Können wir versuchen, das Symbol ein wenig zu vereinfachen, um die Lesbarkeit zu verbessern? Vielleicht 3 Zeilen mit etwas mehr Abstand statt 4?

Mit der Textbeschriftung ist es klarer, aber ohne sie würden die meisten nicht wissen, was es getan hat, ohne darauf zu klicken.

Es wird auch einen Tooltip geben.

In dem Kommentar von re: @tomjn denke ich auch, dass es sich lohnt, zu untersuchen, ob dies in den gesamten Dokumentbaum integriert werden kann, anstatt einen separaten Ort zu erstellen. Die Herausforderung besteht darin, die Einfachheit und Scannbarkeit des Baums beizubehalten und gleichzeitig viel mehr Material aufzunehmen. Aber vielleicht ähnelt das eher dem Ebenenbedienfeld in Sketch oder Photoshop (in der Funktionalität, nicht im Design!), Wo es die einzige Quelle der Wahrheit für die gesamte Seitenstruktur ist. Herausfordernd, gut abzuschneiden, aber vielleicht eine Erkundung wert?

Auch dies ist wahrscheinlich etwas, worüber wir iterieren. Was ist also das nützlichste MVP, das zu etwas Anspruchsvollerem heranwachsen kann?

Es wird auch einen Tooltip geben.

Ich denke nicht, dass das genug ist, aber ich denke, dass dies eine separate Diskussion und eine Feature-Anfrage ist. Ich werde ein neues Ticket eröffnen

Können wir versuchen, das Symbol ein wenig zu vereinfachen, um die Lesbarkeit zu verbessern? Vielleicht 3 Zeilen mit etwas mehr Abstand statt 4?

Ich mag es:

Beim weiteren Nachdenken wurde ich jedoch daran erinnert, dass wir bereits einen solchen Auswahlmechanismus und eine Dokumentübersicht im Infofenster haben:

Ich denke auch, dass es sich lohnt, zu untersuchen, ob dies in den gesamten Dokumentbaum integriert werden kann, anstatt einen separaten Ort zu erstellen.

Ich denke das könnte funktionieren. Ich habe zuvor vorgeschlagen, dass das Element als Plugin umgeschrieben werden könnte, damit es rechts angezeigt wird (siehe # 4287). Aber ich bin ein Fan davon, dies für den Dokumentbaum zu verwenden.

In Bezug auf eine Beschriftung mag ich Beschriftungen, aber die Option, die Blocksymbolleiste oben anzukoppeln, muss in diesem Licht berücksichtigt werden.

Diese Diskussion erinnert mich an # 9053 (CC: @westonruter) - Ich denke, Ihnen könnte Alexis 'Vorschlag gefallen, wie in https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989 gezeigt.

Schön zu sehen, wie es weitergeht und danke für das Konzept @alexislloyd. @jasmussen Ich mag diese

Was ist das nützlichste MVP, das zu etwas Anspruchsvollerem heranwachsen kann?

Ich würde sagen, dies als einfachere Durchquerungssteuerung zu erstellen und später zu prüfen, ob es sinnvoll ist, es basierend auf der Auswahl mit dem Dokumentinhaltsfeld zu kombinieren.

Öffnen Sie dies gemäß der Diskussion in # 10767 erneut, um es zu wiederholen.

Siehe auch zusätzliche Ideen, die in # 11159 vorgeschlagen werden.

Eine zusätzliche Idee, um das Arbeiten mit komplexen Blöcken zu vereinfachen, besteht darin, sich daran zu erinnern, dass der nicht ausgewählte Block eine Vorschau ist und der ausgewählte Block zusätzliche Bearbeitungssteuerelemente anzeigen kann.

Wir können diese Idee nutzen, um die Auswahl der Elemente eines Spaltenblocks zu vereinfachen. Wenn beispielsweise ein Spaltenblock oder ein untergeordnetes Element davon ausgewählt ist, wird das Auffüllen des Containers animiert, um Platz für die Auswahl untergeordneter Elemente zu schaffen. Dies würde auch die seitliche Benutzeroberfläche zugänglich machen. Wir möchten einen Rand um den übergeordneten Block zeigen - den mit erweiterter Auffüllung - zum Beispiel eine gestrichelte Linie.

Dies scheint relativ trivial zu sein, wenn wir die Klasse .is-selected im Block der obersten Ebene wiederherstellen würden, selbst wenn ein Kind ausgewählt wird. Wir haben dies vor einiger Zeit mit einer hasSelectedInnerBlocks-Requisite gemacht.

Folgendes sehen wir, wenn Sie mit der Maus über eine Zelle in einem Spaltenblock fahren:

Bewegen Sie den Mauszeiger über eine Zelle im Medien- und Textblock.

Man sieht den inneren Block und den äußeren Block.
Wie Spalte -> Absatz. Spalte -> YouTube. Medien & Text -> YouTube

Es wäre gut, die Breadcrumbs-Informationen (innere und äußere Blöcke) in den Hover-Informationen anklickbar zu machen. Klicken Sie auf Spalte, um übergeordnetes Element auszuwählen, oder klicken Sie auf Absatz, um untergeordnetes Element auszuwählen.

Als ich dies gerade ausprobierte, fiel mir auf, dass der einfachste Weg, einen übergeordneten Spaltenblock auszuwählen, darin besteht, den zusätzlichen unsichtbaren Trefferbereich zu verwenden, den wir rechts / links vom übergeordneten Block anbieten:

Dieser zusätzliche Trefferbereich ist oben und unten im Block nicht verfügbar, was die Auswahl auf diese Weise erheblich erschwert.

Eine weitere Idee, um die Arbeit mit komplexen Blöcken zu vereinfachen, besteht darin, sich daran zu erinnern, dass der nicht ausgewählte Block eine Vorschau ist und der ausgewählte Block zusätzliche Bearbeitungssteuerelemente anzeigen kann

Wir können diese Idee nutzen, um die Auswahl der Elemente eines Spaltenblocks zu vereinfachen. Wenn beispielsweise ein Spaltenblock oder ein untergeordnetes Element davon ausgewählt ist, wird das Auffüllen des Containers animiert, um Platz für die Auswahl untergeordneter Elemente zu schaffen. Dies würde auch die seitliche Benutzeroberfläche zugänglich machen. Wir möchten einen Rand um den übergeordneten Block zeigen - den mit erweiterter Auffüllung - zum Beispiel eine gestrichelte Linie.

Ich bin mir nicht 100% sicher, ob dies das ist, was @jasmussen oben vorschlägt, aber das Hinzufügen von

Wenn jemand den Block verlässt, kann diese zusätzliche Auffüllung verschwinden, um eine genauere Darstellung des Blocks anzuzeigen.

Dieser zusätzliche Trefferbereich ist oben und unten im Block nicht verfügbar, was die Auswahl auf diese Weise erheblich erschwert.

Ich könnte schwören, dass es ein Ticket für dieses Problem gibt, das damit zusammenhängt, wie der Geschwister-Inserter auch funktioniert. Ich kann es momentan nicht finden, aber ich glaube, dieses Problem sollte behoben werden können. @aduth läuten irgendwelche Glocken, ich könnte schwören, dass Sie in den Kommentaren waren?

Ich bin mir nicht 100% sicher, ob dies das ist, was @jasmussen oben vorschlägt, aber das Hinzufügen von

Das ist mehr oder weniger genau das, was ich meinte, nur schöner visualisiert als ich konnte.

Hier ist eine zusätzliche Kreideskizze, um zu veranschaulichen, was ich meine. Spalten blockieren:

Im Wesentlichen was Sie haben, Kjell - vielleicht mit einer etwas dunkleren gestrichelten Linie. Denken Sie auch daran, dass es je nach Weiterentwicklung des Spaltenblocks auch _column_-Blöcke gibt. Dh die aktuelle Hierarchie ist _Columns → Column → Image_. Wir verwenden heftige CSS-Assistenten, um die 2. Ebene mehr oder weniger unsichtbar zu machen. Wenn Sie dies jedoch in Zukunft auswählen möchten, um beispielsweise eine CSS-Klasse darauf anzuwenden oder andere Optionen, die wir möglicherweise für einzelne Spalten benötigen, ist dies der Fall bedenkenswert.

Diashow-Block:

Um es klar auszudrücken: Es ist kein Diashow-Block geplant. Dies wird nur gekritzelt, um einen Punkt zu veranschaulichen, an dem die Vorschau- und Bearbeitungsmodi eines Blocks sehr unterschiedlich sein können. Es ist so einfach und überraschend störungsfrei, durch einfaches Auswählen und Abwählen der Blöcke zwischen den beiden Modi zu wechseln, dass wir uns erlauben sollten, uns darauf einzulassen und kreativ über die Möglichkeiten zu sein.

Im Falle eines Diashow-Blocks ist der Inhalt fast per Definition außerhalb des Bildschirms / Blocks unsichtbar. Aber es muss nicht sein, wenn Sie es bearbeiten. Wählen Sie einfach den Block aus, um Miniaturansichten mit bearbeitbaren Beschriftungen anzuzeigen. Deaktivieren Sie dann den Block, um eine Vorschau des Ergebnisses anzuzeigen.

Ich könnte schwören, dass es ein Ticket für dieses Problem gibt, das damit zusammenhängt, wie der Geschwister-Inserter auch funktioniert. Ich kann es momentan nicht finden, aber ich glaube, dieses Problem sollte behoben werden können. @aduth läuten irgendwelche Glocken, ich könnte schwören, dass Sie in den Kommentaren waren?

Ich denke, das Nächste könnte eines von # 8883, # 8881, # 5180 sein?

Obwohl der Dokumentbaum hilfreich ist, muss ich den Fokus von dem ändern, was ich manipulieren möchte. Ich hätte wirklich gerne eine bessere Möglichkeit, direkt durch die tatsächlichen Blöcke und verschachtelten Blöcke zu klicken. Ich denke, die oben von @jasmussen beschriebene Klickmethode ist es wert, näher untersucht zu werden.

Hier ist das Problem, das ich häufig habe:

Als Benutzer werde ich mindestens eine Minute damit kämpfen, bevor ich eine andere Lösung finde, die sich irgendwo anders auf dem Bildschirm befindet. 😉

* _wenn ich diesen Kommentar hinzugefügt habe, erschienen eine Reihe weiterer Kommentare. Es mag jetzt nicht so relevant sein, aber ich behalte es hier, um den Kampf zu dokumentieren.

Das Hinzufügen von Auffüllungen + einer visuellen Anzeige des übergeordneten Blocks im Bearbeitungsmodus könnte hier eine große Hilfe sein. Auf diese Weise erhalten Sie einen klaren Hinweis darauf, wo Sie klicken sollten, wenn Sie das übergeordnete Element auswählen möchten:

Mein Anliegen bei dieser Lösung ist, wie die Polsterung in Bezug auf umgebende Blöcke funktioniert:

1. Wird die Auffüllung im übergeordneten Block im Frontend wiedergegeben? Oder einfach mehr Polsterung im Editor?

2. Wird das Auffüllen dynamisch hinzugefügt, wenn der Block wie folgt ausgewählt wird?

1. Oder erscheint der gepolsterte Elternteil so über den umgebenden Blöcken?

Ich versuche nur, mich weiter mit diesem Konzept zu befassen. Würde gerne ein paar Gedanken dazu haben.

Danke @aduth , du hast mich dazu gebracht, mindestens ein Ticket zu finden, das in die richtige Richtung geht. Das GIF in # 9229 erklärt das Problem: Der gelbe Bereich in diesem GIF ist für den Geschwister-Inserter "reserviert". Dies hindert Sie daran, den Block auszuwählen, indem Sie auf den Abstand über oder unter dem Block klicken. Das ist die Antwort auf @kjellrs Kommentar:

Dieser zusätzliche Trefferbereich ist oben und unten im Block nicht verfügbar, was die Auswahl auf diese Weise erheblich erschwert.

Zur weiteren Verdeutlichung dient dieser gelbe Bereich nur dazu, die Schaltfläche zum Einfügen von Geschwistern SICHTBAR zu machen. Alles, was wir wirklich abfangen müssen, ist die Schwebeflugaktion. Es wäre schön, wenn sich ein Klick noch durch diesen gelben Balken ausbreiten und Sie den folgenden Block auswählen könnten.

Obwohl der Dokumentbaum hilfreich ist, muss ich den Fokus von dem ändern, was ich manipulieren möchte. Ich hätte wirklich gerne eine bessere Möglichkeit, direkt durch die tatsächlichen Blöcke und verschachtelten Blöcke zu klicken. Ich denke, die oben von @jasmussen beschriebene Klickmethode ist es wert, näher untersucht zu werden.

Sie können dies jetzt tatsächlich testen, auch wenn die aktuelle Implementierung etwas halbherzig ist.

• Führen Sie Gutenberg aus, eine beliebige Version.
• Fügen Sie einen Spaltenblock mit Inhalt ein.
• Ändern Sie die Größe des Fensters unter den 600px-Haltepunkt und wählen Sie dann.

Dies ist für Mobilgeräte implementiert, mit anderen Worten, damit Sie den übergeordneten Block einfacher auswählen können.

GIF:

Das Problem bei der Implementierung besteht derzeit darin, dass der "Status" zurückgesetzt wird, sobald Sie einen Drilldown auf die tiefste Ebene durchgeführt haben. Es ist also Spalten> Spalte> Absatz, Spalten> Spalte> Absatz, auch wenn Sie denselben Absatz nur zweimal auswählen. Die offensichtliche Lösung für dieses Problem besteht darin, es so zu gestalten, dass Sie, sobald Sie auf die gewünschte Ebene "heruntergebohrt" sind, auf dieser Ebene bleiben, bis Sie den Block wieder abwählen. Dh Spalten> Spalte> Absatz, Absatz, Absatz, Abwählen, Zurückspulen usw.

Ich glaube auch, dass für einige Blöcke diese Klickmethode von entscheidender Bedeutung sein wird. Vor allem, wenn wir uns Seitenvorlagen ansehen, die alle Arten von verschachtelten Inhalten enthalten können.

Die Inspiration dafür, wie Click-through funktionieren kann, wenn es erstaunlich ist, kann auch in Keynote ausprobiert werden. Fügen Sie einige Formen ein und Sie können sie direkt anklicken. Sobald Sie zwei Formen gruppieren, werden sie zu einer neuen Form, die sich leicht bewegen lässt. Um den Inhalt der Gruppe zu bearbeiten, müssen Sie jedoch doppelklicken.

Um Ihre guten Fragen unter https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172 zu beantworten:

Wird die Auffüllung im übergeordneten Block im Frontend wiedergegeben? Oder einfach mehr Polsterung im Editor?

Nein, diese Auffüllung befindet sich nur im Editor und nur, wenn der Block ausgewählt ist. Dies basiert auf dem Block ist das Schnittstellenprinzip , das im Editor besagt:

• Ein nicht ausgewählter Block ist eine Vorschau. Es sollte so gut wie das Frontend aussehen
• Ein ausgewählter Block ist im Wesentlichen der "Blockbearbeitungsmodus", und der Block kann in diesem Zustand zusätzliche Steuerelemente ausgeben und sogar völlig anders aussehen.

Dies ist, was ich versucht habe, mit dem obigen Doodle-Block-Doodle hervorzuheben: Wenn der Diashow-Block nicht ausgewählt ist, handelt es sich um eine Diashow. Wenn es ausgewählt ist, befinden Sie sich im Bearbeitungsmodus für Diashows und sehen ein Miniaturbildraster für jede Folie, sodass Sie Untertitel einfach bearbeiten, neu anordnen usw. können.

Wird das Auffüllen dynamisch hinzugefügt, wenn der Block wie folgt ausgewählt wird?

Ja, mehr oder weniger.

Ich denke, dies könnte einen Prototyp wert sein, um es besser zu erklären und ein Gefühl dafür zu bekommen.

Letztendlich sollte diese Funktion wahrscheinlich eine Requisite auf dem Block selbst sein, etwas, für das sich ein Block entscheiden kann. Ein Blockzitat mit verschachtelten Absätzen sollte diese Schnittstelle wahrscheinlich nicht verwenden - aber beim Bearbeiten von Spalten ist sie möglicherweise perfekt.

Hier ist ein kurzer Codepen-Prototyp: https://codepen.io/joen/pen/exmMQv?editors=1100

Es ist ein bisschen statisch, aber es bringt hoffentlich den Punkt rüber.

Hier ist ein kurzer Codepen-Prototyp: https://codepen.io/joen/pen/exmMQv?editors=1100

Es ist ein bisschen statisch, aber es bringt hoffentlich den Punkt rüber.

Das hilft wirklich, den Punkt zu vermitteln. Ich habe eine leichte Änderung vorgenommen, damit wir sehen können, wie diese gestrichelten Ränder beim Klicken angezeigt werden:

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

Das ist perfekt, danke Kjell! Genau das meine ich. Ich glaube, wir werden wahrscheinlich einige Aspekte der Implementierung optimieren und uns damit befassen wollen, wie es aussieht, wenn das unmittelbare übergeordnete Element (einzelne Spalte) dasjenige ist, das aufgefüllt wird. Aber das ist cool! Ich denke es kann funktionieren.

Das gefällt mir wirklich gut.
Sollten wir eine PR zum Testen mit mehr Blöcken und Inhalten erstellen?
Müssen wir identifizieren, welche Blöcke dies bewirken wird?

Ich grabe es auch.

Wir können dies wahrscheinlich vorerst auf dem Columns-Block prototypisieren, aber damit es landet, müssten wir wahrscheinlich beide Methoden generisch sein, damit andere Blöcke (wie Sie sagen) dies verwenden können, aber auch eine Requisite, so dass ein Block dies kann Entscheide dich dafür. Es wird wahrscheinlich störend sein, wenn der Quote-Block dies hat, sobald er verschachtelte Blöcke empfängt.

@gziolo irgendwelche Gedanken? Insbesondere zu dem Ansatz, den Kjell in https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415 kritzelte

@gziolo irgendwelche Gedanken? Insbesondere zu dem Ansatz, den Kjell in # 9628 kritzelte (Kommentar)

Sieht großartig aus. Dies würde es endlich möglich machen, den übergeordneten Block bei Bedarf einfach auszuwählen. Meine einzige Frage ist, wie Sie sich fühlen würden, wenn Sie die Breite der Säule näher an die ursprüngliche Größe bringen würden, um andere Säulen enger zu machen. Im Moment werden alle Spalten verkleinert, wenn eine von ihnen ausgewählt wird. Dies kann bei mehr als 3 Spalten zu einer suboptimalen Erfahrung führen. @jasmussen hast du noch andere fragen, die ich beantworten soll?

Meine einzige Frage ist, wie Sie sich fühlen würden, wenn Sie die Breite der Säule näher an die ursprüngliche Größe bringen würden, um andere Säulen enger zu machen.

Ich würde eher zustimmen, dass dies etwas ist, das wir fein abstimmen und ausbalancieren sollten, wahrscheinlich in der Umsetzung. Wir können auch versuchen, die Breite / Höhe des Elternteils zu vergrößern, um die Größe des Kindes nicht zu verringern, obwohl dies wahrscheinlich technisch schwieriger ist.

Hast du noch andere Fragen, die ich beantworten sollte?

Grundsätzlich lautet die hier diskutierte Schnittstelle: Fügen Sie dem übergeordneten Block bei Auswahl des untergeordneten Blocks eine Auffüllung hinzu, um die Auswahl zu vereinfachen . Dies fühlt sich gut an in Kjells Prototyp für den Columns-Block. Es wird wahrscheinlich in anderen Blöcken, wie z. B. Abschnittsblöcken oder vielen anderen Blöcken, in denen der untergeordnete Inhalt wahrscheinlich den gesamten verfügbaren Speicherplatz im Inneren ausfüllt, sehr willkommen sein. Aber es wäre wahrscheinlich nicht so schön für so etwas wie den Quote-Block, der zwar noch keine Verschachtelung verwendet, dies aber wahrscheinlich in Zukunft tun wird.

Es wäre also schön, diese übergeordnete Schnittstelle so zu erstellen, dass sie für alle Blöcke generisch ist, standardmäßig deaktiviert, aber ein Block könnte sich für die Verwendung einer Requisite entscheiden.

Haben Sie Vorschläge, wie Sie das am besten angehen können?

Alle Blöcke, die verschachtelte Blöcke enthalten (Spalten, Medien und Text im Moment), rendern diese InnerBlocks -Komponente, die die Klasse .editor-inner-blocks rendert:
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
Dies könnte helfen, eine allgemeine Lösung zu finden, die mit allen verschachtelten Blöcken funktioniert. Es kann jedoch schwierig sein, da .is-selected in einem der untergeordneten Elemente angewendet wird.

Edit: Wenn es nicht ausschließlich mit CSS funktioniert. Wir können immer eine Möglichkeit finden, den Status des übergeordneten Elements zu aktualisieren, um dort die Information anzuzeigen, dass einer der verschachtelten Blöcke ausgewählt ist. @jorgefilipecosta und @aduth haben möglicherweise mehr Einblicke, da sie viel Zeit mit verschachtelten Blöcken verbracht haben :)

Es wäre also schön, diese übergeordnete Schnittstelle so zu erstellen, dass sie für alle Blöcke generisch ist, standardmäßig deaktiviert, aber ein Block könnte sich für die Verwendung einer Requisite entscheiden.

Welche Blöcke betrachten Sie für diesen Ansatz, die keine Verschachtelung verwenden? Das ließ mich darüber nachdenken, warum sie überhaupt keine Verschachtelung verwenden. Stellen Sie sich vor, wir konvertieren die Galerie in einen Container mit verschachtelten Bildblöcken. Wir würden dieses Verhalten kostenlos bekommen, aber auch als Bonus sortieren.

Welche Blöcke betrachten Sie für diesen Ansatz, die keine Verschachtelung verwenden?

Die Galerie ist interessant.

Ehrlich gesagt denke ich hauptsächlich an fortgeschrittenere Layoutblöcke wie Grid-Layoutblöcke oder Tabgroup-Blöcke oder andere ähnliche "Seitenerstellungs" -Blöcke. Alles, was inhaltsspezifisch ist, sollte diese Schnittstelle wahrscheinlich nicht verwenden.

Ehrlich gesagt denke ich hauptsächlich an fortgeschrittenere Layoutblöcke wie Grid-Layoutblöcke oder Tabgroup-Blöcke oder andere ähnliche "Seitenerstellungs" -Blöcke. Alles, was inhaltsspezifisch ist, sollte diese Schnittstelle wahrscheinlich nicht verwenden.

Ich gehe davon aus, dass alle unter die Kategorie Containerblöcke passen, was bedeutet, dass sie InnerBlocks als Implementierungsdetail verwenden sollten, daher sollten sie in diese Kategorie passen. Wir können weiterhin ein Opt-out anbieten, ähnlich wie wir es für andere Funktionen mit der Gruppe supports in der Blockdefinition tun.

Ich gehe davon aus, dass alle unter die Kategorie Containerblöcke passen, was bedeutet, dass sie InnerBlocks als Implementierungsdetail verwenden sollten, daher sollten sie in diese Kategorie passen

Aber würde der Quote-Block nicht auch innere Blöcke verwenden, wenn er Verschachtelungsfunktionen erhalten hätte?

Aber würde der Quote-Block nicht auch innere Blöcke verwenden, wenn er Verschachtelungsfunktionen erhalten hätte?

Ja, Zitat, Liste, Deckung - diese 3 wurden in der Vergangenheit als in verschachtelte Blöcke umgewandelt angesehen.

Eine Sorge (die das Experimentieren nicht blockieren sollte, aber nur erwähnenswert ist!) Ist, dass es bereits einige Probleme mit Spaltenblöcken gibt, wie eng sie sein können und wie sich dies auf Werkzeuge im Bearbeitungsmodus auswirkt. Durch diesen Vorschlag werden Spalten während der Bearbeitung von Interaktionen effektiv noch enger, wodurch diese Engpassprobleme erneut auftreten können.

Es geht auch weiter weg von einer 1: 1-Bearbeitungs- / Ansichtsparität, die ein Problem sein kann oder nicht. Zugegeben, ich mache bereits etwas Ähnliches (zusätzliches Auffüllen bei Auswahl) für einen benutzerdefinierten Block mit InnerBlocks, und es funktioniert gut - aber die Bearbeitungsansicht ist nicht ganz genau.

Es wäre also schön, diese übergeordnete Schnittstelle so zu erstellen, dass sie für alle Blöcke generisch ist, standardmäßig deaktiviert, aber ein Block könnte sich für die Verwendung einer Requisite entscheiden.

Die Möglichkeit, sich für so etwas zu entscheiden, wäre beim Erstellen des Jetpack Form-Blocks großartig gewesen.

Es geht auch weiter weg von einer 1: 1-Bearbeitungs- / Ansichtsparität, die ein Problem sein kann oder nicht.

Ich denke, dass es in Ordnung ist, einige Änderungen zwischen dem ausgewählten und dem nicht ausgewählten Status vorzunehmen, insbesondere wenn dadurch die UX verbessert wird ... obwohl dies jetzt in Bezug auf die inneren Blöcke argumentiert werden kann.

Was passiert auch, wenn ich Blöcke 3 tief verschachtelt habe? Erweitert sich die Auffülloption auf die zweite Ebene, wenn die zweite Ebene auch ein übergeordneter Block ist?

@mapk

Was passiert auch, wenn ich Blöcke 3 tief verschachtelt habe? Erweitert sich die Auffülloption auf die zweite Ebene, wenn die zweite Ebene auch ein übergeordneter Block ist?

Das Auffüllen aller betroffenen Verschachtelungsebenen scheint zu großen Zu- und Abnahmen zu führen, wenn tief verschachtelte Blöcke ausgewählt werden, z. B. ein Absatz in einem Zitat in einer Spalte in einer Zeile in einem Abschnitt. Im Idealfall sollte die Auswahl eines Blocks das Erscheinungsbild jedes anderen Blocks nicht drastisch verändern. Daher erscheint es mir ausreichend, nur den Abstand des unmittelbaren übergeordneten Blocks zu ändern.

Solange Sie das unmittelbare übergeordnete Element auswählen können, können Sie sich in der Hierarchie nach oben arbeiten, da das Auswählen des übergeordneten Elements dazu führt, dass das übergeordnete Element leicht ausgewählt werden kann, und so weiter. Das Menü "Blocknavigation" kann für einen schnelleren Zugriff verwendet werden. Wie einige bereits vorgeschlagen haben, kann es in eine feststeckbare Seitenleiste umgewandelt werden, damit schnell darauf zugegriffen werden kann. (Siehe Nr. 11408 und Nr. 11688.)

Ich würde jederzeit vorschlagen, dass die Änderung der Auffüllung NUR den ausgewählten Block und die direkten Nachkommen betrifft.

Nur für den Fall, dass sich dies auf diese Arbeit auswirkt, kann ich schnell feststellen, dass die Arbeit, die ich landen möchte, um dem Spaltenblock eine vertikale Ausrichtung hinzuzufügen, die _individuellen_ Spalten auswählbar macht (zuvor waren sie nicht auswählbar).

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

Die Arbeit, die ich landen möchte, um dem Spaltenblock eine vertikale Ausrichtung hinzuzufügen, macht die _individuellen_ Spalten auswählbar (zuvor waren sie nicht auswählbar).

Vielen Dank, dass Sie das hier zur Kenntnis genommen haben. Das ist umso mehr ein Grund, diese Interaktion eher früher als später aufzuräumen.

Ich wollte nur etwas mitteilen , das ich heute mit habe .

Dies kommt in einigen der obigen Modelle ein wenig

In diesem Beispiel verwende ich einen dunklen Rand für den fokussierten Zustand. Wenn der Block ein übergeordneter oder untergeordneter Block ist, habe ich einen gepunkteten Lichtrand (sowie einige zusätzliche Auffüllungen) um die anderen verwandten Elemente eingefügt. Auf diese Weise können Benutzer klar erkennen, wo sie sich in der Blockhierarchie befinden, und gleichzeitig erkennen, wo sie klicken können, um andere verschachtelte Blöcke auszuwählen.

@kjellr Das

Allerdings… ich denke, wir würden wieder auf ein Problem mit Kontrast auf der gepunkteten Linie stoßen. Ich kann es nicht mit Sicherheit sagen, aber mein Verdacht ist, dass die Einführung der gepunkteten Linie bedeutet, dass die Kriterien für die Barrierefreiheit eingehalten werden müssen. Und ich denke, dass ein viel höherer Kontrast wahrscheinlich zu einer gewissen visuellen Schwere führen wird, die die Vorteile zunichte machen könnte…

Ich denke nur ein bisschen laut nach. Mag den Look als gut sehender Benutzer wirklich, wäre aber neugierig, ein Feedback zu hören, da es mir nicht ausreicht :)

Auf meinem Bildschirm sah ich zuerst nicht einmal die gepunktete Linie. Es erscheint praktisch unsichtbar, wenn mein Bildschirm nur ein wenig geneigt ist.

Der Kontrast muss nicht so stark verringert werden, wenn er dadurch weniger zugänglich wäre. Solange es ein kleines Feuerzeug ist und ein anderes border-style denke ich, würde es gut funktionieren.

Entschuldigung - hätte in meinem ursprünglichen Kommentar klarer sein sollen: Ich habe dieses Modell in nur wenigen Minuten erstellt, während ich mit Joen gesprochen habe. Ich glaube, ich habe zufällig einige Grautöne ausgewählt, die zu diesem Zeitpunkt auf meinem Bildschirm angezeigt wurden. 😄 Die genauen Farbtöne sollen keine endgültige Lösung vermitteln, sondern nur einen allgemeinen Ansatz.

Als Reaktion auf Bedenken hinsichtlich des Hinzufügens von Auffüllungen zum übergeordneten Block, die dazu führen, dass die inneren Blöcke nicht mehr mit dem Frontend übereinstimmen (# 14148 # 14169), habe ich eine andere Idee entwickelt.

Dies erfordert mehr Entwicklung, kann aber eine gute Option sein.

Wenn Sie in den übergeordneten Block klicken, wird dieser grundsätzlich erweitert (größer als normale Blöcke), um die für eine einfache Auswahl von Kindern und Eltern erforderliche Auffüllung bereitzustellen. Dadurch bleiben die inneren Blöcke visuell mit dem Frontend konsistent.

Screencast

InVision-Prototyp

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

PROS

1. Die inneren Blöcke bleiben die richtige Breite.
2. Die inneren Blöcke bleiben optisch konsistent mit dem Frontend.
3. Eine ausgewählte Blockänderungsgröße ist ein bereits verwendetes Muster.

Nachteile

1. Das Erweitern der Blockauswahl (Breite) über die normale Blockauswahl hinaus ist ein neues Muster.
2. Ich bin nicht sicher, wie das funktionieren wird, wenn Blöcke auf volle Breite eingestellt sind.

Wenn Sie in den übergeordneten Block klicken, wird dieser grundsätzlich erweitert (größer als normale Blöcke), um die für eine einfache Auswahl von Kindern und Eltern erforderliche Auffüllung bereitzustellen. Dadurch bleiben die inneren Blöcke visuell mit dem Frontend konsistent.

Grabe das aus. Ich würde es lieben, wenn die Block-Symbolleiste bündig mit dem linken Rand bleibt, aber das ist ein Implementierungsdetail.

Auf kleineren Bildschirmen wird es eine Herausforderung sein, wenn es nicht wirklich größer werden kann, aber dies fühlt sich auch wie etwas Lösbares an.

Insbesondere scheint es so, als ob dieser Ansatz auf jeden Block mit inneren Blöcken skaliert werden kann, selbst auf den Anführungsblock, der ein so grundlegender Textblock ist, dass die Auswahl so ungehindert wie möglich sein sollte.

Wirklich, wirklich graben Sie Ihre Arbeit, Kjell - es könnte nicht nur unsichtbar mit Marks Idee funktionieren, sondern es hilft auch, die Struktur des Dokuments hervorzuheben, wenn Sie es brauchen, aber den Fluss nicht zu unterbrechen, wenn Sie nur schreiben möchten. Es fühlt sich nach einer soliden Richtung an, und wir brauchen als nächstes einen starken Entwickler.

In einem Implementierungshinweis - das gestrichelte übergeordnete Element könnte theoretisch dieselbe Farbe wie der ausgewählte Block haben, aber aufgrund des Strichs würde es immer noch zweitrangig erscheinen. Wenn Sie mit der Maus über das übergeordnete Element fahren, kann der Umriss fest werden, und wir können sogar das _child_ (das Sie beim Schweben ausgewählt haben) streichen lassen, um anzuzeigen, was beim Klicken passieren wird.

In einem Implementierungshinweis - das gestrichelte übergeordnete Element könnte theoretisch dieselbe Farbe wie der ausgewählte Block haben, aber aufgrund des Strichs würde es immer noch zweitrangig erscheinen. Wenn Sie mit der Maus über das übergeordnete Element fahren, kann der Umriss fest werden, und wir können sogar das _child_ (das Sie beim Schweben ausgewählt haben) streichen lassen, um anzuzeigen, was beim Klicken passieren wird.

Ja! Ich denke, das könnte auch total funktionieren. Mal sehen, wo # 14145 Netze sind, und dann eine Behandlung von dort herausfinden. 👍

Ich habe auch an Rändern herumgebastelt, als ich einzelne Spalten auswählbar gemacht, aber als außerhalb meines PR-Bereichs liegend entfernt habe. Fühlte mich definitiv wie eine UX-Verbesserung. Ich liebe die Richtung, in die das geht!

Nur ein Kopf hoch: Ich spinne die obige Idee in ein separates, prägnantes Thema für die Erkundung. Folgen Sie hier:

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

Wenn sich jemand einschalten kann, um Elternblöcken eine has-child-selected -Klasse hinzuzufügen, wenn sein Kind ausgewählt wird, ist dies der einzige Blocker, um dies zu starten.

Ein verwandtes Problem, das ich beim Testen des neu eingeführten Gruppenblocks festgestellt habe:

Was im Moment verwirrend ist, ist, dass beim Einfügen eines Gruppenblocks tatsächlich der Absatzblock angezeigt wird:

Können wir wenigstens so etwas tun wie:

oder was @mtias in unserem privaten Chat mit der Wiederverwendung der

_Diese sind keineswegs endgültige Entwurfsvorschläge 😃_

@gziolo dieses Problem soll durch # 14241 gelöst werden. Ich stimme dir übrigens zu, also wäre es schön, das bald zu versenden :)

@gziolo dieses Problem soll durch # 14241 gelöst werden. Ich stimme dir übrigens zu, also wäre es schön, das bald zu versenden :)

Nun, ich würde teilweise sagen. Wenn Sie mit diesem neuen benutzerdefinierten Inserter einen Absatz einfügen, kehren wir zum ersten Quadrat zurück 🤷‍♂️

Ich denke, dass # 14935 auch hier helfen wird. Wir sollten auch einige Optionen in der Seitenleiste untersuchen, um mehr Möglichkeiten zu haben, um sicherzustellen, dass der aktuell ausgewählte Block verschachtelt ist.

Ah ja. Ich habe darüber nachgedacht, die Semmelbrösel in der Seitenleiste wiederzubeleben, wie wir es hier getan haben:

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

Einfach und relativ elegant und würde auch diesem Problem helfen (9628).

Einige der oben genannten Ideen wiederholen:

Was wäre, wenn wir die Blocktransformationen / -stile in ein eigenes Element verschieben und das Blocksymbol in ein eigenes "Blockbaum" -Panel verwandeln würden?

Ich denke, dies könnte die Sichtbarkeit der Blocktransformationen / -stile erhöhen und gleichzeitig den Leuten helfen, ein wenig klarer zu anderen verschachtelten Blöcken zu navigieren. Hier ist ein Modell eines komplizierteren Beispiels:

(Beide Kompositionen verwenden auch die Umrisse / Auffüllungen von # 14961)

Das sieht sehr interessant aus Kjell! Es würde dann mit dem Blocknavigationsbereich verknüpft, um Konsistenz zwischen ihnen herzustellen. Wenn man lernt, die Blocknavigation zu verwenden, kann das gleiche Lernen weiterhin verschachtelte Blöcke auswählen.

Ich mag das Modell auf konzeptioneller Ebene sehr, aber etwas an der Ausführung fühlt sich etwas dicht an. Ich weiß nicht, dass ich unbedingt eine bessere Idee habe, aber ich frage mich, ob es eine Möglichkeit gibt, dies ein bisschen leichter zu machen?

Ich weiß, dass ich Schwierigkeiten hatte, einen schnellen Überblick über meine Blockstruktur zu finden. Daher ist dieses Konzept eine großartige Idee, um dieses Problem zu lösen.

Mein Anliegen hier ahmt das von @chrisvanpatten nach . Es ist zwar gut durchdacht, aber es fühlt sich nach viel an.

1. In einigen Blöcken gibt es in bestimmten Kontexten verschiedene Möglichkeiten, Dropdowns anzuzeigen.

Ich denke, das Hinzufügen eines weiteren Chevrons zur Mischung (obwohl es grau und nach rechts zeigt) könnte das Parsen schwieriger machen.

1. Das andere Problem ist, dass die Symbolleiste länger wird. Vielleicht ist dies keine große Sache, aber es kann sein, dass wir Beschriftungen für die Symbole https://github.com/WordPress/gutenberg/issues/10524 und https://github.com/WordPress/gutenberg/issues/ einfügen. 15311.

Nur ein paar Gedanken zum Nachdenken. Dies kann der einfachste Ansatz sein, der kommuniziert, was los ist.

Ich frage mich, ob es eine Möglichkeit gibt, dies etwas leichter zu machen.

Ja, ich denke, das hat etwas mit dem Mangel an Hierarchie zu tun. Das erste Symbolleistenelement sollte sich eher wie das Erdungselement anfühlen, und die anderen sollten sich wie sekundäre Optionen für den Block anfühlen. Eine Art Trennung ist erforderlich. Dies ist nicht die richtige Lösung, aber nur zum Zwecke der Unterhaltung denke ich, dass dies nur ein wenig hilft:

In einigen Blöcken gibt es in bestimmten Kontexten verschiedene Möglichkeiten, Dropdowns anzuzeigen. Ich denke, das Hinzufügen eines weiteren Chevrons zur Mischung (obwohl es grau und nach rechts zeigt) könnte das Parsen schwieriger machen.

Das wäre möglich. Es gibt wahrscheinlich eine andere Möglichkeit, dies darzustellen, an die ich auch nicht denke. Ehrlich gesagt könnte es sogar ein einfacheres zusätzliches "Blockbaum" -Symbol in der Symbolleiste sein, das automatisch für alle übergeordneten oder untergeordneten Elemente hinzugefügt wird:

Das andere Problem ist, dass die Symbolleiste länger wird. Vielleicht ist dies keine große Sache, aber es kann sein, dass wir Beschriftungen für die Symbole # 10524 und # 15311 einfügen.

Einverstanden. Unabhängig davon, ob dies die Richtung ist oder nicht, müssen wir ohnehin eine Lösung für überlange Symbolleisten finden. Ich denke, Bemühungen wie https://github.com/WordPress/gutenberg/pull/16557 helfen dabei ein wenig, ebenso wie umfassendere Überarbeitungen der Symbolleistenhierarchie wie https://github.com/WordPress/gutenberg/issues/ 15096.

Eine Sache, die mir an der Idee eines Blockbaums als Symbolleistenschaltfläche auffällt, ist, dass er als Blocksymbolleistenelement einzigartig ist und sich nicht auf etwas bezieht, das dem Block selbst eigen ist, sondern vielmehr darauf, wie sich der Block darauf bezieht der Rest des Dokuments.

Das ist mehr eine Überlegung als alles andere, aber um eine Analogie von Grafik-Apps zu verwenden, würde diese Art der "Überlagerung" und "Gruppierung" der Benutzeroberfläche normalerweise (ich bin sicher, es gibt Beispiele, die mich als falsch erweisen) nur auf Dokumentenebene existieren anstatt auf Blockebene zugänglich zu sein.

Ich weiß, dass es verschiedene Zugänglichkeitsprobleme in Bezug auf die "Lücke" zwischen dem Block und den Tools auf Dokumentebene gibt, und dass es auf Blockebene möglich ist, die Navigation zu vereinfachen.

Dies ist mehr eine Überlegung als alles andere. Etwas an diesem Tool unterscheidet sich erheblich von den anderen in der Symbolleiste verfügbaren Tools, da es den Block mit anderen Kontexten in Beziehung setzt.

Dies ist mehr eine Überlegung als alles andere. Etwas an diesem Tool unterscheidet sich erheblich von den anderen in der Symbolleiste verfügbaren Tools, da es den Block mit anderen Kontexten in Beziehung setzt.

Ja, ich habe das gleiche Gefühl.

Wir haben dieses Steuerelement jetzt in der oberen Symbolleiste, die zu weit vom Block selbst entfernt zu sein scheint. Vielleicht ist die Seitenleiste tatsächlich der beste Ort dafür? Das Steuerelement scheint fast so, als ob es dem Block zugeordnet werden sollte, aber als eigene separate Symbolleiste, aber wir möchten definitiv keine weitere hinzufügen. 😄

Wir haben dieses Steuerelement jetzt in der oberen Symbolleiste, die zu weit vom Block selbst entfernt zu sein scheint.

Ich möchte auch hinzufügen, dass dies nur in den Standardeinstellungen von Gutenberg gilt. Wenn jemand die Option Top Toolbar auswählt, um alle Block-Symbolleisten in die Top-Symbolleiste zu verschieben, ist dies definitiv nicht der Fall. Trotzdem bezweifle ich, dass die Mehrheit der Benutzer diese Einstellung ändert.

In einem weiteren Punkt würde ich wirklich gerne sehen, wie die Leute auf die Standardeinstellung der Symbolleiste als Standardeinstellung in Gutenberg reagieren würden. Es würde besser mit dem Classic-Editor übereinstimmen und neuen Gutenberg-Benutzern mehr Vertrautheit bieten.

Diese Symbolleisteneinstellung wurde vielfach untersucht und die beste Standardeinstellung wurde nach einigem Testen festgelegt. Weitere Informationen zu Erkundungen finden Sie hier: https://github.com/WordPress/gutenberg/issues/2983.

Ich bezweifle, dass die Mehrheit der Benutzer diese Einstellung ändert.

Es stellt sich heraus, dass die Position einer Symbolleiste eine unglaublich persönliche Einstellung ist. Während der ersten Testphase kam es darauf an, dass diejenigen, die anfingen, WordPress zu verwenden, vom Block bevorzugt wurden, diejenigen, die Erfahrung damit hatten. Die Symbolleiste ist an beiden Stellen voreingestellt, und dies sind die besten Optionen. Dies ist wahrscheinlich auch der Grund, warum es sich eher auf den klassischen Editor ausgerichtet anfühlt. Ich würde persönlich empfehlen, die Standardeinstellung nicht zu ändern.

@jasmussen Sollten wir dies zugunsten von # 17088 schließen

Ja, ich denke wir können. Dieses Ticket wurde unterschiedlich untersucht, während das andere nun einige der Ideen verfeinert. Dieses Ticket ist weiterhin auffindbar, wenn Sie der Referenz auf dem neuen Ticket folgen. Thanks Riad.