Różnica w projektowaniu serwisów www i aplikacji webowych przybiera na znaczeniu wraz z rozwojem środowisk RIA. Temat staje się interesujący dla środowiska usability – powstają zalecenia projektowe oraz metody badawcze dotyczące użyteczności aplikacji RIA. Swoje dwa ostatnie podcasty tematowi poświęcił Jared Spool.

Jared wyróżnia w strukturze aplikacji webowych dwa główne elementy – hub oraz wywiad (interview). Hub jest centralnym miejscem w którym znajdują się informacje na których dokonuje się działań (przykład huba to lista todo lub lista maili). Po wykonaniu operacji wraca się do huba. Wywiad jest natomiast procesem gdzie użytkownik odpowiada na kolejne pytania i przechodzi kolejne kroki procesu. Większość aplikacji łączy oba elementy. Niżej (za publikacją UIE) propozycja wizualizacji huba i wywiadu.

Na stronach firmy Jareda – UIE, kupić można dwie publikacje omawiające metody projektowania aplikacji webowych: The Designer’s Guide to Web Applications, Part II
Web Apps Tour 2007: Learning from Successful Designs, The Designer’s Guide to Web Applications, Part I
Structure and Flows. Warto wspomnieć, że UIE udostępnia za darmo po jednym rozdziale z każdej publikacji.

Aplikacjami Webowymi zajął się też Jakob Nielsen. Nazywany niekiedy „Wałęsą usability” ze względu na dość siermiężne i ortodoksyjne przekonania :). W każdym razie, gdy Nielsen o czymś pisze światek usability zawsze poddaje to dyskusji i jest to cenne samo w sobie. Jakob Nielsen w tym roku pierwszy raz opublikował swoje Top-10 Design Mistakes w odniesieniu do aplikacji (wcześniej zestawienia tego typu dotyczyły serwisów www).

Przyjrzyjmy się bliżej kilku z głównych błędów jakie zostały zdefiniowane w publikacji Nielsena.

• Niestandardowe kontrolki – użytkownicy przyzwyczaili się do tego jak zachowują się checkboxy, listy rozwijane, przyciski – każda zmiana takiej standardowej kontrolki może wprowadzić wiele niepotrzebnego stresu w używanie aplikacji. Nielsen argumentuje za używaniem wzorców projektowych – „Najlepsi projektanci interakcji zdefinowali wygląd i zachowanie kontrolek GUI w wyniki 30 lat pracy popartej tysiącami godzin testów. Mało prawdopodobne abyś przez weekend wymyślił coś lepszego.”, dalej Nielsen pisze „Użytkownicy spędzają większość swojego czasu na innych niż twoja stronach (…) Użytkownicy mają kilka tysięcy razy więcej doświadczenia w interakcji ze standardowymi kontrolkami niż z indywidualnie projektowanymi”.
  Jako szczególny przypadek niestandardowych kontrolek, Nielsen wymienia elementy designu, które wyglądają jak kontrolki ale nimi nie są – najprostszy przykład to elementy, które wyglądają na klikalne ale nie pozwalają na interakcję.
• Brak konsekwencji – konsekwencja w projektowaniu GUI zakłada używanie tych samych nazw na te same rzeczy. Funkcja, która wykonuje czynność powinna z każdego miejsca aplikacji być wywoływana w ten sam sposób. Najbardziej oczywisty przykład niekonsekwencji zauważyłem w oprogramowaniu mojego routera. Pokazuje on adresy MAC podłączonych urządzeń w formacie XX-XX-XX-XX-XX-XX ale gdy chcę dodać nowe urządzenie do listy dostępu to wymaga ode mnie formatu XX:XX:XX:XX:XX:XX. W obrębie jednej aplikacji nie mogę skopiować danych i wkleić ich.
• Brak sugestii – Nielsen używa sformułowania „Perceived affordances” na określenie akcji, które użytkownik wie, że może wykonać gdy patrzy na obiekt. Dobrym przykładem jest tutaj wyraźne oznaczenie elementów ekranu, które można złapać i przeciągnąć w inne miejsce. Aplikacje pozwalając użytkownikom na personalizację powinny jasno komunikować co można na ekranie poprzestawiać.
• Brak odpowiedzi – należy prezentowac użytkownikowi aktualny stan systemu. Przykładowo – badania, które prowadzono niezależnie zawsze pokazują, że użytkownik, który widzi stan systemu jest skłonny dłużej oczekiwać na wykonanie się czasochłonnych zadań. Interesujące, że subiektywny odbiór czasu u użytkowników, którzy widzieli stan systemu był niezgodny z obiektywnym czasem oczekiwania. Użytkownicy (mylnie) uważali, że czekali krócej na zadania o których przebiegu byli informowani.
• Brak komunikatów błędów – komunikaty błędów od zawsze były najbardziej zaniedbanym elementem projektowania. To zupełnie zrozumiałe ale warto zastanowić się jak dobrymi komunikatami o błędach możemy zjednać sobie użytkowników i nauczyć ich przy okazji jak błędów tych unikać.
• Pytanie dwa razy o to samo – użytkownicy zawsze irytują się gdy muszą powtórnie podać informacje o które już ich pytano. Gdy projektuje się pojedyńcze strony aplikacji można pominąć takie pozyskane już dane – warto zatem wyjść od projektowania procesów i dopiero na ich bazie projektować makiety. Pomocny może być tutaj choćby program Axure (www.axure.com), który łączy procesy i strony w jeden prototyp.
• Brak wartości domyślnych – wartości domyślne zawsze polepszają płynność procesów. Rozmyślnie usunąłbym tylko te wartości domyślne, których wybór dla użytkownika jest kluczowy i jeśli nastąpi pomyłkowy wybór wartości domyślnej (np. przez nieuwagę) użytkownik będzie bardzo niezadowolony. Przykładem może to być kolor ubrania (użytkownicy zazwyczaj zakładają, że kolor jest taki jak na zdjęciu gdy często można wybrać różne kolory a kolor defaulowy może być inny niż na fotce).

O pozostałych błędach projektantów przeczytacie u Nielsena: Top-10 Design Mistakes.