Responsive Web Design

Responsive Web Design (RWD), Responsywny Web Design, ma już niemal 15 lat. Zaczęło się od artykułu Ethana Marcotte’a na A List Apart. Marcotte opisał, w jaki sposób można wykorzystać media queries do dostosowania strony pod wielkość viewportu urządzenia. Dzisiaj można się zastanawiać, czy to był hack, ale jedno jest pewne i niezaprzeczalne: RWD zmieniło oblicze Sieci. I to na lepsze.

A wszystko zaczęło się od dwoch prostych założeń: strona WWW nie musi wyglądać tak samo w każdej przeglądarce oraz Sieć jest całkowicie niezależna od urządzenia. Nie były to bynajmniej aż tak przewrotowe stwierdzenia. Środowisko skupione wokół Progressive Enhancement wszak postulowało podobne podejście: funkcjonalność strony powinna być uzależniona od możliwości technologicznych urządzenia osoby użytkowniczej. RWD przenosiło tę ideę w inny kontekst – designu i warstwy prezentacji strony WWW. Oraz pokazywało, jak można ten problem ugryźć od strony technicznej.

Viewport

Zacznijmy od viewportu, bo bez niego trudno zrozumieć, czemu RWD był aż tak przełomowy.

Gdy pojęcie RWD dopiero wchodziło do repertuaru narzędzi osoby webdeveloperskiej, dotyczyło pisania stron w taki sposób, by działały dobrze na różnych urządzeniach. W domyśle: zarówno na urządzeniach stacjonarnych, jak i mobilnych. Popularnym uproszczeniem tematu było twierdzenie, że jest to dostosowywanie strony do różnych wielkości ekranów. Jednak w rzeczywistości chodziło o różne wielkości viewportów. Na polski to słowo najłatwiej przetłumaczyć jako “obszar wyświetlania”. I choć na pierwszy rzut oka brzmi to jak ekran, to często te dwie rzeczy nie są ze sobą tożsame.

Obszar wyświetlania to, w największym uproszczeniu, fragment strony (lub jej całość, jeśli się mieści), który jest w danym momencie widoczny w oknie przeglądarki. Do viewportu nie wlicza się wszelkich elementów interfejsu przeglądarki – paska adresu, pasków przewijania, paska z kartami itp. W przypadku urządzeń mobilnych, na których przeglądarka zwykle zajmuje cały ekran, dodatkowo trzeba doliczyć elementy interfejsu samego systemu operacyjnego (np. pasek powiadomień na samej górze).

Weźmy na tapet prosty przykład – moją stronę domową otwartą na moim telefonie:

Strona Comandeer.pl otwarta na telefonie – na górze ekranu znajduje się systemowy pasek powiadomień, poniżej pasek adresu przeglądarki, niżej sama strona internetowa, a na samym dole systemowy pasek nawigacyjny.

Zakreskujmy teraz wszystkie elementy, które nie wchodzą w skład obszaru wyświetlania:

Strona Comandeer.pl otwarta na telefonie – na górze ekranu znajduje się zakreskowany systemowy pasek powiadomień, poniżej zakreskowany pasek adresu przeglądarki, niżej sama strona internetowa, a na samym dole zakreskowany systemowy pasek nawigacyjny.

Żeby jeszcze bardziej skomplikować sprawę, obszar wyświetlania może się dynamicznie zmieniać i to z wielu różnych powodów, takich jak:

Stąd zaistniała potrzeba reagowania na takie zmiany. Na szczęście CSS umożliwia to przy pomocy media queries, a i w JS-ie istnieją odpowiedniki.

Ale to przecież wciąż nie wszystko! Tradycyjnie przyjmuje się, że ekrany (a co za tym – także viewporty) są prostokątne. Niemniej to nie musi być zawsze prawda. Obecnie istnieje niezwykle szeroka gama urządzeń, z których część nie ma prostokątnych ekranów (np. Apple Watch), ma więcej niż jeden ekran, ale tak w sumie nie do końca (składane smartfony), albo wprowadza pewne odstępstwa od idealnego prostokąta (niesławny notch). To wymusza odejście od klasycznego podejścia opartego na breakpointach na rzecz bardziej płynnych rozwiązań, ponieważ wielkości viewportów są coraz mniej ustandaryzowane.

Równocześnie powoli odchodzi się od rozumienia RWD jako dostosowywania wyłącznie pod różne viewporty. Te wciąż pełnią istotną funkcję, ale coraz większy nacisk kładzie się na funkcje poszczególnych urządzeń. Dopiero połączenie tych dwóch podejść pozwala tworzyć w pełni responsywne strony.

Media queries

Media queries, czyli po polsku zapytania medialne – której to nazwy chyba nigdy nie słyszałem na żywo. Przez lata były najważniejszym elementem RWD. Wszak na początku responsywność w dużej mierze opierała się na dostosowywaniu strony wyłącznie do wielkości viewportu i w tym media queries – na lata przed sensownymi systemami layoutu – naprawdę błyszczały. Ale mamy 2024 rok, responsywny krajobraz nieco się jednak zmienił. Viewport nie jest już głównym wyznacznikiem responsywności. Ta coraz częściej przenosi się na poziom poszczególnych komponentów. Coraz więcej rzeczy można załatwić proporcjami. A zastosowanie założeń IWD i nowoczesnych systemów layoutu sprawia, że media queries zostały zepchnięte w dużej mierze do wyrażania _prawdziwych_ breakpointów.

A równocześnie – nowe wcielenie media queries pozwala reagować na zdecydowanie więcej niż tylko wielkość viewportu. Co więcej, sporo z nowych typów media queries jest skupiona na preferencjach osoby użytkowniczej dotyczących dostępności. Możemy m.in. wykryć, czy osoba użytkownicza chce ograniczenia ruchu na stronie (prefers-reduced-motion), preferuje jasny czy ciemny motyw (prefers-color-scheme), nie chce przezroczystych elementów (prefers-reduced-transparency), ale też – czy korzysta z precyzyjnego urządzenia wskazującego (pointer) oraz czy ma włączony tryb wysokiego kontrastu (forced-colors). Trzeba przy tym pamiętać, że tego typu media queries mogą czasami wprowadzać w błąd. Dlatego warto dać osobie użytkowniczej możliwość nadpisania ustawień na stronie, np. przy pomocy przełącznika, który pozwala w każdej chwili przełączyć z trybu jasnego na ciemny. Automatyczne wykrywanie ustawień jest fajne tak długo, jak działa. Kiedy przestaje, osoba użytkownicza musi mieć szansę naprawić nasz błąd.

Multimedia

Innym nierozerwalnym elementem responsywności są multimedia. O responsywnych obrazkach mówi się już od lat, powstały nawet najlepsze praktyki wokół nich. Warto więc jedynie przypomnieć, że istnieją dwa podstawowe sposoby wstawiania responsywnych obrazków:

To, jaki sposób wybrać, bardzo zależy od konkretnego przypadku, np. jeśli chcemy serwować ten sam obrazek, ale w różnym rozmiarze w zależności od viewportu czy gęstości pikseli urządzenia, wtedy [srcset] jest wygodniejszym rozwiązaniem. Ale jeśli chcemy serwować zupełnie różne obrazki w zależności od dowolnego media query, to wówczas trzeba zastosować picture. I oczywiście można tworzyć potworki łączące obydwie te metody wyboru obrazków:

<picture>
    <source media="( prefers-color-scheme: light )" srcset="light-small.jpg, light-big.jpg 2x" />
    <source media="( prefers-color-scheme: dark )" srcset="dark-small.jpg, dark-big 2x" />
    <img src="light-small.jpg" alt="Jakiś tam obrazek." />
</picture>

Element picture przydaje się również, gdy serwujemy obrazek w kilku formatach – tak, aby zapewnić najlepsze wsparcie dla przeglądarek:

<picture>
    <source srcset="ja-w-czapce.avif" type="image/avif">
    <source srcset="ja-w-czapce.webp" type="image/webp">
    <img src="ja-w-czapce.jpg" alt="Ja w ciepłej i przyjemnej wełnianej czapce.">
</picture>

Responsywne obrazki przy okazji bardzo mocno zahaczają o temat wydajności. Źle użyte mogą znacząco negatywnie na nią wpłynąć.

Oprócz obrazków do możliwości urządzenia powinny dostosowywać się również materiały video. Ostatnio w tej materii platforma sieciowa mocno podgoniła i w końcu responsywne filmiki stały się tak proste jak obrazki!

<video>
    <source src="large.webm" media="(min-width: 1000px)">
    <source src="small.webm">
</video>

Warto przy tym pamiętać, że przeglądarka wybierze filmik wskazywany przez pierwszy element source, który spełnia warunki. Dlatego, jeśli stosujemy media queries z min-width, należy odwrócić kolejność: na samej górze umieścić największe filmiki, a na samym dole – ten bez żadnego media query. Tym sposobem przeglądarka będzie je sprawdzać po kolei, aż trafi na ten, którego atrybut [media] pasuje do ustawień urządzenia. W odwrotnym przypadku zawsze wybrany zostałby filmik bez media query – bo pasuje do każdego urządzenia.

Typografia

Wydaje mi się, że przez wiele lat ten aspekt responsywności był mocno zaniedbywany, a przecież jest jednym z ważniejszych. Ba, pod pewnym względem wręcz najważniejszym – nie da się dostarczyć czytelnej treści na każde urządzenie, jeśli nie zadbamy o to, by font był czytelny! Przez lata dobre praktyki dotyczyły głównie szerokości linii, a wielkość fonta sprowadzała się raczej do konstatacji, że “nie powinna być mniejsza od x”, gdzie “x” najczęściej wynosiło ok. 16 pikseli. Aż w końcu doszło do przełomu i obecnie coraz częściej mówi się o tym, że wielkość fonta powinna się skalować wraz z viewportem urządzenia. Istnieje kilka sposobów na zrobienie tego. Najprostszym jest po prostu podbicie wielkości fonta przy pomocy media queries:

@media screen and ( min-width: 768px ) {
    html {
        font-size: 110%;
    }
}

W tym przypadku dla viewportów równych i szerszych od 768 pikseli podbijamy wielkość fonta o 10%. To najprostsza metoda na zapewnienie responsywności wielkości fonta, ale też – najmniej spektakularna. Font tak naprawdę będzie zmieniał się “skokowo”, jedynie w określonych przez osobę webdeveloperską breakpointach. Obecnie coraz częściej stosuje się rozwiązania, które dodają do wielkości fonta jednostkę zależną od viewportu (np. vw), dzięki czemu ta skaluje się płynnie wraz ze zmianą wielkości viewportu. Przykładem takiego rozwiązania może być Utopia.

Spektrum urządzeń

Choć RWD przeszło już sporą ewolucję i niemal w niczym nie przypomina swojej pierwotnej formy, pewne przekonanie trzyma się dość mocno i od czasu do czasu się na nie natykam. A jest to pogląd, że RWD służy przystosowywaniu stron i aplikacji sieciowych do urządzeń mobilnych. Jest to jednak założenie zgoła błędne. W końcu to RWD, nie MRWD. Responsywność powinna dotyczyć **wszystkich urządzeń**, nie zaś – tylko szczęśliwych wybrańców.

Przyznaję, nazewnictwo niespecjalnie tutaj pomaga. Mamy wszakże technikę mobile first, która dość mocno sugeruje, jaki jest jej priorytet. Ale już dogłębniejsze wczytanie się w jej definicję pokazuje, że prawda jest nieco inna:

The rationale behind the mobile-first approach is to provide users with good user experiences at all screen sizes—by starting with creating a user experience that works well on small screens, and then building on top of that to further enrich the user experience as the screen size increases.

[Założeniem stojącym za podejściem mobile first jest zapewnienie dobrego doświadczenia użytkownikom ekranów o dowolnych rozmiarach – co uzyskuje się przez dostarczenie dobrego doświadczenia na małych ekranach, a następnie, rozbudowując to doświadczenie, także na większych ekranach.]

Urządzenia mobilne nie są zatem celem w podejściu mobile first, raczej po prostu środkiem do jego osiągnięcia. A tym jest zapewnienie responsywności dla osób używających dowolnego urządzenia. Responsywność dotyczy zarówno osoby używającej smartfona, jak i gigantycznego, ściennego telewizora 4K. Choć potrzeby tych dwóch osób są diametralnie różne, tak mają wspólny mianownik: trzeba je spełnić. A zatem zadbać o to, żeby strona była jak najbardziej responsywna.

Do wyboru, do koloru

W 2023 roku niemal nie sposób przewidzieć, z jakiego urządzenia skorzysta użytkownik naszej aplikacji. Nawet próba zawężenia problemu do kilku grup urządzeń (takich jak laptopy, tablety i smartfony) nie rozwiązuje problemu. Ot, weźmy laptopy. Gdy porównamy 13-calowego malucha z jakimś 17-calowym gamingowym monstrum z ekranem superhiperultrawow o rozdzielczości 4K, to już widać, że zapewnienie responsywności dla jednego i drugiego wiązać się będzie z nieco innymi wyzwaniami. A przecież ekrany mogą mieć choćby różną gęstość pikseli (na ciebie patrzę, Retina), która też wpłynie na to, jak duży ostatecznie będzie viewport przeglądarki, albo na dobór grafik. Zresztą takie laptopy nie muszą się różnić tylko wielkością ekranu. Są od dość dawna na rynku laptopty, które wyposażone są w ekrany dotykowe. Czy zatem laptop, z którego ktoś właśnie korzysta w trybie dotykowym, nie powinien dostać ułatwień przeznaczonych na urządzenia dotykowe? A już zostawiając te nieszczęsne laptopy – ze smartfonami nie jest lepiej. Setki różnych wielkości ekranów, podwójne i składane wyświetlacze, dynamiczne wyspy, notche… Nie wspominając już o tym, jak wciąż dużo na rynku jest starych i słabych telefonów. Za rogiem za to czają się jeszcze tablety, smartwatche, inne urządzenia z nieprostokątnym ekranem, konsole przenośne (takie jak Steam Deck), konsole stacjonarne, smart TV (w końcu często mają wbudowane przeglądarki internetowe!), urządzenia VR i AR (jak Apple Vision Pro)… Praktycznie codziennie wychodzi jakieś nowe urządzenie. I jest tego tak dużo, że po prostu fizycznie niemożliwe jest tworzenie stron pod urządzenia.

RWD a urządzenia mobilne

Obecnie coraz częściej można usłyszeć głosy, że RWD się nie sprawdziło, czy wręcz powinniśmy odejść od niego na rzecz czegoś nowego. Bierze się to z poczucia, że responsywność została sprowadzona wyłącznie do dbania o urządzenia mobilne, które dodatkowo zostały uproszczone wyłącznie do “komputerów z małymi ekranami”. A przecież nie jest to prawda. Urządzenia mobilne dostarczają całkowicie inne doświadczenie osobie użytkowniczej niż urządzenia desktopowe.

Jednym z najważniejszym czynników różnicujących jest ekran dotykowy. Podczas gdy komputery mają klawiatury i najczęściej myszki lub inne urządzenia wskazujące, w przypadku urządzeń mobilnych te funkcje najczęściej pełni ekran dotykowy. Klawiatura jest wyświetlana na nim w formie nakładki, zamiast myszki “klika” się elementy na ekranie palcem, itd. To pociąga za sobą zupełnie inne wyzwania projektowe. Jednym z nich jest m.in. dostosowanie metod nawigacji do obsługi dłonią. Wszystkie najważniejsze elementy interfejsu powinny być – dosłownie – na wyciągnięcie ręki czy wręcz palca. Najważniejszym urządzeniem wskazującym staje się często kciuk, który musi mieć możliwość dostania się do przycisków i innych interaktywnych elementów strony.

Mapa stref kciuka na modelu telefonu Pixel 4: lewy górny róg oraz prawy górny róg są strefami trudno dostępnymi dla kciuka, prawy górny róg oraz większość środka i dołu ekranu jest niewygodna w dostępie, natomiast strefą wygodną jest obszar wyznaczony przez półokrągły ruch kciuka po ekranie w momencie, gdy trzyma się go pionowo w prawej ręce.
Strefy kciuka dla telefonu używanego prawą dłonią.
Źródło: Addy Osmani, Modern Touch-Friendly Design, (data dostępu: 8.06.2023), w: Addy Osmani, AddyOsmani.com, (data dostępu: 14.06.2023).

Responsywność na ekranach dotykowych powiązana jest też z zapewnieniem odpowiednio dużych obszarów klikalnych (dotykowych). W końcu palce są zdecydowanie  mniej precyzyjnymi urządzeniami wskazującymi niż myszka czy touchpad.

Dochodzą tutaj kwestie związane także z samym urządzeniem. Wraz z pojawieniem się iPhone’ów z notchami, nie można już dłużej zakładać, że ekran telefonu to idealny prostokąt. W niektórych miejscach mogą pojawiać się niespotykane przeszkody, na które trzeba jakoś reagować. Dlatego zdecydowanie lepiej jest projektować nie pod urządzenia mobilne, a pod możliwości konkretnego urządzenia. Zwłaszcza, że współczesne media queries dają nam takie możliwości.

IWD

Intrinsic Web Design (IWD) – Natywny Web Design to termin zaproponowany przez Jen Simmons. U jego podstaw leży założenie, że współczesny CSS dostarcza nam możliwości, które pozwalają tworzyć w pełni responsywne rozwiązania bez potrzeby używania haków. Nowoczesne systemy layoutowe dają nam możliwość tworzenia designów, które naturalnie dostosowują się do przeglądarki, w jakiej będą wyświetlane. Nie trzeba tak naprawdę stosować media queries (przynajmniej nie do dostosowywania layoutu), przeglądarka zrobi wszystko za nas. My po prostu ustalamy, jak chcemy, żeby layout wyglądał i… to w sumie tyle.

Dzięki współczesnemu CSS-owi mamy możliwość dowolnego mieszania elementów o płynnych i sztywnych rozmiarach, tworzenia wieloosiowych layoutów (które układają się zarówno w rzędach, jak i kolumnach), które same się rozszerzają i zwężają w zależności od dostępnego miejsca czy wręcz zmieniają z układu poziomego na pionowy.

To po prostu responsywny design na sterydach.

Prawdziwa responsywność

Żyjemy w dobie silnej komponentyzacji frontendu. Nie myśli się już o stronach jako o monolitach, ale o zbiorach niezależnych, współpracujących ze sobą komponentów. To ma swoje odzwierciedlenie zarówno w tym, jak projektowane są aplikacje (design systemy), jak i w tym, jak są następnie wdrażane (współczesne frameworki JS-owe). Responsywność też musiała się do tego dostosować. W sukurs przyszły tutaj nowe możliwości CSS-a, które pozwoliły na przejście od responsywności w relacji do viewportu do resposywności w  relacji do komponentu. Równocześnie mały renesans przeżywa Progressive Enhancement, a na horyzoncie majaczy deklaratywny design, pod który podwaliny położyło IWD. Być może Sieć skręca w alejkę, w której to osoba użytkownicza za pośrednictwem swojej przeglądarki decyduje o tym, jak wygląda jej Sieć.

Bo ostatecznie responsywność to umiejętność dostosowywania się do sytuacji w oparciu o dane, które posiadamy, oraz oddanie jak największej kontroli osobie użytkowniczej. Snucie domysłów najczęściej nie działa i bardzo szybko się zbłaźnimy. A, jak wiadomo, dobre wrażenie można zrobić tylko raz.

Źródła

Dodatkowe materiały