adaptive responsive web design ach te internety

Adaptive vs. Responsive Web Design

Nie wiem, jak u Was, ale w mojej karierze przewijało się tylko i wyłącznie pojęcie stron responsywnych. Natomiast hasło stron adaptacyjnych (NIE adaptywnych) widywałam tylko w nagłówkach branżowych artykułów. Zero praktycznego spojrzenia. Zero. Czemu?

Responsive web design
responsywny design

Celem projektowania responsywnego jest zbudowanie czytelnej oraz w pełni funkcjonalnej strony dla każdej szerokości ekranu. Zazwyczaj od 320px wzwyż aplikacja musi zarówno dobrze wyglądać, jak i działać.

Podstawowym założeniem responsywnego designu jest tzw. fluid layout. Oznacza to, iż projektujemy jedną wersję strony, której konstrukcja jest płynna – zmienia się w zależności od dostępnej przestrzeni. Osiągamy to za pomocą np. media queries, czy stylowania komponentów z wykorzystaniem jednostek procentowych.

Cała praca wyświetlenia odpowiedniego designu leży po stronie przeglądarki. To ona decyduje, które style zaaplikować w zależności od szerokości ekranu.

Zalety

  • Generalnie lepsze UX – design dopasowany do każdej szerokości ekranu.
  • RWD jest mniej czasochłonne i kosztowne niż AWD.
  • Łatwe utrzymanie kodu.
  • Strona RWD jest przyjazna dla SEO (posiada tylko jedną wersję).
  • Tona narzędzi sprzyjająca budowaniu stron responsywnych, np. flexbox, gridy (np. CSS Grid).

Wady

  • Strona może być wolniejsza ze względu na konieczność ładowania wszystkich, niekoniecznie potrzebnych stylów, zasobów.
  • Tracimy kontrolę nad wyglądem aplikacji na różnych szerokościach ekranu – projektant jest trochę zmuszony zaufać developerowi w kwestii zadbania o poprawne skalowanie i ułożenie elementów strony.
  • Trudniejsze zadanie programisty – dopilnowanie i poprawne obsłużenie każdej możliwej rozdzielczości.

Adaptive web design
adaptacyjny design

Legendy i mity donoszą, iż źródło tego pojęcia leży w metodyce budowania stron progressive enhancement (stopniowego ulepszania). O niej oraz o różnicach w stosunku do wdzięcznej degradacji pisałam już na blogu.

Aplikacje projektowane według zasad adaptacyjnych posiadają kilka wersji swojego layoutu – każdą dla ściśle określonej rozdzielczości (lub też bardzo wąskiego zakresu szerokości ekranu). Każdy projekt można określić jako layout fixed width. Programista buduje według nich kilka wersji strony. Następnie serwer na podstawie szerokości okna przeglądarki (lub innych parametrów, np. rodzaju urządzenia) decyduje, którą z nich wysłać klientowi. Jest w stanie zaserwować nie tylko odpowiednie pliki HTML, CSS, ale też zasoby, np. wysyłając obrazki wysokiej jakości iPadowi, gorszej – całej reszcie.

Spotkałam się z również z podejściem budowania jednej struktury HTML oraz kilku wersji stylów odpowiednich dla projektów. W takim przypadku serwer wysyła klientom wspólny HTML oraz dedykowany arkusz stylu dla odpowiedniej szerokości.

Zalety

  • Lepsze UX w kontekście urządzeń, dla których jest projektowana aplikacja.
  • Szybkość strony.
  • Gwarancja poprawnego zachowania na dedykowanych urządzeniach.

Wady

  • AWD jest bardziej czasochłonne i kosztowne niż RWD.
  • Strona posiada większe prawdopodobieństwo problemów z SEO (treść strony się powtarza na różnych jej wersjach).
  • Utrudniony proces utrzymania kodu i wprowadzania ewentualnych zmian.
  • Utrudniony proces testowania aplikacji.
  • Utrudnione tworzenie linków wewnętrznych.

RWD czy AWD?

Nie odpowiem Ci na to pytanie. Wszystko zależy od założeń projektowych.

Jeśli posiadasz stronkę, która dobrze wygląda desktopowo i nie chcesz diametralnie zmieniać jej wyglądu, Twoim celem jest tylko i wyłącznie dorobienie wersji mobilnej – idź w AWD. Po prostu zrób osobną wersję mobilną zamiast przepisywać aplikację od nowa.

Inny przypadek – budujesz aplikację od zera, klientowi zależy na optymalizacji, jest bogaty w dolary i szczodry w czasie, a Ty lubisz eksperymentować – również rozsądne wydaje się podejście adaptacyjne.

Kolejna sytuacja sprzyjająca AWD – PoC. Kiedy po prostu chcesz na szybko postawić jakąś w miarę dobrze wyglądającą stronę.

W każdym innym przypadku postawiłabym na design responsywny. Choć być może najlepszym pomysłem jest połączenie obu technik…

Kiedy myślę o moim doświadczeniu, nie jestem w stanie określić, z którego podejścia korzystaliśmy. W większości projektów, w jakich brałam udział, dostawałam od grafików projekty dla np. 3 różnych szerokości ekranu. W tym momencie lekko skłaniamy się w stronę podejścia adaptacyjnego. Jednak ostatecznie budowaliśmy jedną aplikację płynnie dostosowującą się do okna przeglądarki, co ewidentnie wskazywało na podejście responsywne. Nikt jednak nie zmóżdżał się nad poprawnym nazewnictwem. Każdy pracował w taki sposób, aby dostarczyć gotowy projekt w jak najkrótszym czasie, w jak najlepszym stanie. Kwestia adaptive vs responsive była najmniejszym naszym zmartwieniem. A skoro pojęcie stron responsywnych zadomowiło się w branży IT – oczywistym jest korzystanie z takiego słownictwa, które zrozumie każdy członek zespołu.

I taka właśnie jest moja subiektywna rada – porzucenie modnych haseł na rzecz wypracowania własnej techniki budowania aplikacji dostosowanej pod konkretny projekt.

Źródło: muzl.li, htmlpro.net, webroad.

Artykuły, które mogą Ci się spodobać...

Wpisz hasło, którego szukasz i naciśnij ENTER, aby je wyszukać. Naciśnij ESC, aby anulować.

Dawaj na górę