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.). 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.

Ż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. 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.

Ź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).

Ź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.

Ź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/