Przez lata tworzenia stron internetowych bardzo często słyszałem jedno zdanie:

„Musi wyglądać dokładnie tak jak projekt”.

I oczywiście jest w tym sporo racji. Dobry projekt graficzny jest bardzo ważny. Użytkownik nie widzi naszego kodu, frameworka ani architektury aplikacji. Widzi tylko efekt końcowy.

Problem zaczyna się wtedy, gdy próbujemy traktować stronę internetową jak nieruchomy obrazek.

Bo strona internetowa nie jest grafiką.

To żywy system, który musi działać w różnych warunkach.

Projekt w Figmie to tylko jeden przypadek

Grafik zazwyczaj przygotowuje widok dla konkretnego scenariusza:

• określona szerokość ekranu,
• przykładowe teksty,
• konkretna liczba elementów,
• jeden język,
• jeden typ urządzenia.

W rzeczywistości użytkownik może wejść na stronę:

• z telefonu,
• z dużego monitora,
• z powiększoną czcionką,
• z dłuższym tytułem,
• z inną ilością danych.

I tutaj zaczyna się prawdziwe życie aplikacji.

Jeżeli cały projekt opiera się na tym, że wszystko ma znajdować się dokładnie w jednym miejscu, bardzo szybko pojawiają się problemy.

CSS nie służy do rysowania obrazków

Jednym z powodów popularności podejścia pixel perfect było traktowanie CSS jako narzędzia do odtwarzania projektu.

Efekt?

Dużo takich fragmentów:

margin-left: 13px;
top: -4px;
transform: translateX(2px);

Oczywiście czasami takie poprawki są potrzebne. Każdy frontend developer je zna.

Problem pojawia się wtedy, gdy cała strona jest zbudowana z takich wyjątków.

Po kilku miesiącach nikt już nie wie:

• dlaczego ten element ma margin-top: 17px,
• co się stanie po zmianie fontu,
• czy można usunąć tę klasę.

Dobry kod CSS powinien opisywać zasady, a nie przypadkowe przesunięcia.

Najpierw struktura, potem detale

Dużo łatwiej rozwijać stronę, kiedy zaczynamy od odpowiedzi na pytania:

• jaka jest hierarchia informacji?
• które elementy są podobne?
• jakie komponenty będą używane ponownie?
• jak strona zachowa się na małym ekranie?

Przykładowo karta produktu w sklepie internetowym nie powinna być projektowana tylko na stronie głównej.

Ta sama karta może pojawić się:

• w wynikach wyszukiwania,
• w rekomendacjach,
• w kategorii,
• na urządzeniu mobilnym.

Jeżeli działa tylko w jednym miejscu, to nie jest dobrym komponentem.

Responsywność nie powinna być poprawką na końcu

Jeszcze kilka lat temu często wyglądało to tak:

1. Projektujemy desktop.
2. Kodujemy desktop.
3. Na końcu próbujemy zrobić wersję mobilną.

Dzisiaj takie podejście coraz częściej powoduje problemy.

Telefon nie jest „pomniejszoną wersją komputera”.

To inne środowisko.

Dlatego warto od początku korzystać z możliwości CSS:

• Flexbox,
• CSS Grid,
• clamp(),
• zmienne CSS,
• jednostki względne,
• Container Queries.

Przykład:

h1 {
    font-size: clamp(2rem, 5vw, 4rem);
}

Zamiast tworzyć kilka osobnych wersji nagłówka, pozwalamy mu naturalnie dopasować się do ekranu.

Projekt nigdy nie zna całej przyszłości

Jednym z największych wyzwań podczas tworzenia stron i aplikacji jest to, że projekt graficzny zazwyczaj powstaje na podstawie przykładowych danych.

Problem w tym, że w prawdziwych aplikacjach treści często nie są tworzone przez programistów ani projektantów.

W wielu systemach, które tworzę, dane wprowadzają później sami użytkownicy lub klienci aplikacji:

• dodają własne ogłoszenia,
• tworzą artykuły lub wpisy blogowe,
• wpisują nazwy firm,
• uzupełniają opisy,
• dodają zdjęcia i materiały.

Nie mamy pełnej kontroli nad tym, jak długa będzie treść ani jakie dane pojawią się w systemie.

Przykładowy tytuł w projekcie może mieć dwie linijki, ale rzeczywisty użytkownik może wpisać tekst trzy razy dłuższy. Nazwa produktu może być krótka, ale klient może potrzebować dodać dodatkowe informacje. Zdjęcie może mieć inny format niż zakładaliśmy.

I właśnie w takich sytuacjach widać różnicę między stroną zaprojektowaną jako nieruchomy obrazek a stroną zbudowaną jako elastyczny system.

Dobry frontend nie zakłada, że wszystko będzie idealne. Zakłada, że dane mogą być różne i przygotowuje się na takie sytuacje.

Dlatego czasami lepszym rozwiązaniem jest pozwolić elementowi zwiększyć wysokość, zawinąć tekst albo zmienić układ, zamiast na siłę utrzymywać dokładny wygląd z projektu.

Czy pixel perfect jest złym podejściem?

Nie.

Są miejsca, gdzie dokładność ma ogromne znaczenie:

• strony marketingowe,
• animacje,
• specjalne efekty wizualne,
• aplikacje wymagające bardzo precyzyjnego interfejsu.

Ale w większości projektów biznesowych ważniejsze są:

• szybkość działania,
• łatwość utrzymania,
• dostępność,
• możliwość rozwoju.

Strona, którą można łatwo zmienić za rok, jest często lepsza niż taka, która dzisiaj wygląda idealnie, ale każda zmiana wymaga walki z CSS.

Nowoczesny frontend to kompromis

Dobra współpraca między grafikiem i programistą nie polega na tym, aby programista był maszyną kopiującą piksele.

Najlepszy efekt powstaje wtedy, gdy obie strony rozumieją swoje cele.

Grafik dostarcza:

• estetykę,
• hierarchię,
• spójność wizualną.

Programista dba o:

• działanie,
• elastyczność,
• wydajność,
• możliwość rozbudowy.

Bo dobra strona internetowa nie jest obrazkiem.

Jest systemem, który musi działać dzisiaj, jutro i za kilka lat.

Dlatego coraz częściej zamiast pytać:

„Czy wszystko jest przesunięte dokładnie o 1 piksel?”

warto zapytać:

„Czy ta strona nadal będzie dobra, gdy rzeczywistość nie będzie idealna?”