responsive web design and joomla!

RESPONSIVE WEB DESIGN A JOOMLA!

Tomasz Dziuda - Lead Developer @ GavickPro

Czym jest Responsive Web Design (RWD)

?

Na potrzeby dalszych slajdów, pozwoliłem sobie korzystać zamiast ze zwrotu Responsive Web Design, ze skrótu RWD.

RWD - podejście do tworzenia stron w którym wygląd strony jest dostosowywany celem zapewnienia optymalnego wyglądu w zależności od ekranu.

RWD jest jednym z trzech wartych uwagi metod optymalizacji stron do szerokiej gamy urządzeń

Responsive Web Design

Device Experiences

RESS (REsponsive web design with Server-Side components)

Device Experiences to podejście, które zapewnia maksymalną optymalizację dla wymaganych typów urządzeń i tym samym najlepsze User Experience. Jednocześnie wymaga też najwięcej pracy, gdyż w praktyce oznacza przygotowanie kilku-kilkunastu wersji danej witryny.

RESS - dzięki serwerowym skryptom zapewnia dodatkowe udogodnienia - np. pozwala nie dołączać konkretnych styli CSS dla danych urządzeń. Tak naprawdę RESS to ulepszenie RWD, które pozwala zlikwidować pewne wady RWD, które omówimy później. Choć należy zauważyć, że czasem RESS powoduje, że tracimy pewne zalety RWD (opartego na technologiach client-side).

Media queries - podstawa RWD@media screen and (max-width: 1000px)

@media screen and (min-device-width: 320px)

Media queries to podstawa RWD - dzięki ich wykorzystaniu można ograniczyć używanie danego fragmentu kodu CSS do określonych rozmiarów ekranu.

Dodatkowo ważny jest też nieinwazyjny JavaScript (Unobtrusive JavaScript) (gwarantuje on nam, że podstawowe elementy strony zadziałają zawsze niezależnie od tego czy przeglądarka wspiera JavaScript czy też nie).

W tej prezentacji skupię się na RWD w wydaniu Joomlowym - czyli pełny RWD oparty o media-queries.

RWD NA RÓŻNE SPOSOBYStruktura kodu

Pozwoliłem sobie wyróżnić dwie główne grupy podejść stosowanych przy korzystaniu z podejścia RWD:

* pierwsza grupa to sposoby tworzenia i organizacji kodu.* druga grupa to sposoby organizacji architektury strony

DESKTOP-FIRST

.box { background: #777; width: 760px;}

@media (max-width: 799px) { .box { width: 100%; }}

Podejście desktop-first najprościej ujmując, jest stosowane wtedy, gdy zaczynamy dostosowywać stronę w wersji desktopowej do urządzeń mobilnych. Tworzymy zatem reguły wyświetlane na szerokich ekranach, a następnie poprzez media queries tworzymy stylistykę tych elementów dostosowaną do mniejszych ekranów.

MOBILE-FIRST

.box { background: #777; width: 100%;}

@media (min-width: 800px) { .box{ width: 760px; }}

Podejście to wykorzystujemy wtedy gdy zaczynamy od wersji mobilnej strony, a następnie rozszerzamy jej stylowanie na urządzenia o większych ekranach. Jest więc ono po prostu odwrotnością podejścia desktop-first. Warto zwrócić uwagę, że w wypadku przeglądarek, które nie wspierają media-queries, zostanie wyświetlona na dużych ekranach wersja mobilna witryny.

MEDIA-QUERY SPLITTING.box { background: #777;}



Jest to podejście w którym elementy wspólne kodu umieszczone są w kodzie głównym, a elementy charakterystyczne dla danych urządzeń w plikach CSS urządzeń mobilnych. WADA: całkowicie nie zadziała bez wsparcia media-queries (w odróżnieniu do wcześniej wspomnianych podejść, gdzie strona wyświetli się w wersji mobilnej lub desktopowej).

RWD NA RÓŻNE SPOSOBYArchitektura strony

Pozwoliłem sobie wyróżnić dwie główne grupy podejść stosowanych przy używaniu RWD:

* pierwsza grupa to sposoby tworzenia i organizacji kodu.* druga grupa to sposoby organizacji architektury strony.

PEŁNE UŻYCIE RWD

Źródło: joomla.org

Pełne użycie RWD - ma miejsce wtedy kiedy strona posiada jedną wersję dostosowywującą się do wszystkich urządzeń - jako przykład - witryna joomla.org.

PEŁNE UŻYCIE RWD

Kolejny przykład pełnego użycia RWD - nasz darmowy szablon Meet Gavern, który zostanie udostępniony kilka dni po oficjalnej premierze Joomla! 3.0.

PEŁNE UŻYCIE RWD

I jeszcze jeden przykład - tym razem z bardziej zarysowanym podziałem na trzy wersje: desktopową, tabletową i mobilną - szablon GameNews. Na screenshocie szablon w wersji desktopowej...

PEŁNE UŻYCIE RWD

... i szablon GameNews widoczny w wersji tabletowej (korzystającej z dwukolumnowego układu) i mobilnej - opartej na jednokolumnowym układzie.

CZĘŚCIOWE WYKORZYSTANIE RWD

Częściowe wykorzystanie RWD ma miejsce wtedy gdy nasza witryna posiada wersję mobilną, ale chcemy dostosować stronę np. do tabletów. Przykładem jest tutaj szablon AppsPro Tech w którym wykonaliśmy nasze pierwsze podejście do RWD w komercyjnych szablonach, przygotowując wersję strony przystosowaną do tabletów.


Źródło: m.onet.pl

Innym przykładem częściowego wykorzystania RWD może być serwis informacyjny Onet.pl - posiada on dwie wersje witryny - desktopową onet.pl oraz mobilną m.onet.pl - wersja mobilna jest stworzona w całości w oparciu o RWD i dostosowywuje się do rozmiaru ekranu tabletów jak i telefonów.


Źródło: facebook.com

Kolejnym przykładem częściowego wykorzystania RWD jest facebook.com - w tym wypadku serwis dostosowywuje się do użytkowników posiadających duże ekrany, tworząc dodatkowy pasek z aktywnościami znajomych oraz chatem po prawej stronie witryny. Jest to dobry przykład na to, że Responsive Web Design może być wykorzystany w aplikacjach desktopowych, po to by zapewnić optymalne wykorzystanie przestrzeni w oknie przeglądarki. Musimy pamietać, że HTML5 oraz CSS3 tworzone są także z myślą o byciu bazą dla tworzenia aplikacji desktopowych, a co za tym idzie - dzięki użyciu RWD, możemy mieć wpływ na to jak aplikacja się wyświetla w oknach różnych rozmiarów, umożliwiając użytkownikowi uruchomenie kilku aplikacji w oknach obok siebie.

BRAK UŻYCIA RWD

;-)

Trzecim sposobem podejścia do RWD jest brak jego użycia - należy liczyć się z tym, że RWD nie zawsze jest najlepszym rozwiązaniem - zwłaszcza w wypadku gdy mamy bardzo specificznych użytkowników, korzystających z konkretnych urządzeń mobilnych - wtedy podejście RWD jest dla nich mniej optymalne niż wykorzystanie np. podejścia Device Expericences.

ZALETY RWD

Dostępność dla (prawie) wszystkich urządzeń

Zapewnia optymalne wykorzystanie ekranu urządzenia. Problemy mogą jedynie sprawiać urządzenia o nietypowych rozmiarach ekranu.. RWD nie zapewnia jednak z reguły optymalnego User Experience

Rozwiązuje problemy z cache w Joomla!

Cache w Joomla! nie przechowuje oddzielnie wersji mobilnej i desktopowej. Każdy kto korzystał z cache w Joomla! wie, że jeżeli posiadamy oddzielną wersję mobilną witryny to po włączeniu cache, może nastąpić sytuacja w której użytkownik wersji desktopowej widzi wersję mobilną, która została zapisana do cache po wizycie użytkownika korzystającego z urządzenia mobilnego. W wypadku wykorzystania RWD problem zapisu danej strony do cache w jednej wersji nie uwzględniajacej urządzenia użytkownika nie istnieje.

z reguły ;-)

Mniej pracy

Z reguły mniej ;)

Nie trzeba od podstaw projektować wersji tabletowej i mobilnej. CSS wykorzystujemy do przestylowania niektórych cech elementów strony, a nie ich stylowania od podstaw (we wszystkich podejściach: mobile/desktop-first). Co za tym idzie ilość pracy do wykonania zwykle jest dużo mniejsza.

Nie wymaga technologii server-side

Brak zapotrzebowania na technologie działające po stronie serwera jest dużą zaletą RWD - dzięki temu możemy umieszczać pliki stron opartych o RWD w zasadzie w dowolnych miejscach a nie tylko na koncie hostingu, który wspiera jedną z technologii server-side.

WADY RWD

RWD wyprzedza swoją epokę

RWD pod względem technologicznym znacząco wyprzedza swoją epokę. Warto zwrócić uwagę na brak pełnego wsparcia (prefiksy) dla detekcji DPI ekranu, problematyczne media-queries dla urządzeń z ekranami o wysokim DPI - patrz: iPad 3 a Android. Problemy z grafikami. Brak bandwidth media-queries (t.j. media-queries związanych z szybkością łącza internetowego, które pozowoliłyby np. wyłączyć grafiki na stronie, gdy użytkownik korzysta z bardzo wolnego połączenia internetowego).

GRAFIKI W RWD

http://jquerypicture.com/

Znacznik <picture>

https://github.com/scottjehl/picturefill

<picture alt="Description of image subject."> <source srcset="small.jpg 1x, small-highres.jpg 2x">

<source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">

<source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x"> <img src="small.jpg" alt="Description of image subject.">

</picture>

Znacznik <picture> to obecnie propozycja na rozwiązanie palącego problemu związanego z RWD - nie ma obecnie bezproblemowego sposobu, który zapewniałby serwowanie grafik dostosowanych do rozmiarów ekranu urządzenia. Pewną namiastkę funkcjonalności tego znacznika dają nam skrypty takie jak jQuery Picture oraz picturefill.





GRAFIKI W RWD

http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/

<img id="graphic" src="picture.png" alt="Image">

@media all and (max-width:600px) {#graphic {content: url(medium-res.png);}

}

@media all and (max-width:320px) {#graphic {content: url(low-res.png);}

}

@media all and (network-speed:3g) {#graphic {content: attr(alt);}

}

Media queries + właściwość content

Innym sposobem na obejście problemu braku możliwości łatwego wczytania grafik dla urządzeń mobilnych byłoby wykorzystanie znacznika <img> oraz właściwości content z CSS. Jednak istnieją dwie wady tego podejścia:

* niezależnie od wartości właściwości content i tak zostanie wczytana grafika z atrybutu src znacznika <img>.* Obecnie tylko Chrome i Opera wspierają właściwość content dla elementów, które nie są pseudoelementami.

Warto też zwrócić uwagę na oznaczony w kodzie na czerwono fragment - network-speed: 3g - jest to właśnie przykład wspomnianych wcześniej, nie istniejących tzw. bandwidth media queries, które znacząco uprościłyby kwestie związane z szybkością łącza internetowego, jakie wykorzystuje internauta.



GRAFIKI W RWD

Adaptive images.htaccess + skrypt PHP + JavaScript

http://adaptive-images.com/

http://www.w3.org/community/respimg/

Najprostszym obecnie rozwiązaniem do wykorzystania są Adaptive Images - rozwiązanie to bazuje na odpowiednio spreparowanym pliku .htaccess, skrypcie PHP tworzącym miniaturki oraz skrypcie JavaScript, który dobiera grafiki do załadowania na bazie rozmiaru ekranu.

Warto też śledzić Responsive Images Community, która zawiera najświeższe materiały w temacie responsywnego podejścia do tematu grafik na stronach WWW.





TABELE W RWD

<TABLE> -> <DL>

Tabele podobnie jak wszelkiego rodzaju media są także problematycznym elementem na stronach opartych o RWD. Problem z tabelami polega na tym, że często rozszerzają się one na określoną - minimalną szerokość, która nie może zostać zmniejszona bez dodatkowych modyfikacji kodu CSS lub JavaScript.

Problem ten spotkał się z kilkunastoma różnymi rozwiązaniami. Na slajdzie zaprezentowane zostały trzy podejścia:

1) Wykorzystanie skryptów które pozwalają na stworzenie tabel w których część zawartości tabel może być przesuwana poprzez interfejs dotykowy urządzenia.

2) Wykorzystanie listy wyboru widocznych kolumn - w tym wypadku główną wadą jest to, że użytkownik nie może porównać wartości z większej ilości kolumn naraz.

3) Zamiana tabel na listy definicji (znacznik <DL>). Rozwiązanie to jest często najwygodniejsze, gdyż nie wymaga dodatkowych skryptów oraz dodatkowo często nie narusza semantyki strony (zważywszy na to, że jedna fraza w liście (element <DT>) może zawierać kilka opisów (<DD>). Jednak oczywiście rozwiązanie to nie powinno być wykorzystywane w sytuacji gdy, chcemy zapewnić użytkownikowi możliwość porównania wartości z kolumn.

NARZUT KODU CSS.box { background: #777;}



Kolejną wadą RWD jest narzut dodatkowego kodu CSS - jak wiadomo, wszystkie pliki CSS wczytywane są od razu - także te, które nie zostaną wykorzystane (np. pliki widoku mobilnego na notebooku). Jednak warto zwrócić uwagę na fakt, że narzut kodu CSS w tym wypadku nie jest zbyt wielki, z reguły jest to dodatkowe kilka-kilkanaście kB kodu, stąd jest to raczej wada dla osób, które mają obsesję na punkcie każdego zbędnego kilobajta treści tworzących stronę.

(min-width: ??) and (max-width: ??)

Rozdzielczości graniczne

Pytanie bez uniwersalnej odpowiedzi - dobór rozdzielczości granicznych (czyli rozdzielczości przy których wczytywane są konkretne pliki/fragmenty kodu CSS) zależy od rodzaju treści i jej układu. Czasem media-queries są niepotrzebne, a czasem trzeba załadować 4 lub więcej różnych plików/fragmentów kodu CSS.

Ograniczenia funkcjonalności i układu strony

Nie wszystkie układy nadają się na stronę opartą o RWD. Nie wszystkie efekty da się zaimplementować tak by były responsywne. Należy pamiętać, że urządzenia mobilne to ograniczona ilość pamięci RAM (stąd warto rozważnie dobierać rozmiar grafik na stronie) oraz ograniczona moc procesora (warto o tym pamiętać przy korzystaniu z różnego rodzaju animacji).

CO JEST WAŻNE PRZY RWD?

Architektura treści(suffiksy w Joomla! pozwalają sporo ukryć)

Trzeba przemyśleć układ treści tak by udało się osiągnąc z użyciem CSS układ mobilny/tabletowy. Osobiście preferuję przy projektowaniu układu strony połączenie podejść desktop-first oraz mobile-first. Podejście desktop-first wykorzystuję do tworzenia kodu, natomiast podejście mobile-first stosuję do przemyślenia układu strony tzn. prototypuję wygląd strony w widoku mobilnym po to aby przewidzieć pewne problemy, które mogą wystąpić po zeskalowaniu szerokości strony w dół.

Urządzenie mobilne = ekran dotykowy

Niektóre elementy strony są na ekranach dotykowych problematyczne na przykład: menu, popupy. Należy też zadbać o odpowiedni rozmiar interaktywnych elementów.

Zdrowy rozsądek ;-)

Często nie warto martwić się o ekrany dziwnych rozmiarów. Efektowne elementy nie są stworzone dla urządzeń mobilnych - jak już wcześniej wspomniano - duże grafiki => mała ilość RAM, rozbudowane animacje => ograniczona moc CPU. Często złotym środkiem na tego typu problemy tj. pogodzenie efektywnej strony z wyświetlaniem na urzadzeniach mobilnych jest zastąpienie rozbudowanych animowanych elementów statyczną grafiką.

JOOMLA! + BOOTSTRAP = RWD

JOOMLA! - PIERWSZY CMS OPARTY O RWD

Joomla! jest pierwszym z popularnych CMS-ów, który będzie wspierać RWD - zarówno od strony panelu admnistracyjnego jak i od strony front-endu.

ZUNIFIKOWANY UI I UX

Wszystkie komponenty będą oparte o RWD, komponenty będa mieć podobną stylistykę. Tworzenie komponentów nie będzie wymagać dużych prac przy kodzie CSS, co jest dobrą wiadomością dla programistów, którzy niezbyt przyjaźnią się z Photoshopem i ogólnie pojętym designem. Dodatkowo fakt wykorzystania Bootstrap oznacza lepszą unifikację wyglądu komponentów a co za tym idzie ułatwienie nauki obsługi poszczególnych komponentów co pozytywnie wpłynie na czas nauki obsługi panelu administracyjnego.

“SKAZANI” NA BOOTSTRAP

Wraz z głęboko idącą integracją Bootrstap i Joomla!, developerzy będą niejako skazani na użycie tego frameworka. Nie należy się jednak tego obawiać - Bootstrap to dobrze przemyślana platforma z szerokim wsparciem społeczności. Bootstrap wspiera nowoczesne techniki takie jak LESS i RWD. Jedną z problematycznych kwestii jest to, że wszystkie widoki komponentów będą zmienione, a co za tym idzie trzeba będzie od nowa dostosować szablony do nowej Joomla!.

“SKAZANI” NA JQUERYWszystkie skrypty oparte na MooTools do przepisania ;-)

jQuery jest nierozłącznie związany z Bootstrap. jQuery jest dużo popularniejszy od MooTools, a dzięki Google AJAX Libraries API wczytuje się szybciej - także dzięki swojej popularności. Ogromna baza pluginów także przemawia na korzyść jQuery - w zasadzie wszystkie popularniejsze efekty tworzonę są w oparciu o jQuery. Popularne komponenty i tak już go używały. Brak ładowania MooTools i jQuery na jednej stronie to zdecydowana korzyść, która powinna przekonać wszystkich tych, którzy nie chcą przepisywać swoich skryptów z MooTools na jQuery (brak konfliktów pomiędzy skryptami, zdecydowanie mniejsze obciążenie strony kodem JavaScript i mniejszy transfer danych).

KOMPATYBILNOŚĆ WSTECZ

Tworzenie rozszerzeń i szablonów dla obu joomli będzie wymagać dwóch oddzielnych podejść. Warto jednak zauważyć, że zapowiedziano widoki oparte na Bootstrap dla Joomla! 2.5. Zatem główne problemy mogą pojawić się w panelu administracyjnym, jeżeli ktoś używać ponadstandardowych rozwiązań (np. skrypty animacji interfejsu modułów).

PODSUMOWANIERWD to dobry kierunek

wymaga jednak dalszego rozwoju technologii

Dziękuję za uwagę i czekam na pytania :-)

Warto przeczytać:

• http://www.alistapart.com/articles/responsive-web-design/• http://en.wikipedia.org/wiki/Responsive_Web_Design• http://www.lukew.com/ff/entry.asp?1509• http://css-tricks.com/bandwidth-media-queries/

responsive web design and joomla!

Technology