Aplikacje webowe wykorzystujące technologię AJAX mogą zaoferować całkiem ciekawe możliwości swoim użytkownikom. Mogą być wyposażone w dynamiczne formularze, aktywne obiekty, ciekawe elementy graficzne i tekstowe, mogą działać interaktywnie. Niestety zapewnienie spójnego odbioru pracy takiej aplikacji wcale nie jest proste. Wystarczy drobny problem z komunikacją, opóźnienie lub zatrzymanie ładowania jednego ze składników, błąd w jednym z wielu skryptów albo nieprzewidziane przez autorów działania użytkownika, by w stronie mogły pojawiać się błędy. Pół biedy, gdy dotyczy to stron informacyjnych. Niestety ten sam problem dotyczy także niektórych stron transakcyjnych, przykładem może być nowy serwis mBanku.

Ten bank oferuje rachunki podzielone na dwa segmenty – firmowe (na przykład mBiznes konto) oraz indywidualne (na przykład eKonto). Przełączanie między nimi odbywa się za pomocą przełącznika – niestety z nieznanego mi powodu ta opcja czasami działa nieprawidłowo.
Oto dowód:
Kolejny błąd w serwisie transakcyjnym mBanku
Mimo wybrania profilu indywidualnego, system transakcyjny pokazuje rachunki firmowe. Jeśli przy takim błędnym ekranie spróbujemy wykonać przelew, wykona się on z profilu firmowego. Błąd ten udowadnia, że poszczególne części serwisu transakcyjnego nie są ze sobą spójne – a zatem istnieje prawdopodobieństwo dalszych błędów (przypomnę, że jest to aplikacja AJAX, które debugowanie jest trudne). Takie błędy w tym serwisie rzeczywiście są. Jeden z nich prowadzi do opisywanego przeze mnie błędu Error 404, drugi z kolei skutkuje wywołaniem formatki przelewu sugerującej inny typ rachunku – nieuważna osoba wykona przelew z niewłaściwego rachunku lub być może na niewłaściwy rachunek. Dlaczego? Druga strona, na której zatwierdza się przelew, nie informuje jednak o nazwie docelowego rachunku przy przelewach wewnętrznych. Podaje owszem numer konta, ale kto zna numery wszystkich swoich kont na pamięć?
Jest to klasyczny przykład aplikacji, która po wprowadzeniu efektownych elementów utraciła podstawowe zasady działania: czytelność, powtarzalność reguł i tak zwaną „głupotoodporność”. Słowem – przykład tego co się stanie, gdy serwis zaprojektuje sprzedaż i marketing, a nie specjalista od użyteczności (ang. usability).
Chociaż zrzutów ekranu i zapisanych informacji o błędach miałem sporo, publikuję tylko ten jeden przykład, gdyż istnieje prawdopodobieństwo, że z opisów niedoróbek i problemów skorzystają cyberprzestępcy.
Błędów nie mogłem zgłosić w obrębie serwisu mBanku, gdyż kontakt z konsultantem wymaga wtyczki Silverlight, której nigdy nie zainstaluję na komputerze wykorzystywanym do bankowości elektronicznej.