Gotowy projekt graficzny, którego nie dało się po prostu „wkleić"
Agnes Piaseczna uczy angielskiego autorską Metodą 4x15. Przyszła do nas z gotowym projektem graficznym w Figmie, przygotowanym przez zewnętrzne studio. Zadanie brzmiało prosto: postawić stronę dokładnie tak, jak wygląda w projekcie.
Prosto nie było. Projekt to 32 ramki: 15 widoków w wersji na komputer, tyle samo na telefon i dwie dodatkowe sekcje. Każdy widok to od półtora do ponad dziesięciu tysięcy pikseli wysokości. Wersji na tablet nie było wcale. A klientka chciała później sama zmieniać każdy tekst i każde zdjęcie, bez dzwonienia do programisty.
Projekt przeczytany, zanim powstała pierwsza linia kodu
Nie przerysowywaliśmy projektu z ekranu. Wyeksportowaliśmy go z Figmy przez interfejs programistyczny: strukturę każdej ramki, wszystkie zdjęcia w oryginale i rendery całych widoków jako wzorzec do porównań. Do tego powstało małe narzędzie, które zamienia drzewo projektu w czytelny opis układu: odstępy, wyrównania, rozmiary, kolory, kroje i style każdego fragmentu tekstu.
Dzięki temu odstęp 24 pikseli w projekcie był odstępem 24 pikseli w kodzie, a nie „mniej więcej tyle". I dzięki temu wyszło na jaw, czego w projekcie brakuje.
W makiecie były dane kontaktowe samego grafika, przykładowe pytania w FAQ, polityka prywatności skopiowana z szablonu zupełnie innej firmy, siedem literówek w nagłówkach i dwa różne zapisy nazwy metody. Każdą z tych rzeczy wypisaliśmy, poprawiliśmy albo oddaliśmy klientce do decyzji. Nic nie trafiło na produkcję tylko dlatego, że „tak było w Figmie".
Dwa rozmiary: komputer 1440 px i telefon 390 px
Dane kontaktowe i linki grafika
Pytania w FAQ jako przykład
Polityka prywatności innej firmy
Literówki i długie myślniki w nagłówkach
Płynny układ od 320 do 1440 px, z tabletem zaprojektowanym w kodzie
Prawdziwe dane klientki, edytowalne z panelu
Pytania napisane na podstawie treści strony, z danymi dla Google
Polityka napisana pod tę stronę i jej narzędzia
Poprawiona pisownia, jeden zapis myślnika
Jak to zbudowaliśmy
Eksport i analiza projektu
Struktura wszystkich ramek, oryginały zdjęć i rendery wzorcowe pobrane z Figmy. Opis układu generowany automatycznie, więc wymiary bierzemy z projektu, a nie z oka
Fundament i design system
Kolory, typografia, odstępy i cienie jako zmienne CSS. Nagłówek z rozwijanym menu, stopka, przyciski, ikony, slider opinii i tło z teksturą papieru. Wszystko gotowe, zanim powstała pierwsza podstrona
Podstrony równolegle
Każda podstrona dostała własny szablon, własne sekcje i własny arkusz stylów. Wspólne elementy były zamknięte do edycji, więc praca nad jedną stroną nie mogła zepsuć drugiej
Porównanie z projektem
Zrzut każdego widoku zestawiony z renderem z Figmy, w wersji na komputer i na telefon, minimum dwie rundy poprawek na podstronę. Tablet sprawdzany osobno, bo jego wygląd zaprojektowaliśmy sami
Wdrożenie produkcyjne
Przeniesienie plików i bazy z serwera testowego na docelowy, nowe klucze bezpieczeństwa, wymuszone HTTPS, adres bez www i nagłówek HSTS
Panel edycji treści
Po starcie strony każda sekcja dostała formularz w panelu. Klientka zmienia teksty, listy, przyciski i zdjęcia sama
Wierność projektowi bez page buildera
Motyw powstał od zera w PHP, z czystym CSS i zwykłym JavaScriptem, bez kroku budowania i bez żadnych zależności. To świadomy wybór: strona ma działać latami, a klientka ma ją edytować w WordPressie, który zna.
Najtrudniejszy był tablet. Projekt pokazywał tylko dwa skrajne rozmiary, a na stronę wchodzą też iPady, małe laptopy i telefony w poziomie. Pomiędzy 768 a 1279 pikselami układ zaprojektowaliśmy w kodzie, interpolując między wersją na telefon i na komputer tak, żeby każda sekcja zachowała proporcje i hierarchię z Figmy.
- Typografia przełączająca się sama między telefonem a komputerem, z kursywami i kolorowymi słowami dokładnie jak w projekcie
- Kroje Libre Baskerville i Quicksand trzymane na serwerze strony, z pełnym zestawem polskich znaków, bez pobierania z Google
- 69 zdjęć i grafik przekonwertowanych do formatu WebP, każde z wymiarami, żeby układ nie skakał podczas ładowania
- Główne zdjęcie każdej podstrony ładowane z najwyższym priorytetem
- Menu z dwoma poziomami, menu mobilne zamykane klawiszem Escape, stopka z akordeonami na telefonie
Jeden arkusz stylów zamiast kilkunastu
Kod stylów jest podzielony na czytelne pliki: wspólne i osobne dla każdej podstrony. Przeglądarka dostawałaby więc kilkanaście plików, z których każdy wstrzymuje wyświetlenie strony. Rozwiązaliśmy to po stronie serwera: motyw skleja arkusze danego widoku w jeden plik w locie, przepisuje w nim ścieżki do grafik i fontów, a przeglądarka trzyma go w pamięci przez rok. Programista pracuje na małych plikach, odwiedzający pobiera jeden.
279 pól i strona, która działa także bez nich
Klientka chciała edytować treść sama. Typowym rozwiązaniem byłby page builder, czyli dokładnie to, co rozjeżdża projekt graficzny po pierwszej zmianie. Wybraliśmy formularze w panelu oparte na Advanced Custom Fields Pro: 12 grup pól, po jednej zakładce na każdą sekcję strony, plus osobna strona ustawień dla elementów wspólnych.
- Każde pole ma wartość domyślną z projektu, więc przed pierwszą edycją strona wygląda dokładnie jak w Figmie
- Puste pole zdjęcia oznacza grafikę z projektu, a nie dziurę w układzie
- Definicje pól zapisane w kodzie motywu, a nie w bazie, więc są w repozytorium i przenoszą się razem ze stroną
- Strony z własnym układem otwierają się w panelu bez edytora blokowego, tylko z polami, żeby nie dało się niechcący rozbić layoutu
- Menu główne i dwie kolumny stopki zarządzane ze standardowego ekranu menu WordPressa
- Wspólna strona ustawień: kontakt, social media, przycisk konsultacji, sekcja opinii, stopka, strona 404, kody weryfikacyjne i analityka
Formularze edycji to wygoda, a nie warunek działania strony. Gdyby wtyczka kiedyś przestała działać albo wygasła licencja, strona pokazuje treści zapisane wcześniej albo domyślne z projektu, a dane kontaktowe i analityka wracają do standardowego ekranu WordPressa. Żadnej białej strony, żadnego rozsypanego układu.
Formularz, zgody i SEO bez wtyczek
Formularz kontaktowy, baner zgód na cookies i całe SEO napisaliśmy w motywie. Mniej wtyczek to mniej aktualizacji, mniej konfliktów i mniej miejsc, przez które ktoś może się włamać.
- Formularz z walidacją po stronie serwera, jednorazowym kluczem zabezpieczającym, pułapką na roboty i limitem pięciu wysyłek na godzinę z jednego adresu
- Komunikaty błędów czytane przez czytniki ekranu i klauzula informacyjna RODO przy polach
- Google Tag Manager z Consent Mode w wersji drugiej: analityka i marketing domyślnie wyłączone, przycisk „Odrzucam" tak samo widoczny jak „Akceptuję"
- Bez wpisanego identyfikatora kontenera nie ładuje się żaden skrypt śledzący ani baner
- Wysłany formularz i zapisana zgoda trafiają do warstwy danych jako zdarzenia gotowe do pomiaru
Wyszukiwarki i asystenci AI
Tytuł, opis, obraz do udostępnień, adres kanoniczny i wyłączenie z indeksu da się ustawić osobno dla każdej strony, wpisu, kategorii i tagu. Puste pola nie są błędem, tylko sygnałem dla motywu, żeby użył rozsądnej wartości domyślnej. Strona opisuje się wyszukiwarkom danymi strukturalnymi: jako witryna, jako osoba prowadząca zajęcia, z okruszkami nawigacji, artykułami bloga i sekcją pytań.
Osobno ustawiliśmy politykę dla botów AI. Asystenci, którzy cytują strony na żywo w odpowiedziach, mają wstęp. Roboty zbierające treści hurtowo do trenowania modeli są blokowane, bo teksty na stronie to autorski materiał klientki. Motyw generuje też plik llms.txt z opisem strony dla modeli językowych.
Dostępność i testy na każdej szerokości
Strona przeszła automatyczny audyt dostępności WCAG 2.2 na poziomie AA bez żadnego naruszenia. Do tego elementy, których automat nie sprawdzi: cele dotykowe o wielkości co najmniej 44 pikseli, widoczny fokus przy nawigacji klawiaturą, jeden nagłówek H1 na widok, sekcje opisane nagłówkami.
Test układu to skrypt, który otwiera każdą podstronę na pięciu szerokościach i sprawdza cztery rzeczy: czy strona nie przewija się w poziomie, czy wszystkie obrazy się wczytały, czy każdy ma opis alternatywny i wymiary oraz ile jest nagłówków H1. Uruchamialiśmy go po każdej większej zmianie, a nie raz przed oddaniem.
Technologie
PHP
Własny motyw klasyczny
CSS bez frameworka
JavaScript bez zależności
Advanced Custom Fields Pro
Figma REST API
Google Tag Manager
Consent Mode v2
Schema.org JSON-LD
WebP
axe-core
WP-CLI
Rezultaty
Czego ten projekt uczy
Gotowy projekt graficzny skraca drogę, ale jej nie kończy. Makieta pokazuje, jak strona ma wyglądać, a nie jak ma działać: co ze zdjęciem, którego klientka jeszcze nie ma, co z tabletem, którego nikt nie narysował, co z polityką prywatności, która opisuje cudzą firmę. Wierność projektowi to połowa pracy. Druga połowa to wszystko, czego w projekcie nie widać, a co odwiedzający i wyszukiwarka zauważą od razu.
Dlatego tak samo ważne jak odwzorowanie Figmy było to, że strona przetrwa pierwszą edycję treści. Pola z wartościami domyślnymi, układ zamknięty przed przypadkowym rozbiciem i działanie bez wtyczki sprawiają, że za rok strona nadal będzie wyglądać tak, jak ją zaprojektowano.
