Zespół marketingu buduje strony sam. Jak to działa w WordPressie
Redakcja chce opublikować landing pod kampanię w czwartek. Projekt graficzny jest gotowy, treść jest gotowa, a zmiana i tak trafia do kolejki zespołu technicznego. To wzorzec, który widzimy w większości serwisów zbudowanych przed 2022 rokiem, niezależnie od tego, jak dobry jest zespół po obu stronach.
WordPress rozwiązał ten problem na poziomie platformy. Nazywało się to Full Site Editing, dziś w oficjalnej nomenklaturze mówimy o Site Editorze i motywach blokowych. Mechanika została ta sama: zespół contentowy dostaje realną kontrolę nad układem strony, a zespół techniczny przestaje być wąskim gardłem przy każdej zmianie.
Poniżej wyjaśniamy, jak to działa, i co jest warunkiem, żeby zadziałało. Na końcu udostępniamy zapis webinaru, który poprowadziliśmy wspólnie ze studiem Kreatik.
Trzy rzeczy, które składają się na Full Site Editing
To nie jest jedna funkcja, a połączenie trzech mechanizmów. Warto je rozdzielić, bo każdy odpowiada za inną część problemu.
Edytor wizualny. Obejmuje nie tylko treść stron i wpisów, ale też szablony i stałe elementy serwisu. Nagłówek, stopka, układ archiwum, strona 404 – wszystko to edytujesz w tym samym interfejsie co treść.
Interfejs stylów. Jedno miejsce, w którym zdefiniowana jest paleta kolorów, kroje i rozmiary fontów oraz odstępy. Zespół nie dobiera kolorów ręcznie, wybiera z gotowego zestawu. To mechanizm utrzymania spójności wizualnej, nie kosmetyka.
Motyw zbudowany z bloków. W pełni edytowalny, bez sztywnych szablonów PHP, do których trzeba wracać przy każdej modyfikacji struktury.
Skąd bierze się wąskie gardło
W klasycznym podejściu treść wpisuje się w pola formularza, a efekt końcowy widać dopiero na froncie. Dynamiczne elementy wstawia się shortcode’ami, których trzeba się nauczyć i które łatwo zepsuć. Zmiana struktury sekcji wymaga wejścia w kod.
Efekt jest przewidywalny. Osoba nietechniczna pracuje w ciemno i po dwóch pomyłkach przestaje eksperymentować. Każda drobna zmiana wraca do zespołu technicznego, bo tak jest szybciej i bezpieczniej. Kolejka rośnie, a time-to-market kampanii liczy się w tygodniach.
To nie jest wina zespołu. To konsekwencja architektury, która nie przewidywała samodzielnej pracy redakcji.
Podejście blokowe: bloki i patterny
W modelu blokowym każdy element strony jest blokiem: paragraf, obrazek, tabela, przycisk, slider, blok FAQ, lista wpisów, kalendarz. Stronę składa się z nich jak z klocków.
Nad blokami stoją patterny – predefiniowane grupy bloków, na przykład kompletna sekcja strony. Hero z nagłówkiem, tekstem, przyciskiem i zdjęciem to jeden pattern. Sekcja z trzema kafelkami to drugi. Osoba budująca landing wstawia gotowy pattern i podmienia w nim treść. Nie projektuje sekcji od zera i nie ma jak jej rozjechać.
Standardowa biblioteka WordPressa daje sporo bloków od razu. Prawdziwa wartość pojawia się jednak wtedy, gdy na etapie wdrożenia dochodzą bloki dedykowane.
Bloki dedykowane: przykład z projektu afiliacyjnego
Dla jednego z klientów z segmentu afiliacyjnego zbudowaliśmy blok porównywarki. Redaktor wstawia go w treść i wypełnia: nazwa operatora, ocena eksperta, wynik punktowy, przycisk konwersji. Blok sam obsługuje układ, responsywność i spójność wizualną.
Bez tego bloku ta sama sekcja to zadanie dla developera przy każdej publikacji. Z nim jest to pięć minut pracy redaktora. Przy serwisie publikującym kilkanaście recenzji miesięcznie różnica w kosztach utrzymania jest łatwa do policzenia.
Zakres tego, co da się zamknąć w bloku, jest szeroki. Kalkulatory, warstwy filtrowania, tabele porównawcze, sekcje pobierające dane z zewnętrznego systemu. Na projekcie SCCG Management natywną warstwę wyszukiwania i filtrowania zbudowaliśmy na Interactivity API WordPressa, bez dodatkowych wtyczek.
Warunek, który decyduje o wyniku: design system
Tu jest miejsce, w którym większość wdrożeń blokowych rozjeżdża się po pół roku. Site Editor daje redakcji dużą swobodę. Jeśli nie ma zdefiniowanego zestawu komponentów, ta swoboda zamienia się w piętnaście wariantów tego samego przycisku.
Design system to zbiór zasad, wzorców i wytycznych projektowych, które porządkują budowę i rozwój produktu cyfrowego. W metodologii Atomic Design Brada Frosta układa się on w pięć poziomów: atomy, molekuły, organizmy, szablony, strony. Atom to pole input albo przycisk. Molekuła to wyszukiwarka złożona z labelki, inputa i przycisku. Wyżej powstają całe sekcje i strony.
Na webinarze Aleksandra Strelczuk z Kreatika przywołała trzy dane rynkowe. Według badania Adobe praca z design systemem skraca czas dostarczania projektów o 52%. Airbnb po wdrożeniu Design Language System skrócił czas pracy projektantów o 30%. Shopify podaje 95% redukcji czasu potrzebnego na tworzenie interfejsów po wdrożeniu systemu Polaris.
Liczby pochodzą z komunikacji tych firm i dotyczą dużych organizacji z wieloma produktami. Kierunek jest jednak spójny z tym, co widzimy na własnych projektach: koszt spójności ponosi się raz, na etapie projektu, albo wielokrotnie, przy każdej kolejnej podstronie.
Design system ma największy sens, gdy organizacja skaluje istniejący produkt, prowadzi kilka serwisów o różnych interfejsach albo widzi rozjazdy w stylach i kolorach między widokami. To także naturalny moment przy przeprojektowaniu obecnego serwisu.
Jak wygląda praca nad takim projektem
Kolejność jest odwrotna do intuicyjnej. Nie zaczynamy od stron.
Po otrzymaniu projektu graficznego rozkładamy go na części składowe. Developer definiuje poszczególne sekcje jako patterny, potem składa z nich całe strony. Projekt graficzny musi więc odpowiadać na pytania, których klasyczny mockup nie zadaje: jak zespół będzie pracował z serwisem, jak często będzie się on zmieniał, jakich komponentów potrzebuje do rozbudowy.
Dlatego przy migracjach z kreatorów stron na Gutenberga zaczynamy od inwentaryzacji komponentów, nie od przepisywania szablonów. Bez tego kroku powstaje motyw blokowy, który technicznie jest nowoczesny, a w praktyce wymaga developera dokładnie tak samo jak poprzedni.
Co to zmienia po stronie organizacji
- Mniejsza zależność od zespołu front-end przy zmianach w treści i układzie stron
- Zmiany widoczne od razu w edytorze, bez przechodzenia między panelem i frontem
- Większa kontrola redakcji nad układem strony przy zachowanych standardach
- Łatwiejsze utrzymanie zgodności z identyfikacją wizualną, gdy nad jednym serwisem pracuje kilka osób
- Krótsze wdrożenie nowej osoby w projekt, bo widać, co robi konkretny blok
- Fundament oparty na natywnych blokach, a nie na dodatkowej warstwie wtyczki, co daje więcej miejsca na optymalizację Core Web Vitals
Ostatni punkt jest istotny przy serwisach, w których wydajność przekłada się na przychód. Warstwa kreatora stron zawsze coś kosztuje w wynikach. Model blokowy tego narzutu nie ma.
Nagranie webinaru
Poniżej pełne nagranie webinaru „WordPress Full Site Editing i Design System”, który poprowadziliśmy wspólnie ze studiem Kreatik we wrześniu 2023 roku.
W programie:
- koncepcja edytora blokowego i porównanie z podejściem klasycznym (Paweł Zmysłowski, WLC)
- design system: czym jest, dla kogo, kiedy warto go wdrożyć, demo w Figmie (Aleksandra Strelczuk, Kreatik)
- demo na realnym projekcie: budowa podstrony od zera, praca na patternach, Query Loop, edycja stałych elementów serwisu (Bartosz Ornaf, WLC)
Co się zmieniło od nagrania
Nagranie pokazuje interfejs z 2023 roku. Zasady się nie zmieniły, narzędzia owszem. Najważniejsze różnice, jeśli oglądasz to dziś:
Nazewnictwo. Określenie „Full Site Editing” wyszło z oficjalnego słownika WordPressa. Dziś mówimy o Site Editorze i motywach blokowych. W praktyce branżowej skrót FSE nadal funkcjonuje.
Faza 2 Gutenberga jest domknięta. Zakończyła się na wersji 6.3. Site Editor nie jest już obszarem eksperymentalnym, tylko domyślnym sposobem pracy z motywami blokowymi.
Doszły mechanizmy governance. Block Locking API pozwala zablokować wybrane bloki i ustawienia, więc redakcja pracuje w wyznaczonych granicach. Pattern Overrides umożliwiają podmianę treści w patternie bez ruszania jego struktury. Block Bindings API łączy pola własne z blokami natywnymi bez pisania dodatkowego kodu. To odpowiedź na główne zastrzeżenie z 2023 roku, czyli że duża swoboda edycji jest ryzykiem na serwisie korporacyjnym.
Trwa Faza 3. Dotyczy współpracy zespołowej i procesów redakcyjnych. Wersje 7.0 i 7.1 przyniosły asynchroniczne komentarze w edytorze, sterowanie stylami per breakpoint oraz wspomaganie migracji motywów klasycznych. Dla organizacji planujących migrację ma to konkretne znaczenie: część pracy, którą jeszcze niedawno robiło się customowo, jest już w rdzeniu.
Jeśli decydujesz dziś o kierunku, punktem odniesienia jest stan bieżący, nie ten z nagrania. Chętnie przejdziemy przez to na Twoim projekcie. Porozmawiaj z ekspertem WordPress
