Koncepcja RWD – jak myśleć responsywnie podczas projektowania

Wie­le zosta­ło napi­sa­ne i powie­dzia­ne na temat Respon­si­ve Web Design, czy­li o spo­so­bie two­rze­nia stron inter­ne­to­wych, któ­re są dostęp­ne, dobrze się wyświe­tla­ją i są popraw­nie obsłu­gi­wa­ne na każ­dym urzą­dze­niu, pod róż­ny­mi roz­dziel­czo­ścia­mi ekra­nów. W sie­ci jest wie­le infor­ma­cji na temat kon­kret­nych roz­wią­zań, przy­kła­dów, wska­zó­wek pro­jek­to­wych, zarów­no tych mniej jak i bar­dziej tech­nicz­nych.

W tym arty­ku­le, na pod­sta­wie obser­wa­cji oraz dostęp­nych infor­ma­cji, chcia­łam przy­bli­żyć ideę RWD i sku­pić się na cie­ka­wym, nie­tech­nicz­nym podej­ściu do pro­jek­to­wa­nia. Nie będę kon­cen­tro­wać się na kon­kret­nych roz­wią­za­niach, ale na nasta­wie­niu jakie powin­ni­śmy mieć, kie­dy pod­cho­dzi­my do tema­tu „respon­si­ve web desing”.

Poni­żej, sło­wem wstę­pu, lista kil­ku pro­ble­mów, któ­re może roz­wią­zać respon­syw­na stro­na inter­ne­to­wa:

  • trud­ne do prze­wi­dze­nia rodza­je urzą­dzeń, z któ­rych będą korzy­stać użyt­kow­ni­cy,
  • brak sztyw­nych ogra­ni­czeń co do roz­dziel­czo­ści ekra­nu, na jaką powin­no się zwra­cać uwa­gę pod­czas pro­jek­to­wa­nia,
  • brak wie­dzy na temat tego, na jakim urzą­dze­niu, w jakiej sytu­acji i jakich infor­ma­cji będzie szu­kać użyt­kow­nik (jeden użyt­kow­nik = wie­le urzą­dzeń = wie­le kon­tek­stów uży­cia).

Jak można rozumieć Responsive Web Design?

Nale­ży tutaj zazna­czyć, że RWD jest to idea, kon­cep­cja, spo­sób pro­jek­to­wa­nia. Waż­ne w defi­ni­cji jest pierw­sze sło­wo „Respon­si­ve” (z ang. czu­ły, wraż­li­wy). Trak­tuj­my to więc jako two­rze­nie pro­jek­tu, któ­ry jest wraż­li­wy na swo­je oto­cze­nie (oto­cze­niem pro­jek­tu w tym wypad­ku jest urzą­dze­nie, na któ­rym jest wyświe­tla­ne).

W myśl kon­cep­cji, któ­rą chcę przed­sta­wić, nale­ży „zapo­mnieć” o urzą­dze­niach. A już na pew­no nie powin­ny być one naj­waż­niej­szym aspek­tem bra­nym pod uwa­gę pod­czas pro­jek­to­wa­nia.

Dlaczego właśnie takie podejście?

Tak jak pisa­łam wcze­śniej, nie wie­my z jakich urzą­dzeń będzie korzy­stał użyt­kow­nik. A sko­ro two­rzy­my pro­jekt, któ­ry dosto­so­wu­je się do urzą­dze­nia na jakim jest wyświe­tla­ny, to powi­nien się dosto­so­wy­wać do każ­de­go (na tyle na ile jest to oczy­wi­ście moż­li­we). Dru­gą spra­wą jest to, że powsta­ją nowe urzą­dze­nia, a więc tym bar­dziej nie jeste­śmy w sta­nie tego prze­wi­dzieć. RWD nie powin­no odno­sić się do pro­jek­to­wa­nia według roz­mia­rów poszcze­gól­nych ekra­nów, ale do obsłu­gi wie­lu urzą­dzeń.

Myśląc o tym w ten spo­sób, nale­ży sku­pić się na ele­men­cie respon­syw­ne­go pro­jek­to­wa­nia jakim są bre­ak­po­in­ty (ang.), któ­re okre­śla­ją moment, w któ­rym zmie­nia się inter­fejs stro­ny, dosto­so­wu­jąc swój wygląd do aktu­al­nej roz­dziel­czo­ści.

Ustalanie breakpointów

Jed­nym z naj­waż­niej­szych pytań pod­czas pro­jek­to­wa­nia jest „w któ­rym miej­scu usta­wić bre­ak­po­int?”.

Z jed­nej stro­ny moż­na kie­ro­wać się nastę­pu­ją­cą zasa­dą: pro­jek­tu­je­my stro­nę, któ­ra ma się „dobrze” wyświe­tlać na róż­nych urzą­dze­niach, z któ­rych korzy­sta użyt­kow­nik, a więc smart­pho­ne, tablet, lap­top, itd., z uwzględ­nie­niem orien­ta­cji ekra­nu.  Więc jed­ną z moż­li­wo­ści będzie usta­wie­nie bre­ak­po­in­tów według poniż­sze­go obraz­ka.

Breakpoints

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

Teraz nale­ży odpo­wie­dzieć na pyta­nie, czy takie podej­ście jest popraw­ne? Jeśli więc roz­wa­ża­nia na temat RWD będzie­my roz­pa­try­wać w kon­tek­ście popraw­ne­go dosto­so­wa­nia się pro­jek­tu do każ­de­go śro­do­wi­ska w jakim jest uru­cha­mia­ny, to odpo­wiedź brzmi „nie”. Jeśli zaczy­na­my pro­jek­to­wać myśląc o urzą­dze­niach czy roz­dziel­czo­ściach, nie jest to już wte­dy pro­jek­to­wa­nie respon­syw­ne (ponie­waż wte­dy nie two­rzy­my pro­jek­tu, któ­ry będzie się dosto­so­wy­wał do roz­dziel­czo­ści, ale wybie­ra­my roz­dziel­czość i do niej dosto­so­wu­je­my pro­jekt – co „kłó­ci” się z ideą RWD). Poza tym zagad­nie­nie „popu­lar­ne urzą­dze­nia” odno­si się do teraź­niej­szo­ści. Jutro inne urzą­dze­nia, o innych roz­dziel­czo­ściach mogą być popu­lar­ne, a prze­cież wła­śnie o to cho­dzi, aby nasz pro­dukt dopa­so­wał się do każ­de­go z nich (czy będzie to dziś czy jutro).

Jed­nym ze spo­so­bów usta­la­nia bre­ak­po­in­tów, jest podej­ście mówią­ce, aby usta­lić je tam, gdzie pro­jekt tego wyma­ga. Kie­dy nasz pro­jekt nie wyglą­da już dobrze w aktu­al­nej roz­dziel­czo­ści – tam wła­śnie powi­nien być usta­lo­ny bre­ak­po­int, np. box z tek­stem moż­na zwę­żać lub roz­sze­rzać, ale tyl­ko do momen­tu kie­dy treść w nim zawar­ta będzie nadal czy­tel­na. Jeśli prze­sta­je taka być, tam usta­la­my pierw­szy bre­ak­po­int.

Two­rząc respon­syw­ne ser­wi­sy w taki wła­śnie spo­sób powin­ni­śmy myśleć o bre­ak­po­in­tach, aby to pro­jekt dyk­to­wał nam, w któ­rym miej­scu powin­ny się one zna­leźć, a nie na odwrót . Zacznij­my pro­jek­to­wać pierw­szą wer­sję stro­ny, roz­sze­rza­jąc lub zwę­ża­jąc pro­jekt zwra­caj­my uwa­gę, w któ­rym momen­cie stro­na się „łamie” (od angiel­skie­go sło­wa ‘bre­ak”). Wów­czas moż­na reor­ga­ni­zo­wać i zmie­niać ele­men­ty, aby zaczę­ły wyglą­dać lepiej. W zależ­no­ści od pro­jek­tu, cza­sem wystar­czą dwa bre­ak­po­in­ty, cza­sem wię­cej – pra­ca i roz­wój nad pro­duk­tem pozwo­li o tym zde­cy­do­wać.

Najważniejsza jest treść

Pro­jek­tu­jąc lay­out stro­ny opie­raj­my się na tre­ści (nagłów­ki, obraz­ki, tek­sty) – one powin­ny być decy­du­ją­cym czyn­ni­kiem w całym ukła­dzie. Czę­sto spo­ty­ka­my się jed­nak z pro­jek­ta­mi, gdzie na począt­ku został przy­go­to­wa­ny cały układ (uło­że­nie obra­zów, tek­stów itp.), a potem do nich dopa­so­wa­na treść. To samo doty­czy wła­śnie bre­ak­po­in­tów, któ­re zosta­ły okre­ślo­ne jesz­cze przed roz­po­czę­ciem pro­ce­su pro­jek­to­wa­nia.

Tabele

Dobrym przy­kła­dem wyja­śnia­ją­cym są tabe­le. Ist­nie­je kil­ka metod na pro­jek­to­wa­nie respon­syw­nych tabel. A więc spo­sób w jaki przed­sta­wi­my tabe­lę na mniej­szych roz­dziel­czo­ściach, powi­nien być dosto­so­wa­ny do danych, jakie ta tabe­la zawie­ra, a nie na odwrót. Prze­cież nie umiesz­cza­my na stro­nie tabe­li dla same­go jej posia­da­nia. Tabe­le two­rzo­ne są z jakie­goś powo­du. Róż­ne tabe­le prze­ka­zu­ją inne infor­ma­cje. Wybie­ra­jąc spo­sób pre­zen­ta­cji tabe­li, musi­my odpo­wie­dzieć na pyta­nie, czy i jakie ele­men­ty będą porów­ny­wa­ne przez użyt­kow­ni­ków (kolum­ny, rzę­dy) lub czy wszyst­kie infor­ma­cje w tabe­li są nie­zbęd­ne i koniecz­ne do poka­zy­wa­nia ich na mniej­szych roz­dziel­czo­ściach.

Dla przy­kła­du przed­sta­wiam poniż­szą tabe­lę.

Celem tej tabe­li jest umoż­li­wie­nie porów­na­nia poszcze­gól­nych wier­szy. Zwę­ża­jąc więc okno prze­glą­dar­ki, ukry­te zosta­ją dwie kolum­ny, jed­nak dzię­ki zacho­wa­niu ukła­du tabe­li użyt­kow­nik nadal jest w sta­nie porów­nać zawar­te w niej ele­men­ty.

Tabela RWD

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

Inne z kolei roz­wią­za­nie zosta­ło zasto­so­wa­ne na stro­nie http://www.solidshops.com/pricing. W wer­sji na mniej­szą roz­dziel­czość nie zosta­ły ukry­te żad­ne wier­sze ani kolum­ny, dzię­ki cze­mu użyt­kow­nik ma moż­li­wość zapo­zna­nia się z peł­nym dostęp­nym opi­sem pro­duk­tu. Takie jed­nak roz­wią­za­nie nie pozwa­la już na łatwe porów­na­nie poszcze­gól­nych ele­men­tów, ponie­waż zosta­ły one uło­żo­ne w kolum­nie, jeden pod dru­gim. Nale­ża­ło­by się więc zasta­no­wić, co dla mobil­ne­go użyt­kow­ni­ka będzie waż­niej­sze: porów­na­nie pro­duk­tów czy dostęp do peł­nych infor­ma­cji (są też oczy­wi­ście spo­so­by, aby pogo­dzić te dwie potrze­by).

Tabela RWD

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

Dzię­ki tym dwóm przy­kła­dom, chcia­łam poka­zać, że respon­syw­ne tabe­le moż­na zapro­jek­to­wać w róż­ny spo­sób, a wybór ten może pomóc lub prze­szko­dzić w speł­nie­niu przez tabe­lę swo­je­go celu. Dopie­ro kie­dy będzie­my pew­ni prze­zna­cze­nia, dla któ­re­go tabe­la w ogó­le jest two­rzo­na, wów­czas może­my wybie­rać odpo­wied­nie roz­wią­za­nie.

O kon­kret­nych roz­wią­za­niach respon­syw­nych tabel w zależ­no­ści od potrzeb moż­na prze­czy­tać w arty­ku­le: http://blog.cloudfour.com/picking-responsive-tables-solution/

Nawigacja

Innym przy­kła­dem, w któ­rym powin­ni­śmy podą­żać za tre­ścią pod­czas pro­jek­to­wa­nia jest wybór rodza­ju nawi­ga­cji. Jed­ną z naj­prost­szych metod jest po pro­stu umiesz­cze­nie listy ele­men­tów menu na samej górze stro­ny (menu wów­czas w żaden spo­sób nie jest ukry­wa­ne, jest widocz­ne cały czas).

Responsywne menu

 

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

Jest to oczy­wi­ście pro­ste w imple­men­ta­cji roz­wią­za­nie, ale nie­ko­niecz­nie dobre jeśli zale­ży nam na tym, aby użyt­kow­nik w szyb­ki spo­sób dotarł do tre­ści i to wła­śnie wła­ści­wa treść powin­na być wyeks­po­no­wa­na w gór­nej czę­ści stro­ny. Jeśli zde­cy­du­je­my się na ten rodzaj menu (np. poprzez umiesz­cze­nie ele­men­tów jeden obok dru­gie­go), to musi­my się zasta­no­wić czy w przy­szło­ści nie będzie­my chcie­li dodać kolej­nych pozy­cji, któ­re po pro­stu nie zmiesz­czą nam się na sze­ro­kość.

Grafiki

Kolej­nym ele­men­tem, któ­ry może wpły­nąć na spo­sób pro­jek­to­wa­nia są obraz­ki na stro­nie. Oczy­wi­ste jest to, że mniej­sza roz­dziel­czość ozna­cza mniej miej­sca. Jest to więc moment, kie­dy moż­na się zasta­no­wić nad tym, czy koniecz­ne jest poka­zy­wa­nie wszyst­kich obraz­ków na mniej­szych roz­dziel­czo­ściach, jeśli jest on tyl­ko uzu­peł­nie­niem tek­stu.

W arty­ku­le http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution/ opi­sa­no zja­wi­sko „The Art Direc­tion pro­blem”. Doty­czy ono tego, że nie każ­de zdję­cie nada­je się do ska­lo­wa­nia przy mniej­szych roz­dziel­czo­ściach. Jest to spo­wo­do­wa­ne tym, że nie­któ­re zdję­cia mogą posia­dać tak małe ele­men­ty, któ­re na mniej­szych urzą­dze­niach będą po pro­stu nie­wy­raź­ne. Dla­te­go lep­szym roz­wią­za­niem jest przy­cię­cie zdję­cia w taki spo­sób, aby np. na smart­pho­nie wyświe­tlać tyl­ko jego frag­ment. Oczy­wi­ście zda­ję sobie spra­wę, że zdję­cia na stro­nie czę­sto będą pod­mie­nia­ne i nie zawsze jeste­śmy w sta­nie prze­wi­dzieć jakie to będzie zdję­cie. Jed­nak w sytu­acji kie­dy mamy je z góry okre­ślo­ne, war­to już wcze­śniej pomy­śleć o nim w kon­tek­ście mniej­szych urzą­dzeń.

Tekst

Ostat­nim zagad­nie­niem jaki omó­wię są tek­sty na stro­nie. Nawią­zu­jąc do przy­kła­du o roz­sze­rza­niu lub zwę­ża­niu tek­stu do momen­tu, kie­dy będzie on nadal czy­tel­ny, odwo­łam się do arty­ku­łu zamiesz­czo­ne­go na Sma­shing Maga­zi­ne, gdzie opi­sa­no cie­ka­we podej­ście do tema­tu. Arty­kuł nawią­zu­je wła­śnie do czy­tel­no­ści, któ­ra zale­ży od licz­by zna­ków w jed­nej linii tek­stu. Przyj­mu­jąc opty­mal­ną licz­bę zna­ków w linii, dla któ­rej tekst jest czy­tel­ny (nie­któ­re źró­dła poda­ją  45–75 zna­ków), a następ­nie roz­sze­rza­jąc ekran, w momen­cie kie­dy już mie­ści się tekst z więk­szą licz­bą zna­ków niż dopusz­czal­na, powin­ni­śmy tam usta­wić bre­ak­po­int. Zachę­cam jed­nak do zapo­zna­nia się z peł­ną tre­ścią arty­ku­łu, gdzie w peł­ni zosta­ło opi­sa­ne całe podej­ście http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/.

Podsumowując

Wszyst­kie powyż­sze przy­kła­dy, któ­re przed­sta­wi­łam mają na celu poka­za­nie, że zapro­jek­to­wa­nie dobrze respon­syw­nej stro­ny wyma­ga nie tyl­ko umie­jęt­no­ści tech­nicz­nych, a rów­nież naucze­nia się respon­syw­ne­go myśle­nia. Ozna­cza to, że nie powin­ni­śmy dopa­so­wy­wać ele­men­tów i tre­ści do z góry usta­lo­nych roz­dziel­czo­ści. Zamiast tego to wła­śnie treść powin­na dyk­to­wać nam, w jaki spo­sób zapro­jek­tu­je­my stro­nę, a tym samym, w któ­rym miej­scu powin­ny zna­leźć się bre­ak­po­in­ty.

Nie chcę w tym arty­ku­le cał­ko­wi­cie prze­kre­ślać i nego­wać podej­ścia, w któ­rym zwra­ca­my uwa­gę na kon­kret­ne roz­dziel­czo­ści. Chcę tyl­ko przed­sta­wić inne podej­ście tym, któ­rzy w cen­trum swo­ich zain­te­re­so­wań sta­wia­ją na pierw­szym miej­scu urzą­dze­nia z jakich korzy­sta­ją lub będą korzy­stać doce­lo­wi użyt­kow­ni­cy two­rzo­ne­go przez nich pro­duk­tu inte­rak­tyw­ne­go .

 

Ź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 arty­kuł nie jest jedy­nie tłu­ma­cze­niem? Jestem prze­ko­na­ny, że czy­ta­łem go w wer­sji angiel­skiej, ale nie mogę dotrzeć do źró­dła..

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

      Nie jest tłu­ma­cze­niem. Nie wyklu­czam, że powsta­ły już arty­ku­ły na temat, któ­ry pisa­łam (lub powią­za­ny), dla­te­go też na koń­cu poda­łam źró­dła.

      Odpowiedz
  2. Monika
    Monika says:

    Cie­ka­wy arty­kuł. Nie­ste­ty zmia­ny algo­ryt­mu Google w kwiet­niu 2015 r. posta­wi­ły wszyst­kich przed fak­tem doko­na­nym. Two­ja stro­na nie jest respon­syw­na? Ok, w takim razie my posprzą­ta­my ją z wyni­ków wyszu­ki­wań na smart­fo­nach. Idea pięk­na – szko­da że na reali­za­cję dali nie­ca­ły mie­siąc. War­to nad respon­syw­no­ścią poważ­nie zasta­no­wić się i jej imple­men­ta­cję zacząć już w fazie pro­jek­to­wa­nia stro­ny.

    Odpowiedz

Odpowiedz

Want to join the discussion?
Feel free to contribute!

Odpowiedz na „Marta KozłowskaAnuluj pisanie odpowiedzi

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