Analýza konceptuálního modelu aplikace. Vojtěch Šívr

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Analýza konceptuálního modelu aplikace Vojtěch Šívr

Vedoucí práce: Ing. Filip Hanzl

Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia 24. května 2011

iv

v

Poděkování Chtěl bych poděkovat vedoucímu mé práce, Ing. Filipu Hanzlovi, za cenné rady při návrhu a vedení uživatelského testu, Ing. Ivo Malému za pomoc při implementaci a také mé rodině, která mě při studiu podporovala.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze, dne 24. 5. 2011

.............................................................

viii

Abstract Computer systems have become very sophisticated and complex. For their effective usage it is necessary that the user interface is clear and simple. Therefore, various methods from User-centered design are used. The main goal is to analyze the needs and limitations that the end user of our application has. One of the techniques is called usability testing. This thesis describes an extension of this method that uses the knowledge of user’s mental model and conceptual model of the application. Thanks to the shared notation it is possible by comparing the models to distinguish the circumstances of apparently similar problems. These circumstances can be used to fix the design of application’s user interface. Because models that are captured from the test are very large, their creation and analysis using existing tools is time consuming. Therefore, to help the tester this thesis deals with the design of a plugin for IVE tool and describes how to use it effectively during and after the test. Finally this thesis refers the implementation of a subset of features of the designed plugin.

Abstrakt Počítačové systémy se stávají stále sofistikovanějšími a komplikovanějšími. Pro jejich efektivní používání je nutné, aby uživatelského rozhraní bylo srozumitelné a dostatečně jednoduché na ovládání. Proto se používají metodiky uživatelsky orientovaného návrhu softwaru, které mají za cíl komunikovat s potenciálními uživateli již v průběhu vývoje a soustředit se na jejich schopnost orientace v aplikaci. Jednou z těchto metodik, je uživatelské testování použitelnosti.

ix

x

Tato práce popisuje rozšíření výše zmíněné metodiky s využitím znalosti mentálního modelu uživatelů a konceptuálního modelu aplikace. Jelikož oba typy modelů mají stejnou notaci, je možné je mezi sebou porovnat a pomocí toho rozlišit okolnosti vzniku zdánlivě stejných problémů. Tyto okolnosti pak lze využít při návrhu opravy uživatelského rozhraní aplikace. Jelikož modely pořízené z testu jsou značně rozsáhlé, jejich tvorba a analýza stávajícími nástroji je časově náročná. Proto se práce dále zabývá návrhem zásuvného modulu do aplikace IVE tool, který testerovi usnadní testování pomocí této metody, a popisem obecného scénáře testu konceptuálního modelu, který využívá navrhnutý plugin. Na závěr se práce zmiňuje o implementaci podmnožiny funkcí navrhnutého modulu.

Obsah 1 Úvod 1.1 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Analýza problému a návrh testu 2.1 Konceptuální model . . . . . . . . . . . 2.2 Mentální model . . . . . . . . . . . . . . 2.3 Návrh testu . . . . . . . . . . . . . . . . 2.3.1 Výběr aplikace . . . . . . . . . . 2.3.1.1 Open Office . . . . . . . 2.3.1.2 Blender . . . . . . . . . 2.3.1.3 Vim . . . . . . . . . . . 2.3.1.4 GIMP . . . . . . . . . . 2.3.2 Výběr cílové skupiny . . . . . . . 2.3.3 Přehled případů užití - Use Cases 2.3.4 Screener . . . . . . . . . . . . . . 3 Postup při testování 3.1 Postup při testování s experty . . . . . 3.1.1 Protokol . . . . . . . . . . . . . 3.1.2 Pre-test interview . . . . . . . . 3.1.3 Nastavení testu . . . . . . . . . 3.1.4 Nahrávání obrazovky a pořízení 3.1.5 Post-test interview . . . . . . . 3.2 Postup při testování se začátečníky . . 3.2.1 Protokol . . . . . . . . . . . . . 3.2.2 Pre-test interview . . . . . . . . 3.2.3 Nastavení testu . . . . . . . . . 3.2.4 Post-test interview . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . zvukového záznamu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Provedení a zpracování testu 4.1 Vytvoření konceptuální modelu aplikace 4.2 Testované osoby . . . . . . . . . . . . . . 4.2.1 Osoba 1 . . . . . . . . . . . . . . 4.2.2 Osoba 2 . . . . . . . . . . . . . . 4.2.3 Osoba 3 . . . . . . . . . . . . . .

xi

. . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

1 2

. . . . . . . . . . .

3 . 3 . 4 . 5 . 6 . 6 . 6 . 7 . 7 . 8 . 9 . 11

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

13 13 13 14 15 15 16 17 17 17 17 17

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

19 19 22 23 23 23

xii

OBSAH

4.3 4.4 4.5

4.6

4.2.4 Osoba 4 . . . . . . . . . . . . . . . . . . 4.2.5 Osoba 5 . . . . . . . . . . . . . . . . . . 4.2.6 Osoba 6 . . . . . . . . . . . . . . . . . . 4.2.7 Osoba 7 . . . . . . . . . . . . . . . . . . Moderování testu . . . . . . . . . . . . . . . . . Zpracování testu . . . . . . . . . . . . . . . . . Zjištění z testu . . . . . . . . . . . . . . . . . . 4.5.1 Absence kreslení primitiv . . . . . . . . 4.5.2 V aplikaci se nepracuje s objekty . . . . 4.5.3 Absence nástroje, který kreslí rovné čáry 4.5.4 Nelze označit více vrstev . . . . . . . . . 4.5.5 Plovoucí výběr . . . . . . . . . . . . . . Shrnutí použitých aplikací . . . . . . . . . . . .

5 Návrh a popis použití pluginu 5.1 Popis aplikace IVE tool . . . 5.2 Popis použití pluginu . . . . . 5.3 Návrh pluginu . . . . . . . . . 5.3.1 Import modelu . . . . 5.3.2 Vizualizace dat . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

23 24 24 24 24 25 27 28 28 29 31 31 31

. . . . .

35 35 36 38 38 39

6 Implementace pluginu 41 6.1 MentalModelGraphMLImporter . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.2 MentalModelViz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7 Závěr

43

A Uživatelský manuál A.1 Instalační příručka . . . . A.2 Uživatelská příručka . . . A.2.1 Import modelu . . A.2.2 Vizualizace modelu A.2.3 Práce s modelem .

47 47 48 48 48 48

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

B Seznam použitých zkratek

53

C Screener

55

D Zadání testu D.1 Instrukce

57 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

E Obsah přiloženého CD

61

Seznam obrázků 2.1 2.2 2.3 2.4 2.5 2.6

Síť propojených inteligentních bankomatů, vše je uloženo na kartě . . . . . . . 4 Centrální počítač s lokálními “hloupými” terminály, na kartě je pouze PIN . . 4 Komentovat mentální modely uživatelů je užitečné. Pokud se k nim často vracíme, urychlí nám orientaci v modelu. . . . . . . . . . . . . . . . . . . . . . 5 Ukázka výsledného turnajového pavouka . . . . . . . . . . . . . . . . . . . . . 9 Fotka určená k úpravě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Výsledná koláž . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1

Uživatelské rozhraní programu Camtasia. Na první pohled vypadá složitě, ale člověk se s ní rychle sžije. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 4.2 4.3

19 20

Příklad tříd entit. Jednotlivé instance v systému se dají odlišit pomocí atributů. Znázornění podtypů v modelu a vztahu s entitami. . . . . . . . . . . . . . . . Příklad modelu, kde jsou pojmenované vztahy a určené jejich kardinality a parciality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Vybrání více vrstev v GIMPu je možné pouze pomocí ikonky s řetězem, které se nachází vedle každé vrstvy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Uživatel chybně po nakreslení čtverce čeká, že bude moci prostřednictvím kontextové menu upravit jeho atributy . . . . . . . . . . . . . . . . . . . . . . 4.6 Část konceptuálního modelu aplikace, která popisuje vybrání obvodu výběru. 4.7 Část mentálního modelu aplikace, která popisuje, jak uživatel nastaví objektu barvu rámečku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Znázornění absence primitiv pomocí modelů . . . . . . . . . . . . . . . . . . . 4.9 Postup kreslení čáry. Všimněte si, že nápověda dobře reaguje na činy uživatele 4.10 Část modelů, na kterých je vidět rozdíl při kreslení rovných čar . . . . . . . . 4.11 Srovnání modelů ohledně výběru a manipulace s více vrstvami . . . . . . . . . 4.12 Konceptuální model, který zobrazuje funkci plovoucího výběru a jak se dá ukotvit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2 5.3

21 22 26 27 28 29 30 32 33 34

Kostra modelu aplikace, kterou použiji při testu s uživatelem . . . . . . . . . 36 Zobrazení mentálního modelu z pretest interview pluginem. Entity, které mají podtypy, jsou znázorněné červeně. . . . . . . . . . . . . . . . . . . . . . . . . . 37 V modelu se dá daleko lépe orientovat, pokud nemáme zobrazené podtypy. . . 38

A.1 Dialogové okno pro přidání pluginu ze souboru. . . . . . . . . . . . . . . . . . 47 A.2 Z nabídky Convertorů zvolíme importer pro mentální modely. . . . . . . . . . 48

xiii

xiv

SEZNAM OBRÁZKŮ

A.3 Ikonka sloužící pro vizualizaci modelu. . . . . . . . . . . . . . . . . . . . . . . A.4 Zde vybereme správný plugin pro vizualizaci. . . . . . . . . . . . . . . . . . . A.5 Pro zobrazení modelů vedle sebe musíme jeden přetáhnout například k levému rohu aplikace (zobrazí se červený rámeček). . . . . . . . . . . . . . . . . . . . A.6 Pokud je entita společná pro oba modely (jak mentální tak konceptuální), tak po najetí myší na ní je mimo zobrazení sousedních uzlů v prvním grafu zvýrazněna entita v druhém grafu. . . . . . . . . . . . . . . . . . . . . . . . .

49 50 51

52

D.1 Výsledný pavouk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 D.2 Fotka k úpravě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 D.3 Výsledná koláž . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Seznam tabulek 6.1 6.2 6.3

Cyklus dat v aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Schéma tabulky uzlů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Schéma tabulky hran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xv

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Každé zařízení vyrobené člověkem má nějaké rozhraní. Například uživatelské rozhraní mého kola má řídítka, sedadlo, pedály, brzdy a rychlostní stupně. U budíku se skládá z malé obrazovky a několika tlačítek rozmístěných dokola. Dokonce i mapa města nebo vlakový jízdní řád má své uživatelské rozhraní. Jelikož se počítačové systémy staly na rozdíl od výše zmíněných zařízení mnohonásobně komplexnější, nároky na kvalitně navržené a efektivní uživatelské rozhraní vzrostly. Stále více se toho děje automaticky na pozadí, skryto v softwaru, a proto je důležité odhalit co nejvíce informací o těchto dějích uživateli skrze uživatelské rozhraní. Úkolem je, aby uživatel byl schopen rozpoznat, co se stalo se systémem, a na první pohled vidět podobně jako u rozbitého kola, jaký má defekt a jak ho opravit. Kvalitní user interface je důležitý. Návrháři používají metodiky uživatelsky orientovaného návrhu (viz [17]), které spočívají v přímé komunikaci s uživateli v klíčových bodech projektu, aby se ujistili, že všechny původní požadavky budou splněny. Jedním z často používaných postupů při vývoji je výroba různě abstraktních modelů (tzv. prototypů), které mimo jiné mohou sloužit k uživatelskému testování, kdy potencionální uživatelé finálního produktu jsou pozváni, aby si vyzkoušeli tento prototyp a odhalili jeho případné nedostatky. Například automobilka chce vyrobit nové auto. Nejprve zadá práci a požadavky designérovi, který si nakreslí několik skic na papír. Ty posléze donese svým nadřízeným, kteří vyberou ten návrh, který se jim zamlouvá nejvíce. Designér poté vyrobí podrobný plán auta, který poslouží grafikům pro vyrobení 3D podoby auta. Ten je zase poskytnut marketingovému oddělení, které se snaží získat odezvu od zákazníků. Dalším modelem může být větší plastový model, který bude podroben testům aerodynamiky ve speciálním tunelu. Výsledky se pak počítačem zpracují a poslouží například pro odhadnutí očekávané maximální rychlosti a průměrné spotřeby paliva. Ačkoliv by se dalo najít mnohem více modelů, které předcházejí oficiálnímu představení auta veřejnosti na některém z veletrhů, vidíme, že modely se používají v průběhu vývoje k různým účelům. David Benyon ve své knize říká (viz [1], strana 4), že jednou ze zásad vývoje uživatelského rozhraní je rozlišení mezi konceptuálním a fyzickým designem. Na konceptuální úrovni je nutné analyzovat jaké objekty a jaké funkce bude uživatel používat pro splnění daných úkolů, které bude možné v rámci systému řešit. Například při návrhu automatu na vlakové jízdenky designér může určit, že daný automat bude poskytovat informaci o odjezdech a příjezdech vlaků, destinaci a o cenách jízdenek. Dále musí přijímat platby a vydávat lístky. V takovém případě by mezi konceptuální objekty patřily – jízdenka (atribut cena), destinace

1

2

KAPITOLA 1. ÚVOD

(atribut čas příjezdu/odjezdu), apod. Obecnou zásadou je, že se designér snaží, aby výsledný konceptuální model byl co nejjednodušší, obsahoval co nejméně konceptů, ale zároveň aby byl abstraktní reprezentací konkrétního pohledu na celý systém. V některém bodě vývoje se vývojář bude muset rozhodnout, jak vlastně systém bude vypadat. To je fáze fyzického designu. Mimo jiné se zaměřuje i na to, kde a kdy se akce provádějí a v jakém pořadí. Tato práce bude především o konceptuální úrovni a o tom, jak využít znalost konceptuálního modelu pro uživatelské testování. Zejména mě bude zajímat, do jaké míry se představy uživatele (jeho mentální model, o nich později) o tom, co chce udělat, shodují s tím, co nabízí aplikace (tj. její konceptuální model).

1.1

Struktura práce

Při testu použitelnosti se může stát, že několik uživatelů udělá v témže případě chybu a nebudou kvůli tomu schopni dokončit Use Case. Při následné analýze může dojít k tomu, že se tester bude mylně domnívat, že se jedná o tutéž chybu a nerozpozná, že u více uživatelů mohl být problém způsoben různými okolnostmi. Pak mohou nastat situace, kdy ačkoliv chyba byla v programu opravena, stále existuje určité množství uživatelů, kteří s danou funkcionalitou mají potíže. V této práci proto navrhnu rozšíření testu použitelnosti, které bude využívat mentální modely uživatelů. Zejména se soustředím na to, proč k chybám dochází. Budu se ptát: „Proč uživatel nepoužil tento nástroj? Bylo to z důvodu, že jeho ikonka neodpovídala uživatelovým představám? Nebo očekával, že to spíše bude funkce dostupná z kontextového menu? Anebo ho zmátl název nástroje, a původně se domníval, že nástroj slouží k úplně něčemu jinému?“. Nejprve navrhnu a provedu uživatelský test rozsáhlé aplikace. Za pomoci stávajících logovacích a CASE nástrojů (viz [3]) vytvořím konceptuální model aplikace a mentální modely účastníků testu. Díky tomu pak mohu porovnat výsledky jednotlivých účastníků tak, že porovnám jejich modely mezi sebou a interpretuji rozdíly mezi nimi. Po testu zjistím, jestli byl můj původní návrh a odhad rozsahu modelů správný a navrhnu obecný postup při testování konceptuálního modelu aplikace a zápisu modelů. Analyzuji přínos použitých nástrojů a navrhnu a implementuji zásuvný modul do aplikace IVE Tool, který usnadní testerovi vytváření a následnou analýzu modelů.

Kapitola 2

Analýza problému a návrh testu Při výběru tématu mé práce jsem byl motivován faktem, že mě lákalo testovat uživatelské rozhraní s uživateli. Vzpomínám si, že při testování jedné aplikace sloužící ke katalogizaci filmů v rámci semestrálního projektu jsem byl někdy až šokován z různorodosti reakce uživatelů. Byl jsem proto velice nadšen, když mě kontaktoval Ing. Filip Hanzl s nabídkou tohoto tématu bakalářské práce, i když zpočátku jsem měl obavy z metody, kterou budu testovat. O tom, že se tato metoda dá využít při uživatelském testu, jsem byl přesvědčen až příkladem testování bankomatů z knihy Davida Benyona (viz [1], strana 114). Tam ukázal využití mentálních modelů na příkladu z reálného života, kdy dostal za úkol zjistit, proč se před jedním typem bankomatu tvoří fronty zatímco před druhým typem ne, ačkoliv počet uživatelů obou typů bankomatů je shodný. Celkem 16 subjektů se zúčastnilo testu. Benyon byl překvapen z různorodosti mentálních modelů účastníků. Jeden z nich věřil, že velká porce informace (zůstatek, denní limit, pin,. . . ) je uložena přímo na kartě (viz obrázek 2.1). Tato informace je pak aktualizována pomocí bankomatu vždy, když dojde k výběru. Jiný uživatel si oproti tomu myslel, že na kartě je uložen pouze PIN a automat je pouze „hloupý“ terminál sloužící k připojení k centrálnímu počítači, kde jsou uloženy všechny údaje a kde probíhají všechny transakce (viz obrázek 2.2). Ačkoliv oba uživatelé mohou mít pravdu (anebo žádný z nich), tento bankomat určitě neodhaluje příliš mnoho informací o probíhajícím ději na pozadí při vybírání hotovosti a to může mít za následek, že uživatel před tímto bankomatem musí strávit více času, než zcela pochopí, jak bankomat funguje a co od něj vyžaduje. Také to ukazuje na porušení jednoho z 10 pravidel tzv. „Design Heuristics“ (viz [5]) - pravidlo ohledně viditelnosti stavu systému. To říká, že systém by měl uživatele neustále informovat o tom, co se děje, v rámci odezvy v rozumném čase.

2.1

Konceptuální model

Konceptuální model obsahuje jednotlivé koncepty aplikace a relace mezi nimi. Někdy se mu říká doménový model. Jedná se o abstraktní model, u kterého neberu v úvahu návrh implementace ani použitou architekturu. Na této úrovni mě nezajímají ani typy atributů a funkce jednotlivých entit (konceptů). Co mě však zajímá je kardinalita a funkce vztahů mezi koncepty.

3

4

KAPITOLA 2. ANALÝZA PROBLÉMU A NÁVRH TESTU

Obrázek 2.1: Síť propojených inteligentních bankomatů, vše je uloženo na kartě

Obrázek 2.2: Centrální počítač s lokálními “hloupými” terminály, na kartě je pouze PIN

Konceptuální model slouží doménovým expertům při navrhování systému pro diskuzi konkrétního problému. Pomocí něj odhalí správné vztahy mezi různými koncepty, aby posléze model posloužil jako pevný základ pro následující vývoj. Moje notace zápisu konceptuálního modelu aplikace bude podobná jako ve výše uvedeném příkladu s bankomaty (viz obrázky 2.1 a 2.2). Využiji názornost doménového diagramu a zobrazím jednotlivé entity a vztahy mezi nimi pomocí UML class diagramu. Jelikož výsledný model aplikace bude velice rozsáhlý, pro rychlejší orientaci v něm budu model doplňovat o moje poznámky popisující chování konceptu v systému.

2.2

Mentální model

Uživatel komunikuje s aplikací pomocí uživatelského rozhraní. To uživateli ukazuje pohled na konceptuální model. Uživatel si zprostředkovanou interakcí vytváří svůj model o tom, jak systém pracuje, jaké jsou jeho koncepty a jaké jsou mezi nimi vztahy. Nemusí se ale nutně jednat o počítačový systém, lidé si neustále vytvářejí mentální modely o věcech kolem, se kterými přicházejí do styku. Známý ke mně přišel z cesty po Mexika a začal mi povídat historku, která se mu přihodila. Jak jsem ho poslouchal, ihned jsem si začal v hlavě budovat obrázek o tom, jak to tam mohlo vypadat. Jelikož jsem v Mexiku nikdy nebyl, při vytváření mého modelu jsem čerpal z knih a filmů, o kterých mi bylo známo, že se odehrávají v této oblasti. Představoval jsem si malou

2.3. NÁVRH TESTU

5

osadu obydlenou několika sty obyvateli. Muži nevelkého vzrůstu přes den nosí na svých hlavách velké divné klobouky - sombrera. Večer pak popíjejí po barech tequilu. Kolem toho moc neroste, kromě zelených kaktusů je typickou barvou okolí světle žlutá. Takové a další asociace se mi v mysli postupně vyplavovaly na povrch. Ačkoliv tohle je daleko od reálného modelu, jak lidé žijí v Mexiku, je to moje představa - můj mentální model. Lidé, co ten den poslouchali vyprávění mého známého o Mexiku, si podle vlastních zkušeností taktéž formovali vybrané koncepty a vztahy mezi nimi, jako jsem to dělal já. Vytvořili si tak svůj model, který použili pro zobrazení skutečnosti. Jelikož ve své práci budu porovnávat mentální modely s konceptuálním modelem aplikaci a hledat jejich rozdíly, moje notace pro jejich zápis bude stejná. Abych tyto odlišnosti viděl, i když nebudu mít zobrazené modely vedle sebe, ke konceptům, které jsou uživateli jinak chápány, budu přidávat poznámky, ve kterých zmíním závažnost problému a jak moc to ovlivnilo uživatelovo počínání při testu (viz obrázek 2.3).

Obrázek 2.3: Komentovat mentální modely uživatelů je užitečné. Pokud se k nim často vracíme, urychlí nám orientaci v modelu.

2.3

Návrh testu

V dnešní době se vývojáři snaží, co nejvíce vyjít vstříc uživateli. Chtějí, aby ihned po nainstalování a spuštění aplikace ji byli schopní využívat pro úkoly, ke kterým byla navržena. Častokrát se to bohužel příliš nepovede a učící křivka je delší než se původně čekalo. Uživatel tak spíše než používáním softwaru tráví čas bojem s uživatelským rozhraním a čtením manuálu a tutoriálů po internetu. Proto jsem se rozhodl testovat aplikaci, která v konkurenci co do počtu uživatelů ztrácí. K testu si pozvu uživatele konkurenčních programů a budu sledovat, jak se jim daří plnit úkoly, které jim nejsou cizí a které by ve svém programu zvládli udělat.

6

2.3.1


Výběr aplikace

Ačkoliv otestovat konceptuální model lze i u relativně jednoduchého systému (příklad s bankomaty, viz obrázky 2.1 a 2.2), proto abych mohl vyvodit z výsledků nějaké závěry, je rozumné, aby systém obsahoval spoustu informačních artefaktů (tj. entit) a vztahů mezi nimi. Při volbě malého systému bych také nemusel mít takové štěstí a rozdíly by nemusely být tak markantní, nebo v nejhorším případě by mentální modely účastníků testu mohly být shodné. Pokud jsem ke kritériím přiřadil navíc i dosažitelnost a početnost potencionálních účastníků testu, které jsem chtěl rekrutovat ze studentů Fakulty elektrotechnické, oboru Softwarových technologií a managementu, začal jsem s ohledem na moje zkušenosti převážně uvažovat mezi těmito čtyřmi aplikacemi - kancelářským balíkem Open Office, 3D modelovacím programem Blender, textovým editorem Vim a rastrovým editorem GIMP. 2.3.1.1

Open Office

Open Office je plnohodnotný kancelářský balík určený pro všechny nejrozšířenější platformy. Původně byl spravován a vyvíjen firmou Sun Microsystems. Po jejím odkoupení firmou Oracle odešlo z tohoto projektu několik předních vývojářů, ale i přesto vycházejí nové verze. Balík obsahuje kromě textového a tabulkového procesoru i prezentační nástroj, vektorový editor a nástroj pro vytváření matematických vzorců. Navíc je celý zdarma a je šířený jako svobodný software. Ačkoliv se jedná o poměrně dobře zvládnutý software, který je intuitivní a na domácí kancelářskou práci bez problémů postačí, ve světě na konkurenci ztrácí. Na 5-6 lidí, kteří používají jiný kancelářský balík, připadá právě jeden uživatel Open Office (viz [13] a [14]). Důvod, proč jsem se nerozhodl testovat tento program, je jeho přílišná podobnost s Microsoft Office. Program postrádá nějaký vlastní nápad, kterým by se od ostatních odlišil, a proto se jeho uživatel cítí, jako by pracoval v některé ze starších verzí konkurenčního balíku. Na druhou stranu je to také výhoda, uživatel může uplatnit postupy v obou balících a není nucen učit se novým postupům. Pro mé testování ale vhodný není, protože konceptuální modely obou balíků jsou do velké míry totožné. 2.3.1.2

Blender

Blender je pokročilý 3D grafický program určený pro tvorbu interaktivních 3D aplikací, her, animovaných filmů a vizuálních efektů. Stejně jako Open Office je zdarma a dostupný pro operační systémy Windows, Linux i Mac OS X. Uživatelské rozhraní Blenderu je orientováno pro efektivní práci. Skoro všechny funkce jsou přímo dostupné přes nějakou klávesovou zkratku. Ve verzích 2.3 a 2.4 to bylo dohnané do takových extrémů, že některé z funkcí byly dostupné pouze z klávesnice, takže v kontextovém menu byste je hledali marně. Tehdy získal Blender nálepku nesnadno ovladatelného programu, který vyžaduje po uživateli spoustu hodin strávených čtením manuálů a memorizováním klávesových zkratek. Nedávno po několikaletém vývoji vyšla verze 2.5, která již netrpí neduhy předešlých verzí.

2.3. NÁVRH TESTU

7

Ačkoliv se Blender se svým neotřele navrhnutým uživatelským rozhraním jevil jako dobrý kandidát, jako testovací aplikaci jsem jej nevybral. I když se poslední verze svým novým layoutem a ovládáním o něco přiblížila konkurenčním programům, stále je těžké s tímto programem začít pracovat bez předchozích zkušeností. 2.3.1.3

Vim

Vim je další z řady multiplatformních aplikací. Editovat textové soubory všeho druhu pomocí Vimu můžeme již 23 let. To je doba, která uplynula od prvního veřejného vydání tohoto editoru. Jeho spartánské uživatelské prostředí je stejně jako tomu bylo u Blenderu orientováno na maximální efektivitu. Základním principem editování ve Vimu je absence ovládání pomocí myši či kontextových menu. Veškerá interakce je zprostředkována velkým množstvím zkratek a skrz několik režimů práce, které začínajícím uživatelům činí nemalé potíže. I přes to, že z dnešního pohledu dle některých heuristických měřítek, bychom mohli nabýt dojmu, že uživatelské rozhraní Vimu je špatně navržené, těší se tento editor veliké oblibě zejména mezi administrátory a zkušenými uživateli operačních systémů unixového typu. Jelikož je Vim stále pevnou součástí unixových distribucí, věřím, že ani noví administrátoři se bez základní znalosti tohoto editoru neobejdou. Program Vim jsem si jako testovanou aplikaci nevybral z důvodů podobných, které jsem vyjmenoval u Blenderu. Navíc je tento editor v základu poměrně chudý. Mocným IDE se stává až díky rozšířením a přizpůsobením jeho konfigurace na míru uživateli. 2.3.1.4

GIMP

Aplikace GIMP je rastrový editor dostupný pod GPL licencí. Je dostupný pro všechny nejrozšířenější platformy – Windows, Mac OS, Linux. Mezi jeho hlavní přednosti patří dostupnost velkého množství pluginů a skriptů, nízké hardwarové nároky a v neposlední řadě také podpora velkého množství formátů, včetně PSD formátu z programu Adobe Photoshop. Co je však některými uživateli vyčítáno, je uživatelské rozhraní, které je rozděleno do několika na sobě relativně nezávislých oken. Zejména uživatelé starších Windows, kteří nemohou vyhradit GIMPu samostatnou pracovní plochu se mohou ztratit ve změti oken způsobenou právě tímto grafickým editorem. Jinak ale GIMP je plnohodnotný grafický editor, který se zejména funkcionalitou vyrovná konkurenčním programům. Navrch pak přidává některé vektorové funkce, které mohou být využívány jako užitečné pomůcky při vytváření nebo úpravě rastrové grafiky. Na druhou stranu ho shazují četné chyby v aplikaci, nedořešené ovládání nebo chybějící základní funkce, jako je například označení více vrstev najednou nebo kreslení primitiv (obdélníků a elips). Nepěkně taktéž působí tutoriál(viz [9], nacházející se na oficiálních stránkách aplikace, o tom, jak vytvořit rovnou čáru v GIMPu. Jeden by se domníval, že takto důležitou funkci bude mít na starost některý z nástrojů, ale v GIMPu je poněkud nešťastně rovné čáry dosaženo vybráním jednoho z vhodných nástrojů a stiskem dvou klávesových zkratek najednou. Pro mé potřeby je aplikace GIMP ideální pro testování. Je to takový kompromis mezi Open Office a Blenderem. Na jednu stranu GIMP není složitý na naučení natolik, aby se uživatel nedokázal sžít s programem během několika desítek minut. Na straně druhé uživatelské

8


prostředí GIMPU je natolik neortodoxní a některé koncepty natolik „originální“, že bychom je v jiných rastrových editorech hledali marně. Na problematičnost uživatelského rozhraní tohoto rastrového editoru mě nechtěně upozornil můj cvičící předmětu Multimédia 1. V rámci předmětu jsem dostal za úkol vytvořit interaktivní aplikaci pro prostředí CAVE. CAVE je poměrně velké a drahé zařízení čítající několik počítačů a zpravidla 4 nebo 6 projektorů, které dohromady vytváří imersivní virtuální realitu (viz [12]). Nebylo mi jasné, jakým způsobem mezi sebou počítače komunikují a jak se to realizuje v OpenGL aplikaci, a proto jsem se šel zeptat mého cvičícího. Ten mi to vše jasně a stručně vysvětlil, nicméně viděl, že jsem toho z jeho vyprávění moc nepochopil. Řekl si, že názorná grafická ukázka by mohla vnést více jasu do této problematiky. Po ruce byl počítač s operačním systémem Linux, kde byl předinstalovaný GIMP. Cvičící ho spustil a chystal se nakreslit mi jednotlivé počítače jako čtverečky, které pak chtěl propojit mezi sebou a označit data, která si mezi sebou vyměňují. Vzal tedy z panelu něco, co vypadalo jako kreslení obdélníků a nakreslil tím jeden obdélník. K našemu překvapení se obdélník nenakreslil. Mysleli jsme si, že tam ten obdélník je, je ale pouze bílý. Vybrali jsme proto barvu a zkusili nakreslit obdélník znovu, ale bez úspěchu. Po chvilce jsme zjistili, že nástroj slouží pouze k vybírání obdélníkové oblasti a proto jsme se vydali hledat do různých kontextových menu a panelů s nástroji něco, čím bychom něco podobné obdélníkům mohli nakreslit. Když jsme ani po několika minutách nepřišli na to, jak se obdélník nakreslí, otevřeli jsme radši vektorový editor Inkscape, kde už vše bylo, tak jak má být.

2.3.2

Výběr cílové skupiny

Jak jsem již naznačil, rozhodl jsem se testovat uživatele, kteří pracují s 2D rastrovou grafikou, ale používají jiný editor než právě GIMP. Cílem účastníka testování bude vypracovat celkem 3 úkoly, které pokrývají použití převážné většiny funkcí, kterými by měl každý rastrový editor disponovat. Funkce, které bude potřeba použít, budou specifikované ve Screeneru a pro to, aby byl účastník vybrán k testu, musí převážnou část přesně definovaných funkcí znát a zvládat používat v jednom z konkurenčních editorů. Ve vybrané cílové skupině se chci vyvarovat uživatelům, kteří v GIMPu třeba i pracovali, ale nepoužívají ho. Těm by nástrahy GIMPu byly známé, a proto by rozdíl ve výsledcích testování oproti „GIMP-amatérům“ byl markantní. To zohledním ve Screeneru, kde člen cílové skupiny musí zaškrtnout malý počet funkcí, které kdy použil v aplikaci GIMP. Ačkoliv jsem se při vytváření testu v ovládání programu GIMP zdokonalil, zdaleka se nepovažuji za experta. Při vytváření konceptuálního modelu bych pak některé koncepty v uživatelském rozhraní mohl lehce přehlédnout, nebo je špatně pochopit. Proto si k testu pro tvorbu konceptuálního modelu přizvu jednoho „GIMP-experta“, s kterým během testu vylepším mnou vytvořený konceptuální model aplikace. Tento expert pracuje při vytváření a editování 2D rastrové grafiky pracuje právě v této aplikaci. Z přesně dané množiny funkcí ovládá převážnou většinu a umí je použít v testované aplikaci. Má cílová skupina se tedy skládá ze dvou odlišných uživatelských skupin: 1. 2D grafici, kteří v GIMPu začínají - 6 uživatelů

2.3. NÁVRH TESTU

9

2. 2D grafici, kteří GIMP ovládají - 1 uživatel

2.3.3

Přehled případů užití - Use Cases

Při výběru jednotlivých úkolů jsem lpěl na několika kritériích. Na jednu stranu jsem chtěl, aby úkoly nebyly příliš složité a dávaly alespoň trochu smysl, tj. že se nebude jednat o uměle vytvořené úkoly. Zároveň jsem chtěl, aby uživatel využil co nejvíce funkcí a nástrojů - tedy aby objevil, co nejvíce konceptů. Nechtěl jsem ale používat speciální funkce GIMPu, které příliš nenajdete v jiných rastrových editorech a byla by tu tedy šance, že by uživatel nevěděl, co se po něm žádá. Dále jsem chtěl, aby test u počítače nebyl kratší než 20 minut a zároveň, aby nikdo nebojoval s uživatelským prostředím déle než 60 minut. S tímhle na paměti jsem vytvořil následující tři případy užití. 1. Vytvoření turnajového pavouka (viz obrázek 2.4) (a) Vstupní podmínky: Čerstvě nainstalovaný program. Otevřený prázdný soubor v rozlišení 640 x 480 px. (b) Instrukce: Uživatel bude požádán, aby vytvořil jednoduchého turnajového pavouka. K instrukcím dostane také ukázku, jak by měl výsledný obrázek vypadat. Tento UC má za úkol seznámit uživatele s aplikací a „zahřát“ ho na provozní teplotu. Při jeho plnění zjistí, že se v GIMPu nedají kreslit primitivní objekty, jako tomu je v jiných editorech. Bude proto muset využít nástrojů výběru a plechovky. Při vytváření rovné čáry očekávám, že opět narazí, neboť se v aplikaci nenachází nástroj, který v základním režimu kreslí rovně. Metodou pokus-omyl nebo, pokud si všimne stavového řádku s nápovědou, zjistí, jak nakreslit na sebe kolmé rovné čáry. Při volbě barev nechám uživateli volnou ruku, jediná podmínka je, aby barva rámečku byla odlišná od barvy výplně. (c) Poznámka: Ukázalo se, že tento případ použití je těžší, než se zdál. V průměru s ním účastníci testu zápasili skoro polovinu času (kolem 20-25 minut). Někteří nebyli schopni tento Use Case dokončit.

Obrázek 2.4: Ukázka výsledného turnajového pavouka

2. Úprava barev fotografie a aplikace filtrů (viz obrázek 2.5) (a) Vstupní podmínky: Čerstvě nainstalovaný program, otevřený soubor s fotkou k úpravě.

10


(b) Instrukce: Uživatel dostane za úkol vylepšit fotku, která byla nekvalitně pořízena. Fotka bude obsahovat klasické chyby, které produkují levné kompaktní fotoaparáty – postava s červenýma očima, mdlé barvy, rozmazané pohybující se objekty. Zpočátku uživatel nedostane žádné instrukce, co se chyb ve fotce týče, pokud si ale bude myslet, že je hotov, ale na fotce budou stále výše zmíněné artefakty, bude na ně upozorněn. V tomto Use Casu uživatel využije další sadu nástrojů. Nejprve bude muset provést výběr nepravidelné oblasti ve fotce, té bude aplikovat některý z filtrů. GIMP jich obsahuje poměrně velké množství, jsou však dobře rozumně uspořádány do jednotlivých skupin dostupných z horního menu. Dále si bude muset pohrát s nastavením barevnosti fotky, které je ale koncipováno jako u konkurenčních editorů, a proto si nemyslím, že by mělo činit uživateli nějaké potíže. (c) Poznámka: Po prvním složitém úkolu většina účastníků ztratila víru v GIMP. Proto se někdy až divila, jak snadno se tento úkol dal splnit. Nanejvýš uživatelé potřebovali 10 minut pro dokončení tohoto případu použití.

Obrázek 2.5: Fotka určená k úpravě

3. Vytvoření koláže z několika referenčních obrázků (viz obrázek 2.6) (a) Vstupní podmínky: Čerstvě nainstalovaný program, otevřená složka se třemi referenčními obrázky. (b) Instrukce: Účastník dostane 3 obrázky a bude mít za úkol vytvořit koláž, která se co nejvíce bude podobat předloze. Procvičí si tak používání nástrojů pro trans-

2.3. NÁVRH TESTU

11

formaci vrstev. Dále bude požádán, aby retušoval část obrázku. Přitom použije nástroj klonování. (c) Poznámka: Jediná věc, s čím účastníci testu mohou mít problém je, že například uživatelé Adobe Photoshop mohou být zvyklý na to, že všechny transformace provádějí jediným nástrojem. V GIMPu existuje zvlášť 6 nástrojů - posun, rotace, převrácení, naklonění a perspektiva. Dále jsou poměrně neintuitivně zpracovány vrstvy. V aplikaci není možné označit dvě a více vrstev a provádět v nich úpravy. Navíc, dokud nedojde k ukotvení právě vložené vrstvy z paměti (CTRL + V), není možné měnit uspořádání vrstev, ani není možné editovat jiné vrstvy. Toto omezení navíc není uživateli nijak graficky zvýrazněno (například „zšednutí“ ostatních vrstev by bylo přijatelné).

Obrázek 2.6: Výsledná koláž

2.3.4

Screener

Screener bude koncipován do 5 otázek. U každé otázky je v závorce stanovený target (údaj v závorce samozřejmě není součást dotazníku, viz příloha D), který určí, zda uživatel s danou odpovědí vyhověl, či nikoliv. 1. Používáte nějaký pokročilý grafický editor například pro úpravu fotek nebo kreslení? (a) Ano (vyhovuje) (b) Ne (nevyhovuje) 2. Jaké grafické editory používáte* ? (povoleno zaškrtnout více možností, editory očíslujte podle preferencí - editor co používáte nejčastěji 1, druhý nejpoužívanější 2, atd.)

12


(a) GIMP (max. 1-2, co napíší GIMP na první místo) (b) Adobe Photoshop (vyhovuje) (c) Adobe Illustrator (d) Adobe Indesign (e) Inkscape (f) Jiný vektorový editor (g) Jiný rastrový editor (vyhovuje) 3. Kdy jste naposledy pracoval s nějakým grafickým editorem? (a) Dnes nebo včera (vyhověl) (b) Maximálně před týdnem (vyhověl) (c) Maximálně před měsícem (vyhověl) (d) Déle než před měsícem (nevyhověl) 4. Které funkce jste ve Vámi preferovaném editoru již použil? ** (Zaškrtněte libovolné množství odpovědí) (a) Maska (výběr z obrázku) (b) Kreslení primitiv (obdélníky, elipsy) (c) Úprava barev fotky (d) Odstranění červených očí (nebo jiná retuše) z fotky (e) Práce s vrstvami (vytvoření/vymazání vrstvy v obrázku) (f) Změna perspektivy obrázku/fotky (g) Ořez obrázku (h) Převzorkování obrázku (změna velikosti plátna) 5. Které funkce jste již použil v editoru GIMP? *** (Zaškrtněte libovolné množství odpovědí) (a) Maska (výběr z obrázku) (b) Kreslení primitiv (obdélníky, elipsy) (c) Úprava barev fotky (d) Odstranění červených očí (nebo jiná retuše) z fotky (e) Práce s vrstvami (vytvoření/vymazání vrstvy v obrázku) (f) Změna perspektivy obrázku/fotky (g) Ořez obrázku (h) Převzorkování obrázku (změna velikosti plátna) * Uživatel musí označit alespoň jeden rastrový editor, aby vyhověl. ** Uživatel musí zaškrtnout alespoň 6 z 8 odpovědí, aby splnil stanovený target. *** 1 Expert musí zaškrtnout alespoň 6 z 8 odpovědí, 6 dalších lidí nanejvýše 2 odpovědi

Kapitola 3

Postup při testování Před započetím samotného testování s uživateli provedu tzv. „pilot test“, který má za cíl odhalit nedostatky v nastavení testu. Pomůže mi opravit takové chyby jako například přílišná náročnost úloh nebo nepřesné zadání (viz [4], kapitola 10). Dále si vyzkouším, jak bude časově náročné zároveň moderovat test a zapisovat si poznámky ohledně mentálního modelu uživatele. Jelikož v cílové skupině jsou zástupci dvou naprosto rozdílných uživatelů, bude test s každou skupinou probíhat odlišně.

3.1

Postup při testování s experty

K testování si nejprve pozvu jednoho experta přes aplikaci GIMP. Předtím, než mu dám zadání testu, seznámím ho s protokolem a vyzpovídám ho v pre-test interview. Úkolem tohoto testování, bude vytvoření mentálních modelů pokročilého uživatele programu GIMP a zároveň rozšíření mého stávajícího konceptuálního modelu. Jelikož pracují s GIMPem delší dobu, tak očekávám, že jejich mentální model bude velice podobný konceptuálnímu modelu aplikace. Nejprve je seznámím s pravidly testu - s „protokolem“.

3.1.1

Protokol

Před samotným interview expertovi připomenu, že ačkoliv je na „testu“, on není tím, který je testován, ale je tu od toho, aby mi pomohl odhalit ty části systému, které mohou být matoucí nebo chybně navržené. Zdůrazním mu, že pokud mu nějaký úkol nepůjde splnit, tak to určitě není jeho chyba. Požádám ho, že k provedení testu budu potřebovat, aby mi sděloval, co si zrovna myslí a co se snaží zrovna udělat. Pokud ho však bude obtěžovat říkat myšlenky nahlas (bude ho to rozptylovat, bude mít problém s koncentrací na UC), nemusí tak činit, ale bude muset počítat s tím, že ho při jeho práci často budu přerušovat (po každém hotovém podúkolu) a ptát se, co zamýšlel poslední akcí, co očekával od zběsilého klikání pravým tlačítkem myši na právě nakreslený čtverec, apod. Dále mu sdělím, že ačkoliv při testu budu vedle něho sedět, nejsem tam od toho, abych mu radil. Moje úloha bude spočívat v pozorování uživatele při práci s grafickým uživatelským

13

14

KAPITOLA 3. POSTUP PŘI TESTOVÁNÍ

rozhraním GIMPu. On mě tudíž klidně může ignorovat a může se plně soustředit na úkoly a na „think-aloud“ protokol (anglické označení pro vyjadřování myšlenek nahlas). Jelikož se jedná o zkušeného uživatele GIMPu, grafické rozhraní aplikace mu nebudu představovat. Pouze pokud by z nějakého důvodu pracoval v jiné (například starší) verzi, která by byla odlišná od té, která ho za chvíli čeká u testu, tak bych ho v rychlosti provedl po GUI.

3.1.2

Pre-test interview

Poté, co byl participant seznámen s protokolem, přistoupím k předtestovému pohovoru. Ten začnu tzv. „warm up“ otázkami. Ty mají za úkol odpoutat myšlenky účastníka z jeho života. Dále mají za cíl, aby se participant začal soustředit na test a také, aby si zvykl na to, že bude muset odpovídat na mé otázky. Pro tento účel se nejlépe hodí otázky s otevřeným koncem. 1. K čemu editor používáte? 2. Jak dlouho obvykle trvá jedno použití editoru? 3. Proč preferujete GIMP nad konkurenčními editory? Nyní přejdu k hlavní části pohovoru. Účastníkovi ukážu zadání jednotlivých úkolů, které za chvíli bude plnit u počítače, a budu po něm chtít přibližný nástin toho, jak by postupoval. Z jeho odpovědí se budu snažit získat koncepty a vztahy mezi nimi. Z těchto poznámek po skončení testu vytvořím jeden (z celkem dvou) mentální model. Oproti druhému mentálnímu modelu z testu u počítače, nebude tak podrobný, ale měl by zachytit hlavní myšlenkový postup participanta. V případě, že odpovědi účastníka nebudou dostatečně konkrétní, budu jeho výklad doplňovat dalšími otázkami. Příklad: • Účastník: „. . . a takto vzniklé obdélníky pak spojím.“ • Já: „Na referenčním obrázku jsou obdélníky spojeny rovnou čarou. Jak docílíte toho, že čára bude rovná?“ • Účastník: „Vyberu nástroj tužka a s pomocí klávesové zkratky Ctrl + Shift je spojím.“ Ačkoliv jsou jednotlivé úkoly z reálného života, může se stát, že si s nimi účastník nebude vědět rady - nebude vědět, jak je v editoru udělat (popřípadě si je nebude schopen z paměti vybavit). Příklad: • Účastník: „Nevím, jak bych odstranil červené oči z fotky.“ • Já: „Tak si představte, že navrhujete váš grafický editor. V současné době laciných kompaktních fotoaparátů je funkce pro odstranění červených očí téměř nepostradatelná. Jak byste ji do svého editoru zakomponoval?“ • Účastník: „Asi by tam byla v nástrojích funkce pro odstranění červených očí. Na to se klikne a z fotky pak zmizí červené oči.“

3.1. POSTUP PŘI TESTOVÁNÍ S EXPERTY

3.1.3

15

Nastavení testu

Test bude probíhat na desktopovém počítači s nainstalovanými Windows XP. GIMP bude předinstalovaný v nejnovější dostupné verzi - 2.6.11. Nebude obsahovat žádné doplňky, které by nebyly součástí standardní instalace. Rozlišení obrazovky bude 1680 x 1050 px. Zadání a podklady dostane účastník předtištěné na papíře. Dále mu ukáži, kde se nachází soubory potřebné pro jednotlivé use-casy. Výsledek své práce pak uloží ve ztrátovém formátu JPG. Na zadání bude opět v bodech zmíněn protokol testu (viz sekce 3.1.1). Při testu budu jako moderátor přítomný vedle participanta. Z účastníkova počínání si budu vytvářet jeho mentální model - na papír si budu zaznamenávat jména entit, jejich atributy a vztahy mezi nimi v jeho modelu. Bude to časově náročná práce - po každém kroku aktualizovat jeho model, a proto budu účastníka často přerušovat a v případě nejasností jeho akcí se i vyptávat, co tím, či oním kliknutím zamýšlel. Jelikož je participant pokročilým uživatelem GIMPu a splnění úkolů mu bude trvat kratší dobu oproti začátečníkům, bude požádán, aby se pokusil splnit úkol všemi možnými způsoby, které zná. Pomůže mi tak odhalit možné koncepty, které jsem přehlédl při připravování konceptuálního modelu aplikace. Ačkoliv při testu budu přítomen, nebudu tam od toho, abych mu jakkoliv radil. Pokud se uživatel zasekne (nebude vědět jak dokončit úkol, resp. podúkol), budu mu klást další doplňující otázky, neboť právě tady budou největší rozdíly mezi konceptuálním modelem aplikace a jeho mentálním modelem. Příklad: • Účastník: „Nevím, jak mám obdélníky spojit rovnou čarou.“ • Já: „Jak byste očekával, že je půjde spojit?“ • Účastník: „Asi by v programu byl nástroj pro tvorbu rovných čar - úseček. Ale nic takového v editoru není.“ • Já: „Dobře. Pokud si myslíte, že v programu není jiná možnost, jak je spojit, přejděte prosím k dalšímu úkolu.“

3.1.4

Nahrávání obrazovky a pořízení zvukového záznamu

Při vytváření mentálních modelů je důležité, jak účastník pojmenovává koncepty a jak nazývá vztahy mezi nimi. Jelikož budu při testu zaneprázdněný upravováním mentálního modelu a psaním poznámek, aby mi tyto detaily neutekly, tak zároveň provedu screencapturing obrazovky a nahrávání zvukového záznamu z testu pomocí programu Camtasia. Camtasia Studio (viz [6]) je vyspělý software umožňující mimo nahrávání děje na obrazovce i zaznamenávání zvuku z mikrofonu nebo z reproduktorů. Dále je možné nahrávat záznam z webkamery. Nahráváním videa ale Camtasia nekončí. Součástí aplikace je i kvalitní střihové video, kdy můžeme editovat časovou osu, přidávat anotace a měnit zoom kamery (viz obrázek 3.1). Soubory jsou uloženy v proprietárním formátu, který videa velice dobře bezeztrátově komprimuje. Pro ilustraci, při nahrávání 1 hodiny při rozlišení 1680 x 1050 program generoval zhruba 500 MB soubory. Samozřejmě nechybí možnost exportovat video do běžných video formátů, aby šlo přehrát záznam i na počítačích, na kterých není nainstalovaný tento program.

16


Jedinou nevýhodou této aplikace je její cena. Je možné ale tento program bezplatně používat po dobu 30 dnů, čehož jsem já využil.

Obrázek 3.1: Uživatelské rozhraní programu Camtasia. Na první pohled vypadá složitě, ale člověk se s ní rychle sžije.

Ačkoliv Camtasia běžela pouze na pozadí testu, sehrála nakonec důležitou roli při zpracování výsledků a vytváření mentálních modelů. Častokrát se mi stalo, že zatímco jsem si zapisoval jeden koncept do svých poznámek, další koncept mi zrovna utekl. Mít možnost znovu si v klidu projít kompletní test i se zvukovým záznamem bylo k nezaplacení.

3.1.5

Post-test interview

Na potestovém pohovoru si projdu s participantem jeho výsledné JPEG obrázky, které pořídil při testu. Zeptám se ho na moje nesrovnalosti, které mám ve svých poznámkách (v jeho modelu) z průběhu testu. Pokud se mi stane, že účastník při testu málo mluvil a já budu mít pocit, že jsem zachytil málo konceptů, nechám ho podobně jako v pre-testovém interview převyprávět, jak jednotlivé úkoly v GIMPu udělal. Potom mu poděkuji za spolupráci a rozloučím se s ním.

3.2. POSTUP PŘI TESTOVÁNÍ SE ZAČÁTEČNÍKY

3.2

17

Postup při testování se začátečníky

Po provedení pilot testu a testu s experty si pozvu 5-6 členů mé cílové skupiny a provedu s nimi uživatelský test. Úkolem tohoto testování bude vytvořit reprezentaci mentálních modelů uživatelů, kteří v GIMPu skoro nikdy nedělali (viz výběr cílové skupiny 2.3.2). Na druhé straně ale očekávám, že by tito uživatelé byli schopni splnit úkoly v testu v jejich preferovaném editoru (tj. že to jsou zkušení uživatelé konkurenčních editorů). Dříve než se s nimi pustím do testu, seznámím je s protokolem.

3.2.1

Protokol

Protokol pro test se začátečníky je téměř ve všech bodech schodný s protokolem pro testování s experty. Jediný rozdíl mezi nimi je ten, že ačkoliv není nutné nijak představovat interface GIMPu jeho zkušeným uživatelům (neboť toho pravděpodobně vědí více než já a akorát bych je nudil), u uživatelů, kteří s ním nepřišli skoro nikdy do styku, je žádoucí vysvětlit jim v několika bodech, k čemu aplikace slouží. Popíši jim grafické rozhraní a jednotlivé panely programu. Dále jim ukážu základní úkony s aplikací - otevření souboru ze složky skrz kontextové menu, uložení souboru a změna jména, volba formátu a nastavení JPEG komprese.

3.2.2

Pre-test interview

Pre-test interview proběhne stejně jako v sekci 3.1.2, s jediným rozdílem, že se ve třetí „warm up“ otázce, účastníka zeptám, proč preferuje jeho stávající editor nad ostatními. Jelikož ale uběhla nějaká doba od momentu, kdy jsem účastníkovi předložil screener, zeptám se ho, jestli se od té doby něco nezměnilo. Zde bych chtěl zejména odchytit ty uživatele, kteří byli z nějakého důvodu natolik nervózní před testem, že si například nainstalovali GIMP a zkoušeli si v něm funkce zmíněné v otázkách 4 a 5 ze screeneru. S takovými účastníky bych nemohl pokračovat v testu dále. Pokud je vše v pořádku, zeptám se ho, stejně jako experta, jak by postupoval v jeho preferovaném editoru při plnění jednotlivých případů použití. Poznámky z interview pak pro proběhnutí testu zpracuji a vytvořím mentální model uživatele před testem.

3.2.3

Nastavení testu

Na rozdíl od experta, který má za úkol najít všechny možnosti ke splnění UCs, u začátečníka mi bude stačit pouze jeden. Jinak nastavení testu bude stejné jak pro experta, tak pro začátečníka (viz sekce 3.1.3).

3.2.4

Post-test interview

Očekávám, že test se začátečníkem bude trvat mnohem déle než test s expertem. Je tu tedy i větší riziko, že by účastník mohl být nějakým způsobem z testu frustrován, nebo dokonce by nabyl dojmu, že nijak nepomohl. Proto mu poděkuji za jeho čas a sdělím mu, že ačkoliv se mu nepříliš dařilo plnit jednotlivé úkoly, mně naopak velice pomohl, neboť o to jednodušší pak

18


budu mít prácí při identifikování odlišností mezi jeho mentálním modelem a konceptuálním modelem aplikace. Jinak i post-test pohovor bude probíhat stejně jako při testu s expertem (sekce 3.1.5).

Kapitola 4

Provedení a zpracování testu Po návrhu a vytvoření podkladů pro test jsem se mohl pustit do provedení testu. Ještě před vybráním konkrétních osob si připravím konceptuální model aplikace. Při testu pak budu vědět, na co se mám při zápisu informací z pozorování uživatele zaměřit. K zaznamenávání použiji aplikaci Enterprise Architect, kde pro moje potřeby postačí strukturální UML diagram tříd.

4.1

Vytvoření konceptuální modelu aplikace

V modelu používám 3 základní konstrukty - entity, atributy a vztahy mezi entitami. Entita je nějaký objekt, který se nachází v oblasti mého zájmu a který nese nějakou informaci. Bližší popis konceptů mi je umožněn pomocí relací mezi jednotlivými třídami entit. Třída entit obvykle obsahuje několik výskytů (instancí), které jsou mezi sebou rozlišitelné pomocí vlastností - atributů.

Obrázek 4.1: Příklad tříd entit. Jednotlivé instance v systému se dají odlišit pomocí atributů.

Na obrázku 4.1 vidíme příklad entit z grafického editoru GIMP. V programu se nachází množina nástrojů, které uživatel používá při tvorbě grafiky. Nástroj se obvykle nějak jmenuje a je reprezentován v panelu nástrojů ikonkou, čímž se nabízí, že by právě tyto dvě vlastnosti mohly být atributy této entity. Problém však nastává v okamžiku, kdy se budeme snažit naznačit vztahy mezi jednotlivými entitami. V editoru GIMP se například nachází nástroj Lupa, který umožňuje přiblížení celého obrázku. V modelu tedy budu mít vztah mezi nástrojem a obrázkem. To znamená, že

19

20

KAPITOLA 4. PROVEDENÍ A ZPRACOVÁNÍ TESTU

všechny instance této entity také musí mít daný vztah, což ale záhy zjistím, že není pravda. Stačí se podívat na jiný nástroj - například na Štětec. Po chvilce zkoušení v programu zjišťujeme, že zatímco lupa manipuluje s celým obrázkem, štětec kreslí pouze do uživatelem vybrané části obrázku (vybraným například nástrojem Laso, Výběr elipsou, apod.). Odhalili jsme tedy další entitu - Výběr, ale zároveň jsme zjistili, že náš původní odhad nebyl správný a proto musíme do modelu přidat nový konstrukt - podtypy. Podtyp blíže specifikuje nadtyp - v našem případě Lupa je podtypem Nástroje.

Obrázek 4.2: Znázornění podtypů v modelu a vztahu s entitami.

Na obrázku 4.2 vidíme další verzi našeho modelu. Po bližším prozkoumání nástrojů editoru GIMP, které jsou k dispozici uživateli, ale zjistíme, že existuje více nástrojů, které podobně jako štětec pracují výhradně s právě označeným výběrem. Je proto vhodné dále tyto entity členit podle společných atributů a vztahů. Pak bychom mohli najít entitu Kreslicí nástroje, která by pod sebe seskupila podtypy, u kterých si uživatel může zvolit typ stopy a barvu. Zástupci podtypů této entity budou v našem případě Štětec, Tužka, Plechovka a Guma. Při vytváření podtypů si ale musíme dávat pozor. Na jedné straně pokud náš model bude příliš obecný, nebudeme pak moci pozorovat rozdíly mezi modelem uživatele a aplikace kvůli chybějícím konceptům v modelu, protože na této úrovni abstrakce budou podobné, ačkoliv se ve skutečnosti mohou velice lišit (viz obrázek 4.1, kde jsme nemohli znázornit vztah mezi štětcem a výběrem). Na druhé straně, pokud najdeme příliš mnoho podtypů, náš model bude natolik rozsáhlý, že se v něm nebudeme moci vyznat. Proto je nutné si při vytváření podtypů dávat pozor. Obecné pravidlo říká, že pokud podtyp nemá žádný atribut ani vztah navíc oproti nadtypu je nutné zvážit, jestli by se měl v modelu vyskytovat nebo ne. Občas můžeme mít dilema, jestli je daný koncept ještě atributem nebo už entitou. Na obrázku 4.2 vidíme, že dvě entity mají atribut rozměr. Nabízelo by se vytvořit novou entitu

4.1. VYTVOŘENÍ KONCEPTUÁLNÍ MODELU APLIKACE

21

Rozměr, která by měla atributy šířka a délka a měla by vztah s výše zmíněnými entitami. Zde je podobně jako u podtypů se potřeba zamyslet nad tím, jestli nám takové zobrazení pomůže při hledání rozdílů mezi modely, nebo to pouze zhorší čitelnost grafu. V tomhle případě jsem zůstal pouze u atributů, neboť uživatelé neměli problémy při nastavování rozměrů obrázku, respektive výběru.

Obrázek 4.3: Příklad modelu, kde jsou pojmenované vztahy a určené jejich kardinality a parciality. Pro lepší čitelnost se do modelů přidávají jména vztahů mezi entitami a jejich kardinalita a parcialita. Na obrázku 4.3 vidíme, že ačkoliv z entity Obrázek můžeme provést mnoho různých výběrů, v jednom výběru budou pouze části jednoho obrázku. Sice je možné mít v aplikaci GIMP paralelně otevřeno více obrázků, není možné ale vytvořit výběr, který by se skládal z částí dvou a více obrázků. Tuto informaci získanou popisem vztahů pak použiju pro nalezení dalších rozdílů mezi modely, které jsem bez toho nebyl schopen rozlišit. S výše zmíněným omezením ve vztahu „Výběr - Obrázek“ nikdo z uživatelů, co jsem testoval, problém neměl, ale problém měli s omezením, které se týká manipulace s vrstvami (což je další entita). V konkurenčních editorech jsme zvyklý, že můžeme zároveň pracovat s více vrstvami najednou. Ať už jde o jejich přesouvání v seznamu vrstev nebo o aplikaci transformací na více vrstev najednou, intuitivně čekáme, že vrstvy budeme moci pomocí myši a klávesy Shift vybrat a nebudeme muset opakovat stejný sled akcí pro každou vrstvu zvlášť. V GIMPu se více vrstev vybírá pomocí tlačítka s ikonkou řetězu, který je v seznamu vedle každé vrstvy (viz 4.4). Po zatrhnutí je ale možné s vrstvami pouze provádět transformace - přesun, změna měřítka a perspektivy. Pokud budeme chtít některé z vrstev dát dále do pozadí, budeme je muset jednotlivě označit a zvlášť „odklikat“ na požadované místo. Avšak kvůli špatně zvolené ikonce (řetěz evokuje pocit uzamčení) a výskytu slova „Zamknout“ v blízkosti této ikonky

22


Obrázek 4.4: Vybrání více vrstev v GIMPu je možné pouze pomocí ikonky s řetězem, které se nachází vedle každé vrstvy.

měla za následek, že nikdo ze 7 testovaných (včetně experta) neodhalil tuto funkcionalitu. Proto, když chtěli odsunout text v jedné vrstvě a obdélník v druhé vrstvě na jiné místo v dokumentu, museli provést přesun pomocí nástroje dvakrát a pak ručně odhadnout jejich relativní pozici (vycentrovat text do čtverečku). Po dotazu, co si myslí o významu této ikonky mi všichni účastníci testu odpověděli, že slouží pro zamčení vrstvy, aby se pak s ní nemohli dělat žádné nechtěné úpravy. Při vytváření modelu jsem prošel zadání testu a snažil jsem se splnit zadané UCs všemi možnými způsoby, abych odhalil co nejvíce konceptů. Zejména jsem se snažil rozpracovat do detailů ty záležitosti, kde jsem tušil, že budou pro uživatele problematické (viz výše příklad s vrstvami). Naopak u částí systému, kde jsem si myslel, že uživatelé nebudou mít problémy, jsem již tak konkrétní nebyl a v zájmu čitelnosti modelu jsem se snažil šetřit podtypy a vztahy mezi entitami.

4.2

Testované osoby

Zástupce mé cílové skupiny jsem hledal zejména mezi studenty na ČVUT, o kterých jsem věděl, že v rámci svého studia a ve svém volném čase využívají některé z grafických editorů. Otestoval jsem celkem 7 osob, z toho 6 lidí v GIMPu buď nikdy nedělalo, nebo uměli používat

4.2. TESTOVANÉ OSOBY

23

pouze malou část jasně definovaných funkcí zmíněných ve screeneru (viz sekce 2.3.4). Sedmý účastník byl můj „GIMP-expert“. Všech sedm osob jsem otestoval rozmezí 10 dnů. Jelikož celý test včetně obou pohovorů se svojí dobou trvání blížil 90 minutám, v jeden den jsem otestoval maximálně jednoho účastníka.

4.2.1

Osoba 1

S mým prvním účastníkem jsem provedl pilot test. Dle screeneru a pretest interview nepatří k častým uživatelům rastrových editorů. Používá hlavně nástroje pro tvorbu prezentací a vektorové grafiky. Kromě odstranění červených očí a změny perspektivy obrázku ale umí použít všechny ostatní funkce definované ve screeneru. GIMP použil pouze pro ořez fotky, ostatní funkce nikdy nepotřeboval. Při testu byl několikrát zaskočen chováním GIMPu, a proto jsem mu musel několikrát poradit, neboť nevěděl, jak splnit Use case. Zejména ho zaskočilo chování vrstev, které se dle účastníka vůbec nechová tak, jak je zvyklý z jiných editorů.

4.2.2

Osoba 2

Jako druhého jsem si k testu pozval „GIMP-experta“. Ačkoliv uvádí, že GIMP používá často, na první místo nejpoužívanějšího editoru uvedl aplikaci Adobe Photoshop. Testování s ním byla o něco uvolněnější než s ostatními účastníky. Dobře se orientoval v uživatelském rozhraní a odhalil spoustu nových konceptů, kterých jsem si při vytváření konceptuálního modelu nevšiml. Jedním z nich je například miniaturní řádek s nápovědou pod obrázkem, která radí uživateli jak používat právě vybraný nástroj. Nápověda se chová velice inteligentně, pokud máte například vybraný štětec a chystáte se něco nakreslit, automaticky vám radí, jaké klávesové zkratky jsou k dispozici a jak ovlivňují chování nástroje.

4.2.3

Osoba 3

Třetí účastník testu je uživatel rastrových a vektorových programů od firmy Adobe. GIMP zkusil pouze zvědavosti, ale po chvíli snažení to ihned vzdal, takže před testem měl pouze velmi málo zkušeností. Mimo obvyklých problémů, které měla většina účastníků (absence nástrojů pro tvorbu primitiv, nemožnost manipulovat s objekty, apod. viz sekce 4.5), byl překvapen, že v programu není možnost jedním nástrojem zároveň provádět více transformací najednou (rotace, posun, škálování a změna perspektivy), místo toho tu je několik nástrojů, které jsou určeny pouze pro jednu operaci.

4.2.4

Osoba 4

I čtvrtý účastník byl uživatel Photoshopu. Původně jsem se domníval, že to bude můj druhý „GIMP-expert“, neboť ve screeneru označil, že umí používat 7 z 8 vybraných funkcí aplikace. Při testu jsme ale zjistili, že si zřejmě spletl GIMP s programem Inkscape, protože byl z některých částí programu stejně překvapen jako ostatní účastníci, kteří s GIMPem teprve začínali. Test s ním tedy probíhal jako s ostatními začátečníky.

24


4.2.5

Osoba 5

Pátý účastník testu je uživatel 3D modelovacích programů. Pro tvorbu zejména textur potřebných pro své modely používá primárně Photoshop. Pokud ale potřebuje pouze ořezat nebo převzorkovat obrázek, místo aby čekal, než se mu otevře výše zmíněný komerční program, využije kvůli rychlosti startu GIMP. Jiné než tyto dvě funkce ale v aplikaci nikdy nepoužil.

4.2.6

Osoba 6

Jako šestého jsem si k testu pozval studentku Fakulty architektury. Ta používá širokou škálu rastrových a vektorových editorů. Z programu Autocad, který je určen pro projektování a konstruování staveb, je navyklá na používání velkého množství vrstev. S GIMPem se nikdy nesetkala, a proto doplatila na nedotažené ovládání vrstev v aplikaci. V momentech, kdy měla najednou vytvořených přes deset vrstev a chtěla hromadně měnit jejich pořadí, po několika minutách zkoušení zjistila, že bude muset jednotlivě vrstvy vybrat a přesunout je zvlášť.

4.2.7

Osoba 7

Stejně jako předposlední šestý účastník, i sedmý je student architektury. Ačkoliv se s GIMPem také nikdy nesetkal, s plněním úkolů neměl velké problémy. Jako jediný z testu využil offline nápovědu dostupnou z menu programu, která vás zavede na HTML uživatelskou příručku. V ní je popsáno nejen použití všech nástrojů a funkci v programu, ale i rady jak začít, či jak dosáhnout nějakého efektu. Jediná menší nevýhoda může být, že ačkoliv GIMP je kompletně přeložený do češtiny, tato nápověda je celá v angličtině.

4.3

Moderování testu

Při moderování testu jsem se snažil dodržet tzv. „Deset zlatých pravidel“ prezentovaných autory Joe Dumas a Beth Loringem v knize „Moderating usability tests“ (viz [2], kapitoly 3 a 4): 1. Rozhodnout se jak bude probíhat interakce s účastníkem v závislosti na typu testu 2. Respektovat práva účastníka 3. Příliš nenapovídat účastníkovi 4. Respektovat účastníky jako experty 5. Být profesionální, ale upřímný 6. Nechat účastníka mluvit 7. Nespoléhat se pouze na svoji intuici 8. Být nestranný

4.4. ZPRACOVÁNÍ TESTU

25

9. Dávat si pozor na neúmyslné napovídání 10. Zůstat po celou dobu testu stále ve střehu I když jsem věděl, kterých chyb se vyvarovat, v průběhu testů jsem některé z výše zmíněných pravidel porušil. Při pilot testu, který se oproti dalším testům notně protáhl, jsem zvláště ke konci na sobě pozoroval, že již nejsem tak pozorný, jako jsem byl na začátku testu. Chvílemi jsem sledoval počínání účastníka a poslouchal jeho slovní doprovod, který jsem občas doplnil nějakou otázkou, ale už jsem si tolik poznámek nepsal, neboť jsem si myslel, že ten či onen koncept již mám zapsaný. Po testu jsem pak zjistil, že mi v modelu chybělo několik entit, které jsem pak objevil při sledování audiovizuálního záznamu pořízeného při testu. Ke všem účastníkům jsem se snažil chovat stejně. Jelikož ale každý uživatel má svoje pracovní tempo, nemohl jsem si stanovit nějaký přesný časový údaj, po kterém poskytnu nápovědu. Účastníka jsem nechal projít uživatelské prostředí a po té, co mi vyjmenoval koncepty a odpověděl na moje dotazy, jsem mu poskytl radu, jak pokračovat dál. Ze záznamu jsem pak zjistil, že zatímco jednomu účastníkovi jsem napověděl po několika málo minutách, druhého jsem nechal se trápit okolo 10 minut, než jsem mu poradil, v čem je GIMP jiný od jeho představy. Jelikož uživatelům zejména při pretest interview dělalo potíže vybavit si některé koncepty a byli příliš obecní, tak jsem se často vyptával na další a další entity. Při takových pohovorech jsem si hlavně musel dát pozor, abych příliš nenaváděl uživatele. Protože účastníci testu nebyli příliš seznámeni s uživatelským prostředím GIMPu, jak objevovali nové a nové koncepty, jejich mentální model se v průběhu testu neustále měnil. Některé entity a vztahy vznikaly, jiné zase zanikaly. Pokud se uživatel dostal do stádia, kdy si nevěděl rady, a pro pokračování v testu bylo nutné splnit daný úkol, musel jsem mu poradit. Díky mému zásahu (mé radě) se jeho mentální model změnil, já ale z logických důvodů jsem původní chybný koncept v jeho modelu zanechal. Ten mi pak posloužil při odhalování problematických částí uživatelského rozhraní. Příklad uvedu na situaci, která se mi při testování nejednou přihodila: • Účastník: „Hledal jsem nástroj pro nakreslení obdélníku, ale nemůžu ho najít. Nevím jak nakreslit obdélník.“ • Já: „V GIMPu nástroj, který kreslí obdélníky, není. Dělá se to tam jiným způsobem.“ Nyní účastník ví, že daný nástroj v GIMPu není. Bez mé pomoci by ovšem nebyl schopen pokračovat, a proto v jeho mentálním modelu tuto entitu ponechám (tento příklad viz obrázek 4.8).

4.4

Zpracování testu

Protože vytváření a úprava modelů v aplikaci Enterprise Architect není příliš efektivní, neboť je nutné strávit spoustu času v dialogových okénkách a tvořením layoutu, při testu jsem si pouze zapisoval poznámky místo toho, abych rovnou kreslil mentální model. Soustředil jsem se na entity a vztahy mezi nimi, tak jak si to myslí konkrétní účastník.

26


V případě, kdy představa o tom, co chce uživatel udělat, korelovala s tím, co aplikace poskytuje, nenastal žádný problém - daný koncept (entita, vztah mezi entitami, atribut nebo kombinace všech třech) se nacházel jak v mentálním modelu uživatele, tak i v konceptuálním modelu aplikace. Jiné to bylo, když uživatel nemohl najít funkci nebo nástroj, tam kde očekával, že bude. Jeden z problémů, který se týkal všech testovaných, byl ten, že v GIMPu se nepracuje s objekty. Často se stávala situace zobrazená na obrázku 4.5. Zde uživatel nakreslil čtverec použitím nástroje výběr a plechovky. Pak měl za úkol nastavit čtverci jinak barevný rámeček. Zvyklý z jiných zejména vektorových editorů se domníval, že to bude možné pomocí nějaké funkce dostupné z kontextového menu nakresleného objektu. Klikl proto pravým tlačítkem na obrázek a vybíral v něčem, o čem si myslel, že doopravdy kontextové menu je. Kdyby se ale podíval do horní části tohoto okna, zjistil by, že ono tzv. „Kontextové menu“ je ve skutečnosti hlavní menu a všechny funkce, které se mu zobrazily po stisknutí tlačítka myši, jsou také dostupné kdykoliv z horního menu aplikace.

Obrázek 4.5: Uživatel chybně po nakreslení čtverce čeká, že bude moci prostřednictvím kontextové menu upravit jeho atributy

Tento rozdíl je na první pohled patrný z modelů, které můžeme vidět na obrázcích 4.6 (konceptuální model aplikace) a 4.7 (mentální model uživatele). V mentálním modelu některé entity zcela chybí (ačkoliv je zřejmé, že v mentálním modelu se dozajista bude někde nacházet

4.5. ZJIŠTĚNÍ Z TESTU

27

entita „Výběr“, v téhle části modelu není), jiné naopak přebývají. Vytvořily se mezi nimi nové vztahy a některé staré naopak přítomny nejsou (například vztah „Obrázek-Hlavní menu“ bychom hledali v mentálním modelu marně).

Obrázek 4.6: Část konceptuálního modelu aplikace, která popisuje vybrání obvodu výběru.

V první iteraci jsem takto vytvořil mentální modely z mých poznámek z testu. Zjistil jsem hlavní rozdíly a připravil si model pro druhou iteraci, ve které jsem upravoval a dále zpřesňoval model pomocí záznamu pořízeného aplikací Camtasia.

4.5

Zjištění z testu

Při zpracovávání výsledků testu a ostatně při testu samotném se naplnila má očekávání ohledně problematičnosti uživatelského rozhraní GIMPu. Ačkoliv test se skládal z použití běžných a základních nástrojů a funkcí editoru, uživatelům z mé cílové skupiny plnění úkolů činilo nemalé problémy. Nyní zde napíšu jednotlivé problémy, na které jsem při uživatelském testu narazil a podobně jako v sekci 4.4 se budu snažit interpretovat rozdíly mezi mentálním modelem uživatele a konceptuálním modelem aplikace. Z důvodu rozsáhlosti mentálních modelů uživatelů, zde budu ukazovat pouze jejich malé části, které se týkají sledovaného konceptu. Kompletní modely je možné si prohlížet v příloze na CD.

28


Obrázek 4.7: Část mentálního modelu aplikace, která popisuje, jak uživatel nastaví objektu barvu rámečku.

4.5.1

Absence kreslení primitiv

První problém, se kterým se účastník testu setkal, je, že v GIMPu nenašel žádný nástroj, pomocí něhož by mohl nakreslit vybarvený obdélník. V tomhle směru je tento editor unikát. Vždyť i v základním Malování je možné kreslit vybrané základní geometrické obrazce. I když uživatelé strávili s řešením tohoto problému několik minut, nakonec byli za pomoci nástrojů pro výběr obdélníku (respektive elipsy) a plechovky schopni daný úkol splnit, a proto si nemyslím, že tohle není jedna z největších vad programu. Na obrázku 4.8 je interpretace tohoto rozdílu pomocí modelů.

4.5.2

V aplikaci se nepracuje s objekty

Když se uživateli zdárně podařilo nakreslit obdélník, narazil na druhý problém, který spočíval v obarvení rámečku obdélníku barvou. Uživatel je zvyklý z ostatních editorů (jak rastrových, tak i vektorových), že právě nakreslený Objekt je možné měnit pomocí funkcí, které jsou dostupné z kontextového menu (nebo pomocí nějakého toolbaru). Jak už jsem napsal v sekci 4.4, s žádnými objekty se manipulovat v GIMPu nedá. Po stisknutí pravého tlačítka myši se místo kontextového menu zobrazí uživateli položky hlavního menu.

4.5. ZJIŠTĚNÍ Z TESTU

29

Obrázek 4.8: Znázornění absence primitiv pomocí modelů

Jediné, co se trochu přibližuje konceptu Objekt, je textový nástroj. Každé použití tohoto nástroje vytváří novou textovou vrstvu, kterou lze i později editovat (měnit velikost a barvu písma, měnit text samotný, apod.). Rámeček se v aplikaci udělá pomocí funkce Obvod, která je dostupná z menu „Vybrat“. Na takto vzniklý výběr pak použijeme nástroj Plechovka, čímž získáme barevný rámeček (modely viz obrázky 4.6 a 4.7). Při řešení tohoto problému část účastníků hledala v různých menu tuto funkci tak dlouho, dokud ho nenašla. Druhá část si myslela, že tato funkce v editoru chybí a rámeček nakreslila pomocí dvou obdélníků namalovaných přes sebe. Je zajímavé, že ačkoliv někteří z druhé části se k funkci „Obvod“ skrz menu dostali, podle jejího názvu si nemysleli, že právě s její pomocí je možné vytvořit rámeček obdélníku.

4.5.3

Absence nástroje, který kreslí rovné čáry

Uživatelé sotva nakreslili obdélník a už se dostávají k dalšímu problému. Za úkol mají spojit tři obdélníky pravidelně tak, aby vytvořili turnajového pavouka. V programu se ale nenachází nástroj, který bez použití klávesových zkratek kreslí rovné úsečky. Tento problém je podobný

30


problému popsaném v sekci 4.5.1, ale v GIMPu úsečky narozdíl od primitiv kreslit lze, ale postup je poněkud obtížný. Nejprve si musíme vybrat buď nástroj Štětec nebo Tužka a kliknout do obrázku, čímž označíme první bod naší úsečky. Pak po stisku klávesy Shift můžeme kreslit rovné čáry. Pro omezení úhlu, abychom mohli kreslit přesné vertikální a horizontální úsečky, můžeme přidržet Ctrl.

Obrázek 4.9: Postup kreslení čáry. Všimněte si, že nápověda dobře reaguje na činy uživatele Ačkoliv je výše popsaný postup pro vytvoření rovné čáry dobře popsaný řádkem s nápovědou (viz 4.9, většina účastníků nebyla schopna sama nakreslit rovnou čáru. Někteří podobně jako s absencí primitiv si mysleli, že takhle funkcionalita v GIMPu chybí a proto si obdélníkovým výběrem vytvořili úzký proužek, který obarvili barvou a několikrát nakopírovali. Takto vytvořené proužky pak pomocí nástroje rotace a přesunu rozmístili tak, aby vytvořili kýženého pavouka. Hlavní chybu aplikace nevidím v tom, že chybí nástroj pro tvorbu čar, ale ve špatně umístěném a nedostatečně zvýrazněném řádku s nápovědou. Rozdíly mezi modely je možné

4.6. SHRNUTÍ POUŽITÝCH APLIKACÍ

31

vidět na obrázku 4.10.

4.5.4

Nelze označit více vrstev

O tomto problému jsem mluvil při vytváření konceptuálního modelu aplikace (viz sekce 4.1). V GIMPu nelze vybrat více vrstev a měnit jejich obsah a pořadí. Pomocí ikonky řetězu je sice lze propojit, a tak všechny transformace (převrácení, přesunutí, rotace, změna perspektivy) se kopírují do všech takto provázaných vrstev (viz rozdíly modelů na obrázku 4.11).

4.5.5

Plovoucí výběr

K poslednímu problému, který postihl více než jednoho účastníka, docházelo ve třetím UC, kde bylo zapotřebí kopírovat části jednoho obrázku do druhého. V GIMPu, pokud zkopírujeme ze schránky kus výběru do obrázku (například pomocí klávesových zkratek Ctrl+C a Ctrl+V) dojde k vytvoření speciálního typu vrstvy, který se nazývá Plovoucí výběr. Dokud je plovoucí výběr aktivní, není možné měnit žádné jiné vrstvy kromě vrstvy s plovoucím výběrem. Plovoucí výběr je možné „ukotvit“ pomocí některého nástroje pro výběr. Až pak je možné opět manipulovat s ostatními vrstvami (konceptuální model viz obrázek 4.12. Účastníci postupovali tak, že předtím než zkopírovali vybraný kus obrázku, si vytvořili novou vrstvu, do které chtěli vložit vybraný obrázek. Pak byli překvapeni, když po stisku klávesové zkratky Ctrl+V jim byla vytvořena nová vrstva, kterou nechtěli. Ukotvení vrstvy většinou provedli náhodně (měli vybraný nástroj pro výběr a zběsile klikali) nebo mimochodem, když vloženou vrstvu pojmenovali, čímž došlo také k ukotvení.

4.6

Shrnutí použitých aplikací

Jelikož jsem chtěl modely získané při testu použít i v zásuvném modulu, bylo nutné je exportovat z grafické podoby do textové (XML, viz 5.3.1), a proto se volba aplikace Enterprise Architect jako modelovacího nástroje ukázala jako ne zrovna ideální. Export diagramů je velice málo konfigurovatelný a navíc se společně s daty zapisují do souboru údaje o vizualizaci a rozmístění entit v EA. Tyto údaje pak ztěžují orientaci a znesnadňují manipulaci s daty mimo tento CASE nástroj. Jelikož se tento jev vyskytoval i u dalších editorů (například yED graph editor, viz [18]), které umožňují vytvářet mentální modely, pro export jsem použil textový editor - Netbeans. Toto IDE mimo zvýrazňování syntaxe při psaní XML umožňuje jednoduchým způsobem si nastavit šablony, které za nás automaticky vkládají kusy opakujícího se kódu. V šabloně se nastaví proměnné části, mezi kterými je možné po stisknutí zkratky (nutné pro vyvolání šablony) přepínat pomocí kláves TAB nebo ENTER a měnit jejich výchozí hodnoty (například jméno entity a atributy).

32


Obrázek 4.10: Část modelů, na kterých je vidět rozdíl při kreslení rovných čar

4.6. SHRNUTÍ POUŽITÝCH APLIKACÍ

Obrázek 4.11: Srovnání modelů ohledně výběru a manipulace s více vrstvami

33

34


Obrázek 4.12: Konceptuální model, který zobrazuje funkci plovoucího výběru a jak se dá ukotvit

Kapitola 5

Návrh a popis použití pluginu Při vytváření modelů a jejich analýze v CASE nástroji Enterprise Architect jsem narazil na několik problémů. Z testu jsem zjistil, že modely jsou poměrně rozsáhlé a jeden z nich pokrývá zhruba dva papíry rozměru A4. Aby se v takovém modelu dalo dobře orientovat, je dobré, aby model měl nějaký pravidelný layout, který respektuje určitá pravidla (entity ani hrany s názvy a četnostmi nejsou přeházené přes sebe, nezabírají více místa než je třeba, apod.) a zároveň zůstal přehledný. V EA sice možnost nastavení automatického layoutu funguje, ale je spíše na škodu než ku prospěchu. Spoustu času jsem tak musel strávit vytvářením přehledného uspořádání modelu a správnému směrování vztahů mezi entitami tak, aby na své cestě co nejméně křižovaly jedna druhou. Ve stísněných prostorách jsem pak hledal skulinky, do kterých jsem umístil názvy hran a četnosti, tak, aby byly dobře vidět. Tvorba jednoho modelu se tak protáhla i na několik hodin. Další problém nastal v momentě, kdy jsem chtěl porovnávat modely mezi sebou. V EA není žádná možnost zobrazení diagramů vedle sebe, a proto jsem musel při hledání rozdílů překlikávat mezi modely a hledat rozdíly po paměti. Také by mi pomohla nějaká funkce, pomocí které bych se mohl soustředit na detaily modelu - například zobrazení sousedních entit právě vybrané entity nebo skrývání momentálně nepotřebných částí modelu. Z těchto poznatků jsem vycházel při tvorbě zásuvného modelu do aplikace IVE tool, který by sloužil pro ulehčení analýzy konceptuálního modelu aplikace.

5.1

Popis aplikace IVE tool

Program IVE tool, produkt katedry Počítačové grafiky a interakce, slouží pro vizualizaci a zpracování dat získaných z uživatelského testu. Poznámky a logy z testů pořízené z různých aplikací sloužících jako pomůcky při testování je možné importovat a dále zpracovat díky množství dostupných pluginů. Ačkoliv dle jeho autorů (viz [11]) při testování s tímto programem nalezli zhruba stejné množství problémů týkajících se použitelnosti jako při testování bez tohoto programu, čas potřebný pro tvorbu anotací a zpracování dat se snížil. IVE tool tedy slouží k analýze testu použitelnosti a společně se svojí modularitou a snadnou rozšiřitelností se perfektně hodí pro spojení s nástrojem na zpracování modelů.

35

36

5.2

KAPITOLA 5. NÁVRH A POPIS POUŽITÍ PLUGINU

Popis použití pluginu

Využití pluginu začíná už při testu s uživatelem u počítače. Zatímco uživatel bude plnit zadání testu, já budu mít otevřený plugin a v něm si budu vytvářet mentální model uživatele. V testu se ukázalo, že ačkoliv části modelů uživatelů se lišily, hlavní koncepty byly u všech až na výjimky stejné. Proto, místo abych pokaždé začínal s prázdným modelem, si na začátku testu otevřu obecnou kostru, kterou budu dále upravovat dle počínání uživatele. Obecná kostra bude část konceptuálního modelu aplikace, kterou jsem si vytvořil před započetím testu. Předpokládám, že nebude třeba ji příliš měnit. Nežádoucí by bylo, kdybych jako kostru zvolil skoro celý konceptuální model a pak celý test strávil čištěním modelu. Pokud bych si nebyl jistý, jak by taková kostra mohla vypadat, provedení pilot testu by mohlo napovědět. Jak by mohla vypadat základní kostra aplikace GIMP, můžete vidět na obrázku 5.1.

Obrázek 5.1: Kostra modelu aplikace, kterou použiji při testu s uživatelem

Model takto pořízený z testu pak v pluginu ještě doopravím podle audiovizuálního záznamu pořízeného například programem Camtasia. Výsledek si pomocí modulu zobrazím vedle konceptuálního modelu a označím, které entity jsou společné oběma modelům. To mi pak pomůže při zpracování a hledání rozdílů (takto propojené entity budu moci odlišit, například zvýraznit barvou). Tento postup je nutné udělat ručně, neboť dvě entity různého názvu mohou přesto reprezentovat tentýž koncept a naopak, dvě entity stejného názvu mohou reprezentovat koncept jiný. Jako příklad uvedu, že někteří účastníci (hlavně uživatelé

5.2. POPIS POUŽITÍ PLUGINU

37

programu Autocad) říkali vrstvám hladiny (přitom je jasné, že se jedná o stejný koncept). Naopak na ukázkách, které jsem uvedl v kapitolách 4.4 a 4.5 jsme mohli vidět dvojí použití entity kontextové menu, které pokaždé znamenalo něco trochu jiného. Častokrát se v mentálních modelech objevovalo kontextové menu objektu, jelikož se ale objekt nevyskytuje v konceptuálním modelu aplikace, není možné označit, že se jedná o stejnou entitu, jakou je kontextové menu vrstvy, pomocí které můžeme v GIMPu měnit například jméno vrstvy. Poté, co takto označím podobné entity, mohu se pustit do tvorby anotací v zásuvném modulu. Pomocí nich popíši závažné rozdíly mezi modely. Ty pak budou vidět bez potřeby zobrazených obou modelů vedle sebe. Ačkoliv podtypy jsou v modelu důležité, protože bez nich bych nemohl například rozlišit, zdali uživatel hledal odstranění červených očí jako funkci z menu, nebo na to chtěl aplikovat nástroj, jejich používání zhoršuje orientaci v modelu. Více než polovina entit, které jsou v mém konceptuálním modelu aplikace GIMP je právě tvořena podtypy. Proto v pluginu umožním testerovi přepínat mezi různými stupni abstrakce (viz obrázek 5.2 a 5.3).

Obrázek 5.2: Zobrazení mentálního modelu z pretest interview pluginem. Entity, které mají podtypy, jsou znázorněné červeně.

38


Obrázek 5.3: V modelu se dá daleko lépe orientovat, pokud nemáme zobrazené podtypy.

5.3

Návrh pluginu

Tvorba zásuvného modulu pro aplikaci IVE tool se skládá ze dvou hlavních částí: 1. Načtení modelu ze souboru 2. Vizualizace modelu

5.3.1

Import modelu

Při volbě struktury souboru s modelem, jsem vycházel ze standardu GraphML (viz [10]), který jsem přizpůsobil mým potřebám. GraphML je jazyk určený pro textovou reprezentaci grafů. Je založen na XML syntaxi za účelem jednodušší výměny struktur grafů mezi programy. Podporuje zobrazení široké škály grafů - orientované, neorientované, smíšené grafy, hypergrafy a také disponuje speciálním mechanismem, který dovoluje nadefinovat rozšiřující model pro přídavná data (např. informace pro kreslení grafu nebo data specifická pro určitou aplikaci). V souboru jsou zvlášť uvedeny entity a vztahy mezi nimi. DOM ukázkového souboru s modelem se skládá z následujících typů uzlů: 1. Node • označuje entitu v modelu • obsahuje tři atributy – id - povinný identifikátor uzlu – name - povinný atribut, jméno uzlu

5.3. NÁVRH PLUGINU

39

– attributes - nepovinný atribut, obsahuje všechny atributy entity oddělené mezerou • podtyp entity se znázorňuje vnořením uzlu (mezi párové tagy <node>) 2. Edge • označuje vztah mezi dvěma entitami • obsahuje šest atributů – – – – – –

id - povinný unikátní identifikátor hrany name - nepovinný název vztahu source - id uzlu, ze kterého hrana vychází target - id uzlu, do kterého hrana vchází freqSrc - nepovinný, parcialita a kardinalita zdrojového uzlu freqTrgt - nepovinný, parcialita a kardinalita cílového uzlu

3. Info • prostředek pro vytváření anotací k uzlům • obsahuje čtyři povinné atributy – – – –

id - unikátní identifikátor (společný s uzly) text - text popisující cílový uzel nodeId - identifikátor uzlu, ke kterému patří tato poznámka edgeId - unikátní identifikátor hrany, která vznikne mezi cílovým uzlem a poznámkou

Protože v mé implementaci zatím není možné měnit strukturu modelu, modely jsem chtěl vytvářet pomocí programu yED Graph Editor (viz [18]), který nativně pracuje se soubory ve formátu GraphML. Jelikož, ale vedle dat ukládá i své aplikační údaje související s vizualizací (jako například barva nebo pozice uzlu v grafu), soubory vytvořené v tomto programu jsou rozsáhlé a nepřehledné. Proto jsem veškeré modely vytvořil ručně pomocí textového editoru.

5.3.2

Vizualizace dat

Při hledání knihovny, pomocí které budu vizualizovat mé modely, jsem chtěl, aby manipulace s modely nebyla tak statická jako například v Enterprise Architect a zároveň umožňovala nastavení přehledného layoutu, který si pak mohu dynamicky přizpůsobovat. Z nabídky dostupných frameworků pro vizualizaci grafů postavených na technologii Java jsem si nakonec vybral knihovnu Prefuse. Ačkoliv poslední verze vyšla v roce 2007 a je stále označena, že se jedná o betaverzi, framework se může pyšnit početnou fanouškovskou základnou a líbivou galerií projektů využívajících Prefuse (viz [15]). Za úspěchem knihovny stojí přehledně navržené API, jehož použití je snadné. Nejprve je potřeba načíst data ze souboru a rozdělit je do tabulek uzlů a hran. Tabulky tvořící graf jsou pak předány třídě k vizualizaci. Ta pro každý uzel a každou hranu vytvoří instanci třídy VisualItem, která poskytuje přístup jak k atributům souvisejících se zobrazováním (například barva písma, pozadí, velikost fontu) tak i k výchozím datům.

40


Změna výchozích zobrazovacích (ale i datových) hodnot je možná aplikací Action modulů. Těmi je možné ovlivňovat viditelnost VisualItemu, výpočet layoutu nebo přiřazování barev. Více takových modulů tvoří ActionList. Ten je pak předán třídě Visualization, která ho spustí. Jelikož je zbytečné, aby se některé akce volaly pořád dokola (stačí je zavolat jednou například nastavení barvy, změna viditelnosti) a naopak je nezbytné, aby výpočet layoutu probíhal neustále, je možné nastavit pomocí parametru, zdali se má ActionList volat pouze na přání uživatele (například změna barvy když dojde k označení uzlu myší) nebo tolikrát, co počítač stačí (výpočet layoutu). O skutečné podobě instance VisualItemu je rozhodnuto přiřazením modulu Renderer. Ten má na starost kreslení a výpočet prostoru, který zabírají jednotlivé uzly a hrany. Součástí knihovny je několik tříd, které umožňují kreslit základní tvary s popisky a obrázky. Jelikož je vše dobře zdokumentováno, je možné knihovnu rozšířit o vlastní Renderer. O přiřazení Rendereru danému VisualItemu rozhoduje RendererFactory. Pro výběr určité skupiny instancí VisualItem z tabulky je k dispozici třída Predicate, která umožňuje mimo selekcí provádět i manipulace s daty. Kamerou, kterou se koukáme na graf, je komponenta Display. Ta umožňuje provádět různé transformace pohledu (pohyb, rotace nebo přiblížení). Pro interakci s uživatelem je k dispozici rozhraní Control, která odchytává vstup z klávesnice a myši, které je pak zpracováno instancí třídy ControlAdapter.

Kapitola 6

Implementace pluginu Implementace modulu se skládá ze dvou pluginů pro aplikaci IVE tool. Prvním z pluginů je MentalModelGraphMLImporter, který má za cíl nahrát soubor se mnou definovaným formátem (viz sekce 5.3.1) do projektu v aplikaci. Po té je možné takto nahraný soubor vizualizovat pomocí pluginu MentalModelViz, který převede model do tabulkové podoby a zavolá knihovnu Prefuse (viz sekce 5.3.2). Cyklus dat od importu až po vizualizaci můžete vidět v tabulce 6.1.

6.1

MentalModelGraphMLImporter

Tento plugin se skládá z pouze jedné třídy, kde doje k vytvoření aplikačního modelu (AppModel). Aplikační model je tvořen seznamem hran a uzlů. Jednotlivé atributy (například jméno, id, kardinalita a parcialita) jsou ukládány ke každé entitě do hashmapy ve formě klíč-hodnota. Pro přístup k DOM mého XML dokumentu jsem použil knihovnu dom4j (viz [8]).

6.2

MentalModelViz

Vstupem do pluginu určeného k vizualizaci je aplikační model vytvořený pomocí zásuvného modulu MentalModelGraphMLImporter (viz sekce 6.1). Následně je model transformován do tabulek (schémata viz tabulky 6.2 a 6.3), které jsou posléze vizualizovány knihovnou Prefuse. Struktura XML AppModel HierarchyModel Graph

Popis Data jsou uložena v souboru ve stromové struktuře v upravené syntaxi GraphML Data rozdělena zvlášť na seznamy uzlů a hran, součást balíku ive.sdk Model, který obsahuje data ve dvou tabulkách pro Prefuse Graf, kde data jsou instance třídy VisualItem Tabulka 6.1: Cyklus dat v aplikaci

41

42

KAPITOLA 6. IMPLEMENTACE PLUGINU

Sloupec C_NAME C_BACKEND C_EXPANDABLE C_EXPANDED C_INFO C_ATTRIBUTES C_FORCEFIXED

Poznámka Název uzlu Poskytuje zdrojová data (atributy) Určuje, zdali je uzel nadtypem (jestli je možné ho rozkliknout) Pravda, pokud je uzel rozkliknut Určuje, jestli je uzel poznámkou Zformátovaný řetězec atributů Pravda, pokud je uzel zafixovaný (nehýbe se podle layoutu) Tabulka 6.2: Schéma tabulky uzlů

Sloupec C_EDGENAME C_SRC C_TGT C_HIERARCHY C_FREQSRC C_FREQTGT

Poznámka Jméno hrany Identifikátor zdrojového uzlu Identifikátor cílového uzlu Pravda, pokud se jedná o hierarchickou hranu (hrana mezi nadtypem a podtypem) Kardinalita a parcialita zdrojového uzlu (entity) Kardinalita a parcialita cílového uzlu (entity) Tabulka 6.3: Schéma tabulky hran

Interakce mezi modely se děje ve třídě AppModelVisualization, která odchytává události posílané mezi vizualizacemi v aplikaci IVE tool. Vyvolání události se děje pomocí třídy VisualizationWindowManager, která implementuje návrhový vzor Singleton (viz [16]). Protože posílá události do všech registrovaných vizualizací, je nutné odchytit a nereagovat na ty události, které okno poslalo samo sobě. Pro vykreslení názvu hrany je nutné použít návrhový vzor dekorátor (viz [7]). Instance třídy DecoratorItem umožňuje přiřadit jednomu VisualItemu dynamicky více Rendererů. Ve výchozím stavu EdgeRenderer zobrazuje pouze šipku od jednoho uzlu k druhému. Jelikož ale chci vykreslit i název hrany, přiřadím mu tímto způsobem LabelRenderer. Pak jen jednoduchým algoritmem spočtu pozici názvu na hraně a přidám tento výpočet do neustále volaného ActionListu. Pokud se jedná o nastavování layoutu, knihovna dává vývojáři k dispozici sadu funkcí, umožňující nastavit fyzikální systém grafu podle potřeb . V mém grafu jsou uzly nastaveny tak, že do určité vzdálenosti se od sebe odpuzují. Hrany pak fungují jako pružiny, které dle koeficientu drží uzly při sobě. Pro zobrazení textu v uzlu je k dispozici LabelRenderer. Protože jsem potřeboval nějak odlišit název entity od atributů, musel jsem si vytvořit vlastní Renderer. V něm je možné nastavit každému uzlu dva fonty - jeden pro název entity a druhý pro atributy. Přispívá to k lepší orientaci v grafu.

Kapitola 7

Závěr V rámci této práce jsem navrhl rozšíření metodiky testu použitelnosti s využitím konceptuálního modelu rozsáhlé aplikace, která tento typ testování umožňuje. Funkčnost metodiky jsem pak ověřil vytvořením a provedením testu návrhu uživatelského rozhraní rastrového editoru GIMP. Za použití stávajících nástrojů pro záznam a tvorbu modelů jsem zpracoval výsledky testu a vytvořil mentální modely uživatelů. Díky zvolené notaci jsem mohl porovnávat výsledky uživatelů mezi sebou a analyzovat, jak odpovídaly jejich představy o tom, co chtějí udělat, s tím, co nabízí aplikace. Při testování uživatelé často naráželi do podobných problémů. Díky podrobnému studiu jejich mentálních modelů jsem zjistil, že okolnosti problémů častou plynou z různých důvodů. Toto zjištění pak mohou návrháři využít pro úspěšné vymícení dané chyby z uživatelského rozhraní. Dojde tak k ušetření nákladů, které by souvisely s opravováním již jednou opravených chyb, z důvodů špatného analyzování problému. Po provedení testu jsem identifikoval nedostatky použitých nástrojů pro zpracování testu. Navrhl jsem zásuvný modul do aplikace IVE tool, který ušetří jak sběr dat z testu, tak jejich následnou evaluaci. Dále jsem navrhl obecný postup testování rozsáhlých aplikací, který tento typ testu dovolují použít, s využitím navrhnutého pluginu. V poslední části práce jsem implementoval podmnožinu funkcí pluginu. Tester si může pro zlepšení čitelnosti modelu přepínat mezi různými abstrakcemi. Díky tomu se lze lépe soustředit na konkrétní koncepty a s využitím interakce mezi modely v aplikaci IVE tool pak snadněji identifikovat rozdíly v pochopení konceptuálního modelu účastníkem testu. Do budoucna je třeba implementovat zbytek funkcí navrhnutého zásuvného modulu. Zejména je nutné umožnit uživateli vytváření a manipulování s entitami a vztahy v modelu v rámci pluginu. Dále by k jednotlivým uzlům mohl přidávat poznámky při analyzování modelů. Výsledek práce by si pak mohl včetně stávajícího rozmístění layoutu uložit do upravené notace GraphML. Další oblastí zájmu je návrh a implementace uživatelského rozhraní, které výše zmíněnou funkcionalitu testerovi umožní.

43

44

KAPITOLA 7. ZÁVĚR

Literatura [1] BENYON, D. – GREEN, T. – BENTAL, D. Conceptual Modeling for User Interface Development. London, UK : Springer, 1999. [2] DUMAS, J. – LORING, B. Moderating Usability Tests. Oxford : Elsevier, 2008. [3] FIDGEON, T. User Centered Design. , ze 13. 5. 2011.

stav

[4] KUNIAVSKY, M. Observing the User Experience: A Practitioner’s Guide to User Research. London : Morgan Kaufmann Publishers, 2003. [5] NIELSEN, J. 10 Heuristics for User Interface Design. , 7. 5. 2011.

stav

ze

[6] web:camtasia. 1 for All Software. , stav ze 7. 5. 2011. [7] web:decorator. Decorator Pattern. , stav ze 22. 5. 2011. [8] web:dom4j. dom4j - Introduction. , stav ze 15. 5. 2011. [9] web:gimptuts. GIMP - Tutorials. , stav ze 6. 5. 2011. [10] web:graphml. The GraphML File Format. , stav ze 7. 5. 2011. [11] web:ive. Interactive analytical tool for usability analysis of mobile indoor navigation application. , stav ze 15. 5. 2011. [12] web:mechdynecave. CAVE :: Mechdyne Corporation. , stav ze 7. 5. 2011.

45

46

LITERATURA

[13] web:oomarketshare. News: International OpenOffice market shares. , stav ze 7. 5. 2011.

[14] web:oostazeni. OpenOffice.org 3.0: Za první týden 3 miliony stažení. stav ze 6. 5. 2011. [15] web:prefuse. prefuse - interactive information visualization toolkit. , stav ze 15. 5. 2011. [16] web:singleton. Singleton Pattern. , stav ze 15. 5. 2011. [17] web:usercentereddesign. User Centered Design. , stav ze 13. 5. 2011. [18] web:yed. yEd - Graph Editor. , stav ze 15. 5. 2011.

Příloha A

Uživatelský manuál A.1

Instalační příručka

Instalace se skládá v přidání dvou pluginů - MentalModelGraphMLImporter a MentalModelViz do aplikace. To se udělá v dialogu Tools / Plugins (viz A.1).

Obrázek A.1: Dialogové okno pro přidání pluginu ze souboru.

Zde v záložce „Downloaded“ vybereme soubory „ive-mentalmodel.nbm“ a „ive-mentalmodelimporter.nbm“ a posléze je nainstalujeme do aplikace. Instalaci dokončíme restartováním aplikace.

47

48

A.2 A.2.1

PŘÍLOHA A. UŽIVATELSKÝ MANUÁL

Uživatelská příručka Import modelu

V IVE toolu začneme importováním XML souboru s modelem. Po vytvoření projektu v aplikaci import provedeme přes menu „File / Import“. Zde zvolíme, že se jedná a aplikační model a vybereme naše XML soubory. Jako „Convertor“ zvolíme modul „ive.mentalmodel.importer.XMLConvertor“ (viz A.2).

Obrázek A.2: Z nabídky Convertorů zvolíme importer pro mentální modely.

A.2.2

Vizualizace modelu

Po úspěšném načtení modelu do aplikace jej můžeme vizualizovat. To provedeme pomocí ikonky „Vizualize Data“ (viz obr. A.3). Z nabídky pluginů zvolíme MentalModelViz (viz A.4) a v následujícím okně vybereme jeden model k zobrazení.

A.2.3

Práce s modelem

Když máme model vizualizovaný, můžeme s ním provádět následující operace:

A.2. UŽIVATELSKÁ PŘÍRUČKA

49

Obrázek A.3: Ikonka sloužící pro vizualizaci modelu.

• kliknutím a pohnutí myší se pohybujeme po grafu • po dvojkliku na červený uzel je možné jej rozbalit/zabalit • po najetí na uzel jsou zeleně zvýrazněny sousední uzly • kliknutím pravým tlačítkem na uzel dojde k zafixování pozice uzlu • kolečkem na myši je možné se přiblížit/oddálit Porovnávat modely mezi sebou lze, pokud máme vedle sebe více modelů vizualizovaných. Jeden z modelů přetáhneme například do levého rohu (viz A.5). S entitami, které jsou společné oběma modelům, je pak možné provádět následující operace: • rozbalit/zabalit červený uzel • zafixovat uzel pravým tlačítkem myši • zvýraznění označeného uzlu (viz A.6)

50


Obrázek A.4: Zde vybereme správný plugin pro vizualizaci.

A.2. UŽIVATELSKÁ PŘÍRUČKA

51

Obrázek A.5: Pro zobrazení modelů vedle sebe musíme jeden přetáhnout například k levému rohu aplikace (zobrazí se červený rámeček).

52


Obrázek A.6: Pokud je entita společná pro oba modely (jak mentální tak konceptuální), tak po najetí myší na ní je mimo zobrazení sousedních uzlů v prvním grafu zvýrazněna entita v druhém grafu.

Příloha B

Seznam použitých zkratek API Application programming interface CAVE Cave Automatic Virtual Environment DOM Document Object Model EA Enterprise Architect GraphML Graph Modeling Language GIMP GNU Image Manipulation Program GPL General Public License GUI Graphical User Interface IDE Integrated Development Environment PSD Photoshop Document PX Pixel UC Use Case UML Unified Modeling Language XML Extensible Markup Language

53

54

PŘÍLOHA B. SEZNAM POUŽITÝCH ZKRATEK

Příloha C

Screener 1. Používáte nějaký pokročilý grafický editor například pro úpravu fotek nebo kreslení? (a) Ano (b) Ne 2. Jaké grafické editory používáte? (povoleno zaškrtnout více možností, editory očíslujte podle preferencí - editor co používáte nejčastěji 1, druhý nejpoužívanější 2, atd.) (a) GIMP (b) Adobe Photoshop (c) Adobe Illustrator (d) Adobe Indesign (e) Inkscape (f) Jiný vektorový editor (g) Jiný rastrový editor 3. Kdy jste naposledy pracoval s nějakým grafickým editorem? (a) Dnes nebo včera (b) Maximálně před týdnem (c) Maximálně před měsícem (d) Déle než před měsícem 4. Které funkce jste ve Vámi preferovaném editoru již použil? (Zaškrtněte libovolné množství odpovědí) (a) Maska (výběr z obrázku) (b) Kreslení primitiv (obdélníky, elipsy) (c) Úprava barev fotky (d) Odstranění červených očí (nebo jiná retuše) z fotky (e) Práce s vrstvami (vytvoření/vymazání vrstvy v obrázku)

55

56

PŘÍLOHA C. SCREENER

(f) Změna perspektivy obrázku/fotky (g) Ořez obrázku (h) Převzorkování obrázku (změna velikosti plátna) 5. Které funkce jste již použil v editoru GIMP? (Zaškrtněte libovolné množství odpovědí) (a) Maska (výběr z obrázku) (b) Kreslení primitiv (obdélníky, elipsy) (c) Úprava barev fotky (d) Odstranění červených očí (nebo jiná retuše) z fotky (e) Práce s vrstvami (vytvoření/vymazání vrstvy v obrázku) (f) Změna perspektivy obrázku/fotky (g) Ořez obrázku (h) Převzorkování obrázku (změna velikosti plátna)

Příloha D

Zadání testu D.1

Instrukce

• Při testu je zakázáno používání internetu jako zdroje nápovědy. Jediná dovolená nápověda je ta obsažená v GIMPu. • Všechny obrázky nutné pro tento test jsou dostupné ve složce F: GimpTest . • Mým cílem je sledovat, jak uživatel přemýšlí a srovnat to s tím, co aplikace nabízí. Proto musím vědět, co chcete v každém kroku udělat a jak toho hodláte dosáhnout. Pokud si z pozorování nebudu jist, co jste vaší poslední akcí zamýšlel, požádám Vás, abyste zastavil svoji práci a vysvětlil mi vaší logiku. Proto, až to bude možné (například po dokončení akce, odkliknutí dialogu), zastavte svoji práci na okamžik. • Pokud Vás to zvlášť nerozptyluje, přemýšlejte nahlas. Nebudu pak nucen Vás přerušovat každých 30 vteřin. • Ačkoliv jste na „testu“, Vy nejste ten, co je testován. Pokud se Vám něco nedaří, nebo nebudete vědět, jak něčeho dosáhnout, nezoufejte. Naopak, čím více budete ztracen v grafickém uživatelském rozhraní GIMPu, tím snazší potom bude určování rozdílů mezi tím, co nabízí aplikace a tím, co požadujete Vy (jakožto zástupce potencionálních uživatelů). • Poté, co dokončíte úkol, uložte svůj výsledný obrázek jako JPEG a umístěte ho do odpovídající složky (úkol 1 do složky uloha1, úkol 2 do složky uloha2, ...). • Pokud nerozumíte zadání nebo si nevíte rady, ozvěte se 1. Úkol Pomocí aplikace GIMP vytvořte část turnajového pavouka. Jak by mohl výsledný pavouk vypadat, můžete vidět na obrázku níže.

57

58

PŘÍLOHA D. ZADÁNÍ TESTU

Obrázek D.1: Výsledný pavouk

Barvy a poměry mezi vzdálenostmi nemusí odpovídat, co ale musí odpovídat je, aby barva rámečku obdélníku byla různá od barvy výplně, čáry, které spojují obdélníky, musí být být rovné a text uvnitř rámečku vycentrovaný na střed. 2. Úkol Vaším úkolem nyní bude úprava fotky. V dnešní době levných kompaktních fotoaparátů je téměř nutností před tím, než pořízenou fotku někomu ukážete, ji upravit v některém z grafických editorů a odstranit chyby, které nekvalitní fotoaparáty produkují.

Obrázek D.2: Fotka k úpravě

Pomocí GIMPu upravte fotku ze souboru „fotkaKUprave.jpg“, aby co nejvíce odpovídala výsledné fotce (soubor „vyslednaFotka.jpg“).

D.1. INSTRUKCE

59

Chyby vyskytující se na fotce : • červené oči hráčky a brankářky • rozostřená hráčka • mdlé barvy 3. Úkol Vaším posledním úkolem bude vytvoření koláže z několika referenčních fotek. Výsledná koláž by měla přibližně vypadat tak, jako je uvedeno na obrázku „vyslednaKolaz.jpg“. Všechny obrázky, které potřebujete, máte k dispozici ve složce s úkolem.

Obrázek D.3: Výsledná koláž

60

PŘÍLOHA D. ZADÁNÍ TESTU

Příloha E

Obsah přiloženého CD • exe – IVETool ∗ ve složce bin je spustitelný soubor – MentalModelPlugin ∗ obsahuje .nbm soubory se zásuvným modulem do aplikace IVETool – libs ∗ obsahuje knihovny nutné ke spuštění pluginu • models – obsahuje modely jak uživatelské tak konceptuální – k dispozici jsou jako PNG soubory, projekt pro Enterprise Architekt a XML soubory pro vizualizaci pluginem • src – MentalModelGraphMLImporter ∗ zdrojové kódy části pluginu, která má na starosti import modelu do aplikace – MentalModelViz ∗ zdrojové kódy pluginu pro vizualizaci • text – obsahuje text bakalářské práce v PDF formátu • textsrc – obsahuje zdrojový text bakalářské práce v TEX formátu

61

Analýza konceptuálního modelu aplikace. Vojtěch Šívr

Recommend Documents