Projektowanie w przeglądarce – nowy sposób na lepsze strony?

W jaki sposób prezentuje się klientowi wizję przyszłej strony? Najczęściej robi się to przez przedstawienie przygotowanych w Photoshop’ie plików graficznych. Taki schemat pracy uznawany jest za szybszy i bardziej elastyczny niż pisanie kodu i prezentowanie efektów klientowi. Czy znajduje to potwierdzenie w rzeczywistości? Wydaje się, że tworzenie wizualizacji w programach graficznych stało się tak popularne, że zbyt rzadko stawiane jest pytanie dotyczące sensowności takiego rozwiązania i możliwych alternatyw. Dlatego dzisiaj chciałem przedstawić zupełnie inny punkt widzenia na projektowanie stron www. Zacznijmy od końca, czyli od przeglądarki.

Jakiś czas temu trafiłem na artykuł Andy Clark’a Time to stop showing clients static design visuals Nie jest to tekst pierwszej świeżości bo pochodzi z 2008 roku, ale dla mnie był poniekąd objawieniem. To co było w nim najbardziej odkrywcze to po pierwsze uświadomienie pewnych oczywistości a po drugie udowodnienie mi, że na początku swojej kariery wcale nie podchodziłem do tematu projektowania źle.

Kiedy zaczynałem jako freelancer nie miałem (w sumie nadal nie mam) wielkiego pojęcia o Photoshopie (tudzież innych programach graficznych). Dlatego moje projektowanie odbywało się „na żywo”, najzwyczajniej w świecie pisałem kod HTML i CSS, który jako stronę przekazywałem klientowi do akceptacji. Zależnie od tego jak bardzo rozwinięta była początkowa wizja klienta (podstawowe pytanie – czy w ogóle istniała) wymagało to ode mnie trochę więcej lub mniej pracy co samo w sobie nie było bardzo różne od projektowania graficznego. Później (nadal jako freelancer) trafiłem do większej firmy gdzie pierwszym etapem prac było tworzenie makiet i wizualizacji w Photoshopie. Dopiero kiedy klient akceptował tzw. wygląd rozpoczynał się etap pisania kodu, co w skrócie oznaczało po prostu realizację strony.

Dla mnie była to organizacyjna nowość, mimo że byłem świadomy takich schematów. Później wręcz utwierdziłem się w przekonaniu, że jest to zupełnie normalne, w końcu inne firmy też tak robiły, na branżowych blogach pisało się o tym a klienci często wręcz chcieli jako część realizacji otrzymać pliki graficzne.

Myślę, że podobne przekonanie jest powszechne w naszej branży. Pytanie jest jednak proste – czy taki schemat to jedyna alternatywa a jeśli nie to co zamiast niego? 

Andy Clark w wyżej wymienionym artykule sugeruje, że powinniśmy przestać pokazywać klientom statyczne obrazy. To co powinno stać się standardem to projektowanie przy użyciu HTML i CSS. Oznacza to, że należy połączyć fazę koncepcyjną z fazą odpowiedzialną za de facto tworzenie strony www. Dzięki takiemu podejściu projekt cały czas rozwija się w przeglądarce a nie w naszej głowie lub na poziomie programu, który do przeglądania stron internetowych nie słuzy (Photoshop i zamienniki).

Temat jest wręcz filozoficzny :) i można o nim pisać w nieskończoność. Nieustanne pisanie jest niestety niemożliwe więc zamiast rozwodzić się nad różnymi argumentami przedstawię Wam argumenty za i przeciw jakie udało mi się zebrać przeszukując zasoby Interentu w poszukiwaniu informacji na ten temat oraz jakie padły w moich rozmowach i mailach ze znajomymi z branży, z którymi o tym rozmawiałem.

Przeciw:

• pliki graficzne można szybciej edytować a więc organizacyjnie i biznesowo bardziej opłacalne jest tworzenie wizualizacji w takiej właśnie postaci
• „html i css nie mają takich możliwości jak Photoshop”
• łatwiej jest tworzyć stronę mając jakiś punkt odniesienia
• „klienci płacą za pliki psd”

Przeanalizujmy argumenty „na nie”. Pierwszym argumentem przeciw projektowaniu stron za pomocą markup’u był argument szybkości edycji. We wszystkich artykułach jakie czytałem na ten temat, osoby które zdecydowały się na zrezygnowanie z graficznych wizualizacji chwaliły sobie przede wszystkim skrócenie czasu realizacji projektu… Skąd takie rozbieżności? Ciężko stwierdzić. Rzeczywiście edycja plików w Photoshopie jest relatywnie szybka w porównaniu ze zmianą całej koncepcji layoutu w kodzie HTML i CSS. Możliwe jednak, że jest to kwestia porozumienia z klientem. Jeśli od początku jest jakaś zgoda co do fundamentów projektu (np. layout, nawigacja etc.) to zmiany nie powinny być aż tak istotne by przyprawiać nas o zawrotną ilość pracy. Dobrym sposobem na to by złapać zrozumienie z klientem jest stworzenie makiety w programie typu Axure. Takie narzędzie do projektowania UI/UX skraca dystans między naszą a klienta wizją i jest dobrym sposobem na tworzenie prototypów nim przystąpimy nawet do etapu projektowania samej strony (choć właściwie taka makieta jest jakby wstępnym projektem – prototypem). Ostatecznie można też zaufać tym, którzy piszą kod zamiast odpalać Photoshopa. Jeśli nie mieliśmy kontaktu z podobną metodyką to przetestujmy to sami i sprawdźmy czy zrealizujemy projekt szybciej. Z moich „starych” czasów nie przypominam sobie aby projektowanie w przeglądarce sprawiało mi jakieś problemy w kontekście terminów. Wprawdzie projekty, które realizowałem były mniejsze, ale mam wrażenie, że odbywały się jakoś bardziej sprawnie ;)

„HTML i CSS nie mają takich możliwości jak Photoshop” – cokolwiek by to nie miało znaczyć należy przede wszystkim zrozumieć, że program graficzny to nie przeglądarka a przeglądarka to nie program graficzny i nie jest to żadna ujma ani dla przeglądarki ani dla programu graficznego. Jeśli w Photoshopie da się osiągnąć jakiś efekt, którego za pomocą kodu nie można to ostatecznie jest jeszcze opcja wycięcia elementu i najzwyczajniejszego w świecie zamieszczenia go w naszym dokumencie. Sposób mało wysublimowany, ale czasami… Zresztą w czasach CSS3 i HTML5 takie sytuacje będą sporadyczne.

 Trzeci argument „na nie” dotyczył czegoś co określone zostało jako „punkt odniesienia”. Możliwe, że nie jest złym pomysłem widzieć przed oczami jaką wizję strony klient zaakceptował, ale po co skoro można tę wizję tworzyć od razu w postaci strony i przedstawiać klientowi już jako proponowaną witrynę? W ten sposób osiąga się kilka fundamentalnych celów. Przede wszystkim klient od razu widzi gotową stronę w przeglądarce. Dzięki temu od pierwszych chwil może zobaczyć jak przeglądarka wyświetla poszczególne elementy np. jak wygładza czcionkę (albo i nie wygładza – pozdrawiam Google), jak zachowuje się strona przy przechodzeniu między podstronami, jak wygląda naturalna, webowa typografia itd. Takich rzeczy nie da się zasymulować. Nasz zleceniodawca ma więc okazję szybciej zintegrować się z tym co przecież jest ostatecznym celem projektu – jego stroną internetową. Projektując w przeglądarce unikamy też prozaicznego problemu kiedy jakiś element znajdujący się na wizualizacji jest niemożliwy do osiągnięcia w jakiejś przeglądarce lub jego wygląd w znaczący sposób różni się w różnych przeglądarkach. W takim przypadku dany element „wylatuje” z projektu (opcja leniwa) lub klient „widzi go takim jaki jest” i albo to akceptuje albo nie. Po trzecie strona projektowana w przeglądarce jest praktycznie na bieżąco testowana co sprawia, że proces projektowania przybiera funkcję podobną do modelu test driven development.

A co jeśli klient chce otrzymać pliki psd zawierające wizualizację jego strony? Wydaje mi się, że w relacjach z klientem ważna jest uczciwość i szczerość a więc po prostu wytłumaczmy zleceniodawcy, że plików psd nie dostarczymy. Jeśli nadal będzie presja na stworzenie wizualizacji graficznej to zawsze możemy projektować w przeglądarce a później na podstawie gotowej strony stworzyć owe wizualizacje. Jeśli klientowi to nadal nie odpowiada lub nalega na bardziej klasyczny model faz projektowych możliwe, że nie pozostanie nic innego jak powrót do klasyki.

Argumenty za:

• „klient widzi co dostanie” – to zostało dość szeroko wyjaśnione w moim komentarzu do argumentów przeciw projektowaniu w przeglądarce, więc chyba nie muszę dodawać tutaj szerokiego wyjaśnienia
• strona jest testowana na bieżąco – jak już wspomniałem projektowanie w przeglądarce pozytywnie przekłada się też na kompatybilność strony i poniekąd tworzy warunki czegoś na wzór TDD
• skraca się czas projektu – tak twierdzą Ci którzy to robili a ja nie mam powodów żeby nie wierzyć chociaż nie miałem okazji porównać czasu realizacji dwóch wielkościowo podobnych projektów, z których jeden byłby projektowany programem graficznym a drugi w przeglądarce
• budujemy lepszy kod – niewątpliwie możemy też tworzyć bardziej przemyślany kod szczególnie jeśli chodzi o nasze arkusze stylów, dodatkowo jest więcej miejsca na troskę o dostepność i semantykę. Lepsza jakość kodu bierze się głównie z tego, że od samego zarania projektu nie koncentrujemy się tylko na tym jak strona wygląda, ale też na tym jak jest zbudowana.
• strony są po prostu lepsze – jeśli dodać to wszystko do siebie to wychodzi, że projektując strony w przeglądarce po prostu robimy je lepiej.

Jeszcze nie miałem okazji zrealizować dużego projektu, który byłby projektowany w przeglądarce, ale niedługo będę miał ku temu okazję i podzielę się doświadczeniami w komentarzach. Was również zachęcam do komentowania i dzielenia się swoimi doświadczeniami!

Zdjęcie pochodzi z www.freedigitalphotos.net