Neuerungen in WoltLab Suite 6.0: CKEditor 5

Was ist ein WYSIWYG-Editor?

Ein „What You See Is What You Get“-Editor (kurz: „WYSIWYG-Editor“) hat das Ziel, eine möglichst detailgetreue Repräsentation des fertigen Textes bereits beim Verfassen bzw. Bearbeiten zu ermöglichen. Die visuelle Umsetzung von Textformatierungen, Listen oder Tabellen ermöglicht einen komfortablen Umgang ohne sich mit der technischen Funktionsweise herumschlagen zu müssen. Das Konzept ist von Mail-Programmen oder Textverarbeitungen bereits bekannt und leistet dort bereits seit Jahrzehnten wertvolle Dienste.

Warum haben wir uns für CKEditor 5 entschieden?

Der bisher verwendete Editor „Redactor II“ wird seit einiger Zeit nicht mehr weiterentwickelt und besitzt einige Schwächen, die sich im Rahmen unserer Möglichkeiten nur unzureichend beseitigen lassen. Ein großer Kritikpunkt liegt in der technischen Implementierung, die für die Umsetzung von Funktionen direkt auf der Browser-eigenen „contenteditable“-Schnittstelle aufbaut, die jedoch allgemein als sehr unzuverlässig und fehlerhaft gilt. Nutzer früherer Versionen kamen bereits mit CKEditor 4 in Kontakt, der ähnliche Probleme wie „Redactor II“ aufwies.

Die aktuelle Version 5 von CKEditor stellt eine vollständige konzeptuelle und technische Neuentwicklung dar. Mit CKEditor 5 wurde ein WYSIWYG-Editor geschaffen, der plattformunabhängig eine stabile und zuverlässige Erstellung und Bearbeitung von (umfangreichen) Texten erlaubt. Die Nutzung der unzuverlässigen „contenteditable“-Schnittstelle wird hierbei nur für das Nötigste verwendet: Die Entgegennahme von Texteingaben sowie die Darstellung des Endergebnisses. Dieser fast schon revolutionäre Ansatz gipfelt mit CKEditor 5 in einem äußerst zuverlässigen Editor, der zudem eine Vielzahl sinnvoller und hilfreicher Funktionen aufweist.

Absätze und Textformatierungen

Ein neuer Editor bedeutet für uns nicht nur sehr viel Arbeit bei der Integration, sondern gibt uns auch die Möglichkeit, bestehende Praktiken auf den Prüfstand zu stellen und neu zu überdenken. Manche Entscheidungen wurden in der Vergangenheit aus reiner Gewohnheit oder als technischer Kompromiss getroffen, obwohl diese nicht immer ideal waren. Mit dem Wechsel auf CKEditor 5 haben wir einige Verbesserungen vorgenommen, die für manche Nutzer ungewohnt sein können und deren Beweggründe wir an dieser Stelle erläutern möchten.

Neues Feature: Textmarker

Wichtige Aspekte in einem Text werden oftmals mit in Fettdruck oder mit kursiver Schrift ausgezeichnet, um diese gesondert hervorzuheben. Darüber hinaus gibt es Situationen, in denen die Relevanz oder Dringlichkeit eines bestimmten Aspekts stärker hervorgehoben werden soll. Üblicherweise wird hierbei auf Textfarben zurückgegriffen, die aber je nach Farbschema des Stils nur bedingt geeignet sind und bei der Nutzung mehrerer Stile teilweise auf Grund eines mangelnden Kontrasts unleserlich werden.

Die Textmarker stehen in vier verschiedenen Farben zur Verfügung und basieren auf dem Farbschema der Hinweise. Dies ermöglicht eine angepasste Darstellung abhängig vom verwendeten Stils, beispielsweise helle Farben in einem hellen Stil und umgekehrt abgedunkelte Farben bei der Verwendung eines dunklen Farbschemas. Textmarker werden semantisch über das HTML-Element <mark> abgebildet und verbessern damit sowohl die Barrierefreiheit als auch die Erkennung wichtiger Inhalte durch Suchmaschinen.

Echte Absätze

Das Verhalten der Eingabetaste ist vielerorts uneinheitlich: Manchmal erzeugt diese einen einfachen Zeilenumbruch und manchmal entsteht beim Tastendruck ein neuer Absatz. Bei der Verwendung des bisherigen Editors wird bei der Betätigung der Eingabetaste ein neuer Absatz erzeugt, dieser jedoch optisch als reiner Zeilenumbruch dargestellt. Diese Entscheidung ist zu Teilen auch aus technischen Beweggründen in Kombination mit dem alten Editor entstanden, sorgt aber für nachhaltig Probleme bei der Barrierefreiheit und der Interaktion mit anderen Seiten und Programmen beim Kopieren beziehungsweise Einfügen von Texten.

Mit dem Wechsel auf CKEditor 5 beenden wir diese Zweckentfremdung von Absätzen und verbessern die Semantik der erstellten Texte nachhaltig. Absätze werden zukünftig als tatsächliche Absätze dargestellt und verhalten sich so, wie Nutzer es beispielsweise von Textverarbeitungsprogrammen gewohnt sind. Über Shift + Eingabetaste lassen sich auch weiterhin explizite Zeilenumbrüche erzeugen, beispielsweise für die Darstellung von Anschriften. Die korrekte Verwendung von Absätzen verbessert die Interaktion mit anderen Websites und Programmen enorm, Texte werden beim Kopieren und Einfügen üblicherweise korrekt übernommen und erfordern keine Korrekturen der Zeilenumbrüche bzw. Absätze mehr.

Bestehende Texte werden dynamisch korrigiert, damit keine unerwarteten Leerräume zwischen Absätzen entstehen. Diese Kompatibilitätsschicht ermöglicht es, bestehende Texte und Programmlogiken unverändert anwenden zu können und dennoch ein korrektes Endergebnis zu produzieren.

Schriftart, -farbe und -größe in Texten

Im Editor ist es teilweise möglich, die verwendete Schriftart von Texten anzupassen und auch Änderungen der Schriftfarbe oder Schriftgröße sind möglich. Der Nutzen dieser Funktionen ist auf einige wenige Randfälle beschränkt, bieten aber umgekehrt ein enormes Potential für einen ungewollten Fehlgebrauch. Das Spektrum der Fehlnutzungen ist sehr vielfältig und reicht von kaum wahrnehmbaren Abweichungen bis hin zu tatsächlichen Problemen beim Lesen von Texten, nicht zuletzt auch Probleme bei der Verarbeitung durch Suchmaschinen.

Mit WoltLab Suite 6.0 werden drei neue Optionen eingefügt, die Einfluss auf die Verwendung von Schriftart, -farbe und -größe nehmen. Mittels dieser Optionen kann selektiv die Verwendung dieser Textformatierungen bei der Erstellung von Texten verhindert werden. Zusätzlich werden diese Formatierungen bei der Darstellung der Texte entfernt, damit bereits bestehende Vorkommnisse keine Auswirkungen mehr haben.

Diese drei neuen Optionen führen zu keinen Veränderungen bestehender Texte, so werden beispielsweise unterdrückte Textformatierungen bei der Deaktivierung der jeweiligen Option direkt wieder sichtbar. Im Folgenden möchten wir auf die gravierenden Probleme dieser Art von Textformatierungen eingehen und es Betreibern ermöglichen, die Konsequenzen beim Nicht-Einsatz dieser Optionen nachzuvollziehen.

Ungewollte Übernahme von Formatierungen beim Einfügen

Eine typische Quelle für geänderte Schriftarten, -farben oder -größen ist das Einfügen von Texten aus anderen Quellen. Die Übernahme von Elementen wie beispielsweise Listen oder dem Fettdruck von Textteilen ist sehr vorteilhaft, aber nicht selten werden dabei auch unerwünschte Änderungen mit übernommen. Typisch ist hierbei beispielsweise eine schwarze Schriftfarbe (der Standardstil verwendet einen sehr dunklen Grauton) und eine ähnlich aussehende Schriftart, die dem Verfasser des Textes nicht einmal auffällt.

Probleme und Abweichungen bei geänderten Stilen und Farbschemas

Ansprüche und Vorlieben für das Aussehen einer Website können sich über die Zeit ändern, beispielsweise die Verwendung einer anderen Schriftart oder die Anpassung der verwendeten Farbtöne. Die in Texten fest hinterlegte Schriftart und -farbe passt sich an diese Änderungen jedoch nicht an, mit dem Resultat das einige Text ganz oder teilweise aus dem einheitlichen Erscheinungsbild ausscheren.

Eine leicht andere Schriftart ist oftmals zwar unschön, aber nicht unbedingt problematisch. Viel gravierender sind feste Farbwerte, beispielsweise bei der Verwendung eines deutlich anderen Farbschemas, etwa einem dunklen Farbmodus statt einer bisherigen hellen Farbpalette. Texte werden in dieser Konstellation schlecht bis gar nicht mehr lesbar und im Falle von fast deckungsgleichen Schrift- und Hintergrundfarben kann dies sogar als Manipulationsversuch durch Suchmaschinen gewertet werden.

Auch ohne stark abweichende Farbschemas können individuell vergebene Schriftfarben ein Problem darstellen. Manche Nutzer nutzen sehr blasse Farbtöne dazu, Texte vorsätzlich nur sehr schwach darzustellen, verursachen dadurch aber so schwache Kontraste, dass Leser mit eingeschränktem Sehvermögen diese gar nicht mehr wahrnehmen können. Die Lesbarkeit eines Textes ergibt sich aber nicht nur durch ausreichend Kontrast sondern auch durch die Vermeidung von Farbkombinationen, die für einige Leser nicht unterscheidbar sind. Ein gerne bemühtes Beispiel ist die mangelnde Unterscheidbarkeit von roten und grünen Farbtönen bei einer Rot-Grün-Sehschwäche, die es in dieser Form auch für andere Farbkombinationen gibt.

(Gut gemeinte) Änderungen von Schriftgrößen

Vielfach kaum bemerkt stellen geänderte Schriftgrößen in Texten ein mindestens genauso folgenschweres Problem dar, sind aber oftmals nur schwer als solche zu erkennen. Abseits der unabsichtlichen Nutzung anderer Schriftgrößen durch das Einfügen von Texten aus gibt es eine ganze Reihe an Beweggründen für die Nutzung abweichender Schriftgrößen.

Ein prominentes Beispiel ist das Verfassen von Texten in größerer Schrift auf Grund einer signifikanten eigenen Sehschwäche. Statt die bestehenden Möglichkeiten des Betriebssystems und Browsers zu Verbesserung der Lesbarkeit von Texten zu nutzen, werden die eigenen Texte abweichend von allen anderen in größerer Schrift verfasst. Für den Ersteller ist dies durchaus bequem, sorgt aber für eine uneinheitliche Größe von Texten und löst genauso wenig das Problem, dass die Texte anderer Teilnehmer für den Verfasser „zu klein“ sind.

Andere Verfasser verwenden höhere Schriftgrößen zur Auszeichnung von Überschriften, anstatt hierbei auf die bereits bestehenden Möglichkeiten zum Setzen von Überschriften zurückzugreifen. Auf den ersten Blick sind solche Abweichungen oftmals kaum zu erkennen, aber dies hat signifikante Folgen für die Struktur von Texten. Bei der Verwendung „echter“ Überschriften wird eine Struktur erzeugt, die sowohl von Suchmaschinen als auch einem „Screen-Reader“ verstanden und umgesetzt werden.

Kommentare 16

ich empfinde die Formatierung der Absätze störend und es wäre schön die manuell ändern, zu können. Ich habe User deren Signatur ewig lang gezogen werden und so das ganze Lesebild zerstören.

Beispiel Zitat:

Den Alltag hinter sich lassen

und doch Zuhause sein!

Auf alles überflüssige verzichten

und doch Nichts vermissen!

Das Fremde kennenlernen

und doch vertraut fühlen!

Jederzeit weiterziehen können

und doch sein Nest nicht verlassen!

Das ist CAMPING!

Damit wird manche Signatur länger als viele Beiträge selber, bitte überdenkt mal, ob und wie sich das anders umsetzen lässt. Danke!

Mit Shift + Enter lässt sich ein Zeilenumbruch erzeugen.

Super ich bin gespannt! Hatte schon eine Funktion zum Löschen der Formatierungen im Texteditor vermisst. :love:

Das sieht schon ziemlich interessant aus. Gerade mal mit Tabellen getestet und das funktioniert echt um ein Vielfaches weniger frickelig, als mit dem alten Redactor. Insbesondere CMS Artikel und Blogs mit komplexeren Textaufbauten, sollte sich viel angenehmer formatieren und bearbeiten lassen.

Lediglich das Verstecken vieler Funktionen in Untermenüs finde ich nicht gelungen. In einem einfachen Kommentarfeld ist das noch okay, aber beim Erstellen von Artikeln oder umfangreicheren Forenbeiträgen sind viele Klicks notwendig, obwohl doch Platz da wäre… Da erschließt sich mir noch keinen Nutzen. Ja, der arme Nutzer soll nicht überfordert werden, das ist mittlerweile eine Art Mantra im UX-Design geworden. Manchmal geht mir das viel zu weit. Ein wenig darf man den Nutzern auch mal zumuten, finde ich. Wer mal Word oder so aufmacht, fängt doch auch nicht an, in Panik zu verfallen, wegen der vielen Schaltflächen und Buttons. Und gutes UX sollte ja alle mitnehmen, also auch die Power-User. Also vielleicht einfach eine Option, die ein Nutzer anhaken kann und schon wandern alle Icons in die Leiste heraus aus den Untermenüs?

Und noch eine andere Frage: Wird es den CKEditor auch im WoltLab Suite Core zur Verwendung geben oder muss man ein kommerzielles Paket dafür erwerben? Der CKEditor selbst ist ja auch rein kommerziell, oder?

Die Editorleiste wird mit der Beta 1 nochmals überarbeitet, im Detail habe ich es in RE: Editor-Buttons konfigurierbar machen oder mehr Funktionen auf die erste Ebene bringen beschrieben.

Zur Verfügbarkeit des Editors: Wir haben eine passende Lizenzvereinbarung mit CKSource, die es uns gestattet, den Editor auch im Core anzubieten.

Hoffentlich wird auch die Mobile Version, richtig angepasst. Manchmal ist es mega mühsam oder umständlich gemacht.

Bezieht sich das schon auf den neuen Editor, der hier im Forum bereits online ist? Wenn ja, was passt konkret mobile nicht? Idealerweise bitte im Forum als Fehler melden.

Die Frage was sich mir nur stellt, ist ob es nur die Funktionen die jetzt im Editor verfügbar sind gibt oder ob auch das einstellen von Schriftart und Größe und Farbe wieder dazukommt ?

Die Buttons zur Festlegung von Schriftart, -farbe und -größe existieren auch weiterhin. Betreiber haben aber weiterhin für ihre eigene Seite die freie Wahl, wir werden diese Optionen lediglich auf unserer Seite nicht mehr anbieten.

Ich bin schon sehr gespannt, wie sich der neue Editor in der Praxis macht!

Eine für mich sehr wichtige Frage stellt sich aber: Buttons für Code und Inline-Code sind in den Screenshots nicht zu sehen und befinden sich wahrscheinlich hinter dem Symbol mit den drei Punkten oder dem Plus. Welche Möglichkeiten werde ich als Betreiber haben, diese Funktionen auf die erste Ebene zu holen? Denn bei mir werden diese Funktion sehr viel gebraucht - de facto macht das Teilen und Verändern von Code in einem meiner Foren den Großteil der täglichen Aktivität aus. Dafür jedes Mal einen Klick mehr zu benötigen, wäre eine so erhebliche Erschwerung der täglichen Abläufe, dass ich das als Blocker für die Umstellung auf die WoltLab Suite 6.0 betrachten muss. Wird das über die Konfiguration der BBCodes oder auf eine andere Weise anpassbar sein?

Das anpassen, wäre wirklich eine gute Ergänzung.

Das mit den Menüs ist mir beim Testen negativ aufgefallen, die sind super nervig. Und mache Menüs haben noch weitere Untermenüs 😳 Verstehe nicht warum man hier nicht mehr Platz nutzt, der ist doch da.

Die Anpassbarkeit der Editor-Toolbar ist grundsätzlich eine interessante Idee, eventuell findet sich hierzu noch eine sinnvolle Lösung, wie man dies (in gewissen Grenzen) ermöglichen kann. Wir sehen die anstehende Testphase auf woltlab.com auch als Möglichkeit, Erfahrungen zu sammeln, die in so ein Konzept einfließen können.

Den gesamten verfügbaren Platz mit Icons zu befüllen ist nicht unbedingt ideal. Die Aussagekraft von Icons ist begrenzt und erzeugt damit eine hohe kognitive Last, wenn diese umfangreich genutzt werden. Erfahrungsgemäß haben Nutzer bei zu vielen Icons das Probleme, dass die gewünschte Funktion nicht zügig gefunden werden kann.

Untermenüs erlauben eine logische Gruppierung und begrenzen damit die Menge an Icons/Funktionen die zu jedem Zeitpunkt zur Auswahl stehen. Man kann sich das ein bisschen wie eine Bibliothek vorstellen, bei dem auch nicht alle Bücher auf einem einzigen langen Regal stehen, sondern systematisch in Teilbereiche organisiert werden. Ob es sich im Falle des Editors tatsächlich bewährt, wird sich zeigen müssen – auch wenn es erst einmal ungewohnt ist.

Ich verstehe den Ansatz durchaus. Und die Code-Funktionen sind sicherlich nicht für alle Foren so relevant, womit sich diese für ein Untermenü anbieten. Mir ist das auch hier auf woltlab.com nicht so wichtig (wobei es mich auch hier keinesfalls stören würde, wenn es weiterhin permanent sichtbar wäre - so viele Buttons hat der Editor jetzt ja auch nicht). In meinem Forum geht es aber halt tatsächlich nicht darum, dass es ungewohnt sein wird, dort ist es eine der wichtigsten Editor-Funktionen und noch wichtiger als fette und kursive Schrift. Dort muss das daher unbedingt so leicht wie bisher zugänglich bleiben.

Ich bin so gespannt und danke euch für die viele Mühe <3