UX-Probleme mit dem neuen Block-Editor (Gutenberg)

Mit WordPress 5 kam ein neuer blockbasierter Editor in das WordPress-Backend. Auf dem WordCamp Osnabrück habe ich berichtet, welche Probleme in der Usability dabei noch existieren.

Transcript

1. UX-Probleme mit dem neuen Block-Editor (Gutenberg) WordCamp Osnabrück 2019 Torsten Landsiedel @zodiac1978
2. Spalten in Spalten - BOOM!
4. Gefixt in Gutenberg 5.2 (kommt dann mit WordPress 5.2)
5. Abstandshalter reagiert nicht?
6. • Mindestwert 20 • 10er-Schritte Abstandshalter
7. WordPress Workflow Weirdness
8. File-Block einbauen, Datei auswählen, URL kopieren, File-Block löschen - Really? Workflow für einen PDF-Link
9. Block-Editor Classic-Editor Workflow für einen Mailto-Link
10. Kaputter Block - was nun?
11. Kaputter Block Egal was ich mache oder klicke ...
12. Kaputter Block … es endet in jedem Fall in Plain HTML.
13. Wo zur Hölle ist noch mal ...
14. Konsistenz im UI? Warum kann man fast alle Elemente in der Toolbar zentrieren, aber Überschriften in der Sidebar?
15. Ansicht anpassen Custom Fields aktivieren? Überflüssiges ausblenden? Optionen – Voilá!
16. Wo ist der Anfasser? Usability-Aufgabe: Nimm einen Block in einem Mehr-Spalten-Design und ziehe ihn an einen anderen Ort. Jedes Mal wieder scheitere ich daran den “Anfasser” zu finden ...
17. Page Builder? Davor haben mich meine Eltern doch immer gewarnt ...
18. Lock-in Effekt + Performance-Problem Installiert man sich mehrere Block-Plugins (oder Sammlungen) ist es sehr schwierig davon wieder wegzukommen. Benötigt man einen Block, den diese Sammlung nicht hat, installiert man die nächste … Es fehlt ein globales An- und Ausschalten aller Blocks, um diesen Effekt abzufedern. Eine Portabilität zwischen Blöcken wird es wohl nur bei bestimmten Core-Blöcken geben. Richtig praktisch wäre eine Migrationsmöglichkeit zu anderen Block-Sammlungen.
19. Umlauterer Wettbewerb
20. Normalisieren zu NFC Insbesondere am Mac ein Problem von “unechten” Sonderzeichen, wo das Zeichen (z.B. “ä”) aus zwei Zeichen kombiniert wird (a + ̈) und so Rechtschreibprüfung, Suche, Transliteration, etc. kaputt macht. Wird in Gutenberg beim Einfügen repariert, aber nur bei modernen Browsern, die das unterstützen und nur im Inhaltsbereich.
21. HTML-Ansicht beim Block-Editor?
22. Gibt es die überhaupt noch? Per Seite/Beitrag Code Editor Am Block Edit as HTML
23. “Disable visual editor when writing”
24. Disable visual editor when writing
25. Disable visual editor when writing
26. Disable visual editor when writing Ich sehe keinen sinnvollen Anwendungsfall mehr für diese Checkbox in der Gutenberg-Zeit. Ist Gutenberg noch nie aktiv gewesen, startet man mit einem Classic-Block ohne Möglichkeit in Blöcke zu konvertieren und ohne jegliche Styling-Möglichkeit (keine Toolbar). Ist Gutenberg schon länger aktiv, dann landet man nicht in der “Edit as HTML”-Ansicht der Blöcke, die das Anbieten, sondern Gutenberg wird komplett in den Quelltext-Modus gesetzt. Inklusive dem Kommentar-Markup zur Steuerung der Blöcke. Mit hohem Risiko bei Änderungen alles kaputt zu machen.
27. Quo vadis WordPress-Suche?
28. Interne Suche von WordPress korrumpiert Gutenberg speichert alle Blöcke mit HTML-Kommentaren im post content ab. Dadurch werden Suchen nach “paragraph” oder “image” ziemlich nutzlos, da sie für fast jede Seite/jeden Beitrag nun ein Ergebnis liefern. Das Problem existiert eigentlich schon immer, aber bei HTML-Befehlen ist das Problem nicht so schlimm (paragraph -> p, image -> img). Und es kommen immer mehr Blöcke dazu, das Problem nimmt also zu.
29. Kommentare im “post content”
30. Vielen Dank für eure Aufmerksamkeit! Frage? Anmerkungen? Kritik? Eigene Erfahrungen?