Politechnika Gdańska WYDZIAŁ ELEKTRONIKI TELEKOMUNIKACJI I INFORMATYKI Katedra Inżynierii Wiedzy Imię i nazwisko dyplomanta: Ewa Gorajewska Nr albumu: 84989 Rodzaj studiów: magisterskie Kierunek studiów: Informatyka Praca magisterska Temat pracy: Opracowanie narzędzia wspomagającego projektowanie interfejsu. Kierujący pracą: dr inż. Jan Daciuk Zakres pracy: Projektowanie interfejsu użytkownika wymaga stosowania różnych technik wspomagających ten proces. Jedną z nich jest metoda GOMS polegająca na budowaniu modelu zadania i wyznaczaniu parametrów związanych z jego wykonaniem. Projekt ma na celu realizację metody GOMS w środowisku KDE. Umożliwia ocenę interfejsu programów pisanych przy użyciu KDevelop. Przeprowadzenie analizy GOMS obejmuje modyfikację KDevelop oraz opracowanie narzędzia, które utworzy model zadania. Gdańsk, 2005
2 Pragnę serdecznie podziękować Panu dr inż. Janowi Daciukowi, opiekunowi mojej pracy, za poświęcony mi czas, cierpliwość oraz wiele cennych rad i sugestii.
Spis treści WYKAZ RYSUNKÓW... 5 WYKAZ TABEL... 7 WSTĘP... 8 1. Wprowadzenie do Dialogu Człowieka z Komputerem... 9 1.1. Projektowanie interfejsu użytkownika. Wymagania i znaczenie... 10 1.2. Podstawowe zagadnienia Dialogu Człowieka z komputerem... 16 2. Podstawy modelowania GOMS oraz GOMSL... 20 2.1. Analiza zadań za pomocą metody GOMS... 20 2.2. Model KLM... 21 2.3. Język GOMSL... 24 2.4. Algorytm konstrukcji modelu GOMSL... 32 2.5. Edycja dokumentu jako przykład modelu GOMSL... 33 2.6. Szacowanie czasu nauki... 38 2.7. Szacowanie czasu wykonywania zadania... 41 3. Podstawowe informacje oraz modyfikacja narzędzia KDevelop... 44 3.1. Struktura projektu rozwijanego w KDevelop... 46 3.2. Zakres zmian w KDevelop... 48 3.3. Szablony projektów... 49 3.4. Rozbudowa szablonu khello... 51 3.5. Obiekty i obsługa zdarzeń w bibliotece Qt... 52 3.6. Działanie funkcji eventfilter()... 54 3.7. Najważniejsze informacje o pliku zdarzeń... 55 3.8. Wprowadzenie zmian do systemu... 57 4. Realizacja narzędzia GAnalyser... 58 4.1. Definiowanie prymitywnych operatorów GOMSL... 58 4.2. Prawo Fitta... 62 4.3. Problemy związane z biblioteką Qt... 65 4.4. Drzewa przyrostków... 71 4.5. Definiowanie procedur... 76 4.6. Wyznaczanie czasu nauki i wykonywania zadania... 79 5. Testowanie programu GAnalyser... 81 5.1. Zbiór testowy... 81 5.2. Wyniki... 84 5.3. Wnioski... 108 6. Podsumowanie... 110 3
7. Instrukcje dla użytkownika... 112 7.1. Instalacja programu GAnalyser... 112 7.2. Przygotowanie danych do analizy GOMSL... 113 7.3. Wykonanie analizy GOMSL i interpretacja wyników... 114 BIBLIOGRAFIA... 116 ZAŁĄCZNIK PŁYTA CD 4
Wykaz rysunków Rysunek 1.1.1. Oryginalny interfejs FCU (Airbus A320). Źródło: Supporting Strategic Knowledge Structures to Enhance Cockpit Safety. 12 Rysunek 1.1.2. Procedura wprowadzania parametrów lotu (Airbus A320)... 12 Rysunek 1.1.3. Schemat zmodyfikowanego interfejsu FCU. Źródło: Supporting Strategic Knowledge Structures to Enhance Cockpit Safety. 13 Rysunek 1.1.4. Liczba błędów spowodowanych wyborem niewłaściwego trybu prędkości lotu... 14 Rysunek 1.1.5. Łączna liczba popełnionych błędów... 14 Rysunek 1.1.6.a Interfejs radia (Porsche 1996 r). Źródło: Interaction Design for Automobile Interiors. 15 Rysunek 1.1.6.b Interfejs radia (Porsche 1996 r). Źródło: Interaction Design for Automobile Interiors. 15 Rysunek 2.3.1. Symulacja użytkownika w środowisku GLEAN3... 26 Rysunek 3.1.a Logo KDE... 45 Rysunek 3.1.b Logo Kdevelop... 45 Rysunek 3.1.c Logo Qt... 45 Rysunek 4.2.1. Podstawowe pojęcia związane z prawem Fitta... 63 Rysunek 4.2.2. Pomiar odległości dla operatora Point_to... 64 Rysunek 4.3.1. Przykładowy interfejs programu... 67 Rysunek 4.3.2 Drzewo reprezentujące interfejs programu... 68 Rysunek 4.3.3. Interfejs zbudowany z obiektu QTable... 69 Rysunek 4.4.1.a Drzewo przyrostków jawne... 73 Rysunek 4.4.1.b Drzewo przyrostków niejawne... 73 Rysunek 4.4.2. Drzewo przyrostków z etykietami krawędzi... 74 Rysunek 4.4.3. Drzewo przedrostków z zaznaczonymi dowiązaniami... 75 Rysunek 5.1.1. Interfejs programu EuroCalc... 82 Rysunek 5.1.2. Interfejs programu Scribble.... 82 Rysunek 5.1.3. Okno dialogowe Select Color. 82 Rysunek 5.1.4. Interfejs programu TextEdit... 83 Rysunek 5.1.5. Interfejs programu TicTacToe.... 83 Rysunek 5.2.1.a Interfejs programu EuroCalc kolejne etapy realizacji zadania 1... 85 Rysunek 5.2.1.b Interfejs programu EuroCalc kolejne etapy realizacji Rysunek 5.2.1.c zadania 1... 85 Interfejs programu EuroCalc kolejne etapy realizacji zadania 1... 85 Rysunek 5.2.2. Okno programu Scribble po wykonaniu Zadania 1... 90 Rysunek 5.2.3. Okno programu Scribble po wykonaniu Zadania 2... 93 5
Rysunek 5.2.4. Okno programu TextEdit po wpisaniu tekstu... 96 Rysunek 5.2.5. Wyniki gry w kółko i krzyżyk... 104 Rysunek 5.2.6.a Interfejs programu Wizard podczas realizacji Zadania 1... 106 Rysunek 5.2.6.b Interfejs programu Wizard podczas realizacji Zadania 1... 106 Rysunek 5.2.6.c Interfejs programu Wizard podczas realizacji Zadania 1... 106 6
Wykaz tabel Tabela 2.2.1. Operatory KLM... 21 Tabela 2.2.2. Czas wykonywania operatorów KLM... 23 Tabela 2.6.1. Liczba jednostek uczenia w modelu zadania opisującego edycję dokumentu... 40 Tabela 2.7.1. Czasy wykonania procedur modelu opisującego edycję dokumentu... 42 Tabela 3.1. Wymagania KDevelop... 45 Tabela 4.1.1. Przechwytywane typy zdarzeń i definiowane na ich podstawie operatory prymitywne... 59 Tabela 4.1.2. Wygenerowane zdarzenia i zdefiniowane na ich podstawie operatory GOMSL... 62 Tabela 4.4.1. Przykład konstrukcji drzewa przyrostków... 73 7
Wstęp Jednym z kierunków rozwoju współczesnej informatyki jest doskonalenie technologii dialogu człowieka z komputerem. Dziedzina ta już od kilkudziesięciu lat jest przedmiotem intensywnych badań i poszukiwań. W tym czasie naukowcy odnieśli wiele sukcesów oraz wywarli znaczny wpływ na postęp informatyki. W swej pracy często opierali się na badaniach z zakresu psychologii, dogłębnie analizowali zachowanie i sposób myślenia człowieka. Do ich osiągnięć należy zaliczyć obecnie stosowany styl prezentacji graficznego interfejsu użytkownika. Zaproponowane podejście zyskało duże uznanie oraz przyczyniło się do szerokiej popularyzacji komputerów we wszystkich dziedzinach życia i nauki. Wraz z rozwojem oprogramowania coraz większą uwagę zwraca się na pracę inżynierów projektantów. Optymalizacja interfejsu, stworzenie łatwego i intuicyjnego modelu interakcji z użytkownikiem, ma w wielu przypadkach priorytetowe znaczenie. Projektując system sterujący przejazdami pociągów, lotami czy pracą elektrowni, należy wyeliminować każdy czynnik wprowadzający użytkownika w błąd lub stwarzający sytuację nieporozumienia. Jak pokazuje doświadczenie, nawet prosta korekta interfejsu pozwala ograniczyć liczbę błędów ludzkich oraz uniknąć wielu wypadków. Ogromne znaczenie prowadzonych badań doceniają również producenci oprogramowania użytkowego. Można założyć, że wiele obecnych na rynku programów różni się nieznacznie pod względem funkcjonalności, niezawodności czy bezpieczeństwa. O sukcesie produktu decyduje wówczas bardziej przyjazny i atrakcyjny interfejs. Wyniki badań nad technikami dialogu człowieka z komputerem znalazły liczne zastosowania. Nie oznacza to jednak, że wszystko zostało już odkryte i opisane. Przed naukowcami ciągle pojawiają się nowe wyzwania. Wiele interesujących pomysłów nie zostało jeszcze zrealizowanych. Na pewno można dziś stwierdzić, że dziedzina ta będzie w przyszłości równie intensywnie rozwijana, a jej osiągnięcia równie spektakularne. 8
Rozdział 1 Wprowadzenie do Dialogu Człowieka z Komputerem Rozdział ten ma na celu przedstawienie i wyjaśnienie podstawowych zagadnień dotyczących Dialogu Człowieka z Komputerem. Na początku zdefiniowane zostało pojęcie interfejsu użytkownika. Część 1.1 zawiera opis badań oraz rzeczywistych wydarzeń świadczących o dużym znaczeniu procesu projektowania interfejsu. Część 1.2 prezentuje podstawowe założenia Dialogu Człowieka z Komputerem, historię powstania i rozwoju nauki. Wymienia także inne dziedziny, które wpłynęły na ten rozwój, ze szczególnym uwzględnieniem nauki o poznaniu. Rozdział oparty jest na publikacjach Formal Modelling Techniques in Human Computer Interaction (G. de Haan, G.C. van der Veer, J.C. van Vliet), The Evolution of Human Computer Interaction (John M. Carroll) a także Beyond Mode Error: Supporting Strategic Knowledge Structures to Enhance Cockpit Safety (R. Hourizi, P.Johnson). Opisane przykłady pochodzą ze stron internetowych poświęconych projektowaniu interfejsów: http://www.useit.com oraz http://www.jnd.org. *** Na co dzień spotykamy się z różnymi typami interfejsów. Najprostszym przykładem może być etykieta umieszczona na przedmiocie, zawierająca informacje dotyczące jego wykorzystania. Każde urządzenie telefon, zegarek czy też kuchenka mikrofalowa, wyposażone jest w odpowiedni interfejs użytkownika. Interfejsy mogą występować w wielu formach oraz posiadać różną złożoność. Z tego też powodu trudno jest wskazać w miarę precyzyjną definicję, która jednocześnie objęłaby wszystkie zastosowania. W pewnym sensie jest to układ pośredniczący, umożliwiający kontrolę bądź też wymianę informacji z narzędziem, urządzeniem lub systemem. W odniesieniu do programów komputerowych, interfejsem użytkownika nazywamy część oprogramowania, która odpowiada za komunikację pomiędzy użytkownikiem i resztą systemu. Pozwala także nadzorować stan tego systemu. Interfejs może charakteryzować się różnym stopniem skomplikowania. Im bardziej jest złożony, tym większe znaczenie ma proces projektowania i optymalizacji do potrzeb użytkownika. Ten bowiem przyzwyczaił się do faktu, iż dostarczany mu produkt musi spełniać wysokie wymagania, tak aby posługiwanie się nim wymagało minimum wysiłku, 9
a nawet sprawiało przyjemność. Interfejs powinien być jasny, czytelny, łatwy do nauki, funkcjonalny, estetyczny itd. Oczekiwania użytkowników ciągle rosną. Mówiąc o jakości interfejsów często stosuje się pojęcie użyteczności. Dokładniej termin ten oznacza stopień, w jakim interfejs użytkownika umożliwia korzystanie z systemu w sposób efektywny, wydajny oraz satysfakcjonujący. O użyteczności mówimy także w odniesieniu do procesu projektowania interfejsu, mając na myśli zaangażowanie ludzi i środków w celu poprawy jego jakości. 1.1. Projektowanie interfejsu użytkownika. Wymagania i znaczenie Panuje powszechna zgoda, co do faktu, że interfejs powinien być dostosowany do potrzeb użytkownika. Zaprojektowanie dobrego interfejsu ma obecnie priorytetowe znaczenie w cyklu wytwarzania produktu i decyduje o sukcesie przedsięwzięcia. Ktoś mógłby jednak pomyśleć, że przyjazny interfejs to tylko kwestia zadowolenia użytkownika, które ma drugorzędne znaczenie w porównaniu z takimi wymogami jak niezawodność lub bezpieczeństwo. W konsekwencji projektowanie interfejsu nie powinno pochłaniać zbyt wiele czasu i środków przeznaczonych na realizację projektu. Jest to jednak mylne wyobrażenie. O tym jak ważny problem stanowi optymalizacja interfejsu użytkownika pokazuje praktyka, a przykłady z życia są na to najlepszym dowodem. Jakob Nielsen zajmował się problematyką projektowana interfejsów oraz znaczeniem tego zagadnienia w codziennym życiu. W roku 2001 nadzorował badania, podczas których dokonano analizy użyteczności interfejsów w sieciach Internet oraz intranet. Testy objęły kraje Ameryki Północnej, Europy oraz Azji. Pierwsza część badań dotyczyła handlu elektronicznego. Wyodrębniono dwadzieścia, głównie dużych witryn, należących do firm z USA. Następnie ochotnicy wykonali 496 prób realizacji określonych zadań na tych stronach. Współczynnik powodzenia zadania wyniósł 56%. Firmy straciły prawie połowę z potencjalnych zysków, gdyż użytkownicy nie potrafili zrealizować swoich celów. Typową reakcją internauty, po pojawieniu się problemu na stronie internetowej, jest jej opuszczenie. Dzieje się tak, gdy nie jest jasno pokazane, co strona oferuje, gdy umieszczone informacje są trudne do przeczytania i nie odpowiadają na podstawowe pytania użytkownika, bądź też gdy użytkownik zgubi się. Poprawa jakości obsługi klienta, zwiększyłaby ilość zrealizowanych operacji do prawie 80%. Natomiast osiągnięcie takiego poziomu nie tylko znacząco zwiększyłoby zyski, ale także uchroniłoby wiele firm internetowych od upadku. Wyniki przeprowadzonych doświadczeń były jeszcze gorsze w krajach spoza Stanów Zjednoczonych. Realizacja typowych zadań, na tych samych stronach internetowych, okazała się trudniejsza dla użytkowników z Europy i Azji, co oznacza, że wzrost sprzedaży w tych krajach byłby jeszcze większy niż w USA, gdyby dostosowano je do wymagań zagranicznych klientów. Mimo, iż handel elektroniczny jest obecnie dziedziną dynamicznie rozwijającą się, i jego pozycja jest raczej niezagrożona, przeprowadzone badania pokazują, że ciągle istnieje duży potencjał w zakresie 10
zwiększenia sprzedaży, a kluczem do tego celu jest poprawa użyteczności stron internetowych. Druga część badań dotyczyła sieci intranet. Użyteczność intranetu należy rozpatrywać w kontekście produktywności pracowników. Czas, jaki spędzają oni błądząc w sieci lub próbując rozwikłać niezrozumiałe instrukcje, oznacza dla firmy straty w wysokości pensji wypłacanych pracownikom za wykonywanie niewłaściwych zadań. W badaniach wzięły udział osoby zatrudnione w czternastu przedsiębiorstwach (dziesięciu z USA, trzech z Europy oraz jednego z Azji). Użyteczność sieci intranet w poszczególnych przedsiębiorstwach była dosyć zróżnicowana. Ochotnikom polecono wykonanie szesnastu typowych zadań. Koszt realizacji zadań oszacowano na podstawie wydatków związanych z wypłatami dla pracownikowi (za czas poświęcony na wykonanie zadań). Wyniki były następujące: przedsiębiorstwo, w którym użyteczność sieci intranet oceniono jako niską, musiało zapłacić swojemu pracownikowi średnio 3042$. Dla przedsiębiorstwa o średniej użyteczności, był to wydatek rzędu 2069$, podczas gdy dla przedsiębiorstwa o najwyższym poziomie użyteczności, nawet 1563$. Mnożąc powyższe dane przez liczbę pracowników, otrzymamy całkowite koszty związane z pracą w intranecie. Dla firmy zatrudniającej 10,000 pracowników będzie to: niska użyteczność sieci: 30,2 mln $ średnia użyteczność sieci: 20,7 mln $ wysoka użyteczność sieci: 15,6 mln $ Wyraźną różnicę widać przede wszystkim między przedsiębiorstwami pierwszej i drugiej kategorii. Kontynuując powyższy przykład, zwiększenie użyteczności intranetu w przedsiębiorstwie zatrudniającym 10,000 osób, wymaga nakładów w wysokości około 500000$. Natomiast zwrot z inwestycji będzie dziesięcio, a nawet dwudziestokrotny, w zależności od tego, czy nastąpiło podniesienie użyteczności do poziomu wysokiego, czy też średniego. Oznacza to, że średniej wielkości przedsiębiorstwo mogłoby zaoszczędzić nawet 5 mln dolarów rocznie, poprzez poprawę użyteczności sieci intranet i zwiększenie produktywności swoich pracowników. Wyniki przeprowadzonych badań pokazują jak duże znaczenie ma opracowanie odpowiedniego interfejsu użytkownika. Ustalono, że proces projektowania interfejsu powinien pochłaniać ok. 10% budżetu przeznaczonego na realizację projektu. Jednak wydatek ten zwraca się później wielokrotnie. Znaczne ograniczenie kosztów związanych z użytkowaniem systemu to argument, który przemawia do wszystkich kierowników. Jednak pieniądze nie są najważniejszym powodem, dla którego warto inwestować w poprawę użyteczności. Znacznie cenniejsze jest ludzkie życie, a jak pokazuje doświadczenie, niskiej jakości interfejs może stać się śmiertelnym zagrożeniem. Bezpieczeństwo jest niezmiernie ważnym zagadnieniem w lotnictwie, a jego zapewnienie pochłania wiele czasu i wysiłku. W tym celu stworzono obszerny system rejestracji wypadków, również tych spowodowanych niewłaściwą obsługą interfejsu. Jednym z dobrze udokumentowanych przykładów jest katastrofa lotnicza, która wydarzyła się w styczniu 1992 roku. Samolot pasażerski Airbus A320, odbywający krótką podróż z Lyonu do Strasbourga, rozbił się we wschodniej Francji. Ocalało zaledwie sześciu pasażerów. 11
Zginęła również cała załoga. Po odtworzeniu nagrania z kabiny pilota okazało się, że załoga przez długi czas była nieświadoma istniejącego zagrożenia. Nie stwierdzono żadnych oznak paniki, aż do momentu usłyszenia alarmu 200 stóp nad powierzchnią ziemi. Wówczas było już za późno, aby uniknąć rozbicia. W przeprowadzonym dochodzeniu nie wykryto mechanicznych usterek, które mogłyby spowodować wypadek, nie stwierdzono także zaniedbania ze strony załogi. W trakcie dalszych badań ustalono, że podstawowym czynnikiem prowadzącym do katastrofy, był źle zaprojektowany układ sterujący autopilota (Rysunek 1.1.1). Rysunek 1.1.1. Oryginalny interfejs FCU (Airbus A320). Źródło: Supporting Strategic Knowledge Structures to Enhance Cockpit Safety. Rysunek 1.1.2. Procedura wprowadzania parametrów lotu (Airbus A320). Jednostka sterująca lotem (FCU) zbudowana jest z kilku przełączników, umożliwiających wprowadzanie danych w różnych postaciach. Przykładowo prędkość lotu może być wyrażona w stopach na minutę lub w machach (w odniesieniu do prędkości rozchodzenia się dźwięku w powietrzu). Dozwolone jest także stosowanie kombinacji parametrów, np. zejście na wysokość 15,000 stóp z prędkością 400 stóp na minutę. Ostatnim krokiem jest wybór autopilota, który realizuje wprowadzone instrukcje. Służy do tego sześć przycisków umieszczonych na dole FCU. Wciśnięcie pierwszego przycisku oznacza uruchomienie Autopilota 1, po odczekaniu czterosekundowego opóźnienia. 12
Procedura realizacji zadania, polegającego na wprowadzenia parametrów lotu, przedstawiona jest na Rysunku 1.1.2. Nie jest to skomplikowana procedura, jej wykonanie nie powinno sprawić większych problemów. Jednak w chwili wystąpienia błędu zarówno pierwszy jak i drugi pilot pochłonięci byli dodatkowymi zadaniami. Za pierwszym razem nie otrzymali zezwolenia na lądowanie i przygotowywali się do drugiego podejścia. W tym celu należało wykonać min. korektę kursu, wypuścić podwozie oraz wprowadzić odpowiedni współczynnik schodzenia. Prędkość schodzenia podawana jest w jednym z dwóch trybów, w zależności od ustawienia wskaźnika VS/FPA. Pilot wprowadził dane, które miały oznaczać zejście z prędkością 3300 stóp na minutę, z tym, że wskaźnik znajdował się w niewłaściwym ustawieniu i pożądaną wartością był kąt schodzenia 3,3 stopni. Błąd ten spowodował nagły spadek samolotu. W tym momencie pojawił się jeszcze drugi błąd żaden z pilotów nie zauważył gwałtownego zejścia, aż do chwili, gdy zderzenie było nieuniknione. Innymi słowy byli oni zaskoczeni stanem systemu. Ustalenie przyczyny wypadku zapoczątkowało dalsze badania zmierzające do jej wyeliminowania. Wykorzystując różne metody analizy oraz kierując się podstawowymi wytycznymi dotyczącymi projektowania interfejsów, opracowano nowy układ FCU (Rysunek 1.1.3). Najistotniejsze zastosowane modyfikacje to: wprowadzanie parametrów lotu rozpoczyna się po lewej stronie interfejsu, kończy zaś po prawej; opcje dotyczące każdego parametru zostały zgrupowane w kolumnach; po wprowadzeniu instrukcji następuje jej powtórzenie przez autopilota; wprowadzono kontrolę danych wewnątrz systemu; na zakończenie pilot potwierdza poprawność podanych parametrów. Rysunek 1.1.3. Schemat zmodyfikowanego interfejsu FCU. Źródło: Supporting Strategic Knowledge Structures to Enhance Cockpit Safety. Ostatni etap prac polegał na wykonaniu testów użyteczności nowego interfejsu. W tym celu wybrano dziesięć osób, które następnie podzielono na dwie grupy i przeszkolono w zakresie obsługi odpowiednio oryginalnego i zmodyfikowanego interfejsu. Właściwy etap testu polegał na symulacji zadań wprowadzania parametrów lotu. W tym czasie użytkownicy byli obserwowani, a ich kolejne kroki rejestrowane. Dzięki temu, w przypadku niepowodzenia, można było ustalić sekwencję akcji prowadzących do błędu. Zmierzono także czas potrzebny na wykonanie każdego zadania. W pierwszej kolejności przetestowano interfejsy pod kątem wyeliminowania błędu, który spowodował opisaną 13
katastrofę. Wyniki były bardzo optymistyczne. W grupie obsługującej oryginalny interfejs, 40% badanych popełniło ten sam błąd, co piloci Airbusa, podczas gdy w drugiej grupie nie zanotowano ani jednej takiej pomyłki (Rysunek 1.1.4). pomyłka związana z trybem wprowadzania prędkości lotu błąd % 50% 40% 30% 20% 10% 0% oryginalny interfejs zmodyfikow any interfejs Rysunek 1.1.4. Liczba błędów spowodowanych wyborem niewłaściwego trybu prędkości lotu. Podsumowano także liczbę wszystkich popełnionych błędów (Rysunek 1.1.5). łączna ilość błędów 40% błąd % 30% 20% 10% 0% oryginalny interfejs zmodyfikow any interfejs Rysunek 1.1.5. Łączna liczba popełnionych błędów. Katastrofa Airbusa z 1992 roku stanowi niezbity dowód, że użyteczność może być kwestią bezpieczeństwa człowieka. Lotnictwo nie jest jedyną dziedziną, w której niskiej jakości interfejs może doprowadzić do zagrożenia ludzkiego zdrowia i życia. Innym przykładem jest medycyna. Śmiertelne pomyłki lekarzy i pielęgniarek opisywane są w licznych publikacjach na łamach medycznych czasopism bądź też w Internecie. Błędy związane z obsługą aparatury medycznej są przyczyną tak groźnych wypadków jak poparzenia w trakcie naświetlania lub zaaplikowanie pacjentowi podwójnej dawki leku. Dużo zarzutów kierowanych jest pod kątem wykorzystywanych przez szpitale systemów ewidencji pacjentów. Okazuje się, że pomyłki w trakcie wprowadzania danych o pacjentach i ich leczeniu, są najczęściej występującym typem błędu oraz doprowadziły do wielu niebezpiecznych sytuacji. Dlatego dużą uwagę przywiązuje się do zapewnienia wysokiej użyteczność tych systemów. Wszystkie wypadki spowodowane niskiej jakości 14
interfejsem są wnikliwie analizowane i dobrze dokumentowane, w celu uniknięcia ich powtórzenia w przyszłości. Ignorowanie zaleceń odnośnie jakości interfejsu użytkownika stało się w ostatnich latach powodem ostrej krytyki, jaka spotkała przemysł samochodowy. W celu poprawy komfortu kierowcy i pasażerów współczesne samochody oferują wyposażenie w postaci wysokiej jakości systemów audio, TV, telefonów komórkowych, systemów nawigacji satelitarnej itd. W konsekwencji znacznie wzrosła ilość wyświetlaczy oraz układów sterujących we wnętrzu auta. Wszystkie te urządzenia dodatkowo pochłaniają uwagę kierowcy w czasie jazdy. Dlatego też zaprojektowanie przyjaznego interfejsu ma priorytetowe znaczenie dla zachowania bezpieczeństwa. Wielu producentów zdaje się jednak nie dostrzegać istniejącego problemu. Wśród tych najsilniej krytykowanych znalazły się takie marki jak BMW, Volkswagen czy też Porsche. Ten ostatni min. za sprawą radia, które pojawiło się w standardowym wyposażeniu modelu z roku 1996 (Rysunek 1.1.6). Dziesięć identycznych przycisków służących do wyboru stacji umieszczono w jednym rzędzie poniżej wyświetlacza. Jeśli jadący z dużą prędkością kierowca zechce wybrać stację numer sześć, ta prosta czynność może okazać się dużym zagrożeniem. Problem stanowi również wyświetlacz: zły kontrast, mała czcionka, etykiety umieszczone niedokładnie nad przyciskami, które opisują. Okazuje się, że włączenie odtwarzacza CD lub ustawienie poziomu głośności wymaga pochylenia się nad radiem, co z kolei może doprowadzić do wypadku. a) b) Rysunek 1.1.6. a,b Interfejs radia (Porsche 1996 r). Źródło: Interaction Design for Automobile Interiors, http://www.jnd.org. Innym błędem projektowym, często powtarzanym przez producentów samochodów, jest złożona struktura menu. W ulotkach sprzedaży można znaleźć informacje typu przyjazny interfejs użytkownika oferuje szybki dostęp do 700 ustawień. Zgromadzenie siedmiuset opcji w jednym układzie kontrolnym wewnątrz auta na pewno nie można nazwać rozsądnym rozwiązaniem. Ten i inne nie do końca przemyślane pomysły niezmiernie komplikują wykonanie prostych instrukcji. Są przyczyną wielu mniej 15
lub bardziej groźnych wypadków drogowych, gdyż niepotrzebnie absorbują i rozpraszają uwagę kierowcy. Jak pokazuje doświadczenie, projektowanie interfejsu nie jest zagadnieniem drugorzędnym. W biznesie dobry projekt może zadecydować o sukcesie przedsięwzięcia, bądź też stać się przyczyną jego upadku. Jest czynnikiem wpływającym na bezpieczeństwo ludzkiego życia, choć w niektórych przypadkach związek ten nie jest wyraźnie widoczny. Jednak coraz więcej osób, nie tylko specjalistów z informatyki, dostrzega wagę zagadnienia. Dużym zainteresowaniem cieszą się badania mające na celu poznanie i zrozumienie czynników wpływających na poprawę użyteczność interfejsów. Badaniami tymi zajmuje się nauka nazywana Dialogiem Człowieka z Komputerem (Human Computer Interaction). Nie jest to nowy kierunek. Istnieje już od kilkudziesięciu lat, a u jego podstawy leżą odkrycia w wielu innych dziedzinach wiedzy. Kierunek ten jest obecnie intensywnie rozwijany i prawdopodobnie nie zmieni się to w przyszłości, o ile nadal powstawać będą coraz bardziej złożone systemy, wraz z którym pojawiają się nowe problemy dotyczące użyteczności interfejsów. 1.2. Podstawowe zagadnienia Dialogu Człowieka z Komputerem Dialog Człowieka z Komputerem (Human Computer Interaction) to dziedzina wiedzy zajmująca się badaniem użyteczności interfejsów. Naukowcy starają się poznać i zrozumieć, w jaki sposób oprogramowanie oraz inne produkty można dostosować do potrzeb człowieka, tak aby użytkownik mógł z nich korzystać, chciał tego oraz sprawiało mu to przyjemność. Dialog Człowieka z Komputerem charakteryzuje się istnieniem różnych podejść do problemu użyteczności. Opiera się na badaniach nie tylko z zakresu informatyki, ale także wielu innych dyscyplin nauki. Często są to całkiem odmienne dziedziny. Osoba zajmująca się projektowaniem interfejsów musi być wszechstronnie uzdolniona. Powinna posiadać wiedzę z zakresu ergonomii, aby zrozumieć fizyczny aspekt pracy człowieka oraz socjologii, aby móc spojrzeć na problem interakcji w szerszym kontekście. Poznanie użytkownika i jego zachowania wymaga znajomości podstaw psychologii. Dobry projektant powinien być inżynierem, gdyż wiąże się to z opracowaniem nowej technologii, oraz grafikiem, aby umieć zbudować przyjazny i atrakcyjny interfejs. Powinien także znać się na ekonomii, aby wypromować i sprzedać swój produkt. Podobne wymagania można jeszcze długo wyliczać. Podstawy Dialogu Człowieka z Komputerem są więc bardzo szerokie. Trudno jest też wskazać, nawet w przybliżeniu, kiedy dziedzina ta powstała. Niektórzy próbują dostrzec jej źródeł we wczesnych latach sześćdziesiątych i zapoczątkowanych wówczas badaniach nad takimi innowacyjnymi technikami jak edycja tekstu czy wykorzystanie myszy. Według innej opinii, sprecyzowanie podstawowych założeń Dialogu Człowieka z Komputerem i właściwe narodziny tej nauki, nastąpiły na początku lat osiemdziesiątych. Często podawany jest rok 1982, w którym odbyła się konferencja poświęcona czynnikom ludzkim w systemach komputerowych ( Human Factors in Computer Systems ). Prawdą jest, że lata osiemdziesiąte stanowiły prawdziwy przełom w rozwoju Dialogu Człowieka z Komputerem. Gwałtownie wzrosła ilość badań i osiągnięć w zakresie użyteczności interfejsów. Przyjęcie tej tezy wymaga wymienienia 16
kilku innych kierunków rozwoju informatyki, bez których Dialog Człowieka z Komputerem nie mógłby zaistnieć. Tymi kierunkami są: prototypowanie i cykliczny rozwój w zakresie inżynierii oprogramowania; psychologia oprogramowania oraz czynnik ludzki w systemach komputerowych; zastosowanie technik grafiki komputerowej w projektowaniu interfejsów; modele, teorie oraz struktury stosowane przez nauki poznawcze. Prototypowanie i cykliczny rozwój w zakresie inżynierii oprogramowania Lata sześćdziesiąte to okres przełomowy w rozwoju sprzętu komputerowego. Postęp ten umożliwił powstawanie programów o znacznie większych wymaganiach systemowych. Jednocześnie pojawiły się nowe problemy oraz kryzys w inżynierii oprogramowania, który jako taki nie został zażegnany do dziś. Doprowadził jednak do standaryzacji metod rozwoju oprogramowania i ustabilizowania procesu projektowania. Opracowano takie podejścia jak dekompozycja strukturalna, reprezentacja wymagań, specyfikacja. Stanowiły one wstęp do rozwoju bardziej formalnych metod projektowania oprogramowania. Obecnie proces ten jest postrzegany jako powtarzający się w czasie. Powszechnie przyjętą techniką jest szybkie prototypowanie, które polega na budowaniu systemu metodą stopniowych ulepszeń. Na początku tworzony jest prototyp, który udostępnia tylko podstawowe funkcje, często zawiera też sporo błędów. Zostaje jednak przekazany klientowi, a jednocześnie jest rozwijany w sposób cykliczny, wydawane są kolejne wersje. Zaletą takiego podejścia jest możliwość przeanalizowania wymagań oraz weryfikacja celów. Szybkie prototypowanie stanowi obecnie podstawę rozwoju systemów komputerowych. Psychologia oprogramowania oraz czynnik ludzki w systemach komputerowych Kryzys w inżynierii oprogramowania wpłynął także na rozwój kierunku zajmującego się analizą procesu projektowania w kontekście działań człowieka. Kierunek ten stał się obszarem zainteresowania psychologii, głównie w zakresie rozwiązywania problemów oraz manipulacji symbolami. Podejście, według którego zrozumienie ludzkiego zachowania ma kluczowe znaczenie dla całego procesu wytwarzania oprogramowania, w szczególności interaktywnych systemów, cieszyło się dużą popularnością w latach siedemdziesiątych. Do końca dekady powstały formalne grupy zajmujące się zagadnieniami określanymi jako czynnik ludzki w systemach komputerowych. Zapoczątkowane przez nie badania prowadzone są do dzisiaj. Mają na celu poznanie sposobu w jaki ludzie odczuwają i zachowują się podczas pracy przy komputerze. Uzyskane wyniki sugerują, jak można usprawnić pracę użytkownika, np. jakie jest najlepsze ułożenie ręki w czasie pisania na klawiaturze lub jak ustawić monitor, aby korzystanie z niego było wygodniejsze. Zastosowanie technik grafiki komputerowej w projektowaniu interfejsów Przed rokiem 1960 wyrażenie interfejs użytkownika nie istniało w świadomości naukowców. Praca komputera skupiała się na wykonywaniu obliczeń, nie obejmowała natomiast sposobów prezentacji uzyskanych wyników. W latach siedemdziesiątych 17
dokonano wyraźnego postępu w rozwoju komputerów osobistych, a w szczególności monitorów. Przełomowym wydarzeniem w historii informatyki było powstanie pod koniec tej dekady pierwszych środowisk graficznych. W konsekwencji lata osiemdziesiąte stanowiły okres licznych sukcesów w dziedzinie grafiki komputerowej oraz metod wizualizacji. W tym czasie zmieniło się podejście dotyczące przeznaczenia i zastosowania komputerów. Praca przy komputerze przestała być celem samym w sobie. Stał się on środkiem pozwalającym zrealizować inne zadania, narzędziem używanym przez coraz większą liczbę osób z coraz to mniejszym doświadczeniem w tym zakresie. Dlatego należało zadbać, aby systemy były łatwe w nauce, obsłudze oraz odporne na błędy użytkowników. Wymagania te stały się podstawą gwałtownego rozwoju Dialogu Człowieka z Komputerem. Modele, teorie oraz struktury stosowane przez nauki poznawcze Lata siedemdziesiąte to także czas rozwoju nauki o poznaniu (cognitive science). Jej celem jest zrozumienie oraz stworzenie modelu opisującego takie procesy jak postrzeganie, uczenie się, zapamiętywanie, rozwiązywania problemów itp., czyli procesy związane ze zdobywaniem wiedzy. Nauka o poznaniu jest połączeniem wielu innych dyscyplin, między innymi psychologii, filozofii, antropologii oraz sztucznej inteligencji. Wprowadzenie nauki poznawczej do informatyki miało pomóc w tworzeniu programów i dostosowaniu ich do rozwiązywania rzeczywistych problemów, a także czerpania z tego korzyści. Chęć osiągnięcia tego celu sprawiła, że zaczęto analizować takie dziedziny jak mechanika czy algebra. Jednak największym polem do rozwoju nauk poznawczych okazał się Dialog Człowieka z Komputerem. Zrozumienie i wyjaśnienie zasad interakcji człowieka z maszyną wymaga informacji na temat użytkownika, sposobu w jaki zdobywa i wykorzystuje swoją wiedzę, podejmuje decyzje itp. Źródłem wszystkich tych informacji stała się nauka o poznaniu. Według początkowych założeń, Dialog Człowieka z Komputerem miał być dziedziną, która wprowadzi metody poznawcze w proces rozwoju oprogramowania. Szybko zauważono, że nauka o poznaniu dostarcza istotnych wytycznych, które można wykorzystać we wczesnych etapach wytwarzania oprogramowania. Testowanie empiryczne końcowego produktu słabo bowiem sprawdza się w praktyce. Jest kosztowne, wymaga dużo czasu oraz wysiłku, a wyniki pojawiają się późno często zbyt późno, aby wpłynąć na projekt. Potrzebne są więc metody i narzędzia umożliwiające ocenę użyteczności produktu we wczesnych etapach rozwoju. Wykorzystując badania z zakresu nauki o poznaniu, opracowano różne rozwiązania tego problemu. Jednym z nich jest stosowanie wytycznych i standardów. W wyniku przeprowadzonych obserwacji oraz zdobytych doświadczeń, opracowano różne wskazówki dotyczące projektowania interfejsów, np. liczba wykorzystywanych kolorów nie powinna przekraczać sześciu lub liczbę opcji w menu należy ograniczyć do siedmiu. Nauka obsługi interfejsu jest znacznie łatwiejsza jeśli stosowany jest jednolity system oznaczeń. Inne podejście polega na korzystaniu z analogii i metafor tworzeniu projektu na podstawie pojęć zaczerpniętych z codziennego życia. Dobrze znanym przykładem jest metafora desktop, przedstawiająca system komputerowy jako strukturę podobną do pulpitu, z którym związane są pewne obiekty i funkcje. 18
Kolejnym rozwiązaniem jest stosowanie technik formalnego modelowania. Pozwalają one przedstawić wiedzę, którą użytkownik musi posiadać, oraz działania, które musi wykonać, aby zrealizować swoje zadanie w systemie komputerowym. Ważne jest, że uzyskiwane wyniki mają postać modelu, który można analizować. Pozwala to ocenić stopień, w jakim systemy spełniają wymagania dotyczące funkcjonalności, łatwości obsługi i nauki. Innymi słowy jest to oszacowanie mówiące jak skutecznie użytkownik będzie mógł zrealizować określone zadanie w stworzonym projekcie. Ogólny schemat wykorzystywania modeli technicznych w procesie projektowania interfejsu, rozpoczyna się od wstępnej analizy zadania i zaproponowania początkowej formy interfejsu. Następnie tworzone są modele techniczne w celu identyfikacji problemów użyteczności. Nie jest wymagany działający system, więc można stosować je we wczesnych etapach rozwoju oprogramowania. Modele techniczne posiadają wiele zalet w porównaniu z innymi metodami poznawczymi. Stosowanie formalnej notacji umożliwia automatyzację etapów związanych z projektowaniem interfejsu oraz wydajnie wspomaga proces prototypowania i testowania. Korzystanie z modeli technicznych pozwala uzyskać odpowiedzi na pytania dotyczące użyteczności interfejsów znacznie mniejszym nakładem sił i kosztów niż testowanie doświadczalne. Prawdopodobnie najczęściej przytaczany przykład modelu technicznego stanowi GOMS. Jest to użyteczne i sprawdzone praktycznie narzędzie, które zachowanie użytkownika przedstawia w formie opisu struktury zadania. GOMS jest prekursorskim dziełem wśród modeli technicznych. Okazał się jednak na tyle skutecznym rozwiązaniem, iż obecnie stanowi jeden z najszerzej badanych i rozwijanych modeli. *** Projektowanie interfejsu użytkownika jest ważnym zagadnieniem związanym z wytwarzaniem oprogramowania. W pewnych sytuacjach niska jakość interfejsu może spowodować nawet zagrożenie ludzkiego życia. Zapewnienie użyteczności interfejsu ma priorytetowe znaczenie i wymaga stosowania różnych metod wspomagających proces projektowania. Jedną z nich jest GOMS. Polega ona na budowaniu modelu zadania wykonywanego przez użytkownika. Technika GOMS pozwala opracować przyjazny interfejs przy znacznej oszczędności czasu i kosztów związanych z testowaniem. 19
Rozdział 2 Podstawy modelowania GOMS oraz GOMSL. Rozdział ten, mający na celu przedstawienie teorii analizy GOMS i GOMSL, oparty jest na publikacji Davida Kierasa zatytułowanej A Guide to GOMS Model Usability Evaluation using GOMSL and GLEAN3. Struktura rozdziału jest następująca: część 2.1 zawiera definicję i wyjaśnienie najważniejszych pojęć związanych z metodą GOMS. Część 2.2 prezentuje model KLM. W części 2.3 opisana została notacja GOMSL, a w szczególności sposób przechowywania danych oraz instrukcje służące do budowy modelu GOMSL. Część 2.4 omawia algorytm konstrukcji modelu GOMSL, a 2.5 przedstawia konkretny przykład tego algorytmu. Części 2.6 oraz 2.7 wyjaśniają w jaki sposób wyznaczany jest odpowiednio czas nauki oraz czas wykonywania zadania, dwa parametry, na podstawie których dokonywana jest ocena interfejsu. 2.1. Analiza zadań za pomocą metody GOMS W roku 1983 Stuart Card, Thomas Moran i Allen Newell opublikowali wspólną pracę zatytułowaną The Psychology of Human-Computer Interaction. Od tej pory jest ona uznawana za jedną z najważniejszych pozycji dotyczących dialogu człowieka z komputerem. Autorzy zaprezentowali nową technikę analizy zadania, tzw. metodę GOMS. Nazwa GOMS jest akronimem i oznacza Cele (Goals), Operatory (Operators), Procedury (Methods) oraz Reguły Wyboru (Selection Rules), cztery elementy służące do budowy modelu zadania. Sama definicja metody GOMS jest bardzo ogólna. Jest ona opisem wiedzy jaką użytkownik musi posiadać, aby wykonać zadanie. Innymi słowy jest odpowiedzią na pytanie "jak to zrobić". Proces analizy rozpoczyna się od wyznaczenia celów. Cel jest kierunkiem działań użytkownika, końcowym stanem, który stara się on osiągnąć. Aby zrealizować pojedynczy cel, często należy poddać go dekompozycji na cele pośrednie. Na przykład zaznaczenie fragmentu tekstu w edytorze może przebiegać według schematu: użytkownik ustawia kursor myszy na początku wyrażenia, klika lewym przyciskiem myszy, przesuwa kursor na koniec wyrażenia i ponownie klika, mając jednocześnie wciśnięty klawisz Shift. Używając notacji GOMS, definiujemy podstawowy cel ZAZNACZ-TEKST i cele pośrednie PRZESUŃ-MYSZ, KLIKNIJ oraz WCIŚNIJ-SHIFT-I-KLIKNIJ. Te z kolei 20
podlegają dalszej analizie. W kolejnych krokach tworzona jest więc struktura hierarchiczna. Do realizacji poszczególnych celów służą operatory. Są to motoryczne, percepcyjne lub poznawcze czynności wykonywane przez użytkownika. Różnica między celami i operatorami jest bardzo mała i dotyczy stopnia zaawansowania analizy. Jeśli dla pewnej akcji nie jest konieczna jej dalsza dekompozycja, tworzony jest operator. W powyższym przykładzie, zdefiniowane cele pośrednie mogą być operatorami, gdy analityk uzna, że osiągnięto odpowiedni poziom szczegółowości. Trzecią strukturą modelu GOMS są procedury. Procedury to sekwencje operatorów i celów pośrednich, pozwalających osiągnąć określony cel. W omawianym przykładzie zadanie wymaga zdefiniowania następujących procedur: PRZESUŃ-MYSZ na początek wyrażenia, KLIKNIJ, PRZESUŃ-MYSZ na koniec wyrażenia, WCIŚNIJ-SHIFT-I- KLIKNIJ. Aby zaznaczyć fragment tekstu niekoniecznie trzeba posługiwać się myszką. Ten sam efekt uzyskamy wykorzystując klawiaturę. W przypadku gdy istnieje więcej niż jedna procedura realizująca określony cel, należy zastosować reguły wyboru. Bazując na specyficznych właściwościach zadania, decydują one, która procedura jest odpowiednia do jego wykonania. Dla zadanego przykładu reguła wyboru może dotyczyć ilości zaznaczanych znaków: jeśli jest ich więcej niż 10, użyj procedury z myszką. Posługiwanie się modelem GOMS wprowadza pewne założenia odnośnie wiedzy o zadaniu. Po pierwsze jest to wiedza proceduralna. Użytkownik wykonuje zadanie w sposób rutynowy, realizując pewien znany sobie algorytm. Nie są brane pod uwagę takie aspekty jego pracy jak rozwiązywanie problemów lub inne twórcze działania. Po drugie, uwaga analityka koncentruje się na opisie poszczególnych kroków zadania i nie wymaga poznania wykorzystywanego systemu, jego wewnętrznych parametrów. Po trzecie, analiza GOMS rozpoczyna się od zdefiniowania listy celów najwyższego poziomu. Sama metoda GOMS nie potrafi ich jednak dostarczyć. Opis celów musi pochodzić z pewnych źródeł zewnętrznych, np. przeprowadzonych obserwacji lub wywiadów. 2.2. Model KLM KLM wersja oryginalna K [press a key or button] P [point to a target] H [home hands] D [draw a line segment] M [mentally prepare] R [response time] KLM wersja zmodyfikowana K [press a key] T(n) [n * K] P [point to a target] B [press or release mouse button] BB [click mouse button] H [home hands] M [mentally prepare] W(t) [waiting time] Tabela 2.2.1. Operatory KLM. 21
Najprostszym modelem GOMS jest KLM. Model KLM został opracowany przez zespół Card, Moran, Newell w roku 1980. Dynamiczny rozwój interfejsów graficznych stworzył potrzebę jego aktualizacji. W roku 1993 zmodyfikowaną wersję operatorów KLM zaproponował David E. Kieras. Obie wersje, oryginalną i zmodyfikowaną przedstawia Tabela 2.2.1. Operatory modelu KLM K wciśnięcie klawisza. Szacowanie czasu wykonania tego operatora jest trudne, ponieważ zależy on od umiejętności użytkownika związanych z pisaniem na klawiaturze. Jak pokazują badania czas ten może wahać się od 0,12 sec w przypadku doświadczonego użytkownika do nawet 1,2 s jeśli jest on nowicjuszem. Dobrym przybliżeniem i najczęściej wykorzystywanym w praktyce jest wartość 0,28 s. T(n) sekwencja n wpisywanych na klawiaturze znaków. P wskazanie myszką określonego obiektu na ekranie monitora. Czas wykonania operatora P różni się w zależności od odległości związanej z przesunięciem kursora, jak również od rozmiarów obiektu celu. W typowych sytuacjach wartość 1,1 s jest dobrym przybliżeniem. B wciśnięcie lub zwolnienie przycisku myszki. BB kliknięcie myszką (wciśnięcie i zwolnienie przycisku myszki). H przesunięcie ręki z klawiatury na myszkę lub odwrotnie. M operator odzwierciedlający proces myślenia. Oszacowanie czasu wykonywania operatora M wymaga pewnych założeń: użytkownik zna procedurę realizacji zadania, nie angażuje się w rozwiązywanie problemów, ani nie podejmuje żadnych twórczych rozważań. Operator M odzwierciedla krótkie pauzy występujące podczas wykonywania zadania przez użytkownika, związane np. z przypomnieniem sobie nazwy pliku lub zlokalizowaniem obiektu na ekranie. Z punktu widzenia szacowania czasu wykonania zadania, ważne jest nie tyle umiejscowienie operatorów M w modelu, co ich łączna liczba. W(t) oczekiwanie na odpowiedź systemu. W tym czasie użytkownik może wykonywać inne czynności. Przy obecnej szybkości komputerów czas odpowiedzi systemu jest przeważnie pomijalnie mały. Istnieją jednak pewne sytuacje ( np. przetwarzanie danych z baz danych) gdy opóźnienie jest zauważalne. Operator W można jednak pominąć, ponieważ o ile opóźnienie systemu nie jest zbliżone do zera, będzie miało taką samą wartość we wszystkich badanych projektach. Zakładając, że użytkownika nie interesują konkretne wartości, ale raczej wynik porównania tych wartości dla różnych programów, obecność operatora W nie ma większego znaczenia. Czasy wykonywania poszczególnych operatorów w modelu KLM zostały wyznaczone na podstawie przeprowadzonych badań i doświadczeń (Tabela 2.2.2). 22
K 280 msec T(n) 280*n msec P 1100 msec B 100 msec BB 200 msec H 400 msec M 1200 msec W(t) t msec Tabela 2.2.2. Czas wykonywania operatorów KLM. Heurystyczny algorytm wstawiania operatorów M Jednym z trudniejszych etapów tworzenia modelu KLM jest podjęcie decyzji gdzie należy wstawić operator M. Nie istnieją reguły, które w jednoznaczny sposób określałyby takie miejsca. Jedyne wskazówki mają charakter heurystyczny. Jest to kilka zasad zaproponowanych przez twórców GOMS. Zasada 0: Początkowe rozmieszczenie operatorów M. Umieść operator M przed każdym operatorem K oraz przed każdym operatorem P, który oznacza wybór polecenia, a nie jego argumentów (rozpoczyna sekwencję akcji prowadzących do wykonania pewnego zadania). Zasada 1: Usuń operatory M rozdzielające powiązane ze sobą akcje. Jeśli operator znajdujący się przed operatorem M oraz operator znajdujący się za operatorem M są ze sobą powiązane w taki sposób, że na podstawie obecności pierwszego z nich można przewidzieć obecność drugiego, usuń rozdzielający ich operator M. Na przykład, jeśli użytkownik przesunął kursor myszki po czym wykonał kliknięcie, należy usunąć operator M rozdzielający obie akcje, umieszczony tam zgodnie z Zasadą 0. Oznacza to, że sekwencja operatorów P M K zostanie zastąpiona sekwencją P K. Zasada 2: Usuń operatory M umieszczone wewnątrz jednostek poznawczych. Jeśli łańcuch składający się sekwencji operatorów M K jest częścią pewnej jednostki poznawczej, usuń wszystkie operatory M w tym łańcuchu z wyjątkiem pierwszego. Jednostką poznawczą nazywamy sekwencję znaków stanowiących nazwę polecenia lub jego argumenty (każdą sekwencję znaków wpisywaną przez użytkownika w ramach wykonywanego zadania), np. 'Y', 'Hello World' lub '1652.73'. Zasada 3: Usuń operatory M umieszczone przed kolejnymi operatorami ograniczającymi. Jeśli operator K jest dodatkowym i zbędnym operatorem ograniczającym umieszczonym na końcu jednostki poznawczej, usuń operator M stojący przed tym operatorem K (np. ogranicznik argumentu polecenia stojący bezpośrednio za ogranicznikiem tego polecenia). Zasada 4: Usuń operatory M ograniczające polecenia. Jeśli operator K jest operatorem ograniczającym stojącym za pewnym nie zmieniającym się łańcuchem np. nazwą polecenia lub każdym innym wyrażeniem, które jest takie samo za każdym gdy się go używa, usuń operator M umieszczony przed tym 23
operatorem K (dodawanie operatora ograniczającego stało się przyzwyczajeniem, dlatego nie jest on postrzegany jako część łańcucha znaków i nie wymaga oddzielnego operatora M). Jeśli jednak operator K jest operatorem ograniczającym łańcucha znaków, który jest argumentem polecenia lub w ogólności może różnić się, zachowaj operator M przed tym operatorem K. Zasada 5: Usuń operatory M pokrywające się z operatorami R. Nie bierz pod uwagę operatorów M, które pokrywają się z operatorami oznaczającymi opóźnienie systemu R, kiedy użytkownik oczekuje na odpowiedź komputera. W czasie gdy przedstawione reguły były opracowywane, typowy interfejs użytkownika składał się przede wszystkim z wiersza poleceń. W następnych latach zasady te były modyfikowane i dostosowywane do wymagań interfejsów graficznych. Jednak żadna z późniejszych wersji nie zyskała większej popularności. 2.3. Język GOMSL Obecnie nazwą GOMS określa się całą rodzinę technik modelowania zachowania użytkownika. Wykorzystują one ideę czterech struktur opisujących zadanie, ale różnią się sposobem szacowania czasu jego wykonania. Najprostszą metodą GOMS jest model KLM (Keystroke-Level Model), który definiuje zaledwie 6 operatorów odpowiadających podstawowym czynnościom wykonywanym przez użytkownika, jak np. wciśnięcie klawisza lub ruch ręki. Pozostałe techniki GOMS charakteryzują się większą złożonością starają się odwzorowywać nie tylko działania motoryczne, ale również poznawcze i percepcyjne. Dużą popularność zdobyła metoda Davida Kierasa o nazwie NGOMSL (Natural GOMS Language). Model NGOMSL ma postać programu i jest rozszerzeniem znanego wcześniej modelu CMN w oparciu o architekturę CCT (Cognitive Complexity Theory). Język NGOMSL dostarcza dobrze zdefiniowaną procedurę konstrukcji modelu GOMS, która może zostać wykorzystana przez rzeczywiste programy. Jest użyteczny w sytuacjach gdy zadania charakteryzują się sekwencyjną formą kroków i hierarchiczną strukturą. Rozwinięciem metody NGOMSL jest język GOMSL (GOMS Language). Został stworzony jako wykonywalna postać NGOMSL, ma więc na celu jego realizację w praktyce. U podstaw języka GOMSL leżą pewne założenia. Po pierwsze powinien on umożliwiać nie tylko budowę modelu GOMS i wykonywanie go, ale również mieć czytelną, łatwą do analizy formę. Drugie założenie mówi, że GOMSL nie jest typowym językiem programowania, ale raczej "językiem programowania ludzkiego umysłu". Często z tego powodu może wydawać się dość ograniczony. Na przykład brak złożonych instrukcji warunkowych uzasadniony jest zdolnościami przetwarzania ludzkiego mózgu. Jest to próba symulacji architektury umysłu, innej niż komputerowa. Model GOMSL przedstawia proces wykonywania zadania z punktu widzenia użytkownika. Ma postać programu, co ułatwia jego techniczną realizację. W roku 1993 Scott Wood wraz z kilkoma współpracownikami stworzyli narzędzie GLEAN (GOMS Language Evaluation and Analisys), które symuluje przebieg analizy GOMSL. Składa się 24
z dwóch podstawowych części: reprezentującej użytkownika oraz części odpowiadającej urządzeniu systemowi, z którym użytkownik współpracuje. Rozdział ten opisuje język GOMSL w oparciu o jego realizację w środowisku GLEAN3. Reprezentacja danych Narzędzie GLEAN3 symuluje proces realizacji zadania przez użytkownika współpracującego z pewnym systemem. Interakcja z komputerem polega na wymianie informacji. Człowiek obserwuje ekran monitora oraz słucha dźwięków wydobywających się z głośników w ten sposób odbiera informacje z systemu. Jednocześnie wydaje polecenia za pomocą klawiatury, myszki, może też używać sterowania głosowego. Narzędzie GLEAN3 symuluje człowieka za pomocą kilku procesorów przetwarzających informacje wymieniane z systemem oraz procesora głównego. Procesor główny wykonuje procedury napisane w języku GOMSL, korzystając z informacji otrzymanych z systemu, zgromadzonych w pamięci długotrwałej oraz opisu poszczególnych zadań. Opis symulacji użytkownika w środowisku GLEAN3 przedstawia Rysunek 2.3.1. Dane przetwarzane za pomocą języka GOMSL zapisywane są w postaci obiektów. Każdy obiekt ma przyporządkowaną nazwę oraz listę właściwości i odpowiadających im wartości symboli. Symbol może być identyfikatorem, napisem lub liczbą. Identyfikator oznacza dowolny ciąg znaków składający się z liter, cyfr, myślnika i podkreślenia, przy czym pierwszy znak musi być literą. Napisy i liczby zapisywane są w cudzysłowiu. Przedstawiona konstrukcja w prosty sposób dostarcza danych potrzebnych do opisu zadania oraz tworzy strukturę pamięci długotrwałej. Przykładowy fragment kodu wygląda następująco: LTM_item: Copy_Command Name is "Copy". Accelerator_Key is COMMAND-C. W pierwszej linii podana jest nazwa obiektu Copy_Command. Następnie mamy listę właściwości obiektu oraz przypisanych im wartości. Pierwsza wartość jest napisem, druga identyfikatorem. Obok pamięci długotrwałej występuje także pamięć robocza. Przechowuje ona dwa rodzaje informacji. Pierwszy z nich to znaczniki zapisywane w postaci identyfikatorów ujętych w specjalne nawiasy '<' oraz '>'. Znacznik jest podstawową jednostką pamięci roboczej. Jeśli w czasie wykonywania procedury pojawi się jako argument operatora, jest zastępowany przez odpowiadającą mu wartość. Drugim rodzajem informacji jest tzw. obiekt aktywny, czyli aktualnie przetwarzany. Uzyskiwanie dostępu do obiektów jest z natury procesem czasochłonnym. Jeśli jednak obiekt zostanie już zlokalizowany i załadowany do pamięci, wszystkie szczegóły o nim są łatwo i szybko dostępne poprzez mechanizm własność-wartość. Zmiana obiektu wymaga ponownego wysiłku przeładowania wszystkich jego danych. 25