nehrebeccy.pl - Projekt WordPress | WPPoland

#Agencja z Gdyni, która sprzedaje spotkania, a nie produkty

R&K Nehrebeccy to agencja artystyczna z Gdyni, prowadzona przez Renatę i Krystiana Nehrebeckich, działająca nieprzerwanie od 1994 roku. Adres przy ulicy Obrońców Wybrzeża, środowisko trójmiejskie, kluby, domy kultury i biblioteki. Agencja tworzy i obsługuje wydarzenia artystyczne: spotkania z gwiazdami, koncerty, widowiska, uroczyste inauguracje, rocznice i jubileusze, od pomysłu i scenariusza, przez zaangażowanie artystów, po scenografię i projekcje multimedialne. Osobną, rozpoznawalną częścią oferty jest Biesiada Literacka, czyli spotkania z autorami książek.

To ma bezpośrednie konsekwencje dla oprogramowania. Firma, która sprzedaje produkt, potrzebuje katalogu. Firma, która sprzedaje wydarzenie, potrzebuje czegoś innego: dowodu, że wydarzenie się odbyło i że poszło dobrze. Po stronie treści oznacza to, że najważniejszym zasobem serwisu nie jest cennik ani opis usługi, tylko lista nazwisk, z którymi agencja pracowała, oraz archiwum tego, co już się wydarzyło. Strona z 2012 roku była budowana wokół tego założenia.

Drugą cechą tego odbiorcy jest sposób, w jaki podejmuje decyzję. Po drugiej stronie nie siedzi konsument, który kupuje impulsywnie, tylko koordynator programu w domu kultury albo osoba odpowiedzialna za jubileusz firmy. Taka osoba szuka konkretnego nazwiska, sprawdza, czy agencja już z nim pracowała, i dopiero potem pisze albo dzwoni. Nawigacja serwisu musiała więc prowadzić od nazwiska do wydarzenia i od wydarzenia do nazwiska, a nie od strony głównej do zakładki z ofertą.

#Model treści, czyli decyzja, która ustawiła resztę projektu

Wdrożenie stoi na WordPressie i pierwsze rozstrzygnięcie dotyczyło tego, czym w bazie jest artysta, a czym wydarzenie. Najprostsza droga, czyli opisanie obu jako zwykłych wpisów albo, co gorsza, jako stron, wygląda na oszczędność czasu na etapie budowy i mści się przy każdej późniejszej zmianie. Wpis nie ma miejsca na pole z datą wydarzenia, na miejsce, na rolę artysty w tym konkretnym spotkaniu. Wszystko to ląduje wtedy w treści, czyli w jednym polu tekstowym, z którego nic nie da się wyciągnąć programowo.

Dlatego artysta i wydarzenie są tu osobnymi typami treści, a łączy je relacja. Jedno wydarzenie ma wielu twórców, jeden twórca ma wiele wydarzeń, i to jest dokładnie ta struktura, która pozwala zbudować dwa widoki z jednego zbioru danych: sylwetkę twórcy z listą jego wystąpień oraz opis wydarzenia z listą osób, które w nim brały udział. Gdyby te informacje były wpisane ręcznie po obu stronach, każda zmiana wymagałaby edycji w dwóch miejscach, a po roku połowa z nich rozjechałaby się po cichu.

Taksonomie porządkują to z trzeciej strony. Podział na kategorie twórców, pisarzy, aktorów, dziennikarzy, oraz podział na typy wydarzeń, koncert, spotkanie autorskie, inauguracja, jubileusz, daje listy, których nikt nie musi utrzymywać ręcznie. Nowy wpis przypisany do kategorii pojawia się na odpowiedniej liście sam. Wygląda to na drobiazg, ale w serwisie prowadzonym przez dwie osoby, które robią to obok właściwej pracy, różnica między listą generowaną a listą utrzymywaną ręcznie decyduje o tym, czy serwis jest aktualny po trzech latach.

#Kluczowe funkcjonalności serwisu

Portfolio twórców jest głównym widokiem serwisu. Każdy profil zbiera zdjęcia, opis dorobku i historię współpracy, a układ tej strony ma jedno zadanie: pozwolić w kilkanaście sekund ocenić, czy ta osoba pasuje do wydarzenia, które ktoś właśnie planuje. Stąd kolejność informacji, w której zdjęcie i krótki opis stoją wyżej niż pełna biografia, a lista wystąpień jest widoczna bez przewijania do końca strony.

Kalendarz i archiwum wydarzeń to ta sama struktura danych oglądana z dwóch stron. Nadchodzące wydarzenia są informacją dla publiczności, minione są dowodem dla zleceniodawcy. Dlatego wydarzenie po dacie nie znika, tylko przechodzi do archiwum, i o technicznych konsekwencjach tej decyzji piszę osobno niżej, bo to jest miejsce, w którym najłatwiej w tym projekcie było zbudować coś, co po pięciu latach przestaje działać.

Materiały multimedialne, zdjęcia z sal, nagrania audio i wideo, są integralną częścią wpisu, a nie dodatkiem doklejonym na końcu. Galeria z wydarzenia jest najczęściej tym, co przekonuje kolejnego klienta, więc musi być łatwa do dołożenia i musi się szybko otwierać. Te dwa wymagania stoją ze sobą w sprzeczności i cała praca wydajnościowa w tym projekcie polegała na ich pogodzeniu.

Redakcja treści odbywa się w standardowym panelu WordPressa, z polami dopasowanymi do typów treści opisanych wyżej. Świadomie nie ma tu budowniczego stron. Osoba, która dodaje wydarzenie między jednym a drugim spotkaniem autorskim, ma wypełnić pola, a nie projektować układ, bo projektowanie układu przy każdym wpisie to najkrótsza droga do serwisu, w którym dwadzieścia podstron wygląda na dwadzieścia różnych serwisów.

Udostępnianie w mediach społecznościowych jest w tym kontekście funkcją, a nie ozdobą. Informacja o spotkaniu autorskim rozchodzi się przez profile uczestników i przez strony instytucji, w których wydarzenie się odbywa, więc każdy wpis musi mieć poprawne znaczniki dla udostępnienia: tytuł, opis i obrazek, który nie jest przypadkowym fragmentem tła.

#Archiwum jest tutaj argumentem sprzedażowym

W większości serwisów z kalendarzem minione wydarzenie jest śmieciem. Tutaj jest dokładnie odwrotnie, bo zakładka z listą tego, co agencja już zrobiła i kogo gościła, jest silniejszym argumentem niż jakikolwiek opis oferty. To odwrócenie zmienia sposób, w jaki trzeba przechowywać datę.

Naturalny odruch to trzymanie daty wydarzenia jako pola dodatkowego przy wpisie. W WordPressie takie pole ląduje w tabeli z metadanymi, gdzie wartości są tekstem, a nie datą. Zapytanie o wydarzenia z przyszłości przestaje być wtedy porównaniem dat, a staje się porównaniem ciągów znaków, i przy dacie zapisanej w formacie dziennym daje wyniki bezsensowne przy przejściu przez koniec miesiąca. Do tego każde takie zapytanie dokłada złączenie do tabeli metadanych, a filtrowanie i sortowanie po tym samym polu dokłada kolejne.

Rozwiązania są dwa i oba wymagają decyzji na starcie, a nie po roku. Pierwsze: zapisywać datę w formacie, który sortuje się poprawnie jako tekst, czyli rok, miesiąc, dzień bez separatorów. Drugie, czystsze: wykorzystać właściwą datę wpisu jako datę wydarzenia i przesunąć obsługę wpisów z przyszłości, bo wtedy cała selekcja dzieje się na indeksowanej kolumnie tabeli wpisów, a nie na tekstowym polu w metadanych. Różnica między tymi podejściami jest niewidoczna przy pięćdziesięciu wpisach i bardzo widoczna, gdy archiwum urośnie przez kolejne lata, a właśnie po to archiwum istnieje.

Druga pułapka archiwum dotyczy adresów. Strona wydarzenia sprzed trzech lat bywa linkowana ze strony biblioteki albo domu kultury, w którym się odbyło. Jeżeli adresy są zbudowane wokół tego, czy wydarzenie jest nadchodzące, czy minione, to przejście przez datę zmienia adres i wszystkie te odnośniki się psują. Adres musi więc opisywać, czym wydarzenie jest, a nie w której zakładce akurat się wyświetla.

#Wyzwania i zastosowane rozwiązania programistyczne

Pierwszym wyzwaniem była prezentacja obszernej oferty bez przeładowywania strony. Filtrowanie twórców po kategorii i przeglądanie kolejnych porcji listy dzieje się przez AJAX, co w 2012 roku oznaczało konkretny mechanizm: żądanie trafia do wspólnego punktu wejścia WordPressa dla zapytań asynchronicznych. Trzeba wiedzieć, co się przy tym dzieje, bo to wyjaśnia resztę decyzji w tym projekcie. Każde takie żądanie uruchamia pełny start WordPressa razem z wtyczkami, a więc kosztuje tyle samo, co wygenerowanie całej strony, mimo że w odpowiedzi wraca fragment listy. Przy przeglądaniu, w którym użytkownik klika kolejne filtry po kilka razy, to się sumuje.

Stąd bierze się konstrukcja, w której lista jest krótka, filtr zwęża zbiór po stronie zapytania, a nie po stronie przeglądarki, i w której wynik pojedynczego zestawu filtrów daje się przechować. Alternatywa, czyli pobranie wszystkich twórców naraz i przesiewanie ich w przeglądarce, jest kusząca, bo jest prostsza w kodzie, i przestaje działać dokładnie wtedy, gdy zbiór urośnie na tyle, że przesyłanie go w całości kosztuje więcej niż kolejne zapytania.

Drugim wyzwaniem była wydajność serwisu ciężkiego od multimediów. Cache obiektowy w pamięci skraca pracę bazy dla tego, co i tak musi przejść przez PHP: zbiorów wpisów, taksonomii, opcji. Sieć dostarczania treści przejmuje pliki, czyli zdjęcia i nagrania, i w tym projekcie to ona odpowiada za większą część odczuwalnej różnicy, bo to obrazy z sal koncertowych ważą najwięcej. Warto powiedzieć wprost, że to są dwa różne problemy rozwiązane dwoma różnymi narzędziami. Cache obiektowy nie przyspiesza pobrania zdjęcia, a sieć brzegowa nie skraca zapytania do bazy.

Trzecim wyzwaniem był układ responsywny w roku, w którym responsywność była świeżą praktyką, a nie domyślną. W 2012 roku przeglądarki nie miały jeszcze mechanizmu wyboru wariantu obrazka po stronie klienta. Ten mechanizm trafił do WordPressa dopiero kilka lat później. Oznaczało to, że decyzja, którą wersję zdjęcia wysłać, zapadała po stronie serwera, na podstawie zdefiniowanych rozmiarów miniatur. Galeria z wydarzenia, wgrana prosto z aparatu fotografa, musiała więc mieć przewidziane własne rozmiary pośrednie, bo inaczej telefon pobierał plik przygotowany na ekran biurkowy.

Preprocesor arkuszy stylów nie był w tej sytuacji ozdobnikiem, tylko narzędziem do utrzymania punktów przełamania układu w jednym miejscu. Bez niego progi szerokości rozjeżdżają się po całym arkuszu, a każda zmiana siatki wymaga przejścia przez kilkanaście miejsc naraz. Warto dodać, że układ tej strony budowany był jeszcze bez siatek natywnych, które przyszły do przeglądarek później, więc kolumny opierały się na opływaniu i szerokościach procentowych, co przy galerii o zmiennej liczbie elementów wymagało ostrożności przy zamykaniu rzędów.

Czwartym wyzwaniem była łatwość aktualizacji. Tutaj rozwiązanie nie jest techniczne, tylko organizacyjne: pola zamiast dowolnej treści, listy generowane z relacji zamiast ręcznych, i zdefiniowane rozmiary obrazów zamiast decyzji podejmowanej przy każdym wgraniu. Serwis, w którym osoba redagująca musi pamiętać trzy zasady, żeby nie zepsuć układu, jest serwisem, który zepsuje się w pierwszym tygodniu po odbiorze.

#Podział warstw i wycofywanie zmian

Treść, konfiguracja i kod siedzą w tym wdrożeniu osobno, i to jest właściwość, którą widać dopiero przy pierwszej nieudanej zmianie po starcie. Jeżeli wygląd zakładki zależy od tego, co ktoś wpisał w treści wpisu, to poprawka wyglądu jest poprawką treści i nie da się jej wycofać bez cofnięcia redakcji. Jeżeli układ zależy od ustawienia w panelu, a to ustawienie nie jest zapisane nigdzie poza bazą, to odtworzenie stanu sprzed zmiany wymaga pamięci osoby, która to ustawiała.

Rozdzielenie tych trzech warstw sprawia, że wycofanie zmiany rusza jedną z nich. Kod wraca do poprzedniej wersji, a treść zostaje. Treść wraca do poprzedniej wersji, a kod zostaje. To nie jest teoretyczna zaleta, tylko warunek, żeby serwis dało się utrzymywać przez lata przez osobę, która nie brała udziału w pierwszym wdrożeniu.

Testy przypadków brzegowych szły na kopii produkcji, nie na pustej instalacji. W serwisie o tym kształcie różnica jest konkretna: pusta instalacja nie ma galerii z osiemdziesięcioma zdjęciami w jednym wpisie, nie ma twórcy powiązanego z wydarzeniami rozrzuconymi przez kilka lat i nie ma wpisów, w których pole daty zostało wypełnione niekonsekwentnie, bo ktoś kiedyś wpisał ją ręcznie w innym formacie. Wszystkie trzy sytuacje wychodzą dopiero na prawdziwych danych, a każda z nich potrafi wywrócić widok listy.

#Wsparcie i utrzymanie serwisu

Opieka nad serwisem obejmuje aktualizacje silnika i motywu, przegląd logów oraz kopie zapasowe. Kolejność ma tu znaczenie: kopia zapasowa, której nikt nigdy nie odtworzył, nie jest kopią zapasową, tylko plikiem. Weryfikacja odtworzenia jest częścią tej pracy, a nie dodatkiem do niej.

Aktualizacje w serwisie z relacjami między typami treści niosą osobne ryzyko. Gdy relacja między twórcą a wydarzeniem jest utrzymywana przez warstwę pośrednią, to jej zmiana potrafi przestawić sposób zapisu powiązań, a widok listy wygląda wtedy poprawnie dokładnie do momentu, w którym ktoś doda nowy wpis. Dlatego aktualizacje idą najpierw na kopię, a sprawdzenie polega na dodaniu nowego powiązania, a nie na obejrzeniu strony głównej.

Drobne zmiany graficzne i funkcjonalne dokładane w trakcie utrzymania trzymają się tej samej reguły co wdrożenie: zmiana idzie do warstwy, do której należy. Nowy typ wydarzenia to wpis w taksonomii, nie nowy szablon. Inne proporcje zdjęć w galerii to zmiana rozmiarów miniatur i ich przegenerowanie, nie doklejenie stylu do jednej podstrony.

#Przebieg wdrożenia

Całość zajęła około sześciu tygodni, licząc od ustalenia zakresu do publikacji. Układ i rozmieszczenie elementów dostarczył klient, więc etap, który w innych projektach zjada najwięcej kalendarza, tutaj odpadł. Czas poszedł na model treści i na te części, których na makiecie nie widać: relację między twórcą a wydarzeniem, sposób przechowywania daty, rozmiary obrazów i zachowanie list przy filtrowaniu.

Najważniejsza decyzja projektu zapadła na początku i dotyczyła tego, że archiwum jest równoprawnym widokiem, a nie odpadem po kalendarzu. Wszystko inne, od sposobu zapisu daty, przez budowę adresów, po to, że minione wydarzenie zachowuje własną stronę, wynika z tego jednego rozstrzygnięcia. Projekty, w których ta decyzja zapada rok po starcie, kończą się przepisaniem adresów i utratą odnośników z zewnątrz.

Po starcie serwis wszedł w utrzymanie prowadzone po stronie agencji, z naszym wsparciem przy aktualizacjach i zmianach wykraczających poza redakcję treści. Wdrożenie pochodzi z 2012 roku i warto to napisać wprost, bo opisy realizacji często podają dzisiejszy stan jako ten, z którym projekt startował. Tutaj część rozwiązań, jak ręczne zarządzanie wariantami obrazów, była w 2012 koniecznością, a dziś byłaby błędem, ponieważ platforma robi to sama.

#Podsumowanie

nehrebeccy.pl to serwis agencji artystycznej zbudowany wokół dwóch encji, twórcy i wydarzenia, oraz relacji między nimi. Z tej struktury biorą się wszystkie widoki: sylwetka twórcy z listą wystąpień, opis wydarzenia z listą uczestników, listy według kategorii i archiwum, które w tej branży jest argumentem, a nie balastem.

Po stronie technicznej wdrożenie stoi na WordPressie, cache obiektowym w pamięci, sieci dostarczania treści dla materiałów multimedialnych i na układzie responsywnym zbudowanym w czasach, gdy responsywność wymagała ręcznej pracy przy każdym wariancie obrazu. Po stronie organizacyjnej stoi na prostszej zasadzie: serwis prowadzony przez dwie osoby obok ich właściwej pracy musi być odporny na to, że nikt nie będzie pamiętał zasad z odbioru.