Arkadiusz Janicki. Projektowanie zorientowane na użytkownika poprawa użyteczności systemu Hinc. Praca magisterska

Transkrypt

1 Arkadiusz Janicki Projektowanie zorientowane na użytkownika poprawa użyteczności systemu Hinc Praca magisterska Promotor: dr Ewa Gurbiel Uniwersytet Wrocławski Wydział Matematyki i Informatyki Instytut Informatyki Wrocław 2011

2 ii

3 Streszczenie Praca zawiera wprowadzenie do tematyki projektowania zorientowanego na użytkownika, opisuje wybrane metody użyteczności i ich zastosowanie do przeprojekowania interfejsu rzeczywistego systemu. W części pierwszej przedstawiono w zarysie historię ewolucji metod związanych z interakcją człowiek-komputer, użytecznością i projektowaniem zorientowanym na użytkownika. Opisano też popularne metody użyteczności takie jak ocena heurystyczna, testy użyteczności czy prototypowanie. Druga część pracy opisuje doświadczenia z sześciomiesięcznej praktyki w siedzibie firmy Nec Plus Ultra, której celem była poprawa użyteczności jednego z produktów firmy. W trzeciej części znajdują się załączniki z raportami z wykonanych prac. Słowa kluczowe projektowanie zorientowane na użytkownika, użyteczność, prototypowanie, ocena heurystyczna, testy użyteczności, user-centered design, ucd, usability, prototyping, heuristics evaluation, usability testing iii

4 Spis treści Wstęp vii I Wprowadzenie teoretyczne 1 1 Podstawowe pojęcia Interakcja Człowiek Komputer Użyteczność Design Projektowanie zorientowane na użytkownika Metody użyteczności Analiza kontekstu użytkowania Zbieranie wymagań Spotkanie z użytkownikiem Analiza konkurencyjnych rozwiązań Utworzenie rozwiązania projektowego Prototypowanie Iteracyjne projektowanie Wzorce interakcji Standardy, wskazówki i zasady projektowe Ewaluacja interfejsu Historia ewaluacji Ocena heurystyczna Testy użyteczności II Omówienie wykonanych prac 19 3 Iteracja 0 Zapoznanie się z systemem Analiza dokumentacji Analiza funkcjonalności Analiza kontekstu Iteracja 1 Moduł wskaźników System oceny wydziałów rozwoju regionalnego Nowe wymagania Ocena heurystyczna modułu Prototypy ekranów Testy prototypów Prezentacja prototypów klientowi Implementacja Wskaźniki jakości w NPU iv

5 5 Iteracja 2 Moduł planu działania Analiza konkurencyjnych rozwiązań Spotkania z użytkownikami Ocena heurystyczna modułu Propozycje zmian Druga wersja prototypu Implementacja Iteracja 3 Pozostałe części systemu Prototyp Podsumowanie 34 III Załączniki 35 A Analiza kontekstu użytkowania 35 A.1 Użytkownicy A.2 Środowisko pracy A.3 Technologia A.4 Zadania B Analiza konkurencyjnych rozwiązań 38 B.1 Scopi Software de Controle de Projetos e Indicadores B.2 PBworks: Online Collaboration B.3 Basecamp C Ocena heurystyczna systemu Hinc C.1 Wstępna ocena systemu C.2 Ocena modułu wskaźników C.3 Ocena modułu plan działania D Testy z udziałem użytkowników 52 D.1 Usability Test Renata D.2 Usability Test Mara D.3 Usability Test Liege D.4 Usability Test Mariana D.5 Usability Test Dimitri D.6 Usability Test Guilherme E Architektura interfejsu 59 Bibliografia 62 v

6 vi

7 Wstęp Informacje o systemie Hinc Firma Nec Plus Ultra (NPU) z siedzibą we Florianópolis w Brazylii istnieje od 1997 roku. Podstawowym profilem działalności firmy są usługi konsultingowe z zakresu wdrażania oprogramowania typu ERP oraz usługi doradztwa biznesowego skierowane do firm z branży budowlanej. Od kilku lat firma zajmuje się także tworzeniem i dostarczaniem własnych rozwiązań informatycznych. 1 System Hinc jest autorską aplikacją rozwijaną przez NPU od 2000 roku. Początkowo głównym zadaniem systemu było wspieranie wewnętrznego obiegu informacji w firmie. Pierwsza wersja programu została napisana w języku Delphi i korzystała z technologii IntraWeb VCL. W roku 2005 została podjęta decyzja o zmianie technologii. Aplikacja miała zostać napisana od początku w języku Java z wykorzystaniem aktualnych technologii internetowych. Przy projektowaniu nowej wersji uwzględniono także wiele dodatkowych wymagań nowy system nie miał być dedykowaną aplikacją, lecz uniwersalnym narzędziem do zarządzania projektami w małych i średnich firmach. We wstępie do dokumentacji systemu [31] możemy przeczytać: System Hinc wspiera proces zarządzania wiedzą oraz informacjami o projektach, programach i innych aktywnościach, a także zadaniami, terminami, kosztami, jakością, zasobami, ryzykiem i komunikacją pomiędzy pracownikami. Zadaniem systemu Hinc jest rozwijanie bazy wiedzy organizacji i wspieranie ciągłej optymalizacji. (tłum. autor) Znaczna część dzisiejszej funkcjonalności systemu powstała w pierwszych dwóch latach prac ( ). Przez kolejne lata aplikacja ewoluowała i była stopniowo wzbogacana o nowe funkcje. Do dnia dzisiejszego zaimplementowano podstawową część planowanej funkcjonalności, jednak nie wszystkie z założeń zostały zrealizowane. System w aktualnej wersji nie umożliwia m.in. zarządzania jakością, kosztami ani ryzykiem. Aplikacja spełnia jednak swoje podstawowe zadanie, jakim jest wspieranie obiegu informacji w firmie. Dedykowany moduł aplikacji jest też wykorzystywany przez wydział planowania administracji stanu Santa Catarina. Podjęte zostały też próby wdrożenia systemu w innych organizacjach, ale nie można ich określić jako udanych. Cel pracy magisterskiej Praca powstała podczas sześciomiesięcznej, pełnoetatowej praktyki w siedzibie firmy NPU w okresie od stycznia do lipca Podstawowym zadaniem wyznaczonym na czas trwania praktyki była poprawa użyteczności systemu Hinc. Niniejsza praca stanowi szczegółową dokumentację wykonanych przez autora zadań. Autor był w całości odpowiedzialny za projekt nowych rozwiązań dotyczących użyteczności oraz częściowo odpowiedzialny za ich implementację. Dobór metod pracy był konsultowany z kierownictwem projektu oraz z promotorem pracy. 1 Źródło: 2 Praktyka organizowana była przez AIESEC międzynarodową organizację prowadzoną przez studentów. vii

8 Ograniczenia Głównym ograniczeniem był czas trwania praktyki. Podczas sześciu miesięcy miała odbyć się przebudowa całego interfejsu aplikacji. Dodatkowo harmonogram i zakres prac musiał pokrywać się z odgórnymi celami projektu, co oznacza, że kolejność wykonywanych prac nie zawsze była optymalna. Dodatkowym utrudnieniem w pracy nad projektem była bariera językowa. Cała dokumentacja systemu, komunikaty interfejsu użytkownika, a nawet komentarze i nazwy funkcji w kodzie programu były napisane w języku portugalskim, którego autor pracy praktycznie nie znał przed przyjazdem do Brazylii. W zespole roboczym komunikacja odbywała się w języku angielskim i nie było większych problemów z wymianą informacji, jednak podczas testów z udziałem użytkowników niezbędna była obecność tłumacza. Struktura pracy Praca składa się z trzech części. Pierwsza zawiera wprowadzenie teoretyczne, w którym przedstawiono podstawowe pojęcia i wykorzystywane metodologie. Druga część opisuje wykonane prace oraz wyjaśnia motywacje poszczególnych decyzji. Część trzecia zawiera szczegółowe raporty dokumentujące kolejne etapy pracy nad projektem. Większość z nich napisana jest w języku polskim, a część w angielskim. viii

9 Część I Wprowadzenie teoretyczne 1 Podstawowe pojęcia 1.1 Interakcja Człowiek Komputer Stopień złożoności współczesnych rozwiązań informatycznych jest tak duży, że często konieczne jest szczegółowe analizowanie i dokładne projektowanie interakcji pomiędzy użytkownikiem a komputerem. Zajmuje się tym interdyscyplinarna dziedzina nauki zwana Interakcją Człowiek Komputer (ang. Human Computer Interaction, HCI), klasyfikowana jako część wspólna informatyki, psychologii i designu [2]. 1 Początkowo światy te były zupełnie rozłączne: psychologowie badali zachowanie się ludzi, projektanci projektowali przedmioty codziennego użytku a informatycy tworzyli systemy komputerowe. Gdy komputery zaczęły zastępować codzienne narzędzia, gdy zaczęły odgrywać coraz większą rolę w życiu przeciętnego człowieka, niezbędna stała się współpraca. Człowiek Historia gatunku ludzkiego zaczyna się wiele milionów lat temu, gdy nasi przodkowie zaczęli używać narzędzi z kamienia, kości i drewna. Pierwsze narzędzia były bardzo proste i ułatwiały wykonywanie podstawowych czynności, jednak z biegiem czasu ludzie nauczyli się wytwarzać coraz bardziej skomplikowane przedmioty. To właśnie umiejętność wytwarzania narzędzi, obok wyprostowanej postawy ciała, jest cechą charakterystyczną wyróżniającą człowieka spośród innych ssaków [15]. Narzędzia pomagały zapanować nad światem przyrody, a kolejne zdobycze technologiczne często decydowały o losach cywilizacji. O sukcesie narzędzia decydowała jego przydatność i użyteczność odpowiednio zaostrzony kamień ułatwiał rozczłonkowanie upolowanej zwierzyny, pług ciągnięty przez konia usprawniał uprawę roli a prasa drukarska umożliwiała znacznie szybsze powielanie informacji. Gatunek ludzki wyróżnia się także spośród innych żywych organizmów niezwykłymi zdolnościami komunikacji. Trudno jest określić kiedy nasi przodkowie zaczęli posługiwać się językiem, lecz pierwsze przesłanki na istnienie komunikacji symbolicznej datowane są na ok 100 tys. lat temu. Opanowanie języka umożliwiło pozagenetyczne przekazywanie zdobytej wiedzy pomiędzy pokoleniami. Język stał się nośnikiem kultury i umożliwił powstanie wszystkiego, co dzisiaj określamy jako ludzkie. Komputer Komputer (z ang. computer od łac. computare obliczać), czyli programowalne urządzenie do wykonywania obliczeń, jest jednym z najbardziej zaawansowanych narzędzi, jakie człowiek do 1 Pojęcie designu zostanie wprowadzone w dalszej części tego rozdziału, na str. 4. 1

10 tej pory wynalazł. Jego podstawowym zadaniem jest wykonywanie obliczeń, jednak możliwość przetworzenia praktycznie każdej informacji na postać cyfrową sprawia, że zastosowania komputerów są niemalże nieskończone. Pierwszy mechanizm, zasługujący na miano komputera, opisany został w 1837 roku przez angielskiego uczonego i wynalazcę Charlesa Babbage a. Zaprojektowana przez niego maszyna analityczna (ang. analytical engine) miała składać się z czterech komponentów: jednostki obliczeniowej, magazynu, czytnika kart perforowanych oraz drukarki. Urządzenie zakładało możliwość dynamicznej zmiany tablic obliczeń, było więc kompletne w sensie Turinga [14]. Projekt wyprzedzał jednak możliwości techniczne ówczesnej epoki i nigdy nie został zrealizowany. Trzeba było kolejnych stu lat, aby osiągnięcia ludzkości pozwoliły na zrealizowanie pierwszych komputerów. Pojawiające się kolejno rozwiązania takie jak ABC ( ), 1 Z3 (1941), Colossus (1943) czy ENIAC (1946) rozpoczęły nową epokę w historii ludzkości. Początkowe jedynie instytucje rządowe i wielkie koncerny mogły pozwolić sobie na rozwiązania typu mainframe. Kolejne lata przynosiły bardziej zaawansowane rozwiązania, które stawały się dostępne dla coraz szerszych grup użytkowników. W latach 50-tych i 60-tych tzw. minikomputery zaczęły pojawiać się w laboratoriach badawczych. Lata 70-te to początek ery tanich układów scalonych i mikrokomputerów, które, produkowane na masową skalę, rozpoczęły informatyczną rewolucję. Dzisiaj mikrokomputery znajdziemy m.in. w zegarkach, telefonach, lodówkach i samochodach. Informatyzacja obejmuje kolejne dziedziny naszego życia i coraz trudniej jest znaleźć aktywność, w której nie uczestniczą systemy informatyczne. Komputery już nie są używane tylko do liczenia służą do komunikacji, przetwarzania tekstów i zdjęć, do tworzenia muzyki i filmów animowanych. Są wykorzystywane do rozrywki i zabawy, oraz do pracy, która ma niewiele wspólnego z liczeniem. Komplikuje się też kwestia terminologii. Mówiąc o telefonie komórkowym lub inteligentnym samochodzie nie okreslamy ich już mianem komputera, chociaż posiadają one procesory o dużych możliwościach obliczeniowych. Löwgren i Stolterman w swojej książce [27] wprowadzają pojęcie cyfrowego artefaktu (ang. digital artefact) na określenie czegoś, co jest dziełem człowieka i co mogło zaistnieć dzięki technologii komputerowej. W tej pracy częściej jednak będziemy posługiwać się terminami takimi jak produkt, system lub program. Interakcja Zaprojektowanie interakcji pomiędzy komputerem a człowiekiem nie jest prostym zadaniem. Pomimo tego, że komputery zostały skonstruowane przez człowieka, należymy do zupełnie innych światów. Ludzie są organizmami żywymi, ukształtowanymi przez miliony lat ewolucji. Pobieramy informacje ze świata za pomocą pięciu zmysłów (wzroku, słuchu, smaku, węchu i dotyku), a komunikujemy się ze sobą głównie za pomocą języka. Komputery gromadzą i przetwarzają informacje jedynie w postaci binarnej. Każda inna reprezentacja tekstowa, graficzna czy dźwiękowa, aby mogła być przetworzona przez komputer, musi być ostatecznie przekształcona w ciąg zer i jedynek. Także informacja zwrotna musi przejść szereg transformacji, aby mogła być zrozumiała przez człowieka. 1 ABC (Atanasoff Berry Computer) urządzenie skonstruowane w Iowa State College, USA było pierwszym elektronicznym urządzeniem liczącym. Nie było jednak komputerem w pełnym znaczeniu tego słowa, ponieważ nie było programowalne. 2

11 Pojawia się zatem konieczność istnienia interfejsu warstwy pośredniej umożliwiającej wymianę informacji w obie strony. Pod pojęciem interfejsu rozumiemy tu zarówno urządzenia wejściowe i wyjściowe służące do komunikacji pomiędzy człowiekiem a maszyną, jak i wszelkie możliwe techniki interakcji i dialogu. Babbage w swojej maszynie analitycznej zaproponował użycie kart perforowanych i rozwiązanie to przez długi czas było z powodzeniem stosowane w informatyce. Odpowiednio przygotowane informacje były kodowane na kartach za pomocą urządzenia zwanego dziurkarką, wstępna weryfikacja była realizowana przez sprawdzarkę, a następnie karty były wkładane do czytnika, który wczytywał informacje do pamięci komputera. Po przetworzeniu przez komputer, być może po kilku godzinach lub dniach, informacje w postaci tekstu lub liczb wracały do użytkownika wydrukowane przez prostą drukarkę. Dużym krokiem w dziedzinie interfejsów były systemy, w których użytkownik miał dostęp do klawiatury i terminalu tekstowego. Wiele warstw pośrednich zostało zautomatyzowanych, przez co uzyskano namiastkę interaktywności i rzeczywistej komunikacji. Komputer reagował na komendy użytkownika znacznie szybciej, łatwiej można było wychwycić i poprawić błędy. Pojawiły się nowe możliwości interakcji, a przez kolejne lata interfejsy tekstowe przeszły długą ewolucję: od prostej linii komend do pełnoekranowych aplikacji o sporych możliwościach. Na początku lat 70-tych zaczęły powstawać pierwsze interfejsy graficzne, które zrewolucjonizowały sposób, w jaki dziś pracujemy z komputerem. Pojawiły się okienka, ikony i komendy w paskach menu, które użytkownicy mogli wybierać za pomocą myszki. Metafora biurka, katalogów i plików odzwierciedlały pojęcia znane z codziennego życia i korzystanie z komputerów stało się bardziej intuicyjne. Dzisiaj, wraz z dalszym rozwojem technologii, pojawiają się coraz to nowe możliwości interakcji. Współczesne kieszonkowe komputery smartphon-y nie posiadają klawiatury ani myszki. Komunikacja odbywa się głównie przez dotykowy ekran, który łączy funkcję urządzenia wejściowego i wyjściowego. Produkty wydają przeróżne dźwięki sygnalizując zdarzenia; coraz lepiej radzą też sobie z komendami wydawanymi za pomocą głosu. Komunikują się też przez zmysł dotyku za pomocą wibrowania. Jedynie możliwości wpływania na zmysł smaku i węchu wciąż pozostają mocno ograniczone. 1.2 Użyteczność Pojęcie użyteczności (ang. usability) pojawiło się w słowniku nauki na początku lat 1980-tych, zastępując używany wcześniej, niezbyt precyzyjny termin przyjazny dla użytkownika [7]. Użyteczność, chociaż jest jednym z najważniejszych pojęć w całej dziedzinie HCI, nie ma jednej definicji. Najtrafniejszą i najczęściej cytowaną jest ta, wprowadzona przez normę ISO [21]: Użyteczność to miara wydajności, efektywności i satysfakcji z jaką dany produkt może być używany przez określonych użytkowników dla osiągnięcia określonych celów w określonym kontekście użycia. Jakob Nielsen [32] proponuje odmienną, bardziej szczegółową terminologię. Pisze o dwóch kluczowych atrybutach jakości interfejsu użytkownika: przydatności (ang. utility) która określa, czy interfejs spełnia swoje zadanie, oraz użyteczności (ang. usability) określającej, czy interfejs jest łatwy w użyciu. Użyteczność definiuje za pomocą pięciu pojęć: 3

12 1. Nauczalność (ang. learnability): jak łatwo jest użytkownikowi wykonać podstawowe zadania przy pierwszym kontakcie z interfejsem? 2. Efektywność (ang. efficiency): jak szybko korzystają z produktu użytkownicy, którzy go znają? 3. Zapamiętywalność (ang. memorability): czy użytkownicy potrafią szybko przypomnieć sobie jak korzystać z interfejsu po dłuższej przerwie? 4. Błędy (ang. errors): ile błędów popełniają użytkownicy, jak poważne są to błędy i czy łatwo mogą się z nimi uporać? 5. Satysfakcja (ang. satisfaction): jak przyjemne jest korzystanie z interfejsu? Pojęcia przydatności i użyteczności są ze sobą bardzo blisko związane, tak że nie sposób myśleć o nich oddzielnie. Interfejs, który jest łatwy w użyciu, ale nie spełnia swojego zadania, jest bezużyteczny. Definicja wprowadzona przez normę ISO zawiera w sobie oba terminy. Dodatkowo mówi ona o kontekście użycia bardzo ważnym, a pomijanym przez Nielsena czynniku mającym wpływ na ocenę użyteczności. Dlatego też, na potrzeby tej pracy korzystać będziemy z pierwszej definicji. 1.3 Design W pracy tej często będziemy korzystać z dorobku designu, 1 rozumianego jako dziedzina sztuki użytkowej spokrewniona z wzornictwem przemysłowym, projektowaniem graficznym, architekturą itp. Chociaż w ostatnim czasie uczyniono wiele w kierunku ustrukturyzowania designu jako nauki [13], pozostaje on wciąż silnie związany ze światem sztuki, który rządzi się własnymi prawami. Pojęcie designu ciągle ewoluuje. Jak pisze Norman [37]: Do niedawna słowo design odnosiło się przede wszystkim do wyglądu produktów. Dzisiaj jest inaczej projektantów interesuje użyteczność i funkcjonalność, spełnianie podstawowych potrzeb i dostarczanie pozytywnych wrażeń. Dostrzeżono, że jednym z podstawowych czynników dobrego designu jest dobra interakcja. (tłum. autor) Gałęzią designu zajmującą się współczesnymi systemami interaktywnymi jest projektowanie interakcji (ang. interaction design). Jest to młoda dziedzina która czerpie zarówno z bogatej tradycji designu, jak i ze współczesnych osiągnięć HCI. 1.4 Projektowanie zorientowane na użytkownika Projektowanie zorientowane na użytkownika (ang. User-Centered Design, UCD) to filozofia projektowa stawiająca użytkownika końcowego jego potrzeby i ograniczenia w centralnym miejscu procesu projektowego. Idea zakłada zaangażowanie w proces produkcyjny ludzi, którzy będą używać systemu w przyszłości, aby stworzyć produkt najlepiej odpowiadający ich wymaganiom. 1 Termin design zapożyczony z języka angielskiego stopniowo upowszechnia się w języku polskim. Czasami tłumaczy się go jako projektowanie, lecz nie oddaje to pełnego znaczenia w tym kontekscie. Słownik wyrazów obcych Władysława Kopalińskiego podaje następującą definicję: «design [wym. dizajn] szeroko pojmowana sfera wzornictwa; planowanie, marketing i organizacja produkcji, tworzenie atrakcyjnej formy wyrobu, tożsamości towaru i wizerunku producenta na rynku.» Słowo znajdziemy też w uniwersalnym słowniku języka polskiego PWN: «design [termin zawodowy związany ze sztuką] a) projekt jakiegoś wyrobu przemysłowego; b) zespół cech charakterystycznych dla jakiegoś twórcy, regionu, projektu itp. Klasyczny design w wystroju wnętrza. Nowoczesny design samochodu.» 4

13 Zaplanuj proces zorientowany na czowieka Określ kontekst użytkowania Oceń rozwiązania pod względem wymagań System spełnia wymagania Określ wymagania użytkownika i organizacji Utwórz rozwiązania projektowe Rysunek 1: Zależności pomiędzy aktywnościami w procesie zorientowanym na użytkownika (na podstawie ISO ) Termin zrodził się w latach 1980-tych w laboratoriach badawczych Donalda Normana i zyskał popularność po publikacji jego książki User-Centered System Design: New Perspectives on Human- Computer Interaction. Początków metody należy jednak szukać w pomysłach skandynawskich badaczy, jak m.in. Kristen Nygaard, którzy w latach 1970-tych po raz pierwszy zaangażowali użytkowników w proces projektowy [1]. Chociaż metoda ta wywodzi się z badań nad użytecznością systemów komputerowych, to jest na tyle ogólna, że można ją stosować podczas projektowania wszelkiego rodzaju produktów i usług. Zazwyczaj używa się wtedy nazwy projektowanie zorientowane na człowieka (ang. Human-Centered Design, HCD). Doświadczenie pokazuje, że produkty zaprojektowane przede wszystkim z myślą o użytkownikach są łatwiejsze w użyciu i dostarczają większej satysfakcji, a praca z nimi jest bardziej efektywna. Przekłada się to na tak realne wartości jak na zyski przedsiębiorstwa, zaoszczędzony czas i oszczędzone frustracje użytkowników. Wielu projektantów wywodzących się ze środowisk artystycznych nadmiernie koncentruje się na wyglądzie produktu. Tych, którzy pochodzą ze świata techniki często interesuje tylko wykorzystanie najnowszych technologii. Projektanci stosujący założenia UCD projektują rozwiązania, które są użyteczne i przynoszą pożytek użytkownikom, organizacjom i całemu społeczeństwu [47]. Norma ISO Pod koniec lat 1990-tych metodologia UCD została sformalizowany przez Międzynarodową Organizację Normalizacyjną w postaci normy ISO Human-centred design for interactive systems. W 2010 roku norma ta została rozszerzona i przemianowana na ISO [22]. Dokument ten definiuje ustrukturalizowany proces oraz poszczególne aktywności, które należy podjąć podczas pracy nad systemem, aby zapewnić wysoką jakość produktu końcowego. Proces opracowany jest w sposób umożliwiający wdrożenie go w organizacjach o różnym stopniu doświadczenia w zagadnieniach związanych z użytecznością. Proces rozpoczyna się etapem planowania, w którym podejmowane są decyzje odnośnie całej przyszłej pracy. Należy zaplanować z jakich metod będziemy korzystać, wyznaczyć harmonogram oraz 5

14 zadecydować o zakresie poszczególnych zadań. Planowanie procesu projektowania nie jest prostym zadaniem. Musimy wziąć pod uwagę wiele czynników, takich jak ograniczone zasoby, budżet i czas. W wielu przypadkach powinniśmy umieć przewidzieć przyszłe sytuacje. Wymaga to od projektanta dużej wiedzy i doświadczenia. Proces projektowania zorientowanego na użytkownika jest procesem iteracyjnym, co oznacza, że kolejne wersje produktu powstają stopniowo. Użytkownicy mogą uczestniczyć w procesie projektowym podczas każdego z tych etapów, jednak ostateczny zakres współpracy pozostaje w gestii projektantów. Ważne jest, aby użytkownicy mieli faktyczny wpływ na ostateczny rezultat prac. Każda iteracja może składać się z czterech etapów: 1) analizy kontekstu, 2) sprecyzowania wymagań, 3) przygotowania projektu, 4) oceny zaproponowanego rozwiązania. W różnych stadiach życia projektu iteracje będą zazwyczaj przebiegać inaczej. W początkowej fazie prac więcej uwagi będzie przeważnie poświęcane analizie kontekstu i określaniu wymagań, natomiast w dalszych iteracjach etapy te mogą zostać całkowicie pominięte, a główny ciężar prac przesunie się na przygotowywanie kolejnych rozwiązań i ich ewaluację. Norma nie określa żadnych wymagań ani nie daje też żadnych wskazówek odnośnie metod pracy nad użytecznością. Istnieje jednak bogata literatura opisująca szczegółowo poszczególne metody, a także wiele innych materiałów ze wskazówkami dla projektantów i przykładami zastosowań w konkretnych sytuacjach projektowych [5, 16, 34]. Każdy projekt jest jednak inny i wymaga indywidualnego podejścia. Nie ma uniwersalnego przepisu, który sprawdzałby się we wszystkich przypadkach. 6

15 2 Metody użyteczności W tym rozdziale przedstawimy wybrane metody użyteczności. Najwięcej miejsca zostanie poświęcone tym metodom, które zastosowano podczas prac nad systemem Hinc. Pokrótce omówimy też inne ważne techniki. Większość z nich jest niezależna od stosowanej technologii i sprawdza się w różnych kontekstach, ale głównie będziemy rozważać zastosowania dotyczące współczesnych komputerów osobistych, zakładając, że użytkownik ma do dyspozycji klawiaturę, myszkę oraz ekran monitora. Niektóre techniki będziemy prezentować wyłącznie pod kątem ich przydatności w niniejszej pracy. Metody zostały podzielone na cztery kategorie odpowiadające poszczególnym etapom procesu ISO Nie należy jednak traktować tego podziału zbyt dosłownie. Poszczególne metody są często przydatne na różnych etapach pracy. Ponadto proces projektowania w rzeczywistym świecie nigdy nie jest liniowy i nie da się go zamknąć w sztywnych ramach algorytmu, dlatego też wybraną kategoryzację należy traktować wyłącznie jako swobodną strukturę porządkującą, ułatwiającą przedstawienie tematu w przystępny sposób. Trzeba także nadmienić, że celem tej pracy nie było przygotowanie kompletnego ani wyczerpującego kompendium dostępnych metod użyteczności. Osoby zainteresowane zgłębieniem tematu odsyłamy do literatury. 2.1 Analiza kontekstu użytkowania Pierwszym krokiem do poznania rzeczywistych potrzeb użytkowników jest zrozumienie kontekstu, w jakim nasz produkt będzie używany (ang. usability context analysis, UCA). Mówiąc o kontekście mamy na myśli wszystkie czynniki, które mają wpływ na użyteczność, lecz nie dotyczą bezpośrednio samego produktu. Określa się je mianem wymagań niefunkcjonalnych. Poradnik opracowany przez Nigela Bevana i in. z Serco Usability Services [44] powstał na bazie doświadczeń z wdrażania normy ISO w wielu firmach i instytucjach. Opisuje on praktyczną metodę identyfikowania i dokumentowania czynników, które mają wpływ na użyteczność. Autorzy sugerują, aby podczas analizy kontekstu skupić się na pięciu czynnikach: użytkownikach systemu, ich zadaniach, środowisku pracy, technologii oraz warunkach fizycznych. Informacje te są zbierane w początkowej fazie projektu oraz stopniowo uzupełniane w dalszych etapach prac. Dokładna analiza tych czynników i uwzględnienie ich w procesie produkcyjnym jest jednym z kluczowych założeń procesu zorientowanego na użytkownika. 1. Użytkownicy. Ważnym pytaniem, na które powinniśmy sobie odpowiedzieć jest kim właściwie są użytkownicy naszego systemu? Pytanie może wydawać się proste, jednak odpowiedź w wielu przypadkach nie będzie oczywista. Zazwyczaj będziemy mogli wyróżnić wiele zainteresowanych stron (ang. stakeholders) i grup użytkowników, które będą używać systemu do realizacji swoich zadań. Każda grupa może mieć odmienne cele, różne kwalifikacje a także inne nastawienie do produktu czy do technologii w ogóle. Istnieje wiele sposobów zbierania i analizowania informacji dotyczących użytkowników. Korzysta się tu głównie z metod wypracowanych przez psychologię i socjologię. Niektóre z nich bardziej szczegółowo omówimy w kolejnym rozdziale. 7

16 Na tym etapie pracy należy jednak zainicjować proces zbierania informacji o użytkownikach i ustalić możliwie najwięcej podstawowych faktów. Dobrze przygotowana charakterystyka każdej rozpatrywanej grupy powinna zawierać informacje o charakterze wykonywanej pracy, a także o wiedzy, doświadczeniu i kwalifikacjach użytkowników systemu. Ważne są też informacje o ewentualnych ograniczeniach lub szczególnych zdolnościach umysłowych, które należy wziąć pod uwagę. 2. Zadania. Do prawidłowego określenia funkcjonalności produktu niezbędne jest zrozumienie zadań, jakie użytkownicy wykonują w obecnym środowisku. Analizę taką przeprowadza się czasami podczas zbierania wymagań funkcjonalnych. Dobrze określone wymagania funkcjonalne mogą zapewnić, że system będzie spełniał swoje podstawowe funkcje, aby jednak system był użyteczny należy wziąć pod uwagę wiele innych czynników. Przy projektowaniu interfejsu wszystkie szczegóły mogą być użyteczne. Oprócz podstawowej charakterystyki zadania, czyli poszczególnych kroków z których się składa, opisu danych wejściowych oraz oczekiwanego rezultatu, należy też określić częstotliwość i ważność zadania, obciążenie umysłowe i fizyczne podczas jego wykonywania, zależności pomiędzy zadaniami itp. Również w tym przypadku repertuar dostępnych metod jest bardzo duży. Klasyczną techniką jest analiza hierarchiczna zadań (ang. hierarchical task analysis, HTA), która polega na dekompozycji zadań na coraz to mniejsze aktywności. Czasami do opisywania zadań używa się przypadków użycia (ang. use case), składających się z opisu kroków niezbędnych do wykonania danego zadania. Metody te uważane są za pracochłonne i nie są zalecane podczas analizy wymagań niefunkcjonalnych. Stosunkowo popularną i znacznie mniej formalną techniką są scenariusze użycia (ang. scenarios of use). Mają one formę krótkich, obrazowych historyjek przedstawiających konkretną sytuację wraz z wieloma informacjami dotyczącymi kontekstu. Scenariusze dobrze sprawdzają się podczas prac nad użytecznością pozwalają na lepsze zrozumienie typowych zadań użytkowników, stanowią też dobrą podstawę testów użyteczności czy oceny heurystycznej. 3. Środowisko pracy. W wielu przypadkach pomocne może być zrozumienie struktury organizacyjnej i komunikacyjnej organizacji, dla której przygotowujemy system. Warto zwrócić uwagę na cele organizacji, relacje w branży oraz stopień współpracy pomiędzy użytkownikami. Przeanalizowanie rzeczywistego przepływu informacji może dać nowy wgląd w znaczenie poszczególnych etapów i zadań, oraz zaowocować pomysłami, które usprawnią dotychczasową pracę. 4. Technologia. Analiza kontekstu powinna też obejmować informacje o sprzęcie, na jakim będzie działać system oraz innych wymaganiach technicznych. W zależności od dostępnej technologii optymalne rozwiązania mogą bardzo się różnić. Ważne jest też zidentyfikowanie innych programów i systemów, które są używane w miejscu pracy. 5. Warunki fizyczne. Na użyteczność mogą też mieć wpływ warunki atmosferyczne, widoczność, dostępna przestrzeń i postura użytkownika podczas korzystania z systemu lub produktu. Należy też uwzględnić wszystkie czynniki ryzyka związane z zagrożeniami zdrowia lub życia. 8

17 2.2 Zbieranie wymagań Gdybym spytał moich klientów, czego potrzebują, to powiedzieliby, że szybszego konia. Henry Ford W procesie projektowym zorientowanym na użytkownika sami użytkownicy mają wpływ na ostateczny kształt produktu. Ich wymagania stanowią podstawę prac, uczestniczą oni w przygotowywaniu rozwiązania projektowego i oni oceniają, czy produkt został właściwie skonstruowany. Nie oznacza to jednak, że tylko użytkownicy decydują o ostatecznym wyniku prac. Prawdę mówiąc taka metoda nie zaprowadziłaby nas zbyt daleko. W rzeczywistym procesie musimy uwzględnić wymagania klienta i organizacji w której system będzie funkcjonował; system musi spełniać wymagania, o których użytkownicy końcowi nie zawsze wszystko wiedzą. Istnieje wiele czynników, które mają wpływ na ostateczny kształt produktu i zadaniem projektanta jest umiejętne uwzględnienie ich w procesie projektowym. Tradycyjne metody analizy wymagań koncentrują się na wymaganiach funkcjonalnych, które mają zapewnić, że system będzie spełniał swoje zadanie. Funkcjonalność i przydatność produktu jest oczywiście bardzo ważna także w przypadku systemów zorientowanych na użytkownika. Atrybuty te nie są jednak głównym przedmiotem zainteresowań UCD. Zakładamy, że wymagania te będą spełnione a naszym głównym celem jest zapewnienie, aby system był użyteczny Spotkanie z użytkownikiem Podstawowe podejście do zbierania wymagań zakłada spotkanie z użytkownikiem twarzą w twarz. Osobisty kontakt jest bardzo ważny, pozwala na lepsze wzajemne zrozumienie i nawiązanie owocnej współpracy. Podczas fizycznego spotkania komunikacja jest najpełniejsza, gdyż rejestrujemy nie tylko to, co użytkownik mówi i robi, ale także emocje, mowę ciała i wszelkie inne informacje przekazywane niewerbalnie. Wiele metod bazuje na bezpośrednim kontakcie z użytkownikiem. Mają one wiele wspólnego (we wszystkich uczestniczy przynajmniej jeden użytkownik i przynajmniej jeden prowadzący), lecz w zależności od celu spotkania, miejsca i innych okoliczności wyróżniamy różne metody. Wywiad (ang. interview) jest jedną z najprostszych technik. Prowadzący spotyka się z użytkownikiem, aby zebrać odpowiedzi na przygotowane wcześniej pytania. Tematyka pytań będzie się różnić w zależności od projektu: może dotyczyć charakteru wykonywanej pracy, doświadczeń z innymi produktami, oczekiwań odnośnie nowej aplikacji itp. Miejsce spotkania nie jest istotne, ważne jest jedynie, aby możliwa była swobodna rozmowa. Podobne spotkanie można przeprowadzić z grupą użytkowników, lecz należy być wtedy świadomym interakcji, jakie mogą wystąpić. Przykładowo, jeżeli na spotkaniu będzie znajdował się przełożony i jego podwładny, to możemy nie dotrzeć do wszystkich istotnych informacji. Uczestnicy spotkania mogą też wzajemnie sugerować się swoimi wypowiedziami i przez to ograniczać własną kreatywność. Wywiady przeprowadza się zazwyczaj w początkowych fazach projektu, gdy chcemy poznać subiektywne oczekiwania użytkowników i ich indywidualne preferencje. Więcej istotnych informacji można jednak uzyskać stosując inne techniki. 9

18 Wywiad środowiskowy (ang. contextual inquiry) to metoda pozwalająca na zebranie cennych danych o użytkowniku, jego środowisku, zadaniach i preferencjach. Spotkanie odbywa się w miejscu pracy użytkownika podczas wykonywaniu jego codziennych czynności. Prowadzący obserwuje użytkownika siedząc obok niego, lub lekko z tyłu i zadając pytania odnośnie wykonywanych aktywności. Ważne jest, aby użytkownik czuł się swobodnie nasza obecność powinna być jak najmniej intruzyjna. Nie powinno się przerywać ani oceniać wypowiedzi, nie należy wpływać na sposób wykonywania zadań. Przeprowadzając wywiad środowiskowy możemy zebrać wiele istotnych informacji. Sporo jednak zależy od tego, jak przygotujemy się do przeprowadzenia spotkania. David Travis [48] udziela kilku praktycznych wskazówek: Przede wszystkim należy sprecyzować jasny cel spotkania (ang. focus question, hunt statement) i przedstawić go użytkownikowi, np. zamierzam zbadać, w jaki sposób wykonujesz codzienne zadania, aby poprawić użyteczność systemu. Ważne jest, aby użytkownik wiedział po co jest to spotkanie i czuł się swobodnie. Trzymając się wyznaczonego celu łatwiej będzie też uniknąć sytuacji, w której rozmowa schodzi na nieistotne dla nas tematy. Travis sugeruje, aby nagrywać spotkanie (najlepiej na dyktafonie) oraz robić zdjęcia. Dzięki temu możemy mieć pewność, że nic nam nie umknie i możemy się lepiej skoncentrować na przeprowadzeniu wywiadu i notowaniu własnych spostrzeżeń. Zdjęcia są źródłem cennych informacji odnośnie kontekstu użytkowania, ułatwią też komunikację z innymi członkami zespołu podczas analizy danych. Ważne jest sporządzanie dokładnych notatek w trakcie przeprowadzania wywiadu. Sugeruje się też napisanie podsumowującego raportu bezpośrednio po zakończeniu spotkania. Najważniejsza podczas przeprowadzenia wywiadu środowiskowego jest jednak zdolność słuchania i obserwacji. Należy zwrócić uwagę na to, jak użytkownik zachowuje się podczas wykonywania zadań: czy sprawiają mu one trudność, czy wykonuje je automatycznie. Czy zachowania systemu budzą w nim zadowolenie, złość, zniecierpliwienie, jakie jest jego nastawienie. Warto notować wszystkie nietypowe terminy, którymi posługuje się użytkownik, stanowiące wewnętrzny żargon organizacji. Wszystkie te informacje mogą okazać się przydatne w dalszych etapach prac Analiza konkurencyjnych rozwiązań Inną, popularną metodą badawczą, używaną podczas prac nad użytecznością jest analiza dostępnych na rynku rozwiązań. Głównym celem przeprowadzania analizy jest dokładne przyjrzenie się produktom, z którymi nasza aplikacja będzie konkurować oraz zidentyfikowanie ich mocnych i słabych stron. Metoda ta pozwala też na znalezienie propozycji rozwiązań, które mogą być zaadaptowane w naszej aplikacji. Pierwszym etapem jest zidentyfikowanie istniejących na rynku konkurencyjnych produktów. Zakładamy, że dysponujemy już informacjami na temat kontekstu użytkowania naszej aplikacji i znamy istotne potrzeby użytkowników. Do analizy powinniśmy wybrać produkty, które spełniają te potrzeby oraz odpowiadają rozpatrywanemu przez nas kontekstowi. W zależności od dostępnego czasu i zasobów analiza może być przeprowadzona na różne sposoby. W podstawowej wersji przyjmuje ona formę oceny eksperckiej, w której systemy analizowane są pod kątem użyteczności podczas wykonywania podstawowych zadań. W przypadku projek- 10

19 tów o większym budżecie analiza może obejmować testy konkurencyjnych produktów z udziałem użytkowników. Można wtedy zebrać więcej cennych informacji. Wnioski z analizy są spisywane w postaci raportu o odpowiednim stopniu dokładności. W podstawowej formie zawiera on obserwacje przedstawione w podpunktach; bardziej obszerna wersja może zawierać dokładne omówienie produktów i zalecenia projektowe, które należy uwzględnić w pracach nad produktem. 2.3 Utworzenie rozwiązania projektowego Najważniejszą i najtrudniejszą częścią całego procesu jest utworzenie rozwiązania projektowego. Rozwiązaniem tym, w przypadku systemów informatycznych, będzie cyfrowy artefakt prototyp o pewnym stopniu dokładności lub w pełni funkcjonalny produkt. Jak powiedziano już wcześniej, nie da się jasno wyznaczyć granic pomiędzy poszczególnymi etapami procesu projektowego. Pomysły dotyczące rozwiązania mogą pojawić się na każdym etapie prac, czasami w najmniej spodziewanych momentach. Praca twórcza jest jedną z najmniej rozumianych ludzkich aktywności i jest najmniej podatna na próby opisania jej za pomocą metod i algorytmów. Nie znaczy to jednak, że takie próby nie są podejmowane. Istnieje wiele sposobów na stymulowanie wyobraźni projektantów, na planowanie pracy w sposób skutkujący najlepszymi efektami. Metodologia projektowania zorientowanego na użytkownika jest jednym z takich rozwiązań. Wszystkie działania w całym cyklu projektowym służą zebraniu danych i analizie materiałów potrzebnych na etapie tworzenia rozwiązania projektowego Prototypowanie Prototyp jest pewną aproksymacją gotowego produktu, posiadającą jego istotne właściwości. Prototypem może być szkic interfejsu wykonany ołówkiem, statyczny obrazek przygotowany przy pomocy programu graficznego, lub prosta aplikacja umożliwiająca interakcję. W przypadku projektowania fizycznego produktu prototypem może być makieta wykonana ze styropianu, pianki lub innego materiału. Podstawową funkcją prototypu jest funkcja komunikacyjna tworzymy je, aby przedstawić klientowi, użytkownikom i innym członkom zespołu propozycje rozwiązań i zebrać informacje zwrotne. Prototypowanie jest jedną z najważniejszych technik w projektowaniu zorientowanym na użytkownika. Prototypy służą za podstawę testów użyteczności i umożliwiają zebranie uwag we wczesnych etapach prac. Dzięki nim możemy wychwycić i wyeliminować wiele błędów jeszcze zanim zaczniemy proces implementacji. Główną zaletą tworzenia prototypów jest to, że ich przygotowanie nie wymaga zazwyczaj dużych nakładów pracy. Możemy sobie pozwolić na zaprojektowanie różnych wersji rozwiązania i, zbierając opinie użytkowników, wybrać tę, która będzie najodpowiedniejsza. Stworzone prototypy mogą również posłużyć za dokumentację projektową. Przykładowo, podczas projektowania serwisu internetowego często tworzy się kilka wstępnych propozycji szaty graficznej, czasami przygotowanych przez różnych grafików. Rozwiązania mają postać statycznych obrazków, które można zaprezentować klientowi i użytkownikom. Zazwyczaj 11

20 niewielkim nakładem prac możemy też przygotować interaktywną wersję prototypów, w której użytkownicy mogą klikać aktywne elementy i przechodzić pomiędzy ekranami. Daje to wrażenie obcowania z funkcjonalnym produktem i ułatwia przekazanie idei interakcji. Bazując na zebranych opiniach wybiera się jeden projekt, które będzie zrealizowany Iteracyjne projektowanie W metodologii projektowania zorientowanego na użytkownika proces projektowy przyjmuje formę iteracyjną. Oznacza to, że etapy projektowania, oceny projektu i doprecyzowywania wymagań powtarzają się cyklicznie. Różni się to od tradycyjnych metod (jak np. model kaskadowy), w których etap projektowania występuje tylko raz. Gdyby zastosować projektowanie iteracyjne do opisanego wcześniej przykładu tworzenia serwisu internetowego, proces mógłby wyglądać następująco: (a 1 ) Określamy kontekst użytkowania przyszłego systemu. (r 1 ) Zbieramy oczekiwania klienta i użytkowników odnośnie powstającego serwisu. (p 1 ) Projektant przygotowuje prototypy kilku wersji interfejsu w postaci prostych szkiców na papierze. (e 1 ) Przedstawiane są one użytkownikom i na podstawie ich opinii wybiera się jedną z wersji. (p 2 ) Na podstawie wybranego rozwiązania przygotowuje się bardziej dokładne prototypy. (e 2 ) Przeprowadza się ocenę nowych prototypów. (p 3 ) Po uwzględnieniu wniosków z oceny wprowadza się w prototypach poprawki i rozpoczyna proces implementacji serwisu. (e 3 ) Wersja testowa serwisu poddawana jest testom użyteczności. (p 4 ) Po uwzględnieniu wyników testów wprowadzane są poprawki i serwis jest umieszczany w sieci. Etap projektowania (p i ) pojawił się w tym przypadku cztery razy. W pierwszej iteracji efektem pracy były papierowe prototypy, w drugiej dokładne prototypy graficzne, w trzeciej częściowo funkcjonalne rozwiązanie i w czwartej końcowy produkt Wzorce interakcji Wzorce projektowe interfejsu użytkownika (ang. user interface design patterns) lub wzorce interakcji (ang. interaction design pattern) są sposobem na opisanie optymalnych rozwiązań dla częstych problemów pojawiających się podczas projektowania interakcji. Koncepcję wzorca wprowadził po raz pierwszy Christopher Alexander, jako sposób na opisanie rozwiązań architektonicznych. Pojęcie to zostało zaadoptowane na potrzeby innych dziedzin, w tym także informatyki, gdzie jest powszechnie używane do opisywania problemów związanych z projektowaniem architektury systemów [17]. 1 Opisany proces mógłby okazać się zbyt skomplikowany, aby go zastosować podczas projektowania prostej witryny internetowej, jednak w przypadku dużego serwisu o złożonej nawigacji byłby jak najbardziej wskazany. Decyzja o wyborze metod pracy zawsze powinna należeć do projektanta. 12

21 Można powiedzieć, że wzorce interakcji powstają na drodze ewolucji i naturalnej selekcji. Dokumentowane przez projektantów rozwiązania rzeczywiście sprawdzają się w praktyce i odpowiadają poznawczym możliwościom użytkowników. To właśnie sprawia, że wzorce stanowią nieocenioną pomoc przy projektowaniu interakcji. Umiejętnie stosując sprawdzone metody możemy mieć pewność, że nasz produkt będzie łatwy i przyjemny w użyciu. Podobnie jak wzorce projektowe stopniowo zadomawiają się w informatycznym folklorze i stają się elementem bibliotek oraz języków programowania, tak i wzorce interakcji kształtują rozwój technologii interfejsów. Przykładem mogą być nowości wprowadzane w języku HTML5 takie jak wsparcie dla operacji przeciągnij i upuść, programowa obsługa przycisku wstecz w przeglądarce, znacznik paska postępu ÔÖÓ Ö lub nowe semantyczne znaczniki: Ö, ÓÓØ Ö oraz Ò Ú. Istnieją również próby opisania wzorców interakcji za pomocą formalnych modeli. Korzystające z nich rozwiązania mogą mieć praktyczne zastosowanie podczas generowania interfejsów użytkownika na podstawie odpowiednio zamodelowanych wymagań, lub automatycznego przekształcania interfejsów w zależności od technologii klienta [39]. W swoim podstawowym zastosowaniu wzorce interakcji mają być jednak pomocą dla projektantów. Poniżej przedstawimy trzy przykładowe wzorce, które zastosowano podczas projektowania nowego interfejsu dla programu Hinc. Figure 2: Dwupanelowy selektor w programie Norton Commander Dwupanelowy selektor (ang. two-panel selector) to jeden z najprostszych, ale i najskuteczniejszych wzorców interakcji. Stosujemy go, gdy chcemy zapewnić użytkownikowi możliwość przeglądania informacji związanych z kolekcją obiektów. W pierwszym panelu, najczęściej znajdującym się po lewej stronie, umieszczamy elementy w postaci listy lub struktury drzewiastej. Wybranie jednego elementu powoduje pokazanie szczegółowych informacji w drugim panelu. Wzorzec jest spotykany w wielu aplikacjach programach pocztowych, menadżerach plików i w popularnych serwisach internetowych. Nawet początkujący użytkownicy znajdują analogię z podobnymi rozwiązaniami i szybko poznają sposób działania. Wykorzystanie tego wzorca powoduje mniejsze obciążenie poznawcze niż prezentowanie szczegółowych informacji na odrębnym ekranie. Przy odświeżeniu całego okna użytkownik musi poświęcić więcej uwagi aby zorientować się co jest pokazywane. Odświeżenie jedynie fragmentu ekranu 13

22 wymaga przeskanowania mniejszej powierzchni. Dodatkowo lista jest ciągle aktywna i ułatwia wizualne zlokalizowanie elementu w strukturze [45]. Narzędzia pokazujące się po wskazaniu elementu (ang. hover-reveal tools) ujawniają się po najechaniu kursorem na aktywny element. Ten typ nawigacji jest szczególnie przydatny, gdy chcemy pozwolić użytkownikowi na interakcję z treścią dokumentu, a jednocześnie zależy nam na estetyce i przejrzystości interfejsu. Zyskując na przejrzystości tracimy niestety pewną część użyteczności związaną z odkrywalnością (ang. discoverability). Użytkownik dowiaduje się o ukrytej funkcjonalności dopiero po najechaniu kursorem na element i początkowo mogą wystąpić problemy z odnalezieniem funkcji systemu. Jest to jednak kompromis na który możemy sobie pozwolić, bo bardzo szybko idea działania staje się zrozumiała i naturalna [42, 25]. Edycja w miejscu (ang. inline edit) to wzorzec pozwalający na wzbogacenie interfejsu o możliwość edycji tekstu, przy jednoczesnym zachowaniu przejrzystości interfejsu. Tekst wyświetlany jest w standardowy sposób i dopiero po kliknięciu w niego pojawia się pole edycji. Należy zasygnalizować użytkownikowi, że taka funkcjonalność istnieje, np. przez podświetlenie tekstu po najechaniu nań kursorem. Można rozważyć użycie tego wzorca w przypadku każdego tekstu, które użytkownik może chcieć zmieniać. Nie należy jednak przesadzać jeśli podstawową funkcją strony jest edycja treści, wówczas kontrolka edycji powinna być cały czas widoczna [25] Standardy, wskazówki i zasady projektowe Badania pokazują, że użytkownicy lepiej oceniają użyteczność interfejsów, których obsługa jest dla nich intuicyjna. Intuicyjność rozwiązania oznacza, że użytkownik spotkał się już z czymś podobnym w przeszłości i wie, czego oczekiwać. Jeśli coś wygląda jak przycisk, to użytkownik prawdopodobnie będzie próbował w to kliknąć; jeśli wygląda jak checkbox lub radio-button będzie chciał go zaznaczyć; jeśli wygląda jak pasek przewijania będzie próbował go przeciągnąć. Znaczenie tych elementów ustaliło się już wiele lat temu i użytkownicy komputerów bez problemu je rozpoznają. W wielu przypadkach możemy też zakładać znajomość wielu innych technik interakcji użytkownik może próbować kliknąć prawym przyciskiem myszki, aby uzyskać menu kontekstowe lub może użyć skrótów klawiszowych, które zna z innych programów, aby wykonać podobną akcję (Ctrl+Z, Ctrl+C, Ctrl+V,...). W witrynach internetowych użytkownicy zinterpretują podkreślony tekst w kolorze niebieskim jako odnośnik, klikając w logo serwisu będą chcieli przejść do strony głównej, a menu nawigacyjnego będą szukać po lewej stronie lub w górnej części ekranu. Cenne wskazówki dotyczące projektowania interfejsów dla konkretnych platform można znaleźć w dokumentach dostarczanych przez producentów systemów jak np. Apple Human Interface Guidelines [3] lub Windows User Experience Interaction Guidelines [28]. Zawierają one szczegółowe informacje na temat wykorzystania poszczególnych elementów interfejsu oraz ustalonych standardów i konwencji. 14

23 W przypadku Internetu, który nie ma centralnej organizacji odpowiedzialnej za platformę, 1 Jakob Nielsen proponuje pragmatyczne podejście: jeśli ponad 80% stron internetowych używa tego samego rozwiązania, uznaje się je za standardowe; w przypadku, gdy rozwiązanie stosowane jest w 50 79% przypadków, uważane jest za konwencję; w pozostałych sytuacjach, w których żadne z rozwiązań nie dominuje, użytkownicy są zakłopotani, gdyż nie wiedzą czego oczekiwać. Wtedy zadaniem projektanta jest zaproponowanie optymalnego rozwiązania. Na wyższym poziomie abstrakcji znajdują się zasady projektowe (ang. design principles). Są to ogólne reguły, które warto mieć na uwadze podczas projektowania. Don Norman w swojej książce [36] opisuje kilka z nich. Pisze o tym, jak ważne są modele konceptualne, czyli reprezentacje produktu, które użytkownik tworzy w swoim umyśle. Istotne są reakcje artefaktu na nasze działania, naturalne ograniczenia możliwych interakcji oraz dobre mapowania pomiędzy kontrolkami a rzeczywistością. Kluczowe jest też odpowiednie umieszczenie znaczników informujących o możliwych akcjach. Zasady projektowe nie zawierają żadnych szczegółów dotyczących technologii, są uniwersalne i niezależne od kontekstu. Umiejętne ich zastosowanie wymaga jednak od projektanta dużego doświadczenia oraz dogłębnego zrozumienia zagadnień związanych z projektowaniem. Należy je rozumieć raczej jako narzędzia wspomagające kreatywność i podejmowanie decyzji, niż jako proste techniki, które można zastosować w każdej sytuacji. 2.4 Ewaluacja interfejsu Diabeł tkwi w szczegółach przysłowie ludowe Ważnym etapem w pracy nad projektem jest ocena przygotowanego prototypu. Przeprowadzamy ją aby lepiej poznać potrzeby użytkowników, otrzymać informacje zwrotne na temat projektu, lub porównać alternatywne rozwiązania. Metody ewaluacji możemy podzielić na dwie podstawowe kategorie: metody eksperckie, w których specjaliści w dziedzinie użyteczności oceniają interfejs bazując na wyznaczonych kryteriach i własnej wiedzy. Najpopularniejsze metody z tej dziedziny to ocena heurystyczna i cognitive walkthrough; metody empiryczne, w których to użytkownicy są podstawowym źródłem informacji. Do najpopularniejszych metod należą różne odmiany testów użyteczności, kwestionariusze, czy testowanie A/B. Proces ewaluacji można rozpocząć w każdym stadium projektu, gdy tylko dysponujemy pierwszymi prototypami. Wczesne uwzględnienie wniosków z ewaluacji zazwyczaj przekłada się na zaoszczędzony czas i lepszą jakość końcowego produktu. Również w późniejszych fazach powinniśmy przeprowadzać ewaluacje szczegółowych prototypów i częściowo funkcjonalnych rozwiązań. Uwagi zebrane w tych etapach zazwyczaj będą dokładniejsze i bardziej wiarygodne. 1 Za organizację taką można uznać World Wide Web Consortium (W3C), jednak zajmuje się ona jedynie opracowywaniem standardów na poziomie technicznym. 15

24 2.4.1 Historia ewaluacji Metody ewaluacji interfejsów mają swoje korzenie w badaniach nad ergonomią i czynnikiem ludzkim, przeprowadzanych na długo przed pojawieniem się komputerów. Początkowo celem badaczy było odkrycie praw rządzących ludzkim zachowaniem i opracowanie obiektywnych metod naukowych, które mogły znaleźć zastosowanie w praktyce. Jednym z pionierów tych badań był amerykański psycholog Paul M. Fitts ( ). Zapisał się on w historii jako autor matematycznego modelu opisu ruchu człowieka, który wykorzystał m.in. do poprawy bezpieczeństwa samolotów wojskowych. Model ten, zwany prawem Fittsa, określa czas potrzebny na wskazanie obiektu jako wprost proporcjonalny do logarytmu odległości, a odwrotnie proporcjonalny do logarytmu rozmiaru obiektu docelowego. Prawo Fittsa można sformułować w postaci wzoru: ( ) T = a+blog 2 1+ D W gdzie: T to czas, D odległość pomiędzy punktem początkowym a środkiem obiektu docelowego, W wielkość celu, a a i b to empiryczne zmienne, takie jak czas reakcji lub czas potrzebny na kliknięcie przycisku. Przekładając to na język interfejsów: łatwiej jest kliknąć w duży przycisk, który znajduje się w pobliżu kursora. Znajomość tej prawidłowości jest bardzo przydatna przy projektowaniu i analizie interfejsów. Prawo Fittsa okazuje się użyteczne przy wszystkich typach urządzeń wskazujących, w szczególności myszki, ale także innych urządzeń sterowanych za pomocą rąk, nóg, sterowanych wzrokiem, itp. (a) (b) Rysunek 3: Dwie propozycje interfejsu okna kontekstowego. Inną ciekawą techniką pozwalającą oszacować czas wykonywania zadania na komputerze wyposażonym w klawiaturę i myszkę, jest Keystroke-Level Model uproszczona wersja analizy GOMS. 1 Polega ona na tym, że poszczególnym czynnościom przypisujemy ustalone empirycznie wartości czasowe, np.: K = 0.28 s. naciśnięcie i zwolnienie klawisza klawiatury, P = 1.1 s. wskazanie elementu za pomocą myszy, B = 0.1 s. naciśnięcie i zwolnienie przycisku myszy, H = 0.4 s. przeniesienie ręki z myszy na klawiaturę i vice versa, M = 1.2 s. przygotowanie mentalne, W(t) = t ms. czekanie na odpowiedź systemu. 1 GOMS (ang. Goals, Operators, Methods, Selection rules) ciężka metodologia analizy zachowań użytkowników. Rzadko stosowana w praktyce, ze względu na duży nakład pracy. 16

25 Następnie rozkładamy zadanie na czynności atomowe i otrzymujemy oszacowanie czasu, jaki zadanie zajmie przy wykorzystaniu danego interfejsu. Dzięki tej metodzie możemy zmierzyć efektywność i w obiektywny sposób porównać różne wersje interfejsu. Jeśli w przykładach na rys. 3 będziemy chcieli wybrać opcję Update entire table, w sytuacji (a) zadaniu temu będzie odpowiadać sekwencjaàåè È z czasem wykonywania 4.0 s., zaś w sytuacji (b) sekwencjaàåè z czasem zaledwie 2.8 s. [24] Ocena heurystyczna Jedną z najczęściej stosowanych eksperckich metod ewaluacji interfejsów jest zaproponowana przez Nielsena i Molicha ocena heurystyczna (ang. heuristic evaluation). Polega ona na tym, że jeden lub kilku oceniających analizuje produkt pod kątem spełniania podstawowych wytycznych, zwanych heurystykami. 1 Każdy znaleziony problem jest odnotowywany, wraz z informacją o jego ważności oraz odnośnikiem do heurystyki którą narusza. Wynikiem ewaluacji jest dokument zawierający wszystkie odnalezione błędy, a czasem także sugestie rozwiązań problemów. Zaproponowany przez autorów zestaw składa się z 10 heurystyk: I. Pokazuj status systemu. II. Zachowaj zgodność pomiędzy systemem a rzeczywistością. III. Daj użytkownikowi pełną kontrolę. IV. Trzymaj się standardów i zachowaj spójność. V. Zapobiegaj błędom. VI. Pozwalaj wybierać zamiast zmuszać do pamiętania. VII. Zapewnij elastyczność i efektywność. VIII. Dbaj o estetykę i umiar. IX. Zapewnij skuteczną obsługę błędów. X. Zadbaj o pomoc i dokumentację. Ocena heurystyczna, w miarę możliwości, powinna być przeprowadzana przez kilka osób. Badania pokazują, że zwiększa to szanse na wychwycenie większej ilości błędów; dodatkowo unikamy sytuacji, w której indywidualne preferencje decydują o ostatecznym kształcie systemu. Metoda nie wymaga dużego przygotowania od oceniających, chociaż zalecane jest, aby mieli oni podstawową wiedzę z zakresu projektowania interakcji. Idealnym rozwiązaniem jest zatrudnienie ekspertów użyteczności. Przed rozpoczęciem ewaluacji należy unikać tłumaczenia oceniającym dokładnych zasad działania programu. Jedynie w przypadku systemów o wąskich zastosowaniach znajomość dziedziny może być pomocna. W takich przypadkach warto przygotować scenariusze opisujące typowe zadania użytkowników. Zazwyczaj jednak oceniający powinni być w stanie poradzić sobie sami i jedynie w ostateczności polegać na radach osób znających system. 1 Należy je rozumieć jako element pośredni pomiędzy wskazówkami a zasadami projektowymi, opisanymi w punkcie

26 2.4.3 Testy użyteczności Test użyteczności (ang. usability testing) jest najprostszą i najskuteczniejszą empiryczną metodą ewaluacji interfejsu. Do jego przeprowadzenia potrzebny jest jedynie użytkownik, prototyp rozwiązania oraz osoba przeprowadzająca test. Użytkownik dostaje do wykonania zadania, często sformułowane w formie prostych scenariuszy. Prowadzący obserwuje zachowanie użytkownika i wychwytuje wszelkie istotne informacje. Głównym celem testu jest zbadanie, jak użytkownicy radzą sobie z wykonywaniem podstawowych zadań oraz poznanie ich opinii o produkcie. Podczas testów użyteczności często stosuje się technikę zwaną protokołem głośnego myślenia (ang. think aloud protocol). Polega ona na tym, że użytkownik podczas wykonywania zadań mówi na bieżąco o tym, co robi. Analizując wypowiedzi użytkownika możemy lepiej zrozumieć jego działania i zidentyfikować przyczyny problemów. Przed rozpoczęciem testu należy zaznajomić użytkownika z metodą i podkreślić, że oceniamy program, a nie jego. Metoda zakłada jak najmniejszą ingerencję prowadzącego. W idealnej sytuacji, po podaniu wstępnych informacji i rozwianiu wątpliwości prowadzący powinien jedynie obserwować i słuchać. Nie powinien odpowiadać na żadne pytania, nie powinien w żaden niewerbalny sposób oceniać tego, co użytkownik robi lub mówi. Testy użyteczności mogą przyjmować też bardziej rozbudowaną formę. Czasami przeprowadza się je w specjalnych laboratoriach, wyposażonych w wydzielone pokoje obserwacyjne. Zachowania użytkowników są nagrywane na video, często z kilku różnych kamer, rejestrujących zawartość ekranu, układ rąk na klawiaturze i mimikę użytkownika. Materiał uzyskany podczas takich testów jest znacznie bogatszy, jednak jedynie firmy dysponujące odpowiednimi środkami mogą sobie pozwolić na takie badania. W większości przypadków wystarczą jednak znacznie prostsze warunki. Ważnym aspektem przeprowadzenia testów użyteczności jest wybranie odpowiednich użytkowników. Jeśli to możliwe powinny to być osoby, które rzeczywiście używają lub będą używać danego produktu. Jeśli nasz produkt ma być wykorzystywany przez lekarzy, to powinniśmy ich zaprosić do testów; jeśli tworzymy serwis młodzieżowy, to powinniśmy testować go z uczniami lub studentami. W przypadku, gdy produkt przeznaczony jest do szerokiego grona odbiorców musimy wybrać osoby odpowiednie dla danej grupy docelowej. 18

27 Część II Omówienie wykonanych prac Ta część zawiera szczegółowe omówienie zadań wykonanych przez autora podczas pracy nad projektem. Kolejne iteracje zostaną przedstawione w porządku chronologicznym, odpowiadającym rzeczywistemu przebiegowi prac. Rozdział 3 opisuje pokrótce etap zapoznawania się z systemem i dostępnymi materiałami oraz planowania przyszłych prac. Zdecydowano się na wykorzystanie metodologii projektowania zorientowanego na użytkownika wraz z elementami metodyk zwinnych. Określono wstępny plan na kolejne miesiące i przystąpiono do prac nad pierwszą iteracją. W zakres pierwszej iteracji (rozdział 4) weszło przebudowanie modułu wskaźników. Iteracja objęła wszystkie etapy cyklu UCD: zdefiniowanie kontekstu i wymagań, przygotowanie prototypów, przetestowanie ich z użytkownikami oraz implementację. Druga iteracja (rozdział 5) poświęcona była modułowi planu działania. Również w tym przypadku zbadano aktualny kontekst użytkowania i przeanalizowano istniejące wymagania. Przygotowano kilka propozycji rozwiązań i rozpoczęto implementację jednej z nich. Ostatnia trzecia iteracja (rozdział 6) objęła rozwiązania dotyczące całego systemu. Zadaniem autora było przygotowanie szkicowych rozwiązań dotyczących kolejnych etapów prac nad systemem. 19

28 3 Iteracja 0 Zapoznanie się z systemem czas: (3 tygodnie) zakres prac: planowanie W początkowym etapie prac głównym zadaniem autora było zapoznanie się z istniejącym systemem poznanie struktury aplikacji, metod pracy oraz wykorzystywanych technologii. Rozmawiano na temat historii projektu oraz planach na najbliższe miesiące. W tym czasie narodził się też pomysł udokumentowania wykonanych zadań w postaci niniejszej pracy magisterskiej. 1 Przeprowadzono przegląd metod pracy nad użytecznością, które mogłyby być użyte podczas dalszych prac. Rozpoczęto też spisywanie nowych wymagań oraz propozycji dotyczących nowego interfejsu. 3.1 Analiza dokumentacji Dokładny projekt systemu stanowiła obszerna dokumentacja opracowana za pomocą programu Enterprise Architect [31]. Zawierała ona ponad 150 opisanych przypadków użycia, ok. 100 wymagań funkcjonalnych, ok. 100 opisów reguł biznesowych oraz wiele diagramów klas. Dokumentacja ta stanowiła bogate źródło informacji, lecz niestety duża jej część była już nieaktualna. Bardzo szczegółowo był też opracowany system pomocy. Oprócz krótkiego wstępu i historii wersji można było znaleźć tam opis funkcjonalności poszczególnych części systemu. Każda z podstawowych akcji systemu była opisana w postaci kroków niezbędnych do jej wykonania. Informacje te okazały się jednak zupełnie nieprzydatne i użyteczność systemu pomocy w obecnej formie okazała się wątpliwa. 3.2 Analiza funkcjonalności Najskuteczniejszą formą odkrywania rzeczywistej funkcjonalności okazał się przegląd dostępnych funkcji i próby wykonania podstawowych zadań za pomocą systemu. Już na początku użytkowania zauważono wiele niedogodności czyhających na nowego użytkownika systemu. Wszystkie uwagi zaczęto spisywać w postaci listy, która później przerodziła się w ewaluację heurystyczną obecnej wersji programu (zał. C na stronie 41). 3.3 Analiza kontekstu Istniejąca dokumentacja zawierała zaledwie dwie wzmianki odnoszące się do wymagań niefunkcjonalnych: RNF Wspieranymi przeglądarkami są Netscape 4.7 i Internet Explorer 5.0 oraz późniejsze wersje. RNF System musi posiadać przyjazny interfejs użytkownika. Podczas prac nad projektem autor zapoznał się także z wieloma niepisanymi wymaganiami dotyczącymi kontekstu użytkowania. Wymagania te w wielu przypadkach wydawały się tak oczywiste, 1 Początkowo praca magisterska miała zostać napisana w języku angielskim, po pewnym czasie jednak zdecydowano się na napisanie jej po polsku. 20

29 a w innych tak rozmyte i niejasne, że do tej pory nikt nie zadał sobie trudu spisania ich i ustrukturalizowania. Jak się później okazało, brak jasnych decyzji odnośnie kontekstu użytkowania w wielu przypadkach był powodem problemów i nieporozumień. Analiza kontekstu uwzględniająca informacje zebrane podczas całego czasu trwania projektu znajduje się w trzeciej części tej pracy (zał. A na stronie 35). Dokument zawiera podstawowe informacje o użytkownikach systemu oraz ich środowisku pracy, a także główne założenia odnośnie wykorzystywanej technologii. W ramach analizy kontekstu, w późniejszych etapach prac, przygotowano też szczegółową analizę najważniejszych zadań wykonywanych przez obecnych użytkowników. Wstępnie zaproponowany harmonogram obejmował dokładną analizę użyteczności obecnego systemu, przygotowanie propozycji zmian, a następnie przejście do etapu projektowania i implementacji. Ostatecznie postanowiono podzielić pracę na mniejsze etapy. W pierwszej kolejności zmiany miały objąć moduł wskaźników wykorzystywany przez urząd stanu Santa Catarina. Prace związane z tym modułem ujęto w ramy pierwszej iteracji. 21

30 4 Iteracja 1 Moduł wskaźników czas: (6 tygodni) zakres prac: moduł wskaźników, system raportów, rozwiązania nowego interfejsu Moduł wskaźników jest najmłodszą historycznie częścią systemu. Początkowo był on projektowany jako uniwersalne narzędzie do analizy wskaźników jakości, jednak na skutek nawiązania współpracy z działem planowania administracji stanu Santa Catarina moduł przekształcił się w dedykowane rozwiązanie dostosowane do potrzeb klienta. 4.1 System oceny wydziałów rozwoju regionalnego Santa Catarina jest jednym z 26 stanów Brazylii. Jego powierzchnia wynosi km² (ok 30% powierzchni Polski) i zamieszkiwany jest przez 6,2 mln. mieszkańców [52]. W roku 2003 administracja stanu przeprowadziła reformę administracyjną, wprowadzając nową, dwustopniową strukturę organizacyjną. Stan podzielono na 6 sektorów oraz 36 regionów, przekazując nowym jednostkom administracyjnym odpowiednie uprawnienia decyzyjne. Główną celem przeprowadzenia reformy była decentralizacja władzy publicznej, zmniejszenie biurokracji i usprawnienie jakości świadczonych usług publicznych. Przekazanie władzy nowym jednostkom organizacyjnym zrodziło potrzebę monitoringu i oceny efektywności poszczególnych Wydziałów Rozwoju Regionalnego (pt. SDR - Secretaria de Estado de Desenvolvimento Regional). Opracowano precyzyjny model składający się z 53 wskaźników, z których część odnosiła się do obszarów kompetencji wydziału (zdrowie, edukacja, gospodarka, infrastruktura), a część pozwalała mierzyć skuteczność działania lokalnej administracji [12]. Do zbierania i analizowania danych początkowo używano arkusza kalkulacyjnego, lecz wkrótce uświadomiono sobie potrzebę użycia narzędzia lepiej dostosowanego do potrzeb administracji. Zdecydowano się na wybór systemu Hinc dostarczanego przez firmę Nec Plus Ultra. 4.2 Nowe wymagania W momencie przystąpienia autora do pracy nad projektem, system Hinc był używany przez wydział planowania administracji stanu Santa Catarina od ponad roku. Przez ten czas w aplikacji zgromadzono sporą ilość danych i pojawiła się potrzeba zaprezentowania ich w przystępny sposób. Klient zgłosił zapotrzebowanie na trzy rodzaje raportów generowanych przez system. Dodanie tej funkcjonalności nie było prostym zadanie, gdyż wymagało przebudowy wewnętrznej reprezentacji danych aplikacji i stworzenia nowego systemu szablonów. Nowe wymagania były jasno określone i dział programistyczny miał już wstępny projekt rozwiązania. Zadaniem autora było przeprojektowanie interfejsu użytkownika w ten sposób, aby zapewnić nową funkcjonalność, eliminując przy tym wszelkie problemy użyteczności istniejące w obecnej wersji modułu. 4.3 Ocena heurystyczna modułu Przed przystąpieniem do przygotowania rozwiązań projektowych wykonano ocenę heurystyczną istniejącego modułu i zidentyfikowano problemy dotyczące użyteczności. Szczegółowy raport do- 22

31 Rysunek 4: Prototyp ekranu szczegóły celu stępny jest jako załącznik C.2 na stronie 43. Za podstawowe uchybienie uznano fakt, że najważniejsza funkcjonalność systemu ukryta jest na końcu długiej ścieżki nawigacyjnej i dostęp do niej jest bardzo utrudniony. Rozwiązania dotyczące nawigacji często sugerowały mylne znaczenie poszczególnych opcji, co mogło prowadzić do błędów skutkujących utratą ważnych informacji. System nie zawierał żadnych wskazówek, które pozwalałyby zorientować się z strukturze danych i wzajemnych zależnościach. Sam teoretyczny model obliczeń wskaźników był dość złożony, a istniejący system dodatkowo niepotrzebnie go komplikował. Podczas oceny zrodziło się wiele sugestii i pomysłów, które zostały zrealizowane w dalszych etapach prac. 4.4 Prototypy ekranów Po przeprowadzeniu analizy przystąpiono do przygotowywania prototypów. Wykonanie pierwszych projektów było trudnym zadaniem, gdyż należało jednocześnie wykonać dwa zadania: po pierwsze zaprojektować rozwiązania interakcji w nowym module wskaźników, a po drugie zaproponować szatę graficzną i główną nawigację dla całej aplikacji. Na szczęście udało się wykonać oba zadania równocześnie i pierwsze propozycje zostały przyjęte bez większych zmian. Można było uniknąć tej trudności projektując najpierw poglądowe prototypy poszczególnych ekranów, a dopiero po ich zatwierdzeniu opracować dokładne rozwiązania graficzne. W rzeczywistości powstało wiele szkiców interfejsu wykonanych na papierze, które służyły do komunikacji w zespole. Ich kopie jednak nie zachowały się do dokumentacji. Przygotowano prototypy czterech ekranów: 1) lista celów (ang. objective list), 2) szczegóły celu (ang. objective details), 3) lista szablonów (ang. template list), 4) szczegóły szablonu (ang. template details). 23

32 Szata graficzna oparta została na motywie Enterprise Gray dostarczanym wraz z biblioteką Smart- GWT. Wykorzystano ikony z tego motywu, oraz dodatkowo wybrane piktogramy z kolekcji Crystal Project Icons. 1 Prototypy były utrzymane w jednorodnej kolorystyce z dominującym kolorem niebieskim. Zaproponowane rozwiązania nawigacyjne zakładały umieszczenie paska aplikacji w górnej części ekranu. Miał być to stały element systemu, służący do nawigacji pomiędzy poszczególnymi modułami. Umieszczono na nim jedynie najważniejsze odnośniki, aby ograniczyć jego rozmiar na ekranie. Podstawowy model nawigacji wewnątrz modułu oparto o wzorzec dwupanelowy selektor (opisany na str. 13). Dostępną przestrzeń ekranu podzielono na dwie części o proporcjach 2 /3+ 1 /3. Wybranie elementu w lewym panelu miało powodować aktualizację danych po prawej stronie. Aby zwiększyć dostępną przestrzeń w prawej części zastosowano rozwijane panele (ang. closable panels). Zaproponowane rozwiązanie było uniwersalne i elastyczne. Dzięki modułowej budowie dodawanie nowych funkcjonalności przebiegało sprawniej, gdyż nie wymagało przebudowy całego interfejsu. Wyznaczone konwencje miały być także przestrzegane w przyszłości, podczas prac nad innymi modułami. 4.5 Testy prototypów Po wykonaniu prototypów przystąpiono do przetestowania ich z użytkownikami systemu. Pierwszy test przeprowadzono z Renatą testerką aplikacji zatrudnioną w firmie. 1 Renata należała do zespołu programistycznego, lecz nie była bezpośrednio związana z projektowaniem nowego interfejsu. Dobrze znała działanie poprzedniej wersji systemu i rozumiała główne idee wprowadzanych zmian w funkcjonalności, więc po krótkim wprowadzeniu mogliśmy skutecznie przeprowadzić test. Test przeprowadzono z wykorzystaniem protokołu głośnego myślenia (str. 18) oraz metody czarodzieja z krainy Oz. Użytkownikowi pokazywano statyczny ekran i zlecano wykonanie podstawowych zadań. Użytkownik opisywał w jaki sposób próbowałby wykonać zadanie, a prowadzący omawiał reakcję systemu na akcję użytkownika lub zmieniał ekran na kolejny, jeśli było to konieczne. Podczas eksperymentu zebrano wiele uwag, które zaraz po zakończeniu testu zostały spisane w postaci raportu. Znaleziono kilka drobnych błędów interfejsu oraz kilka cennych uwag, które zostały uwzględnione w dalszych etapach pracy. W zachowaniu użytkownika widoczne były także nawyki z poprzedniej wersji systemu. Uwagi związane z tymi aspektami nie były brane pod uwagę w dalszych pracach. 4.6 Prezentacja prototypów klientowi Następnym krokiem było zaprezentowanie prototypów nowych ekranów klientowi. Odbyło się spotkanie, w którym uczestniczyła kierowniczka wydziału planowania, oraz dwóch pracowników 1 Crystal Project Icons to opracowana przez Everaldo Coelho kolekcja ikon udostępniana na licencji LGPL. Zawiera ona ogromny zbiór dobrze zaprojektowanych piktogramów utrzymanych w jednorodnej stylistyce. Ikony z tej kolekcji wykorzystywane są w m.in. w środowisku graficznym KDE. 1 Raport z testu znajduje się w załączniku D.1 na stronie

33 administracyjnych. Spotkanie miało bardziej formalny charakter, więc ograniczono się do prezentacji nowych rozwiązań oraz zebrania uwag i sugestii ze strony klienta. 2 Kierowniczka reprezentowała ważną grupę użytkowników systemu kierownictwo średniego szczebla. Można było zauważyć, że podstawowe cele użytkownika dotyczą analizy danych, generowania zestawień i raportów. Większość uwag dotyczyła sugestii nowych rozwiązań, które nie były uwzględnione w najbliższej iteracji. Nowe rozwiązania dotyczące wprowadzanie danych oraz ich weryfikacji zostały zaakceptowane bez większych poprawek. Następnie wykonano drugą wersję prototypów, uwzględniającą wnioski z przeprowadzonych testów oraz niektóre sugestie użytkowników. Dokonano zmian w kolorystyce aplikacji zdecydowano się na użycie bardziej jaskrawych kolorów. Nowe prototypy posłużyły za dokumentację prac nad bieżącą iteracją. 4.7 Implementacja Zaimplementowanie nowej funkcjonalności wymagało dużych zmian w wewnętrznej strukturze danych aplikacji. Zdecydowano, że najlepszym rozwiązaniem będzie porzucenie aktualnego kodu i rozpoczęcie prac od początku, uwzględniając wszystkie zebrane wcześniej doświadczenia. Nową aplikację oparto o komercyjną wersję biblioteki SmartGWT oferującą wiele przydatnych rozwiązań i udogodnień. Biblioteka zawierała bogaty zestaw kontrolek interfejsu użytkownika, które w łatwy sposób można było integrować z logiką biznesową i źródłami danych. Rysunek 5: Poglądowy model danych w module wskaźników W pierwszej kolejności przygotowano nowy model danych. Wygenerowano z niego tabele bazy danych i szkielet aplikacji, który posłużył za podstawę dalszych prac. Autor rozpoczął pracę nad 2 Raport ze spotkania znajduje się w załączniku D.2 na stronie

34 implementacją interfejsu użytkownika, a drugi programista pracował nad logiką biznesową. Podczas programowania trzymano się standardów i dobrych praktyk programistycznych. Praca szła sprawnie i po kilku tygodniach udało się zrealizować założenia iteracji. Po przejściu podstawowych testów i przekonwertowaniu istniejących danych nowa wersja modułu została wdrożona u klienta. Opinie użytkowników były bardzo pozytywne. 4.8 Wskaźniki jakości w NPU Pod koniec fazy implementacji przeprowadzono wywiad z Marianą pracowniczką NPU odpowiedzialną za kontrolę jakości. Celem spotkania było przeanalizowanie możliwości wykorzystania nowego modułu wskaźników dla wewnętrznych potrzeb firmy. 1 W ocenie nowy system wypadł znacznie lepiej niż jego poprzednia wersja. Został jednak uznany za zbyt złożony, aby realizować obliczenia wskaźników jakości w firmie. Takie zastosowanie systemu nie było jednak priorytetem i nie było uwzględnione we wstępnych wymaganiach. Oceniono, że model obliczeń jest dobrze zaprojektowany i w przyszłości możliwe będzie opracowanie uproszczonej wersję modułu stosunkowo niewielkim nakładem prac. Zmiany te nie były jednak przewidziane w najbliższym harmonogramie. 1 Raport ze spotkania znajduje się w załączniku D.4 na stronie

35 5 Iteracja 2 Moduł planu działania czas: (9 tygodni) zakres prac: moduł planu działania Można śmiało powiedzieć, że moduł planu działania jest najważniejszym elementem systemu Hinc. Przed rozpoczęciem prac przeanalizowano ponownie architekturę modułu i jego powiązania z pozostałymi częściami aplikacji. Rysunek 6: Komponenty ujęte w zakresie prac nad iteracją 2 Chociaż liczba funkcji oferowanych przez ten moduł była porównywalna z funkcjonalnością modułu wskaźników, to istniało kilka czynników zwiększających stopień trudności i ryzyka tej w iteracji: 1. Stopień powiązania modułu z pozostałymi częściami aplikacji jest bardzo wysoki. Przy pracy nad poprzednią iteracją mogliśmy pozwolić sobie na swobodne przeprojektowanie architektury systemu i napisanie modułu praktycznie od początku ponieważ był on niezależny. W tym przypadku musimy zapewnić współpracę z istniejącymi modułami, w szczególności z kalendarzem, modułem wskaźników i modułem diagnostycznym. Planowane zmiany powinny zakładać jak najmniejszą ingerencję w powiązane części systemu. 2. Funkcjonalność modułu jest codziennie wykorzystywana przez pracowników firmy. 3. W poprzedniej iteracji wymagania dotyczące nowej funkcjonalności były określone w tym przypadku musimy zaproponować propozycje zmian. 5.1 Analiza konkurencyjnych rozwiązań Podczas przygotowań do pracy nad tą iteracją przeprowadzono przegląd produktów o podobnej funkcjonalności. Zebrano informacje od pracowników firmy i skorzystano z wyszukiwarki inter- 27

36 netowej. Duża część znalezionych rozwiązań ukierunkowana była na zarządzanie projektami programistycznymi zrezygnowano z analizy tych rozwiązań, ponieważ nie odpowiadały one kontekstowi użytkowania aplikacji Hinc. Niektóre rozwiązania oferowały dostęp do wersji testowej i tam gdzie było to możliwe przeprowadzono ewaluację działających systemów. W wielu przypadkach jednak wgląd w rzeczywistą funkcjonalność był ograniczony i za podstawę ewaluacji posłużyły zrzuty ekranu i informacje marketingowe dostarczane przez producenta. Ograniczyło to w oczywisty sposób dokładność oceny, ale metoda ta okazała się wystarczająca na potrzeby projektu. Ostatecznie zdecydowano się na dokładne przeanalizowanie trzech produktów: Scopi, PBworks oraz Basecamp. Szczegółowa analiza tych rozwiązań znajduje się w dodatku B na stronie Spotkania z użytkownikami W ramach drugiej iteracji przeprowadzono spotkania z pracownikami firmy NPU oraz zebrano ich uwagi i sugestie. Spotkania miały na celu zbadanie, w jaki sposób użytkownicy wykorzystują system w swojej codziennej pracy. Chociaż moduł planowania spełniał swoje podstawowe zadania, to jego obsługa w wielu przypadkach bardzo utrudniała codzienną pracę. Dokładne testy przeprowadzono z dwoma osobami reprezentującymi różne grupy użytkowników. Pierwszy test przeprowadzono z Liage, która była zatrudniona jako pracownik administracyjny. Do jej zadań należało układanie planu dla konsultantów oraz monitorowanie postępów prac. Spotkanie przeprowadzono jeszcze w czasie trwania pierwszej iteracji, ponieważ Liage miała wkrótce zmienić pracę. Okoliczność ta dawała szansę na bardziej otwartą i szczerą krytykę systemu i rzeczywiście w czasie spotkania uzyskano sporo cennych uwag. 1 Drugie spotkanie przeprowadzono z Dimitrim jednym z konsultantów zajmujących się wdrażaniem systemów klasy ERP w firmach budowlanych. Dzięki specyfice swojej pracy Dimitri potrafił dokładnie opisać procesy i sekwencje realizowanych zadań. Jego uwagi okazały się bardzo przydatne i dały duży wgląd w rzeczywisty przebieg prac. 2 Testy użyteczności ujawniły wiele niedogodności, a dodatkowa analiza danych w aplikacji ukazała także inne problemy. Użytkownicy często używali różnych funkcji w sposób niezgodny z przeznaczeniem świadczyło to z jednej strony o elastyczności systemu, ale z drugiej o jego niedostosowaniu do wykonywania podstawowych zadań. 5.3 Ocena heurystyczna modułu Przeprowadzona ocena heurystyczna ujawniła wiele problemów i niedogodności. Raport z oceny, który można odnaleźć w załączniku C.3 na stronie 46, zawiera uwagi zebrane przez autora oraz niektóre problemy zgłaszane przez użytkowników. W sumie odnaleziono 32 problemy użyteczności, w tym jeden krytyczny ( ) i aż 12 problemów średniej wagi ( ). Korzystanie z modułu nie było intuicyjne przy pierwszym kontakcie z systemem. Aby poznać działanie poszczególnych opcji, w wielu przypadkach trzeba było zasięgnąć opinii doświadczonych użytkowników. Dodatkowo okazało się, że znaczna część funkcjonalności działa niepoprawnie 1 Szczegóły w raporcie D.3 na stronie Szczegóły w raporcie D.5 na stronie

37 Rysunek 7: Pierwszy prototyp ekranu szczegóły projektu albo w ogóle nie jest zaimplementowana. Bardzo negatywnie wpływało to na użyteczność, bo jaki użytek użytkownicy mogą mieć z kontrolek, które w ogóle nie działają? Lepszym rozwiązaniem byłoby ukrycie ich aż do czasu zaimplementowania odpowiedniej funkcjonalności. 5.4 Propozycje zmian Po dokładnym przeanalizowaniu wszystkich materiałów przygotowano propozycje zmian oraz pierwszy prototyp głównego ekranu. Propozycje zakładały znaczne uproszczenie systemu i dostosowanie go do aktualnych potrzeb użytkowników. Biorąc pod uwagę ograniczony czas i zasoby planowano, aby ta iteracja pokryła najmniejszy, niezbędny zakres funkcjonalności. Pod koniec kwietnia przedstawiono zebrane pomysły kierownictwu projektu. Chociaż niektóre pomysły zostały uznane za interesujące, to jednak główne propozycje zmian odrzucono i uznano za zbyt daleko idące. Istniejąca architektura informacji została zaprojektowana dawno temu i nie zamierzano z niej rezygnować, mimo iż nie zawsze odpowiadała ona rzeczywistym wymaganiom. Argumenty kierownictwa przeciwko proponowanym zmianom często były uzasadnione. Błędem autora okazało się nadmierne skupienie na bieżących użytkownikach systemu i nie branie pod uwagę potrzeb przyszłych klientów. W innych sytuacjach, chociaż istniała zgoda co do słuszności wprowadzenie zmian, z różnych względów trzeba było pozostać przy starych, niewygodnych strukturach. Sytuacja ta pokazała, że w rzeczywistych projektach użyteczność nie zawsze musi być priorytetem. Wprowadzenie zaproponowanych zmian i uproszczenie systemu z pewnością zaowocowałoby poprawą użyteczności, lecz być może obniżyłoby atrakcyjność rynkową produktu. Ostateczny wynik procesu projektowego jest często efektem ścierania się różnych racji, rezultatem kompromisów i trudnych decyzji. Tak było i w tym przypadku. Pierwszy prototyp trzeba było wyrzucić do kosza i rozpocząć pracę od nowa. 29

38 Rysunek 8: Drugi prototyp ekranu szczegóły projektu 5.5 Druga wersja prototypu Opracowanie czytelnego interfejsu przy znacznie większej funkcjonalności okazało się nie lada wyzwaniem. Zdecydowano się na złamanie konwencji i zmianę używanego do tej pory szablonu strony. Listę z zadaniami rozciągnięto na całą dostępną szerokość, pozostawiając jedynie miejsce na pionowe zakładki po lewej stronie. Dzięki temu mogliśmy dodać dodatkowe kolumny do tabeli, nie powodując wizualnego chaosu. Zawartość prawej szpalty przeniesiono do pionowych zakładek. Funkcjonalność z nimi związana nie była kluczowa dla użytkowników systemu, więc ukrycie tych opcji nie spowodowało obniżenia użyteczności, a być może nawet ją poprawiło: w pierwszym projekcie każdy z elementów miał do dyspozycji tylko małą część ekranu i przy większej ilości danych pojawiałby się pasek przewijania, który mógłby utrudniać znalezienie interesującej nas pozycji. W nowym rozwiązaniu każda z sekcji miała do dyspozycji znacznie większą przestrzeń, która dawała duże możliwości czytelnej prezentacji danych. Projekt listy zadań wymagał bardzo szczegółowego przeanalizowania. Była to kluczowa funkcjonalność modułu, a być może i całego systemu. Podczas całego czasu trwania iteracji eksplorowano i testowano różne rozwiązania nawigacji. Ostateczny prototyp widoczny na rysunku 9 zapewniał wymaganą funkcjonalność oraz spełniał najważniejsze założenia dotyczące użyteczności. Tym razem nie było czasu na dokładne testy prototypów z użytkownikami. Zaprezentowano jednak prototypy pracownikom firmy i ich opinie były bardzo pozytywne. 5.6 Implementacja Przygotowanie prototypów trwało dłużej niż przewidywano, ale na szczęście harmonogram projektu był dość elastyczny. Po zaakceptowaniu prototypów ustalono wstępny plan dalszych prac i zakres zadań do wykonania w tej iteracji. Autor miał pracować nad implementacją przez najbliższy miesiąc, a po tym czasie rozpocząć pracę nad trzecią iteracją. Podobnie jak wcześniej, autor miał zajmować się głównie programowaniem interfejsu użytkownika. 30

39 Rysunek 9: Prototyp możliwe interakcje dla jednego zadania A) nazwa dwukrotne kliknięcie otwiera szczegóły zadania, B) połączona funkcjonalność paska postępu oraz stanu wykonywania zadania, C) data rozpoczęcia edycja w miejscu; kolory informują o opóźnieniu, D) data zakończenia edycja w miejscu; kolory informują o opóźnieniu, E) osoby przypisane do zadania edycja w miejscu, autouzupełnianie, F) załączniki, G) komentarze, H) edycja szczegółów, I) usunięcie zadania. W kilku miejscach projekt zakładał wykorzystanie nietypowych kontrolek, których nie było wśród komponentów dostarczanych przez bibliotekę SmartGWT, więc należało napisać je od początku. W innych sytuacjach trzeba było zmieniać domyślne zachowanie istniejących komponentów i dostosowywać je do wymagań projektu. Czasami wybrana technologia narzucała dodatkowe ograniczenia i zrealizowanie zaplanowanych rozwiązań wymagało zastosowania obejść lub kompromisów. Zazwyczaj jednak praca szła sprawnie i najważniejsze założenia udało się zrealizować zgodnie z planem. W momencie zakończenia przez autora pracy nad drugą iteracją dostępna była wersja alfa posiadająca podstawową funkcjonalność. Większość elementów interfejsu użytkownika została zaimplementowana, lecz nie wszystko jeszcze działało idealnie. Niektóre komponenty były wciąż atrapami i nie były podpięte do odpowiednich procedur biznesowych. Programiści NPU kontynuowali pracę nad kodem i kilka miesięcy później nowa wersja modułu planu działania została zakończona i wdrożona z sukcesem w firmie. 31

40 6 Iteracja 3 Pozostałe części systemu czas: (4 tygodnie) zakres prac: komunikacja, diagnostyka, konfiguracja systemu Ostatnim etapem pracy nad projektem była integracja części systemu nie objętych do tej pory refaktoryzacją. Były to moduły o mniejszym priorytecie (jak np. diagnostyka) lub stosunkowo mało skomplikowane (jak system wiadomości, konfiguracja systemu czy baza zasobów). Tym razem autor pracy nie miał już uczestniczyć w etapie implementacji. Głównym celem iteracji było zebranie pomysłów i przygotowanie prototypów ułatwiających wykonanie przyszłych prac. Na początku przygotowano kompletną listę istniejących i planowanych elementów interfejsu. 1 Okazało się, że do wykonania pozostało blisko 2/3 ekranów i kontrolek przewidzianych w pełnej wersji systemu. W większości były to jednak elementy o prostej funkcjonalności, rzadko używane przez użytkowników, więc ich użyteczność nie miała znaczącego wpływu na jakość całego systemu. W wielu przypadkach można było też zastosować opracowane wcześniej konwencje i wzorce interakcji. 6.1 Prototyp Z powodu innego charakteru prac oraz ograniczeń czasowych zdecydowano się na zastosowanie metody szybkiego prototypowania. Wybrano do tego celu program Axure RP Pro 6 ułatwiający tworzenie interaktywnych prototypów. 30 dniowa wersja próbna dostarczana przez producenta w zupełności wystarczyła do naszych potrzeb. 2 Przygotowany prototyp miał postać strony internetowej i zawierał projekt nawigacji całego systemu, z wyjątkiem tych części, które zostały opracowane we wcześniejszych iteracjach. Opracowano bardziej czytelny układ dla istniejących elementów interfejsu, oraz zaproponowano kilka nowych rozwiązań. Zebrano też pomysły dotyczące systemu, które pojawiały się na różnych etapach prac. Tym razem można było uwzględnić także te elementy, których zaimplementowanie byłoby bardzo pracochłonne. Nie trzeba też było wnikać w szczegóły techniczne prototyp miał jedynie pokazywać możliwości przyszłej aplikacji, która być może kiedyś zostanie zrealizowana. Przygotowano prototypy ekranów modułu diagnostycznego uwzględniające zmiany w architekturze danych. Znacznie zmieniono podstawową funkcjonalność modułów związanych z projektami i zasobami, a także ekrany konfiguracji systemu. Zaprojektowano nowy wygląd oraz nową funkcjonalność kalendarza oraz zaproponowano nowe rozwiązania ułatwiające komunikację, takie jak czat, system powiadomień, czy łatwy dostęp do wiadomości. Przygotowano też szczegółowy prototyp ekranu logowania, który był pierwszym elementem pokazującym się użytkownikowi i miał duży wpływ na odbiór systemu. Wśród pomysłów zaproponowanych w tej iteracji znalazło się wiele rozwiązań ułatwiających dostęp do informacji istotnych z punktu widzenia użytkownika. Strona główna systemu miała być spersonalizowanym punktem zawierającym listę zadań przypisanych do danego użytkownika, listę projektów i planów, w których uczestniczy oraz przegląd najnowszych wiadomości. Strona pro- 1 Załącznik E na stronie Strona programu: 32

41 Rysunek 10: Prototyp spersonalizowanej strony głównej systemu jektu miała pokazywać poglądowy kalendarz oraz ostatnią aktywność związaną z tym projektem. Zaproponowano też możliwość zawężania zakresu działania systemu do jednej organizacji lub jednego projektu. Podobne rozwiązania istniały we wszystkich konkurencyjnych produktach i analiza użyteczności pokazała potrzebę opracowania tej funkcjonalności. Prototyp miał na celu pokazanie możliwości dalszej ewolucji systemu. Zaprezentowano go kierownictwu i użytkownikom, nie było już jednak czasu na zebranie opinii i wniosków, ani na przygotowanie kolejnych, bardziej szczegółowych iteracji. 33

42 7 Podsumowanie Praktyka autora w firmie Nec Plus Ultra dobiegła końca 10 lipca 2011 roku. Zarówno w opinii kierownictwa projektu, jak i autora, zakończyła się ona dużym sukcesem. Wybrane metody pracy sprawdziły się w praktyce i pozwoliły na dokładne zbadanie problemów użyteczności systemu, przeprowadzenie testów z użytkownikami, zaproponowanie zmian oraz częściowe ich zaimplementowanie. Biorąc pod uwagę ograniczenia, o których wspomniano na początku pracy, dostępny czas udało się wykorzystać bardzo efektywnie. Wszystkie aktywności związane z ewaluacją, analizą i projektowaniem interfejsu użytkownika zostały obszernie opisane w niniejszej pracy. Autor uczestniczył także w opracowywaniu nowej architektury systemu oraz w pracach implementacyjnych, którym poświęcono tutaj mniej miejsca, a które były równie ważne z punktu widzenia projektu. W opinii autora zrealizowano główny cel tej pracy magisterskiej, czyli poprawę użyteczności systemu Hinc. Wprawdzie nie przeprowadzono formalnej ewaluacji użyteczności po wykonaniu wszystkich prac, jednak opinie otrzymywane podczas prezentacji prototypów, oraz po oddaniu do użytku poszczególnych części systemu były bardzo pochlebne. Z pewnością jeszcze wiele można by zrobić dla poprawy użyteczności tego systemu. Dalsze testy z użytkownikami prowadziłyby do kolejnych obserwacji, które być może podważyłyby słuszność niektórych decyzji. W wielu miejscach zapewne nie udało się uniknąć wpływu selektywnego postrzegania i indywidualnych preferencji autora być może inny projektant zaproponowałby inne, być może lepsze rozwiązania. Każdy projekt informatyczny jest jednak unikalny, a dotyczy to także pracującego nad nim zespołu, który ma swój wkład w powstanie całości. 34

43 Część III Załączniki A Analiza kontekstu użytkowania A.1 Użytkownicy Głównymi użytkownikami programu są pracownicy administracyjni oraz kierownictwo organizacji. Zakładamy dobrą znajomość obsługi komputera oraz programów biurowych (Excel, Word). Grupy użytkowników: pracownik (ang. employee) osoba pracująca w firmie lub organizacji, odpowiedzialna za wykonywanie zadań oraz wprowadzanie danych, 1 menadżer (ang. manager) pracownik administracyjny średniego stopnia, odpowiedzialny za projekt, kierownik (ang. executive) odpowiedzialny za wyniki organizacji, 2 kontroler jakości (ang. quality inspector) odpowiedzialny za kontrolę jakości w organizacji. Użytkownicy powiązani z systemem, ale nie używający go bezpośrednio: reprezentant klienta finansuje i kontroluje wykonanie projektów, sekretarka lokalnego urzędu odpowiedzialna za dostarczanie danych (moduł wskaźników). A.2 Środowisko pracy Aplikacja skierowana jest do małych i średnich firm oraz do organizacji publicznych na terenie Brazylii. Nie uwzględniamy dużych firm, ponieważ takie potrzebują bardziej zaawansowanych rozwiązań. A.3 Technologia System jest aplikacją typu RIA 3 opartą na technologii SmartGWT. Wykorzystywany jest serwer aplikacji Tomcat oraz baza danych PostgresSQL. Aplikacja działa w przeglądarkach internetowych Firefox 3+, IE 8+, Chrome 4+. Wspierana rozdzielczość ekranu to 1024x768. Nie ma szczególnych wymagań odnośnie niższych ani wyższych rozdzielczości, lecz system powinien optymalnie wykorzystywać dostępną przestrzeń. Zakładamy dostęp do aplikacji przez wewnętrzną sieć organizacji lub przez szybkie łącze internetowe. 1 Czasami zamiennie mogą pojawiać się terminy odpowiadające danemu typowi organizacji, jak np urzędnik (ang. public servant) lub konsultant (ang. consultant). 2 W przypadku organizacji rządowej będzie to urzędnik wyższy rangą (ang. goverment official). 3 ang. Rich Internet Application, bogata aplikacja internetowa 35

44 A.4 Zadania Zadanie Przygotowanie projektu warunki wstępne: Zawarto umowę z klientem dotyczącą nowego projektu. cel: Zaplanowanie pracy działu produkcyjnego. opis: Pracownik administracyjny wprowadza informacje o nowym projekcie. Tworzy za pomocą gotowych szablonów nowe plany oraz przypisuje ich realizację odpowiednim pracownikom. Wprowadza terminy wykonywania poszczególnych planów oraz ich etapów. Np. w przypadku firmy konsultingowej prowadzącej szkolenia z obsługi oprogramowania, każdy plan może odnosić się do odrębnego modułu objętego umową; odpowiedzialny za realizację wszystkich planów będzie tylko jeden konsultant. wynik: Wprowadzone do systemu informacje o projekcie; pracownicy zostali powiadomieni o przypisanych im zadaniach. Opcjonalnie: wydruk zestawienia informacji do wiadomości klienta. częstotliwość: Stosunkowo rzadko raz w tygodniu, raz w miesiącu. czas wykonywania: min Zadanie Aktualizacja planu warunki wstępne: Pracownik wykonał jakieś zadanie lub jego część. cel: Poinformowanie przełożonego o postępach. opis: Pracownik uaktualnia status przydzielonych mu zadań, lub uaktualnia informacje o postępie, opcjonalnie dodając komentarz. wynik: Plan zawiera uaktualnione informacje. Opcjonalnie: odpowiednie osoby dostają powiadomienie o zmianach. częstotliwość: Często kilka razy dziennie. czas wykonywania: 1 5 min Zadanie Modyfikacja planu warunki wstępne: Dokonano ustaleń odnośnie kolejnych etapów prac lub zaistniała potrzeba zmiany bieżącego planu. cel: Dokumentacja postępu prac. opis: Pracownik wprowadza informacje o nowych zadaniach. Opcjonalnie: przydziela je odpowiednim osobom. wynik: Plan zawiera uaktualnione informacje; pracownicy zostali powiadomieni o przypisanych im zadaniach. częstotliwość: Raz lub kilka razy w tygodniu. czas wykonywania: W zależności od rodzaju planu od kilku do kilkudziesięciu minut. 36

45 Zadanie Wprowadzanie danych o wskaźnikach warunki wstępne: Pracownik posiada nowe informacje o wartości wskaźników dla danego celu w danym okresie. cel: Aktualizacja danych umożliwiająca dokonanie analizy. opis: Pracownik odnajduje właściwy obiekt analizy oraz odpowiedni wskaźnik i wprowadza informacje o wartości tego wskaźnika w danym okresie. Np. W przypadku wydziału planowania w urzędzie będą to informacje przysłane przez sekretariat danego regionu. wynik: Dane są zapisane w bazie i odpowiednie wartości są obliczane automatycznie. częstotliwość: W zależności od częstotliwości pomiarów wskaźnika raz w miesiącu, raz na dwa miesiące, raz na kwartał. czas wykonywania: Wprowadzenie wartości pojedynczego wskaźnika powinno zajmować jak najmniej czasu (mniej niż minutę). Najczęściej pracownik będzie musiał wprowadzić dużą ilość wskaźników. Zadanie Zdefiniowanie szablonu wskaźników warunki wstępne: Zaistniała potrzeba pomiaru nowego typu obiektów (np. wydajności pracowników). cel: Zdefiniowanie szablonu wskaźników umożliwiającego analizę obiektów danego typu. opis: Kontroler jakości definiuje strukturę wskaźników które będą mierzone. Dla każdego wskaźnika określa jego parametry takie jak nazwa, częstotliwość i jednostka pomiaru. Określa też wagi wskaźników czyli informacje o tym, jaki wpływ będą miały na ogólny wynik. Opcjonalnie wprowadza dodatkowe komentarze ze wskazówkami dla wprowadzających informacje. wynik: Zdefiniowany poprawnie szablon. częstotliwość: Bardzo rzadko (jest to jednak ważna funkcjonalność). czas wykonywania: W zależności od ilości parametrów kilka godzin, lub kilka dni. Zadanie Modyfikacja szablonu wskaźników warunki wstępne: Wcześniej został zbudowany szablon wskaźników, być może zdefiniowano cele korzystające z tego szablonu. Zaistniała potrzeba modyfikacji szablonu. cel: Wprowadzenie zmian w strukturze szablonu oraz we wszystkich celach opartych na tym szablonie. opis: W trakcie prowadzenia pomiarów okazało się, że struktura wskaźników nie została poprawnie określona. Kontroler jakości modyfikuje strukturę wskaźników wprowadzając odpowiednie zmiany. wynik: Szablon oraz wszystkie cele korzystające z tego szablonu zostają zaktualizowane. częstotliwość: Stosunkowo rzadko (jest to jednak ważna funkcjonalność). czas wykonywania: W zależności od ilości parametrów od kilku minut do kilku godzin. 37

46 B Analiza konkurencyjnych rozwiązań B.1 Scopi Software de Controle de Projetos e Indicadores Scopi jest oprogramowaniem rozwijanym przez firmę TCA Informática z siedzibą w Taquara w Brazylii. Jak informuje wydawca, system służy do planowania strategicznego, zarządzania projektami, procesami i wskaźnikami i skierowany jest do organizacji publicznych oraz firm prywatnych, niezależnie od ich wielkości. Wśród listy klientów znajduje się prefektura miasta Porto Alegre, instytucje zajmujące się zarządzaniem jakością i liczne organizacje pozarządowe. 1 System Scopi uznano za szczególnie wart uwagi z kilku względów. Po pierwsze, funkcjonalność systemu, a w szczególności moduł wskaźników, bardzo pokrywają się z funkcjonalnością oferowaną przez system Hinc. Po drugie, jest to system podobnej skali, rozwijany również w Brazylii. Po trzecie, może on być postrzegany jako bezpośredni konkurent systemu Hinc. Wydawca nie oferuje możliwości skorzystania z wersji testowej programu, jednak na stronie internetowej produktu znajdują się zrzuty ekranu wszystkich ważniejszych części systemu i to one posłużyły za podstawę ewaluacji. Zalety rozwiązania 1. Interfejs systemu jest w przeważającej części czytelny, spójny i przejrzysty. 2. Jasne powiązania pomiędzy poszczególnymi modułami: (a) użytkownik może określić cele biznesowe na mapie strategicznej; (b) następnie stworzyć projekty opisujące w jaki sposób te cele będą realizowane; (c) oraz zdefiniować wskaźniki pozwalające na śledzenie realizacji zadań; (d) terminy realizacji zadań i projektów pokażą się automatycznie w kalendarzu. 3. Możliwość szczegółowej konfiguracji powiadomień wysyłanych przez system. Wady rozwiązania 1. Nie wszystkie opcje systemu przedstawione są w sposób czytelny dla użytkownika. Niektóre z ekranów prezentowały dużą zbyt dużą ilość niepotrzebnych informacji. 2. Dobór ikon był w niektórych przypadkach bardzo nieintuicyjny a czasami nadmierne akcentowano akcje, które nie wymagały zwiększonej uwagi: (a) Strzałki kierunków niewłaściwie wykorzystywane do oznaczenia stopnia ryzyka. (b) Priorytet zadania oznaczony przez żółtą ikonę z wykrzyknikiem, która kojarzona jest z ostrzeżeniem lub istniejącym problemem. (c) Najbardziej rzucającą się w oczy ikoną jest wielki czerwony przycisk wyjścia z systemu. (d) Czerwona ikonka pojawiająca się jako zawsze widoczna, kontekstowa akcja wielu rekordów w systemie nadmiernie przyciąga uwagę, w dodatku jej wygląd przypomina znak drogowy zakazu wjazdu. 1źródło: marzec

47 3. Wybór wykres kołowego, jako metody prezentacji graficznej informacji analizy SWAT 2 nie jest zbyt trafny. B.2 PBworks: Online Collaboration PBworks jest jednym z największych na świecie dostawców rozwiązań wspierających współpracę online. Firma oferuje dedykowane rozwiązania skierowane do agencji interaktywnych, sektora usług prawniczych, konsultingowych czy firm biotechnologicznych, ale także do organizacji nonprofit czy sektora edukacyjnego. Każda z dostępnych wersji produktu oferuje nieco inny zestaw funkcjonalności dostosowany do potrzeb klienta. 1 Na potrzeby analizy założono konto testowe w wersji PBworks Business skierowanej do małych i średnich firm. Funkcjonalność tej wersji była zbliżona do funkcjonalności oferowanej przez moduł plan działania systemu Hinc. Obszar roboczy (workspace) odpowiada pojęciu projektu, natomiast funkcjonalność modułu zadania (tasks) odpowiada modułowi plan działania. Zalety rozwiązania 1. Interfejs zrealizowany jest w sposób przejrzysty, jasny i czytelny. 2. Moduł zadań: (a) Przy tworzeniu nowego zadania system zapewnia podstawową, minimalną funkcjonalność: nadania nazwy zadaniu, przypisania go do wybranej osoby i określenia terminu wykonania. (b) Możliwość przeglądania zadań związanych z danym projektem wg różnych kryteriów: w siatce kalendarza, wg daty planowanego zakończenia lub wg zdefiniowanych kamieni milowych (milestones). (c) Możliwość łatwego przeglądania zadań przypisanych do wybranego użytkownika lub utworzonych przez niego. (d) Przyciski tworzenia nowego zadania i kamienia milowego znajdują się w widocznym miejscu. (e) Użytkownik może jednym kliknięciem oznaczyć zadanie jako wykonane. (f) Każda zmiana dotycząca zadania jest rejestrowana w postaci wpisu w historii, do której użytkownik ma łatwy dostęp. 3. Użytkownik ma możliwość łatwego przeglądania i wyszukiwania plików związanych z danym projektem. 4. System umożliwia wysyłanie powiadomień o wybranych zdarzeniach na skrzynkę pocztową. 5. System umożliwia komunikację z innymi użytkownikami w czasie rzeczywistym za pomocą funkcji czatu. 6. Kontrolka wyboru użytkowników, używana w różnych częściach systemu, zrealizowana jest w prosty i intuicyjny sposób. 2 Analiza SWOT (ang. SWOT strengths, weaknesses, opportunities, threats) jest uniwersalnym narzędziem wykorzystywana do porządkowania informacji. Istotne informacje dotyczące analizowanego obiektu kategoryzowane są w cztery grupy: mocne strony, słabe strony, szanse i zagrożenia. Metoda stosowana jest m.in. podczas analizy projektów czy organizacji. 1źródło: marzec

48 Wady rozwiązania Nie znaleziono żadnych poważnych błędów dotyczących użyteczności systemu. Jedyne nasuwające się niedogodności wynikały z innych potrzeb badanej grupy docelowej. 1. Brak możliwości zdefiniowania daty rozpoczęcia zadania oraz daty rozpoczęcia prac nad kamieniem milowym. 2. Dostępność systemu jedynie w języku angielskim 3. Brak możliwości instalacji systemu na lokalnym serwerze firmy. B.3 Basecamp Basecamp rozwijany przez firmę 37signals jest, podobnie jak poprzednie rozwiązanie, jednym z wiodących narzędzi do współpracy on-line. Obecnie jest używany przez ponad 7 mln użytkowników na całym świecie. 1 System zapewnia bogatą funkcjonalność, w dużej części zbliżoną do tej, oferowanej przez system PBworks. Na potrzeby ewaluacji założono darmowe konto testowe. Podczas ewaluacji produktu ograniczono się do przeglądu innowacyjnych rozwiązań tego produktu, niedostępnych w dwóch poprzednich produktach. Zalety rozwiązania 1. Szablony projektów: System umożliwia tworzenie szablonów które bardzo ułatwiają pracę nad nowymi projektami. 2. Podczas tworzenia projektu system umożliwia łatwe przydzielenie dostępu do projektu dla klienta lub dla innej firmy. 3. System zapewnia użyteczne wskazówki ułatwiające nowemu użytkownikowi rozpoczęcie pracy. 4. Liczba etapów zadania ograniczona do niezbędnych dwóch: wykonana / niewykonana. 5. System delikatnie wyróżnia zadania, które są przypisane do aktualnie zalogowanego użytkownika. 6. Formularz dodawania/edycji zadania wyświetla się bezpośrednio na liście (wzorzec edycji w miejscu, str ). 1źródło: marzec

49 systemu: 1 bardzo poważny problem, C Ocena heurystyczna systemu Hinc 1.5 Niniejsza dokument zawiera kompilację raportów z oceny heurystycznej systemu Hinc. Poszczególne części dokumentu powstawały w kolejnych iteracjach pracy nad projektem. Wyjątkiem jest część pierwsza, opisująca problemy pojawiające się w różnych miejscach serwisu. Zawarte tam uwagi były zbierane podczas całego czasu trwania projektu. Znalezione problemy zostały skategoryzowane według ich wpływu na przydatność i użyteczność problem średniej wagi, drobna niedogodność. C.1 Wstępna ocena systemu 1. Spójność wizualna (a) System Hinc ewoluował przez wiele lat i poszczególne części systemu zostały zaimplementowane z wykorzystaniem różnych technologii. Najstarsze części systemu wykorzystują prosty interfejs HTML+JS, a w niektórych miejscach pojawiają się aplety Javy. Moduł planu akcji korzysta z biblioteki graficznej GWT-Ext, a moduł wskaźników z jej następcy SmartGWT. Sugestia: Cały system powinien korzystać z jednej biblioteki graficznej. Po przeanalizowaniu dostępnych rozwiązań zdecydowano się na użycie komercyjnej wersji Smart- GWT. (b) W istniejącej wersji aplikacji można było znaleźć ikony w przeróżnych odmianach i stylach. Część z nich, szczególnie w starszej części aplikacji, zachowywała surowy design i ciemno-niebieską kolorystykę. W nowszych modułach można było znaleźć ikony w bardziej radosnych odcieniach, pochodzące zazwyczaj z darmowych bibliotek, często nawiązujące stylistyką do ikon systemu Windows. Sugestia: System powinien zapewnić jednorodną ikonografię dla podstawowych akcji (tworzenie, usuwanie, aktualizacja, generowanie raportów, przyznawanie uprawnień) (c) Nawigacja i funkcjonalność podobnych opcji w różnych częściach serwisu jest realizowana na wiele sposobów. System powinien wykorzystywać ograniczoną liczbę wzorców interakcji. 2. Nawigacja (a) Aktualna struktura nawigacyjna odzwierciedla wewnętrzną architekturę aplikacji, a nie procesy poznawcze użytkownika. Sugestia: Reorganizacja głównego menu aplikacji. Ułatwienie dostępu do najczęściej używanych funkcji systemu. (b) System nie zapewnia możliwości horyzontalnego poruszania się w strukturze nawigacyjnej. 1 Notacja z czaszkami zapożyczona została z książki Jakoba Nielsena Prioritizing Web Usability 41

50 Przykład. aby przejść od planu działania do odpowiadającej mu noty korygującej należy przejść przez główne menu do modułu diagnostyka i odnaleźć notę korzystając z wyszukiwarki. Sugestia: Należy usprawnić nawigację pomiędzy poszczególnymi modułami. (c) W przypadku, gdy czas sesji upłynął system wyświetla odpowiedni komunikat. Użytkownik musi wybrać opcję wylogowania, aby zalogować się ponownie. Sugestia: Po wygaśnięciu sesji system powinien przenosić użytkownika automatycznie do strony logowania. (d) System zapisuje informacje o wszystkich ważnych akcjach wykonywanych przez użytkowników, jednak nie ma możliwości łatwego ich przeglądania. Sugestia: Należy wzbogacić system o elementy pozwalające na łatwy dostęp do historii wybranych typów obiektów. 3. Struktura informacji (a) System pozwala na kategoryzowanie informacji według hierarchii: grupa firm > firma > projekt. Hierarchia ta nie odzwierciedla rzeczywistych potrzeb użytkownika i komplikuje użytkowanie systemu. Sugestia: Należałoby zrezygnować z dwóch pierwszych poziomów i pozostawić tylko funkcjonalność projektów. 4. Tabela prezentująca listę rekordów (projektów, zasobów, użytkowników,...) (a) Pole id pokazuje identyfikator rekordu w bazie danych. Jest to wewnętrzna informacja systemu i nie powinna być prezentowana użytkownikowi. 1 (b) Przycisk Zamknij: Kliknięcie przycisku powoduje powrót do strony głównej systemu. W tym miejscu jest on zupełnie nieadekwatny i niepotrzebny. (c) Przycisk Reset pokazujący się podczas edycji formularza jest niepotrzebny i powinien być usunięty. (d) Funkcjonalność przycisków wyświetlania i edycji rekordów utrudnia wykonywanie podstawowych zadań. Sugestia: Aby usprawnić nawigację, wiersze tabeli można wyposażyć w kontekstowe przyciski pojawiające się po najechaniu kursorem na element (str. 14). 5. Komunikacja (a) W skrzynce odbiorczej znajdują się razem wiadomości od innych użytkowników, potwierdzenia dostarczenia i komunikaty generowane przez system. Poza tematem wiadomości nie ma żadnego oznaczenia kontekstu. Bardzo utrudnia to odnalezienie właściwych informacji. Sugestia: Oddzielenie wiadomości wysyłanych przez użytkowników od komunikatów generowanych przez system. 1 W rzeczywistości użytkownicy czasami wykorzystywali identyfikatory rekordów w codziennej pracy. Pozwalały im one na obejście problemów dotyczących użyteczności w przypadku, gdy system nie zapewniał odpowiedniej funkcjonalności. Numery pozwalające za zidentyfikowanie dokumentów były zapisywane na karteczkach przyklejanych do monitorów, lub były wpisywane jako komentarze tekstowe do bazy danych. Jest to doskonały przyklad na to, że obecny interfejs nie spełniał swojego zadania. 42

51 (b) Możliwości konfiguracji powiadomień wysyłanych przez system są bardzo ograniczone. Sugestia: Należy usprawnić konfigurację wysyłania wiadomości przez system. (c) System nie zapewnia możliwości wysyłania wiadomości na adres użytkownika. Jest to ważna funkcjonalność w tego typu systemach. Sugestia: Należy zapewnić integrację systemu z pocztą elektroniczną. (d) Moduł forum w systemie nie jest używany. Sugeruje się usunięcie tej funkcjonalności. C.2 Ocena modułu wskaźników Data powstania dokumentu: Lista celów 1. Po dwukrotnym kliknięciu w wartość pola tytuł, opis lub okres pojawia się pole edycji. (a) Użycie wzorca edycji w miejscu jest nieintuicyjne i niespójne. Zmiana tych wartości nie jest najczęściej wykonywaną akcją. Sugestia: Po dwukrotnym kliknięciu powinny otwierać się szczegóły wskaźnika. (b) System w żaden sposób nie sygnalizuje istnienia możliwości edycji w miejscu nieedytowalne pola id, częstotliwość i punktacja są prezentowane w ten sam sposób co edytowalne. 2. Zmiana wartości częstotliwość nie jest w ogóle możliwa. 3. Aby uzyskać dostęp do drzewa, użytkownik musi wybrać przycisk rozwijania wiersza. (a) Dostęp do drzewa wskaźników danego celu nie jest intuicyjny a przycisk rozwijania jest mało widoczny. (b) Wykorzystanie tego wzorca interakcji nie jest w tym miejscu właściwe. Przy rozdzielczości 1024x768 jedynie 25% dostępnej powierzchni ekranu jest wykorzystywane. (c) W większości przypadków pojawiają się dwa paski przewijania wertykalnego. 4. Pole id pokazuje identyfikator rekordu w bazie danych. Jest to wewnętrzna informacja systemu i nie powinna być prezentowana użytkownikowi. 5. Numerowanie wierszy tabeli jest w tym miejscu niepotrzebne. 6. Aby wygenerować raport, użytkownik musi zaznaczyć kilka wierszy (używając myszy i klawisza ctrl). Aby wydrukować całą listę, użytkownik musi zaznaczyć każdy wiersz ręcznie. Funkcjonalność tworzenia raportów nie odzwierciedla potrzeb użytkownika. 7. Funkcjonalność przycisków importu/eksportu jest bardzo niejasna. W rzeczywistości opcja ta wykorzystywana jest do tworzenia kopii celu. 8. Po najechaniu kursorem na ikonę autoryzacji, wygląd kursora nie zmienia się na wskaźnik sygnalizujący, że dostępna jest jakaś akcja. 43

52 Figure 11: Lista celów z otwartym drzewem wskaźników 9. Funkcjonalność menu kontekstowego w nagłówku jest nadmiarowa. System wykorzystuje wszystkie możliwe opcje biblioteki SmartGWT związane z nagłówkami tabeli: użytkownik może zmienić kolejność wyświetlania kolumn i ich widoczność, może zdefiniować własny porządek sortowania lub wykonać grupowanie wartości każdej z kolumn (ma to sens jedynie dla okresu). Po wykonaniu którejś z tych akcji początkujący, a nawet zaawansowani użytkownicy, mogą mieć problemy z przywróceniem domyślnego widoku aplikacji. Sugestia: należy ograniczyć funkcjonalność tabeli do niezbędnego minimum. 10. Po wygaśnięciu sesji wyświetla się odpowiedni komunikat, ale po kliknięciu OK użytkownik może w dalszym ciągu przeglądać dane. Drzewo wskaźników 11. Edycja w miejscu System umożliwia edycję niektórych wartości bezpośrednio w tabeli, po dwukrotnym kliknięciu pola. (a) Podobnie jak w przypadku listy celów, zmiana wartości nie jest najczęściej wykonywaną akcją. Rozwiązanie jest nieintuicyjne i problematyczne. (b) Podwójne kliknięcie na wartość pola punktacja powoduje otwarcie foldera (jeżeli wybrany wiersz jest folderem), albo brak akcji (jeśli wybrano liść). Zaleca się stosowanie jednorodnych konwencji. 12. Tworzenie struktury wskaźników (a) Opcja dodawania nowych węzłów drzewa ukryta jest w menu kontekstowym wyświetlanym po naciśnięciu prawego przycisku myszki. Sugestia: Należy umieścić tą funkcjonalność w bardziej widocznym miejscu. 44

53 (b) Przy podpinaniu nowych wskaźników do istniejących, zamienia się on w folder. Nie ma wyraźnego rozróżnienia pomiędzy wskaźnikami a folderami. (c) Po przekształceniu wskaźnika w folder w dalszym ciągu mamy dostęp do szczegółów takich jak formuły, pola, punktacje itp., ale informacje te nie są właściwe dla folderu i nie są wykorzystywane. (d) Usuwanie węzłów jest możliwe tylko za pomocą menu kontekstowego. 13. Ikony widoczne w górnej części ekranu odnoszą się do celu, a nie do wskaźnika, jak można by przypuszczać. Np. kliknięcie przycisku usuń spowoduje usunięcie celu wraz z całym drzewem wskaźników, a nie pojedynczego wskaźnika. 14. Po najechaniu kursorem na ikonę edycji, wygląd kursora nie zmienia się na wskaźnik sygnalizujący, że z tą ikoną związana jest jakaś akcja. 15. Podobnie jak w przypadku listy celów, mamy nadmiarową ilość zbędnych opcji związanych z nagłówkiem tabeli. Opcje wskaźnika Figure 12: Okno szczegółów wskaźnika 16. Po wybraniu opcji szczegółów wskaźnika otwiera się nowe wirtualne okno. Ten wzorzec interakcji nie jest wykorzystywany w żadnej innej części systemu. 17. System umożliwia zdefiniowanie wielu formuł dla danego wskaźnika, lecz w rzeczywistości sensowne jest wykorzystanie tylko jednej. 18. Układ kontrolek okna jest bardzo nieintuicyjny (np. przycisk zamknięcia okna znajduje się na środku ekranu). 45

54 19. Zakładka wykres wskaźnika skrywa, oprócz wykresu, także pola do wprowadzania wartości wskaźnika w poszczególnych okresach. (a) Funkcjonalność wprowadzania wartości jest najczęściej wykorzystywaną funkcjonalnością modułu wskaźników i powinna być odpowiednio wyeksponowana. (b) Użytkownik może aktualnie wprowadzić dwie wartości dla tego samego okresu, nie powinno to być dozwolone. (c) Użytkownik może wprowadzić wartości wykraczające poza zakres czasowy celu, wartości te będą brane pod uwagę podczas obliczeń powodując błędne wyniki. Nie powinno to być dozwolone. Sugestia: Po zdefiniowaniu częstotliwości pomiarów danego wskaźnika liczba pól do wypełnienia jest ściśle określona (np. w przypadku 2 zmiennych 12 miesięcy użytkownik powinien wprowadzić 24 wartości). Można poprawić użyteczność systemu generując odpowiednie pola, zamiast wymagać, aby użytkownik je za każdym razem wprowadzał. C.3 Ocena modułu plan działania Data powstania dokumentu: Architektura informacji i notacja graficzna 1. Etap/stan: System pozwala na wybranie jednego z siedmiu stanów akcji: planowana, zaplanowana, wykonywana, oczekująca, odwołana, zakończona, zatrzymana (pt. planejando, planejado, executando, pendente, cancelado, finalizado, parado). (a) System pozwala tylko na niektóre przejścia pomiędzy stanami. Bardzo utrudnia to wykonywanie prostych zadań. (b) Każdy z siedmiu stanów akcji jest oznaczany innym kolorem. Rozwiązanie to jest uzasadnione, jednak dobór kolorów i sposób prezentacji informacji pozostawia wiele do życzenia. Sugestia: Należy zredukować liczbę dostępnych stanów do trzech: planowana, wykonywana, zakończona (pt. planejado, executando, finalizado) Sugestia: Należy umożliwić zmianę stanu bez otwierania okna szczegółów akcji. 2. Status: System wyświetla dwa rodzaje ikon informujących o statusie planu i poszczególnych akcji: zielony ptaszek gdy termin zadania nie został przekroczony oraz czerwony wykrzyknik gdy termin upłynął, a stan wskazuje na to, że zadanie nie zostało wykonane. (a) Znaczenie ikon nie jest jasne przy pierwszym kontakcie z systemem. (b) Umieszczanie ikon przy każdej akcji utrudnia odnalezienie kluczowych informacji i powoduje u użytkownika niepotrzebne obciążenie poznawcze. Sugestia: należy wyświetlać czytelne informacje o statusie tylko wtedy gdy istnieje taka potrzeba - np. termin wykonania zadania upłynął lub upływa dzisiaj. 46

55 3. Priorytet: System wyświetla informacje o priorytecie zadań w postaci gwiazdek o trzech kolorach (niski priorytet zielony, średni żółty, wysoki czerwony). (a) W tym przypadku ikonografia wydaje się być odpowiednia, jednak należy się zastanowić nad sensownością istnienia priorytetu niskiego (w bazie firmy NPU jedynie 3% akcji jest ma ten priorytet). Sugestia: Ikony priorytetu akcji powinny się pokazywać w jednej kolumnie. 4. Kamień milowy: po oznaczeniu akcji jako kamień milowy (ang. milestone, pt. marco) pojawia się obok niej zielonkawa flaga. Symbolika i kolorystyka nie jest czytelna, a sama funkcjonalność tej opcji jest mało przydatna (zaledwie 50 spośród akcji w bazie firmy) [UH6] 5. Słownictwo. Nazwy funkcji i kategorii odpowiadają zazwyczaj ich funkcjonalności, lecz nie odzwierciedlają rzeczywistego słownictwa używanemu przez pracowników. Plan działania (pt. plano de açăo) jest dość abstrakcyjnym tworem i nie odzwierciedla rzeczywistych procesów w firmie. Akcja (pt. açăo) pojęcie o dość dużym stopniu abstrakcji. Bardziej odpowiednie byłoby użycie pojęcia zadanie (pt. tarefa) Zasób ludzki (pt. recurso humano). Możliwość przypisania zasobów ludzkich do wybranej akcji wydaje się poprawna semantycznie, jednak bardziej naturalne jest przydzielenie osób do zadania. Lista planów działania 6. Formularz wyszukiwania (a) Pierwszą rzeczą, jaką użytkownik widzi po wejściu do modułu jest wielki formularz zaawansowanego wyszukiwania. Przeanalizowanie go powoduje duże obciążenie poznawcze, a testy użyteczności pokazały, że jego funkcjonalność rzadko kiedy jest wykorzystywana przez użytkowników. [UH:07,08] Sugestia: zmienić domyślny widok modułu, przenieść formularz wyszukiwania w inne miejsce 7. Tabela z listą planów jest nieczytelna (a) Nazwa: Najważniejszą informacją w tabeli jest nazwa planu działania. Aktualnie system pokazuje jedynie pierwszych 10 znaków nazwy (pełna nazwa jest widoczna jako tooltip, po najechaniu kursorem na komórkę tabeli) Sugestia: należy pokazywać pełną nazwę planu, odpowiednio wyróżnioną (np. przez pogrubienie) (b) Nazwa projektu: aktualnie widocznych jest pierwszych 5 znaków. To zdecydowanie za mało, informacje są nieczytelne. Sugestia: należy pokazywać pełną nazwę projektu. (c) ID: pole prezentuje identyfikator planu w bazie danych. Jest to wewnętrzna informacja systemu i nie powinna być prezentowana użytkownikowi. 47

56 Figure 13: Lista planów działania - pierwszy ekran (d) Pozostałe pola: status, data rozpoczęcia i zakończenia, priorytet, osoba odpowiedzialna. Te informacje mają mniejszą wartość informacyjną. Należy zastanowić się, czy są one potrzebne w tym miejscu interfejsu. (e) Tabela nie ma domyślnego porządku sortowania i elementy pokazują się losowo. Pierwszą akcją wykonywaną przez większość użytkowników jest kliknięcie w nagłówek i posortowanie listy według pola ID. W rzeczywistości pożądanym porządkiem sortowania jest sortowanie według daty. 8. Przyciski pod tabelą (a) Niektóre przyciski wymagają wcześniejszego zaznaczenia planu na liście powyżej, inne zaś nie. Funkcjonalności nie jest intuicyjna, użytkownicy muszą nauczyć się wykorzystywać opcje systemu [UH 09] (b) Nowy: Tworzenie nowego planu działania jest jedną z kluczowych akcji, należy odpowiednio wyróżnić ten przycisk, być może przenieść go na początek listy. (c) Edycja: Jest to podstawowa akcja wykonywana przez użytkowników. Otwarcie planu wymaga wybrania elementu z listy i kliknięcia tego przycisku. Sugestia: Użytkownicy powinni mieć możliwość otwarcia planu działania poprzez pojedyncze kliknięcie na nazwie planu. [FITT] (d) Usunięcie, uprawnienia: Te przyciski wymagają wybrania elementu z listy. Sensownym rozwiązaniem byłoby umieszczanie kontekstowej grupy przycisków przy każdym rekordzie listy i wyświetlanie jej tylko wtedy, gdy kursor znajduje się nad tym rekordem. 48

57 Figure 14: Szczegóły planu działania (e) Wydruk: Wbrew oczekiwaniom wybranie elementu z listy i kliknięcie tego przycisku nie spowoduje przejścia do ekranu drukowania. Zamiast tego zostanie nam ponownie pokazane okno wyszukiwania i dopiero po ponownym odnalezieniu elementu będziemy w stanie go wydrukować. Sugestia: Umieszczenie polecenia wydruku wraz z opcjami kontekstowymi. (f) Import, Eksport: Funkcjonalność tych przycisków pozwala na stworzenie kopii wybranego planu zadań lub utworzenie szablonu, który będzie wykorzystywany do tworzenia kolejnych planów (podobnie jak w przypadku modułu wskaźników REF). Nazwy akcji (import/eksport) nie oddają rzeczywistej funkcjonalności, są one prawdopodobnie zaszłością z wcześniejszych wersji systemu, kiedy istniała opcja importu/eksportu danych do formatu MS Project. Sugestia: Należy przeanalizować sposób korzystania przez użytkowników z tych akcji i zapewnić podobną funkcjonalność za pomocą bardziej czytelnego systemu szablonów. (g) Zamknięcie: Kliknięcie przycisku powoduje powrót do strony głównej systemu. W tym miejscu jest on zupełnie nieadekwatny i niepotrzebny. Szczegóły planu działania 9. Formularz pozwalający na edycję podstawowych danych jest istotny w momencie tworzenia nowego planu, jednak później rzadko kiedy zachodzi potrzeba zmiany tych danych. Użytkownicy zapoznani z systemem często używają przycisku ukrywania sekcji szczegółów umieszczonego po prawej stronie nagłówka, aby zwiększyć dostępny obszar roboczy. Sugestia: Formularz edycji szczegółów nie powinien pokazywać się po otwarciu akcji. Powinien być dostępny jako opcja. 49

58 Figure 15: Szczegóły akcji monitoring 10. Automatyczne wysyłanie wiadomości: System pozwala na zaznaczenie opcji automatycznego wysyłania wiadomości do osoby odpowiedzialnej. Użytkownik nie jest informowany jakie informacje i kiedy będą wysyłane. W przypadku zaznaczenia tej opcji osoba odpowiedzialna będzie otrzymywać wiadomości o każdej zmianie stanu jakiejkolwiek akcji w tym planie. Przy aktualnym zastosowaniu systemu opcja ta rzadko jest wykorzystywana, gdyż powoduje zasypywanie użytkownika ogromną ilością informacji. Sugestia: Należy przemyśleć system informowania użytkowników o zdarzeniach. Należy uwzględnić propozycję oddzielenia wiadomości od użytkowników od powiadomień generowanych przez system. 11. Drzewo akcji (a) Przy otwarciu planu pokazywany jest tylko korzeń drzewa aby obejrzeć szczegóły trzeba użyć przycisków rozwijania drzewa. Sugestia: Należy zmienić tą funkcjonalność i domyślnie pokazywać użytkownikowi większą ilość informacji. (b) Opcja dodawania nowych akcji ukryta jest w menu kontekstowym wyświetlanym po naciśnięciu prawego przycisku myszki. Sugestia: Należy umieścić tą funkcjonalność w bardziej widocznym miejscu (c) Tworzenie struktury akcji nie jest intuicyjne. Przy dodawaniu nowych zadań do istniejącej akcji zamienia się ona w grupę akcji i tracimy część zawartych w niej informacji. Nie ma wyraźnego rozrożnienia pomiędzy akcjami a grupami akcji (folderami). Sugestia: Należy przeanalizować sposób grupowania akcji i zaprojektować bardziej intuicyjne rozwiązanie. 50