Mitte 2018 überlegte Sports.ru, auf einen neuen WYSIWYG- Texteditor für Benutzerbeiträge umzusteigen . Seit Juni 2019 befindet sich der Editor im Beta-Modus. In dieser Zeit haben wir viele Probleme gelöst, die sowohl mit dem Design der Architektur des gesamten Dienstes als auch mit der Implementierung des Editors selbst im Browser auf der Grundlage der ProseMirror- Bibliothek verbunden waren , und beschlossen, unsere Erfahrungen zu teilen.

Inhaltsverzeichnis

1. Einleitung
1.1. Warum brauchten Sie WYSIWYG
1.2 ? Beschreibung der Aufgabe, mit der die Entwickler konfrontiert waren
2. Auswahl des Tools
3. Was ist passiert?
3.1. Servicearchitektur
3.2. Was sind die Herausforderungen?
4. Beta-Testergebnisse

1. Einleitung

1.1. Warum brauchten Sie WYSIWYG?

Sports.ru ist ein Sportmedium mit einem Publikum von 20 Millionen Nutzern pro Monat. Unsere Hauptunterschiede zu klassischen Medien sind die Community und UGC . Benutzerinhalte - Bewertungen, Kommentare, Chats, Beiträge - ergänzen nicht nur den redaktionellen Wert, sondern schaffen auch eine Plattform, auf der Benutzer miteinander interagieren können. Jeden Monat schreiben unsere Benutzer fast 10.000 Beiträge. Die besten von ihnen werden zusammen mit den redaktionellen Seiten auf der Hauptseite der Website eingereicht und an mobile Anwendungen und soziale Netzwerke gesendet. Benutzerinhalte machen etwa 40% aller Lesevorgänge auf Sports.ru-Seiten aus.

Wir möchten die bequemste Plattform für Sportautoren sein, um Inhalte zu erstellen und sie einem interessierten Publikum zugänglich zu machen. 10 Jahre haben wir den TinyMCE- Editor verwendet- und am Ende war es veraltet und passte nicht mehr sowohl zum Team als auch zu den Benutzern, die an moderne Redakteure gewöhnt waren.

Feige. 1. Die Oberfläche des alten Editors basierend auf TinyMCE

Von den Autoren von Blogs erhalten regelmäßig folgende Beschwerden:

Ich schrieb lange, schloss dann versehentlich den Tab und alles war weg;
lange Texte zu schreiben ist sehr unpraktisch;
Es ist ärgerlich, dass Sie zum Einfügen jedes Bildes es zuerst auf das Bildhosting hochladen müssen.

Das Team hatte auch seine eigenen Beschwerden:

In TinyMCE können Sie keine Bilder direkt aus einer Datei hochladen. Sie können nur Links zu Bildern anhängen. Aufgrund der Tatsache, dass Benutzer keine Bilder in unseren Speicher hochladen konnten, konnten wir nichts dagegen tun, wenn Links zu ihnen starben.
Die Möglichkeiten zum Bearbeiten und Formatieren des Textes sind nicht ausgewogen. Einerseits gab es nicht genügend Stile, zum Beispiel für interne Überschriften im Text. Andererseits war es möglich, die verfügbaren Werkzeuge in beliebiger Kombination zu verwenden. Infolgedessen sahen die Beiträge nicht einheitlich aus (bei Sports.ru begannen die Arbeiten zur Implementierung des Design-Systems, und Benutzerbeiträge sollten entsprechend aussehen).
Inhalte werden in HTML erstellt und gespeichert. Daher ist es schwierig, Stile in Posts auf verschiedenen Clients zu verwalten und nur Änderungen am Layout von Posts vorzunehmen.

Als nächstes folgt eine Geschichte darüber, wie wir das Problem der Erstellung eines neuen Editors auf der Front-End-Seite gelöst haben. Es stimmt, es wird auch etwas an den Produkt-, Design- und Backend-Teilen geben, denn ohne dies wird es schwierig sein zu verstehen, warum eine bestimmte Entscheidung am Frontend getroffen wurde.

1.2. Beschreibung der Aufgabe für die Entwickler

Kurz gesagt, die These, auf die wir uns ursprünglich stützten: Bloggen auf Sports.ru ist ein Schmerz. Im Prinzip wäre es möglich, keinen neuen Editor zu erstellen, sondern einfach die automatische Speicherung und die Möglichkeit, Bilder in Ihren eigenen Speicher hochzuladen, hinzuzufügen - und die meisten Beschwerden von Benutzern und Mitarbeitern würden verschwinden. Trotzdem wollte ich das Tool für alte Technologien nicht unterstützen, sondern einen neuen modernen Editor erstellen, den wir einfach entwickeln und skalieren können.

Neben der unbequemen Benutzeroberfläche bestand eines der wichtigsten technischen Probleme des alten Editors darin, dass der Inhalt des Posts sofort als HTML-Zeichenfolge gespeichert wurde und Änderungen im Erscheinungsbild des Posts entweder die Intervention von Backend-Entwicklern erforderten oder zur Laufzeit auf dem Client implementiert wurden (z. B. die Platzierung von Anzeigenblöcken) im Körper der Post). Unsere Aufgabe war es unter anderem, die Daten von ihrer Präsentation zu trennen und dementsprechend das Layout und die Oberfläche im Client-Code zu belassen und mit den Daten im Server-Code zu arbeiten.

Als Vorbild haben wir Medium genommen und manchmal Ideen aus Google Doc ausspioniert . Zusätzlich zur Lösung der bereits identifizierten Probleme haben wir beschlossen, einige neue Funktionen hinzuzufügen, die die Verwendung des Editors komfortabler machen:

WYSIWYG, .. what you see is what you get (. « , », ), , . , ;
( , , , , ; , ) .

Gleichzeitig sollte der Herausgeber selbst nicht an die Funktionen von Sports.ru gebunden sein, da Sports.ru, obwohl das Vorzeigeprojekt in unserem Unternehmen, immer noch nicht das einzige ist. Das Unternehmen entwickelt außerdem die internationalen Sportmedien Tribuna , ein soziales Netzwerk für Wettbegeisterte Betting Insider , und hat kürzlich ein eigenes Produktionsstudio für Werbeprojekte eröffnet. Die Entwicklung eines Online-Editors ist teuer genug, um diesen Code nicht auf einer anderen Site mit anderen Sätzen und Stilen mit eigenen Tools zum Bearbeiten und Formatieren wiederverwenden zu wollen.

Wir haben viel Textinhalt und bevor wir mit der Erstellung eines neuen Post-Editors beginnen, haben wir uns überlegt, wie dieser Inhalt gespeichert werden soll. TinyMCE gab uns keine Wahl und der Inhalt musste nur in HTML gespeichert werden, was, wie oben erwähnt, nicht zum Team passte. Aus diesem Grund haben wir ein eigenes Format zum Speichern von Textdaten entwickelt, das unseren Anforderungen entspricht, und es als strukturierten Körper bezeichnet.

Der strukturierte Körper ist ein Array von Objekten, das die Struktur des Inhalts widerspiegelt. In diesem Fall ist der Inhalt in Elemente unterteilt, die unabhängige Blöcke sind, z. B. Absatz, Liste, Bild. Ein Element speichert Informationen darüber, um welchen Typ es sich handelt und welche Eigenschaften es hat. Beispielsweise beschreibt der Untertitelblock den Titel im Text, er muss den Text und die Ebenenfelder enthalten. Dementsprechend enthält Text den Text dieser Überschrift und Ebene enthält die Ebene (von 1 bis 4). Ein strukturierter Körper, der aus einem Header der zweiten Ebene besteht, könnte beispielsweise so aussehen:

const structuredBody = [
    {
        type: 'subtitle',
        value: {
            text: '    ',
            level: 2,
        },
    },
];

Der Übergang zum strukturierten Körper ermöglichte es uns, den Prozess der Trennung von Geschäftslogik, Daten und deren Präsentation zu beginnen. Letztendlich möchten wir, dass Server und Clients nur Daten austauschen. Und wie und warum diese Daten dem Endbenutzer angezeigt werden sollen, bestimmt jeder Client unabhängig.

Inhalte im Formatd-Body-Format werden in JSON gespeichert. Um den Inhalt zu überprüfen, haben wir ein JSON-Schema namens strukturiertes Body-Schema erstellt. Dieses Diagramm beschreibt alle gültigen Elemente und ihre Eigenschaften. So können wir sicher sein, dass überall dort, wo ein strukturierter Körper benötigt wird, ein Satz von Schlüsseln und Werten verwendet wird.

Darüber hinaus können verschiedene Teams dieselben Dienste verwenden, um Inhalte in diesem Format zu verarbeiten. Zum Beispiel ein Dienst zum Generieren von HTML aus einem strukturierten Körper zum Anzeigen von Inhalten oder ein Editor zum Erstellen von Inhalten. Dies reduziert die Kosten für die Entwicklung und Unterstützung des gesamten Kerns von Diensten im Zusammenhang mit der Erstellung und Anzeige von Inhalten erheblich.

Es wurde angenommen, dass der neue Editor Eingabe- und Ausgabeinhalte ausschließlich im strukturierten Textformat akzeptieren sollte. Und hier war es notwendig, den subtilen Punkt zu berücksichtigen: Da die Beiträge früher sofort in HTML gespeichert wurden, wurde diese HTML-Zeichenfolge aus der Datenbank zur Anzeige an den Client übertragen (im Folgenden verstehen wir unter Client ausschließlich den Browser, sofern nicht anders angegeben). Jetzt möchten wir den Inhalt aller Beiträge im strukturierten Text speichern, aber Clients können nur HTML verarbeiten. Zusammen mit der Aufgabe, zu einem neuen Editor zu wechseln, wird gleichzeitig eine neue Möglichkeit für Kunden implementiert, Beiträge zum Lesen direkt aus dem strukturierten Körper anzuzeigen. Wir haben beschlossen, dass es besser ist, ein Elefantenstückchen zu essen. Daher müssen Sie zuerst TinyMCE vollständig aufgeben und erst dann die Logik übernehmen, Beiträge zum Lesen anzuzeigen. Außerdem,Nicht alle alten Beiträge haben es geschafft, den Inhalt in ein neues Format zu übersetzen. Dies bedeutet, dass diese Beiträge immer nur in HTML gespeichert werden und dass sie auch weiterhin lesen können.

Insgesamt: Ein Teil der Beiträge (alle neuen und alten, die erfolgreich in das neue Format übertragen wurden) wird in zwei Formaten gespeichert - HTML und strukturierter Text - bis die neue Anzeigelogik zum Lesen implementiert ist, und der Rest (die meisten alten und sehr sehr alten) Beiträge) bleiben nur in HTML.

2. So wählen Sie ein Werkzeug aus

Wir mussten die Möglichkeit erkennen, einen Beitrag auf dem Client zu bearbeiten und zu erstellen, wobei die oben genannten Funktionen und Einschränkungen berücksichtigt wurden. Wie immer können Sie eine vorgefertigte Lösung wählen oder eine eigene entwickeln.

Zunächst haben wir untersucht, welche vorgefertigten Bibliotheken zum Erstellen von WYSIWYG-Editoren vorhanden sind und ob sie für uns geeignet sind. Wir haben uns für Slate , Draft.js und ProseMirror entschieden .

Neben der Speicherung von Inhalten in einer Datenstruktur war für uns auch die Möglichkeit, mit Vue oder reinem JS zu arbeiten, von entscheidender Bedeutung, da wir bereits damit begonnen hatten, die Site mit Vue + Vuex auf einen neuen technologischen Stack zu verschieben. Darüber hinaus möchte ich bei Bedarf die Funktionen der fertigen Bibliothek mit Hilfe neuer Module (von Drittanbietern oder selbst geschrieben) erweitern.

Tab. 1. Vergleich der überprüften Bibliotheken mit den wichtigsten Parametern für Sports.ru

Wie Sie der Tabelle entnehmen können, hat ProseMirror unsere Anforderungen vollständig erfüllt. Daher haben wir nicht mehr über die Idee nachgedacht, eine eigene Bibliothek zum Bearbeiten von Textinhalten zu schreiben, sondern diese Bibliothek genauer untersucht. Es gibt immer noch eine ziemlich beliebte Feder , die nicht in unseren Vergleich aufgenommen wurde, nur weil wir sie bei der Auswahl eines Werkzeugs ehrlich vergessen haben. Entsprechend unseren wichtigsten Anforderungen geht es auch vorbei, aber es ist einfach so passiert. Wir haben bereits in einem anderen Artikel darüber gesprochen, was ProseMirror ist und wie man damit arbeitet .

3. Was ist passiert?

3.1. Servicearchitektur

Der Inhaltseditor selbst auf dem Client ist bei weitem nicht alles. Sie müssen den Editor in einem vorhandenen Projekt platzieren, ihn irgendwo auf der Webseite anzeigen und auch die Interaktion mit dem Backend in Betracht ziehen, das Problem lösen, zwei Editoren gleichzeitig zu unterstützen (Sie konnten den alten nicht sofort aufgeben) und den Inhalt in zwei Formaten (HTML und strukturiert) speichern Körper).

Alle diese Aufgaben können in Aufgaben unterteilt werden, die sich auf das Frontend, das Backend und deren Integration beziehen. Wir befassen uns hauptsächlich mit Front-End- und Integrationsproblemen, erwähnen jedoch auch einige wichtige Aspekte der Back-End-Aufgaben.

Frontend-Services für den Editor können in mehrere Ebenen unterteilt werden:

Webseite zum Erstellen und Bearbeiten eines Beitrags;
Vue-app, . , , Vue, -, , , , .., , , ;
WYSIWYG- ProseMirror, Vue. , , ;
SB2HTML – HTML structured body, . , structured body – , . , , , . Sports.ru HTML structured body, - HTML . HTML Node.Js, JS- .

Der Vorgang des Speicherns des Pfostens ist in Abb. 2 dargestellt. 2. Der Inhalt des Beitrags im strukturierten Body-Format und seine Metadaten werden an das Backend übertragen. Das Backend sendet Inhalte an den SB2HTML-Dienst, empfängt fertiges HTML in der Antwort, legt all dies in die Datenbank und teilt dem Client mit, dass der Beitrag erfolgreich gespeichert wurde, oder meldet einen Fehler.

Feige. 2. Schema zum Speichern eines Beitrags beim Erstellen oder Bearbeiten in einem WYSIWYG-Editor

3.2. Welche Schwierigkeiten hatten Sie?

Es gab viele Schwierigkeiten, sie traten ständig und oft in den unerwartetsten Momenten auf.

Wie bereits erwähnt, befindet sich der Inhaltseditor im Formular, mit dem Sie zusätzliche Daten eingeben können, die zum Erstellen eines Beitrags erforderlich sind, z. B. Titel, Anmerkungen usw. Zur Kommentierung sollte es möglich sein, Bilder aus einer Datei und über einen Link aus dem Internet herunterzuladen. Für Inhalte wollen wir aber auch Bilder aus einer Datei laden und darüber hinaus nach den gleichen Regeln referenzieren. Und hier stehen wir vor einem Dilemma: Einerseits wird der Inhalt des Beitrags beim Bearbeiten von der externen Form isoliert und von ProseMirror-Tools bereitgestellt, andererseits möchte ich das DRY- Prinzip beachtenund duplizieren Sie nicht den gleichen Code. Wir haben dies wie folgt gelöst: Wir haben das Laden von Bildern als eine Reihe von Methoden in ein Objekt auf der Vue-Formularebene beschrieben und dieses Objekt als einen der Parameter an den Konstruktor des WYSIWYG-Editors übergeben.

Entitäten, die Inhalte beschreiben - Knoten und Fragment - werden im ProseMirror-Modell definiert. Für eine Transaktion werden jedoch nur Indizes verwendet, um den Zeichenbereich zu bestimmen, auf den diese Transaktion angewendet wird (Indizes werden sowohl ab dem Anfang des Dokuments als auch ab dem Anfang des übergeordneten Knotens gezählt). Die Zeichenindizierung ist eines der zentralen Konzepte von ProseMirror. Beim Bearbeiten und Formatieren von Text ist es jedoch viel bequemer, über Entitäten aus dem ProseMirror-Modell nachzudenken. Aus diesem Grund haben wir für eine komfortable Arbeit mit Inhalten unsere Helfer geschrieben, um die Interaktion mit einem Dokument für Transaktionen zu vereinfachen. Nach dem Beginn unserer Arbeit erschien die Tiptap- Bibliothek , eine Reihe ähnlicher Helfer.

Das nächste Problem war, dass wir bei der Erstellung des Schemas festgestellt haben, dass wir bereits über ein genehmigtes internes Format zum Speichern von Inhalten verfügen - einen strukturierten Körper, der unseren Anforderungen entspricht, und dass ProseMirror den Inhalt in einem eigenen Format in einer Story speichert. Der Wechsel zum ProseMirror-Format war schwierig und unpraktisch. Wir befanden uns in einer Situation, in der Daten in einem Format über die API an den Client gelangen und ein anderes angezeigt werden muss. Eine ähnliche Situation tritt auf, wenn geänderte oder erstellte Inhalte gespeichert werden müssen. Zu diesem Zweck haben wir einen Konverter implementiert, der Formate hin und her konvertiert. Sie haben einen einfachen Test für ihn geschrieben, der den Inhalt eines Beitrags im strukturierten Textformat aufnimmt, ihn in das ProseMirror-Format übersetzt, dann zurück und bereits die Originalversion mit der erhaltenen vergleicht. Es stellte sich schnell und einfach heraus.

Als sich das Dokumentschema änderte und in der Regel komplizierter wurde, wurde klar, dass die geringste Änderung zu Fehlern im Editor führen kann, und ein solcher Test scheint eine sehr schlechte Abdeckung zu ergeben. Infolgedessen musste ich Tests für fast alle Kombinationen von Knoten und Marken mit zwei kleinen Konvertermethoden schreiben. Ohne diese Tests ist es nun unmöglich festzustellen, ob die nächste Änderung in der Schaltung etwas unterbricht oder nicht.

Das nächste Problem hängt wiederum mit der Notwendigkeit der Abwärtskompatibilität alter und neuer Technologien zusammen. Unser WYSIWYG-Editor ist nur in Browsern (Desktop und bald auch Mobile) implementiert. Dementsprechend wird zum Bearbeiten von Inhalten auf dem Client in JSON im formatstrukturierten Text angegeben, das Lesen von Posts in Browsern erfolgt jedoch nur aus HTML. Gleichzeitig haben die meisten mobilen Anwendungen bereits auf die Anzeige von Benutzerbeiträgen direkt aus dem strukturierten Körper umgestellt.

Für mobile Anwendungen musste der Fall angegeben werden, in dem der Client ein Element aus einem strukturierten Körper nicht verarbeiten kann. Wenn beispielsweise dem strukturierten Körper ein neues Element hinzugefügt wird, dessen Anzeige nur in einer neueren Version der Anwendung implementiert ist. Da nicht alle Benutzer ihre Anwendungen gleichzeitig aktualisieren, musste für ältere Versionen ein Plan „B“ angegeben werden: Anstatt HTML aus einem strukturierten Textkörper zu erstellen, fügen Sie ein vorgefertigtes HTML-Fragment für das gewünschte Element ein. Das Vorhandensein von HTML-Fragmenten für jedes Element wurde im strukturierten Körperschema nicht bereitgestellt, da die eigentliche Idee dieser Struktur darin bestand, das Speichern von Daten in HTML zu verweigern. Am Ende kamen wir jedoch zu dem Schluss, dass wir zwei strukturierte Körperschemata benötigen - eines für die Anzeige und eines für die Bearbeitung. Die Unterschiede zwischen den Schemata sinddass der strukturierte Körper zum Bearbeiten nur den Inhalt des Artikels enthält und zur Anzeige einige zusätzliche Elemente hinzugefügt werden. Insbesondere wird ein HTML-Fragment für jedes Element erstellt, wenn ein Beitrag im SB2HTML-Dienst gespeichert und nur dem strukturierten Körper hinzugefügt wird, um den Beitrag anzuzeigen. Darüber hinaus zeigt der strukturierte Körper Werbeflächen im anzuzeigenden Inhalt an.

Wenn wir den Inhalt zur Bearbeitung im Browser öffnen, können wir grundsätzlich nicht auf ein unbekanntes Element stoßen, da alle Beiträge auf dieselbe Weise erstellt und angezeigt werden. Aber sie beschlossen, einen solchen Fall auch für die Zukunft vorauszusehen. Zu diesem Zweck haben wir dem ProseMirror-Schema ein Standard-Stub-Element hinzugefügt. Wir haben dieses Element unsupportedBlock genannt. Der Stub wird anstelle eines nicht unterstützten Elements angezeigt. Wir haben es als graues Rechteck mit Text stilisiert, der besagt, dass dieses Element nicht unterstützt wird und nicht bearbeitet werden kann. Wenn ein Beitrag gespeichert wird, bleibt ein solches Element im strukturierten Körper unverändert. Der Benutzer kann seine Position relativ zu anderen Elementen ändern, aber der interne Inhalt eines unbekannten Elements kann nicht geändert oder bearbeitet werden. Der Benutzer kann jedoch ein solches Element löschen, dann natürlichEs wird nicht im endgültigen Dokument gespeichert.

Alle beschriebenen Probleme standen im Zusammenhang mit den Schwierigkeiten bei der Implementierung des WYSIWYG-Editors. Während es im Beta-Modus existierte, konnten wir den alten Editor auf TinyMCE nicht aufgeben und mussten beide Editoren unterstützen, um die Abwärtskompatibilität zwischen ihnen zu gewährleisten. Sie können beispielsweise einen Beitrag im WYSIWYG-Editor erstellen, speichern, dann in TinyMCE bearbeiten, speichern, in WYSIWYG erneut öffnen usw. Als Ergebnis haben wir beim Öffnen in WYSIWYG den gleichen Inhalt wie beim vorherigen Speichern in TinyMCE gesehen. Um die Abwärtskompatibilität zu implementieren, war es erforderlich, HTML-Inhalte an TinyMCE zu senden, die wir bereits gelernt haben, aus strukturierten Körpern zu erstellen und beim Speichern des Beitrags in der Datenbank zu speichern. Wenn Sie einen Beitrag über TinyMCE speichern, wird der auf dem Server erstellte Inhalt über den HTML2SB-Dienst ausgeführt.Dadurch können wir sowohl frisches HTML als auch strukturierten Text speichern.

HTML2SB ist das Gegenteil von SB2HTML, dh es konvertiert Inhalte von HTML in strukturierte Körper. Chronologisch gesehen erschien dieser Dienst früher als alles andere, da vor der Erstellung des WYSIWYG-Editors die einzige Möglichkeit, Post-Inhalte im strukturierten Body-Format abzurufen, das direkte Parsen aus HTML war. HTML2SB war Teil der Backend-Infrastruktur rund um den Post-Editor, wurde jedoch nach dem Verlassen von TinyMCE nicht mehr benötigt.

4. Beta-Ergebnisse

Jetzt steht der WYSIWYG-Editor allen Benutzern in der Beta-Version zur Verfügung und wird in Kürze der Hauptredakteur von Sports.ru-Posts. Wir haben bereits ein Tool zum Erstellen und Bearbeiten von Posts erhalten, das die meisten unserer Anforderungen erfüllt:

Die Benutzeroberfläche des Herausgebers ist klar, prägnant und modern geworden. Das Schreiben langer Beiträge ist viel einfacher geworden.
Jetzt können Sie Bilder aus einer Datei und über einen Link herunterladen, die sofort in unser Repository gestellt werden.
Die Option zum Einbetten von Einbettungen aus wichtigen sozialen Netzwerken und Video-Hosting-Sites wurde hinzugefügt.
bereinigte Textformatierungsstile;
Mobile Anwendungen haben bereits auf die Anzeige von Posts aus strukturierten Körpern umgestellt und können ihre eigenen Stile für Inhalte festlegen.

Natürlich ist der Editor noch nicht vollständig getestet, wir erkennen regelmäßig neue Fehler. Die folgenden Updates kommen:

automatisch speichern;
WYSIWYG-Version für Benutzer mit erweiterten Rechten (Administratoren, Vollzeiteditoren);
Erstellen und Bearbeiten von Posts in mobilen Browsern;
Meldungen zur parallelen Bearbeitung eines Dokuments durch mehrere Benutzer;
Tipps und Onboarding;
statistische Widgets für Sportmannschaften, Spiele und Aufstellungen.

Zum Zeitpunkt dieses Schreibens wurden bereits mehr als 13.000 Beiträge über die Beta-Version des Editors veröffentlicht, was etwa 20% der Gesamtzahl der Benutzertexte auf Sports.ru für den Zeitraum von Juni 2019 bis einschließlich Februar 2020 entspricht. Der Anteil der über den neuen Editor erstellten und veröffentlichten Beiträge wächst stetig.

Feige. 3. Der Anteil der Benutzerbeiträge, die im neuen Editor erstellt und veröffentlicht wurden

Es scheint, dass das organische Wachstum des Anteils der über den neuen Editor erstellten und veröffentlichten Benutzerbeiträge ein Signal dafür ist, dass die Benutzer mit dem Update zufrieden sind. Dies wird auch durch das Feedback in der Ankündigung des Starts der Betatests bestätigt (einige davon sind in Abb. 4 dargestellt). Daher planen wir in den kommenden Monaten, die Erstellung von Posts vollständig auf den neuen Editor zu übertragen, um uns nur auf dessen Unterstützung und Entwicklung zu konzentrieren.
Welche Funktionen würden Sie übrigens unserem WYSIWYG-Editor hinzufügen?

Feige. 4. Benutzerkommentare in einem Beitrag mit der Ankündigung des WYSIWYG-Editor-Updates

Als Sports.ru schrieb ihr WYSIWYG-Editor