Manuál (verze 1.0)
Masarykova univerzita
© 2013-2016 Tilioteo Ltd
Hypothesis 1.5.4
webová platforma
Autoři: Kamil Morong
Čeněk Šašinka
Pavel Ugwitz
Obsah
1 ÚVOD ____________________________________________________________________________________________________________ 1
1.1 Aplikace v oblasti kognitivní kartografie________________________________________________________________________________________________________ 1
1.2 Užití na poli psychologické diagnostiky_________________________________________________________________________________________________________ 2
2 HYPOTHESIS – HLAVNÍ CHARAKTERISTIKY A ARCHITEKTURA ___________________________________________________________________ 2
2.1 Hierarchická struktura testové baterie _________________________________________________________________________________________________________ 3
2.2 Počítačové adaptivní testování (Computer Adaptive Testing) ______________________________________________________________________________________ 6
2.3 Multi-player/task tests______________________________________________________________________________________________________________________ 7
2.3.1 Multi-task mode: synchronní běh testů _____________________________________________________________________________________________________ 7
2.3.2 Multi-player mode – asynchronní běh testů__________________________________________________________________________________________________ 7
2.4 Managerský modul _________________________________________________________________________________________________________________________ 8
2.4.1 Administrátor účtů (správa účtů) __________________________________________________________________________________________________________ 8
2.4.2 Slide editor ____________________________________________________________________________________________________________________________ 8
2.4.3 Nabídka testových baterií a módy testování _________________________________________________________________________________________________ 9
2.4.4 Exportní modul________________________________________________________________________________________________________________________ 10
2.5 Selekční aplikace__________________________________________________________________________________________________________________________ 10
3 FUNKCIONALITA STÁVAJÍCÍCH SLIDŮ____________________________________________________________________________________ 11
3.1 Dotazníky________________________________________________________________________________________________________________________________ 11
3.2 Obrazové podněty ________________________________________________________________________________________________________________________ 11
1
3.3 Ovládání slidu ____________________________________________________________________________________________________________________________ 11
3.4 Uživatelské akce a jejich ovládání ____________________________________________________________________________________________________________ 12
3.5 Dialog window ___________________________________________________________________________________________________________________________ 12
3.6 Mapy ___________________________________________________________________________________________________________________________________ 12
3.7 Audio a video ____________________________________________________________________________________________________________________________ 13
3.8 Image-Sequence Layer _____________________________________________________________________________________________________________________ 13
3.9 Implementace Processing.js_________________________________________________________________________________________________________________ 13
4 TECHNICKÉ ŘEŠENÍ _________________________________________________________________________________________________ 13
4.1 Přesnost měření z hlediska času _____________________________________________________________________________________________________________ 14
5 PROPOJENÍ S EYETRACKING SYSTÉMEM _________________________________________________________________________________ 15
6 AKTUÁLNÍ VÝVOJ A DOSTUPNOST PLATFORMY____________________________________________________________________________ 15
REFERENCE_________________________________________________________________________________________________________ 18
1
1 Úvod
Charakter platformy Hypothesis vychází z kontextu spolupráce mezi
psychology a kartografy. V rámci výzkumného záměru „Dynamic
geovisualization in crises management“ (Konečný et al., 2011; Kubíček et al.,
2013) vznikla potřeba vyvinout výzkumný nástroj, který by umožňoval
sledovat činnost uživatele při práci s kartografickými produkty včetně těch
interaktivních a zároveň umožnil vytvářet a administrovat psychologické
testy. Interaktivní elektronické mapy jsou v současné době nejčastěji
komponovány na straně klienta ve webovém prohlížeči (Evans and Sabel,
2012), a proto bylo potřeba i koncepci připravované platformy od začátku
koncipovat jako webovou aplikaci. Tak vznikla aplikace s názvem MuTeP
(Multivariate Testing Program), která pracovala na bázi klient–server
a umožňovala na mapových podkladech provádět různorodé činnosti, jako je
např. bodové označování objektů, výběr linií, zakreslování tras atp. (Kubíček
and Šašinka, 2011; Štěrba et al., 2014; Stachoň et al., 2013; Konečný et al.,
2011, Kubíček et al., 2011, Kubíček et al., 2016).
Stejná funkcionalita byla zároveň užívána při tvorbě performačních
psychologických testů a úloh mj. při adaptaci Framed-line testu (Kitayama et
al., 2003) či Embedded figure testu (Witkin et al., 1971). Koncepce aplikace
MuTeP však vykazovala principiální limity v několika aspektech, mj.
neumožňovala adaptivní testování. Proto byla ve druhém kroku na základě
zkušeností s aplikací MuTeP vyvinuta zcela nová platforma – Hypothesis –
která překonala omezení předchozího systému.
Při definování architektury platformy Hypothesis byl od začátku kladen důraz
na šíři a variabilitu funkcionality a flexibilitu při tvorbě konkrétních testových
úloh a baterií.
1.1 Aplikace v oblasti kognitivní kartografie
Kartografické vizualizace představují komplexní grafický podnětový materiál
(Thorndyke and Stasz, 1979; Edler et al., 2014), ve kterém vždy dochází
k interakci mezi formou a obsahem. Výzkumník v rámci testování užívá pro
každou úlohu stejného typu vždy nová území, a proto je třeba vždy definovat
i nová správná řešení. Potřebné flexibility při tvorbě jednotlivých slidů bylo
v případě platformy Hypothesis dosaženo díky logice propojení unikátních
slide templatů (slide templates) a na ně navázaných slide contentů (slide
contents) (viz kapitola 2.1), ve kterých lze dle potřeby modifikovat podnětový
materiál či hodnoty správných řešení.
Na mapě uživatel běžně vykonává různorodé činnosti a typy operací
(Crampton, 2002; Roth, 2013) od zcela jednoduchého „vizuálního
vyhledávání a označování“ bodových objektů či cílových oblastí, přes
„srovnání či řazení objektů“ jedné kategorie, složitější operace typu
„vyhledání optimální trasy“ či „průchodivost terénem“ (Hofmann et al., 2015;
Devlin and Bernstein, 1997), až po činnosti velice komplexní, jako je operační
řízení v krizovém managementu (Vakalis et al., 2004, Ilmavirta, 1995,
Konečný et al., 2006), rozhodování v oblasti agrikultury (Kubíček et. al,
2013) či analýza zločinnosti (Roth et al., 2015). Design platformy Hypothesis
umožňuje realizovat jak experimenty na „molekulární úrovni“, tak studie
zkoumající spíše „molární chování“ uživatele (Baum, 2002).
V prvním případě je tedy cílem zkoumat spíše bazální kognitivní procesy.
Jedná se o úlohy zaměřené na vizuální vyhledávání či zapamatování,
ve kterých je analyzována rychlost, správnost a přesnost řešení, popř. četnost
řešení na souboru zkoumaných osob.
Ve druhém případě se výzkumník zaměřuje na vyšší kognitivní procesy
a zkoumá strategie užité při řešení problému. Analyzovaným chováním je
potom sekvence operací na mapě, např. vyvolání legendy, zoomování, posun
2
mapy, přepínání mezi vrstvami mapy, zaznačení cílových oblastí a jejich
propojení optimálními trasami.
1.2 Užití na poli psychologické diagnostiky
Široká funkcionalita a možnost interaktivně prezentovat bohatý grafický
materiál spolu s centrální databází a propracovaným managerským modulem
předurčuje platformu Hypothesis k použití na poli psychologické diagnostiky.
Platforma umožňuje nově vytvářet či adaptovat celou řadu psychologických
performačních testů, které dříve existovaly jen ve verzi tužka-papír (Mead
and Drasgow, 1993) Hypothesis umožňuje vyhodnocovat akce uživatele již
v průběhu testování, a v tabulce Results jsou tak poté dostupná nejen hrubá
data, ale i vypočítané skóry a indexy. V současné době bylo již nově
vytvořeno či adaptováno několik testů, mj. D2 Test of Attention (Ross, 2005),
Trail Making Test či Test of Grammatical Transformation (Baddeley, 1968;
Giovagnoli et al., 1996).
2 Hypothesis – hlavní charakteristiky a architektura
Platforma Hypothesis se skládá z managerského modulu a databáze.
Databáze, která obsahuje jak jednotlivé slidy, celé testové baterie (packs), tak
i získané výsledky, je umístěna na centrálním serveru. Uživatelé
i administrátoři přistupují přes běžný webový prohlížeč do managerského
modulu (obr. 1).
Po přihlášení nabízí prostředí managerského modulu několik dílčích
funkcionalit.
Testovaným osobám je dostupná pouze nabídka testových baterií (list of
test baterries), které dle nastavení administrátorem mohou spustit buď
v základním módu (fullscreen okna běžného prohlížeče), nebo
v kontrolovaném módu (SWT browser).
Administrátoři (uživatelé vyšší úrovně Manager či Superuser) mají kromě
zmíněné nabídky spustitelných testů k dispozici rovněž administrační modul
(user administration module), ve kterém spravují uživatelské účty pro
jednotlivé uživatele či skupiny uživatelů. Administrátor dále disponuje
exportním modulem, který umožňuje export hrubých dat (raw data)
z tabulky Results ve formátu .xlsx. Pro post-processing hrubých dat byla
vytvořena samostatná selekční aplikace. Administrátor rovněž při přípravě
nových testů využívá slide editor, který umožňuje zobrazovat a editovat
slide. Administrátor má možnost editovat připravované slidy přístupem přes
webový prohlížeč, vlastní tvorba testových baterií už ale probíhá přímo
v databázi.
Dlouhodobá vize rozvoje a užívání platformy Hypothesis je postavena na
dvou aspektech – sdílení a kumulace. Předpokladem sdílení i efektivní
kumulace je umístění databáze na centrálně přístupný server. Sdílením se
rozumí nejen možnost využívat již hotové testy či jejich části, a to
i geograficky vzdálenými pracovními skupinami, ale rovněž možnost se
kolaborativně podílet na jejich tvorbě.
3
Díky webovému řešení platformy je možné zpřístupnit při publikování
výzkumných studií i použité výzkumné baterie jako takové, a tedy i originální
podnětový materiál a design experimentů. Rovněž se nabízí možnost
zpřístupnit vědecké obci i databázi výsledků, resp. raw data experimentů.
Kumulace probíhá ve dvou rovinách. Jednak různé pracovní skupiny
postupně sestavují celé výzkumné baterie či dílčí tasky, které zůstavají
následně k dispozici pro budoucí užití v původní podobě (např.
psychodiagnostické testy) nebo mohou být užity po částečných úpravách.
Druhým případem kumulace je postupná implementace funkcionality, která
je nutná pro realizaci konkrétních testových baterií. Tato nově
implementovaná či vytvořená funkcionalita je následně dostupná ve formě
připravených šablon (slide templates). Postupnou výzkumnou činností se tak
kumulativně rozšiřuje funkcionalita a užitný potenciál platformy jako celku
a zároveň se kumulují hotové testy či různé typy tasků použitelné při dalších
navazujících studiích.
2.1 Hierarchická struktura testové baterie
Nejvyšší úroveň struktury představují testové baterie tzv. packy (packs),
které jsou dále členěny dle navržené hierarchie (viz obr. 3). Testová baterie,
resp. pack, je z pohledu uživatele tvořena sérií slidů, které jsou nejčastěji
řazeny lineárně. To znamená, že je dopředu dáno pevné pořadí slidů a uživatel
prochází postupně všechny slidy od začátku do konce ve stanoveném pořadí.
Řazení slidů může být ale rovněž znáhodněné či vykazovat stromovou, popř.
cyklickou strukturu (viz kapitola 2.2).
Samotné slidy jsou seskupovány do vyšších celků tzv. tasků. To se provádí
arbitrárně, nejčastěji dle logiky testové baterie a tematické příbuznosti.
V praxi při tvorbě testové baterie (packu) administrátor vytváří nejčastěji
několik tasků, např.:
1. úvod a osobní údaje,
2. instrukce,
3. zácvik,
4. testové úlohy,
5. zpětná vazba o výkonu a závěr atp.
Obrázek 1 Základní funkční komponenty platformy Hypothesis: a) database (kapitola 4), b)
manager module (2.4) s export modulem (2.4.4), user administration modulem (2.4.1),
seznamem přístupných testů (2.4.3) a slide editorem (2.4.2), c) uživatelské rozhraní
webového prohlížeče umožňující základní, resp. kontrolovaný mód sběru dat pomocí SWT
browseru (2.4.3) a d) selekční aplikace (2.5).
4
Členění slidů do vyšší struktury tasků umožňuje jednoduché a efektivní užití
těchto již hotových tematických celků v dalších testových bateriích.
Jednotlivé hierarchické úrovně testové baterie jsou definovány a provázány
v tabulkách databáze (obr. 2).
Základní jednotkou testové baterie je slide. Samotný slide je tvořen dvěma
částmi – slide templatem s asociovaným slide contentem (viz obr. 3). Dle
filozofie tvorby testových baterií by do slide templatu měly být soustředěny
všechny záležitosti týkající se struktury slidu. Jedná se zejména o definici
vizuálního uspořádání komponent, všech případných dialogových oken
a funkční logiky slidu. Jednou vytvořené slide templaty jsou uloženy
v centrální databázi a je možné je vždy znovu použít (a to i jinými
výzkumnými týmy) pro jiný experiment v původní podobě či je mírně upravit
dle aktuálních požadavků, a vytvořit tak jejich mutace.
Funkční logika slidu představuje odezvy systému na chování probanda a je
tvořena definicí ovládacích nástrojů (např. pro zoom či posun interaktivní
mapy, zakreslování bodu, lomené linie či polygonu, dialog window, časovač)
a obsluhy událostí komponent (např. kliknutí na tlačítko, stisk klávesy apod.),
definicí akcí navázaných na tyto události, definicí proměnných používaných
v rámci slidu, definicí případných čítačů a nakonec definicí výstupních hodnot
ze slidu ukládaných do databáze.
Slide content je vždy asociován s konkrétním slide templatem a určuje, jaký
konkrétní obsah bude finální slide zobrazovat. Jestliže je např. v slide
templatu definovaná přítomnost a formát tlačítek, obrázku a textového bloku,
potom slide content nejčastěji určuje, jaká konkrétní označení tlačítka nesou,
který obrázek se zobrazí a jaký text bude prezentován.
Obrázek 2 Obsahy tabulek Slide, Task a Branch jsou s vyšší hierarchickou úrovní
provázány pomocí párovacích tabulek - task-slide, branch-task a pack-branch. Slidy
(contenty) jsou asociovány s odpovídajícími slide templaty pomocí unikátních ID.
5
Obrázek 3 V tabulkách databáze jsou ukotveny hierarchické vazby mezi slide template, slide (content) a task-slide. Tabulka Slide template obsahuje jednotlivé slide templaty, které definují
charakter slidu. Přes unikátní GUI jsou propojeny se slidy, resp. slide contenty. Ve slidu je definovaný obsah vázán vždy na konkrétní slide templaty. Typicky je na jeden slide template vázáno
více slide contentů. Slidy (content) jsou asociovány v tabulce task-slide s konkrétními vyššími celky – tasky.
6
Samotné tasky nejsou asociovány s packem přímo, ale přes meziúroveň,
tzv. branch. Tasky jsou v rámci branche řazeny lineárně a mají pevně dané
pořadí. Smyslem branche je efektivní tvorba testových baterií (packů)
umožňujících computer adaptive testing. Nejjednodušší forma testové baterie
(packu) je lineární a obsahuje jeden branch, ve kterém je seřazen daný počet
tasků (viz obr. 4). Složitější packy mají stromovou strukturu a testovaná osoba
prochází postupně jednotlivými větvemi (branches) na základě svého
aktuálního výkonu. Rovněž je možné cyklicky opakovat jeden branch do té
doby, než je dosaženo požadované úrovně výkonu, např. vyžadovaného
procenta správných řešení u zácviku (viz obr. 5).
2.2 Počítačové adaptivní testování (Computer Adaptive Testing)
Platforma Hypothesis umožňuje počítačově adaptivní testování (CAT)
(Jelínek et al., 2006; Žitný et al., 2012; Květon et al., 2008; Gershon,
2005), a to hned na několika úrovních hierarchie testové baterie: na
úrovni branches, na úrovni tasku, resp. skupiny slidů, a rovněž v rámci
realizace jednoho slidu.
První, elementání stupeň představuje adaptivitu v rámci vykonávání
jednoho slidu. Vybrané události mají nastaveny své oblužné akce, ve
kterých jsou přiřazeny hodnoty definovaným proměnným a jsou s nimi
prováděny základní aritmetické či logické operace. Dostupné jsou
větvící algoritmy (IF - THEN - ELSE, SWITCH), či smyčky (WHILE),
kterými může být řízen běh v rámci jedné slidy. Pro optimalizaci
adaptivního testování na této úrovni byl vytvořen specializovaný slide
tzv. image-sequence-layer (viz kapitola 3.8).
Druhý stupeň adaptivity existuje na úrovni tasku jakožto souboru
jednotlivých slidů. Na základě výstupů z právě dokončeného slidu (slide
outputs), ale i ze série předchozích slidů, je dle definovaného pravidla vybrán
další následující slide. Pravidla určující průběh konkrétního tasku jsou
definována v databázi v tabulce Task. Za speciální případ řazení slidů v rámci
tasku lze považovat randomizaci. Shrnuto, task nabízí tři módy průběhu:
linerární řazení slidů, randomizované řazení pro každé spuštění testu
a adaptivně se měnící.
Poslední stupeň adaptivity představují větve (branches), které rovněž určují
přechod k následující větvi či ukončení testové baterie na základě
vyhodnocených podmínek. Vyhodnocení se děje vždy až na konci příslušné
branche.
Obrázek 4 Vlevo je uvedeno schéma struktury testové baterie resp. packu číslo 5, který
obsahuje pouze jednu branche číslo 5 . Branche dále obsahuje dva tasky 3 a 4 a ty několik
lineárně řazených slidů. Vpravo je zobrazen hypotetický pack 6, který již obsahuje několik
větví.
7
2.3 Multi-player/task tests
Jednou z výrazných charakteristik platformy je tzv. multi-player/task mode.
V reálném čase spolu buď interagují dva či více uživatelů najednou při řešení
jedné úlohy, nebo naopak jeden uživatel obsluhuje více různorodých, ale
zároveň propojených úloh. V prvním případě se jedná o tzv. asynchronní běh
testů, druhá třída je definována jako synchronní testování.
1
https://www.schuhfried.at/test/PP-R
2.3.1 Multi-task mode: synchronní běh testů
Synchronní běh testů je založen na principu řídicí (master) a podřízené (slave)
testové baterie, resp. packu. Funkcionalita byla vyvinuta pro typ experimentů,
ve kterých jeden uživatel plní paralelně více úloh nebo je nucen sledovat dění
na více obrazovkách zároveň.
Multi-task mode byl ověřen vytvořením testu periferního vnímání, který je
adaptací původní diagnostické metody „PP-R Periphere Wahrnehmung – R“
společnosti Schuhfried (Karner and Neuwirth, 2001). Tento původní test je
součástí Wiener testsystem a je vázán na specializované hardwarové
vybavení.1
Ve zkušebním testu byla oveřena funkcionalita synchroního
testování, ve kterém uživatel plní primární úlohu na hlavním monitoru
označováním cílových objektů klikáním myši a zároveň reaguje stisknutím
klávesy na klíčové stimuly prezentované na periferních monitorech (obr. 5).
2.3.2 Multi-player mode – asynchronní běh testů
Multi-player mode byl primárně zamýšlen pro účely výzkumu v oblasti geokolaborace
(Krek and Bortenschlager, 2006; MacEachren et al., 2005).
V případě multi-player módu interagují dva či více uživatelů při řešení
totožné úlohy. Všechny testy jsou ovládány jednotlivými uživateli nezávisle,
avšak může v nich docházet k synchronizačním pauzám v případě, kdy je další
běh testu podmíněn akcí jiného uživatele. Jedná se tedy o typ testu, ve kterém
všichni uživatelé řeší stejnou úlohu, ale tvůrce testové baterie může definovat
různé podmínky jejího průběhu. Tvůrce úlohy může nastavit, který uživatel
odpovídá jako první či v jakém pořadí se událost, např. zobrazení obrázku,
prezentuje jednotlivým uživatelům. Multi-player mode byl rovněž
implementován při adaptaci experimentálních úloh z oblasti sociální
psychologie (obr. 6) či behaviorální ekonomie (Asch, 1951; Ciampaglia et al.,
2014).
Obrázek 5 Schéma multi-task módu. Uživatel plní primární úlohu na centrálním monitoru či
zařízení, které obsluhuje myší (Master pack). Zároveň reaguje vybranými klávesami na cílové
stimuly, které jsou prezentovány na periferních monitorech (slave packs).
8
2.4 Managerský modul
Managerský modul představuje rozhraní, kterým přistupují uživatelé
k samotné aplikaci. Pro uživatele jsou definovány tři možné role: superuser,
manager a user. Běžný „user“ může pouze vybírat a spouštět zpřístupněné
testy. Superuser a manager mají nadto přístup i k dalším modulům:
administrátorovi účtů (správa účtů), exportnímu modulu a slide editoru.
Přihlášení se provádí za pomocí uživatelského jména a hesla. Bez přihlášení
je možné přistoupit do managerského modulu jako guest, resp. spustit pouze
volně zpřístupněné testové baterie.
2.4.1 Administrátor účtů (správa účtů)
V rámci správy uživatelských účtů lze každému uživateli nastavit jeho jméno,
heslo a úroveň jeho práv prostřednictvím role. Uživatel s rolí superuser má
neomezené možnosti z hlediska správy všech uživatelů, testů a rovněž
přístupu k výsledkům.
Manager má k dispozici své skupiny, v jejichž rámci může vytvářet jednotlivé
uživatele a přidělovat testové baterie. Manager má díky exportnímu modulu
přístup k výsledkům z testových baterií, které byly realizovány členy jeho
skupiny. Může rovněž využívat slide editor.
Nejnižší úroveň user je určena pro testované osoby, kterým je umožněno
pouze spustit testovou baterii. Dostupnost jednotlivých testových baterií,
resp. jejich expiraci a způsob spuštění, nastavuje manager či superuser
(obr. 7).
Administrátor účtu umožňuje vytvářet a editovat uživatele hromadně
a exportovat rovněž hromadně ve formátu .XLSX i tyto seznamy účtů včetně
příslušných atributů, např. automaticky generovaných hesel (obr. 7).
2.4.2 Slide editor
Součástí funkcionality managerského modulu na úrovni superuser a manager
je slide editor, který slouží ke zobrazování a editaci připravovaných slidů.
Uživatel kopíruje XML kód připravovaného slidu (content a template) přímo
do k tomu určených oken v manager modulu. Následně může být tento slide
Obrázek 6 Užití multiplayer módu při počítačové adaptaci experimentu S. Asche
zkoumajícího vliv sociálního tlaku na konformitu. Všem participantům je nejdříve exponován
ve stejný čas totožný objekt. Následně mají odhadnout jeho velikost zakreslením linie.
Zakreslená linie se bezprostředně zobrazí i dalším dvěma participantům.
9
spuštěn, a případně rovnou upravován. Ověřený, popř. upravený kód je
následně nahrán do databáze.
2.4.3 Nabídka testových baterií a módy testování
Platforma Hypothesis umožnuje několik variant spuštění a běhu testu, kterou
administrátor volí podle kontextu testování. Pro účely sběru dat, ve kterém
nejsou vyžadovány kontrolované podmínky, např. při online dotazníkovém
šetření, lze spustit test v běžném webovém prohlížeči.
Test je spuštěn z nabídky testů do full screenu pop-up window či alternativně
otevřením nového okna prohlížeče kliknutím na HASH odkaz. Administrátor
má možnost nastavit, zda bude uživateli povoleno spuštění konkrétního testu
v kontrolovaném módu (featured) či v běžném módu (legacy), či bude dána
možnost volby (obr. 8). Kontrolovaný mód je realizován pomocí browseru
postaveného na komponentách SWT. Pro spuštění v SWT browseru (Cornu,
2004) je vyžadována instalace běhového prostředí Java (Java Runtime
Environment). Po spuštění testu v SWT browseru jsou uživateli omezeny
takřka všechny funkce, kterými disponuje běžný webový prohlížeč a které
mohou potenciálně narušit kontrolovaný průběh testu. SWT browser spustí
test v režimu celé obrazovky a neumožní ukončit aplikaci běžným způsobem,
např. klávesovou zkratkou Alt+F4, pomocí tlačíka escape a rovněž zamezuje
použít funkci „aktualizace stránky“ či vyvolat kontextové menu pravým
tlačítkem myši apod. Vzhledem k postupnému omezování podpory java
v prohlížečích je aktuálně testován alternativní způsob pro zajištění
kontrolovaného módu (viz kapitola 6).
Obrázek 7 Ukázka administrátora účtů: nahoře editace nového uživatele či hromadně více
uživatelů; dole seznam označených uživatelů vybraných pro export.
10
2.4.4 Exportní modul
Platforma Hypothesis ukládá akce a události vznikající při testování do
tabulky Results. Tvůrce testové baterie má zároveň možnost definovat klíčové
cílové proměnné či definovat pravidla pro jejich agregaci nebo vyhodnocení.
Tyto hodnoty jsou potom ukládány jako zvláštní proměnné – slide outputs.
Součástí managera je exportní modul (obr. 9), ve kterém administrátor
nejdříve volí požadovanou testovou baterii a následně vybírá časové období,
popř. konkrétní administrace testů, které budou následně vyexportovány ve
formátu .xslx. Tento soubor obsahuje veškerá raw data a je určen pro další
zpracování.
2.5 Selekční aplikace
Pro efektivní výběr, resp. pro filtraci požadovaných proměnných obsahující
veškerá raw data a pro jejich úpravu do formátu vhodného pro následnou
analýzu je k dispozici selekční aplikace vytvořená ve Visual Basic. Selekční
aplikace prohledá datový soubor a vybírá hodnoty či části řetězců na základě
definovaných podmínek. Selečkní aplikace obsahuje vždy triplety listů:
1) list s načtenými raw daty,
2) list, ve kterém uživatel definuje proměnné, jejichž hodnoty chceme
selektovat,
3) list, kde jsou vyselektovány cílové hodnoty.
Obrázek 10 Exportní modul s označenými dokončenými testy
Obrázek 8 Testové baterie z nabídky v kontrolovaném (featured) či běžném módu
(legacy).
11
3 Funkcionalita stávajících slidů
Jedna ze základních koncepčních charakteristik platformy Hypothesis je
modulárnost, která umožňuje kontinuální rozvoj a rozšiřování funkcionality.
Platformu Hypothesis lze chápat jako výkonné jádro složené z content
managementu testových baterií, testového procesoru pro renderování slidů
a event loggeru s datovým skladem. Díky otevřenému API lze vytvářet další
externí moduly implementující nové komponenty a/nebo implementovat
rozšiřující funkce, které mohou obsahovat výpočetní algoritmy.
Výchozí sestava obsahuje implementaci základních komponent, mezi které
patří vertikální a horizontální layout pro členění obrazovky, formulářové
prvky (např. TextField, ComboBox, SelectPanel), dále Button, Image, Panel,
Label, či komponenty pro Audio a Video. Specifickou funkcionalitu
představují dialog Window a Timer. Další implementované komponenty jsou
součástí dvou extra dodávaných modulů – Maps pro interaktivní mapy
a Processing pro užití interaktivních animací vytvořených v jazyku
processing.
3.1 Dotazníky
Běžnou součástí výzkumných baterií jsou nejrůznější formuláře umožňující
sběr osobních dat či zjišťování postojů na Likertových škálách. Pro tento účel
jsou k dispozici vyplňovací textová pole (text fields), rozbalovací seznamy
(dropdown lists), škály atd. Tyto komponenty umožňují okamžité ověření
zadávaného vstupu, čímž může být kontrola povinného vyplnění položky či
zadání čísla v určeném intervalu.
3.2 Obrazové podněty
Pro běžné zobrazení podnětů se používá obrázek (image). Podporovány jsou
všechny běžné rastrové formáty obrázků (png, jpeg, gif,…). Při přípravě
podnětů je vhodné volit grafický formát s ohledem na typ obsahu a minimální
velikost souboru. Například pro schematické, málo barevné, čárové podněty
je vhodný formát GIF či PNG, zatímco pro plnobarevné podněty, jako jsou
fotografie, je vhodný formát JPEG. Zcela se nedoporučuje používat formát
BMP, který nepoužívá žádnou metodu komprese obrazových dat a soubory
jsou tak enormě velké. Při návrhu slidu s obrazovým podnětem je třeba počítat
s různou, předem nedefinovanou dobou načítání obrazových dat, které
je ovlivněno zejména fyzickou velikostí souboru a rychlostí internetového
připojení. Webové browsery standardně využívají cache pro ukládání dříve
načtených obrázků, proto se pro opakované zobrazení stejného souboru
(identické URL adresy obrázku) použije dříve uložený soubor v lokálním
počítači, což může být násobně rychlejší než první zobrazení unikátního
obrázku. Různou dobu načítání obrázků lze eliminovat pomocí maskování
do doby jeho načtení. Komponenta Image nabízí jednoduché snímání kliku
myší, při kterém jsou zaznamenány koordináty odpovídající obrazovým
pixelům.
3.3 Ovládání slidu
Interakce s obsahem slidu může být zajištěna pomocí tlačítek, a to buď
samostatným tlačítkem (button), nebo jejich skupinou (button panel, který
zjednodušuje použití např. v případech výběru z více odpovědí). Další
možnost ovládání je pomocí klávesnice, kdy lze snímat stisk kláves, a to jak
alfanumerických, tak i speciálních (kurzorové či funkční klávesy apod.).
Běh může být řízen také nezávisle na uživateli pomocí časovače (timer),
přičemž zbývající čas může být prezentován v rámci slidu. Běžící časovač lze
libovolně zastavit a opakovaně spouštět. Nejčastěji používaná je událost
doběhnutí časovače (stop), avšak využitelné je i spuštění časovače (start)
nebo signalizace nastaveného pravidelného intervalu v události (update).
Na stisk tlačítek, kláves a události časovačů jsou typicky navázány akce, které
řídí průběh slidu.
12
3.4 Uživatelské akce a jejich ovládání
V rámci slidu lze definovat libovolné uživatelské akce, které představují
samostatně vykonatelné a pojmenované subrutiny. Akce sestávají
z vyhodnotitelných výrazů, které mohou být logické, matematické, mohou
volat funkce objektových proměnných nebo rozhodovat dle větvicího výrazu
(např. IF-THEN-ELSE, SWITCH-CASE).
Akce mají své místo při obsluze událostí, kterými jsou např. doběhnutí
časovače, stisk tlačítka, stisk klávesy, kliknutí do obrázku apod. Akce lze
mezi sebou vzájemně volat, což je výhodné zejména při užití větvení nebo při
sestavování složitější akce, která je tak složena z jednotlivých dílčích částí.
Neocenitelnou výhodou použití akcí je zamezení opakování stejného kódu na
více místech nahrazením volání jedné akce a navíc je každé spuštění akce
uloženo do tabulky událostí.
Používání akcí tak vede k přehlednějšímu a srozumitelnějšímu zápisu
funkčního algoritmu slidu.
3.5 Dialog window
Funkce Dialog window se užívá např. pro opětovné vyvolání nápovědy při
řešení úlohy v rámci slidu. Dialog window se zobrazí voláním jeho příslušné
funkce a to může být asociováno např. se stiskem tlačítka či jakoukoliv akcí
v rámci definované logiky ve slidu. Ukončuje se zavřením okna kliknutím
na symbol křížku. Do databáze se ukládá tedy jak začátek, tak konec akce.
Dialog window může být otevřeno jako tzv. „nemodální“, umožňující práci
se slidem, nebo „modální“, kdy je vše okolo zneaktivněno a zatmaveno, čímž
může výzkumník odlišit aktuálně realizované činnosti participanta.
Po zavření modálního okna může participant dále pokračovat v započaté
činnosti, např. zadávání lomené linie atp.
3.6 Mapy
Mapová komponenta je obsažena v externím plug-in modulu. Hlavním
přínosem komponenty je implementace mapové kompozice, která se skládá
obvykle z jedné podkladové vrstvy a překryvné vrstvy vektorových prvků.
Podkladovými vrstvami může být interaktivní WMS mapa poskytovaná online
serverem nabízejícím WMS mapové služby. WMS vrstva vyžaduje
specifikaci geografického referenčního systému (CRS) a výchozího výřezu
(bounding box). Dle serverem poskytovaných dat může WMS vrstva
obsahovat jeden druh informace, nebo komplexní kartografickou informaci
v podobě mapové kompozice. Interaktivitu vrstvy následně zabezpečují
ovládací nástroje pro změnu měřítka (zoom) a posun mapového výřezu. Každá
změna vyvolává požadavek na server k aktualizaci dat.
Velmi užitečnou vrstvou mapové komponenty tedy je vrstva vektorových
prvků (feature layer). Tato vrstva obsahuje vektorové objekty, které mohou
být definovány v rámci specifikace vrstvy nebo zadány uživatelem pomocí
některého z nástrojů pro vytváření vektorových objektů. Vektorovým
objektům lze nastavovat různé vlastnosti, jako např. vizuální styl zahrnující
barvu obrysu, výplně, tloušťku čar. Pokud se nastaví objekt jako neviditelný,
s výhodou se tak používá jako aktivní oblast zájmu (area of interest). Takové
objekty s nastavenou obsluhou kliknutí jsou následně použity k přímému
vyhodnocování akcí probanda.
Další typ vrstvy, kterou nabízí mapová komponenta, je vrstva se statickým
obrázkem (image layer). Tento druh vrstvy nahrazuje základní komponentu
Image, neboť využívá výhody vektorové vrstvy a zároveň nástrojů pro
zadávání vektorových objektů. Tak vzniká sestava využitelná pro vytváření,
snímání a vyhodnocování komplexních úloh nad obrazovým podnětovým
materiálem.
Mapová komponenta umožňuje snímání kliknutí či užití nástrojů pro zadávání
bodu, úsečky, lomené linie a polygonu. Pokud je nastaven souřadnicový
13
systém, zejména ve spojení s WMS vrstvou, potom snímaná data obsahují
nejen informaci o souřadnici v obrazových pixelech, ale také ve skutečných
souřadnicích zobrazeného území.
3.7 Audio a video
Platforma disponuje dvěma základními mediálními komponentami. Pro
přehrávání zvukové stopy (nejčastěji formát mp3) slouží Audio, pro
přehrávání audiovizuálních souborů ve formátu podporovaném webovými
prohlížeči (nejlépe mp4) slouží komponenta Video. Přidanou vlastností video
komponenty je možnost snímání kliknutí do obrazu obdobně jako u statického
obrázku. Kromě koordinátů je zaznamenán také aktuální čas audiovizuální
stopy
3.8 Image-Sequence Layer
Komponentou, která významně rozšiřuje možnosti a šíři užití platformy
Hypothesis, je tzv. „Image-Sequence Layer“. Při standardním průchodu
testem se vždy přechází z jedné slidy na následující, což vyžaduje jistý čas
pro načtení podnětového materiálu ze serveru. Toto řešení však principiálně
znemožňovalo připravit takový typ úloh, ve kterém by se stimuly obměňovaly
s velkou frekvencí a s krátkou dobou expozice (např. v řádu max. desítek
milisekund). Při užití běžných slidů je rychlost a reliabilita prezentace
omezena rychlostí a stabilitou komunikace mezi serverem a klientem. Z toho
důvodu byla vytvořena tato speciální komponenta, která umožňuje načíst
podnětový materiál dopředu do paměti lokálního počítače, resp. cache
browseru, a realizovat tak i tachistoskopický typ testů (Godnig, 2003).
Vlastní prezentace se spustí vždy až po načtení veškerého obsahu. Do tohoto
okamžiku je slide neaktivní a může být zakryt maskou.
Další klíčovou vlastností je programovatelnost slidu. Lze tak definovat
algoritmus určující průběh slidu a umožňuje znovu mimo jiné právě
počítačové adaptivní testování i na úrovni slidu.
3.9 Implementace Processing.js
Processing je dalším externím modulem, který rozšiřuje možnosti platformy
Hypothesis. Přináší stejnojmennou komponentu, jejímž smyslem je použití
aplikací vytvořených v programovacím jazyce Processing, respektive jeho
webové implementaci Processing.js. Processing je vizuální programovací
jazyk nabízející integrované vývojové prostředí, které je srozumitelné
a uživatelsky přívětivé i pro jedince pouze se základními znalostmi
programování. Processing byl vytvořen pro účely vizualizace dat,
interaktivních animace, videohry a dalšího grafického materiálu (viz
Shiffman, 2008; Reas and Fry, 2010). Processing.js je sesterský projekt
programovacího jazyka Processing, byl vytvořen pro web a je interpretovaný
pomocí JavaScriptu a spustitelný v HTML5 kompatibilních browserech (viz
processingjs.org).
Díky vytvořenému rozhraní mezi platformou Hypothesis a Processing.js lze
vytvářet a administrovat celou řadu úloh, ve kterých je vyžadována vysoká
míra interakce ve vizuálně bohatém a komplexním prostředí. Dochází
k obsoustranné komunikaci mezi aplikací Processing a jádrem platformy
Hypothesis, a tak je možné řídit průběh úlohy běžící v Processing.js a rovněž
ukládat klíčové události v definované podobě do databáze platformy
Hypothesis. Každá událost či akce v Processing.js může pomocí callback
metody volat akci definovanou ve slidu, a tím může být ovlivněn průběh slidy.
Naopak, slide může zavolat metodu processingového kódu, a tím ovlivnit běh
processingové aplikace.
14
4 Technické řešení
Platforma vznikla za použití moderní technologie dynamických webových
stránek. Jádro a rozhraní stojí na rámci Vaadin 7, databázové operace
zajišťuje Hibernate ORM a PostgreSQL ve verzi 9.1 (nebo vyšší) slouží jako
primární databázový systém.
Architektura aplikace má tři vrsty: klient, server a databáze (obr. 10). Klient
má na starosti užitelské interakce a běží na standardním webovém prohlížeči
nebo na speciálním browseru, který je součástí balíčku aplikace – Hypothesis
Browseru. Ten se postaven na komponentách SWT a umožňuje přísnější
podmínky pro administraci testů. Vrstva klient komunikuje na pozadí se
serverem prostřednictvím technologie Ajax RPC (remote procedure call).
Server je implementován jako servlet serveru aplikace (např. Apache
Tomcat), který zajišťuje zpracování klientských požadavků a update
uživatelského rozhraní.
4.1 Přesnost měření z hlediska času
Velká pozornost při vývoji byla věnována přesnosti měření z hlediska časové
komponenty. Řešení postavené na bázi server–klient, zvláště pokud jsou
obslužné akce ovládány na straně serveru, má oproti desktopovým aplikacím
principiální nevýhodu právě v důsledku prodlení, vznikajícího při komunikaci
mezi serverem a klientem. Ve směru server–klient vznikají latence při
načítání obsahu, např. obrázků uložených na vzdáleném úložišti. V opačném
Obrázek 11 Schéma technického řešení
15
směru, klient–server, potom dochází k prodlení v odezvě systému na akce
uživatele. Například kliknutí myši je zaznamenáno na klientu a následně
odesláno na server. Při přenosu dochází k nespecifikovanému zpoždění
uložení této události i zpětné reakce systému na akci samotnou. Tato prodlení
se sice nejčastěji pohybují pouze v řádu milisekund, ale nejsou konstatní.
Variabilita v rychlosti komunikace mezi klientem a serverem tak představuje
šum, který znepřesňuje měření.
Z těchto důvodů bylo implemetováno několik řešení, která tato principiální
omezení kompenzují. Především se do databáze ukládá jak čas přijaté události
na serveru, tak jeho párový klientský čas. Např. při kliknutí myší je uložen
jak čas vzniku události na straně klienta, tak čas přijetí události na serveru.
Rozdíl párových časů je způsoben dobou přenosu po síti. Zatímco při instalaci
systému na lokální síti je prodlení zcela zanedbatelné, při přenosu po internetu
je závislé na externích faktorech.
Další řešení limitů představuje užití specializovaných typů slidů. Slide typu
image-sequence layer načítá veškeré obrázky před spuštěním úlohy do paměti
klienta, a eliminuje tak zpoždění při načítání obsahu v průběhu úlohy (viz
kapitola 3.8). Slidy uživající plugin processing.js zase přenášejí podstatnou
část obsluhy událostí na stranu klienta (viz kapitola 3.9). Celá úloha je potom
v principu řízena z lokálního počítače a do databáze jsou posílány pouze
klíčové události s klientským časem. Implementace processing.js zcela
eliminuje omezení řešení server–client a umožňuje vytvářet testové úlohy
vyžadující maximální časovou preciznost, např. v kontextu užití technologie
eyetrackingu.
2
http://www.smivision.com/en/gaze-and-eye-tracking-
systems/products/red250mobile.html
5 Propojení s eyetracking systémem
Platforma Hypothesis byla sice primárně určena pro extenzivní sběr dat,
zároveň byl všal vývoj od počátku koncipován s ohledem na budoucí
propojení s eyetracking systémy, které umožňují hloubkovou analýzu činnosti
uživatele. Díky využití již existující opensource aplikace Ogama (Voßkühler
et al., 2008) a následnému vývoji webové aplikace HypOgama je nyní možné
na platformě Hypothesis administrovat experimenty za současného užití
eyetracking systému SMI 250mobile2
či Eyetribe3
.
Stávající řešení je postaveno na ex-post synchronizaci dat eyetracking
systému a platformy Hypothesis (Popelka et al., 2016). Toto řešení je součástí
širší koncepce, která zahrnuje mj. i nástroj ScanGraph pro následnou
explorativní analýzu dat (viz Doležalová and Popelka, 2016). V současné
době je již ovšem zároveň vyvíjeno nové řešení umožňující nativní propojení
a real-time interakci platformy Hypothesis a eyetracker systému. Řešení je
technologicky postaveno na websocket komunikaci frameworku Vaadin
a jeho funkčnost byla již prakticky ověřena.
3
https://theeyetribe.com/
16
6 Aktuální vývoj a dostupnost platformy
Aktuální vývoj platformy je nyní především soustředěn, kromě již zmíněného
propojení s eyetracking systémem, na implementaci 3D technologie,
optimalizaci platformy pro tablety a vytvoření browseru na bázi Chromia.
Tato nově vyvíjená aplikace využívající open source projekt Chromium je
alternativou pro kontrolovaný sběr dat namísto původního řešení postaveného
na SWT browseru. Zároveň je připravována koncepce pro plně grafické
uživatelské rozhraní pro tvorbu testových baterií, které v budoucnu umožní
administrátorům přístup a editaci přes běžný webový prohlížeč.
Platformu Hypothesis je nyní možné využívat ve spolupráci s Masarykovou
univerzitou pro akademické účely či jiné nekomerční užití zdarma. V případě
zájmu o komerční užití platformy Hypothesis či jiný specifický typ užití je
možné sjednat formu a licenční podmínky individuálně.
18
Reference
1. Arnett JA, Labovitz SS. Effect of physical layout in performance of the Trail Making Test. Psychological Assessment. 1995; 7(2): 220–221.
doi:10.1037/1040-3590.7.2.220
2. Asch SE. Effects of group pressure on the modification and distortion of judgments. In: H. Guetzkow HS, editor. Groups, leadership and men. Pittsburgh:
Carnegie Press. 1951. pp. 177–190.
3. Baddeley AD. A 3 min reasoning test based on grammatical transformation. Psychonomic Science. 1968; 10(10): 341–342.
4. Baum WM. From molecular to molar: a paradigm shift in behavior analysis. Journal of the Experimental Analysis of Behavior. 2002; 78(1): 95-116.
5. Brychtová A, Coltekin A. An Empirical User Study for Measuring the Influence of Colour Distance and Font Size in Map Reading Using Eye
Tracking.The Cartographic Journal. 2016; 53(3): 202-212. doi: 10.1179/1743277414Y.0000000101
6. Ciampaglia GL, Lozano S, Helbing D. Power and Fairness in a Generalized Ultimatum Game. PLoS ONE. 2014; doi:10.1371/journal.pone.0099039
7. Cornu Ch. SWT browser: Viewing HTML pages with SWT Browser widget. 2004 August 26 [cited 30 October 2016]. Available
from: https://eclipse.org/articles/Article-SWT-browser-widget/browser.html
8. Crampton JW. Interactivity types in geographic visualization. Cartography and Geographic Information Science. 2002; 29(2): 85-98.
9. Devlin AS, Bernstein J. Interactive way-finding: map style and effectiveness. Journal of Environmental Psychology. 1997; 17(2): 99-110.
doi:10.1006/jevp.1997.0045
10. Doležalová J, Popelka S. ScanGraph: A novel scanpath comparison method using graph cliques visualization. Journal of Eye Movement Research.
2016; 9(4): 1-13. doi:10.16910/jemr.9.4.5
11. Edler D, Bestgen A-K, Kuchinke L, Dickmann F. Grids in Topographic Maps Reduce Distortions in the Recall of Learned Object Locations. 2014. doi:
10.1371/journal.pone.0098148
12. Evans B, Sabel CE. Open-Source web-based geographical information system for health exposure assessment. International Journal of Health
Geographics. 2012; 11(2): 1-12. doi:10.1186/1476-072X-11-2
13. Gershon RC. Computer Adaptive Testing. Journal of Applied Measurement. 2005; 6(1): 109-127.
14. Giovagnoli AR, Del Pesce M, Mascheroni S, Simoncelli M, Laiacona M, Capitani E. Trail making test: normative values from 287 normal adult controls.
The Italian Journal of Neurological Sciences. 1996; 17(4): 305–309. doi:10.1007/BF01997792
15. Godnig EC. The Tachistoscope: Its History and Uses. Journal of Behavioral Optometry. 2003; 14(2): 39-42.
19
16. Hegarty, M. and Waller, D. (2004). A dissociation between mental rotation and perspective-taking spatial abilities, Intelligence, 32(2), 175–191.
17. Hofmann A, Hošková-Mayerová Š, Talhofer V, Kovařík V. Creation of models for calculation of coefficients of terrain passability. Quality & Quantity.
2015; 49(4): 1679-1691.
18. Ilmavirta A. The use of GIS-system in catastrophe and emergency management in Finnish municipalities. Computers, Environment and Urban Systems.
1995; 19(3): 171-178.
19. Jelínek M, Květon P, Denglerová D. Adaptivní testování - základní pojmy a principy. Československá psychologie. 2006;50(2):163-173.
20. Karner T, Neuwirth W. Die Bedeutung der peripheren Wahrnehmung in der verkehrspsychologischen Untersuchung. Psychologie in Österreich. 2001;
21(3): 183–186.
21. Kitayama S, Duffy S, Kawamura T, Larsen JT. Perceiving an object and its context in different cultures: a cultural look at new look. Psychological
Science. 2003; 14(3): 201-206.
22. Konečný M, Březinová Š, Drápela MV, Friedmannová L, Herman L, Hübnerová Z, et al. Dynamická geovizualizace v krizovém managementu. 1st ed.
Brno: Masarykova univerzita; 2011.
23. Konečný M, Friedmannová L, Stanek K. An adaptive cartographic visualization for support of the crisis management. In: CaGIS publications –
Autocarto 2006. Vancouver WA: CaGIS; 2006. 100–105.
24. Konečný M, Kubíček P, Stachoň Z, Šašinka Č. The usability of selected base maps for crises management: users' perspectives. Applied Geomatics.
2011; 3: 189–198.
25. Kozhevnikov M, Hegarty M. A dissociation between object-manipulation and perspective-taking spatial abilities. Memory & Cognition. 2001; 29: 745-
756.
26. Krek A, Bortenschlager M. Geo-collaboration and P2P Geographic Information Systems. Current Developments and Research Challenges. 2006 June
[cited 30 October 2016]. In: Collaborative Peer to Peer Information Systems (COPS06) Workshop - WETICE 2006, Manchester, UK. Available
from: http://www.sel.uniroma2.it/cops06/papers/COPS06-Krek.pdf
27. Kubíček P, Kozel J, Štampach R, Lukas V. Prototyping the visualization of geographic and sensor data for agriculture. Computers and Electronics in
Agriculture. 2013; 97(9):83-91. doi:10.1016/j.compag.2013.07.007.
28. Kubíček P, Šašinka Č, Stachoň Z, Štěrba Z, Apeltauer J, Urbánek T. Cartographic Design and Usability of Visual Variables for Linear Features. The
Cartographic Journal. 2016; 2016(1): 1-11. doi:10.1080/00087041.2016.1168141
29. Kubíček P, Šašinka Č, Stachoň Z. Vybrané kognitivní aspekty vizualizace polohové nejistoty v geografických datech. [Selected Cognitive Issues of
Positional Uncertainty in Geographical Data]. Geografie - Sborník České geografické společnosti. 2014; 119(1): 67-90.
20
30. Kubíček P, Šašinka Č. Thematic Uncertainty Visualization Usability – Basic Methods Comparison. Annals of GIS. 2011; 17(4): 253-263.
doi:10.1080/19475683.2011.625978.
31. Květon P, Jelínek M, Denglerová D, Vobořil D. Software pro adaptivní testování: CAT v praxi [Software for adaptive testing: CAT in action].
Československá psychologie. 2008; 2 (52):145-154.
32. Květon P, Jelínek M, Vobořil D, Klimusová H. Computer-based tests: the impact of test design and problem of equivalency. Computers in Human
Behavior. 2007; 23: 32-51.
33. MacEachren, AM, Cai G, Sharma R, Rauschert I, Brewer I, Bolelli L, Shaparenko B, Fuhrmann S, Wang H. Enabling collaborative geoinformation
access and decision-making through a natural, multimodal interface. International Journal of Geographical Information Science. 2005; 19(3): 293-317.
34. Mead AD, Drasgow F. Equivalence of computerized and paper-and-pencil cognitive ability tests: A meta-analysis. Psychological Bulletin. 1993; 114(3):
449-458.
35. Popelka S, Brychtová A. Eye-tracking Study on Different Perception of 2D and 3D Terrain Visualisation .The Cartographic Journal. 2013; 50(3): 240-
246.
36. Popelka S, Stachoň Z, Šašinka Č, Doležalová J. Eyetribe Tracker Data Accuracy Evaluation and Its Interconnection with Hypothesis Software for
Cartographic Purposes. Computational Intelligence and Neuroscience. 2016; 1-14. doi:10.1155/2016/9172506
37. Reas C, Fry B. Getting Started with Processing. 1st ed. Sebastopol: O’Reilly Media, Inc; 2010.
38. Ross RM. The D2 Test of Attention: An Examination of Age, Gender, and Cross-cultural Indices. Chicago: Argosy University; 2005.
39. Roth RE, Ross KS, MacEachren, AM. User-centered design for interactive maps: A case study in crime analysis. International Journal of GeoInformation.
2015; 4(1): 262-301.
40. Roth RE. An empirically-derived taxonomy of interaction primitives for Interactive Cartography and Geovisualization. Transactions on Visualization
& Computer Graphics. 2013; 19(12): 2356-2365.
41. Řezník T, Horáková B, Szturc R. Geographic Information for Command and Control Systems Demonstration of Emergency Support System. In:
Zlatanova S, Peters R, Dilo A, Scholten H, editors. Intelligent Systems for Crisis Management: Geo-information for Disaster Management (GI4DM)
Lecture Notes in Geoinformation and Cartography. Berlin-heidelberg: Springer Verlag; 2013. pp 263-275. doi: 10.1007/978-3-642-33218-0_1
42. Shiffman D. Learning Processing: A Beginner's Guide to Programming Images, Animation, and Interaction. 1st ed. Morgan Kaufmann; 2008.
43. Schuhfried G. PP-R Periphere Wahrnehmung - R. [cited 30 October 2016]. Available from: https://www.schuhfried.at/test/PP-R
44. Stachoň Z, Šašinka Č, Štěrba Z, Zbořil J, Březinová Š, Švancara J. Influence of Graphic Design of Cartographic Symbols on Perception Structure.
Kartographische Nachrichten. 2013; 4: 216-220.
21
45. Štěrba Z, Šašinka Č, Stachoň Z, Kubíček P, Tamm S. Mixed Research Design in Cartography: A Combination of Qualitative and Quantitative
Approaches. Kartographische Nachrichten.2014; 64(5): 262-269.
46. Thorndyke PW, Stasz C. Individual differences in procedures for knowledge acquisition from maps. Cognitive psychology.1980; 12(1): 137–175.
47. Vaadin Ltd. 2016. [cited 30 October 2016] Available from: https://vaadin.com/home
48. Vakalis D, Sarimveis H, Kiranoudis CT, Alexandridis A, Bafas G. A GIS based operational system for wildland fire crisis management II. System
architecture and case studies. Applied Mathematical Modelling. 2004; 28(4): 411–425. doi:10.1016/j.apm.2003.10.006
49. Voßkühler A, Nordmeier V, Kuchinke L, Jacobs AM. OGAMA - OpenGazeAndMouseAnalyzer: Open source software designed to analyze eye and
mouse movements in slideshow study designs. Behavior Research Methods. 2008; 40(4): 1150-1162.
50. Voßkühler A. OGAMA Description (for Version 2.5). A software to record, analyze and visualize gaze and mouse movements in screen based
environments. 2009. [cited 30 October 2016] Available from: http://www.ogama.net/sites/default/files/pdf/OGAMA-DescriptionV25.pdf
51. Voßkühler A. OGAMA (OpenGazeAndMouseAnalyzer): An open source software designed to analyze eye and mouse movements in slideshow study
designs. 2015, 16 May. [cited 30 October 2016]. Available from: www.ogama.net
52. Witkin HA, Oltman PK, Raskin E, Karp S. A manual for the embedded figures test. California: Consulting Psychologists Press; 1971.
53. Žitný P, Halama P, Jelínek M, Květon P. Validity of cognitive ability tests - comparison of computerized adaptive testing with paper and pencil and
computer-based forms of administrations. Studia Psychologica. 2012; 54(3): 181-194.
54. A port of the Processing Visualization Language. [cited 30 October 2016] Available from: http://processingjs.org/