2. 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ń
3. 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).
4. 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.
5. RWD NA RÓŻNE SPOSOBY
Struktura 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
6. 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.
7. 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.
8. MEDIA-QUERY SPLITTING
.box {
background: #777;
}
@media (max-width: 799px) {
.box {
width: 100%;
}
}
@media (min-width: 800px) {
.box{
width: 760px;
}
}
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).
9. RWD NA RÓŻNE SPOSOBY
Architektura 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.
10. 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.
11. 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.
12. 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...
13. 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.
14. 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.
15. CZĘŚCIOWE WYKORZYSTANIE RWD
Ź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.
16. CZĘŚCIOWE WYKORZYSTANIE RWD
Ź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.
17. 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.
19. 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
20. 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.
21. Mniej pracy
z reguły ;-)
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.
22. 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.
24. 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).
25. GRAFIKI W RWD
Znacznik <picture>
<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>
http://jquerypicture.com/
https://github.com/scottjehl/picturefill
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.
26. GRAFIKI W RWD
Media queries + właściwość content
<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);}
}
http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/
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.
27. 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.
28. 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.
29. NARZUT KODU CSS
.box {
background: #777;
}
@media (max-width: 799px) {
.box {
width: 100%;
}
}
@media (min-width: 800px) {
.box{
width: 760px;
}
}
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ę.
30. Rozdzielczości graniczne
(min-width: ??) and (max-width: ??)
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.
31. 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).
33. 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ół.
34. 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.
35. 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ą.
37. 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.
38. 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.
39. “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!.
40. “SKAZANI” NA JQUERY
Wszystkie 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).
41. 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).
42. PODSUMOWANIE
RWD to dobry kierunek
wymaga jednak dalszego rozwoju technologii
43. 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/
