O Craigu Sharkiem Niegdyś Craig był zadowolony, gdy nazywano go programistą, prelegentem, autorem i rzecznikiem. Od tamtego czasu do tej listy dodał określenie: organizator spotkań oraz konferencji poświęconych językowi JavaScript. Gdyby ktoś jeszcze uzupełnił tę listę o dwa punkty: mąż oraz ojciec, to zbliżyłby się zapewne do wyjaśnienia, dlaczego Craig bardzo często jest wyjątkowo szczęśliwy.

O Andrew Fisherze Andrew uwielbia zabawy z technologiami, zwłaszcza tymi z pogranicza WWW, urządzeń mobilnych, przetwarzania bez granic (ang. ubicomp) oraz danych. Tworzył rozwiązania cyfrowe o charakterze globalnym od samego początku istnienia WWW, pracując dla takich marek, jak Nintendo, peoplesound, Sony, Cotton On, Melbourne Cup oraz Optus. Jest kierownikiem do spraw technologii w JBA — firmie specjalizującej się w zarządzaniu danymi — z siedzibą w Melbourne, w Australii. W swojej pracy koncentruje się na odnajdywaniu sensu w dużych, zmieniających się zbiorach danych. Andrew jest także założycielem Rocket Melbourne — technologicznego start-upu badającego komputery fizyczne oraz internet rzeczy (ang. Web of Things).

O wydawnictwie SitePoint SitePoint specjalizuje się w publikowaniu zabawnych, praktycznych i łatwych do zrozumienia informacji przeznaczonych dla specjalistów zajmujących się projektowaniem i tworzeniem stron WWW. Warto odwiedzić witrynę http://www.sitepoint.com/, by przejrzeć dostępne na niej blogi, książki, biuletyny informacyjne, artykuły oraz fora. Można na niej znaleźć wiele informacji o językach JavaScript, PHP, Ruby, tworzeniu aplikacji na urządzenia mobilne, projektowaniu i tak dalej.

O serii Jump Start Książki z serii Jump Start w szybki i praktyczny sposób przedstawiają języki programowania oraz technologie używane do tworzenia witryn i aplikacji internetowych. Mają one zazwyczaj około 150 stron i można je przeczytać w weekend, zdobywając w ten sposób solidny fundament wiedzy i wiarę w możliwość przeprowadzania samodzielnych eksperymentów.

Wstęp Użytkownicy korzystający ze stworzonych przez Ciebie witryn mogą w ogóle nie wiedzieć, czym jest projektowanie responsywnych stron WWW. Będą wiedzieć jedynie to, że aplikacja działa bądź nie działa, albo że doprowadzenie jej do stanu, w którym można z niej korzystać, wymaga dużo wysiłku. Projektowanie responsywnych stron WWW polega na zapewnieniu użytkownikom jak najlepszych wrażeń podczas korzystania z utworzonych witryn. Przede wszystkim wiąże się to z jak największym ograniczeniem konieczności modyfikowania wielkości okna i przewijania zawartości podczas nawigowania po witrynie, i to niezależnie od tego, czy użytkownik będzie to robił na komputerze stacjonarnym, netbooku, czy też jeszcze mniejszym urządzeniu mobilnym. Techniki wykorzystywane podczas projektowania responsywnych stron WWW zapewniają, że wrażenia użytkowników będą optymalne, a nam zaoszczędzą problemów związanych z dostosowywaniem ich niezależnie dla każdego z użytkowników i urządzeń. Techniki te pomagają rozwiązać poważny i realny problem, którym jest nieznajomość tego, gdzie i w jaki sposób będzie używana nasza aplikacja. Nadszedł więc czas, aby je dokładniej poznać i wykorzystać.

Kto powinien sięgnąć po tę książkę Wszyscy zajmujący się tworzeniem stron WWW, zaczynając od biznesmenów, przez projektantów, korporacje, na programistach kończąc.

Zastosowane konwencje W książce zastosowaliśmy pewne konwencje związane z typografią oraz układem, służące do wyróżniania różnych rodzajów informacji. Przyjrzyjmy się następującym elementom.

Przykładowe kody Fragmenty kodu będą prezentowane przy wykorzystaniu czcionki o stałej szerokości, takiej jak ta:

Doskonały letni dzień

To był doskonały dzień na spacer po parku. Ptaki śpiewały, a dzieci trudziły się w szkole.

10

Responsywne strony WWW

Jeśli prezentowany fragment kodu jest dostępny w przykładach dołączonych do książki, to nad nim zostanie umieszczona nazwa pliku, jak na poniższym przykładzie: example.css .footer { background-color: #CCC; border-top: 1px solid #333; }

Jeśli w treści książki prezentowany jest jedynie fragment zawartości pliku, to zostanie to oznaczone słowem „(fragment)” umieszczonym za nazwą: example.css (fragment) background-color: #CCC;

Jeśli do istniejącego przykładu ma zostać dodany nowy fragment kodu, to zostanie on oznaczony pogrubioną czcionką: function animate() { new variable = "Witaj"; }

W przypadkach, gdy istniejący kod jest wymagany do zapewnienia kontekstu przykładu, zamiast go powtarzać w całości, będziemy umieszczali znak wielokropka: function animate() { ... return new_variable; }

Niektóre fragmenty kodu muszą być wpisane w jednym wierszu, jednak w tej książce, ze względu na ograniczone wymiary strony, musiały zostać podzielone i zapisane w kilku wierszach tekstu. Symbol  oznacza znaki nowego wiersza dodane wyłącznie w celu zapewnienia odpowiedniego formatowania. Znaki te należy pominąć. URL.open("http://www.sitepoint.com/responsive-web-design-real-usertesting/?responsive1");

Podziękowania Craig Sharkie Ta książka nie byłaby tym, czym jest, gdyby nie rady, których udzielał nam zespół wydawnictwa SitePoint. To właśnie ten zespół wyznaczył tempo oraz rytm prac nad publikacją, a jego styl wywarł wpływ na cały proces. Ale jeszcze większe uznanie należy się zespołowi witryny Web Directions: http://webdirect ions.org. John Allsopp oraz Maxine Sherrin wraz z Guyem Leechem i Lisą Miller stworzyli nie tylko wspaniałą witrynę, która stanowiła podstawę dla przykładów zamieszczonych w tej książce, lecz także serię spotkań technologicznych, które co roku mnie inspirują.

Andrew Fisher Wpisywanie słów na komputerze jest łatwe; znacznie trudniej sprawić, by miały one sens. Dziękuję Simonowi, Dianie oraz Kelly z wydawnictwa SitePoint za wysiłki nad nadaniem tej książce sensu, a to, że czyta się ją dobrze, jest w większym stopniu zasługą ich niż moją. Craig nie tylko napisał większość treści, lecz także przejrzał fragmenty mojego autorstwa, więc chciałbym mu podziękować za doskonałe opinie oraz za zapewnienie mi możliwości współpracy.

Rozdział

Zapewnianie responsywności Im dłużej pracujemy nad projektami związanymi z WWW, tym łatwiej możemy zauważyć, ile prawdy jest w powiedzeniu, że jedynym pewnikiem są zmiany. Widzieliśmy już, jak zmieniały się używane języki programowania, wzorce projektowe, popularność przeglądarek, a ostatnio urządzenia używane do przeglądania zasobów internetu oraz kierunki ewolucji aplikacji sieciowych. I to właśnie ta ostatnia zmiana wymusza projektowanie responsywnych stron WWW (ang. responsive web design, w skrócie RWD; choć używane jest także określenie elastyczne strony WWW) — podejście do sposobu projektowania stron WWW w znacznej mierze dotyczące działań użytkownika. Zmiany zachodzące w urządzeniach, których używamy, nie są niczym nowym, inne jest jednak ich tempo oraz zakres. Tak niedawno naszym największym wyzwaniem było podjęcie decyzji, czy tworząc strony, powinniśmy dokonać tego wielkiego kroku naprzód i zmienić ich szerokość z 800 na 1024 piksele. Dokonując tej zmiany, myśleliśmy, że kupujemy sobie trochę czasu i że prądy technologicznych zmian nieco zwolnią, jednak technologia miała inne zdanie na ten temat. Wraz z powiększeniem wymiarów monitorów i ekranów naszym nowym wyzwaniem było określenie, ile z całej dostępnej powierzchni należy wykorzystać, gdyż wzrosła także rozdzielczość używanych ekranów. Jednak powiększenie się liczby pikseli na większych ekranach nie jest jedyną zmianą, gdyż nagły wzrost popularności urządzeń mobilnych oznacza także zmniejszenie się ekranów, na jakich są wyświetlane strony WWW. Obecnie musimy także uwzględniać urządzenia mobilne działające w układzie pionowym i poziomym, tablety działające także w tych dwóch układach, laptopy, komputery stacjonarne, przeróżne wymiary i proporcje monitorów, a nawet odbiorniki telewizyjne — na tych wszystkich urządzeniach mogą być wyświetlane strony WWW. Tym, czego nam potrzeba, jest rozwiązanie pozwalające, by projektowane strony mogły się elastycznie dostosować do urządzenia, na którym zostały wyświetlone, tak jak strona przedstawiona na rysunku 1.1, choć obrazuje on jedynie wierzchołek góry lodowej. I tak właśnie narodziła się metodologia projektowania responsywnych stron WWW (określana także jako metodologia RWD).

14

Responsywne strony WWW

Rysunek 1.1. Różny wygląd strony sitepoint.com na różnych urządzeniach to tylko wierzchołek góry lodowej

Oprócz zmian w urządzeniach, na których mogą być wyświetlane aplikacje, zmianom uległy także sposoby interakcji użytkowników z tymi aplikacjami. Interfejs oddzielający użytkownika od aplikacji jest coraz mniej dostrzegalny i jednocześnie staje się coraz bardziej naturalny. Gdy specjaliści od dostępności wciąż nawoływali do ulepszania sposobów obsługi myszy i klawiatury, nasze aplikacje nagle musiały poradzić sobie z nowym wyzwaniem — zdarzeniami związanymi z dotykiem, gestami oraz kontrolerami do gier używanymi jako urządzenia do wprowadzania danych. Wprowadzenie technologii Siri w urządzeniach firmy Apple oraz zmiany, które w ostatnim czasie wprowadzono w Google TV, oznaczają, że sterowanie głosem nie jest już jedynie ciekawostką znaną z filmów fantastycznonaukowych. Pod terminem metodologii RWD kryje się grupa technik i technologii, które sprawiają, że stworzenie jednej aplikacji działającej na wielu różnych urządzeniach staje się tak praktyczne, jak to tylko możliwe. Potrzebę tę zauważają nie tylko osoby zawodowo zajmujące się tworzeniem stron i aplikacji internetowych, także wielkie i małe firmy poszukują sposobów na coraz szersze udostępnianie publikowanych treści niezależnie od tego, gdzie i jak użytkownicy będą z nich korzystać.

Napisz raz i uruchom Ethan Marcotte, uznawany za „ojca” metodologii RWD, w maju 2010 roku opublikował na witrynie A List Apart artykuł, któremu przebiegle nadał tytuł „Responsive Web Design”1. Koncentruje się w nim na płynnych siatkach (ang. fluid grids), responsywnych obrazach oraz zapytaniach o media (ang. media queries), stanowiących technologiczne podstawy metodologii RWD.

1

http://www.alistapart.com/articles/responsive-web-design/.

ZAPEWNIANIE RESPONSYWNOŚCI

Marcotte wskazał także konieczność określenia nowego sposobu przygotowywania treści, dostosowanego do tych trzech podstaw technologicznych. Celem tych kluczowych technologii jest próba zbliżenia się do nieuchwytnego celu, jakim jest „możliwość napisania jednej aplikacji, którą będzie można wszędzie uruchamiać”. Dzięki zastosowaniu metodologii RWD oraz będących jej efektem zmian w sposobach generacji treści jesteśmy w stanie sprawić, by nasze aplikacje dostosowywały się do urządzeń stosowanych przez użytkowników. Zamiast na urządzeniach, koncentrujemy się zatem na użytkownikach. Marcotte, doświadczony programista, spędził lata na badaniach i przekonywaniu do technik, które przedstawił w swoim artykule. Ze względu na to, że opierają się one na dokładnie przebadanych najlepszych praktykach programistycznych, trudności związane z rozpoczęciem ich stosowania są znacznie zredukowane, a wielu projektantów nieświadomie korzysta już z niektórych elementów tych technik. Oznacza to także, że nawet niewielkie zmiany w sposobie dostarczania aplikacji mogą mieć znaczące konsekwencje dla użytkowników i niejednokrotnie mogą przygotować naszą aplikację do dalszego rozwoju. Zważywszy na gwałtowny wzrost popularności urządzeń mobilnych, ich wielkość i rozdzielczość może oznaczać, że możliwości wykorzystania naszych aplikacji ulegną ograniczeniu. Choć użytkownicy z konieczności nauczyli się już używać podwójnego dotknięcia w celu powiększania stron, to jednak techniki RWD pozwolą im tego uniknąć i poprawić ich wrażenia. Prosta zmiana pozwala zapewnić lepsze domyślne wrażenia użytkowników korzystających z urządzeń o mniejszych ekranach lub z urządzeń, w których szerokość ekranu może się zmieniać zależnie od ułożenia. Banalna operacja — dodanie elementu meta viewport — pozwala dostosować witrynę do urządzeń mobilnych i tabletów, zakładając oczywiście, że użyjemy przy tym odpowiednich atrybutów. Możliwości, jakie zapewnia ten element, przedstawimy bardziej szczegółowo w dalszej części rozdziału, jak na razie jednak dobrze ilustruje je rysunek 1.2. W przeglądarce przedstawionej z lewej strony zawartość została wyświetlona w sposób, jakiego można oczekiwać po tradycyjnej witrynie oglądanej na urządzeniu mobilnym. Z kolei zawartość przeglądarki widocznej z prawej strony została wyświetlona w znacznie bardziej użyteczny sposób. Oczywiście nie jest to jedyna zmiana, jakiej będą potrzebować tworzone aplikacje, jednak ten przykład powinien zaostrzyć apetyt czytelnika na to, co znajdzie w dalszej części książki. Wciąż jednak pozostaje miejsce na dalsze usprawnienia. Rysunek 1.3 przedstawia tę samą witrynę wyświetloną na iPadzie. Na pierwszym zrzucie nie określono obszaru prezentacyjnego, na kolejnym został on określony. To nie wszystkie narzędzia, jakimi dysponujemy, jednak techniki RWD wciąż stają się coraz potężniejsze, a my dopiero zaczęliśmy. Czy teraz moglibyśmy się jeszcze zatrzymać? Dzięki płynnym siatkom, responsywnym obrazom i zapytaniom medialnym nasz arsenał jest niemal w pełni przygotowany.

15

16

Responsywne strony WWW

Rysunek 1.2. Zastosowanie właściwości określających obszar prezentacyjny na witrynie SitePoint

Rysunek 1.3. Strona wyświetlona w Safari na iPadzie bez określania obszaru prezentacyjnego i w razie jego określenia

Filary projektowania responsywnych stron WWW W kolejnych czterech rozdziałach zostaną opisane filary metodologii RWD: płynne siatki, responsywne obrazy, zapytania medialne oraz treści dynamiczne. Zacznijmy od przedstawienia ogólnego obrazu rozwiązania. Płynne siatki (ang. fluid grids), będące pierwszym filarem metodologii RWD, są naturalnym spadkobiercą płynnych układów. Były one niezwykle popularne w roku 2006, kiedy

ZAPEWNIANIE RESPONSYWNOŚCI

to najbardziej nurtującym zagadnieniem był wybór pomiędzy stronami o szerokości 800 lub 1024 pikseli2. Pewne znaczenie ma tu także problem doboru odpowiedniej typografii, gdyż prezentowane treści muszą być równie elastyczne jak sam układ. Rozmieszczanie zawartości stron w siatkach i kolumnach było marzeniem projektantów już od samego początku istnienia WWW. Dostępne implementacje muszą jeszcze dowieść swojej wartości, choć wprowadzenie przez organizację W3C odpowiednich zmian w standardach może prowadzić do zmiany trendów. Ze względu na to, że ani w języku HTML, ani nawet w HTML-u 5 nie ma elementów przeznaczonych do tworzenia kolumn lub siatek, będzie nam potrzebne odpowiednie narzędzie. Najpopularniejszym rozwiązaniem pozwalającym na szybkie tworzenie struktury siatki są platformy, takie jak 960.gs3 przedstawiona na rysunku 1.4.

Rysunek 1.4. Strona przedstawiająca wpis w Wikipedii, z nałożoną 16-kolumnową strukturą siatki 960 Grid System

Jedną z zalet korzystania z platform jest szybkość tworzenia stron; kod HTML i CSS, na którym są one oparte, nadaje się do zastosowania w wielu przeglądarkach, zapewnia zgodność wstecz, jest rozszerzalny i dostępny dla bardzo wielu programistów. Kiedy już rozwiązanie W3C będzie obsługiwane w przeglądarkach, zapewni nam ogromne możliwości i elastyczność, jednak do czasu gdy to nastąpi, nasze potrzeby w pełni zaspokoją biblioteki i narzędzia przedstawione w rozdziale 2. 2

http://www.cameronmoll.com/archives/001220.html.

3

http://960.gs/.

17

18

Responsywne strony WWW

Drugi filar, responsywne obrazy (bądź też obrazy adaptacyjne, jak określa je specyfikacja HTML5), służy do rozwiązywania dwóch problemów: trudności z przewidzeniem wymiarów, jakie będzie miał wyświetlony obraz, oraz rozdzielczości, w jakiej może on zostać wyświetlony. Aby sprostać tym wymaganiom, stosowane są różne techniki — zaczynając od sposobów pozwalających na lepsze dostosowywanie się obrazów do płynnych siatek i układów, a kończąc na nowych propozycjach HTML5, które mają pozwolić, by na różnych urządzeniach były stosowane obrazy pobierane z różnych źródeł. To, jak zastosujemy te wszystkie techniki, by uzyskać jak najlepszy rezultat, sprowadza się do określenia równowagi pomiędzy naszymi możliwościami oraz oczekiwaniami użytkownika. I właśnie tym zagadnieniem zajmiemy się w rozdziale 3. Problem z obrazami polega na tym, że siatki są elementem strukturalnym, natomiast jakość obrazów oraz wrażenia, jakie zapewniają, są odczuwalne dla użytkowników. Użytkownicy zapewne nawet nie zauważą faktu użycia siatki — będą jedynie z radością korzystali z możliwości, jakie ona zapewnia — natomiast prawdopodobnie zwrócą uwagę na rozciągnięte, ziarniste lub zbyt małe obrazy. Dodatkowo wielu producentów zmienia gęstość pikseli na ekranach swoich urządzeń, przez co wiele z nich jest w stanie wyświetlać 1,5 – 2 razy więcej pikseli. Jeśli nasza aplikacja nie będzie w stanie ich wykorzystać, użytkownicy mogą się czuć oszukani. I na odwrót: jeśli nasza aplikacja będzie używać wyłącznie obrazów przystosowanych do ekranów o dużej gęstości, a jej użytkownicy będą w przeważającym stopniu korzystali ze starszych urządzeń mobilnych lub komputerów stacjonarnych, to okaże się, że zmusimy ich do pobierania obrazów, których ich przeglądarki nie są w stanie odpowiednio wykorzystać. A to zarówno dla użytkowników, jak i dla nas oznacza straconą przepustowość, nie wspominając już nawet o zmarnowanym wysiłku naszego zespołu. Rysunek 1.5 ilustruje przykład rozdzielczości obrazów zaczerpnięty z witryny HTML5 Rocks4. Pawian z lewej strony został wyświetlony w obszarze o wielkości 100×100 pikseli, czyli takim, jaki określono w kodzie strony. Z prawej strony widoczny jest obraz o wymiarach 200×200 pikseli, który zostanie wyświetlony w urządzeniach wyposażonych w ekrany o dużej gęstości. Natomiast w środku został umieszczony superostry obraz o wymiarach 200×200 pikseli, który będzie wyświetlony w podanym na stronie obszarze 100×100 pikseli.

Rysunek 1.5. Rozdzielczość obrazów przedstawiona na witrynie HTML5 Rocks na przykładzie pawianów 4

http://www.html5rocks.com/en/mobile/high-dpi/.

ZAPEWNIANIE RESPONSYWNOŚCI

Ostatnim filarem technologicznym przedstawionym przez Marcotte’a są zapytania medialne. Spośród wszystkich wymienionych rozwiązań stanowią one najpotężniejsze narzędzie języka HTML5, a dodatkowo są najlepiej obsługiwane w wielu przeglądarkach. Wprawdzie bez dodatkowych sztuczek nie będą one działać prawidłowo w starszych wersjach Internet Explorera — wcześniejszych od IE 9 — niemniej jednak sposoby rozszerzania możliwości tych przeglądarek są dobrze znane i powszechnie akceptowane. Zapytania medialne działają na urządzeniach i w przeglądarkach, na których nasze aplikacje są używane, zapewniając aplikacjom możliwość dostosowania się do tych urządzeń, co pokazaliśmy na rysunku 1.6.

Rysunek 1.6. Prezentowane na witrynie mediaqueri.es efekty zastosowania zapytań medialnych na przykładach stron Designmodo oraz Incredible Types

Możliwości urządzeń są stosowane w zapytaniach medialnych, a te z kolei określają, które style CSS zostaną użyte przez aplikację. Zapytania medialne badają możliwości urządzenia, na przykład sprawdzają, czy konkretna przeglądarka jest w stanie zrealizować podane wymagania. Jeśli tak, to zostanie wczytany odpowiedni plik CSS lub wykonane będą określone reguły CSS:

Składnia zapytań medialnych jest oparta na typach mediów, które zaczęto stosować już w CSS 2.0 (standard ten pojawił się w 1998 roku, a jego główne uzupełnienie — w 2008), zatem ich podstawy powinny być dobrze znane.

19

20

Responsywne strony WWW

Pierwszy z powyższych przykładów przedstawia zastosowanie typu medium, natomiast drugi — przykład użycia zapytania medialnego. Gdyby nie fakt, że w atrybucie media drugiego elementu link zostało umieszczone wyrażenie, a nie lista typów oddzielonych od siebie przecinkami, oba te elementy byłyby identyczne. Wszystkie możliwości, jakie dają zapytania medialne, przedstawimy dokładnie w rozdziale 4. Ostatnim filarem są dynamiczne treści, które zostały omówione w rozdziale 5. Stanowią one najnowszy dodatek do technik RWD i ciągle są rozwijane. Zwolennicy metodologii RWD zgadzają się, że konieczna jest strategia tworzenia treści, której centralnym punktem byłby użytkownik, niemniej jednak wciąż konieczne jest uzyskanie konsensusu co do konkretnego rozwiązania, a prawdopodobieństwo, że nastąpi to szybko, jest raczej niewielkie. Metodologia RWD nie tylko proponuje rozwiązania techniczne pozwalające dopasowywać treści do urządzeń, jakimi dysponuje użytkownik, lecz także stara się dostosować do zmian zachodzących w zaufaniu użytkownika do treści. Kiedy interakcje pomiędzy użytkownikami i aplikacjami będą się stawały coraz mniej zauważalne, techniki RWD będą mogły przejmować na siebie coraz więcej obowiązków. Metodologia RWD sugeruje, że żądanie wykonania jakiejś akcji zmienia swój priorytet, kiedy akcja ta zostanie już wykonana, bądź też że strona główna ulega zmianie, gdy zmieni się fizyczna lokalizacja urządzenia — tak właśnie działa witryna Web Directions South 20125, przedstawiona na rysunku 1.7.

Rysunek 1.7. Strona Web Directions South 2012 zmienia się po przybyciu na miejsce konferencji

I tak to wygląda. Projektowanie responsywnych stron WWW jest logiczną reakcją ze strony środowiska projektantów i programistów na radykalne i destrukcyjne zmiany wywoływane przez nowoczesne urządzenia. Środowisko to stara się także wypracować rozwiązania, które z powodzeniem będzie można używać w przyszłości; myśli o przyszłości, a nie jedynie reaguje na obecnie zachodzące zmiany w stosowanych urządzeniach. Środowisko to traktuje projektowanie responsywnych stron WWW jako coś, co staje się standardową techniką operacyjną. Kiedy już zaczniemy ją stosować, będziemy jej używać do tworzenia wszystkich naszych aplikacji.

5

http://south12.webdirections.org.

ZAPEWNIANIE RESPONSYWNOŚCI

Dostosuj lub zacznij od nowa A zatem już wiemy, że projektowanie responsywnych stron WWW jest czymś, co ułatwia życie użytkownikom. Kiedy jednak należy stosować metodologię RWD w naszym procesie produkcyjnym? Czy chcąc z niej skorzystać, najlepiej zacząć od samego początku? Czy może lepiej pozostawić tworzoną aplikację w dotychczasowej postaci i użyć technik RWD wtedy, gdy będzie to konieczne? Odpowiadając krótko na to pytanie: najlepiej jest kontynuować pracę, pamiętając jednak o wszystkich technikach RWD. W jaki sposób należy to robić, zależy już od konkretnego programisty, zastosowania oraz tworzonej witryny. Kiedy struktura naszego rozwiązania jest solidna, będzie możliwe zastosowanie technik tworzenia płynnych siatek (opisanych w rozdziale 2.). Jeśli nasze treści są solidne, a używany CMS dostatecznie elastyczny, to może się okazać, że jedynym, czego nam trzeba do wykorzystania zapytań medialnych opisanych w rozdziale 4., będzie nowy szablon. Jeśli nasz kod jest stabilny i pewny, to precyzyjne wstawienia dynamicznych obrazów, przedstawionych w rozdziale 3., może być łatwe i przyjemne jak spacer w parku. Może się nawet okazać, że w naszej aplikacji nie musimy stosować wszystkich filarów metodologii RWD. Niemniej jednak może się także okazać, że czas pracy nad projektem ulegnie drastycznemu skróceniu, jeśli całkowicie od podstaw stworzymy nowy, wielokolumnowy układ witryny. Wydajność stylów CSS może być znacząco lepsza, jeśli wrócimy do standardowego prostokątnego układu i zastosujemy zapytania medialne, zaczynając do zera. Z kolei odpowiednie użycie szablonów, tak by poddomeny dostarczały precyzyjnie dostosowane treści, może rozwiązać wszystkie problemy z doborem obrazów. Nic nie stoi na przeszkodzie, by łączyć używane rozwiązania. Na przykład istniejąca witryna może być podstawą do utworzenia nowego, rozszerzonego rozwiązania obsługującego więcej urządzeń. Nie należy obawiać się wielkości istniejącej aplikacji i dopuścić, by zniechęciła nas do stosowania technik RWD. Podobnie należy się powstrzymać przed odrzuceniem istniejącej aplikacji i rozpoczynaniem jej tworzenia od początku. Najważniejsze jest, by po prostu zacząć stosować opisywane tu rozwiązania.

Sami stanowimy przykład Pierwszych pięć rozdziałów tej książki powstało jako prezentacja przygotowana na konferencję Web Directions South 20126; to wygodne, że mogliśmy użyć witryny tej konferencji jako przykładów. Ze względu na to, że już wcześniej zastosowaliśmy w niej pewne techniki RWD, musimy cofnąć się nieco w czasie i usunąć je, by zacząć od zera. 6

http://south12.webdirections.org/.

21

22

Responsywne strony WWW

W książce będziemy się odwoływali wyłącznie do jednej strony z tej witryny — Speakers & Sessions7, przedstawionej na rysunku 1.8 — niemniej jednak będzie ona doskonałym materiałem przykładowym. Przeglądając tę witrynę, trzeba pamiętać, że z powodzeniem spełniła ona swoje zadanie: na wszelkie problemy, jakie uda się na niej znaleźć, należy patrzeć pod kątem tego, że działała prawidłowo. W tej książce zadbamy jedynie o to, by działała jeszcze lepiej.

Rysunek 1.8. Strona prelegentów i sesji konferencji Web Directions South 2012 7

http://south12.webdirections.org/speakers-sessions.

ZAPEWNIANIE RESPONSYWNOŚCI

Celem stosowania metodologii RWD jest zdobycie i zatrzymanie użytkowników naszej aplikacji, zobaczmy zatem, co możemy w tym celu zmienić. Zaczniemy od kodu naszej przykładowej strony. Podczas tworzenia wszystkich witryn WWW podejmowane są pewne decyzje dotyczące kodu, które mają sens w czasie trwania prac, lecz później, gdy technologia zdąży się już zmienić, stają się dyskusyjne. Skoro nasza przykładowa witryna wykorzystuje już pewne rozwiązania typowe dla responsywnych stron WWW, postanowiliśmy je z niej usunąć. Przywracając ją do stanu „nieresponsywnego”, możemy zaczynać z czystym kontem. Poniżej przedstawiona została struktura kodu dotyczącego jednego prelegenta, stosowana na powyższej stronie: