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!

Odpowiedz na „MichałAnuluj pisanie odpowiedzi

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