TheTarPit

ekstremalnie cienki klient

Sformułowanie „aplikacja webowa” zapewne razi purystów językowych. Niestety nie znam lepszego odpowiednika pojęcia „web application”, jakiejś bardziej polskiej nazwy na architekturę, w której interakcja z użytkownikiem odbywa się poprzez strony w przeglądarce internetowej. Czy to będzie się odbywało w internecie czy w intranecie, w sieci rozległej czy lokalnej — bez znaczenia. Ważne, że po jednej stronie jest użytkownik uzbrojony jedynie w przeglądarkę (mniej lub bardziej dowolną), a po drugiej serwer obsługujący żądania tego użytkownika i zapewne jakąś bazę danych. Niby klasyczna architektura klient-serwer, ale specyfika klienta^[1] powoduje, że aplikacje webowe to zupełnie nowa jakość problemów.

sporo zalet

Przede wszystkim gigantyczną zaletą jest maksymalnie cienki klient. W dzisiejszych czasach można bez większego ryzyka założyć, że każdy użytkownik ma zainstalowaną przeglądarkę WWW i stanowi ona raczej element lokalnego systemu niż część aplikacji. Zatem klient to jedynie strona, ta odrobina tekstu (X)HTML wysłana z serwera do przeglądarki plus towarzyszące jej skrypty, arkusze stylów czy obrazki. Taka sytuacja uwalnia od szeregu problemów:

• Wdrożenie klienckiej części aplikacji webowej jest stosunkowo proste — może być wymagane jedynie dostrojenie wersji przeglądarek, a i to niekoniecznie.
• Każdy użytkownik ma zawsze taką samą aplikację jak inni. Odpada kłopot z rozsyłaniem i instalowaniem nowych wersji, po prostu wystarczy zmienić program na serwerze (jeden!) a użytkownik logując się na tej samej stronie co zwykle automagicznie zacznie używać nowej wersji.
• Komunikacja części klienckiej z serwerem odbywa się po HTTP czy HTTPS na popularnych portach, co ma zbawienny wpływ jeżeli nie na samo bezpieczeństwo, to przynajmniej na samopoczucie administratora sieci.
• Ilość i rozmieszczenie użytkowników może być płynne. I to niemal bezboleśnie, bo właściwie zrzucamy odpowiedzialność na administratora sieci — aplikację można używać z każdego miejsca, z którego da się dostać do strony na serwerze.

jeszcze więcej wad

Pierwszy i najważniejszy, choć dla osób spoza grzęzawiska może mało oczywisty, problem to zrozumienie (nie mówię, że akceptacja, zrozumienie) przez użytkownika, klienta, handlowców i managerów faktu, że technologia webowa ma swoje ograniczenia. Przeglądarka z założenia nie robi wiele ponad prezentację strony (X)HTML, a ten język ze swej natury oferuje ograniczone możliwości interakcji. Oczywiście strona mająca stanowić część kliencką aplikacji jest „wzbogacana” przez DHTML, jednak pozostaje tylko stroną. Istnieje co prawda Web Hypertext Application Technology Working Group, ale jak sami piszą:

This working group aims to make their development easier, and hopes to specify new technologies that make it possible to make much prettier and more usable interfaces with less dependence on complex scripts, less dependence on server-generated pages, and a more seamless user experience.

Kluczowe jest tutaj sformułowanie „aims to make”. Na razie jest mizernie i ubogo — możliwości zestaw kontrolek występujących w HTML w porównaniu z możliwościami aplikacji desktopowych są praktycznie żadne. Niestety to jest coś, czego handlowcy, kierownictwo wyższego szczebla ani zwykli użytkownicy najczęściej zrozumieć nie potrafią i/lub nie chcą^[2]. I właśnie to jest problem numer jeden, bo sam fakt istnienia tych ograniczeń stosunkowo łatwo jest zaakceptować — w końcu każda technologia ma swoje ograniczenia i tyle.

Kolejny, chyba jeszcze mniej oczywisty, problem wynika z powyższego — interfejs użytkownika aplikacji webowej jest znacznie trudniejszy do wykonania niż interfejs aplikacji desktopowej. Z kilku przyczyn:

• Nie istnieją standardy interfejsu analogiczne jak w aplikacjach desktopowych — nie wiadomo jak ma wyglądać menu, jak ma być rozwiązana nawigacja po stronach, jak prezentować pomoc kontekstową itd. itp.
• Problematyczna dostępność aplikacji webowej za pomocą urządzeń innych niż myszka. Nie jest to może skomplikowane technicznie, ale wymagany jest tutaj pewien poziom świadomości, o który wciąż zadziwiająco trudno.
• Wygląd graficzny aplikacji może być dowolny, a dowolność oznacza kłopoty — trzeba mieć kogoś, kto potrafi to jakoś ładnie zaprojektować.

Powyższe (i kilka mniejszych szczegółów) powoduje, że zadanie projektanta i twórcy interfejsu aplikacji webowej to zadanie zupełnie inne niż zadanie programisty części serwerowej tego samego systemu. A ponieważ tradycyjne aplikacje desktopowe zazwyczaj nie wymagały zatrudnienia specjalisty od interfejsu, więc również przy aplikacjach webowych takiego człowieka się nie zatrudnia. Można oczywiście skorzystać z gotowych rozwiązań czy najróżniejszych półproduktów i na ich bazie wykonać interfejs własnej aplikacji. Najczęściej jednak pozostawia się to zadanie tym samym ludziom, którzy implementują całą resztę systemu. W efekcie interfejsy webowe zaprojektowane i stworzone przez programistów są niemal zawsze beznadziejne zarówno wizualnie jak i funkcjonalnie.

W takim kontekście słowo „cienki” w tytule tego wpisu nabiera zupełnie innego znaczenia...

Komentarze