Jak wybrać edytor tekstu dla redakcji stawiającej na digital?
15 May 2023
Wiele redakcji nadal korzysta ze starych, przestarzałych edytorów tekstu, które często są dalekie od przyjazności dla użytkownika (obraz wygenerowany przez Midjourney)
Napisał Zespół Autentika
Wybór odpowiedniego edytora dla firmy medialnej może wydawać się prostym zadaniem. W rzeczywistości jest to zaawansowana technologia, w której każde małe działanie – jak naciśnięcie przycisku – wywołuje wiele zmian w podstawowym systemie programu. Opiszemy, jak przygotowujemy rekomendacje dla naszych klientów, abyś wiedział, co wziąć pod uwagę przy wyborze następnego edytora tekstu.
Przez lata zespół The New York Times korzystał z wewnętrznie opracowanego edytora tekstu, który nie do końca spełniał potrzeby redakcji. UI pozostawiał wiele do życzenia – podczas tworzenia artykułu użytkownicy musieli przechodzić przez długą serię nieintuicyjnych i mało atrakcyjnych wizualnie zakładek. Ponadto edytor sprawiał wiele kłopotów po stronie inżynieryjnej. Zespół NYT ostatecznie zdecydował się opracować nowy edytor (o nazwie Oak), który zapewniał bardziej intuicyjną i elastyczną implementację kodu i eliminował wiele problemów powodowanych przez starszy edytor.
Przykład NYT ilustruje typowe wyzwanie redakcji. Korzystają ze starych, przestarzałych edytorów tekstu, które często są dalekie od przyjazności dla użytkownika. Na przykład nie pozwalają dziennikarzom i redaktorom wstawiać komponentów artykułu w tekście ani zobaczyć szczegółowego podglądu materiału przed publikacją.
Jeśli tak jest również w twojej organizacji i szukasz odpowiedniej technologii do budowy nowego edytora tekstu, przyjrzyj się, jak podchodzimy do takich wyzwań i przygotowujemy rekomendacje odpowiedniego stosu technologicznego.
Czytaj też: Jak zaczynamy współpracę z redakcjami
Kluczowe zasady projektowania
Najpierw zdefiniujmy typowe zasady projektowania edytora tekstu:
1. Baza edytora będzie używana do zarządzania blokami i powinna umożliwiać podstawowe interakcje, takie jak dodawanie, zmiana kolejności i usuwanie bloków. 2. Bloki treści powinny być niezależnymi modułami/wtyczkami z własną zawartością, logiką i komunikacją API. 3. Użytkownicy mogą dodawać bloki treści niezależnie lub korzystać z predefiniowanych szablonów artykułów. 4. Artykuł powinien być kontenerem bloków z ustawieniami definiującymi kategorię artykułu, status i datę publikacji oraz miejsce i czas publikacji. 5. Dostępne bloki mogą być dowolnie rozszerzane o nowe rozwiązania w zależności od bieżących potrzeb. 6. Komunikacja z edytorem rich text będzie odbywać się przez API. 7. Dane bloków będą wysyłane do API w czasie rzeczywistym i zapisywane/odbierane jako obiekt JSON. 8. Przenosimy stylizację i formatowanie treści do obiektu JSON i rezygnujemy z notacji HTML. 9. Zapisywanie bloków powinno skutkować treścią renderowaną możliwie blisko końcowej formy wizualnej. 10. Końcowa treść powinna być walidowana przed publikacją, w tym jakość metadanych, analiza SEO i inne kryteria. 11. Edytor tekstu musi być zgodny z procesem redakcyjnym wydawcy.

Wybór odpowiedniego edytora dla firmy medialnej może wydawać się prostym zadaniem, ale w rzeczywistości może być dość skomplikowany.
Podstawowy stos technologiczny
1) Nginx + PM2
Zalecamy użycie Nginx, zaprojektowanego z natury jako serwer proxy. Umożliwia łatwą współpracę z aplikacją do zarządzania procesami Node.js. Jest to również oprogramowanie zapewniające skalowalność i jednoczesną obsługę wielu żądań przy niskich wymaganiach sprzętowych. Dostarczanie treści statycznych jest dwukrotnie szybsze niż w przypadku konkurencyjnego Apache2.
Jako menedżer procesów Node.js zalecamy PM2. Umożliwia uruchamianie wielu aplikacji Node.js (np. mikroserwisów) i oferuje dodatkowe narzędzia do monitorowania aplikacji klienckich.
2) API
Zalecamy GraphQL jako format API. Dane schematu pozwalają zespołowi front-endowemu pracować bez znaczącego zaangażowania deweloperów back-endowych w dostarczanie danych. Rozważaliśmy też REST lub API w trybie mieszanym, ale uznaliśmy GraphQL za bardziej wszechstronne, nowoczesne i wygodne rozwiązanie dla typu projektów naszych klientów.
3) React/Next.js
Proponujemy stworzenie aplikacji edytora opartej na bibliotece React (lub frameworku Next.js). Jest to aplikacja z dynamicznym renderowaniem treści, zapewniająca maksymalny komfort i wysoką wydajność dla użytkownika końcowego dzięki Virtual DOM.
Podstawą interfejsu byłyby wielokrotnie używane komponenty z własną logiką.
Środowisko to charakteryzuje się rozbudowanymi możliwościami aplikacji i dużą społecznością. Jest to obecnie najpopularniejsze rozwiązanie dla deweloperów tworzących frontend, co jest też ważnym aspektem z perspektywy HR – ułatwia pozyskanie deweloperów do wsparcia projektu.
4) Styled components + xStyled
W erze powszechnego użycia frameworków JS wykorzystujących szablony projektowane bezpośrednio w JS, naturalną konsekwencją jest stosowanie rozwiązania CSS-in-JS.
Popularną biblioteką ułatwiającą implementację tego podejścia jest biblioteka styled-components, często używana w aplikacjach pisanych w React.
Dzięki Styled-components nie jesteśmy już ograniczeni do definiowania stylów przypisanych tylko do konkretnej klasy CSS – zamiast tego style są dołączane do konkretnego komponentu, co ułatwia ich wielokrotne użycie w całej aplikacji. Ponadto xStyled pomaga zachować spójność z design systemem i umożliwia tworzenie stylów bezpośrednio w JSX.

Przeprowadziliśmy szeroko zakrojone badania nad edytorami rich text, by znaleźć najlepsze rozwiązanie
Rekomendacja edytora rich text
Lexical
Nasza analiza dostępnych rozwiązań edytorów wskazuje Lexical jako preferowaną opcję dla organizacji medialnych.
Zalety:
- Koncepcyjnie odpowiada założeniom narzędzia opracowywanego dla projektów naszych klientów.
- Jest niezależny od frameworka, ale natywnie obsługuje React – popularną bibliotekę do tworzenia aplikacji webowych.
- Komunikuje się z aplikacją przez API, co zapewnia większą elastyczność integracji z innymi systemami.
- Wynikowa treść jest w formacie JSON – bardziej ustrukturyzowanym i zestandaryzowanym sposobem reprezentowania treści niż HTML.
- Zapewnia konfigurowalny i modularny interfejs.
- Obsługuje współpracę w czasie rzeczywistym.
- Brak zależności dla łatwiejszej integracji z innymi frameworkami.
- Posiada licencję open-source.
- Jest następcą Draft.js i dostosowany do współczesnych realiów deweloperskich i przeglądarek, zapewniając bardziej aktualne rozwiązanie.
- Nie zawiera zależności, co czyni go lekkim i łatwym w użyciu z innymi frameworkami, jak Solid czy Svelte.
Potencjalną wadą Lexical może być to, że nie ma takiego samego poziomu wsparcia społeczności jak niektóre bardziej ugruntowane edytory rich text. Może wymagać większego nakładu pracy deweloperskiej, aby w pełni dostosować i rozszerzyć edytor zgodnie z potrzebami klienta.

Alternatywne opcje
W naszym procesie rozważaliśmy też inne opcje, jednak nie spełniały wszystkich początkowych wymagań.
Editor.js
Zalety:
- Blokami można łatwo zarządzać za pomocą funkcji przeciągnij i upuść.
- Obsługuje formatowanie inline i na poziomie bloków.
- Zapewnia przejrzysty i prosty interfejs użytkownika.
- Treść edytora można łatwo eksportować jako obiekt JSON, który mogą konsumować inne aplikacje.
- Obsługuje współpracę w czasie rzeczywistym.
- Posiada licencję open-source.
Wady:
- Ograniczone typy bloków w porównaniu z innymi edytorami.
- Produkt end-to-end, który może blokować lub utrudniać implementację innych rozwiązań stworzonych dla klienta.
- Brak wbudowanej obsługi pracy z obrazami poza podstawowym wstawianiem i wyrównywaniem.
- Brak bezpośredniej obsługi React.
- Wymaga niestandardowej integracji z API do komunikacji danych.
- Dokumentacja nie jest zawsze aktualna i może nie obejmować wszystkich dostępnych funkcji.
- Biblioteka rdzenia edytora jest objęta licencją własnościową, co może budzić obawy niektórych użytkowników.
Dowiedz się więcej o Editor.js
Quill
Quill może być alternatywnym wyborem dla redakcji, ponieważ oferuje rozbudowane API nad DOM, zapewniające bardziej zaawansowane i trafne możliwości edycji tekstu. Jest też wysoce konfigurowalny i obsługuje nowe formaty i treści wykraczające poza tradycyjne funkcje edytorów tekstu, jak pogrubienie, kursywa i listy. Użytkownicy mogą dodawać niestandardowe elementy, takie jak pokazy slajdów, interaktywne listy kontrolne i modele 3D.
Quill ma jednak ograniczenia, które mogą hamować dalszy rozwój. Produkt nie był rozwijany przez trzy lata, co może utrudniać implementację.
Zalety:
- Oferuje szeroką gamę opcji formatowania.
- Łatwy w użyciu z przyjaznym interfejsem.
- Obsługuje współpracę w czasie rzeczywistym.
- Wysoce konfigurowalny, pozwala deweloperom modyfikować funkcje według potrzeb.
- Oferuje funkcje współpracy w czasie rzeczywistym.
- Posiada dobrze udokumentowane API.
- Posiada licencję open-source.
Wady:
- Nie jest już rozwijany; ostatnia aktualizacja pochodzi z 2019 roku.
- Ograniczona funkcjonalność zarządzania blokami.
- Może być wolny przy ładowaniu i renderowaniu dużych dokumentów.
- Wymaga dodatkowych wtyczek dla bardziej zaawansowanych funkcji.
- Opcje formatowania w Quill mogą być czasem niespójne, co utrudnia tworzenie złożonych projektów lub szablonów.
- Dokumentacja API może być trudna w nawigacji i może wymagać metodą prób i błędów przy implementacji.
- Społeczność stojąca za Quillem nie jest tak duża jak w przypadku niektórych innych opcji, co może ograniczać dostępność wtyczek firm trzecich i zasobów wsparcia.
CKEditor
Zalety:
- Wysoce konfigurowalny i modularny z różnymi opcjami formatowania i wtyczkami.
- Obsługuje zarządzanie blokami metodą przeciągnij i upuść.
- Umożliwia łatwą integrację z popularnymi frameworkami webowymi.
- Posiada dobrze udokumentowane API.
- Posiada funkcję autozapisu, aby zapobiec utracie danych w przypadku nieoczekiwanych zdarzeń, takich jak przerwy w zasilaniu lub awarie.
- Obsługuje dostępność i jest zgodny ze standardami WCAG 2.0 i Section 508.
- Oferuje funkcję wspólnej edycji dla współpracy w czasie rzeczywistym między użytkownikami.
- Posiada licencję open-source.
Wady:
- Niektórzy użytkownicy zgłaszali trudności z dostosowaniem interfejsu do swoich potrzeb.
- Może być zasobochłonny i może spowalniać wydajność w większych projektach.
- Duży rozmiar może wpływać na czas ładowania strony.
- Niektóre wtyczki wymagają płatnych licencji.
- Dokumentacja może być trudna w nawigacji i zrozumieniu dla niektórych użytkowników.
Tiptap Editor
Zalety:
- Posiada modularną strukturę, umożliwiającą łatwą konfigurację i rozszerzenie.
- Obsługuje zarówno frameworki Vue.js, jak i React.
- Używa architektury komponentów bez renderowania, która nie zawiera żadnych predefiniowanych komponentów UI, co ułatwia integrację z dowolnym frameworkiem lub biblioteką frontendową.
- Zapewnia współpracę w czasie rzeczywistym.
- Posiada licencję open-source.
Wady:
- Krzywa uczenia się dla Tiptap może być stroma, szczególnie dla deweloperów nieznających Vue.js lub TypeScript.
- Ograniczone wsparcie społeczności.
ProseMirror
Zalety:
- Wysoce konfigurowalny i rozszerzalny.
- Silny nacisk na strukturę danych i definicję schematu.
- Używa modularnej architektury, ułatwiającej dodawanie lub usuwanie funkcji według potrzeb.
- Posiada aktywną społeczność i trwający rozwój.
- Posiada licencję open-source.
Wady:
- Stroma krzywa uczenia się przy implementacji.
- Wymaga większej wstępnej konfiguracji i ustawień w porównaniu z prostszymi edytorami.
- Ograniczona dokumentacja i zasoby w porównaniu z niektórymi innymi opcjami.
- Niektórzy użytkownicy zgłaszali problemy z wydajnością przy bardzo dużych dokumentach lub złożonych schematach.
Dowiedz się więcej o ProseMirror
Draft.js
Zalety:
- Zbudowany przez Facebooka i używany w ich produktach, posiada silną społeczność i wsparcie.
- Zapewnia bogaty system wtyczek umożliwiający dodatkową funkcjonalność i integrację z innymi bibliotekami i narzędziami.
- Dobrze integruje się z React i innymi popularnymi frameworkami.
Wady:
- Projekt jest w fazie zanikania.
- Krzywa uczenia się może być stroma, szczególnie dla osób nowych w React i jego ekosystemie.
- Dokumentacja API nie jest tak wyczerpująca jak w przypadku niektórych innych edytorów.
- Osiągnięcie współpracy w czasie rzeczywistym i synchronizacji z Draft.js może być trudne.
- Wydajność edytora może ucierpieć przy pracy z dużą ilością treści.
Podsumowanie
Po szeroko zakrojonych badaniach doszliśmy do wniosku, że najlepszy edytor rich text dla dużych organizacji medialnych powinien być wysoce konfigurowalny i dostosowany do ich wewnętrznych procesów redakcyjnych i przepływów pracy. Wśród najbardziej polecanych opcji znalazły się Lexical i Editor.js.
Ostatecznie stwierdziliśmy, że Lexical spełnia większość wymagań: konfigurowalny i modularny interfejs, łatwa komunikacja przez API oraz solidny system wsparcia z dokumentacją, forami i responsywnym zespołem wsparcia.
W naszej rekomendacji bierzemy też pod uwagę trwałość rozwiązania i kto za nim stoi. Jeśli wybierzesz rozwiązanie wspierane przez giganta technologicznego jak Meta – jak ma to miejsce w przypadku Lexical – edytor będzie prawdopodobnie wspierany długoterminowo i przyciągnie dużą społeczność użytkowników. Na koniec sprawdzamy zgłoszone problemy na Githubie i czy są aktywnie adresowane.
Oczywiście wybór często zależy od bardzo konkretnych potrzeb, wielkości firmy medialnej i jej złożoności. Jeśli chcesz podzielić się swoim doświadczeniem – zawsze jesteśmy otwarci na sugestie i nowe pomysły.
Obejrzyj też: Które narzędzia AI naprawdę zasługują na zainteresowanie?



