Sealpage - zarys wizji

Potrzebujemy dobrego CMS-a. Nie znalazłem takiego, więc najlepiej będzie, jeżeli takiego stworzymy :slight_smile: W tym poście opiszę jakie problemy napotykam w pracy z istniejącymi CMS-ami i jak proponuję je rozwiązać.

Projekt tego CMS-a nazywa się teraz roboczo Sealpage.

Zapraszam do komentowania i brania udziału w realizacji zarysowanego tutaj projektu :muscle:

Cechy dobrego CMS-a

Oto lista cech, które moim zdaniem powinien posiadać dobry CMS:

1. Wydajność.

Od samych fundamentów CMS powinien być budowany z wydajnością na uwadze. Jestem w głębokim szoku, kiedy widzę ile zajmuje wyrenderowanie prostej strony “Hello World” z jednym obrazkiem takim tytanom CMS-owym jak Drupal czy Wordpress (10s+!). Wspomniane CMS-y mają warstwę cache’u, która znacznie przyspiesza stronę dla niezalogowanych użytkowników, ale zalogowani użytkownicy już nie mają tego przywileju. Do tego mam bardzo przykre doświadczenia z nieczyszczącymi się cache’ami, cache’ami które są wielorakie (trzeba czyścić wiele z nich, w różnych miejscach, aby zmiany na stronie się ukazały) i innymi nieprzewidzianymi przeszkodami związanymi z warstwami cache’u w tych frameworkach.

Dobry CMS powinien wyświetlać strony natychmiastowo, obojętnie czy ktoś jest zalogowany, czy jest anonimowym użytkownikiem. Wydajność powinna być osiągnięta poprzez maksymalne skrócenie czasu generowania strony, a nie tylko za pomocą agresywnego cache’owania. Cache powinien czyścić się sam, lub powinna istnieć możliwość szybkiego i prostego czyszczenia go ręcznie. Potrzeba więc szybkiego sposobu na renderowanie stron.

2. GUI do tworzenia treści.

Jeżeli zależy nam tylko na wydajności, to możemy skorzystać z headless-owych CMS-ów, albo nawet z generatorów statycznych stron. Wszak trudno pobić wydajność serwera statycznych plików html :wink: Niestety korzystanie z takich narzędzi wyklucza tworzenie stron, którymi potem mają zarządzać osoby nietechniczne, no bo nie będziemy kazać klientowi puszować pliów md gitem na staging żeby wywołać builda.

Aktualne duże CMS-y są tak dziwnie zrobione, że pozwalają wyklikać WSZYSTKO z poziomu panelu admina. Można zmienić układ strony, można doinstalować moduły, można je konfigurować, przeglądać logi, konfigurować SMTP… Domyślam się, że taki stan rzeczy jest przydatny w workflow „wrzuć te pliki na FTP w hostingu i będziesz miał stronę, wszystko sobie wyklikasz”. Ale moim zdaniem przy takim podejściu traci zarówno docelowy użytkownik / content creator, jak i developer tworzący daną stronę.

Dlaczego użytkownik traci? Bo dostaje przeładowany interfejs, w którym wiecznie boi się, że coś zepsuje. To jest historia stara jak świat: „Proszę mi tu dać CMS, bo ja chcę móc sobie potem zmienić wszystko samodzielnie i nie musieć z każdą pierdołą do was dzwonić”. Miesiąc po oddaniu projektu: „Dzień dobry, chcę zmienić jedną pierdołę, ale nie mogę tego znaleźć, no i boję się szukać bo jeszcze coś naknocę”

Dlaczego developer traci? Bo musi wyklikiwać konfigurację strony za pomocą interfejsu webowego, zamiast robić to np. w plikach tekstowych albo automatyzować za pomocą swoich (lub dostarczonych przez CMS!) skryptów.

Z tego powodu moim zdaniem potrzebne jest rozłączenie interfejsu do wprowadzania treści od interfejsu do konfiguracji strony. Nie wszystko musi być wyklikiwalne, wręcz ograniczałbym to do absolutnego minimum, nakreślonego przez odpowiedzialność użytkownika końcowego.

Dobry CMS udostępnia interfejs graficzny do wprowadzania i edytowania treści, ale konfiguracja sposobu jego działania odbywa się w kodzie.

3. WYSIWYG

Moim zdaniem edytory typu WYSIWYG nie mają miejsca w dobrym CMS. Kiedyś, kiedyś takie edytory wydawały mi się niesamowicie przydatne - definiuję po prostu kolekcję z polem typu HTML, w formularzu edycji daję jakiegoś WYSIWYG i klient może osiągać różne bajery graficzne bez konieczności proszenia mnie o ich implementację w html/css.

Ale wysiwygi zawodzą mnie na następujące sposoby:

  1. Dostępność. Dobra strona jest podzielona na nagłówki h1-h6, aby osoby korzystające ze screen readerów mogły wygodniej po niej skakać i odnaleźć się z większą łatwością. Niestety czasem nawet najlepszemu klientowi niemożliwe jest wytłumaczenie, że <font style="font-size:20pt> to nie to samo, co <h2>.

    Dlatego sposób na wprowadzanie treści przez użytkownika końcowego powinien być stworzony tak, aby wprowadzenie treści niedostosowanych pod a11y było trudne, a może nawet nie możliwe.

    IMHO super rozwiązał to Discourse - mamy edytor z guzikami, ale to nie jest wysiwyg. Kliencie - chcesz większy tekst? Zaznacz go i użyj przycisku “nagłówek”. Dodadzą się znaczniki markdownowe, które mogłyby być bardzo dezorientujące („a skąd te hasztagi?”), ale generowany na żywo podgląd po prawej stronie pomaga zrozumieć, jaki będzie efekt i jakie jest ich znaczenie.

  2. Bardziej złożone layouty klient może łatwo zepsuć. Miałem kiedyś sytuację, że klient przyklepał projekt od grafika, w którym na jednej z podstron jest taki layout:

    Zdecydowałem się, że wdrożymy te stronę zgodnie z projektem, przy zachowaniu responsywności itp, ale strona nie będzie edytowalna. Jeżeli klient miałby dostęp do edycji tego w typowym edytorze wysiwyg, który próbuje na podstawie contentu w HTML zrobić edytor przypominający MS Word, to istnieje zbyt duże ryzyko, że klient wciśnie o jeden backspace za dużo i cały layout się rozsypie.

  3. Problemy z formatowaniem. Niby wysiwyg ułatwia tworzenie treści, ale niestety „when what you see is what you get, then you can’t get what you don’t see”, przez co zdarzają się sytuacje, w których nawet power-userzy mogą czuć frustrującą bezsilność:

4. Możliwość trzymania wersji strony w GIT

Jedną z największych bolączek Drupala i Wordpressa jest to, jak trudno jest pracować nad stroną tworzoną w którymś z nich w więcej niż jedną osobę. Przyczyną tego jest fakt, że te CMS-y trzymają konfigurację strony (układ elementów, fragmenty tekstowe, ustawienia motywu itp) w bazie danych.

Dlatego też workflow w którym robimy snapshoty strony w commitach i możemy sobie po nich wygodnie skakać, robić review itp jest niesamowicie utrudniony. No bo przecież nie będziemy trzymali dumpów mysql w repozytorium…

Często więc wpólna praca nad stronami w tych frameworkach kończy się na wspólnym edytowaniu instancji tej strony na produkcji lub stagingu, bez kontroli wersji.

Drupal troszkę próbował nalepić plaster na ten problem poprzez stworzenie narzędzia CLI do automatyzacji części z tych procesów, ale to jest leczenie mocno objawowe, nie rozwiązującego bardziej fundamentalnego problemu: w bazie danych są zarówno treści strony, jak konfiguracja jej layoutu i innych aspektów jej działania.

Dobry CMS powinien mieć to ściśle rozgraniczone. Sealpage będzie w bazie danych trzymał tylko treści, a opis tego jak strona wygląda i jak jest skonfigurowana będzie w plikach z jej kodem, ew. w jakichś plikach konfiguracyjnych, dzięki czemu będziemy mogli pracować nad stroną w naszym Sealhub Workflow. Klonujesz repo, checkoutujesz się na jakiegoś commita, odpalasz kod, widzisz stronę z tego commita. Niby niewiele, ale Wordpress i Drupal tego nie dają.

Wiem, że to blokuje drogę do idealnego “dajemy stronę klientowi, i jak w przyszłości chce coś zmienić, to już sam sobie wyklika”, ale po prostu wiem, że nawet przy usilnych staraniach programistów klient tak rzadko osiąga samodzielność w konfigurowania strony, że to nie jest warte ograniczeń, jakie nakłada na proces jej developowania.

Chciałbym, aby Sealpage był tworzony przy założeniu współpracy pomiędzy klientem/użytkownikiem a developerem. Użytkownik może wprowadzać zmiany w treści strony, a zmiany w jej strukturze są dokonywane przez dewelopera.

Architektura

Proponuję, aby Sealpage składał się z trzech osobnych modułów:

  1. ORM do ustawiania struktury contentu i dającego bezpieczne REST-owe API: już mamy - Sealious. Po tym refaktorze nabierze całkiem współczesnego kształtu. To jest kod, którym będzie zarządzał deweloper.

  2. GUI do tworzenia i edycji treści wg struktury opisanej w ORM - trzeba stworzyć (i wymyśleć nazwę!). Panel edycji danej strony / posta nie dawałby pełnego GUI, tylko osobne pola dla różnych elementów opisanych w strukturze ORM-owej. To jest interfejs, do którego będzie się logował klient.

  3. Sytem templatek nastawiony na edycję wg zdefiniowanej struktury i szybkość renderowania. Będzie renderować strony widoczne dla czytelników witryny.

    Nie mam tutaj na myśli języka do interpolacji HTML-a ze zmiennymi (mamy już do tego takie moduły jak pug czy zwykłe template literals w JS). Opis HTML-owej treści w kontekście Sealpage’a będzie składał się z komponentów, które są funkcjami które zwracają HTML.

    Aby np. zrobić stronę z nagłówkiem, zdjęciem i tekstem, tworzymy listę trzech elementów (nazwa_komponentu:string , parametry:any) i podajemy jako input do renderowania. Wynikem renderowania jest HTML.

    HTML nie będzie zwracany jako string, ale jako Stream. Dzięki temu nie będziemy musieli czekać na zakończenie renderowania całego HTML-a aby zacząć wysyłać odpowiedź do przeglądarki. Pomocne będzie w tym narzędzie flora, które niedawno przepisałem na TypeScripta.

    Rozmiar strony będzie można też zmniejszyć poprzez dołączanie tylko tego CSS-a, który jest używany na danej podstronie, najlepiej dając go wewnątrz <style> zamiast kazać robić osobny request.

    Ten system templatek (nazywany przeze mnie roboczo Tempseal) będzie składał się więc z:

    • biblioteki gotowych komponentów (np. “obrazek z opisem”, “dłuższa treść napisana w markdownie”, “slideshow”;
    • metadanych umożliwiających panelowi do tworzenia i edycji treści wyświetlanie inputów do każdego z paramsów używanych komponentów;
    • integracji z narzędziem do streamowania HTML-a.

Tyle przemyśleń udało mi się uzbierać na teraz. Niedługo zacznę rozpisywać plan działania na poszczególne atomowe taski, tak aby każdy mógł wziąć udział w procesie tworzenia tego narzędzia :slight_smile:

Zapraszam też do dzielenia się Waszymi przemyśleniami.

2 Likes