Content first

Jest wiele różnych podejść do responsywności czy wręcz ogólniej – tworzenia stron WWW. Jedni uważają, że należy zaczynać od projektowania na mniejsze viewporty (w domyśle: mobilne), a następnie na większe (w domyśle: desktopowe). Inni z kolei, że wręcz odwrotnie: zacząć od projektu na duże viewporty, a potem dostosować go na te mniejsze. Opinie ekspertów są od dawna podzielone. Dlatego oczywiście pozwolę dorzucić swoją, bo czemuż by nie.

Zacznijmy od tego, że uważam, iż o wiele właściwsze jest pierwsze podejście – czyli projektowanie od małych viewportów w kierunku tych większych. Z uwagi na to, że w tym podejściu poświęcamy uwagę urządzeniom mobilnym w pierwszej kolejności (bo one zwykle mają mniejsze viewporty), przyjęła ona nazwę mobile first (mobilne najpierw). I ma to sporo sensu, bo nie da się ukryć, że żyjemy w mocno mobilnym świecie, w którym desktopy często służą już wyłącznie do pracy. Większość czasu spędzanego w Sieci odbywa się na smartonach czy tabletach, które towarzyszą nam w wielu czynnościach życia codziennego. A skoro lwią część czasu spoglądamy w małe ekrany, wydaje się logiczne, że tym małym ekranom powinno poświęcać się więcej uwagi w procesie projektowania stron WWW.

Tylko taka narracja napotyka na pewien istotny problem. Sieć jest w pełni niezależna od urządzenia, na którym osoba użytkownicza ją przegląda. Nie da się przewidzieć, z jakiego urządzenia osoba użytkownicza skorzysta. Takie zgadywanie niekoniecznie przyniesie nam cokolwiek dobrego. Nie jest też specjalnie przyszłościowe, bo nowych urządzeń powstaje bez liku i po prostu nie da się nad nimi nadążyć. Dlatego warto przesunąć nieco akcent w myśleniu. Zadajmy sobie proste pytanie: co jest najważniejszą częścią strony WWW?

Odpowiedź wydaje się dość oczywista: treść. Na najbardziej podstawowym poziomie strona WWW to taki dokument Worda. Też formatujemy tekst, aby był bardziej czytelny dla osoby użytkowniczej. I to od tego, co chcemy przekazać, zależy, jak strona będzie wyglądać. Dlatego projekt warto zacząć od rozplanowania treści i tego, jak ją można przedstawić. A równocześnie: treść to wciąż przede wszystkim tekst, często z dodatkiem multimediów. Na tym najbardziej podstawowym poziomie to właśnie tekst narzuca nam takie fundamentalne ramy designu.

Niejako naturalnym ogranicznikiem dla tekstu jest optymalna długość linii. Najlepsze praktyki wspominają obecnie, że powinna ona wynosić mniej więcej od 60 do 80 znaków. Można zatem przyjąć, że nasza treść nie powinna przekraczać takiej szerokości, bo inaczej staje się mniej czytelna. Ale nie sposób nie zauważyć, że obecnie ekrany często są zdecydowanie szersze niż te 60-80 znaków i można na nich zamieścić zdecydowanie więcej rzeczy. Więc skoro nasz ekran ma szerokość 100 znaków, to być może obok głównej treści da się dołożyć jakąś prostą nawigację. Jak ma 160 znaków, to z drugiej strony mogą się pojawić np. odnośniki do źródeł, na które powołujemy się w artykule. Jeśli ekran jest mały na tyle, że mieści się tylko tekst, to wówczas wszystkie te elementy będą wyświetlane w kolumnie, jeden po drugim.

Naszym punktem odniesienia przestaje być wielkość samego viewportu, a staje się nim to, ile miejsca mamy wokół treści. Tym samym przesuwamy się z obszaru mobile first, które już samą nazwą sugeruje, na czym się skupia, a przechodzimy do obszaru content first (treść najpierw). Niby nie jest to wielka zmiana, ale mimo wszystko dość mocno wpływa na sposób, w jaki myśli się o designie. Przy podejściu mobile first myślimy o tym, że mamy mały ekran urządzenia i trzeba tam wszystko zmieścić. Przy podejściu content first – mamy treść, która ma mniej więcej zawsze tę samą szerokość. I myślimy, jak tą treść ubogacić, żeby jak najlepiej służyła osobie użytkowniczej. Przechodzimy od myślenia o pewnym ograniczeniu do myślenia o sposobie ulepszania.

Uważam też, że taka zmiana podejścia pozwala ominąć znane problemy z podejściem mobile first, a więc m.in. “rozlazłość” treści na dużych viewportach. Bo koncentrujemy się na tym, żeby to właśnie treść była zawsze najważniejszym elementem strony i to design dostosowuje się do niej, ulepsza ją, nie zaś – odwrotnie.

No i jeszcze jedna kwestia na koniec: pod względem technicznym content first praktycznie niczym nie różni się od mobile first. Bo jest to tak naprawdę lekkie przesunięcie myślenia na poziomie projektowym. A to, w jaki sposób następnie zostanie to przeniesione na faktyczny kod, jest sprawą całkowicie drugorzędną. Coraz częściej podnoszą się głosy, że mobile/content first jest dobrym podejściem projektowym, ale niekoniecznie sensownym technicznie. Stąd też propozycje rozwiązań, takich jak Generic First CSS. W dużym skrócie polega on na podawaniu jako domyślnych stylów całkowicie niezależnych od viewportu. Natomiast style, które od tego viewportu zależą, są zamknięte w odpowiednim media query, które wskazuje zarówno na minimalną, jak i maksymalną szerokość viewportu (takie breakpointy na sterydach):

.card {
    border-radius: 5px;
    padding: 1rem;
}

@media screen and ( min-width: 60rem ) and ( max-width: 100rem ) {
    .card {
        width: 50%;
    }
}

@media screen and ( min-width: 100rem ) and ( max-width: 150rem ) {
    .card {
        width: 20%;
    }
}

Takie podejście otwiera ciekawe możliwości. Wyobrażam sobie narzędzie, które jest w stanie wyciągać takie media queries i robić z nich osobne arkusze stylów. To pozwalałoby przeglądarce priorytetyzować tylko te arkusze stylów, których aktualnie potrzebuje, a resztę dociągać w tle:

<link rel="stylesheet" href="generic.css">
<link rel="stylesheet" href="60rem-100rem.css" media="(min-width: 60rem) and (max-width: 100rem)">
<link rel="stylesheet" href="101rem-150rem.css" media="(min-width: 101rem) and (max-width: 150rem)">

Zatem: na poziomie projektowym warto wykorzystywać mobile first, ale skupione przede wszystkim na treści, nie na viewporcie (czyli content first), a na poziomie CSS-a – być może sprawdzić rozwiązania pokroju Generic CSS.

Źródła

Dodatkowe materiały