Responsive Web Design - okiem praktyka - NowyMarketing

Trochę terminologii

Responsive Web Design to termin ukuty przez Ethana Marcotte’a niecałe dwa lata temu w artykule „Responsive Web Design”. Wskazuje on, że serwis WWW stworzony został w taki sposób, który powoduje, że adaptuje się on do wielkości ekranu/urządzenia czy okna przeglądarki. Strona prezentuje się więc w różny sposób w zależności od szerokości (i rzadziej wysokości) wyżej wymienionych. Powinien to być sposób, który ułatwia czytanie zawartości, nawigację oraz ogranicza potrzebę powiększania/pomniejszania i przewijania.

RWD oznacza, że serwis został stworzony przy użyciu rozszerzenia @media dostępnego w CSS3. Koncepcjami powiązanymi z RWD są „Mobile First” i „Progressive Enhancement”. Pierwsza z nich mówi, żeby projektować serwis najpierw w wersji mobilnej. Druga, żeby wzbogacać layout/rozbudowywać go w miarę możliwości urządzenia (np. rozdzielczości) czy wspierania nowych standardów HTML/CSS3. Na smartfonie w pozycji pionowej, zaprezentujemy układ jednokolumnowy, na małym tablecie — dwukolumnowy, a na większych urządzeniach (czy też na ekranie komputera) dodamy kolejną kolumnę (trzecią). Ten sposób tworzenia serwisów ma, z mojego punktu widzenia, kolosalną zaletę — serwis taki jest gotowy na przyszłe urządzenia, o których dzisiaj nic nie wiem. Przykładowo pojawi się nowy tablet z całkowicie nową przeglądarką. W starym sposobie tworzenia serwisów musiałbym dodawać po stronie serwera urządzenie do listy urządzeń mobilnych o danych możliwościach. Łatwo o tym zapomnieć. W nowym sposobie — już jesteśmy na to gotowi. Urządzenia samo wybierze i dopasuje do siebie odpowiedni plik czy reguły CSS odpowiedzialne za wygląd strony WWW.

Zobacz również

Praktyka od strony projektanta, grafika i współpracy z klientami

RWD nakłada na projektanta i grafika dodatkowe obowiązki. Od początku trzeba pamiętać, że wygląd naszej strony będzie się zmieniał. Trzeba pomyśleć, co zmieniamy i jak. Czy też, co wyświetlamy, a co nie na małych urządzeniach. Dobrze też, by layout zakładał, że np. blok tekstu może mieć różne szerokości.

Trzeba też pokazać takie projekty klientowi i wytłumaczyć (co czasami jest wyzwaniem), że dany element strony może zmieniać swoją wielkość czy położenie. Jak widać, oznacza to dodatkową pracę i zmianę dotychczasowych sposobów projektowania funkcjonalności i wyglądu serwisu.

Z doświadczenia wiem, że dobrze jest skorzystać ze wspomnianych koncepcji „Mobile First” i „Progressive Enhancement”. To znaczy – najpierw pomyśleć i zaprojektować serwis mobilny, a potem go rozszerzać o dodatkowe funkcje czy inny sposób prezentacji np. galerii zdjęć.

#PrzeglądTygodnia [30.03-05.04]: marki na prima aprilis, prozwierzęce kampanie, moda kolejny raz spotkała się z kinem

Należy też pamiętać (to słowa do projektanta i grafika), że niektóre widgety (np. te facebookowe) nie zawsze pozwalają w łatwy sposób na zmianę wymiarów – elementy typu karuzele, zakładki, które wymagają JavaScriptu będą raczej musiały być przystosowane/przepisane na nowo, by obsłużyły zmieniające się wymiary elementów strony.

Słuchaj podcastu NowyMarketing

Praktyka od strony kodera HTML/CSS/JavaScript

Z mojego doświadczenia wynika, że koder powinien brać czynny udział w pracach (przynajmniej przy pierwszych projektach wykorzystujących RWD) już na etapie tworzenia szkiców stron.

By po pierwsze wiedział, jak zaplanować sobie prace, a po drugie — ważniejsze moim zdaniem — wskazał, że niektóre rozwiązania (wspomniane np. zakładki) wymagają większej ilości pracy i że można inaczej rozwiązać dany element nawigacyjny. Zdecydowanie ułatwia to i przyspiesza prace. A to właśnie na koderze spoczywa wdrożenie projektów i koder najbardziej odczuje ilość dodatkowych prac.

Łyżka dziegciu

Jak każda koncepcja i ta ma swoje wady czy też niedoskonałości. Najpoważniejszą jest wzrost transferu danych. Przykładowo obrazki będziemy przesyłać w największej możliwej wielkości, mimo użycia telefonu komórkowego do obejrzenia strony. Tak samo wzrosną (tu w mniejszym stopniu) wielkości plików CSS, JavaScript. A i plik HTML nie będzie optymalny – będzie zawierał wszystkie możliwe elementy, choć nie wszystkie mogą być w danej sytuacji wykorzystane (aczkolwiek można to obejść). I oczywiście trzeba pamiętać, że starsze wersje Internet Explorera (nadal popularne!) nie obsługują CSS3 i @media.