Front-end development stron i systemów internetowych

Najpierw sprawdzamy projekt od strony technicznej

Makiety pokazują wygląd i podstawowe zachowanie interfejsu, ale nie zawsze wszystkie sytuacje, które pojawią się później w działającym serwisie.

Sprawdzamy więc m.in. zachowanie elementów na różnych szerokościach ekranu, dłuższe treści, wersje językowe, stany formularzy, brak danych czy sposób działania elementów interaktywnych.

Jeżeli UX/UI powstaje w CG2, frontend konsultujemy z projektantami jeszcze przed rozpoczęciem kodowania. Jeżeli dostajemy gotowy projekt od klienta lub innego zespołu, wskazujemy miejsca, które wymagają doprecyzowania.

Układamy frontend z komponentów

Nie kodujemy każdej podstrony jako osobnego widoku. Projekt dzielimy na elementy, które będą wielokrotnie wykorzystywane w serwisie: karty, teasery, galerie, formularze, nagłówki, listy czy bardziej rozbudowane sekcje.

Korzystamy przy tym z podejścia znanego z Atomic Design. Komponent ma określone warianty i zasady działania, dzięki czemu może być używany w różnych miejscach bez ponownego projektowania i pisania tego samego kodu.

Przy większych serwisach ma to znaczenie również kilka lat po uruchomieniu. Nowe podstrony i funkcje można budować na elementach, które już istnieją i zostały wcześniej sprawdzone.

Ten sam system komponentów przenosimy do Drupala

Na frontendzie się to nie kończy. Przy wdrożeniach w Drupalu przygotowujemy CMS tak, żeby redaktor mógł korzystać z przygotowanych komponentów podczas tworzenia kolejnych stron.

Element zaprojektowany w Figmie ma więc swój odpowiednik we frontendzie i sposób obsługi w CMS-ie. Redaktor może z dostępnych elementów układać całe widoki, łącząc np. sekcje tekstowe, galerie, listy, teasery, formularze czy komponenty przygotowane specjalnie dla danego projektu.

Nie oznacza to pełnej dowolności. Określamy warianty i zasady użycia komponentów tak, żeby nowe podstrony pozostawały spójne z projektem i identyfikacją wizualną serwisu.

W praktyce tworzymy więc jeden ciąg:

1. projekt UX/UI,
2. komponent frontendu,
3. komponent w Drupalu, 
4. podstrona budowana przez redaktora.

Dostępność powstaje razem z frontendem

Semantyczny HTML, obsługa klawiaturą, focus, formularze czy sposób działania elementów interaktywnych wynikają bezpośrednio z kodu frontendu.

Dlatego dostępności cyfrowej nie traktujemy jako zestawu poprawek wykonywanych po zakończeniu developmentu. Uwzględniamy ją podczas budowania poszczególnych komponentów i sprawdzamy ich działanie w trakcie prac.

Testujemy już podczas kodowania

Nie czekamy z testami do momentu, kiedy cały frontend jest gotowy. Poszczególne komponenty sprawdzamy na bieżąco podczas developmentu.

Korzystamy również z narzędzi wspieranych przez AI i testów automatycznych, które pomagają wychwytywać problemy z kodem, responsywnością, kompatybilnością oraz działaniem komponentów w różnych przeglądarkach. Dzięki temu część błędów poprawiamy od razu, zanim trafią do kolejnych etapów projektu.

Automatyzacja i AI wspierają pracę developera, ale nie zastępują sprawdzenia rzeczywistego zachowania interfejsu.

Sprawdzamy komponenty na prawdziwych treściach

Idealnie przygotowany tekst i zdjęcie z projektu nie pokazują, jak serwis będzie wyglądał po kilku miesiącach pracy redakcji.

Dlatego sprawdzamy komponenty także z dłuższymi tytułami, brakującymi zdjęciami, różną liczbą elementów, innymi proporcjami grafik czy treścią w kolejnych wersjach językowych.

Frontend powinien działać przewidywalnie nie tylko w dniu uruchomienia, ale również wtedy, gdy serwis jest później intensywnie rozwijany.