Czy (i dlaczego?) warto zainwestować w Responsive Web Design - NowyMarketing

Zobacz również

Nowy Marketing kilkukrotnie pisał już o RWD:

W niniejszym tekście, chcielibyśmy poruszyć temat, o którym co prawda nie rozmawiają dżentelmeni, jednak dostawcy usługi ich klienci muszą: finanse.

RWD zalewa nas niczym wysoka fala – zadziwiająco szybko i z wielką siłą. Już ten podstawowy fakt sugeruje, że warto zainwestować w serwis RWD – po prostu po to, by być na fali 😉

#NMPoleca: Jak piękny design zwiększa konwersję w e-commerce? Tips & Tricks od IdoSell

Pozostałe kwestie są bardziej wielopłaszczyznowe.
Postaramy się w tym artykule odpowiedzieć na, jak zawsze złożoną, kwestię opłacalności i kosztów inwestycji w Responsive Web Design i użyjemy w tym celu kilku uproszczeń ułatwiających przyjęcie jednoznacznych stanowisk.

Słuchaj podcastu NowyMarketing

Dla mniej dociekliwych – odpowiedzi krótkie i prawie natychmiastowe, zainteresowanych zachęcamy do zabrnięcia z nami w szczegóły:

Krok 1 – co wybrać

Jeśli chcesz, by Twój serwis był dostępny nie tylko z poziomu desktopu, ale także z urządzeń mobilnych, masz do wyboru dwie opcje: RWD lub dedykowany serwis mobilny.

„Zwykły“ serwis www vs Responsive Web Design
Pytanie o zasadność inwestowania w serwis RWD jest tak naprawdę pytaniem o podejście do usera serwisu: czy stojącego w kolejce po poranne latte pozostawiamy ze standardową wersją serwisu www, zazwyczaj wszak “możliwą do odczytania” na urządzeniu mobilnym, czy też wykonujemy (przebudowujemy) serwis w Responsive Web Design?
Innymi słowy – dbamy o to, by nasz serwis był w pełni dostępny z każdego urządzenia i dla każdego użytkownika czy liczymy na to, że “jakoś to będzie”? A jeśli wybierzemy opcję pierwszą – ile to będzie kosztowało?
Responsive Web Design vs dedykowany serwis Mobilny
A może, zamiast budować nowy serwis w Responsive Web Design warto zainwestować po prostu w mobilną wersję istniejącej strony? Co będzie tańsze? Co będzie lepsze?

Zanim zdecydujesz co wybrać i poznasz koszty, koniecznie przeanalizuj poniższe zagadnienia.
W odpowiedzi na oba powyższe pytania, jako nadrzędne postawmy cele biznesowe i czynniki, jakie powinny wpływać na decyzje finansowe i strategiczne.

ODBIORCA

Jaki jest ruch generowany przy użyciu urządzeń mobilnych w Twoim serwisie w ciągu ostatnich 12 miesięcy i przede wszystkim jak znaczny jest procent jego przyrostu?
Czy odwiedzający Twój serwis użytkownicy mobilni to Twoja główna grupa docelowa i w szczególny sposób Ci na niej zależy?

STRATEGIA

Jaka jest strategia Twojej organizacji dotycząca użytkowników mobilnych, obecności w mobile web?
Czy Twoja organizacja jest technicznie, kreatywnie i emocjonalnie (tak, emocjonalnie) gotowa na Responsive Web Design – na większe niż dotychczas współdziałanie z projektantami, pracę w Agile, i przede wszystkim wydłużony czas testów?
Ten ostatni dla wielu jest nieznośnie długi – pokutuje tu nadal obecne przekonanie o tym, że należyte wykonanie serwisu (zarówno w warstwie interfejsu, jak i programowania) w ogóle nie wymaga testów – przecież zespół tworząc coś, na czym się zna nie powinien popełniać błędów. Jeśli jesteś w grupie z tym podejściem, szczególnie wnikliwie odpowiedz sobie na to pytanie.
W rzeczywistości multi-screen nie sprawdza się bowiem Waterfall, ani znikome współdziałanie twórców z Klientem – bliska współpraca jest absolutnie kluczowa dla projektów RWD tworzonych z sukcesem – wstępna rozmowa o zachowaniach interfejsu na różnych nośnikach nie wystarczy.

SZCZEGÓŁY

Czy istnieją wyraźne i jasne powody konieczności realizacji dedykowanego mobilnego serwisu? (np. bardzo długie treści, które powinny być napisane osobno, bezpośrednio dla użytkowników mobilnych, złożone funkcjonalności, których użycie na nośnikach mobilnych mogłoby być kłopotliwe?
Czy masz w zespole osobę gotową do podjęcia odpowiedzialności i zarządzania kontentem na wielu wersjach serwisu, czy też nie dysponujesz zespołem, który mógłby pilnować spójności i aktualizacji, zatem możliwe jest jedynie utrzymywanie jednego serwisu?
Czy twórcy serwisu są w stanie wykonywać należycie pracę opisaną w punkcie wyżej?
Czy Twój serwis posiada coś, co może być dostarczane wyłącznie dzięki możliwościom smartphone’ów, czy też kontent i funkcjonalności są na tyle uniwersalne, że nie wymagają zastosowania natywnych możliwości urządzeń mobilnych?

Dopiero teraz, gdy znasz realia, potrzeby, wymagania i możliwości możemy rozmawiać o kosztach…

Ad 1. „Zwykły“ serwis www vs Responsive Web Design
Stworzenie tego samego w założeniach serwisu w podejściu RWD to ok. 30% – 50% większe koszty niż dla standardowego serwisu www. Dlatego też przy wyborze rozwiązania konieczne jest wzięcie pod uwagę wszystkich punktów z części “Odbiorca” i “Strategia. Pozytywne odpowiedzi na powyższe pytania sugerują, że pieniądze zainwestowane w serwis RWD zwrócą się i to z nawiązką (oczywiście każdorazowo inaczej rozłożony w czasie).
Ad 2. Responsive Web Design vs dedykowany serwis Mobilny
Upraszczając i biorąc pod uwagę uśrednione doświadczenia nasze i innych agencji – zazwyczaj nie ma zbyt wielkich różnic w kosztach realizacji serwisu mobilnego i RWD. Wyraźne różnice finansowe dotyczą dopiero długofalowego utrzymania – RWD w dłuższym rozliczeniu w przeważającej większości okazuje się dużo tańszy, niż strona mobilna.
Znane są niezaprzeczalne plusy i argumenty przemawiające za RWD w stosunku do mobilnych wersji (przedstawiamy je poniżej), istnieją jednak realizacje, w których zasadnym jest tworzenie dedykowanych rozwiązań mobilnych. W podjęciu decyzji zdecydowanie kluczowe są odpowiedzi na pytania w części “Szczegóły”.
Wszelkie próby podania jednoznacznej odpowiedzi na pytanie “kiedy RWD jest lepsze od dedicated mobile web” kończą się tam, gdzie zaczynają się uogólnienia. Z doświadczenia jednak możemy przekazać jedną bazową zasadę: jeśli chcesz stworzyć wizerunkowy serwis www, a nie złożoną aplikację o bardzo specyficznych potrzebach lub serwis korzystający z natywnych własności telefonu, bardziej sensowne ekonomicznie i realizacyjnie jest wybranie RWD.

Dla uzasadnienia i rozwinięcia powyższych stwierdzeń ale przede wszystkim dla przedstawienia złożoności sprawy, poświęcimy chwilę na bliższe przyjrzenie się tematowi:

Za i przeciw Responsive Web Design

Powiedzmy, że zdecydowaliśmy, iż klient w kolejce po latte ma widzieć na swoim smartfonie dedykowaną mu wersję strony. Rozważamy Responsive. Co przemawia na jego korzyść a co na niekorzyść?

RWD – powszechnie znane “za”

Serwis tworzony jest raz i działa na tysiącach urządzeń o różnych parametrach ekranu.
Jednokrotnie powstaje koncepcja interfejsu, projektowana jest architektura informacji, planowane ułożenie kontentu i projekt graficzny. Jeden raz pisze się kod.
Utrzymanie – wprowadzona raz zmiana, poprawiony raz błąd, zaktualizowany raz kontent widoczne są natychmiast wszędzie i dla wszystkich.
Jeden URL, jeden hosting.
Łatwiejsze zarządzanie linkami.

RWD – mniej znane “za”

Realia utrzymania – z doświadczenia spotkań z Klientami wiemy, że zazwyczaj jedna agencja tworzy (lub stworzyła serwis jakiś czas temu), inna zaś buduje dedykowaną wersję mobilną serwisu. Rodzi to jeszcze większe realne problemy z zarządzaniem kontentem, aktualizacjami i utrzymaniem spójności (także technicznej) obu serwisów.
RWD pozwala zarządzającym serwisem czerpać zmultiplikowany zysk z pojedynczej inwestycji na wielu platformach i rozdzielczościach – jeden design, produkcja, wspólne zarządzanie treścią i nakładami marketingowymi.
Jeden URL – posiadanie jednego serwisu dla wszystkich nośników oznacza także, że za pomocą jednego URL-u dostarczysz kontent wszystkim Twoim odbiorcom. Nie musisz się martwić o przekierowania i niezgodności pomiędzy nośnikami. Kiedy promujesz link, masz pewność, że niezależnie od tego, jak i gdzie użytkownik wyświetla Twój website, dotrze do tych samych linków.
Google rekomenduje RWD… (jakie lepsze “za” możemy przytoczyć? 🙂 https://developers.google.com/webmasters/smartphone-sites/)
Możliwości – RWD pozwala tworzyć NAPRAWDĘ różne interfejsy, budować odmienną architekturę informacji, prezentować kontent strony na bardzo różne sposoby – (niestety, powszechnie pokazywane dziś serwisy zrealizowane w RWD nie oddają nawet w połowie możliwości, jakie RWD ze sobą niesie. W większości to dość prymitywne odwzorowania tego samego serwisu w różnym ułożeniu treści, ale bez skupienia na różnicach potrzeb użytkowników nośników, ich przyzwyczajeń i oczekiwań).

RWD – Co tak naprawdę wpływa na koszty?

Czyli znane nam “przeciw”

Czas potrzebny na dewelopment – proces powstawania projektu RWD jest bardziej czasochłonny, niż mogłoby się wydawać. Pod uwagę trzeba wziąć takie czynniki jak:
– wydłużony czas projektowania interfejsu – od samego początku ważne jest określenie zasad zachowania i zmian UI w zależności od nośnika;
– wykorzystanie odpowiednich patternów;
– wybranie odpowiedniego dla nas frameworka (o ile mamy zamiar z takowego korzystać) lub projektu bazowego;
– planowanie szczegółowe podstawowych elementów (np. break-pointów, chociaż niektóre osoby dostosowują break-pointy do projektu graficznego, nie na odwrót).
Trzeba pamiętać przede wszystkim o tym, cytując Bryana Riegera, że “The absence of a media query is in fact, the first media query”, co jest najważniejszym czynnikiem przy pracy “mobile first”, która to metodologia optuje za stworzeniem podstawowego projektu z pełnym kontentem, jaki chcemy przekazać użytkownikowi i rozwijanie go wraz z udostępnianymi nam możliwościami nowych rozwiązań.
Jest to kluczowe przy próbie przeniesienia aktualnego serwisu stworzonego z myślą wyłącznie o desktopach do świata mobilnego. W większości przypadków operacja taka będzie wymagała dużo większych zasobów czasowych, niż napisanie strony od podstaw.
Zwiększony czas testowania i zapewnienia jakości – testowanie serwisu w wielu środowiskach, szczególnie na prawdziwych urządzeniach, a nie z wykorzystaniem emulatorów lub poprzez zwykłe zsuwanie okna przeglądarki, jest czasochłonne. Bardzo czasochłonne. Dni, kiedy do testów wystarczyło nam zanistalowanie kilku wersji znanych przeglądarek, minęły. Aktualnie nadal oczywiście testujemy aplikacje na przeglądarkach, tyle, że mamy do czynienia ze zwielokrotnieniem opcji – przeglądarki desktopowe i mobilne, w dziesiątkach przeróżnych wersji, o różnej specyfikacji, z różnymi funkcjonalnościami i możliwościami które możemy wykorzystać. Każde z urządzeń zachowuje się inaczej, a my musimy zrozumieć, na jakiej zasadzie ono działa i starać się zapewnić odpowiedni sposób przedstawienia naszej treści. Większość gotowych narzędzi, które pomagają developerom w testowaniu responsywnych rozwiązań, bazuje na zmianie dostępnej szerokości i wysokości, na której wyświetlana jest strona. Nie oddaje to jednak szybkości generowania strony, różnicy w możliwościach dostępnych przeglądarek mobilnych, prędkości łącza czy zachowania bez wykorzystania myszki i klawiatury, chociaż i takie narzędzia zaczynają powstawać jak grzyby po deszczu. Możemy jedynie z nadzieją czekać na idealne narzędzie do testowania… Na dzień dzisiejszy jednym z rozwiązań problemu jest analiza użytkowników pod kątem korzystania z konkretnych nośników i zamknięcie tej fazy wyłącznie do testowania tych nośników.
“Przeprogramowanie” mentalne i emocjonalne zespołu do innego system pracy
Resposive Web Design kocha Agile. W Agile klient jest częścią procesu. Należy się zatem przygotować na iteracyjność i współdziałanie oraz na to, że proces Waterfall nie działa w rzeczywistości multi-screen. Ścisła współpraca jest absolutnie niezbędna dla udanego projektu responsive, więc upewnij się, że zespoły projektowe po stronie wykonawcy i po stronie klienta są w pełni komunikatywne i dysponują czasem (i ochotą) na regularne kontakty i wzajemne weryfikowanie swojej pracy. Praca iteracyjna pozwala klientowi na uczestniczenie w procesie i wgląd w prototypy klikalnych, w pełni zaimplementowanych części serwisu. Dzięki temu może on decydować na bieżąco o dodatkowych funkcjonalnościach i zaawansowanych potrzebach – to zaleta, jest jednak i wada – taki sposób pracy wymaga często podjęcia decyzji o budżecie zmiennym, zamkniętym jedynie w minimalnej i maksymalnym przedziale.
Szczególnie wykwalifikowany zespół realizujący – aktualnie na polskim rynku nadal niewielu twórców RWD potrafi w pełni go wykorzystać i dostarczyć. Dotyczy to w mniejszym stopniu front-end deweloperów (oni najbardziej dynamicznie zareagowali na trend RWD), w większym zaś projektantów interfejsów i grafików. RWD wymaga bowiem innego procesu myślenia o grafice, dodatkowych umiejętności i wiedzy, która musi być stale pogłębiana i rozwijana.
Wykwalifikowane zespoły, jeśli są w mniejszości, kosztują więcej…

Podsumowując

Serwis tworzony zgodnie z regułami Responsive Web Design jest droższy w tworzeniu od tradycyjnego serwisu www. Koszty budowy serwisu RWD są podobne, jak w przypadku serwisu mobilnego, jednak eksploatacja tego pierwszego w dłuższej perspektywie czasowej niesie ze sobą niższe koszty, niż w przypadku mobile web. Decyzja – mobile, czy RWD zależy od potrzeb. W przypadku, gdy potrzebujesz złożonej aplikacji o bardzo specyficznych potrzebach lub serwisu korzystającego z natywnych własności telefonu – wybierz mobile web. W każdym innym – rekomendujemy serwis Responsive. Nie tylko dlatego, że taka jest fala. Taka jest przyszłość!

Autorzy: Anna Zarudzka, Kamil Ogórek

Autorzy reprezentują Chilid Web Design Agency, pasjonaci łączenia dobrego designu z technologiami client side, uparci ewangeliści Responsive Web Design.