Koncepcja RWD – jak myśleć responsywnie podczas projektowania

Wiele zostało napisane i powiedziane na tem­at Respon­sive Web Design, czyli o sposo­bie tworzenia stron inter­ne­towych, które są dostęp­ne, dobrze się wyświ­et­la­ją i są poprawnie obsługi­wane na każdym urządze­niu, pod różny­mi rozdziel­czoś­ci­a­mi ekranów. W sieci jest wiele infor­ma­cji na tem­at konkret­nych rozwiązań, przykładów, wskazówek pro­jek­towych, zarówno tych mniej jak i bardziej tech­nicznych.

W tym artykule, na pod­staw­ie obserwacji oraz dostęp­nych infor­ma­cji, chci­ałam przy­bliżyć ideę RWD i skupić się na ciekawym, nietech­nicznym pode­jś­ciu do pro­jek­towa­nia. Nie będę kon­cen­trować się na konkret­nych rozwiąza­ni­ach, ale na nastaw­ie­niu jakie powin­niśmy mieć, kiedy pod­chodz­imy do tem­atu „respon­sive web desing”.

Poniżej, słowem wstępu, lista kilku prob­lemów, które może rozwiązać respon­sy­w­na strona inter­ne­towa:

  • trudne do przewidzenia rodza­je urządzeń, z których będą korzys­tać użytkown­i­cy,
  • brak szty­wnych ograniczeń co do rozdziel­czoś­ci ekranu, na jaką powin­no się zwracać uwagę pod­czas pro­jek­towa­nia,
  • brak wiedzy na tem­at tego, na jakim urządze­niu, w jakiej sytu­acji i jakich infor­ma­cji będzie szukać użytkown­ik (jeden użytkown­ik = wiele urządzeń = wiele kon­tek­stów uży­cia).

Jak można rozumieć Responsive Web Design?

Należy tutaj zaz­naczyć, że RWD jest to idea, kon­cepc­ja, sposób pro­jek­towa­nia. Ważne w definicji jest pier­wsze słowo „Respon­sive” (z ang. czuły, wrażli­wy). Trak­tu­jmy to więc jako tworze­nie pro­jek­tu, który jest wrażli­wy na swo­je otocze­nie (otocze­niem pro­jek­tu w tym wypad­ku jest urządze­nie, na którym jest wyświ­et­lane).

W myśl kon­cepcji, którą chcę przed­staw­ić, należy „zapom­nieć” o urządzeni­ach. A już na pewno nie powin­ny być one najważniejszym aspek­tem branym pod uwagę pod­czas pro­jek­towa­nia.

Dlaczego właśnie takie podejście?

Tak jak pisałam wcześniej, nie wiemy z jakich urządzeń będzie korzys­tał użytkown­ik. A sko­ro tworzymy pro­jekt, który dos­tosowu­je się do urządzenia na jakim jest wyświ­et­lany, to powinien się dos­tosowywać do każdego (na tyle na ile jest to oczy­wiś­cie możli­we). Drugą sprawą jest to, że pow­sta­ją nowe urządzenia, a więc tym bardziej nie jesteśmy w stanie tego przewidzieć. RWD nie powin­no odnosić się do pro­jek­towa­nia według rozmi­arów poszczegól­nych ekranów, ale do obsłu­gi wielu urządzeń.

Myśląc o tym w ten sposób, należy skupić się na ele­men­cie respon­sy­wnego pro­jek­towa­nia jakim są break­pointy (ang.), które określa­ją moment, w którym zmienia się inter­fe­js strony, dos­tosowu­jąc swój wygląd do aktu­al­nej rozdziel­czoś­ci.

Ustalanie breakpointów

Jed­nym z najważniejszych pytań pod­czas pro­jek­towa­nia jest „w którym miejs­cu ustaw­ić break­point?”.

Z jed­nej strony moż­na kierować się następu­jącą zasadą: pro­jek­tu­je­my stronę, która ma się „dobrze” wyświ­et­lać na różnych urządzeni­ach, z których korzys­ta użytkown­ik, a więc smart­phone, tablet, lap­top, itd., z uwzględ­nie­niem ori­en­tacji ekranu.  Więc jed­ną z możli­woś­ci będzie ustaw­ie­nie break­pointów według poniższego obraz­ka.

Breakpoints

Żródło: http://www.workbysimon.com/observatory/responsive-web-design-breakpoints-or-fluid/

Ter­az należy odpowiedzieć na pytanie, czy takie pode­jś­cie jest poprawne? Jeśli więc rozważa­nia na tem­at RWD będziemy roz­pa­try­wać w kon­tekś­cie poprawnego dos­tosowa­nia się pro­jek­tu do każdego środowiska w jakim jest uruchami­any, to odpowiedź brz­mi „nie”. Jeśli zaczy­namy pro­jek­tować myśląc o urządzeni­ach czy rozdziel­czoś­ci­ach, nie jest to już wtedy pro­jek­towanie respon­sy­wne (ponieważ wtedy nie tworzymy pro­jek­tu, który będzie się dos­tosowywał do rozdziel­czoś­ci, ale wybier­amy rozdziel­czość i do niej dos­tosowu­je­my pro­jekt – co „kłó­ci” się z ideą RWD). Poza tym zagad­nie­nie „pop­u­larne urządzenia” odnosi się do ter­aźniejs­zoś­ci. Jutro inne urządzenia, o innych rozdziel­czoś­ci­ach mogą być pop­u­larne, a prze­cież właśnie o to chodzi, aby nasz pro­dukt dopa­sował się do każdego z nich (czy będzie to dziś czy jutro).

Jed­nym ze sposobów usta­la­nia break­pointów, jest pode­jś­cie mówiące, aby ustal­ić je tam, gdzie pro­jekt tego wyma­ga. Kiedy nasz pro­jekt nie wyglą­da już dobrze w aktu­al­nej rozdziel­czoś­ci – tam właśnie powinien być ustalony break­point, np. box z tek­stem moż­na zwężać lub rozsz­erzać, ale tylko do momen­tu kiedy treść w nim zawarta będzie nadal czytel­na. Jeśli przes­ta­je taka być, tam usta­lamy pier­wszy break­point.

Tworząc respon­sy­wne ser­wisy w taki właśnie sposób powin­niśmy myśleć o break­pointach, aby to pro­jekt dyk­tował nam, w którym miejs­cu powin­ny się one znaleźć, a nie na odwrót . Zaczni­jmy pro­jek­tować pier­wszą wer­sję strony, rozsz­erza­jąc lub zwęża­jąc pro­jekt zwraca­jmy uwagę, w którym momen­cie strona się „łamie” (od ang­iel­skiego słowa ‘break”). Wów­czas moż­na reor­ga­ni­zować i zmieni­ać ele­men­ty, aby zaczęły wyglą­dać lep­iej. W zależnoś­ci od pro­jek­tu, cza­sem wystar­czą dwa break­pointy, cza­sem więcej – pra­ca i rozwój nad pro­duk­tem poz­woli o tym zde­cy­dować.

Najważniejsza jest treść

Pro­jek­tu­jąc lay­out strony opier­a­jmy się na treś­ci (nagłów­ki, obraz­ki, tek­sty) – one powin­ny być decy­du­ją­cym czyn­nikiem w całym układzie. Częs­to spo­tykamy się jed­nak z pro­jek­ta­mi, gdzie na początku został przy­go­towany cały układ (ułoże­nie obrazów, tek­stów itp.), a potem do nich dopa­sowana treść. To samo doty­czy właśnie break­pointów, które zostały określone jeszcze przed rozpoczę­ciem pro­ce­su pro­jek­towa­nia.

Tabele

Dobrym przykła­dem wyjaś­ni­a­ją­cym są tabele. Ist­nieje kil­ka metod na pro­jek­towanie respon­sy­wnych tabel. A więc sposób w jaki przed­staw­imy tabelę na mniejszych rozdziel­czoś­ci­ach, powinien być dos­tosowany do danych, jakie ta tabela zaw­iera, a nie na odwrót. Prze­cież nie umieszcza­my na stron­ie tabeli dla samego jej posi­ada­nia. Tabele twor­zone są z jakiegoś powodu. Różne tabele przekazu­ją inne infor­ma­c­je. Wybier­a­jąc sposób prezen­tacji tabeli, musimy odpowiedzieć na pytanie, czy i jakie ele­men­ty będą porówny­wane przez użytkown­ików (kolum­ny, rzędy) lub czy wszys­tkie infor­ma­c­je w tabeli są niezbędne i konieczne do pokazy­wa­nia ich na mniejszych rozdziel­czoś­ci­ach.

Dla przykładu przed­staw­iam poniższą tabelę.

Celem tej tabeli jest umożli­wie­nie porów­na­nia poszczegól­nych wier­szy. Zwęża­jąc więc okno przeglą­dar­ki, ukryte zosta­ją dwie kolum­ny, jed­nak dzię­ki zachowa­niu układu tabeli użytkown­ik nadal jest w stanie porów­nać zawarte w niej ele­men­ty.

Tabela RWD

Źródło: http://www.authenticjobs.com/pricing/

Inne z kolei rozwiązanie zostało zas­tosowane na stron­ie http://www.solidshops.com/pricing. W wer­sji na mniejszą rozdziel­czość nie zostały ukryte żadne wier­sze ani kolum­ny, dzię­ki czemu użytkown­ik ma możli­wość zapoz­na­nia się z pełnym dostęp­nym opisem pro­duk­tu. Takie jed­nak rozwiązanie nie pozwala już na łatwe porów­nanie poszczegól­nych ele­men­tów, ponieważ zostały one ułożone w kolum­nie, jeden pod drugim. Należało­by się więc zas­tanow­ić, co dla mobil­nego użytkown­i­ka będzie ważniejsze: porów­nanie pro­duk­tów czy dostęp do pełnych infor­ma­cji (są też oczy­wiś­cie sposo­by, aby pogodz­ić te dwie potrze­by).

Tabela RWD

Źródło: http://www.solidshops.com/pricing

Dzię­ki tym dwóm przykładom, chci­ałam pokazać, że respon­sy­wne tabele moż­na zapro­jek­tować w różny sposób, a wybór ten może pomóc lub przeszkodz­ić w spełnie­niu przez tabelę swo­jego celu. Dopiero kiedy będziemy pewni przez­naczenia, dla którego tabela w ogóle jest twor­zona, wów­czas może­my wybier­ać odpowied­nie rozwiązanie.

O konkret­nych rozwiąza­ni­ach respon­sy­wnych tabel w zależnoś­ci od potrzeb moż­na przeczy­tać w artykule: http://blog.cloudfour.com/picking-responsive-tables-solution/

Nawigacja

Innym przykła­dem, w którym powin­niśmy podążać za treś­cią pod­czas pro­jek­towa­nia jest wybór rodza­ju naw­igacji. Jed­ną z najprost­szych metod jest po pros­tu umieszcze­nie listy ele­men­tów menu na samej górze strony (menu wów­czas w żaden sposób nie jest ukry­wane, jest widoczne cały czas).

Responsywne menu

 

Źródło: http://www.whitelotusaromatics.com/

Jest to oczy­wiś­cie proste w imple­men­tacji rozwiązanie, ale niekoniecznie dobre jeśli zależy nam na tym, aby użytkown­ik w szy­b­ki sposób dotarł do treś­ci i to właśnie właś­ci­wa treść powin­na być wyek­sponowana w górnej częś­ci strony. Jeśli zde­cy­du­je­my się na ten rodzaj menu (np. poprzez umieszcze­nie ele­men­tów jeden obok drugiego), to musimy się zas­tanow­ić czy w przyszłoś­ci nie będziemy chcieli dodać kole­jnych pozy­cji, które po pros­tu nie zmieszczą nam się na sze­rokość.

Grafiki

Kole­jnym ele­mentem, który może wpłynąć na sposób pro­jek­towa­nia są obraz­ki na stron­ie. Oczy­wiste jest to, że mniejsza rozdziel­czość oznacza mniej miejs­ca. Jest to więc moment, kiedy moż­na się zas­tanow­ić nad tym, czy konieczne jest pokazy­wanie wszys­t­kich obrazków na mniejszych rozdziel­czoś­ci­ach, jeśli jest on tylko uzu­pełnie­niem tek­stu.

W artykule http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution/ opisano zjawisko „The Art Direc­tion prob­lem”. Doty­czy ono tego, że nie każde zdję­cie nada­je się do skalowa­nia przy mniejszych rozdziel­czoś­ci­ach. Jest to spowodowane tym, że niek­tóre zdję­cia mogą posi­adać tak małe ele­men­ty, które na mniejszych urządzeni­ach będą po pros­tu niewyraźne. Dlat­ego lep­szym rozwiązaniem jest przy­cię­cie zdję­cia w taki sposób, aby np. na smart­phonie wyświ­et­lać tylko jego frag­ment. Oczy­wiś­cie zda­ję sobie sprawę, że zdję­cia na stron­ie częs­to będą pod­mieni­ane i nie zawsze jesteśmy w stanie przewidzieć jakie to będzie zdję­cie. Jed­nak w sytu­acji kiedy mamy je z góry określone, warto już wcześniej pomyśleć o nim w kon­tekś­cie mniejszych urządzeń.

Tekst

Ostat­nim zagad­nie­niem jaki omówię są tek­sty na stron­ie. Naw­iązu­jąc do przykładu o rozsz­erza­niu lub zwęża­niu tek­stu do momen­tu, kiedy będzie on nadal czytel­ny, odwołam się do artykułu zamieszc­zonego na Smash­ing Mag­a­zine, gdzie opisano ciekawe pode­jś­cie do tem­atu. Artykuł naw­iązu­je właśnie do czytel­noś­ci, która zależy od licz­by znaków w jed­nej linii tek­stu. Przyj­mu­jąc opty­mal­ną liczbę znaków w linii, dla której tekst jest czytel­ny (niek­tóre źródła poda­ją  45–75 znaków), a następ­nie rozsz­erza­jąc ekran, w momen­cie kiedy już mieś­ci się tekst z więk­szą liczbą znaków niż dopuszczal­na, powin­niśmy tam ustaw­ić break­point. Zachę­cam jed­nak do zapoz­na­nia się z pełną treś­cią artykułu, gdzie w pełni zostało opisane całe pode­jś­cie http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/.

Podsumowując

Wszys­tkie powyższe przykłady, które przed­staw­iłam mają na celu pokazanie, że zapro­jek­towanie dobrze respon­sy­wnej strony wyma­ga nie tylko umiejęt­noś­ci tech­nicznych, a również nauczenia się respon­sy­wnego myśle­nia. Oznacza to, że nie powin­niśmy dopa­sowywać ele­men­tów i treś­ci do z góry ustalonych rozdziel­czoś­ci. Zami­ast tego to właśnie treść powin­na dyk­tować nam, w jaki sposób zapro­jek­tu­je­my stronę, a tym samym, w którym miejs­cu powin­ny znaleźć się break­pointy.

Nie chcę w tym artykule całkowicie przekreślać i negować pode­jś­cia, w którym zwracamy uwagę na konkretne rozdziel­czoś­ci. Chcę tylko przed­staw­ić inne pode­jś­cie tym, którzy w cen­trum swoich zain­tere­sowań staw­ia­ją na pier­wszym miejs­cu urządzenia z jakich korzys­ta­ją lub będą korzys­tać docelowi użytkown­i­cy twor­zonego przez nich pro­duk­tu inter­ak­ty­wnego .

 

Źródła:

http://tangledindesign.com/deciding-what-responsive-breakpoints-to-use/

http://tympanus.net/codrops/2012/10/30/becoming-device-agnostic/

http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution/

http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/

3 odpowiedzi
  1. Michał
    Michał says:

    Czy ten artykuł nie jest jedynie tłu­macze­niem? Jestem przeko­nany, że czy­tałem go w wer­sji ang­iel­skiej, ale nie mogę dotrzeć do źródła..

    Odpowiedz
    • Marta Kozłowska
      Marta Kozłowska says:

      Nie jest tłu­macze­niem. Nie wyk­luczam, że pow­stały już artykuły na tem­at, który pisałam (lub pow­iązany), dlat­ego też na końcu podałam źródła.

      Odpowiedz
  2. Monika
    Monika says:

    Ciekawy artykuł. Nieste­ty zmi­any algo­ryt­mu Google w kwiet­niu 2015 r. postaw­iły wszys­t­kich przed fak­tem doko­nanym. Two­ja strona nie jest respon­sy­w­na? Ok, w takim razie my posprzą­tamy ją z wyników wyszuki­wań na smart­fonach. Idea pięk­na — szko­da że na real­iza­cję dali niecały miesiąc. Warto nad respon­sy­wnoś­cią poważnie zas­tanow­ić się i jej imple­men­tację zacząć już w fazie pro­jek­towa­nia strony.

    Odpowiedz

Odpowiedz

Want to join the discussion?
Feel free to contribute!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *