Das Customization-Team hat sich Gedanken dazu gemacht, welche Probleme in diesem Jahr angegangen werden können – sowohl kleinere Probleme für die ersten paar Monate, als auch größere Projekte für den Rest des Jahres. Außerdem wurden Punkte festgehalten, die Ende 2017 möglich sein sollen.
Accessibility
Verschiedenes
Core
Voraussetzungen für den neuen Editor
Matías Ventura hat in seinem Beitrag »Editor Technical Overview« festgehalten, welche Aspekte bei der Umsetzung des neuen Editors beachtet und eingehalten werden sollten. Dabei nennt er als ersten Punkt, dass der komplette Inhalt aus den Blöcken in post_content
bleiben muss – in einer zugänglichen und portablen Form, während noch zusätzliche HTML-Struktur für die Identifizierung der Blöcke eingefügt wird. Diese zusätzliche Struktur sollte bestenfalls unsichtbar sein, damit die korrekte Darstellung in Bereichen sichergestellt ist, die nichts von den Blöcken wissen (zum Beispiel in Feeds oder in alten Editor-Versionen).
Sein zweiter Punkt ist die Einfachheit und Semantik der Repräsentation. Dabei geht es ihm darum, dass das zusätzliche Markup für die Identifizierung der Blöcke so klein wie möglich sein sollte, da WordPress bisher ein »Champion der Webstandards« ist und es auch bleiben soll. Als dritten Punkt nennt er statische und dynamische Blöcke. Die häufigsten werden mit Text und Bildern vermutlich statische sein, dynamische sind beispielsweise Shortcodes oder Widgets.
Seine vierte Anforderung ist eine konsistente Nutzererfahrung. Fünfter und letzter Punkt ist das System. Hier gibt es drei verschiedene Aspekte: Das User-Interface zur Bearbeitung eines Blocks, die Abgrenzung des Blocks im Markup und die Ausgabe eines Blocks. Für diese drei Punkte muss jeweils die beste Lösung in puncto Design und technische Umsetzung gefunden werden.
Abschließend schlägt Matías vor, sich zunächst auf einige statische Blöcke wie Text, Bilder mit und ohne Beschriftung sowie Zitate zu beschränken. Als eine Möglichkeit zur Block-Trennung im Markup führt er HTML-Kommentare an, was dann so aussehen könnte (aus dem Beitrag von Matías kopiert):
<!-- wp:image -->
<figure>
<img src="/">
<figcaption>A picture is worth a thousand words</figcaption>
</figure>
<!-- /wp -->
Code-Sprache: HTML, XML (xml)
Editor-Meeting vom 19. Januar
Im Meeting ging es hauptsächlich darum, wie die Blöcke voneinander abgegrenzt werden können. Zu einer finalen Entscheidung ist das Team hier nicht gekommen, es gab verschiedene Ansätze:
- HTML-Kommentare.
data-
-Attribute.- Eigene HTML-Elemente oder Wrapper aus
div
s oder Ähnlichem.
Ein weiteres Thema waren Blöcke innerhalb von anderen Blöcken, um beispielsweise mehrspaltige Inhalte zu ermöglichen. Dass eine Möglichkeit zur Verschachtelung vielleicht mal wünschenswert ist, soll im Hinterkopf behalten werden.
Customization in 2017
In ihrem Beitrag »Customization in 2017« hat Mel Choyce einen groben Plan für das Customization-Team aufgeschrieben. Zunächst betont sie, dass Customization nicht nur die Verbesserung des Customizers meint, sondern den gesamten Prozess des Aufsetzens einer Site – von der Installation bis zur Bearbeitung an einer existierenden Site. Dabei gibt es die beiden folgenden Ziele:
- »Ich möchte eine Site erstellen, auf die ich stolz bin und die mir hilft, erfolgreich zu sein.«
- »Ich möchte eine Site erstellen, auf die meine Kunden stolz sind und die ihnen hilft, erfolgreich zu sein.«
Dafür hat sie einige Aufgaben aufgelistet, die innerhalb der ersten paar Monate erreicht werden könnten. Einige davon sind beispielsweise Demo-Inhalte beim Wechseln eines Themes auf einer bestehenden Website (#38624), verloren gegangene Widgets und Menüs beim Wechseln eines Themes, ein Media-Widget (#32417) und Formatierungsmöglichkeiten für das Text-Widget (#35243). Größere Projekte für den Rest des Jahres sind:
- Content-Blöcke.
- Revisionen für visuelle Änderungen (#31089 und #21666).
- Entwurf, Planen und Reviewen von Änderungen, damit die Site genau richtig aussieht, bevor die Änderungen live geschaltet werden (#31089 und #28721).
Ende 2017 sollen folgende Punkte möglich sein:
- Eine Onboarding-Erfahrung mit smarten Standards, die es schneller ermöglicht, die gewünschte Site zu erstellen.
- Komplexe und dynamische Layouts bauen, unabhängig vom Theme.
- Jedes Stück Inhalt auf der Site per Drag-&-Drop an eine andere Stelle ziehen.
- Vor der Erstellung einer Seite die möglichen Seiten-Layouts anschauen und auswählen.
- Jeden Inhalt da bearbeiten, wo man ihn sieht.
- Eine grundlegende Site erstellen, ohne zwischen verschiedenen Admin-Screens wechseln zu müssen.
- Live-Vorschau für alle Änderungen, die das Aussehen der Site beeinflussen.
- Änderungen rückgängig machen und Revisions-Historie anschauen.
- Vielleicht sogar die komplette Site von einem Smartphone aus bauen?
Oder, etwas kürzer:
Mehr Infos zu den Plänen findet ihr im Beitrag von Mel.
Verschiedenes
Design
Verschiedenes
Polyglots
Verschiedenes
- Notizen zum Polyglots-Meeting vom 18. Januar. Unter anderem wurde vorgeschlagen, die Rosetta-Sites der lokalen Communitys durchzugucken und inaktive Teams auf den Nutzen der Sites aufmerksam zu machen (um beispielsweise Events anzukündigen).
Docs
Neues »Theme Developer Handbook« ist live
Am 18. Januar wurde das neue Theme Developer Handbook veröffentlicht. Damit wird das Ziel erreicht, auf dem Developer-Hub Entwickler-Ressourcen für jeden Hauptaspekt von WordPress zu haben. Bei Trello wird die weitergehende Verbesserung des Handbuchs organisiert. Mehr dazu findet ihr im Beitrag »Theme Developer Handbook released« von Jon Ang.
Theme-Review-Team
Meeting vom 17. Januar
Das Theme-Review-Team hat im Meeting dafür gestimmt, dass Reviewer automatisch von einem Ticket entfernt werden, wenn sie zwei Tage nach der Zuweisung keinen Kommentar im Ticket geschrieben haben. Daneben gibt es einige, die das Mentoren-Programm wieder einführen möchten – hierfür müssten aber genug erfahrenen Reviewer gefunden werden, die als Mentoren arbeiten möchten.
Ein weiterer Diskussionspunkt war eine Prioritäts-Queue für Themes von Autoren, deren letztes Theme weniger als fünf Probleme hatte. Dadurch könnte auch ein Anreiz geschaffen werden, sich vor dem Upload mehr darum zu bemühen, dass ein Theme möglichst wenige Probleme aufweist. Mehr zum Meeting des Theme-Review-Teams gibts in den Notizen von Justin Tadlock.
Meta
Handbuch-Redesign
Mark Uraine hat sich ein paar Gedanken dazu gemacht, wie die Übertragung der Handbücher auf das O2-Theme weitergehen könnte. Dabei hat er sich aktuell die beiden floatenden Menüs vorgenommen, die auf Handbuchseiten erscheinen – links eine Navigation für das gesamte Handbuch, rechts ein Inhaltsverzeichnis des Beitrags.
Einen Screenshot seiner Gedanken dazu findet ihr in seinem Beitrag »Handbook Redesign«.