WordPress - motywy, wtyczki, informacje, programowanie

Serwisy responsywne – Responsive Web Design i Media Queries

Nie mogę się nadziwić jak wiele osób na co dzień tworzących serwisy internetowe, albo nie słyszało nigdy o Responsive Web Design, albo zignorowało go jako jedną z wielu nowinek o przeciętnym znaczeniu. Tymczasem to jeden z najważniejszych konceptów jakie się pojawiły w ostatnich latach i coś, czego niewątpliwie wszyscy będą musieli się nauczyć.
Jeśli jeszcze nie wiesz, co to jest Responsive Web Design (RWD), ten tekst jest przede wszystkim dla Ciebie.

Powiększ okno przeglądarki z otwartym WPinternals.pl i skaluj je na szerokość obserwując jak zachowują się poszczególne elementy strony. Nie tylko zmieniają się ich szerokości, ale też ich wzajemne położenie, niektóre mogą znikać. I to wszystko bez jednej linijki JavaScriptu.

Powrót do źródeł?

Kiedy w moje głowie dojrzewał pomysł zrobienia WPinternals.pl, wpadł mi w ręce prosty i dość niepozorny motyw Yoko. To był tak naprawdę pierwszy responsywny motyw, któremu poświęciłem więcej uwagi i to był ten moment, kiedy RWD, dotąd jedna z ciekawostek, o której wiedziałem, ale która niespecjalnie mnie interesowała, stała się dla mnie jedną z najważniejszych.

Pamiętam dawne czasy, drugą poławę lat 90-tych kiedy robiłem pierwsze swoje strony WWW. Powszechne były wtedy płynne layouty, w których tekst rozlewał się w zależności od szerokości okna przeglądarki. To nie był przypadek tylko konsekwencja logiki, która leżała u podstaw HTML’a. Jest to język, którego zadaniem jest reprezentacja struktury tekstu – określenie co w nim jest tytułem, co nagłówkiem rozdziału lub podrozdziału, co jest warte podkreślenia, a co jest cytatem oraz określenie powiązań między dokumentami albo wieloma miejscami tego samego dokumentu.

NCSA Mosaic

NCSA Mosaic dla Windows, wersja 1.0

Reprezentacja tekstu miała być uniwersalna, oderwana od przeglądarki, a trzeba pamiętać, że w tym czasie wciąż używało się jeszcze NCSA Mosaic, Netscape raczkował, Internet Explorer w ogóle się nie liczył, a stosunkowo często używany był Lynx, czyli przeglądarka działająca pod Unixem w trybie tekstowym. W tamtym czasie wszystkie strony sprawdzało się pod Lynxem i musiały być czytelne. Dziś mało kto to robi, chociaż poprawne i użyteczne renderowanie strony w Lynxie jest dobrym sygnałem chociażby na to, że strona zostanie dobrze zinterperetowana i odczytana przez oprogramowanie dla niewidomych i niedowidzących, albo że Google Bot poprawnie ją rozumie i zindeksuje.

Lynx

Serwis WPinternals.pl we współczesnej wersji przeglądarki Lynx (Debian, Gnome Terminal)

Utrzymanie tej kompatybilności między przeglądarkami nie było kilkanaście lat temu jakąś wyszukaną praktyką, po prostu możliwości określania wyglądu stron były bardzo niewielkie, a wymagania estetyczne użytkowników raczej umiarkowane. Strony były proste. Przypominały dzisiejsze blogi, takie ja ten, Składały się z listy zajawek, jakiejś nawigacji i strony artykułu.

Potem jednak wszystko zaczęło się zmieniać, ewoluował HTML. Pierwsze implementacje CSS (IE3, potem Netscape Navigator 4, były koszmarem i panowała powszechna opinia, że to jakiś poroniony wynalazek, ale z czasem CSS dojrzał i w jakimś momencie obudziliśmy się w Internecie, który niemal cały był (w dużej części wciąż jest) poskładany jak gazeta – „do piksla”, ze skomplikowanymi układami modułów, tak jakby był wydrukowany na niezmiennym i nie wymagającym adaptacji papierze.

I nagle się okazało, że prawie z dnia na dzień chcemy ten Internet oglądać na urządzeniach o bardzo różnych rozdzielczościach. To już nie są dwie czy trzy szerokości ekranu jak dawniej – 640, 800 i 1024, z których dwie tak naprawdę były w użyciu. Pojawiły się setki urządzeń mobilnych, za pośrednictwem których ludzie korzystają z sieci. Największa powszechnie używana szerokość ekranu to 1920, takie monitory kosztują już zaledwie kilkaset złotych. Szerokości tanich monitorów i laptopów to okolice 1300px. Najmniejsze to 320 – tryb portrait iPhona i wielu innych komórek.

Nigdy jeszcze nie było takiej rozpiętości w możliwościach urządzeń, a jednocześnie wiemy, że ta różnorodność nie zmniejszy się, wszystkie te urządzenia będą w powszechnym użyciu. W dodatku dziś przyzwyczajenia estetyczne i wymagania funkcjonalne użytkowników nie pozwalają tworzyć stron tak prostych jak kiedyś. Samo skalowanie strony, czyli zwężanie głównej kolumny tekstu do jakichś rozsądnych granic, już nie wystarcza. Żadna strona z płynnym layoutem, mająca więcej niż jedną kolumnę nie będzie dobrze wyglądać i przy szerokości 320px, i po rozciągnięciu do, powiedzmy, 1200px.

RWD rozwiązuje ten problem, ponieważ pozwala nie tylko na skalowanie poszczególnych modułów czy zdjęć na ekranie, ale także na zmianę ich wzajemnego położenia, zmianę wielkości czionek, a nawet ukrywanie niektórych elementów layoutu, bez dotykania HTMLa i tego jak strona jest w nim opisana, bez konieczności używania JavaSciptu, tylko w oparciu o CSS3 i media queries.

Jak działa Responsive Web Design?

Technika RWD jest możliwa dzięki CSS3 media queries. Pozwalają one powiedzieć przeglądarce, że pewien kawałek naszego arkusza styli powinien być zastosowany tyko dla pewnych szerokości ekranu. Na przykład:

#something {
    width: 80%;
}

@media only screen and (max-width: 800px) {
    #something {
        width: 100%
    }
}

Obiekt HTML o identyfikatorze #something będzie miał 80% szerokości, dla szerokości ekranu powyżej 800px. Jeśli będzie wyświetlany na węższym ekranie będzie zajmował 100% jego szerokości. Co ważne, aby przeglądarka zmieniła style nie musimy przeładowywać strony. Wystarczy że szerokośc okna się zmieni, na przykład dlatego, że zwęzimy okno przeglądarki, albo dlatego, że obrócimy naszego iPada z położenia landscape w położenie portrait i zostaną zastosowane style dla danej szerokości.

Oczywiście w naszym arkuszu styli możemy umieścić wiele takich media queries, możemy też określić minimalną szerokość dla danego stylu. Przypatrzmy się bardziej złożonemu przykładowi. Zacznijmy od pliku HTML:

<!doctype html>
<html lang="pl-PL" xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <meta name="viewport" content="width=device-width">
</head>
<body>

<div id="just-one-div">
	<p>Zwężaj i rozszerzaj okienko podziwiając kolorki.</p>
</div>

</body>
</html>

Linia 5 dotyczy Microsoft Internet Explorera i mówi, że ma on użyć najnowszego silnika do renderowania strony oraz  żeby załadował rozszerzenie Chrome Frame, jeśli jest zainstalowane. Nawet ze starych wersji Explorera robi ono sensowna przeglądarkę. W linii 6 informujemy przeglądarkę, żeby nie skalowała (nie pomniejszała) strony, tak by zmieściła się cała na ekranie (tak działają niektóre przeglądarki mobilne). Mamy tutaj jednego DIVa o identyfikatorze #just-one-div i zobaczymy najprościej jak zmienia się w zależności od szerokości okna.

Kliknij aby zobaczyć przykład 1.

Arkusz styli dla tej strony wygląda następująco:

body {
	background: #efefef;
}

#just-one-div {
	width: 50%;
	padding: 20px;
	margin: 50px auto;
	text-align: center;
	background: white;
	border: 2px solid black;
	font: bold 20px Arial, sans-serif;
	color: black;
}

@media only screen and (max-width: 900px) {
	#just-one-div {
		background: #FFB658;
	}
}

@media only screen and (max-width: 800px) {
	#just-one-div {
		background: #4D6F82;
	}
}

@media only screen and (max-width: 700px) {
	#just-one-div {
		background: #E3774C;
	}
}

@media only screen and (max-width: 600px) {
	#just-one-div {
		background: #AD413B;
	}
}

@media only screen and (max-width: 500px) {
	#just-one-div {
		color: white;
		background: #73214A;
	}
}

W miarę jak zwężamy okno, zmienia się kolor tła wybranego elementu. Jak widać pozostałe atrybuty pozostają niezmienne, nie musimy więc robić pełnych arkuszy styli dla każdej szerokości, a jedynie zmieniać to, co jest dla nas istotne.

Pełny kod przykładu 1 w pliku ZIP, ze wszystkimi elementami, można pobrać tutaj.

Spróbujmy teraz zrobic cos bardziej użytecznego. W kodzie HTML przykładu zamieńmy naszego DIVa na:

<div id="just-one-div">Media: </div>

oraz zastosujmy następujący arkusz styli:

body {
	background: #efefef;
}

#just-one-div {
	position: fixed;
	top: 10px;
	left: 10px;
	padding: 5px;
	margin: 5px;
	border: 1px solid black;
	font: 12px Arial, sans-serif;
	color: black;
	background: yellow;
}

#just-one-div:after {
	content: "global";
}

@media only screen and (max-width: 1024px) {
	#just-one-div:after {
		content: "1024px - iPad landscape, Kindle Fire landscape";
	}
}

@media only screen and (max-width: 800px) {
	#just-one-div:after {
		content: "800px - Samsung Galaxy II landscape";
	}
}

@media only screen and (max-width: 768px) {
	#just-one-div:after {
		content: "768px - iPad portrait";
	}
}

@media only screen and (max-width: 600px) {
	#just-one-div:after {
		content: "600px - Kindle Fire portrait";
	}
}

@media only screen and (max-width: 480px) {
	#just-one-div:after {
		content: "480px - iPhone landscape, Samsung Galaxy II portrait";
	}
}

@media only screen and (max-width: 320px) {
	#just-one-div:after {
		content: "320px - iPhone portrait";
	}
}

Kliknij aby zobaczyć przykład 2.

Zbudowaliśmy całkiem sensowne narzędzie do debugowania media queries. Wyświetlana jest aktualna szerokość przeglądarki i wybrane urządzenia, które maja taką szerokość ekranu.

Pełny kod przykładu 2 w pliku ZIP można pobrać tutaj.

Czas najwyższy żeby zacząć eksperymentować ze zmianami layoutu. Najprostszy i najczęściej używany układ elementów to zestaw składający się z nagłówka strony, stopki, główniej kolumny z treścia i sidebara.

Typowy layout

Typowy layout prostej strony internetowej

W serwisach responsywnych taki layout zmienia się przy mniejszej szerokości przeglądarki. Wszystkie elementy skalują się do pewnego momentu, aż w końcu sidebar przeskakuje pod kolumnę z treścią. Zobaczmy jak to się dzieje na prostym przykładzie. W kodzie HTML strony zdefiniujmy wszystkie potrzebne elementy:

<div id="wrap">
	<div id="header"></div>
	<div id="content"></div>
	<div id="sidebar"></div>
	<div id="footer"></div>
</div>

a następnie użyjmy odpowiedniego arkusza styli

body {
	background: #dedede;
}

div {
	background: #065AB1;
	color: white;

	border: none;
	padding: 0;
	margin: 0;
}

#wrap {
	width: 90%;
	float: none;
	margin: 0 auto;
	border: 0;
}

#header {
	float: left;
	width: 100%;
	margin: 0 0 20px 0;
}

#content {
	clear: both;
	width: 70%;
	float: left;
	margin: 0 5% 0 0;
}

#sidebar {
	width: 25%;
	float: right;
	margin: 0;
}

#footer {
	clear: both;
	float: left;
	width: 100%;
	margin: 20px 0 0 0;
}

#header:after  {	content: "header"; }
#content:after {	content: "content"; }
#sidebar:after {	content: "sidebar"; }
#footer:after  {	content: "footer"; }

@media only screen and (max-width: 800px) {
	#content {
		width: 100%;
	}

	#sidebar {
		clear: both;
		float: left;
		margin-top: 20px;
		width: 100%;
	}
}

Kliknij aby zobaczyć przykład 3.

Abu uprościć przykład nie wpisywaliśmy w poszczególne bloki żadnej treści. Zostały ustawione tylko niezbędne atrybuty.

Pełny kod przykładu 3 w pliku ZIP można pobrać tutaj.

Bardzo często robiąc responsywny serwis musimy się liczyć z dodatkowymi utrudnieniami. Jeżeli chcemy wyświetlać reklamę Google AdSense na sidebarze, nie powinien się on zwężać poniżej szerokości wybranej przez nas formy reklamowej (np. boksu 300 x 250). W takim wypadku będziemy musieli użyć atrybutu min-width i niestety poniżej pewnej szerokości nie możemy już liczyć na to, że sidebar i główna kolumna z treścią będą się skalować w stałej proporcji (w procentach). Często layout, który robimy ma więcej niż dwie kolumny, to również jest utrudnienie. Możemy też chcieć aby sidebar nie „spadał” w całości poniżej bloku z treścią, tylko żeby po zwężeniu strony jego część pojawiła się powyżej, a część poniżej. Ponieważ najczęściej zbudowanie dobrze zachowującego się layoutu responsywnego wymaga pewnej precyzji, zawsze należy zresetować wszystkie style.

Kolejny przykład pokazuje układ trójkolumnowy który adaptuje się do szerokości przeglądarki bez skalowania. Warto wrócić uwagę na zachowanie trzeciej kolumny, która poniżej szerokości 1024 piksli „spada” pod pierwsze dwie kolumny, ale dodatkowo dzieli się, i to w ten sposób, że zmienia się kolejność elementów.

Adaptacja layoutu trojkolumnowego

Kliknij aby zobaczyć przykład 4.

Pełny kod przykładu 4 w pliku ZIP można pobrać tutaj.

Wada takiej adaptacji bez żadnego skalowania jest to, że przy szerokościach pomiędzy granicznymi (tymi dla których określono media query) strona duże marginesy. Layout zaraz po złamaniu ma 50% pustej przestrzeni. Dlatego warto, żeby poszczególne elementy choć trochę się skalowały. Pokazujemy to w kolejnym przykładzie, gdzie ten sam layout nie tylko się tak samo adaptuje ale też skaluje.

Kliknij aby zobaczyć przykład 5.

Pełny kod przykładu 5 w pliku ZIP można pobrać tutaj.

Dlaczego RWD jest taki ważny

W swoich zaleceniach dla webmasterów Google opowiedział się zdecydowanie po stronie RWD, określając, że jest to najlepsza metoda na budowę serwisów dla urządzeń mobilnych, znacznie lepsza i bardziej pożądana niż tworzenie drugiej, mobilnej wersji. Dlaczego jest to rozwiązanie tak dobre, i wspierane przez liderów branży?

  • Przede wszystkim mamy zawsze jeden kod HTML, jedną strukturę strony, a zmieniają się tylko style. To znaczy, że nie tylko każda przeglądarka, ale też boty indeksujące widzą stronę zawsze w ten sam sposób. Serwis ma też zawsze ten sam zestaw linków wewnętrznych.
  • Poprawnie zrobiony serwis responsywny jest future ready – gotowy na przyszłe wyzwania, na nowe urządzenia, które się pojawią, na nowe rozdzielczości. Jest znacznie większa szansa, że nie „zestarzeje się” tak szybko.
  • Serwis responsywny wygląda dobrze nie tylko na różnych urządzeniach ale też dostosowuje swój wygląd do szerokości normalnej, desktopowej przeglądarki. Jeśli w danym momencie mamy ciasno na ekranie, korzystamy z wielu okien, możemy go zwęzić bez obawy, że pojawi się dolny scrollbar, który zabija natychmiast użyteczność każdej strony.
  • Przy dobrym podejściu i odrobinie wprawy RWD jest po prostu tani. Nie tylko dlatego, że taniej jest zrobić jeden serwis niż kilka – a to nasz czeka kiedy będziemy chcieli robić wersje dla różnych urządzeń – ale też dlatego, że później jest znacznie tańszy w utrzymaniu. Mamy po prostu tylko jeden serwis, w którym musimy dokonywać zmian. Koszt RWD rośnie i to nieliniowo jeśli dramatycznie rośnie skala komplikacji serwisu, liczba różnych stosowanych layoutów i ich komplikacja, czyli liczba użytych modułów i ich różnorodność. W jakimś momencie zapanowanie nad tym dla różnych szerokości zaczyna się zbliżać do punktu, w którym właściwie trzeba zrobić kilka oddzielnych projektów. Tylko, że powinniśmy sobie zadać pytania, skoro doszliśmy do takiego stanu – czy aby na pewno to, co robimy ma sens? Czy projekt naszego serwisu nie poszedł kompletnie „w maliny”? Stąd ostatnia z zalet RWD, którą chciałbym podkreślić:
  • Konieczność myślenia wieloma szerokościami i poradzenia sobie ze zmianami layoutu silnie dopinguje do robienia prostych i przejrzystych serwisów o jasnej strukturze i płaskiej nawigacji. Po okresie dominacji koszmarnie pogmatwanych i nabitych setkami modułów stron, to bardzo ważny trend.

O czym warto pamiętać  stosując Responsive Web Design

Serwis powinien zawsze wyglądać dobrze

Odruchem każdego, kto zabiera się za robienie strony w RWD jest ustalenie media queries dla typowych szerokości najpopularniejszych urządzeń (1024, 800, 768, 620, 480, 320). Chociaż nie musi to dać złych efektów, nie ma powodu, dla którego powinniśmy się tego trzymać. Powstaje coraz więcej nowych urządzeń mobilnych, lawinowo rośnie liczba nowych modeli tabletów, producenci prześcigają się w dogadzaniu różnym grupom użytkownikom manewrując często rozmiarami i rozdzielczością ekranu. Nawet jeśli dziś dominują jakieś rozdzielczości, raptem za pół roku może się okazać, że najpopularniejsze są już inne.

Pisałem już wyżej, że bardzo ważne jest także zachowanie serwisu responsywnego w zwykłej przeglądarce, a tu już nigdy nie wiemy jaki będzie wybór użytkownika. Dlatego punkty przełączenia styli powinny być dobrane zawsze tam gdzie zwężany lub poszerzany serwis zaczyna wyglądać źle. Wielu twórców stron RWD poleca rozpoczynanie od najwęższego możliwego layoutu i ustawianie punktów zmiany styli tam gdzie podczas rozszerzania zaczyna on się już źle prezentować

Nie należy ukrywać treści

Choć jest to oczywiście możliwe dzięki zastosowania display:none, nie należy prawie nigdy przy zmianie szerokości ukrywać elementów treściowych.

Nie wolno karać użytkowników urządzeń mobilnych ukrywając część informacji, po to aby prezentowane strony były mniejsze. Oczywiście jest jakimś problemem ładowanie strony takiej jak ta, z wieloma dużymi obrazkami na przykład na iPhonie, ale są inne sposoby żeby uczynić ją lżejszą (to temat na oddzielny tekst). Ukrywanie części treści jest złym wyborem.

Jak od każdej reguły i od tej są wyjątki. Jeśli na przykład miniatury obrazków przy wypisach z artykułów nie maja roli informacyjnej, a służą bardziej jako bullety czy po prostu dekoracja, możemy je ukryć dla najwęższych wersji layoutu (tak też robię na WPinternals). Możemy je ukryć dokładnie tak samo jak inne elementy wystroju strony, jeśli nie rujnuje to komunikacji strony.

RWD to nie wszystko

Tworząc strony dla różnych urządzeń należy pamiętać, że layout to nie wszystko. Poprzez odpowiednie API urządzeni te dają specyficzne dla siebie możliwości, i jeśli to jest możliwe strona powinna je wykorzystywać. Na telefonie komórkowym może to być dostęp do lokalizacji użytkownika, nawiązanie połączeni głosowego, interface dotykowy, itp.

Inne projektowanie

Projektowanie dobrych stron w RWD wymaga pewnej edukacji i zmiany przyzwyczajeń nie tylko u programistów. W znacznie większym stopniu muszą się dostosować projektanci WWW i graficy. Tu nie wystarczy już zrobić jednego PSD dopieszczonego do piksla. Trzeba sobie zdawać sprawę, które elementy naturalnie przeniosą się na layout responsywny, a które będą sprawić ogromne problemy. Mam nadzieję, że ten tekst w na tyle ludzki sposób przedstawia zagadnienie, że może służyć jako materiał wprowadzający również dla grafików i projektantów.

Powiadomimy Cię o nowych artykułach

Komentarzy: 31

  1. Marku, a może byś wystąpił na tegorocznym WordCampie w Gdańsku z prezentacją na ten temat?

    • Niestety wygląda na to, że w tym czasie w październiku nie ma szans, ale jeszcze powalczę. Dobry pomysł, generalnie chętnie przyłożę się do propagacji RWD.

      • Wielka szkoda, że nie mogłeś być. Marek, a może byś zrobił zrobił pogadankę na ten temat na WordUpie w styczniu?

        Cieszę się niezmiernie, że znów tutaj pojawią się nowe artykuły. Jak zawsze, jestem pod wrażeniem.

  2. Chylę czoła do samej podłogi. Wpis nic dodać nic ująć. Trafia na szczyt składników z których chciałbym stworzyć własny motyw. Po stokroć dzięki, bo bardziej przyjemnie i prosto chyba już nie można opisać. Subskrybuję o/

  3. Dobry tekst i madry. Ciesze sie, ze sa przyklady ktore rozjasniaja wiele rzeczy. Czytalo sie na „jednym tchu” a to naprawde dobrze swiadczy o autorze.

  4. ten cały wymysł>>>> Responsive Web Design to trochę przerost treści nad formą, może kolejny pomysł, żeby zmusić klientów do wydania kilkuset złotych? Zbyt duży podziw dla trendów zachodnich jest zgubny, a tutaj strasznie nim śmierdzi.

    Przed chwilą przeanalizowałem ruch, który mam u siebie. Niecałe 2% użytkowników spośród miesięcznych 450.000 odwiedzało serwis na urządzeniach mobilnych. Zdecydowanie za mało, aby opłacało się wdrażać na stronach już istniejących RWD.

    Swoją drogą nie jestem przeciw, ale nie ma czym się zachwycać. Rozdzielczość pracy tabletów jest na tyle wysoka oby obyło się bez tego. Z mojego (zapewne niewielkiego) doświadczenia mogę dodać, że wdrażanie go pod rozdzielczości 620, 480, 320 to zupełna strata czasu i próba dopasowania strony dla jeszcze mniejszej liczby użytkowników, kosztem większej pracy, która w żaden sposób się nie zwróci. Ogólnie mam mieszane uczucia, czy to nie jest przypadkiem taka sztuka dla sztuki. Co innego jak ktoś prowadzi blog/serwis o tematyce mobilnej, wtedy ma to sens, ale ogólnie raczej nie warto. (jest to moje subiektywne odczucie).

    Co nie zmienia faktu, że artykuł trzyma wysoki poziom merytoryczny.

    • Świat się zmienia i dzisiejsze 2% może się kiedyś stać 80%. Szczerze mówiąc ciężko sobie wyobrazić inny rozwój wydarzeń.

      Faktycznie, masz rację, że na razie to nie jest duża część ruchu i w wypadku wielu serwisów inwestycja w „mobilność” może być problematyczna, zwłaszcza jeśli jest to przeróbka działającego serwisu. Tylko, że RWD nie jest rozrzutnością, a właśnie tanim i skalowalnym sposobem żeby z problemu wybrnąć.

      Zamiast inwestować w kosztowne aplikacje natywne, wystarczy pewna zmiana perspektywy i stosunkowo niewielkim kosztem Twój serwis (zwłaszcza gdy mówimy o nowo robionym serwisie) będzie się wygodnie oglądał na każdym urządzeniu. Możesz pójść tylko kawałek tą drogą, łatwo i tanio, albo zrobić totalne cacuszko ze wszystkimi możliwymi wodotryskami. To jest własnie zaleta tego rozwiązania – wystarczy że trochę się postarasz i już są jakieś efekty. Kiedy od początku projektujesz serwis nie jest to specjalnie kosztowne, więcej w tym zabawy niż kłopotu. Ja starych serwisów nie ruszam, ale nowe robię już responsywnie.

      Swoją drogą, pojechałeś z tymi „trendami zachodnimi”. Jakoś umiesz odróżnić zachód Internetu? 🙂

      • Franek,

        Nie wiem czy Twój serwis posiada wersję mobilną, ale jeżeli nie… to może jest to wytłumaczenie owych 2%?

        PS Artykuł dobry, brawo!

    • no nie wiem czy to 2%, ja ani moi znajomi nie korzystamy z czegoś takiego, przyznam się sam nie wiem gdzie są ludzie korzystający z urządzeń mobilnych do przeglądania sieci, przyznam się, że o nich tylko czytam.Ani moi znajomi ani ja nie korzystamy z takich urządzeń, ale jesteśmy zacofani…

      „zachód sieci” jest trochę inny. Kiedy u nas strony sprzedażowe, które sprzedawały były schludne, u nich najlepiej sprzedawały strony, które wyglądały paskudnie. Kiedy u nas ktoś nie ma pomysłu na serwis idzie na zachód i go szuka, tam jest więcej 🙂 ale to może być moje błędne widzenie faktów.

      @Marek Soból
      Rzeczywiście w porównaniu do aplikacji RWD jest o wiele tańsze

      • Franek, powiem Ci tak: Kiedy prezes dużej firmy XYZ wpadnie na pomysł by wszystkie swoje oszczędności oddać firmie, którą wyszuka na ekranie swojego Iphone5 będąc w hotelu Hilton z jedną ze swoich sekretarek…. to albo Twoja firma będzie drenować jego kieszeń albo firma kogoś innego kto był trochę bardziej otwarty na przyszłość.

        IE6 kiedyś też było super – korzystało z niego 80% społeczeństwa – bo był czas gdy nie było praktycznie nic innego oprócz IE6 – a dzisiaj? Minęło kilka lat i tej przeglądarki już nie ma na rynku – tak samo może być z firmą, która zdecyduje się nie inwestować w RWD.

        Warto również powiedzieć, że RWD można zawsze jakby „dorobić” – nie od razu klient musi zlecać Ci wykonanie strony responsywnej. Ja na co dzień posługuję się Twitter Bootstrap Framework a kod piszę tak by był łatwo rozszerzalny. Nie ma dla mnie żadnego problemu by klientowi, który dziś nie ma kasy dorobić responsywne wariacje za 3 miesiące kiedy tę kasę będzie mieć – bo gdy jakby fasada (desktop) wykonana jest na Bootstrapie to jest co rozbudowywać a praca jest zarazem przyjemna i szybka.

        Powiem jeszcze zupełnie z innej beczki – ja miałem podobne podejście do WordPressa kilka lat temu – myślałem, że jest to po prostu kolejny system blogowy, nie ma co się tym specjalnie przejmować itp itd i wiesz co…. byłem strasznie mega w plecy – bywało tak, że w miesiącu potrafiły do mnie spłynąć 2-3 zamówienia duże na wordpressa… których nie umiałem obsłużyć i poszły sobie do kieszeni kogoś innego 🙁 Tak samo będzie w przypadku każdego webdevelopera, który nie będzie potrafił stworzyć strony z wykorzystaniem RWD.

  5. Fajnie jest czytanie dobrego artykułu na temat RWD, którego szuka się od kilku dni i napisany jest w taki sposób. Moim zdanie, jesteśmy niejako świadkami narodzin nowej techniki projektowania stron, która niebawem będzie podstawą wymaganą przez klientów – właśnie to mnie najbardziej cieszy 🙂

    Pozdrawiam

    • Podpinając się pod wypowiedź kolegi dodam tylko tyle, że może w końcu dzięki RWD znikną te wszystkie brzydkie, krzywe jak cholera projekty graficzne wykonane przez pseudo grafików lub po prostu osoby nie nadające się do tego fachu. Jakby nie patrzeć większość ze znanych mi grafików, którzy mają za zadanie sprojektować stronę responsywną korzysta z czegoś takiego jak GRID – wierzcie mi, to już jest jak dla mnie bardzo duża zmiana – projekty które dziś przychodzą do mnie są w większości proste, nie przebajerowane – takie jakie być powinny – estetyczne ale zarazem atrakcyjne dla oka.

  6. Na IE8 przykład 3 nie działa. Pozostałe pewnie też. Why?

    • Na IE8 nie działają media queries. Można kombinować z JS, ale ja w swoich serwisach layout pod IE8 usztywniam na 1024 (alternatywny stylesheet) Nie chce mi się tracić czasu na wspieranie dla zasady badziwnych przeglądarek z minionych epok. Ostatecznie strona usztywniona na 1024 na IE8 (powiedzmy na XP) jest w porządku i z punktu widzenia użytkownika normalna, po co kombinować. Na iPhonie IE8 przeciez nie ma 🙂

      • Może i badziewna przeglądarka, zgadzam się (od lat używam Opery, niedawno przeniosłem się na Firefox) ale… wciąż wielu ludzi używa IE. Sorki, takie są realia. Można sobie mówić, że jesteśmy lepsi, że korzystamy z naszych mózgów bardziej logicznie, mamy przeglądarki, które fajnie interpretują standardy itp. ale jak wytłumaczyć panu prezesowi, żeby nie sprawdzał strony w IE tylko w tej.. no… wie pan panie prezesie… a tak.. „mocarelli fajerfoks”… albo w tym „gromie / gronie ?” czy „łoperze”… jak? Klient nie che słuchać o standardach – jemu się źle wyświetla, źle mu zrobiliśmy, nie „łumiemy”… 😉

        • Wtedy piszesz takiemu że przez używanie przegladarki IE moga mu sie wlamac na konto bankowe i okradną go. Chyba trafi do takiego 🙂

  7. Dzięki, właśnie ostatnio naszło mnie na zabawę z RWD 🙂

    Jest może gdzieś spis rozdzielczości, pod które najlepiej to wykorzystywać?

  8. Wszystko pięknie, ale co z transferem w urządzeniach mobilnych 2 Giga od Play kilka wejść na strony zrobioną w RWD i mamy kłopocik.

    • Jeszcze niedawno neostrada miała limity, niedługo limitów po prostu nie będzie nigdzie, znikną podobnie jak znikł komutowany dostęp do internetu i inne tymczasowe formy strzyżenia ludzi przez operatorów. Kłopocik jest zatem niewielki i szybko przemijający 🙂

  9. Artykuł super, rzadko się spotyka w sieci logiczne wywody. Nie zgodzę się jednak z ostatnim komentarzem. Limity będą jakieś zawsze. O ile w świecie w miarę „zachodnim” (czyli europa, stany itp) zasadniczo nie ma tego problemu, o tyle w miejscach które są jakby „przyszłym” targetem internetu, tam to potrwa baaardzo długo. Mam tu na myśli naprzykład Afrykę, A jest to rynek na tyle potężny, że warto się z nim liczyć. Zresztą, widać to po zaangażowaniu chocby Facebooka, który „rozdaje’ tam ludziom telefony z darmowym dostępem do FB. Ale tylko do FB. I to telefony jakie tutaj już się nie spotyka od lat, czyli tylko tekst i ewentualnie jakieś obrazki ANSI.
    Ale z tego też powodu warto robić strony, które można przeglądac nawet w Lynxie, O ile oczywiście naszym targetem nie jest tylko znajomy z sąsiedniego osiedla czy przysłowiowa pani Halinka poszukująca programu TV..
    Ale to tylko tak żeby się czegoś przyczepić 🙂 Jeszcze raz gratuluje umiejętności przekazywania wiedzy.

    • Dziękuję za miłe słowa. Co do limitów – cóż, wszystko zależy od puntu widzenia, od rynku dla którego robi się serwis, itd. ja się nauczyłem przez lata, że jak próbuje się robić serwisy, które naprawdę idealnie działają na wszystkim, to naprawdę na niczym nie działają fajnie i są tak kosztowne w budowie i utrzymaniu, że mogą nigdy nie powstać. Podobnie jak nie można robić gier równając do dołu do najgorszych używanych na rynku komputerów i kart graficznych (bo cala ta branża po prostu byłaby w tej chwili 10 lat do tyłu) podobnie nie sposób równać z serwisami do najgłupszych przeglądarek i najgorszych łącz. Dlatego tak cenię RWD bo przy rozsądnych kosztach pozwala na sporą kompatybilność, dostęp z wielu urządzeń, łatwo jest wyłączyć responsywność dla głupich przeglądarek podając inny arkusz styli i serwis będzie po prostu działał w jednej szerokości. A najważniejsze jest to, że to jest standard future ready. W internecie gdzie nowoczesna strona po trzech latach staje się przestarzała, ważniejsza wydaje mi się kompatybilność z przyszłością 🙂 Oczywiście to trzeba wyważyć – nie ma rozwiązań idealnych, ani uniwersalnej, zawsze słusznej filozofii.

  10. Wielkie dzięki za artykuł! dla mnie genialny, sam próbuje się „przerzucić” na projektowanie RWD ale w internecie ciężko było znaleźć informacje na ten temat podane w fajny sposób jak u ciebie,

    • Bardzo dziękuję. RWD to teraz modny temat, coraz więcej jest ciekawych poradników.

  11. dobrze że trafiłem tutaj 🙂 aktualnie jestem na etapie zbierania informacji jak do tego tamatu podejść i odświeżyć swój web z przed kilku lat 🙂

  12. Super obecnie w Polsce mamy 5 mln użytkowników mobilnych wszystko się zmienia
    więc RWD jest przymusem dla każdego Webmastera.

  13. Dziękuję za bardzo wartościowy poradnik. Dla mnie moment przełomowy, od dziś już nigdy nie stworzę nic nieresponsywnego.

  14. Wreszcie znalazłem coś napisanego po ludzku. Wystarczy raz przeczytać aby bez problemu zrozumieć 🙂
    Stosować ? nie stosować ? „PageSpeed Insights” obecnie jeszcze dla „komórek” -> „Obecnie nie wlicza się do wyniku ogólnego” a co jak zacznie ? Myślę, że wtedy strony nie RWD chyba jednak w wynikach google będą na coraz dalszych stronach wyszukiwań…
    Mam pytanie :
    jak lepiej :
    w head ->
    czy w arkuszu -> @media only screen and (max-width: 980px) {
    }

  15. Merytorycznie świetne! Tylko na Boga, STYLÒW, a nie STYLI!!!!

  16. Czy można z automatu przerobić stronę a jeśli nie szukam osoby która sie tego podejmie, Jakie koszty ?