Dlaczego Responsive Web Design tak bardzo boli?

Do tej pory poruszono już tak wiele aspektów idei tworzenia stron internetowych w duchu Responsive Web Design, że można by przypuszczać, iż temat jest opracowany, zaprezentowany i przyswojony przez branżę, a co ważniejsze przez marki, które powinien on interesować szczególnie. I teoretycznie jest. Pozostał jednak co najmniej jeden aspekt praktyczny RWD, który leży mi na wątrobie.

Chodzi o proces pracy nad serwisem responsywnym. Zasadniczo różni się on zdecydowanie od znanych nam tradycyjnych procesów produkcji.

Otóż do tej pory mieliśmy sprawę dosyć prostą: koncepcja serwisu, struktura i makiety, potem grafika, jej akceptacja i pliki źródłowe grafiki wysyłane do developera. Klient zaangażowany na każdym etapie procesu, aktywnie nanoszący swoje uwagi, szczególnie w kontekście grafiki, akceptujący strona po stronie, projekt po projekcie, ikonka po ikonce, aż do szczęśliwej akceptacji.

I nagle wkracza Responsive Web Design. Jedni wiedzą i chcą, inni coś słyszeli, ale nie traktują go poważnie, jeszcze inni pierwsze słyszą.

Na tych, którzy podejmują rękawicę i próbują zlecić wdrożenie RWD czeka nie lada niespodzianka. I nie będę tutaj przynudzać o podejściu mobile first – to zdaje się już wszyscy wiedzą, że pracę nad serwisem najlepiej zacząć od mobile czyli od najmniejszego ekranu, aby dopisywać kolejne treści, a nie je ukrywać, jak w przypadku podejścia mobile last/desktop first. Chodzi mi raczej o drażliwą kwestię projektów do serwisu RWD.

Jeśli chcemy wykonać serwis RWD efektywnie, a rezultat końcowy ma “oszczędzać”  użytkownika Internetu mobilnego i ładować się bezproblemowo, odpuszczamy sobie projekt (w tym klasycznym rozumieniu pojęcia “projekt graficzny”). Serio – nie robimy grafik strona po stronie, bo efekt końcowy nie będzie ani zgodny z nimi, ani sensownie wyświetlany, ani ekonomiczny jeśli chodzi o wagę i szybkość ładowania. PSD dostarczone webdeveloperowi nie sprawdzi się.

Zamiast tego możemy zaproponować klientowi moodboard. I wierzcie mi zobaczycie zdzwinienie w jego oczach. Mooboard to najprościej rzecz ujmując taki worek z klockami, z których ma powstać statek kosmiczny, a patrząc na te kawałeczki zupełnie nie wiadomo, jak to będzie wyglądało. Trochę tak jest z moodboardem. Zbiera on do jednego worka ikony, które będą użyte na stronie, fonty tekstów i  nagłówków,  same boksy, główny motyw graficzny (key visual). Nie ma tu miejsca na skomplikowane motywy graficzne, projektowanie strona po stronie, przesuwanie krok po kroczku, a to w jedną a to w drugą (w ramach strategii pixel perfect). W RWD developer dostaje worek z klockami w postaci moodboarda oraz skalowalne makiety jako instrukcję i układa to wszystko w jedną, działającą już całość. Dopiero wtedy klient ma pełen obraz serwisu.

http://www.vanseodesign.com/web-design/style-guides-mood-boards-style-tiles/

http://wdim.desplechin.com/imd220.php

W tym kontekście praca nad serwisem RWD budzi wiele kontrowersji. Zamiast wiedzy o wyglądzie serwisu, dostajemy zbiór elementów graficznych i komplet skalowalnych makiet. Na makietach warto na moment się zatrzymać, gdyż prezentują one właściwe zachowanie serwisu i pokazują jak jego poszczególne elementy będą się układały. Oznacza to, że zwężając/rozszerzając okno przeglądarki z makietą, od razu widzimy, jak on się zachowuje. W przypadku tradycyjnych, statycznych makiet, nie mamy takiej możliwości. To duża zaleta procesu Mobile First RWD. Myślę, że może ona trochę osłodzić brak projektów graficznych.

Podsumowując już – po co właściwie to wszystko? Sprawa pierwsza – aby świadomie korzystać z zalet RWD, trzeba właściwie zrealizować proces produkcji w trybie mobile first. Jeśli RWD włożymy w stary proces, będzie ciężko i nieefektywnie, a zaprojektowany wcześniej efekt końcowy będzie trudny do osiągnięcia. Warto zatem poeksperymentować z modyfikacją proces – zaskoczenie co do sprawności wdrożenia może być bardzo pozytywne.