Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze
Fakulta informačních technologií
Katedra softwarového inženýrství
Diplomová práce
Nástroj pro optimalizaci fasetové navigace
Bc. Petr Sobotka
Vedoucí práce: Mgr. Petr Matyáš
10. května 2012
Poděkování
Rád bych poděkoval Mgr. Petru Matyášovi za jeho čas a vstřícnost, kterou
projevil jako vedoucí této diplomové práce.
Prohlášení
Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl
veškeré použité informační zdroje v souladu s Metodickým pokynem o etické
přípravě vysokoškolských závěrečných prací.
Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající
ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů.
V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění
(licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež
jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen
„Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny
Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli
účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou
licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti)
na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla
do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve
výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn
zdrojový kód Díla.
V Praze dne 10. května 2012
.....................
7
České vysoké učení technické v Praze
Fakulta informačních technologií
c 2012 Petr Sobotka. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém
v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících
s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci
Petr Sobotka. Nástroj pro optimalizaci fasetové navigace: Diplomová práce.
Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.
Abstract
The presented thesis focuses on the issues of optimal facet selection and facet
ordering for faceted navigation purposes. It offers an overview of the currently
available literature on this topic and considers the possibility of using A/B
and multivariate testing tools.
Based on this overview, it describes analysis, design and implementation
of a software tool for measuring facet and facet value usage. The tool is then
deployed and the details and results of this real-world application are analyzed.
The thesis further incorporates usability testing which was arranged to
uncover possible usability issues of the faceted navigation which structure was
changed based on the previous results.
Keywords faceted navigation, faceted classification, multiple criteria filter,
facet optimization, facet ordering
Abstrakt
Práce se zabývá problematikou optimálního výběru faset pro fasetovou navigaci, otázkou řazení faset a fasetových hodnot. Předkládá přehled dostupné
literatury věnující se tomuto tématu a zvažuje možnosti využití A/B a multivariantních testovacích nástrojů pro tyto účely.
9
Následně popisuje analýzu, návrh a implementaci softwarového nástroje
sloužícího k měření využití faset a fasetových hodnot. Tento nástroj byl nasazen do reálného provozu, podmínky nasazení a výsledky vzešlé z naměřených
statistických dat jsou detailně rozebrány.
Dále práce popisuje průběh a předkládá závěry uživatelského testování,
které bylo uspořádáno za účelem odhalení případných chyb v použitelnosti
u fasetové navigace, jejíž struktura byla upravena na základě výsledků měření.
Klíčová slova fasetová navigace, fasetová klasifikace, multikriteriální filtrace, optimalizace faset, řazení faset
10
Obsah
Úvod
17
1 Vymezení pojmů
1.1 Faseta a fasetové hodnoty . . . .
1.2 Význam fasetové navigace . . . .
1.3 Popis práce s fasetovou navigací .
1.4 Související pojmy . . . . . . . . .
19
19
24
27
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Rešerše
29
2.1 Rešerše v literatuře . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 A/B a multivariantní testovací nástroje . . . . . . . . . . . . . 31
2.3 Webové analytické nástroje . . . . . . . . . . . . . . . . . . . . 32
3 Požadavky
3.1 Obecný záměr . . . . . . . . .
3.2 Obecná architektura nástroje
3.3 Funkční požadavky . . . . . .
3.4 Nefunkční požadavky . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
36
37
40
4 Analýza a návrh
4.1 Problémová doména . . . . .
4.2 Analytické třídy . . . . . . .
4.3 Metodika návrhu . . . . . . .
4.4 Architektura . . . . . . . . .
4.5 Návrh doménového modelu .
4.6 Návrh metodiky měření . . .
4.7 Návrh REST API . . . . . . .
4.8 Návrh uživatelského rozhraní
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
42
43
44
46
51
52
54
5 Implementace
57
11
5.1
5.2
Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . .
Implementace klienta . . . . . . . . . . . . . . . . . . . . . . . .
6 Testování
6.1 Jednotkové testy . . . . . . . . . . .
6.2 Testování výkonu . . . . . . . . . . .
6.3 Ověření implementovaného software
6.4 Uživatelské testování . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
59
61
61
62
63
65
Závěr
71
Literatura
73
A Seznam použitých zkratek
77
B UML
79
C REST API
91
D Ukázky UI
95
E Obsah přiloženého CD
103
12
Seznam obrázků
1.1
1.2
1.3
1.4
Zjednodušený objektový model katalogu vín. . . .
Wireframe uživatelského rozhraní faset vzniklých
modelu katalogu vín. . . . . . . . . . . . . . . . . .
Demonstrace hierarchické struktury kategorií. . . .
Koncepty stavějící na fasetách a vztahy mezi nimi.
.
z
.
.
.
. . . . . . . .
objektového
. . . . . . . .
. . . . . . . .
. . . . . . . .
21
25
28
3.1
3.2
3.3
Konceptuální schéma nasazení aplikace. . . . . . . . . . . . . . . .
Diagram případů užití pro živé aktéry. . . . . . . . . . . . . . . . .
Diagram případů užití pro klienta API. . . . . . . . . . . . . . . .
37
38
39
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
po. . .
. . .
Základní analytické třídy. . . . . . . . . . . . . . . . . . . . .
Vrstvy softwarové architektury podle [9]. . . . . . . . . . . . .
Vztahy mezi Model, View a Controller podle podle [29]. . . .
Návrhové třídy User, Client a Experiment. . . . . . . . . . . .
Návrhové třídy pro klíčové doménové entity. . . . . . . . . . .
Datový model pro persistenci pořadí faset pro návštěvníky. .
Přidělování identifikátorů návštěvníkům. . . . . . . . . . . . .
Nested Set . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identifikace nového návštěvníka a zaznamenání nové události
mocí REST API. . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Lo-fi prototyp titulní stránky aplikace. . . . . . . . . . . . . .
6.1
20
42
44
45
46
47
49
50
51
53
56
Celková odezva tří nejpoužívanějších kombinací HTTP metoda REST zdroj za tří různých konfigurací. . . . . . . . . . . . . . . . .
63
B.1 Diagram analytických tříd. . . . . . . . . . . . . . . . . . . . . . .
B.2 Celkový diagram návrhových tříd. . . . . . . . . . . . . . . . . . .
B.3 Třída pro realizaci REST API klienta. . . . . . . . . . . . . . . . .
79
89
90
C.1 Vytvoření nového experimentu pomocí REST API. . . . . . . . . .
C.2 Úprava nebo smazání experimentu pomocí REST API. . . . . . . .
94
94
13
D.1
D.2
D.3
D.4
D.5
Lo-fi prototyp založení nového experimentu. . . . . . . . . . . . . .
Lo-fi prototyp detailu běžícího experimentu. . . . . . . . . . . . . .
Lo-fi prototyp nastavení API klíčů pro experiment. . . . . . . . . .
Lo-fi prototyp rozhraní pro změnu hesla. . . . . . . . . . . . . . . .
Fasetová navigace v kategorii sprchové kouty v obchodě České koupelny. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.6 Fasetová navigace v kategorii sprchové vaničky v obchodě České
koupelny. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.7 Fasetová navigace v kategorii umyvadla v obchodě České koupelny.
D.8 Fasetová navigace v kategorii vodovodní baterie v obchodě České
koupelny. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.9 Počet kliknutí na fasety v kategorii vodovodní baterie. . . . . . . .
D.10 Počet kliknutí na fasety v kategorii sprchové kouty. . . . . . . . . .
D.11 Počet kliknutí na fasety v kategorii sprchové vaničky. . . . . . . . .
D.12 Počet kliknutí na fasety v kategorii sprchové boxy. . . . . . . . . .
D.13 Počet kliknutí na fasety v kategorii umyvadla. . . . . . . . . . . . .
D.14 Počet kliknutí na fasety v kategorii zrcadla. . . . . . . . . . . . . .
D.15 Počet kliknutí na fasety v kategorii osvětlení. . . . . . . . . . . . .
14
96
97
98
99
99
100
100
101
101
101
102
102
102
102
102
Seznam tabulek
6.1
6.2
Přehled testovaných kategorií zboží s fasetovou navigací. . . . . . .
Souhrn naměřených dat . . . . . . . . . . . . . . . . . . . . . . . .
64
65
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
Specifikace
Specifikace
Specifikace
Specifikace
Specifikace
Specifikace
Specifikace
Specifikace
Specifikace
C.1
C.2
C.3
C.4
C.5
C.6
C.7
Podporované HTTP metody pro jednotlivé zdroje REST
Specifikace REST zdroje Event . . . . . . . . . . . . . .
Specifikace REST zdroje Experiment . . . . . . . . . . .
Specifikace REST zdroje Facet . . . . . . . . . . . . . .
Specifikace REST zdroje FacetPosition . . . . . . . . . .
Specifikace REST zdroje FacetValue . . . . . . . . . . .
Specifikace REST zdroje Visitor . . . . . . . . . . . . .
případu
případu
případu
případu
případu
případu
případu
případu
případu
užití
užití
užití
užití
užití
užití
užití
užití
užití
Autentizovat . . . . . . . . . . . .
VytvořitNovýExperiment . . . . .
ProhlédnoutStatistikyExperimentu
ZměnitHeslo . . . . . . . . . . . .
ZměnitRoliUživatele . . . . . . . .
PozastavitExperiment . . . . . . .
ZaznamenatNovéhoNávštěvníka .
ZískatNastaveníNávštěvníka . . .
ZaznamenatChováníNávštěvníka .
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
81
82
83
84
85
86
87
88
API
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
92
92
92
93
93
93
Úvod
V průběhu uplynulých deseti let zaujalo v prostředí Webu naprosto dominantní postavení paradigma přímého vyhledávání. Odklon od hierarchických
struktur pro uspořádání obsahu, které provázelo paradigma procházení, byl
logickým důsledkem stále se zlepšující použitelnosti přímého vyhledávání odvíjející se především od pokroků v oblasti relevance výsledků. Nárůst obsahu
na Webu postupem času zcela diskvalifikoval katalogy webových stránek a hierarchická kategorizace obsahu od té doby přežívá jen u tematicky vymezených
webů, např. u internetových obchodů. Ovšem z části je tomu tak také z důvodu nedostatečné technické vyspělosti těchto webových sídel, neboť kvalitní
technologie přímého vyhledávání nemusí být pro všechny subjekty dostupná
a využití volně nabízených alternativ může bránit řada faktorů. Uživatelé
tak mnohdy nemají jinou volbu, než obsah webů sekvenčně procházet, neboť
funkce přímého vyhledávání buď nedává kýžené výsledky, nebo zcela chybí.
Konceptem, který vrací paradigma procházení zpět do hry, je fasetová
navigace. Jedná se v podstatě o skupinu vzájemně propojených filtrů, které
umožní uživateli během několika kliknutí omezit prozkoumávanou množinu
na několik málo vysoce relevantních objektů. V momentě, kdy je množina
výsledků uspokojivě malá, přechází uživatel na jejich sekvenční prozkoumání,
přičemž kritéria filtrace může kdykoli snadno změnit a interakcí s filtry se
tak dozvídá nejen o existenci dalších vyhovujících objektů, ale zároveň se učí
zákonitostem členění celé množiny.
Fasetová navigace představuje nejmocnější v současnosti známý koncept
pro multikriteriální filtraci a to především ze dvou důvodů. Jednak použití faset zmenšuje množinu výsledků logaritmicky. I z mnoha set tisícové původní
množiny objektů lze během několika kliknutí dosáhnout rozumné množiny výsledků o velikosti maximálně několika desítek objektů. Druhým důvodem je
struktura uživatelského rozhraní, která nenabízí uživateli kombinace kritérií,
které nejsou v množině objektů zastoupeny a neumožní mu tak dopracovat se
k prázdné množině výsledků. To je zásadní rozdíl oproti jiným multikriteriálním filtračním nástrojům, jako je např. tzv. pokročilé vyhledávání, u kterého
17
Úvod
uživatel nejprve specifikuje svá kritéria a teprve poté zkouší, zda objekt vyhovující jeho požadavkům vůbec existuje.
Nezanedbatelným jevem dokazujícím potenciál fasetová navigace je i její
konvergence s přímým vyhledáváním. Na jedné straně vidíme uplatnění přímého vyhledávání v rámci fasetové navigace, které lze použít k fulltextovému
prohledání výsledné množiny objektů a ještě více tak urychlit nalezení hledaného cíle. Na druhé straně spatřujeme naopak využití fasetové navigace
v rámci výsledků přímého vyhledávání, kdy výsledky lze omezovat pomocí
různých dalších kritérií, které by nebylo snadné vyjádřit pouhou změnou uživatelského dotazu.
Podíváme-li se však na fasetovou navigaci z pohledu vývojáře, zjistíme,
že její implementace, resp. návrh vhodné fasetové klasifikace pro objekty, nad
kterými chceme fasetovou navigaci postavit, není zdaleka triviální a vyžaduje
iterativní přístup s několikerým opakováním uživatelského testování a následného přepracování struktury. Fasety by měly být formulovány jako navzájem
ortogonální, jejich názvy i názvy fasetových hodnot by měly být pro uživatele
dobře srozumitelné, množství hodnot ve fasetě by mělo být únosné atd. Tyto
obecné rady pramenící z dostupné literatury jsou příliš vágní a neposkytují
konkrétní vodítka, jak strukturu faset sestavit. Přihlédneme-li navíc k faktu,
že fasetová klasifikace objektů se zpravidla v čase mění, neboť nové objekty
přibývají a je třeba hledat nová kritéria pro jejich třídění, situace se nadále
komplikuje.
Je s podivem, že v dnešní době rozmachu nástrojů pro webovou analytiku
shledáváme na trhu absenci vhodných nástrojů pro analýzu fasetové navigace.
Přitom nástroj umožňující podrobné měření využití faset by se mohl stát cenným pomocníkem podstatně zrychlujícím iterace vývoje, neboť by omezil nároky na uživatelské testování a mohl by přinést zcela nové statistické závěry,
které z kvalitativně orientovaného uživatelského testování nelze vyvodit.
Cílem této práce je vyvinout nastíněný softwarový nástroj a otestovat ho
na datech z reálního provozu fasetové navigace.
18
Kapitola
Vymezení pojmů
1.1
Faseta a fasetové hodnoty
Fasetová navigace je prověřený [14] nástroj umožňující efektivní průzkum určitého informačního prostoru. Tento prostor tvoří zpravidla kolekce entit, nejčastěji elektronických dokumentů, opatřených metadaty.
Základním stavebním kamenem fasetové navigace je faseta1 . Při studiu literatury shledáváme, že definic fasety existuje celá řada. Podle [32] fasety tvoří
„jasně definované, vzájemně výlučné a dohromady vyčerpávající aspekty, vlastnosti nebo charakteristiky určité třídy nebo subjektu“. O trochu širší definici
poskytuje [2], podle níž jsou fasety „kategorie, vlastnosti, atributy, charakteristiky, relace, funkce nebo koncepty, které jsou stěžejní pro množinu dokumentů
nebo entit a které jsou předmětem zájmu skupiny uživatelů“. Existuje mnoho
dalších definic, které se snaží více či méně vyčerpávajícím způsobem definovat
fasetu pokud možno nezávisle na specializaci v rámci informační vědy.
Vzhledem ke skutečnosti, že se tato práce pohybuje na poli softwarového
inženýrství, dovolíme si níže vymezit termín faseta s použitím pojmů v tomto
oboru běžných.
Každou fasetu tvoří množina položek, tzv. fasetových hodnot (facet values, [15], [24]), někdy také označovaných foci (sg. focus) [28], [7]. Fasety lze
členit na jednohodnotové a vícehodnotové, nebo na ploché a hierarchické. Viz
níže.
1
Podle Slovníku spisovného jazyka českého broušená okrajová ploška drahokamu, přeneseně sražená, zkosená hrana. Tento výklad dává zajímavým způsobem do souvislostí současný přenesený význam fasety v rámci informační vědy. Faseta reprezentuje jeden z mnoha
úhlů pohledu, kterými se můžeme dívat na informační prostor, tedy s jistou mírou nadsázky
náš broušený drahokam. Metafora navíc obstojí i v dalších ohledech, protože úhel pohledu
můžeme snadno měnit a zároveň se ve většině případů díváme skrze více faset najednou.
19
1
1. Vymezení pojmů
1.1.1
Vymezení pomocí pojmů softwarového inženýrství
Naším informačním prostorem, nad kterým budujeme fasetovou navigaci, bude
množina objektů jisté třídy. Fasetu si v tomto kontextu můžeme představit
jako obor hodnot jednoho z atributů třídy.
Na obrázku 1.1 vidíme zjednodušený objektový model katalogu vín – problémové domény, která bývá s oblibou zmiňována v příkladech týkajících se
fasetové navigace. Entita BottleOfWine má čtyři atributy, jedním z nich je
vazba na další entitu, konkrétně Region. Přičemž objekty druhé uvedené třídy
mohou tvořit stromovou strukturu.
BottleOfWine
- color
- volume
- price
region
Region
- name
parent
Obrázek 1.1: Zjednodušený objektový model katalogu vín.
Fasetová navigace katalogu vín postavená nad tímto zjednodušeným modelem by měla čtyři fasety, které by přímo zrcadlily atributy třídy BottleOfWine. Wireframe vzniklého uživatelského rozhraní můžeme vidět na obrázku
1.2. Pojďme se nyní zaměřit na grafickou reprezentaci fasety v rámci uživatelského rozhraní. V každé fasetě vidíme obor hodnot atributu, ze kterého
faseta vznikla. Každá hodnota slouží jako hypertextový odkaz, pokud na
něj uživatel klikne, dojde k uplatnění fasety (viz dále).
První faseta na obrázku 1.2 s názvem Region vznikla z atributu, jehož
hodnotou je vazba na další objekt2 . Jako hodnoty této fasety se proto použijí
identifikátory objektu, jenž je cílem vazby. V tomto případě jde o hodnoty
atributu name třídy Region.
Vidíme, že fasetová navigace se sice zaměřuje jen na jednu třídu objektů,
avšak bere v ohledu sousedy této třídy v rámci celého objektového grafu
a umožní je přímo využít k filtrování. Datovým modelem pro fasetovou navigaci tedy může být plně normalizovaný objektový graf.
Ve čtvrté fasetě, která vychází z atributu, jehož obor hodnot je spojitý, vidíme uplatnění mírně odlišného přístupu, kdy jsou použity intervaly, namísto
výčtu konkrétních hodnot, což by bylo nejen nepraktické ale často z důvodu
2
20
Přesněji řečeno, hodnotou atributu je uživatelsky definovaný datový typ.
1.1. Faseta a fasetové hodnoty
Region
Color
Volume
Price
France (16)
Italy (5)
South America (4)
United States (2)
Red (8)
White (5)
Rosé (6)
Tawny (2)
0,5 l (8)
0,75 l (153)
1,0 l (45)
Less than €5 (7)
€5 - €15 (12)
€15 - €30 (131)
€30 - €100 (62)
Obrázek 1.2: Wireframe uživatelského rozhraní faset vzniklých z objektového
modelu katalogu vín.
spojitosti i nemožné. Fasety vycházející z numerických atributů také mnohdy
používají speciální prvek uživatelského rozhraní, tzv. slider, který umožní uživateli nastavit konkrétní požadovanou hodnotu, případně tzv. double slider,
pomocí něhož lze specifikovat dokonce vlastní interval3 . V závislosti na datovém typu hodnot existují i další způsoby, jak realizovat obsah faset. Lze použít
např. palety barev4 , časovou osu [19], piktogramy5 atd. Avšak drtivá většina
implementací fasetové navigace dostupných na webu používá slovní formulace
a prosté hypertextové odkazy.
Číslo v závorkách u každé hodnoty vyjadřuje počet entit v informačním
prostoru, které splňují dané kritérium, neboli jejichž atribut reprezentovaný
danou fasetou má právě tuto hodnotu.
Zcela samostatnou problematiku, které se dotkne i tato práce, představuje
řazení hodnot v rámci fasety. Ve wireframu na obrázku 1.2 je použit nejběžnější způsob, kdy jsou hodnoty seřazeny sestupně podle četnosti v rámci
informačního prostoru. Druhým nejčastějším řešením je řazení dle abecedy.
Zůstává otázkou, zda by nebylo vhodnější řadit hodnoty podle jejich žádanosti uživateli fasetové navigace.
Uvedený princip vzniku faset z atributů entit má pochopitelně jistá omezení. Ne všechny atributy se dají pro potřeby faset využít a navíc vůbec nemusí
být žádoucí všechny atributy ve fasety přeměňovat. Má to smysl jen u těch
atributů, u kterých očekáváme, že by je uživatel mohl použít k filtraci dané kolekce entit. Zdůrazněme, že popsaná podstata vzniku faset zároveň implikuje,
že jedna fasetová navigace (sada faset) je spjata pouze s kolekcí entit jedné
třídy. Pokud je potřeba navigovat uživatele mezi entitami více tříd, zpravidla
je nutné učinit tak odděleně s využitím několika fasetových navigací. Jednou
z typických aplikací fasetové navigace jsou katalogy informačních zdrojů, dokumentů. Zde lze hovořit o jedné třídě entit. Jinou častou aplikací jsou webové
obchody s mnoha druhy zboží. V tomto případě se naopak uplatní fasetová
3
Nejčastějším případem užití tohoto prvku je atribut cena v katalozích webových obchodů.
4
Používá např. katalog http://www.artistrising.com
5
Používá např. aplikace http://wefeelfine.org
21
1. Vymezení pojmů
navigace pro každý druh zboží.
V tomto oddíle jsme popsali vznik fasetové navigace z tříd a objektů, tedy
z dat. Literatura nezřídka hovoří o vzniku faset z metadat [8], [15], [10]. Domníváme se, že jde pouze o jiný úhel pohledu na tutéž problematiku. Komplexní
objekty mohou nést „informační jádro“ a vedle něj i metadata, obojí v podobě atributů. Je často filosofický problém odlišit první od druhého. Užíváním
slova metadata chtěli pravděpodobně autoři výše uvedených článků zdůraznit
fakt, že „informační jádro“ leží mimo množinu dat, se kterou pracují, v jistých
případech i zcela mimo informační prostor – ve fyzickém světě. Pro účely této
práce jde o problém marginální a mezi daty a metadaty jakožto zdrojem pro
vznik faset nebudeme rozlišovat.
1.1.2
Hierarchické fasety
Příklad znázorněný na obrázcích 1.1 a 1.2 používá jednu hierarchickou fasetu.
Jde o takovou fasetu, jejíž hodnoty sestávají z objektů stejné třídy formujících
stromovou strukturu. Z diagramu tříd 1.1 je patrné, že touto entitou je v našem
příkladě Region.
Pokud uživatel v jednom kroku vybere některou z hodnot hierarchické
fasety, v následujícím kroku jsou mu prezentovány další hodnoty představující
potomky hodnoty vybrané v prvním kroku.
Hierarchická faseta představuje mocný filtrační nástroj, který umožňuje
uživateli, aby si sám zvolil přesnost, se kterou chce uplatnit kritérium filtrace reprezentované fasetou. Navíc bylo ukázáno, že navigace se současným
využitím více hierarchických faset nedělá uživatelům problémy [8].
Vedle hierarchických faset mluví někteří autoři o hierarchii faset [6]. Hierarchii v tomto případě neformují hodnoty jedné fasety, ale celé fasety. První
motivace tohoto řešení spočívá v sémantickém posunu fasety, ke kterému nezřídka dochází, jakmile se v hierarchii zanořujeme. Hierarchie celých faset nám
umožní tento posun lépe podchytit. Např. místo hierarchické fasety Místo můžeme použít hierarchii faset Stát → Kraj → Město atp. Druhou motivací je
pak možnost zařadit jednu fasetu do více hierarchií.
V této práci nebudeme hierarchii celých faset brát v potaz.
1.1.3
Vícehodnotové fasety
V definici fasety podle [32], zmíněné v předchozím textu, je uvedeno, že fasety by měly být vzájemně výlučné a dohromady vyčerpávající. Druhá
část toho tvrzení platí i pro hodnoty ve fasetě. Naopak vzájemná výlučnost
hodnot není nutná a je zcela v pořádku, pokud je dvě a více hodnot přiřazeno
jedné entitě [7]. V takovém případě budeme mluvit o vícehodnotové fasetě
(multi-valued facet). Pro názorný příklad není nutné chodit daleko: v hypotetické fasetové navigaci pokrývající doménu receptů na vaření bude ve fasetě
ingredience typicky každé entitě (receptu) přiřazeno více hodnot.
22
1.1. Faseta a fasetové hodnoty
Skutečnost, zda má entita v rámci fasety více hodnot, je pochopitelně
determinována strukturou datového modelu, na kterém je fasetová navigace
postavena. Buď má daný atribut entity jedinou hodnotu, nebo jde o kolekci
hodnot (resp. je hodnotou vazební entita u M:N vazeb).
Otázkou zůstává, zda vícehodnotové fasety nejsou pro uživatele méně srozumitelné. Velikost množiny entit, které odpovídají aktuálně specifikovaným
kritériím v rámci všech faset, totiž u standardní fasety odpovídá součtu četností výskytů hodnot (čísla uvedená v závorkách za každou hodnotou). U faset
s vícenásobnými hodnotami toto pochopitelně neplatí. Ačkoli studie zabývající se uživatelským testováním fasetové navigace operují s vícehodnotovými
fasetami [8], [15], závěry o srozumitelnosti čísel v závorkách nepřinášejí.
1.1.4
Volba více hodnot v rámci fasety
Jednou z nejzásadnějších vlastností fasetové navigace je přítomnost, či naopak absence podpory pro volbu více hodnot v rámci jedné fasety. Pokud
tato funkcionalita je přítomna, liší se uživatelské rozhraní ve výchozím stavu
od ukázky 1.2 tím způsobem, že se před každou hodnotou nachází zaškrtávací formulářové políčko (tzv. checkbox). Uživatel může pomocí těchto prvků
zaškrtnout všechny hodnoty, které ho zajímají.
Volba více hodnot v rámci jedné fasety je natolik fundamentálním rysem,
že můžeme hovořit o dvou skupinách fasetových navigací podle toho, zda tímto
rysem disponují (multiple choice), či nikoli (single choice). Pokud je možnost
volby více hodnot přítomna, posouvá to expresivitu fasetové navigace jakožto
dotazovacího nástroje na zcela novou kvalitativní úroveň (viz následující oddíl). Implikuje to však zároveň komplexnější uživatelské rozhraní, které může
ztrácet na přehlednosti. Nejde přitom jen o zaškrtávací políčka, která přibudou před hodnotami ve fasetách. Zásadní rozdíl spočívá ve způsobu, jak se
fasetová navigace chová, když uživatel provádí volbu. V jednodušší verzi bez
možnosti volby více hodnot v rámci jedné fasety dojde po kliku uživatele na
hodnotu buď k celkovému odstranění fasety6 , nebo alespoň k odebrání všech
ostatních hodnot a ponechání pouze vybrané hodnoty. Jak uživatel vybírá
hodnoty v jednotlivých fasetách, uživatelské rozhraní se postupně neustále
zjednodušuje a stává se stále více pouze přehledným souhrnem uplatněných
kritérií7 . Naproti tomu fasetová navigace umožňující současnou volbu více
hodnot v rámci jedné fasety zůstává stále stejně rozsáhlá, neboť všechny hodnoty musí být stále zobrazeny pro případ, že by v dané fasetě chtěl uživatel
zaškrtnout nějaké další.
Ačkoli by ve výchozím stavu, kdy uživatel čelí celé nefiltrované množině
entit, měly logicky být zaškrtnuté všechny hodnoty ve všech fasetách, není
zvykem tak činit. Uživatel by musel odškrtat hodnoty, které ho nezajímají,
6
7
Indikace zvolené hodnoty se přesouvá např. do drobečkové navigace.
Pochopitelně s možností je individuálně zrušit
23
1. Vymezení pojmů
a to představuje rozpor se vzorem chování zažitým v prostředí webu, který lze
shrnout jako „klikni na to, co chceš“ [24].
1.1.5
Fasety jako nástroj pro konstrukci dotazu
Volbou jedné hodnoty v rámci některé z faset uživatel definuje kritérium,
podle kterého si přeje filtrovat obsah informačního prostoru. Případnou volbou
dalších hodnot v jiných fasetách definuje další kritéria, která dohromady tvoří
konjunkci. Verbalizovaný dotaz může vypadat např. takto: vypiš všechna
vína, která jsou z Francie a zároveň jsou červená a zároveň se dodávají
v litrových lahvích. (Uživatel v tomto případě použil k vyjádření svého zájmu
tři fasety.)
Už tato základní funkcionalita fasetové navigace představuje dostatečně
silný nástroj. Pokud navíc umožníme volbu více hodnot v rámci fasety, dostaneme nástroj ještě silnější. Poté může uživatel definovat kritéria formující
konjunkci disjunkcí. Např.: vypiš všechna vína, která jsou z Francie nebo
Itálie a zároveň jsou červená nebo růžová a zároveň se dodávají v třičtvrtělitrových nebo litrových lahvích.
1.2
Význam fasetové navigace
Existují dvě základní paradigmata hledání, která provázejí web od dob jeho
vzniku [3], jsou to:
• procházení hierarchických struktur,
• přímé vyhledávání.
První paradigma se opírá o organizační systém sestávající ze stromů kategorií. Jednotlivé uzly představují předem daná kategorizační kritéria. Tento
přístup k organizaci informačního prostoru má tři naprosto zásadní úskalí:
1. Uživatel nořící se ve stromu níže a níže je postaven před neměnnou posloupnost rozhodnutí, která musí učinit, pokud se chce dobrat listu
stromu. Přitom tato posloupnost nemusí vůbec odpovídat jeho vnímání
důležitosti jednotlivých kritérií. Uživatel například může dospět do uzlu,
který definuje další členění na základě kritéria, které je pro uživatele
naprosto irelevantní. Ještě horší situace nastane, když danému kritériu
uživatel nerozumí. V obou případech je donucen vyzkoušet všechny podstromy uzlu a hierarchická organizace od tohoto bodu ztrácí význam.
2. Celkový počet kategorií roste exponenciálně. Velmi často se v rámci
stromu kategorií vyskytuje duplicita, resp. multiplicita celých podstromů.
Pokud je dodrženo stejné kritérium kategorizace vždy v rámci celého patra stromu, pak je s výjimkou svého kořene multiplicitní dokonce každý
podstrom. Tato skutečnost znesnadňuje úpravy uzlů.
24
1.2. Význam fasetové navigace
Wines
France
Italy
Red
Red
White
0,5l 0,75l 1,0 l
White
0,5l 0,75l 1,0 l
Rosé
0,5l 0,75l 1,0 l
Rosé
Tawny
0,5l 0,75l 1,0 l
0,5l 0,75l 1,0 l
Tawny
0,5l 0,75l 1,0 l
0,5l 0,75l 1,0 l
0,5l 0,75l 1,0 l
Obrázek 1.3: Demonstrace hierarchické struktury kategorií.
3. Při malé změně struktury je často zapotřebí provést přesuny velkého
množství kategorizovaných entit, případně celých podstromů.
Všechny tři uvedené problémy ilustruje obrázek 1.3 s příkladem stromové
struktury kategorií. Pro nedostatek prostoru byla realizována jen část stromu
odpovídajícího fasetové navigaci z obrázku 1.2, kompletní strom by měl 4 × 4
× 3 × 4 + 1 = 193 uzlů. Přičemž je nutno podotknout, že fasetová navigace na
obrázku 1.2 používá velmi střídmé množství faset i hodnot, praktické aplikace
fasetové navigace mívají nezřídka 5-6 faset a podobné množství hodnot v každé
z nich.
Každé kritérium, podle kterého chceme filtrovat, vytváří vlastní dimenzi.
Pro efektivní multikriteriální filtraci s možností volby pořadí uplatněných kritérií tak potřebujeme multidimenzionální organizační schéma. A právě
tím fasetová navigace je [7].
„Fasetová navigace staví na předpokladu, že existuje více než jeden způsob nahlížení světa a každá zdánlivě ustálená klasifikace je ve své podstatě
provizorní a dynamická.“[19] Podle [7] je fasetová navigace vhodná pro tři
a více dimenzí klasifikace, přičemž nezáleží, zda organizujeme šaty ve skříni
nebo veškeré vědomosti lidstva. Tato nadsázka může působit úsměvně, velmi
úderně však vyzdvihuje univerzálnost nebývalého rozsahu, kterou se fasetová
navigace vyznačuje.
Druhé paradigma – přímé vyhledávání – které se během uplynulých let
stalo populárnějším a nyní zcela dominuje, se vyskytuje ve dvou podobách.
25
1. Vymezení pojmů
V drtivé většině případů je realizováno jako fulltextové vyhledávání. Ve zbytku
případů jde o tzv. parametrické vyhledávání8 , jehož uživatelské rozhraní má
nejčastěji podobu formuláře s mnoha prvky, přičemž některé mohou být povinné, jiné nepovinné. Uživatel nejprve specifikuje požadovaná kritéria a poté
formulář odešle, čímž iniciuje hledání. Rovněž tento způsob prohledávání informačního prostoru má nezanedbatelné nevýhody:
1. Formulář není interaktivní, před odesláním chybí jakákoli zpětná vazba.
S tím souvisí následující bod.
2. Zpravidla značná část (mnohdy více než polovina) kombinací hodnot
neexistuje a výsledkem hledání je prázdná množina. To má zcela fatální
dopad na uživatelský prožitek. Člověk, který obdrží tuto zprávu opakovaně, vyhodnotí situaci buď jako svoje selhání, nebo (zcela oprávněně)
shledá nástroj nepoužitelným.
Fasetová navigace efektivně řeší jak nevýhody pokročilého vyhledávání,
tak nevýhody klasifikace postavené na hierarchii kategorií. Ačkoli případy
užití těchto dvou nástrojů nejsou shodné, fasetová navigace může překvapivě
pomocí jediného rozhraní oba tyto nástroje nahradit. Vykazuje následující
fundamentální vlastnosti:
• Pořadí volby kritérií ponechává na uživateli.
• Interaguje s uživatelem a po každé volbě kontextově přizpůsobuje další
nabízené volby.
• Informuje uživatele o přesném počtu entit odpovídajících aktuálně nastaveným kritériím.
• Zcela eliminuje riziko dosažení prázdné množiny výsledků.
• Nevyžaduje žádnou úpravu při přidání entit do, či odebrání entit z informačního prostoru.
Většina implementací navíc poskytuje uživateli kromě údaje o počtu odpovídajících entit i jejich plný výpis, často s možností řazení a někdy i s možností fulltextového vyhledávání v rámci množiny aktuálních výsledků. Pomocí takto sofistikovaného nástroje může uživatel velmi rozsáhlou kolekci9
všech entit během několika vteřin omezit na malou množinu cca 50 položek
8
Někdy také označováno jako pokročilé vyhledávání.
Experimentální prostředí popsané v [8] pracuje nad množinou 40 000 entit. Práce [6]
zmiňuje dva experimenty, z nichž jeden staví na množině 1,8 milionů entit. Z principu, kterým
fasetová navigace řeší tzv. prokletí dimensionality, vyplývá, že neexistuje žádná horní hranice
pro velikost počáteční množiny. S růstem její velikosti však úměrně rostou i nároky na kvalitu
návrhu fasetové navigace, resp. klasifikace.
9
26
1.3. Popis práce s fasetovou navigací
[24], kterou je již schopen projít sekvenčně. Přitom uživatel může libovolný
dílčí krok, který vyhodnotí jako nesprávný, vrátit a vydat se jinou cestou.
Benefitem oproti výše zmíněným paradigmatům je i skutečnost, že se uživatel
prací s fasetami učí zákonitostem organizace dané informační domény.
1.3
Popis práce s fasetovou navigací
Typický scénář práce s fasetami (bez podpory mnohonásobného výběru) vypadá následujícím způsobem: uživatel se ocitne na stránce s fasetovou navigací.
Ta kromě faset obsahuje i ukázku několika (desítek) entit a údaj o jejich celkovém počtu. Uživatel se zběžně seznámí s názvy, případně hodnotami faset
a vybere si fasetu, která ho „zaujme nejvíce“. V jejím rámci vidí hodnoty,
každou s údajem o četnosti v závorce. Klikne na některou z hodnot, s níž
se identifikuje, neboli o které je přesvědčen, že nejlépe vyjadřuje jeho nejdůležitější požadavek. Po kliknutí se celá stránka aktualizuje. Faseta, v rámci
níž bylo provedeno klinutí, skryje všechny svoje hodnoty, kromě té vybrané.
Dále přibude křížek umožňující uživateli právě učiněnou volbu vrátit zpět.
Ostatní fasety také změní svůj obsah. Zobrazují nadále pouze ty hodnoty,
které se vyskytují v množině entit omezené specifikovaným kritériem. Rovněž
čísla v závorkách jsou přepočítána, aby odrážela aktuální stav. Zároveň dojde
k nahrazení původního vzorku entit za jiný, který odpovídá zvolenému kritériu a je upraven údaj o celkovém počtu odpovídajících entit. Pokud uživatel
klikne na hodnotu v některé ze zbývajících faset, scénář se opakuje. V kterémkoli okamžiku může uživatel množinu odpovídajících entit zúžit uplatněním
další fasety, nebo rozšířit odstraněním dříve uplatněného kritéria. V momentě,
kdy uživatel zúží množinu entit na počet umožňující sekvenční prozkoumání,
úloha fasetové navigace končí a uživatel se k ní vrací, pouze pokud chce změnit
svá kritéria, nebo začít nové hledání.
1.4
Související pojmy
Literatura věnovaná fasetám operuje s několika koncepty využívajícími fenoménu faset. Pojďme je krátce představit a uvést, jaké jsou mezi nimi rozdíly.
Mezi pojmy patří především:
• fasetová klasifikace (faceted classification),
• fasetová navigace (faceted navigation),
• fasetové hledání (faceted search),
• fasetové brouzdání (faceted browsing),
• fasetové filtrování (faceted filtering).
27
1. Vymezení pojmů
koncept
nástroj
proces
fasetová
klasifikace
fasetová
navigace
fasetové
brouzdání
fasetové
hledání
fasetové
filtrování
iniciuje
používá
Obrázek 1.4: Koncepty stavějící na fasetách a vztahy mezi nimi.
Mnohdy se uvedené pojmy zaměňují, což z našeho pohledu představuje
problém. Ačkoli slova navigace, klasifikace, hledání, brouzdání a filtrování
označují procesy, ne všechny uvedené koncepty budeme jako procesy chápat.
Fasetová klasifikace představuje koncept stěžejní. Jde o samotnou podstatu souběžného členění organizovaných entit do několika navzájem disjunktních klasifikačních struktur – faset. Fasetová navigace převádí předchozí
koncept do funkční podoby a umožňuje efektivní procházení množiny entit,
zužování, resp. rozšiřování výběru. Vyskytuje se především na webu a v desktopových aplikacích, výjimečně však i ve fyzickém světě10 . Fasetové hledání
spojuje koncepty fulltextového vyhledávání a fasetové navigace. Uživatel nejprve zadá do vyhledávacího pole dotaz a teprve v rámci množiny výsledků
je použita fasetová navigace. Fasetové hledání se potýká s problémem nemožnosti operovat nad více třídami objektů. Z počátečního uživatelského dotazu
lze jen stěží určit požadovanou třídu a prezentované výsledky zpravidla míchají entity více tříd. Nad touto množinou pak ovšem nelze postavit fasety.
Řešením je buď předřadit výsledkům informaci o odpovídajících třídách a nechat uživatele vybrat konkrétní třídu a v rámci ní pokračovat fasetami, což
je dosti krkolomné, nebo lze zobrazovat jen fasety, které mají všechny nalezené třídy společné. V tom případě však dochází ke značnému kompromisu.
Fasetové brouzdání označuje proces průzkumu informačního prostoru pomocí fasetové navigace, přičemž cíl nemusí být předem nutně známý. Konečně
fasetové filtrování znamená pouhé „ořezávání“ množiny výsledků pomocí
faset.
Vztahy mezi zmíněnými koncepty se snaží vizualizovat obrázek 1.4.
10
Jedná se především o způsob organizace písemných pramenů nazvaný Colon Classification vyvinutý v první polovině 20. stol S. R. Ranganathanem.
28
Kapitola
Rešerše
Nepodařilo se nalézt žádný existující softwarový nástroj vytvořený za účelem
optimalizace nebo měření využití fasetové navigace. Rešerše se proto zaměří
nejprve na dostupnou literaturu a následně na možnosti využití A/B a multivariantních testovacích nástrojů, popř. nástrojů pro webovou analytiku.
2.1
Rešerše v literatuře
V uplynulém desetiletí byla fasetová navigace podrobena poměrně intenzivnímu výzkumu. Předmětem podrobných studií [8], [15] se stala především
použitelnost. Objevily se nové publikace na téma analýzy faset, neboli metodiky sestavování fasetové klasifikace pro existující informační kolekce. Např.
[7], který vychází ze starší [28], nebo [4]. Řada děl se zabývá fasetami jako
takovými a zaměřuje se na jejich obhajobu a popularizaci, např. [7], [5], [24],
nebo přináší konkrétní doporučení pro realizaci [13] a shrnuje nedávné pokroky
[14]. Téma poloautomatizovaného sestavování fasetové klasifikace načíná [12].
[13] a [14] zmiňují postup tvůrců webového obchodu eBay Express, kteří
pomocí logů webového serveru a záznamu jednotlivých kliknutí uživatelů určili, které fasety jsou nejdůležitější pro ten který typ prodávaného zboží. Nechávají zobrazit vždy 4-5 faset, přičemž zbývající fasety jsou skryté a lze je
zobrazit na požádání. Bližší podrobnosti však uvedeny nejsou.
Práce [6] se zabývá výběrem vhodných faset pro zpřesnění dotazů v rámci
OLAP (OnLine Analytical Processing) systémů. Primárním cílem je zobrazovat takové fasety a fasetové hodnoty, které vyzdvihují nové trendy, výjimky
nebo abnormality v datech. Navrhovaný systém počítá „zajímavost“ (interestingness) jednotlivých fasetových hodnot na základě jejich odchylky od
předpokládané hodnoty. Údaje pro podporu tohoto chování jsou předpočítány výhradně předem na základě dat z celého informačního prostoru, nad
kterým nástroj operuje. Chování uživatelů nástroj nebere v potaz.
Tématu této diplomové práce se částečně blíží nepublikovaný článek Přibližně optimální výběr faset [21], který se zabývá výběrem faset pro výsledky
29
2
2. Rešerše
fulltextových dotazů. Řazení dokumentů ve výsledcích dotazu je určeno tradičně rankem. Pro každý dokument ve výsledcích se prověřují všechny k němu
příslušící fasety a předpočítává se, jaký vliv na rank by mělo uplatnění té
které fasetové hodnoty. Na základě těchto údajů je následně vybrána optimální množina faset. Práce formuluje výběr faset jako NP-těžký (NP-hard)
optimalizační problém a navrhuje pro něj aproximativní řešení.
Z hlediska této diplomové práce je nejzajímavější problematika výběru,
počtu a řazení faset, případně řazení hodnot v rámci faset. [19] k tomuto
tématu uvádí: „Výběr vhodných faset je klíčová záležitost a vyžaduje dobrou
znalost klasifikovaných položek a uživatelů.“ Dále se však tématu nevěnuje.
[28] předkládá poměrně rozsáhlou metodiku pro sestavování faset skládající
se ze tří rovin. První, ideová rovina, ve své druhé části nazvané Principles
for the Citation Order of Facets and Foci obsahuje obecné rady ohledně řazení, např.: „řazení by mělo být relevantní k podstatě, předmětu a rozsahu
klasifikace“. Dále navrhuje některá schémata pro řazení, např. chronologické,
abecední, prostorové řazení. Řazení od nejjednoduššího k nejobtížnějšímu aj.
Tato vodítka shledáváme příliš obecnými.
Nastiňme typickou situací, do které se může dostat tvůrce fasetové navigace: disponuje množinou entit, pro které sestavil fasetovou klasifikaci. Vznikne
jisté množství faset. V tomto bodě vyvstane otázka, zda je vhodné do budoucí
navigace zařadit všechny fasety a v jakém pořadí. Na obě části otázky může
odpovědět doménový expert, se kterým se tvůrce poradí. Vznikne tedy jistý
rozumný výběr faset s jistým rozumným pořadím odpovídajícím pohledu experta. Bude toto řešení optimální z pohledu uživatelů?
Zde je pochopitelně na místě podotknout, že vzhledem k podstatě fasetové
navigace, která staví na možnosti uplatňovat kritéria v libovolném pořadí,
neexistuje nic takového jako optimální výběr a pořadí. Každý uživatel může
mít jiné preference. Což ovšem nevylučuje, že se mezi uživateli vyskytnou
jisté vzory. Bylo by dobré umět tyto vzory odhalit a složení i pořadí faset jim
přizpůsobit.
Hrubou představu může poskytnout uživatelské testování. To je však primárně určeno k odhalování chyb v použitelnosti, nikoli ke zjišťování uživatelských preferencí. Navíc je poměrně nákladné. Vzhledem ke stále větší oblibě
fasetové navigace se nelze spokojit s představou, že by bylo nutné pro každou
nově vznikající sadu faset organizovat další uživatelské testování.
Uživatelské testování může dále jen obtížně přinést odpověď na otázku,
jaké je nejvhodnější pořadí hodnot v rámci faset. Současný dominující trend,
kdy jsou hodnoty řazeny sestupně podle četnosti, nelze považovat za uspokojivý. Tento způsob řazení sice informuje uživatele, co je nejčetnější, zdaleka
však nemusí platit, že nejčetnější je i tím nejžádanějším. Naopak si lze snadno
představit problémové domény, kde nejžádanější budou naopak nejvzácnější
exempláře.
Domníváme se, že zde existuje prostor pro nástroj provádějící
statistickou analýzu využití faset, který by z naměřených dat sestavil
30
2.2. A/B a multivariantní testovací nástroje
optimální pořadí a výběr faset a výrazně tak urychlil proces návrhu
struktury fasetové navigace.
2.2
A/B a multivariantní testovací nástroje
A/B testování a multivariantní testování jsou statistické metody sloužící k určení vlivu určitého prvku webových stránek na úspěšnost dosažení jistého předem definovaného cíle, nejčastěji konverze11 . A/B testování operuje se dvěma
verzemi stránky, resp. prvky stránek, které náhodně předkládá příchozím návštěvníkům. Pomocí mechanismu cookies je zajištěno, aby návštěvník viděl
stejnou verzi i při opakovaném návratu a jeho uživatelský prožitek nebyl testováním zasažen. Multivariantní testování se od A/B testování liší pouze použitím více než dvou variant.
Je zřejmé, že čím více variant stránky testujeme, tím větší provoz musí
stránka vykazovat, abychom obdrželi statisticky průkazné výsledky měření.
Na trhu existuje celá řada nástrojů pro A/B a multivariantní testování, většinou jsou poskytovány formou služby. Mezi nejznámější patří Google Website
Optimizer12 , Optimizely13 , Visual Website Optimizer14 . Nejznámějším opensource nástrojem je Genetify15 .
Pokud bychom chtěli fasetovou navigaci testovat pomocí uvedených nástrojů, ztotožnili bychom variantu stránky s konkrétním pořadím, resp. složením faset. Ruzné varianty by vznikly výběrem, případně permutací faset.
Vzhledem k tomu, že všechny výše uvedené nástroje předpokládají ruční sestavení experimentů a přihlédneme-li k exponenciální závislosti počtu variant
na počtu faset, nejeví se možnost optimalizovat fasetovou navigaci pomocí
těchto nástrojů jako příliš vhodná.
Google Website Optimizer disponoval aplikačním rozhraním (API), pomocí něhož bylo možné tvorbu experimentů automatizovat, ovšem toto rozhraní Google v květnu roku 2011 pozastavil.
Závažnější komplikace pro případné využití výše uvedených nástrojů za
účelem testování faset však plynou z principu fungování těchto nástrojů. Ty
předpokládají svázání experimentu s jedinou webovou stránkou identifikovanou pomocí URL, která slouží jako vstupní brána experimentu. Uživatel buď
provádí činnost na této stránce, nebo z ní odejde, čímž je první část experimentu ukončena (je zaznamenáno, kterou variantu uživatel viděl) a čeká se
11
Konverze v terminologii online marketingu znamená přeměnu návštěvníka webové
stránky v zákazníka, čili typicky vytvoření elektronické objednávky. O rozšíření uvedených
metod se postaralo především odvětví online marketingu, takže nejznámějším typem cíle
je konverze; cíl však může představovat jakákoli skutečnost nebo činnost, kterou je možné
pomocí webových technologií dostatečně průkazně změřit, např. navštívení nějaké stránky,
vyplnění formuláře, odeslání emailu prostřednictvím webového rozhraní atd.
12
http://www.google.com/websiteoptimizer
13
http://www.optimizely.com
14
http://visualwebsiteoptimizer.com
15
https://github.com/gregdingle/genetify/wiki/
31
2. Rešerše
jen na to, zda uživatel dosáhne předem stanovaného cíle experimentu, což se
může odehrát na libovolné jiné stránce, ne nutně bezprostředně po odchodu
ze vstupní stránky.
V případě použití fasetové navigace uživatel ze své perspektivy zůstává při
uplatňování faset na jedné webové stránce, ovšem technicky tomu tak není,
protože volba hodnoty v některé z faset má zpravidla za následek přechod na
jinou URL a tím pádem konec první fáze experimentu. Po uplatnění jediné
fasety by tak testovací nástroj přestal zaznamenávat další volby. To je však
nepřijatelné, výsledkem tohoto experimentu by byla pouze informace, která
z faset je nejčastěji použita pro první volbu. Jedinou možností by bylo sestavit
další experimenty podmíněné výsledkem předchozích experimentů, to je však
z důvodu již výše zmíněné kombinatorické exploze nepřijatelné.
Dále si musíme uvědomit, že cílem nástrojů pro A/B a multivariantní testování je vždy vybrat jedinou vítěznou variantu. Lze se domnívat, že případný
multivariantní experiment by nikdy neskončil nalezením vítězné varianty, protože několik variant by vykazovalo srovnatelné výsledky.
Celou řadu skutečností bychom navíc pomocí uvedených testovacích nástrojů nebyli vůbec schopni změřit, namátkou uveďme návraty ve fasetové
navigaci (uplatnění kritéria a jeho následné zrušení), celkový počet uplatněných faset, velikost výsledné množiny objektů, užití stránkování a řazení apod.
Tyto údaje však v žádném případě nelze zanedbat, protože mohou představovat vodítko k úpravám fasetové navigace.
Na základě výše uvedených faktů shledáváme možnosti použití A/B a multivariantních testovacích nástrojů pro potřeby optimalizace fasetové navigace
jako velmi omezené.
2.3
Webové analytické nástroje
Použití nástrojů pro webovou analytiku za účelem měření fasetové navigace
se přímo nabízí. Nejznámějším zástupcem této skupiny nástrojů je Google
Analytics, který je dostupný zdarma.
Tento softwarový produkt nabízí značně univerzální mechanismus nazvaný
Události, pomocí něhož lze zaznamenávat libovolné akce, které se odehrají na
webové stránce. Pro každou měřenou událost lze specifikovat kategorii, akci,
štítek a případně číselnou hodnotu. Na první pohled se zdá tato funkcionalita
zcela vhodná pro měření fasetové navigace. Měříme-li v rámci webové stránky,
která obsahuje pouze jednu skupinu faset, pak atribut kategorie použijeme
k rozlišení fasety, atribut akce k určení akce, kterou pomocí faset uživatel
provedl (uplatnění fasety, zrušení fasety, zrušení všech faset...), a atribut štítek
použijeme k zaznamenání konkrétní fasetové hodnoty.
Pokud však chceme měřit v rámci webové prezentace obsahující více fasetových navigací (např. e-shop s různými kategoriemi zboží), bude muset být
mapování atributů jiné. kategorie pravděpodobně ponese údaj o původní ka32
2.3. Webové analytické nástroje
tegorii zboží kategorii, atribut akce zůstane stejný jako v předchozím případě,
ale atribut štítek bude obsahovat jméno fasety. Pro údaj o fasetové hodnotě
již nezbude vhodné pole. Teoreticky lze využít čtvrtý, celočíselný atribut pro
zaznamenání interního identifikátoru uplatněné fasetové hodnoty, ale Google
Analytics hodnoty předané pomocí tohoto atributu agreguje a ve webovém
uživatelském rozhraní zobrazuje pouze průměrné hodnoty. Pro identifikaci použitých hodnot je tedy tento atribut nevhodný.
Naměřená data mají pouze omezenou vypovídací hodnotu, lze z nich určit
procentuální zastoupení akcí a názvů faset, na které bylo kliknuto. Již však
nelze vysledovat typická pořadí uplatnění faset, velikost výsledné množiny
filtrovaných objektů ani např. historii akcí jednoho uživatele.
Z uvedeného plyne, že Google Analytics nabízí značně omezené možnosti
pro optimalizaci fasetové navigace.
33
Kapitola
Požadavky
V této kapitole specifikujeme požadavky na zamýšlený softwarový nástroj nejprve neformálně a posléze standardním způsobem ve formě běžné pro softwarové inženýrství: pomocí seznamu (katalogu) požadavků a případů užití.
Požadavky budeme dle zvyku dělit na funkční (functional requirements) a nefunkční (non-functional requirements)[1]. Připomeňme, že první skupina definuje konkrétní funkcionalitu a chování připravovaného systému, zatímco druhá
skupina požadavků zachycuje obecnější kvalitativní kritéria a případná omezení.
3.1
Obecný záměr
Rešerše 2 otevřela prostor pro softwarový nástroj s poměrně jasnými obrysy.
Jeho primárním účelem bude spolupracovat s existujícími implementacemi
fasetové navigace a nabídnout metody pro detailní analýzu jejich využití ze
strany koncového uživatele. (Z tohoto záměru již plynou konkrétní důsledky
pro architekturu nástroje, jejich upřesnění následuje níže 3.2.) V této roli by se
nástroj měl stát pasivní součástí systému zajišťujícího chod fasetové navigace.
Jedinou výjimkou bude usměrňování chování fasetové navigace do té míry,
aby měření jejího využití probíhalo statisticky korektně.
Druhým stěžejním účelem je poskytnout závěry z měření, podle kterých
bude možné strukturu fasetové navigace upravit tak, aby se přiblížila jistým
kvalitativním i kvantitativním cílům. Typicky půjde o identifikaci nepoužívaných či problematicky formulovaných faset. Závěry bude moci formulovat živý
uživatel pohledem do statistických přehledů (reportů), které budou výstupem
z měření.
Záměrem je tedy připravit softwarový nástroj, který si bude moci případný
zájemce (provozovatel aplikace s fasetovou navigací - např. e-shopu) stáhnout
a rozeběhnout na vlastním serveru, nebo využít sdílené instalace. Nástroj bude
fungovat jako webová služba, kterou zájemce využije tím způsobem, že připraví implementaci klientské části, kterou zahrne do svojí aplikace s fasetovou
35
3
3. Požadavky
navigací. Tímto způsobem oba systémy zintegruje (propojí) a následně bude
moci začít měřit využití faset koncovými návštěvníky svojí aplikace. Tito tedy
nepřijdou s plánovaným optimalizačním nástrojem vůbec do styku. Jednotlivé
měřené fasetové navigace bude nástroj evidovat ve formě oddělených experimentů. Dále bude nástroj disponovat ještě uživatelským webovým rozhraním
pro vzdálenou správu experimentů. Pomocí tohoto rozhraní pak provozovatel
bude moci sledovat jednotlivé statistiky, klíčové metriky a případně experimenty ve vhodný moment zastavit. Bude na provozovateli, jak experimenty
vyhodnotí. Bude moci zachovat propojení obou systémů a po ukončení běhu
experimentu zobrazovat návštěvníkům změřený optimální výběr a pořadí faset, nebo propojení ukončí a s výsledky naloží po svém.
3.2
Obecná architektura nástroje
Pojďme shrnout záměry vyjádřené v předchozím oddíle a specifikovat konkrétní požadavky na obecné vlastnosti a strukturu zamýšleného nástroje. Nástroj bude fungovat jako samostatná webová aplikace umožňující využití
ve stylu klient–server. Hlavní funkčnost bude poskytována ve formě webové
služby.
Klienti16 budou s nástrojem komunikovat pomocí jeho REST API. Dále
bude možné se k nástroji přihlásit pomocí webového uživatelského rozhraní za
účelem správy, konfigurace a prohlížení výsledků.
Způsob nasazení a princip fungování nástroje ilustruje diagram 3.1. Návštěvník webové aplikace s fasetovou navigací (budeme ji dále označovat jako
mateřskou aplikaci) komunikuje pomocí svého prohlížeče pouze s touto webovou aplikací. Teprve ona pomocí volání REST služby komunikuje s navrhovaným optimalizačním nástrojem. Posílá mu údaje o chování návštěvníků a získává specifická nastavení pro jednotlivé návštěvníky. Existence optimalizačního nástroje je pro návštěvníky mateřské aplikace skryta. K nástroji se však
lze přihlásit i přímo, přičemž tento přístup je určen výhradně pro administrátory, tedy typicky např. vývojáře mateřské webové aplikace.
Uvedená architektura je zvolena záměrně proto, aby nástroj bylo možné
integrovat s libovolnou platformou, jíž klient využívá k běhu své fasetové
navigace. Jediný požadavek na klientskou platformu v tomto případě tvoří
schopnost komunikovat pomocí HTTP protokolu. Předpokládáme využití zamýšleného nástroje zejména v oblasti webové fasetové navigace a v prostředí
webu komunikují pomocí HTTP protokolu všechny aplikace. Teoreticky však
nic nebrání využití nástroje i např. v desktopové aplikaci vybavené vhodnou
knihovnou pro síťovou komunikaci.
16
36
Vymezení pojmu klient vůči pojmům uživatel a návštěvník je součástí sekce 4.
3.3. Funkční požadavky
HTTP server
Visitor's
browser
HTTP connection
Web site with
Faceted Navigation
HTTPS connection
(REST API calls)
HTTP server
Admin's
browser
HTTPS connection
Facet Optimization
Tool
Obrázek 3.1: Konceptuální schéma nasazení aplikace.
3.3
Funkční požadavky
Systém umožní pomocí webového rozhraní:
• přihlášení uživatele, změnu hesla;
• vytvoření uživatelských účtů superuživatelem;
• specifikaci rolí uživatelů pro jednotlivé experimenty;
• správu přístupových klíčů pro klienty API;
• zobrazení a vhodnou vizualizaci veškerých naměřených dat týkajících se
daného experimentu;
• zobrazení chování jednoznačně identifikovaného uživatele fasetové navigace v čase (záznam jeho interakce s fasetami).
Systém umožní pomocí REST API:
• autentizaci klienta;
37
3. Požadavky
System
Authenticate
View
Experiment
Stats
Change
Password
User
Administrate
API Keys
Change User
Role
Experiment
Owner
Pause
Experiment
Obrázek 3.2: Diagram případů užití pro živé aktéry.
• vytvoření nového experimentu;
• nadefinování struktury faset a jejich hodnot pro experiment;
• registrování kliku na určitou hodnotu v určité fasetě návštěvníkem fasetové navigace identifikovaným jedinečným identifikátorem současně s registrováním počtu položek odpovídajících návštěvníkově volbě, registrování případného následného zrušení této volby;
• registrování doplňujících údajů o chování návštěvníka fasetové navigace:
stránkování, řazení, reset všech faset, opuštění fasetové navigace za účelem prozkoumání jedné konkrétní entity;
• generování náhodného pořadí faset a persistenci tohoto pořadí pro jednoznačně identifikovaného návštěvníka fasetové navigace;
• pozastavení experimentu;
38
3.3. Funkční požadavky
System
Authenticate
Create New
Experiment
Pause
Experiment
API
Client
Register New
Visitor
Access Visitor
Settings
Register Visitor
Behaviour
Obrázek 3.3: Diagram případů užití pro klienta API.
U každého experimentu budou evidovány následující údaje. Pokud to bude
vhodné, tak jednak v absolutním tvaru jako počet, tak v relativním tvaru jako
míra:
• kliknutí na hodnoty ve fasetách,
• kliknutí agregované na celé fasety,
• četnost hodnoty fasety v momentě kliku,
• okamžité zrušení volby fasety,
• kliknutí na nápovědu u dané fasety,
• nejmenší dosažený počet vyhovujících položek při práci s fasetovou navigací,
• střední doba mezi kliknutími na fasety.
39
3. Požadavky
Na uvedené funkční požadavky přímo navazuje návrh prototypu uživatelského rozhraní, který je uveden v kapitole 4.8.
3.4
Nefunkční požadavky
• Veškerá komunikace s aplikací by měla probíhat pomocí šifrovaného spojení, mimo jiné proto, že údaje o využití faset mohou být pro některé
subjekty citlivé.
• Integrace aplikace by měla být ze strany klienta co nejjednodušší.
• Nároky na nasazení provozovatelem by měly být co nejnižší.
V příloze jsou v tabulkách B.1 až B.9 uvedeny rozpracované specifikace
případů užití, které byly znázorněny výše na diagramech 3.2, 3.3.
40
Kapitola
Analýza a návrh
Objektově orientovaná softwarová analýza slouží k vytvoření konceptuálního
analytického modelu, který věrohodně popisuje problémovou doménu. Často se
o tomto modelu hovoří jako o počítačově nezávislém17 (Computer-Independent
Model) [1, s. 31]. Měl by zachycovat pouze popis toho, co zamýšlený systém
bude dělat, nikoli jak toho bude dosaženo [1, s. 138].
Oproti tomu softwarový návrh zpracovává konkrétní prostředky a postupy pro dosažení požadované funkcionality. Jeho cílem je připravit detailní
popis struktury a procesů připravovaného softwarového díla. Návrhový model může být buď platformově nezávislý (Platform-Independent Model), nebo
platformově závislý (Platform-Specific Model). V prvním případě podle něj lze
výsledný software naimplementovat v libovolném jazyce, v druhém případě již
model obsahuje konkrétní třídy, knihovny a postupy vlastní vybrané implementační platformě. V této práci se budeme snažit o platformově nezávislý
návrhový model.
Dále je součástí této kapitoly také několik oddílů, které se zabývají návrhem v obecnějším slova smyslu: návrh metodiky měření 4.6, návrh REST
API 4.7 a návrh uživatelského rozhraní 4.8.
4.1
Problémová doména
„Prvním krokem při tvorbě objektově orientovaného díla je objasnění problémové domény.“ [1, s. 173]. Rozborem širšího kontextu problémové domény
se zabývala celá kapitola 1, v sekci 3.1 byly popsány cíle pro navrhovanou
aplikaci; tyto v podstatě vymezují problémovou doménu v rámci širšího okolí
problematiky fasetové navigace. Nyní lze již zcela konkrétně identifikovat entity, které budou hrát v aplikaci klíčovou roli:
17
Přestože tento pojem zavádí metodika MDA (Model-Driven Architecture), kterou v této
práci nepoužíváme, lze jej uplatnit i na výstup objektově orientované analýzy, neboť cíle jsou
shodné.
41
4
4. Analýza a návrh
Stěžejní entitou v aplikaci je experiment. Každý experiment se skládá
z množiny faset. Fasetu definuje množina fasetových hodnot. K fasetové
hodnotě se může vztahovat jedna nebo více událostí, přičemž každá událost
je vázána na konkrétního návštěvníka.
K aplikaci přistupují prostřednictvím webového rozhraní klienti a uživatelé. Uživatelé jsou živí lidé, zatímco klienti jsou jiné webové aplikace.
Uživatelé mají přiřazeny role.
Každý experiment má přiřazen alespoň jednoho uživatele a alespoň jednoho klienta. Uživatel i klient však mohou přistupovat k více experimentům.
4.2
Analytické třídy
Vyjádřením výše uvedeného popisu problémové domény je diagram analytických tříd 4.1, jeho rozšířenou verzi doplněnou o atributy naleznete v příloze
na obrázku B.1.
User
*
1
*
1..n
Role
1..n
*
Experiment
Client
1
*
Facet
Visitor
1
1
*
FacetValue
1
*
Event
*
Obrázek 4.1: Základní analytické třídy.
42
4.3. Metodika návrhu
4.3
Metodika návrhu
Návrh aplikace vychází do velké míry z metodiky Domain Driven Design [9]
(dále jen DDD). Jak již název napovídá, klade tato metodika velký důraz
na problémovou doménu. Hlavní myšlenka spočívá v trvalé snaze uchovávat
v aplikaci věrohodný model domény, který bude neustále aktuální a bude
jasně oddělen od ostatních částí aplikace. Model musí dostatečně reflektovat
procesy v problémové doméně. Zároveň je však potřeba, aby klíčové koncepty
vhodně generalizoval, protože jedině tak může zůstat uspokojivě přehledný
[27].
Vhodné izolace modelu se dosahuje členěním aplikace do logických vrstev,
jak ilustruje obrázek 4.2. Vrstva uživatelského rozhraní je zodpovědná za
prezentaci stavu a funkcí aplikace, koncový přístup k datům a interpretaci
uživatelských příkazů. Aplikační vrstva zajišťuje chod aplikace, ale neobsahuje žádnou business logiku ani nezachycuje stav domény. Obojí je naopak
obsahem doménové vrstvy. Ta reprezentuje i veškeré procesy a omezení
domény. Persistenci doménových objektů zajišťuje vrstva infrastruktury,
která kromě toho může obsahovat další podpůrné mechanismy.
Členění aplikace na vrstvy není v oblasti návrhu softwaru ničím novým.
DDD však přináší nové pojetí, když vymezuje především doménovou vrstvu
vůči vrstvě aplikační. Reaguje tak na v praxi nejčastější formu problematického návrhu, ve kterém bývá role domény potlačena a v horším případě navíc
zcela smíchána s aplikační logikou.
Metodika DDD pracuje s šesti základními stavebními bloky. Entity jsou
objekty, které mají vlastní identitu a nejsou mezi sebou zaměnitelné. Tzv.
hodnotové objekty (value objects) na rozdíl od entit identitu nemají a můžeme je ničit a znou vytvářet bez ztráty jakékoli informace. Služby (services)
vykonávají operace s entitami. Metodika DDD klade velký důraz na rozumné
a pravdivé rozdělení kompetencí mezi služby a entity. V praxi to znamená,
že v entitách by se neměly objevit metody, které v problémové doméně nemají předlohu v podobě operace, kterou by entita skutečně sama prováděla.
(Např. článek se sám nepřeloží, proto by ani tato entita neměla mít takovou metodu. Naopak v systému může existovat služba pro překlad článků.)
Dalším stavebním kamenem jsou agregáty, skupiny vzájemně svázaných objektů, které jsou zapouzdřeny a navenek poskytují rozhraní pouze skrz jednu,
tzv. kořenovou entitu. Pomocí tohoto mechanismu se modelují různé závislosti, zodpovědnosti a omezení problémové domény. K vytváření složitějších
agregátů slouží továrny (factories). Konečně úložiště (repositories) zajišťují
potřebnou abstrakci nad datovou infrastrukturou, tedy nad konkrétním způsobem uložení dat, případně více zdroji dat. Úložiště poskytují základní operace
typu CRUD, ale starají se také o složitější dotazy a o sestavování objektového
grafu agregátů.
„Přestože je metodika zaměřena převážně na tvorbu rozsáhlejších softwarových projektů, které nemohou být vyvíjeny jinak než v týmu, muže mít
43
4. Analýza a návrh
výrazný přínos i pro relativně malý softwarový projekt (...). Následování metodiky totiž zaručí motivaci dostatečně porozumět danému problému, modelovat
jej, a vystihnout tak jeho principy. V neposlední řadě zajistí přehlednější členění jednotlivých celků aplikace a minimalizaci jejich vzájemných závislostí.“
[27, s. 17]
Obrázek 4.2: Vrstvy softwarové architektury podle [9].
4.4
Architektura
Velká část webových aplikačních rámců (frameworků), bez ohledu na platformu, staví na architektonickém vzoru Model–View–Controller (dále jen MVC).
Také aplikace, jež je předmětem této práce, bude při implementaci využívat
framework, který je na tomto vzoru postaven, proto si pojďme krátce připomenout hlavní principy a strukturu MVC.
Model18 je datovým a funkčním jádrem aplikace [29]. Jak již bylo uvedeno
výše a jak ze samotného názvu vyplývá, Model by měl doslova modelovat
procesy, objekty, asociace a omezení problémové domény. Jde o elektronickou
reprezentaci vhodné výseče reálného světa.
View je komponenta zajišťující pohled na Model, přičemž slovo pohled je
nutno chápat v přeneseném slova smyslu spíše jako hledisko, nebo perspektivu,
18
Pokud budeme v následujících odstavcích mluvit o Modelu jakožto jedné ze tří komponent vzoru MVC, budeme jej uvádět s velkým počátečním písmenem. V případě, že budeme
mít na mysli obecný model ve smyslu softwarového inženýrství, bude počáteční písmeno
malé.
44
4.4. Architektura
protože ne vždy má aplikace grafický uživatelský výstup. View si v momentě
potřeby vyžádá od Modelu aktuální stav, případně Model sám View uvědomí.
Často je View ztotožňováno s uživatelským rozhraním, zde je nutno podotknout, že zdaleka ne všechny aplikace postavené na vzoru MVC mají uživatelské rozhraní. Pokud jím však disponují, stává se View prostředníkem mezi
uživatelem a aplikací. Od uživatele přijímá příkazy, které dále předává Controlleru.
Controller určuje chování aplikace ve vztahu k uživateli, příp. neživému
klientovi. Přijímá skrze View jimi vyvolané podněty a reaguje na ně, přičemž
před zajištěním adekvátní reakce může volat metody Modelu.
Vztahy a vzájemnou komunikaci mezi všemi třemi uvedenými komponentami ilustruje obrázek 4.3.
Obrázek 4.3: Vztahy mezi Model, View a Controller podle podle [29].
Většina frameworků obsahuje podporu pouze pro View a Controller a implementaci Modelu nechává na bedrech programátorů a návrhářů. Tento přístup zcela naplňuje podstatu Modelu, jenž je již z definice plně závislý na
oblasti působnosti konkrétní aplikace. Uvedená situace vede ke stavu, kdy zatímco View a Controller bývají odbornou veřejností interpretovány víceméně
shodně, úloha, struktura i význam Modelu se mezi jednotlivými implementačními pojetími velmi liší. Na jedné straně se můžeme setkat s potlačením
významu Modelu, kdy jeho úloha je zploštěna na pouhou persistenci dat a je
tedy realizován pouhým přístupem do databáze, na druhé straně se lze setkat
i s opačným extrémem: bytněním Modelu, kdy jsou mu přiřazovány i kompetence, které mu nepřísluší. Pomocnou metodu pro usnadnění rozhodování, co
ještě do Modelu zařadit a co už ne, nabízí [30]: Model by měl plnit svoji funkci
i po nahrazení View a Controlleru. Lze např. zkusit nahradit grafické uživatelské rozhraní textovým, nebo aplikaci přepracovat pro nasazení ve formě
webové služby19 . Pokud při tom bude potřeba do Modelu zasáhnout, jedná se
19
Myšlena REST nebo SOAP webová služba.
45
4. Analýza a návrh
o indikátor nevhodného návrhu.
Pojetí Modelu v rámci této práce čerpá jednak z uvedené metodické pomůcky a dále z metodiky DDD. Podstatnou část Modelu tedy tvoří doménové
objekty a část servisních tříd.
4.5
Návrh doménového modelu
Na následujících diagramech tříd nejsou pro větší přehlednost uvedeny gettery
a settery pro běžné členské proměnné, pouze pro kolekce.
Diagram 4.4 představuje doménové třídy User, Client a Experiment. Z diagramu je patrné, že M:N asociace mezi uživatelem a experimentem a M:N
asociace mezi klientem a experimentem jsou modelovány jako vazební entity,
přičemž vazební entita UserBinding navíc váže doménovou třídu Role, která
na tomto diagramu není rozpracována. Sémantika této asociace je následující:
Uživatele může přistupovat k experimentům a pro každý experiment může mít
přidělenu nějakou roli.
User
- ID: int
- name: String
- email: String
- password: String
- salt: String
UserBinding
1
*
*
*
1
Role
Client
- ID: hash
- name: String
- secret: String
1
ClientBinding
1
*
Experiment
- ID: int
1
- name: String
- description: String
- URL: String
+ getFacets(): Collection
+ getEvents(): Collection
*
Obrázek 4.4: Návrhové třídy User, Client a Experiment.
Vazby mezi klíčovými doménovými třídami lze vidět na diagramu 4.5.
U třídy Experiment evidujeme název, popis a URL experimentu. U třídy Facet
evidujeme název a údaj static, který udává, zda se faseta účastní randomizace,
nebo zda je statická. Tento mechanismus umožní do systému zadat výjimky,
které se občas ve fasetových navigacích vyskytují v podobě fasety se zvláštním postavením. Entita FacetValue (fasetová hodnota) rovněž obsahuje název
a dále členské proměnné left, right a rootId, které jsou zde pro potřeby hierarchizace pomocí datové struktury Nested Set (popsána v oddíle 4.5.3).
Dále na diagramu 4.5 vidíme třídu Visitor reprezentující koncového návštěvníka fasetové navigace. Každý návštěvník je identifikován pomocí uni46
4.5. Návrh doménového modelu
Experiment
- ID: int
- name: String
- description: String
- URL: String
+ getFacets(): Collection
+ getEvents(): Collection
1
*
Facet
- ID: int
- externID: int
- name: String
- static: boolean
+ getFacetValues()
1
1
*
0..1
1
Visitor
- ID: UUID
- IPv4: String
- userAgent: String
EventType
- ID: int
- name: String
*
Event
*
1
*
- ID: int
- timestamp: int
- resultSetSize: int
0..1
*
1
*
FacetValue
- ID: int
- externID: int
- name: String
- left: int
- right: int
- rootId: int
1
*
FormerChoice
- ID: int
*
*
1
Obrázek 4.5: Návrhové třídy pro klíčové doménové entity.
verzálně jedinečného identifikátoru, viz oddíl 4.5.1. Dále u něj evidujeme IP
adresu, ze které webovou stránku s fasetovou navigací navštívil, a otisk jeho
user agenta, což je řetězec, který v HTTP požadavku posílají prohlížeče a je
pomocí něj možné rozlišit typ a verzi prohlížeče.
V samém středu diagramu je umístěna třída Event (událost), jež má vazby
na všechny ostatní uvedené třídy. Sémantika diagramu z perspektivy této třídy
je následující (po směru hodinových ručiček, začátek vlevo dole): událost má
určitý typ (např. kliknutí na fasetu, zrušení předchozí volby fasety, řazení výsledků atd.). Událost vyvolal konkrétní návštěvník. Událost spadá pod určitý
experiment, v rámci toho experimentu (fasetové navigace) mohlo být kliknuto na nějakou fasetu a fasetovou hodnotu (v případě, že tomu odpovídá
typ události). Třída FormerChoice reprezentuje ostatní kritéria, která v rámci
faset uživatel specifikoval dříve, než inicioval současnou událost. Tato třída
má pochopitelně vazbu na třídy faseta a fasetová hodnota, protože uplatnění
kritéria ve fasetové navigaci je definováno jako kliknutí na konkrétní hodnotu
v rámci konkrétní fasety. U každé události pochopitelně evidujeme její přesný
čas a dále velikost výsledné množiny objektů, jinými slovy kolik filtrovaných
objektů v rámci fasetové navigace odpovídá uživatelem specifikovaným kritériím.
47
4. Analýza a návrh
4.5.1
Podpora externích identifikátorů
Na diagramech návrhových tříd jsou patrné členské proměnné s názvem ID,
jež nesou unikátní identifikátor objektu dané třídy. Kromě něj mají však třídy
Facet a FacteValue ještě členskou proměnnou externID, která nese externí
identifikátor z klientské aplikace. Důvod tohoto řešení je jednoduchý, při propojení dvou systémů, které nezávisle na sobě uchovávají interní reprezentaci
nějaké entity, je potřeba, aby minimálně na straně jednoho z nich byl také uložen identifikátor toho samého objektu z druhého systému, tzv. binding, aby při
předávní entity mezi systémy mohlo dojít k překladu identifikátoru a správnému zařazení na straně příjemce. Jelikož jeden z cílů při návrhu aplikace je co
nejsnazší integrace na straně klienta, bude si identifikátory z klientského systému pamatovat námi navrhovaná aplikace. V opačném případě by si je musel
pamatovat klient a to by značně zesložitilo integraci, protože by to vyžadovalo persistenci na straně klienta. Takto stačí, když bude klient při zasílání
informací o událostech uvádět svoje interní identifikátory a serverová aplikace
údaje přeloží.
Elegantnějším řešením by zdánlivě bylo použití univerzálně unikátních
identifikátorů, tzv. UUID. To je mechanismus, který řeší výše uvedený problém s identifikací entit napříč různými systémy. Existuje několik různých verzí
UUID (algoritmů) [20], které zajistí, aby vygenerovaný identifikátor nekolidoval s žádným jiným identifikátorem v žádném jiném systému. Nicméně použití
v našem případě se nejeví jako rozumné, protože klienti již budou mít zpravidla
svoji strategii pro přidělování identifikátorů naimplementovanou a vyžadovat
její změnu pouze kvůli zavedení nástroje pro optimalizaci faset je nesmyslné.
Pojďme pro úplnost shrnout, s jakými identifikátory klient při ostrém provozu manipuluje a které z nich si musí pamatovat. Identifikátor aktuálního
návštěvníka získá v rámci HTTP požadavku z hlavičky Cookie, proto si jej
pamatovat nemusí. Identifikátor faset a fasetových hodnot, na které bylo kliknuto, zná, neboť při komunikaci může uvádět své interní identifikátory. Ani
v tomto případě si tedy nemusí pamatovat žádanou novou informaci. Jedinými
údaji, které musí persistovat na své straně, jsou ID experimentu, kterého se
zasílané události týkají, a svůj klientský klíč spolu se sdíleným heslem pro autentizaci každého požadavku na API. Celkem jde tedy o pouhé tři proměnné,
jejichž hodnoty mohou být v implementaci přímo vepsány do kódu.
4.5.2
Identifikace návštěvníků
Jak bude později uvedeno v oddíle 4.6, ve fázi měření je žádoucí, aby pro každého návštěvníka bylo pořadí faset jiné. Na druhou stranu uživatelský požitek
a vůbec ergonomie fasetové navigace by byla narušena, pokud by návštěvník při každé návštěvě viděl jiné pořadí faset. Proto zavádíme mechanismus,
který zajistí konzistentní pořadí faset pro každého návštěvníka po celou dobu
měření.
48
4.5. Návrh doménového modelu
Diagram 4.6 ukazuje vazební entitu FacetPosition, která zajišťuje persistenci pořadí faset pro návštěvníky. Sémantiku diagramu lze interpretovat
následujícím způsobem: Experiment má pro každého návštěvníka jiné pořadí
faset. Také lze však asociace číst z druhé strany: Návštěvník může být přiřazen
k více experimentům. Na tomto místě by bylo vhodné vysvětlit, proč nemá
návštěvník přímou asociaci na experiment a proč model připouští více experimentů pro jednoho návštěvníka. Nejprve je však nutno vysvětlit mechanismus
identifikace návštěvníků.
Experiment
- ID: int
- name: String
- description: String
- URL: String
+ getFacets(): Collection
+ getEvents(): Collection
Facet
1
*
- ID: int
- externID: int
- name: String
- static: boolean
+ getFacetValues()
1
1
*
FacetPosition
- position
*
*
1
Visitor
- ID: UUID
- IPv4: String
- userAgent: String
Obrázek 4.6: Datový model pro persistenci pořadí faset pro návštěvníky.
Při první návštěvě je návštěvníkovi přidělen identifikátor a tento je na
straně návštěvníkova prohlížeče uložen ve formě cookie. Situaci ilustruje diagram 4.7. Při každém dalším požadavku již návštěvník posílá tento identifikátor v HTTP požadavku, takže mateřská aplikace s fasetovou navigací
může měřené události předávat dál opatřené identitou návštěvníka, který je
inicioval.
Cookie je však platná minimálně pro celou doménu třetího řádu [18] a na
jedné takové doméně (např. www.example.org) může být umístěno více fasetových navigací a všechny může být žádoucí měřit pomocí navrhovaného
nástroje. Proto nemá návrhová třída Visitor přímou vazbu na Experiment
a návštěvník může být sdílen mezi více experimenty.
Uvedený postup zajištění konzistence testovaného uživatelského rozhraní
mezi jednotlivými návštěvami stejného uživatele pomocí mechanismu cookies
je standardně používán i u A/B a multivariantních testovacích nástrojů, o kterých byla řeč v oddíle 2.2.
Ze sekvenčního diagramu 4.7 dále plyne, že výběr konkrétního formátu
49
4. Analýza a návrh
Visitor's
Browser
Website with
Faceted Navigation
request for page
Facet
Optimizer
request for new identifier
identifier
setCookie(identifier)
Obrázek 4.7: Přidělování identifikátorů návštěvníkům.
přidělovaných identifikátorů zůstává v kompetenci námi navrhované aplikace.
Vzhledem k tomu, že cookie jsou čitelné a manipulovatelné ze strany návštěvníka, nebude vhodné jako identifikátory použít posloupnost přirozených čísel.
Lepším řešením se jeví použití např. hashovací funkce nebo v předchozím oddíle zmíněného UUID.
4.5.3
Datové struktury
Pro uložení hierarchických datových struktur do relační databáze existují
různé přístupy. Zpravidla je efektivita části základních operací vykoupena neefektivitou zbývajících základních operací. Při důrazu na co nejvyšší výkon při
operaci čtení se v posledních letech s oblibou používá koncept obecně známý
pod názvem Nested Set ( „zanořená množina“), publikovaný původně bez
tohoto označení [16].
Jedná se o strom, jehož uzly jsou očíslovány dvakrát: při prvním a při
posledním průchodu. Atributy uzlu se většinou označují left a right. Tato
struktura umožňuje pomocí jediného dotazu do databáze vybrat libovolný
podstrom. Stačí pouze specifikovat omezení na hodnoty left a right. Další výhodou je primitivní test na existenci podstromu u určitého uzlu, stačí pouze
odečíst hodnotu right od hodnoty left a pokud je výsledkem jedna, víme, že
žádný podstrom neexistuje.
Rychlost čtení je vykoupena cenou úpravy struktury stromu, kdy je nutno
přečíslovat všechna pole left a right s hodnotami vyššími nebo rovnými hodnotám těchto polí u právě vkládaného uzlu.
Struktura Nested Set se jeví jako vhodná pro ukládání fasetových hodnot. U nich potřebujeme podporovat hierarchické struktury. Dražší operace
vytvoření struktury není na obtíž, protože se projeví pouze při specifikaci
experimentu a při jeho běhu se ze struktury už pouze čte.
50
4.6. Návrh metodiky měření
1
2
3
10
7
4
5
8
9
6
Obrázek 4.8: Nested Set
4.6
Návrh metodiky měření
Stěžejní úlohou navrhovaného nástroje bude měřit „žádanost“ jednotlivých
faset návštěvníky, neboť po skončení měření je cílem seřadit fasety od nejvíce
žádaných, po nejméně žádané a dosáhnout tak optimálního řazení. Žádanost
můžeme měřit jako poměr počtu kliknutí na danou fasetu ku celkovému počtu kliknutí na všechny fasety. Nicméně výsledky takovéhoto přístupu by byly
ovlivněny pořadím faset v době měření. Uživatelské rozhraní obsahující fasety tvoří dvourozměrnou plochu, kterou uživatelé prozkoumávají postupně,
zpravidla od levého horního rohu, a nevěnují tak všem fasetám rovnoměrnou
pozornost.
Abychom zajistili všem fasetám rovnoměrnou pozornost uživatelů a následně mohli změřit jejich míru prokliku, je potřeba pořadí faset měnit. Přesněji formulováno: potřebujeme zajistit, aby pořadí fasety bylo náhodnou veličinou s rovnoměrným rozdělením.
Toho lze dosáhnout pomocí generování náhodného pořadí faset pro jednotlivé návštěvníky fasetové navigace. Pro nově příchozího návštěvníka určíme
pořadí faset tím způsobem, že každou fasetu ohodnotíme pomocí generátoru
náhodných čísel a podle přidělených hodnot pak fasety seřadíme. Vygenerované pořadí je však potřeba uchovávat, aby bylo konzistentní v průběhu všech
návštěv daného člověka, jako to dělají A/B testovací nástroje zmíněné v sekci
2.2, jinak by byl narušen uživatelský prožitek a zhoršila by se použitelnost
stránky s fasetovou navigací.
Uvedený postup je motivcí pro existenci návrhové třídy FacetPosition uvedené na diagramu 4.6, pomocí níž je uchováváno pořadí faset v závislosti na
experimentu a návštěvníkovi, a je důvodem, proč klientská aplikace při každém zobrazení stránky s fasetovou navigací volá API optimalizačního nástroje,
51
4. Analýza a návrh
konkrétně GET /api/facet-position, viz v následující sekci.
4.7
Návrh REST API
Programovací rozhraní (API) představuje jednu z nejdůležitějších součástí navrhované aplikace. Přes něj bude probíhat veškerá komunikace s klientskými
aplikacemi a bude tudy plynout drtivá většina nových dat. Návrhu API byla
proto věnována zvýšená pozornost.
Representational state transfer (REST) [11] je distribuovaná síťová architektura navržená pro prostředí Webu. Je úzce spjatá s protokolem HTTP;
dokonce ji velmi zjednodušeně můžeme chápat jako sadu pravidel a doporučení, jak navrhovat webová aplikační rozhraní komunikující právě pomocí
protokolu HTTP.
REST je na rozdíl od jiných síťových architektur, jako je XML-RPC či
SOAP, zaměřen na přenos stavu zdrojů dat (resources) a nikoli na vzdálené
volání procedur/funkcí. Pro manipulaci se zdroji využívá čtyři základní metody protokolu HTTP a to GET, POST, PUT a DELETE.
Navrhovaná aplikace bude pracovat se zdroji, jež vychází ze základních
doménových tříd: experiment, faseta, návštěvník atd. Nad těmito zdroji je
možné uskutečňovat uvedené HTTP metody, ovšem ne nade všemi zdroji mají
všechny metody smysl. Bližší přehled o podpoře jednotlivých metod u různých
zdrojů poskytuje tabulka C.1. V případě, že klient uplatní na určitý zdroj
nepodporovanou metodu, server odpoví chybovým kódem 405 (Method Not
Allowed) [26, s. 272].
4.7.1
Scénář volání API
Existuje několik scénářů volání REST API, které lze rozdělit do dvou skupin. První skupinu tvoří scénáře Vytvoření nového experimentu (diagram C.1)
a Úprava nebo smazání experimentu (diagram C.2). Druhou skupinu tvoří scénáře Identifikace nového návštěvníka a Zaznamenání nové události sdružené
do jednoho diagramu 4.9.
4.7.2
Formáty dat
Známé pravidlo o návrhu REST rozhraní říká, že formát zdroje (tzv. media
type) by neměl být obsažen v URI ve formě přípony a že vhodným způsobem,
jak informovat klienta o formátu dat, je HTTP hlavička Content-type. Pokud
naopak žádá specifický formát dat sám klient, měl by použít hlavičku Accept
[22, s. 32].
Tohoto pravidla se budeme držet i my. Navržené API bude pro všechny
zdroje podporovat výstupní formáty application/xml a application/json,
přičemž první z nich bude výchozí a o druhý bude klient moci požádat hlavič52
4.7. Návrh REST API
Client
REST API
POST /api/visitor
201 Location /api/visitor/«ID»
GET /api/facet-position?experimentId=«ID»&visitorId=«ID»
loop
[for each click on facets]
POST /api/event
Obrázek 4.9: Identifikace nového návštěvníka a zaznamenání nové události
pomocí REST API.
kou Accept. Pokud si klient vyžádá jiný media type, bude výsledkem volání
metody HTTP chybový kód 406 (Not Acceptable).
Metody PUT a POST budou na vstupu podporovat pouze media type
application/xml. Pokud bude klientem zaslána hlavička Content-type s jiným obsahem, server odpoví chybovým kódem 415 (Unsupported Media Type)
[22, s. 32]. Pokud hlavička zaslána nebude, pokusí se API vstup parsovat,
případně validovat oproti XML Schema (viz dále), a pokud neuspěje zobrazí
vhodné chybové hlášky a pošle chybový kód 400 (Bad Request).
4.7.3
Validace vstupních dat
Validace XML dat zaslaných pomocí metod POST a PUT bude probíhat
oproti XML Schema specifikacím jednotlivých zdrojů.
Kromě toho pochopitelně musí proběhnout i jiné kontroly vstupu, např.
kontrola konzistence, která zajistí odmítnutí požadavků obsahujících identifikátory neexistujících zdrojů, popřípadě zdrojů, které nejsou v souladu s jinými
v požadavku identifikovanými zdroji (např. fasetová hodnota nespadající do
uvedené fasety apod.).
53
4. Analýza a návrh
4.7.4
Autentizace
Přístup k veškerým zdrojům REST API bude podmíněn použitím registrovaného API klíče (obdoba uživatelského jména účtů pro živé lidi) a zasláním
platného podpisu (tzv. signature) pro aktuální požadavek.
Při vytváření příslušného API klíče v uživatelském rozhraní vygeneruje
systém i tzv. sdílené heslo (shared secret), což je obdoba hesla uživatelských
účtů živých lidí. Uživatel (v roli administrátora experimentu) si sdílené heslo
zkopíruje a použije jej při implementaci klienta API. Server si dvojici klíč–
sdílené heslo uloží.
Místo aby se při každém požadavku posílala dvojice API klíče s sdíleného
hesla, pošle se pouze klíč a podpis požadavku. Ten vznikne jako výsledek
funkce HMAC [17] těla požadavku a sdíleného hesla. Pomocí tohoto postupu
se zamezí posílání sdíleného hesla a zároveň server bude moci ověřit autenticitu
požadavku, neboť si sám spočítá HMAC z těla přijatého požadavku a sdíleného
hesla patřícímu k danému klíči a výsledek porovná se zaslaným podpisem.
Popsaný postup [25] je poměrně rozšířený mezi webovými službami velkých internetových hráčů, používá jej např. Amazon Web Services nebo Google Checkout. Potenciální slabinou je nutnost ukládat sdílené heslo v původní
podobě v databázi serveru. To kontrastuje s dobrým zvykem neuchovávat uživatelská hesla v databázi v původní podobě, uchovávat pouze jejich otisky
a navíc solené. V tomto případě tento postup nelze uplatnit, protože bez znalosti původního sdíleného hesla by server nemohl požadavky validovat, viz výše
uvedený princip. Nicméně na tomto místě je nutno podotknout, že existuje zásadní rozdíl mezi uživatelskými hesly a sdílenými hesly. První uvedené řetězce
pocházejí přímo od uživatelů a v případě prolomení ochrany serveru a jejich
získání lze část uživatelů kompromitovat, neboť mohou používat stejné heslo
i k jiným službám. V druhém případě však řetězec generuje sama aplikace
a v případě prolomení ochrany databáze se kompromitace nerozšíří za hranice
dané služby. Navíc lze případný úspěšný útok následně řešit vygenerováním
nových dvojic klíč–sdílené heslo.
4.8
Návrh uživatelského rozhraní
Proces návrhu uživatelského rozhraní staví na případech užití zpracovaných
v kapitole 3. Prvním krokem je tvorba tzv Low-fidelity (zkráceně Lo-fi) prototypů. Jejich hlavním úkolem je ověřit a případně dále rozvinout nápady
týkající se obsahu, estetické stránky a interakce uživatele s uživatelským rozhraním [31]. Toho všeho dosahují Lo-fi prototypy za velice nízkých nákladů,
protože bývají připraveny načrtnutím v libovolném grafickém editoru, nebo
případně i tužkou na papíře.
Prototypy byly tvořeny s ohledem na známé Nielsenovo desatero [23], což je
sada heuristik formulující základní principy pro návrh uživatelských rozhraní.
54
4.8. Návrh uživatelského rozhraní
Náčrty byly vytvořeny v prototypovacím nástroji Balsamiq20 . Kompletní sadu
lo-fi prototypů lze najít v příloze D.
4.8.1
Vyhodnocení lo-fi prototypů
Prototypy byly testovány vytištěné na papír na dvou respondentech zběhlých
v práci s počítačem a zvyklých pohybovat se na Webu. Respondenti pomocí
tužky ukazovali, kde mají zájem kliknout, a podle toho jim byl předložen další
kus papíru s navazujícím uživatelským rozhraním.
Z tohoto rychlého testování vyplynuly především následující závěry:
1. Oba respondenti si stěžovali, že aplikace nemá nějakou „vizuální identitu“,
tedy logo nebo název, na které jsou zvyklí z webových stránek.
2. Jeden respondent navrhl, aby logo nebo název převzalo funkci tlačítka
Overview.
3. Oba respondenti měli problém s interpretací vizuálních grafů na stránce
s přehledem experimentu (obr. D.2). Jeden respondent považoval graf za
vyjádření součtu všech akcí v tabulce po pravé straně, druhý respondent
si tabulku s grafem vůbec nespojil a domníval se, že jde o prvky zcela
nesouvisející co se týče „datového základu“.
Vzhledem ke zjištěným problémům bylo rozhodnuto, že hlavní menu obsahující položky Overview a Settings bude zcela odstraněno. Funkci první položky převezme klikatelné logo/název umístěný v levém horním rohu. Funkci
druhé položky převezme textový řetězec s názvem aktuálně přihlášeného uživatele, který je umístěn v pravém horním rohu. V rámci webových aplikací
není neobvyklé, že právě přes něj se uživatel dostane na stránku s osobním
nastavením.
Dále bylo rozhodnuto přepracovat detail experimentu tak, aby nad vizuálním grafem byl umístěn filtr událostí podle jejich typu a zobrazovaný graf
včetně absolutních čísel se týkal vždy jen jednoho vybraného typu událostí.
20
http://builds.balsamiq.com/b/mockups-web-demo/
55
4. Analýza a návrh
Obrázek 4.10: Lo-fi prototyp titulní stránky aplikace.
56
Kapitola
5
Implementace
5.1
Použité technologie
Aplikace navržená v této práci byla naimplementována pomocí jazyka PHP
s využitím frameworku Zend a nástroje pro objektově-relační mapování Doctrine 2.
V této kapitole popíšeme klíčové vlastnosti uvedených softwarových produktů,
které byly důvodem pro jejich použití.
5.1.1
PHP
PHP je skriptovací jazyk pro vývoj webových aplikací s téměř 17letou historií. Teprve po roce 2004, kdy vyšla verze 5, se však začal vyvíjet vstříc plnohodnotné platformě pro objektově orientovaný vývoj. V současnosti nabízí
podporu standardních stavebních mechanismů OOP jako jsou třídy, dědičnost, abstraktní třídy a interfaces, zapouzdření, reflexi. V aktuálně používané
stabilní verzi 5.3 navíc obsahuje podporu jmenných prostorů, lambda funkcí
i closures.
Jazyk PHP byl vybrán především pro značnou rozšířenost této platformy
mezi webovými servery. Podle21 používá PHP verze 5 více než 70 % webových
prezentací na Internetu, u nichž se podařilo zjistit programovací jazyk. Použití
jazyka hojně podporovaného webovými servery významně snižuje nároky na
nasazení výsledné aplikace, což je jeden z požadavků uvedených v sekci 3.
5.1.2
Zend Framework
Zend Framework22 (zkráceně ZF) je webový aplikační rámec pro jazyk PHP
vyvíjený firmou Zend a komunitou dobrovolníků v režimu open-source s licencí
New BSD. V současné době ve verzi 1.11 obsahuje přes 60 modulů řešících
zpravidla úzce vymezenou problematiku, např. autentizaci, logování, kešování,
21
22
http://w3techs.com/technologies/details/pl-php/5.3/all
http://framework.zend.com/
57
5. Implementace
správu přístupových práv atd. Framework lze použít buď jako základ pro vývoj MVC webové aplikace (v takovém případě se staví na základních modulech
Zend_Application, Zend_Controller, Zend_View ...) nebo lze jednotlivé moduly použít samostatně a integrovat je do stávající aplikace jako knihovny.
5.1.3
Doctrine 2
Doctrine 223 je nástroj pro objektově-relační mapování (ORM) napsaný v jazyce PHP. Zatímco verze 1 významně stavěla a návrhovém vzoru Active Record, který s sebou nese mnoho nevýhod (povinnost entit dědit od určité nadtřídy, nevhodné míchání kompetencí, horší testovatelnost), verze 2 používá
odlišný přístup: návrhový vzor Data Mapper. Ten umožňuje, aby doménové
objekty vyvíjené aplikace obsahovaly jen ty operace, které jsou skutečně v jejich kompetenci a zodpovědnost za operace týkající se persistence přenáší na
tzv. mapovací objekt.
Použití Doctrine 2 představuje výraznou pomoc při snaze o naplnění stěžejních principů DDD. Pomáhá izolovat doménovou vrstvu od vrstvy infrastrukturní pomocí přímé podpory úložišť (repositories). Každá entita tak může
mít svoje úložiště, které poskytne základní operace persistence, ale i složitější
dotazovací metody.
Při práci s jakýmkoli nástrojem pro objektově-relační mapování se potýkáme s problémy souvisejícími s procházením objektového grafu. Programátor
se nemůže „chovat zcela objektově“ a musí mít neustále na paměti principy
mapování na relace a uvažovat o způsobu, jakým se průchod grafem přeloží do
relačních dotazů. Celý objektový graf pochopitelně nelze načíst z databáze do
paměti, proto bývá typicky načten jeden nebo více objektů jedné třídy a při
následném přecházení k jiným objektům pomocí asociací mezi nimi dochází
k pokládání dalších a dalších dotazů do databáze. Velmi jednoduchý a racionálně motivovaný průchod objektovým grafem tak může vést k obrovskému
množství databázových dotazů. Jako příklad uveďme požadavek na vypsání
všech zaměstnanců a jejich kontaktních údajů. V prvním kroku je pomocí jediného dotazu načten seznam zaměstnanců. Při následném průchodu pomocí
cyklu musí být pro každého zaměstnance načteny kontaktní údaje a dojde tedy
ke spuštění minimálně tolika dalších dotazů do databáze, kolik je zaměstnanců.
Snadno si lze představit více úrovní zanoření a následný exponenciální nárůst
počtu dotazů do databáze. K tomuto jevu typicky dochází, když programátor
používá ORM jako black-box a neuvažuje nad tím, jak je průchod objektovým
grafem transformován na dotazy do relační databáze.
Doctrine 2 tento problém elegantně řeší pomocí vlastního dotazovacího jazyka DQL, který je sice na první pohled syntaxí podobný SQL, ale ve skutečnosti je čistě objektově orientován. V jednotlivých úložištích můžeme definovat
vlastní dotazovací metody, které pomocí jazyka DQL určí, do jaké hloubky se
23
58
http://www.doctrine-project.org/
5.2. Implementace klienta
má objektový graf načíst. Doctrine pak tento dotaz vyhodnotí pomocí jednoho
databázového SQL dotazu a následně objektový graf sestaví. Sice stále platí,
že programátor k efektivní implementaci výše uvedeného musí předem znát
potřebný způsob průchodu objektovým grafem, při vlastním průchodu však
již nedochází k žádnému volání databáze a programátor může uvažovat čistě
objektově.
Kromě objektově-relačního mapování slouží Doctrine také jako abstraktní
vrstva nad jednotlivými databázovými stroji. Aplikace postavená na Doctrine
může při nasazení používat databázi Oracle, MS SQL Server, MySQL, PostgreSQL nebo SQLite. Tento fakt opět výrazným způsobem ovlivní pozitivním
směrem nároky na nasazení implementované aplikace.
5.1.4
APC
APC je zkratka pro Alternative PHP Cache. Jedná se o framework určený
primárně pro kešování kompilovaného bytekódu PHP skriptů, ale díky uživatelsky přístupnému rozhraní umožňuje kešovat libovolná data.
Význam APC roste při použití rozsáhlých frameworků jako je Zend Framework. Tyto aplikační rámce obsahují často tisíce zdrojových souborů, které
by při každém dotazu musely být znovu kompilovány. Použití cache ušetří
nejen procesorový čas, ale především cenné zlomky sekund při odbavování
požadavků směřovaných na webovou aplikaci.
APC využívá mimo jiné i Doctrine 2 a to k několika účelům. Jednak jako
tzv. Query Cache, kdy dochází k uložení překladu jazyka DQL na standardní
SQL, dále tzv. Metadata Cache, která slouží k ukládání mapovacích informací
pro jednotlivé doménové třídy a konečně Result Cache, jež jednoduše kešuje
výsledky jednotlivých dotazů a může tak zcela eliminovat potřebu opakovaného dotazování.
5.2
Implementace klienta
V zájmu uskutečnění testů aplikace na reálných datech byo potřeba naimplementovat klientskou část, která bude komunikovat s optimalizačním nástrojem
pomocí jeho REST API, popsaného v kapitole 4.7. Za tímto účelem byl využit modul Zend Frameworku s názvem Zend_Rest_Client. Nad ním byla
postavena třída Service_FacetOptimizer_Rest, která je vizualizována na
diagramu B.3 a lze ji nalézt na přiloženém CD (viz příloha E).
Uvedená třída zajišťovala veškerou komunikaci s optimalizačním nástrojem, pojďme si však blíže vysvětlit, kde a jak byla jednotlivá volání API iniciována.
V momentě příchodu nového návštěvníka na stránku s fasetovou navigací (přesněji při odeslání návštěvníkova HTTP požadavku) zavolal obsluhující
PHP skript metodu Service_FacetOptimizer_Rest::postNewVisitor(), načež obdržel identifikátor pro nového návštěvníka a tento později v HTTP od59
5. Implementace
povědi předal ve formě cookie. (Situaci již dříve ilustroval v trochu obecnější
rovině diagram 4.7.) Ještě předtím však obsluhující skript provedl druhé volání API prostřednictvím metody
Service_FacetOptimizer_Rest::getFacetOrder(), pomocí něhož získal náhodně vygenerované pořadí faset pro návštěvníka. Následně skript svoji činnost dokončil a odeslal výslednou stránku s fasetovou navigací (a případným
další obsahem) v HTTP odpovědi návštěvníkovi. V situaci, kdy návštěvník
již identifikátor ve formě cookie má přidělen, se odehrává pouze druhé volání
API. V obou případech jde o synchronní volání, neboť se čeká na reakci
REST API a teprve poté je výsledná stránka odeslána návštěvníkovi.
Zachytávání jednotlivých událostí generovaných návštěvníkem v rámci faset bylo však naimplementováno mírně odlišně. Bylo použito skriptování na
straně prohlížeče a informace o událostech byly zasílány asynchronně pomocí
AJAXu na jiný obsluhující PHP skript. Ten měl za úkol požadavek pouze přeposlat na API pomocí volání metody
Service_FacetOptimizer_Rest::postNewEvent(). Nutnost tohoto
„prostřednictví“ pramení v bezpečnostním konceptu jménem Same Origin Policy, který uplatňují prohlížeče a který zamezuje možnosti volání AJAXových
požadavků mimo doménu, na které se stránka se skriptem nachází.
60
Kapitola
Testování
6.1
Jednotkové testy
Jednotkové testy (unit tests) mají za úkol testovat nejmenší autonomní celky
kódu, což jsou v případě objektově-orientovaného přístupu třídy. Pro každou
třídu existuje jeden test též ve formě třídy obsahující mnoho metod, z nichž
každá testuje jednu konkrétní vlastnost, funkčnost nebo chování testované
třídy. Vlastní testování je prováděno postupným automatizovaným spuštěním
všech testů. Běh může být přerušen, pokud některý test selže, nebo jsou chyby
hlášeny pohromadě po skončení všech testů, to závisí na konkrétní strategii.
Důležité je, že testy jsou navzájem zcela nezávislé, takže selhání jednoho testu
neovlivní jiné testy.
Část aplikace byla vyvíjena přístupem Test-Driven Development (TDD),
který předpokládá nejprve napsání jednotkových testů pro plánovanou funkcinalitu, následně rychlou (někdy naivní) implementaci tak, aby testy prošly bez
chyby, a poté může přijít přepracování kódu (tzv. refactoring) do přehlednější,
případně efektivnější podoby. Takto bylo vyvíjeno především REST API.
Síla TDD přístupu spočívá tom, že nutí vývojáře detailně si ujasnit, co
od implementované třídy chce. Aby mohl napsat test, musí být nejprve schopen exaktně vyjádřit kritéria pro jeho splnění. Testy tak slouží jako detailní
formální specifikace funkčnosti jednotlivých tříd. Pokud je TDD uplatňováno
zodpovědně a i následné úpravy kódu jsou nejprve vyjádřeny pomocí testů,
pak testy poskytují vždy aktuální přehled o stavu implementace.
TDD přístup byl uplatňován za pomocí testovacího frameworku PHPUnit24 .
Jednotkové testy jsou součástí zdrojového kódu na přiloženém CD (příloha
E).
24
http://www.phpunit.de
61
6
6. Testování
6.2
Testování výkonu
Z hlediska výkonnosti je nejkritičtější částí aplikace REST API. Některé jeho
zdroje mohou být volány synchronně a na rychlosti odezvy proto může záležet celková odezva mateřské aplikace s fasetovou navigací. Případné dlouhé
prodlevy se negativně projeví na uživatelském prožitku návštěvníků.
Rozhodli jsme se proto změřit střední dobu odbavení nejčastěji používaných dvojic HTTP metoda – zdroj, konkrétně:
• POST /api/visitor
• GET /api/facet-position
• POST /api/event
Odezvy spojení byly měřeny za tří následujících konfigurací:
1. přes nezabezpečené HTTP spojení,
2. přes šifrované SSL spojení,
3. přes šifrované SSL spojení se zapnutým APC na straně optimalizační
aplikace.
Jak mateřská aplikace v roli klienta, tak optimalizační aplikace v roli serveru jsou naprogramované v jazyce PHP a běžely na virtuálních linuxových
serverech v rámci fyzických serverů umístěných na páteřní síti v Praze. Pro
dokreslení průměrná odezva příkazu PING z klienta na server byla 0.363 ms.
Doba odezvy byla měřena přímo v kódu na straně klienta se začátkem těsně
před odesláním HTTP požadavku a koncem v momentě obdržení odpovědi.
Střední doba odezvy byla pro danou kombinaci konfigurace–metoda–zdroj
vypočítána vždy ze vzorku 2000 změřených volání.
Výsledky ilustruje graf na obrázku 6.1. Z grafu je patrné, že provozování
spojení přes SSL spojení znamená nezanedbatelný nárůst doby odezvy, který
se však podařilo vykompenzovat zapnutím APC cache. Výsledná celková odezva pod hranicí 0.2 sekundy je akceptovatelná, není však nijak osluňující.
V popisu implementace klienta 5.2 bylo uvedeno, že v našem případě bylo
volání POST /api/event implementováno jako asynchronní, zatímco
POST /api/visitor a GET /api/facet-position jako synchronní. V případě, kdy návštěvník zavítá na stránku s fasetovou navigací poprvé, dojde
k oběma posledně uvedeným voláním za sebou (viz obr. 4.9), což už znamená
souhrnnou odezvu cca 0.4 sekundy. Při dalších zobrazeních fasetové navigace
se sice již POST /api/visitor nevolá, i tak však celková odezva zavdává důvod k zamyšlení nad možnostmi dalšího zrychlení.
Vzhledem k tomu, že volání GET /api/facet-position je nutné uskutečnit při každém zobrazení libovolné stránky fasetové navigace, aby klient zjistil
62
6.3. Ověření implementovaného software
0,40
čas v sekundách
0,35
0,30
0,25
0,20
0,15
0,10
0,05
0,00
POST /api/visitor
GET /api/facet-position
bez SSL
SSL
POST /api/event
SSL + APC
Obrázek 6.1: Celková odezva tří nejpoužívanějších kombinací HTTP metoda
- REST zdroj za tří různých konfigurací.
vygenerované pořadí faset pro aktuálního návštěvníka, a vzhledem k tomu, že
toto pořadí se ve fázi experimentu „měření“ v čase nemění, stálo by za úvahu
zavést nějakou formu kešování těchto informací na straně klienta.
Záleží vždy na konkrétním případu, zda se výše navržené zrychlení vyplatí
implementovat. Jeho nevýhodou je, že přenáší kompetence z optimalizační
aplikace na klienta a zvyšuje nároky na implementaci celé služby. Pokud má
však rychlá odezva stránek vysokou prioritu, vyplatí se implementaci zvážit.
6.3
Ověření implementovaného software
Pro ověření funkčnosti implementovaného software na reálných datech byla
aplikace nasazena do ostrého provozu pro měření fasetové navigace v internetovém obchodě České koupelny (http://www.ceske-koupelny.cz/). Jedná
se o středně velký e-shop s koupelnovým vybavením čítající zhruba 4 000 položek zboží a průměrnou denní návštěvností okolo 1 000 uživatelů. V rámci
prezentace existuje sedm kategorií zboží, které disponují fasetovou navigací,
přičemž každá z nich sestává z jiných faset, výjimkou je pouze faseta Výrobce,
která je pro všechny společná.
V optimalizačním nástroji bylo tedy založeno sedm experimentů pojmenovaných pro snadnou orientaci podle příslušných kategorií, viz přehledová
tabulka 6.1.
Všechny experimenty běžely současně na přelomu dubna a května 2012
po dobu 12 dní. Během této doby vidělo alespoň jeden z experimentů 2 900
unikátních návštěvníků a bylo zaznamenáno celkem 18 600 jimi vyvolaných
63
6. Testování
kategorie
vodovodní baterie
sprchové kouty
sprchové vaničky
sprchové boxy
umyvadla
zrcadla
osvětlení
počet faset
6
6
5
8
7
2
3
počet položek zboží
853
346
206
93
266
65
35
Tabulka 6.1: Přehled testovaných kategorií zboží s fasetovou navigací.
událostí. Přesně podle metodiky uvedené v sekci 4.6 bylo každému návštěvníkovi vygenerováno náhodné pořadí faset pro každý experiment, který navštívil
(toto se již odehrávalo pomocí navrhnuté a naimplementované funkcionality
optimalizačního nástroje). Výjimkou byla faseta výrobce, která má v obchodě
České koupelny speciální postavení a je umístěna z prostorových důvodů nad
ostatními fasetami, proto byla z náhodného řazení vynechána.
V průběhu měření nebyly zaznamenávány události typu kliknutí na nápovědu fasety, protože obchod České koupelny takovými nápovědami nedisponuje. Nebyla tak bohužel změřena případná problematická formulace názvů
faset, kvůli níž tento typ událostí nástroj podporuje. Události všech ostatních typů zaznamenávány byly. Přehled jejich počtů naměřených v rámci jednotlivých experimentů předkládá tabulka 6.2. Povšimněme si předposledního
řádku tabulky, který uvádí počty konverzí25 , můžeme tedy mimo jiné vidět,
které kategorie jsou z hlediska obchodního výkonu nejproduktivnější.
Screenshoty z implementované aplikace zachycující četnosti využití faset
v jednotlivých experimentech jsou uvedeny na obrázcích D.9 - D.15.
6.3.1
Vyhodnocení experimentů
V experimentech osvětlení, zrcadla a sprchové boxy bylo získáno příliš málo
dat na to, aby bylo možné přistoupit k nějaké selekci faset. V experimentu
vodovodní baterie byla skryta nejméně používaná faseta konstrukce. Obdobně
v experimentu sprchové kouty faseta materiál výplní a v experimentu umyvadla fasety dvojumyvadlo a odkládací prostor.
Ve všech měřených kategoriích bylo změněno pořadí faset tak, aby odpovídalo jejich změřené žádanosti. Ani jedna z kategorií přitom původně neměla
shodné řazení, přestože pořadí faset bylo při implementaci fasetové navigace
pečlivě uváženo a stanoveno po konzultaci s doménovým expertem.
Dále bylo na základě měření rozhodnuto, že se změní řazení fasetových
hodnot tak, aby se jako první řadily hodnoty nejčastěji klikané.
25
64
Vysvětlení pojmu konverze bylo uvedeno v sekci 2.2.
sprchové kouty
sprchové vaničky
sprchové boxy
umyvadla
zrcadla
osvětlení
návštěvníků
výběr hodnoty
zrušení hodnoty
zrušení všeho
událost řazení
stránkování
výběr produktu
konverze
událostí celkem
vodovodní baterie
Experiment
6.4. Uživatelské testování
632
1312
224
33
83
1407
594
11
3664
1132
1766
196
35
89
1125
1842
6
5059
666
721
66
18
56
459
1241
4
2565
373
244
41
12
57
349
522
1
1226
1075
1594
251
44
78
1539
1928
7
5441
124
71
4
1
13
182
185
0
456
96
49
3
4
2
68
98
2
226
Tabulka 6.2: Souhrn naměřených dat
6.4
Uživatelské testování
Uživatelské testování proběhlo po skončení experimentů uvedených v předchozím oddíle. Předmětem testování se staly kategorie zboží obsahující fasetovou
navigaci, přičemž zvláštní důraz byl kladen na tři výše zmíněné kategorie, ve
kterých bylo přistoupeno ke skrytí části faset. Modifikovaná podoba e-shopu
byla spuštěna na jiné adrese, mimo produkční verzi, ovšem veškeré ostatní
součásti kromě fasetové navigace zůstaly v nezměněné podobě. Test použitelnosti byl zaměřen výhradně na fasetovou navigaci a nezaměřoval se tedy
vůbec na specifika nákupu v elektronickém obchodě jako je vkládání zboží do
košíku nebo úspěšný průchod objednávkovým procesem.
Testování použitelnosti se zúčastnilo pět mužů a jedna žena, všichni ve
věku mezi 20 a 25 lety, studenti vysokých škol. Respondenti byli k testování
motivování finančně. Ani jeden respondent neměl předchozí zkušenost s nákupem zboží z oblasti koupelnového vybavení, které prodává testovaný obchod.
Proto bylo nejprve potřeba respondenty ústně seznámit s tematikou prezentace.
Před testováním byl sestaven seznam deseti úkolů, jež měli účastníci při
testování postupně splnit. Ke každému úkolu byl dále připraven motivační
scénář. Seznam úkolů uvádíme níže, motivační scénáře za účelem stručnosti
vynecháváme, jelikož jsou k textu této práce irelevantní. Naopak uvádíme
vnitřní motivaci, která vedla k formulaci každého jednotlivého úkolu.
Testování s jedním uživatelem trvalo 30 minut, probíhalo pouze za přítomnosti autora práce v tiché místnosti na dostatečně výkonném notebooku
65
6. Testování
s úhlopříčkou displeje 12 palců a rozlišením 1366 na 768 pixelů. K notebooku
byla připojena standardní myš. Za účelem pozdějšího vyhodnocení byl zaznamenáván zvuk a video zachycující dění na obrazovce. Tvář respondenta na
video zaznamenávána nebyla.
Výchozím bodem při zahájení testování byla titulní strana webového obchodu a během testování nebyli respondenti instruováni k žádnému konkrétnímu pohybu na stránkách, mezi jednotlivými úkoly tedy v rámci navigace
webu přecházeli samostatně. Při práci s webem nebyli ani omezeni na fasetovou navigaci, bylo jim řečeno, že mohou používat libovolných prvků v rámci
celé prezentace, nicméně zaměření jednotlivých úkolů bylo sestaveno tak, aby
cílilo na využití fasetové navigace.
Ani jeden z respondentů dříve neslyšel pojem fasetová navigace a proto
nebylo toto spojení v průběhu celého testování používáno, testující nechal
účastníky, aby označovali fasetovou navigaci vlastními výrazy. Nejčastější pojmenování bylo filtry a objevil se i pojem kategorie.
6.4.1
Úkoly pro testování použitelnosti
1. Nalezněte dvě čtvercové keramické sprchové vaničky do 4 000
Kč.
Motivace: nalezení příslušné kategorie respondentem, seznámení se s
principy práce s fasetovou navigací.
2. Zjistěte, kolik nabízí obchod České koupelny keramických rohových umyvadel.
Motivace: nalezení kategorie respondentem, seznámení se s prvkem oznamujícím počet položek zboží vyhovujících nastaveným kritériím, seznámení se s četnostmi jednotlivých fasetových hodnot uvedenými v závorkách.
3. Zjistěte, kolik stojí nejlevnější obdélníkový sprchový kout vybavený bezpečnostním sklem.
Motivace: použití skryté fasety materiál výplní.
4. Zjistěte, kolik víceprvkových dřezových baterií od firmy LaTorre obchod nabízí. A kolik umyvadlových?
Motivace: použití skryté fasety konstrukce, posléze nutnost zrušit jednu
z předchozích voleb pomocí křížku.
5. Vyberte si jakékoli třísegmentové posuvné dveře do sprchového
koutu.
Motivace: absence potřebné fasety pro rozlišení počtu segmentů. Cílem
bylo zjistit, jak bude respondent na absenci reagovat.
6. Najděte čtvrtkruhovou akrylátovou sprchovou vaničku Gomera
od firmy Teiko.
66
6.4. Uživatelské testování
Motivace: zjistit, zda je fasetová navigace pro respondenta natolik dobře
použitelná, že jí upřednostní před fulltextovým vyhledáváním.
7. Vyberte si podle vlastního výběru vaničku a sprchový kout,
nebo sprchový box s celkovou cenou max. 20 000 Kč.
Motivace: sledování přirozenější, samostatné práce respondenta s fasetami. Zjištění, zda pořadí faset odpovídá jeho spontánním potřebám.
8. Nalezněte umyvadlo s odkládacím prostorem do 3 000 Kč.
Motivace: Použití skryté fasety odkládací prostor.
9. Vyberte čtvrtkruhovou akrylátovou sprchovou vaničku buď od
firmy Roltechnik, nebo od firmy Polysan.
Motivace: zjistit, jak velký problém představuje absence vícenásobné
volby, viz sekce 1.1.4 (fasetová navigace v obchodu České vany umožňuje
v každé fasetě zvolit jen jednu hodnotu).
10. Vyberte keramický závěsný klozet od firmy Ideal Standard.
Motivace: zjištění chování a reakce respondenta při práci s kategorií,
která nedisponuje fasetovou navigací.
Obecně lze konstatovat, že jakmile se respondenti poprvé s fasetovou navigací na stránce setkali a seznámili se s principy jejího fungování, velmi rychle
si její používání osvojili. Dokázali pak bez problémů fasety identifikovat i v jiných kategoriích zboží a vnímali je odděleně od ostatní funkcionality. Dva
respondenti na konci testování uvedli, že se již s fasetovou navigací setkali,
pro ostatní byla funkcionalita zcela nová.
Na dotaz, co znamenají čísla v závorkách uvedená u fasetových hodnot,
všichni respondenti správně uvedli, že jde o počet vyhovujících položek zboží.
Tři účastníci testování se sami pozastavili nad způsobem řazení hodnot ve
fasetách. Jeden jej označil jako vysloveně problematický, druzí dva ho vnímali
jako nepřehledný, ale v případě testovaného množství fasetových hodnot za
snesitelný. Zbylí tři testeři se k pořadí nevyjádřili a na pozdější dotaz, jaké
řazení by očekávali, shodně prohlásili, že abecední.
Pěti respondentům nečinily skryté fasety žádné problémy a příslušný prvek
pro rozbalení dalších voleb použili zpravidla bezprostředně po zadání úkolu.
Jeden respondent skryté fasety nezaregistroval a měl problém úkol dokončit,
po téměř dvouminutovém zevrubném zkoumání ostatních faset nakonec na
možnost rozkliknout si skryté fasety přišel a úkol dokončil.
Na otázku, proč jsou fasety skryté, uvedli dva účastníci, že proto, aby
uživatele nerušily, a dva odpověděli, že je tomu kvůli jejich menší důležitosti.
Jeden respondent nevěděl proč, ale ocenil, že rozhraní je tak přehlednější,
a jeden respondent nepovažoval skrytí za opodstatněné a navrhl, aby bylo
uplatněno až při větším množství faset.
67
6. Testování
Na přímý dotaz, zda výška fasetové navigace nezabírá na stránce příliš
mnoho místa a zda neomezuje uživatele v prohlížení výsledného zboží, jeden respondent uvedl, že by uvítal, kdyby fasety bylo možné sbalit všechny,
nicméně že ve výchozím stavu při vstupu do dané kategorie by měly být fasety rozbaleny. Ostatní respondenti neměli s výškou žádné problémy a čile
používali kolečka myši k rychlému přeskočení faset, když činnost v rámci nich
dokončili.
Když byli respondenti vyzváni ke splnění úkolu, který se odehrával v kategorii, která nedisponovala fasetovou navigací, projevili zpravidla lítost nad
absencí „filtrů“. Dva respondenti doslova řekli, že by potřebovali mít možnost
výpis filtrovat jako v ostatních [fasetových] kategoriích.
Celé testování, zejména úkoly 4 a 9 prokázaly, že uživatelům nedělá problém zrušit vybranou hodnotu ve fasetě křížkem a vrátit se tak o jeden, či více
kritérií zpět. Nutno však dodat, že v horní části umístěny prvek zrušit všechny
volby opatřený stejným symbolem křížku, používali respondenti jen zřídka. Jeden respondent se jal postupně odstraňovat šest uplatněných kritérií a teprve
v polovině této činnosti zaregistroval uvedené resetovací tlačítko. Tato situace
vhodně demonstruje přístup k řešení úkolů, který byl během testování pozorován několikrát: uživatel většinou okamžitě volí první způsob řešení, který
ho napadne, a teprve pokud je tento způsob zdlouhavý nebo nevede rychle
k cíli z jiného důvodu, uživatel činnost přeruší a začne hledat jiné možnosti,
jak dosáhnout cíle.
V průběhu testování uživatelé často opustili výpis zboží s fasetovou navigací, aby se podívali na detail konkrétního zboží. Jako problematický se ukázal
pozdější návrat zpět. Pokud k němu uživatelé použili tlačítko zpět v prohlížeči, bylo vše v pořádku. Pokud se však vrátili pomocí menu, nebo ještě jinou cestou, získali fasetovou navigaci ve výchozí (vyresetované) podobě. Dva
respondenti uvedli, že je obtěžuje volit si kritéria znova. Tato závada v použitelnosti však nemá snadné řešení, protože je otázkou, zda by bylo vhodné,
aby si fasetová navigace pamatovala poslední konfiguraci nastavených kritérií
trvale, až do dalšího vstupu uživatele na stránku (např. pomocí cookie v prohlížeči). Není totiž zřejmé, zda by uživatel po (i pozdějším) návratu s jistotu
zaregistroval, že filtr je aktivní, a mylně se nedomníval, že je k dispozici pouze
menší množství produktů. Kvůli této záležitosti by bylo vhodné uskutečnit
další uživatelské testování a teprve pak přijmout nějaké opatření.
Tři účastníci na konci testování sami explicitně koncept fasetové navigace
pochválili a uvedli, že se jim funkcionalita líbí a považují ji za přínosnou.
6.4.2
Vyhodnocení
Testování použitelnosti přineslo tři zásadní poznatky: uživatelé neměli při
práci s fasetami žádný významný problém týkající se použitelnosti. S fasetami interagovali plynule, plně chápali sémantiku a princip fasetové navigace a na celý mechanismus si rychle zvykli. Tento závěr je konzistentní se
68
6.4. Uživatelské testování
studiemi [8], [15]. Dále lze konstatovat, že skrývání méně využívaných faset
nepředstavuje problém, pokud je prvek pro přístup k dalším volbám umístěn
v těsné blízkosti viditelných faset. Uživatelé skrývání vnímají jako přínosné
z hlediska přehlednosti celého rozhraní. Konečně třetí zásadní poznatek je, že
hodnoty v rámci faset nemá smysl řadit podle jejich změřené míry prokliku
(žádanosti). Takové uspořádání není pro uživatele dostatečně transparentní.
Nejlepším způsobem se jeví řazení podle abecedy.
Z testování dále vyplynula celá řada poznatků ohledně použitelnosti dalších
prvků webového obchodu, jako je stránka s výsledky fulltextového vyhledávání, struktura informací na stránce s detailem zboží, formulace názvů položek
v hlavním menu nebo přítomnost různých informačních a propagačních prvků.
Vzhledem k tomu, že se tyto poznatky netýkají tématu této práce, neuvádíme
je, nicméně budou postoupeny provozovateli obchodu.
69
Závěr
S ohledem na zadání práce se rešeršní část věnovala nejprve související literatuře, neboť žádný existující softwarový nástroj pro optimalizaci fasetové navigace se nepodařilo vypátrat. Ani v literatuře nebyly nalezeny žádné konkrétní
postupy pro stanovení optimálního výběru a pořadí faset, případně fasetových
hodnot. Dostupné publikované práce se tohoto tématu dotýkaly jen okrajově
a obsahovaly pouze vágní a obecná doporučení.
Dále bylo v rešeršní části zjištěno, že nástroje pro A/B a multivariantní
testování nejsou vhodné k měření a optimalizaci fasetové navigace z důvodu
samotného principu jejich fungování.
Rešerše tak otevřela prostor pro implementaci vlastního nástroje sloužícího
k měření využití faset a stanovení jejich optimálního pořadí a složení. Následně
byl analyzován a navržen software v podobě webové aplikace, který umožní
měřit využití faset a fasetových hodnot ze strany provozovatele libovolného
webu disponujícího fasetovou navigací.
Software byl naimplementován pomocí jazyka PHP s využitím aplikačního
rámce Zend a knihovny pro objektově-relační mapování Doctrine.
Implementovaný nástroj je připraven na integraci se stávajícím aplikačním vybavením provozovatele, neboť dle zadání funguje na principu webové
služby s architekturou REST. Díky tomuto rozhraní existují jen minimální
prerekvizity pro integraci na straně zájemce. Dále nástroj disponuje webovým
uživatelským rozhraním sloužícím k administraci, kontrole průběhu a následnému vyhodnocení experimentů provozovatelem.
Ve dvanáctidenním ověřovacím provozu byl implementovaný nástroj nasazen pro optimalizaci fasetové navigace v sedmi kategoriích zavedeného elektronického obchodu. Na základě výsledků měření byla struktura fasetové navigace
v rámci jednotlivých kategorií obchodu změněna a následně byla podrobena
detailnímu testování použitelnosti s šesti respondenty.
Závěry testování ukázaly, že optimalizovaná fasetová navigace nevykazuje
žádné zásadní chyby v použitelnosti. Uživatelé se v ní dobře orientovali, byli
schopni bez obtíží nalézt skryté fasety a zavedení skrytých faset hodnotili jako
71
Závěr
přínosné pro přehlednost ovládání. Zároveň však testování odhalilo, že řazení
hodnot v rámci faset podle jejich žádanosti není pro uživatele srozumitelné,
neboť očekávají abecední řazení.
Vzhledem k velkému množství dat, které bylo pomocí implementovaného
nástroje shromážděno, má smysl do budoucnosti uvažovat o rozšíření funkčnosti zejména o automatizovanou tvorbu pravděpodobnostních modelů, na
jejichž základě by aplikace mohla poskytnout predikci faset pro nově příchozí
uživatele. Otázkou však zůstává, zda by dynamická skladba faset nebyla na
úkor použitelnosti a zda by takové chování bylo pro uživatele transparentní
a srozumitelné. Odpověď by však mohlo dát uspořádání nového uživatelského
testování.
72
Literatura
(1) Arlow, J.; Neustadt, I.: UML2 a unifikovaný proces vývoje aplikací. Computer Press, první vydání, 2007, ISBN 978-80-251-1503-9.
(2) Barre, K. L.: Faceted navigation and browsing features in new OPACs:
robust support for scholarly information seeking? Knowledge Organization, ročník 34, č. 2, 2007: s. 78–90.
(3) Broder, A. Z.; Carmel, D.; Cutrell, E.; aj.: Workshop on Faceted Search.
2006, http://sites.google.com/site/facetedsearch/.
(4) Broughton, V.: Faceted classification as a basis for knowledge organization in a digital environment; the Bliss Bibliographic Classification as a
model for vocabulary management and the creation of multidimensional
knowledge structures. In The Seventh International ISKO Conference,
ISKO, 2002.
(5) Broughton, V.: The need for a faceted classification as the basis of all
methods of information retrieval. In Aslib proceedings, ročník 58, 2006,
s. 49–72.
(6) Dash, D.; Rao, J.; Megiddo, N.; aj.: Dynamic Faceted Search for
Discovery-driven Analysis. In Conference on Information and Knowledge
Management, ACM, 2008, str. 863.
(7) Denton, W.: How to Make a Faceted Classification and Put It On the
Web. 2003, http://www.miskatonic.org/library/facet-web-howto.
html.
(8) English, J.; Hearst, M.; Sinha, R.; aj.: Flexible Search and Navigation
using Faceted Metadata, 2002, unpublished manuscript.
(9) Evans, E.: Domain-Driven Design: Tackling Complexity in the Heart of
Software. Addison-Wesley Professional, 2003.
73
Literatura
(10) Fagan, J. C.: Usability Studies of Faceted Browsing: A Literature Review.
Information Technology and Libraries, 2010: s. 58–66.
(11) Fielding, R. T.: Architectural Styles and the Design of Network-based
Software Architectures. Disertační práce, University of California, 2000.
(12) Hearst, M.: Clustering versus Faceted Categories for Information Exploration. Communications of the ACM, ročník 49, 2006: s. 84–88.
(13) Hearst, M.: Design Recommendations for Hierarchical Faceted Search
Interfaces. In ACM SIGIR Workshop on Faceted Search, ACM, 2006.
(14) Hearst, M.: UIs for Faceted Navigation: Recent Advances and Remaining Open Problems. In Workshop on Human-Computer Interaction and
Information Retrieval, HCIR, 2008.
(15) Hearst, M.; Li, K.; Swearingen, K.; aj.: Faceted Metadata for Image
Search and Browsing. In CHI, 2003, s. 76–83.
(16) Kamfonas, M. J.: Recursive Hierarchies: The Relational Taboo! The Relational Journal, 1992, http://www.kamfonas.com/id3.html.
(17) Krawczyk, H.; Bellare, M.; Canetti, R.: HMAC: KeyedHashing for Message Authentication. RFC 2104 (Informational), Únor 1997, updated by RFC 6151. Dostupné z WWW:
<http://www.ietf.org/rfc/rfc2104.txt>
(18) Kristol, D.; Montulli, L.: HTTP State Management Mechanism. RFC
2965 (Historic), Říjen 2000, obsoleted by RFC 6265. Dostupné z WWW:
<http://www.ietf.org/rfc/rfc2965.txt>
(19) Kwasnik, B.: The Role of Classification in Knowledge Representation
and Discovery. Library Trends, ročník 48, 1999: s. 22–47.
(20) Leach, P.; Mealling, M.; Salz, R.: A Universally Unique IDentifier (UUID)
URN Namespace. RFC 4122 (Proposed Standard), Červenec 2005. Dostupné z WWW: <http://www.ietf.org/rfc/rfc4122.txt>
(21) Liberman, S.; Lempel, R.: Approximately Optimal Facet Selection, 2009,
unpublished.
(22) Massé, M.: REST API Design Rulebook. O’Reilly Media, 2012, ISBN
978-1-449-31050-9.
(23) Nielsen, J.; Mack, R. L. (editoři): Usability Inspection Methods. John
Wiley & Sons, New York, NY, 1994, ISBN 0-471-01877-5.
74
Literatura
(24) Padilla, M.: User Interface Implementations of Faceted Browsing.
2008,
http://www.digital-web.com/articles/user_interface_
implementations_of_faceted_browsing/.
(25) Reese,
G.:
Principles
for
Standardized
REST
Authentication.
2009,
http://broadcast.oreilly.com/2009/12/
principles-for-standardized-rest-authentication.html.
(26) Richardson, L.; Ruby, S.: RESTful Web Services. O’Reilly Media, 2007,
ISBN 978-0-596-52926-0.
(27) Sobotka, P.: Privátní znalostní systém. Bakalářská práce, České vysoké
učení technické v Praze, Fakulta elektrotechnická, 2009, vedoucí bakalářské práce Mgr. Petr Matyáš.
(28) Spiteri, L.: A Simplified Model for Facet Analysis. Canadian Journal of
Information and Library Science, ročník 23, 1998: s. 1–30.
(29) Tichý, J.: Programová podpora tvorby webových aplikací. Diplomová
práce, Vysoká škola ekonomická, 2004.
(30) Tichý, J.: Model není pouze databáze. 2007, http://www.phpguru.cz/
clanky/model-neni-pouze-databaze.
(31) Walker, M.; Takayama, L.; Landay, J. A.: High-fidelity or Low-fidelity,
Paper or Computer? Choosing Attributes when testing web prototypes.
2002.
(32) Wynar, B. S.; Taylor, A. G.: Introduction to cataloging and classification.
Libraries Unlimited, 8 vydání, 1992, ISBN 9780872879676.
75
Příloha
Seznam použitých zkratek
AJAX Asynchronous JavaScript and XML
APC Alternative PHP Cache
API Application Programming Interface
CIM Computer-Independent Model
CRUD Create–Retrieve–Update–Delete
DQL Doctrine Query Language
GUI Graphic User Interface
HMAC Hash Message Authentication Code
HTTP Hypertext Transfer Protocol
MVT Multivariate Testing
ORM Object-Relational Mapping
PIM Platform-Independent Model
REST REpresentational State Transfer
SOAP Simple Object Access Protocol
SSL Secure Sockets Layer
SQL Structured Query Language
TDD Test-Driven Development
TLS Transport Layer Security
UI User Interface
77
A
A. Seznam použitých zkratek
URI Uniform Resource Identifier
URL Uniform Resource Locator
UUID Universally Unique IDentifier
78
Příloha
UML
User
- name
- email
- password
1
*
Role
- name
1..n
*
Experiment
- name
- description
- url
*
1..n
Client
- key
- sharedSecret
1
*
Facet
- name
Visitor
- IPv4
- userAgent
1
*
FacetValue
- name
1
*
Event
1
*
- time
Obrázek B.1: Diagram analytických tříd.
79
B
B. UML
Případ užití: Authenticate (Autentizovat)
ID: 1
Stručný popis:
Uživatel se přihlásí pomocí jména a hesla.
Hlavní aktér:
uživatel
Vedlejší aktéři:
žádní
Vstupní podmínky:
žádné
Hlavní scénář:
1. Uživatel zadá jméno a heslo.
2. Když v systému existuje účet se stejným jménem a heslem:
2.1 Systém uživatele přihlásí.
3. Když v systému neexistuje účet se stejným jménem nebo zadané
heslo není správné:
3.1 Systém zobrazí chybovou hlášku a vyzve uživatele k opakování zadání přihlašovacích údajů.
Výstupní podmínky:
Identita je ověřena a uživatel je přihlášen.
Alternativní scénáře:
žádné
Tabulka B.1: Specifikace případu užití Autentizovat
80
Případ užití: CreateNewExperiment (VytvořitNovýExperiment)
ID: 2
Stručný popis:
Uživatel založí v systému nový experiment.
Hlavní aktér:
uživatel
Vedlejší aktéři:
žádní
Vstupní podmínky:
Uživatel je přihlášen.
Hlavní scénář:
1. Uživatel zadá jméno, popis a URL nového experimentu.
2. Uživatel vybere jiné uživatele, kteří budou mít do experimetu přístup, a určí jejich role.
3. Když je vyplněn alespoň název a URL experimentu:
3.1 Systém vytvoří nový experiment.
4. Jinak:
4.1 Systém zobrazí chybovou hlášku a vyzve uživatele k doplnění
chybějících údajů.
Výstupní podmínky:
Experiment je vytvořen.
Alternativní scénáře:
žádné
Tabulka B.2: Specifikace případu užití VytvořitNovýExperiment
81
B. UML
Případ užití:
mentu)
ViewExperimentStats
(ProhlédnoutStatistikyExperi-
ID: 3
Stručný popis:
Uživatel prochází veškeré statistiky k experimentu.
Hlavní aktér:
uživatel
Vedlejší aktéři:
žádní
Vstupní podmínky:
Uživatel je přihlášen.
Hlavní scénář:
1. Uživatel vybere ze seznamu dostupných experimentů jeden konkrétní.
2. Systém mu umožní procházet veškeré naměřená i vypočítané údaje
o daném experimentu.
Výstupní podmínky:
žádné
Alternativní scénáře:
žádné
Tabulka B.3: Specifikace případu užití ProhlédnoutStatistikyExperimentu
82
Případ užití: ChangePassword (ZměnitHeslo)
ID: 4
Stručný popis:
Uživatel si změní heslo.
Hlavní aktér:
uživatel
Vedlejší aktéři:
žádní
Vstupní podmínky:
Uživatel je přihlášen.
Hlavní scénář:
1. Uživatel zadá do jednoho pole svoje současné heslo a do dvou polí
požadované nové heslo.
2. Když systém vyhodnotí zadané současné heslo jako správné:
2.1 Systém změní uživateli heslo na nově požadované.
3. Jinak:
3.1 Systém zobrazí chybovou hlášku a vyzve uživatele k opakování celého scénáře.
Výstupní podmínky:
Uživatel má změněné heslo.
Alternativní scénáře:
žádné
Poznámky:
Všechna pole zobrazují místo zadaných znaků hvězdičky (nebo tečky).
Tabulka B.4: Specifikace případu užití ZměnitHeslo
83
B. UML
Případ užití: ChangeUsersRole (ZměnitRoliUživatele)
ID: 5
Stručný popis:
Uživatel změní roli jiného uživatele pro určitý experiment.
Hlavní aktér:
uživatel
Vedlejší aktéři:
žádní
Vstupní podmínky:
Uživatel je přihlášen a jeho role pro daný experiment je Vlastník.
Hlavní scénář:
1. Uživatel vybere jiného uživatele, jehož roli chce změnit.
2. Uživatel vybere ze seznamu novou uživatelskou roli, kterou chce
dotyčnému přiřadit.
3. Systém dotyčnému uživateli přiřadí novou roli.
Výstupní podmínky:
Role vybraného uživatele je změněna.
Alternativní scénáře:
žádné
Tabulka B.5: Specifikace případu užití ZměnitRoliUživatele
84
Případ užití: PauseExperiment (PozastavitExperiment)
ID: 6
Stručný popis:
Uživatel změní stav experimentu na pozastaven.
Hlavní aktér:
uživatel
Vedlejší aktéři:
žádní
Vstupní podmínky:
Uživatel je přihlášen a jeho role pro daný experiment je Vlastník.
Hlavní scénář:
1. Uživatel iniciuje pozastavení experimentu.
2. Systém zobrazí varovnou hlášku s žádostí o potvrzení.
3. Když uživatel hlášku potvrdí:
3.1 Systém experiment pozastaví.
Výstupní podmínky:
Stav vybraného experimentu je pozastaven.
Alternativní scénáře:
žádné
Tabulka B.6: Specifikace případu užití PozastavitExperiment
85
B. UML
Případ užití: RegisterNewVisitor (ZaznamenatNovéhoNávštěvníka)
ID: 7
Stručný popis:
Klient pošle do systému údaje o novém návštěvníkovi. Systém vytvoří
vnitřní reprezentaci tohoto návštěvníka a vrátí jeho jednoznačný identifikátor.
Hlavní aktér:
klient API
Vedlejší aktéři:
žádní
Vstupní podmínky:
Klient je autentizován.
Hlavní scénář:
1. Klient odešle údaje o novém návštěvníkovi.
2. Systém založí vnitřní reprezentaci návštěvníka a vrátí klientovi
identifikátor nového návštěvníka.
Výstupní podmínky:
Návštěvník je zaevidován.
Alternativní scénáře:
žádné
Tabulka B.7: Specifikace případu užití ZaznamenatNovéhoNávštěvníka
86
Případ užití: AccessVisitorSettings (ZískatNastaveníNávštěvníka)
ID: 8
Stručný popis:
Klient získá nastavení specifické pro jednoznačně identifikovaného návštěvníka.
Hlavní aktér:
klient API
Vedlejší aktéři:
žádní
Vstupní podmínky:
Klient je autentizován.
Hlavní scénář:
1. Klient odešle identifikátor návštěvníka a identifikátor experimentu.
2. Když v systému neexistuje návštěvník s daným identifikátorem:
2.1 Systém odešle klientovi chybovou hlášku.
3. Když v systému existuje návštěvník s daným identifikátorem:
3.1 Když v systému existuje specifické nastavení návštěvníka pro
daný experiment:
3.1.1 Systém odešle klientovi informace o specifickém nastavení.
3.2 Jinak:
3.2.1 Systém vygeneruje výchozí nastavení návštěvníka a odešle jej klientovi.
Výstupní podmínky:
žádné
Alternativní scénáře:
žádné
Tabulka B.8: Specifikace případu užití ZískatNastaveníNávštěvníka
87
B. UML
Případ užití: RegisterVisitorBehaviour (ZaznamenatChováníNávštěvníka)
ID: 9
Stručný popis:
Klient pošle údaj o chování návštěvníka a systém je zaznamená.
Hlavní aktér:
klient API
Vedlejší aktéři:
žádní
Vstupní podmínky:
Klient je autentizován.
Hlavní scénář:
1. Klient odešle identifikátor návštěvníka, identifikátor experimentu,
typ události a případně další doplňující údaje.
2. Když v systému neexistuje návštěvník nebo experiment s uvedenými identifikátory:
2.1 Systém odešle klientovi chybovou hlášku.
3. Jinak:
3.1 Systém založí záznam o chování návštěvníka.
Výstupní podmínky:
žádné
Alternativní scénáře:
žádné
Tabulka B.9: Specifikace případu užití ZaznamenatChováníNávštěvníka
88
Obrázek B.2: Celkový diagram návrhových tříd.
89
Client
- ID: hash
- name: String
- secret: String
User
- ID: int
- name: String
- email: String
- password: String
- salt: String
1
1
ClientBinding
1
Role
- name
*
EventType
- ID: int
- name: String
*
*
UserBinding
1
*
*
*
1
Event
- ID: int
- timestamp: int
* - resultSetSize: int
1
*
Experiment
- ID: int
1 - name: String
- description: String
- URL: String
+ getFacets(): Collection
+ getEvents(): Collection
1
*
*
1
1
*
* 1
*
1
Visitor
- ID: UUID
- IPv4: String
- userAgent: String
FacetPosition
- position
*
*
0..1
0..1
FormerChoice
- ID: int
*
1
*
FacetValue
- ID: int
- externID: int
- name: String
- left: int
- right: int
- rootId: int
1
Facet
- ID: int
- externID: int
- name: String
- static: boolean
+ getFacetValues()
*
1
B. UML
«interface»
Service_FacetOptimizer
+ postNewExperiment()
+ postNewFacet()
+ postNewFacetValue()
+ postNewVisitor()
+ postNewEvent()
+ getFacetOrder()
Service_FacetOptimizer_Rest
- hostUrl: const String
- apiUrl: const Sting
- apiKey: const String
- sharedSecret: const String
- client: Zend_Rest_Client
+ getStartTime()
+ getTotalTime(secs: int, milis: int)
+ postNewExperiment(name: String, desc: String, url: String)
+ postNewFacet(experimentId: int, facetId: int, facetName: String)
+ postNewFacetValue(facetId: int, facetValueId: int,
facetValueName: String)
+ postNewVisitor(ipv4: String, userAgent: String)
+ postNewEvent(experimentId: int, visitorId: int, eventType: String,
timestamp: int, resultSetSize: int, facetChoices: array)
+ getFacetOrder(visitorId: int, experimentId: int)
Obrázek B.3: Třída pro realizaci REST API klienta.
90
Příloha
REST API
HTTP Metoda
Zdroj
GET
POST
PUT
DELETE
experiment
x
x
x
x
facet
x
x
x
x
facet-value
x
x
x
x
visitor
x
x
facet-position
x
event
x
x
Tabulka C.1: Podporované HTTP metody pro jednotlivé zdroje REST API
91
C
C. REST API
/api/event
Metoda
OK HTTP kód
Accept
povinné parametry
GET
200
id
POST
201
application/xml
application/json
(XML data)
PUT
–
–
–
DELETE
–
–
–
Tabulka C.2: Specifikace REST zdroje Event
/api/experiment
Metoda
OK HTTP kód
GET
200
POST
201
PUT
200
DELETE
204
Accept
povinné parametry
id
application/xml
application/json
(XML data)
(XML data)
id
Tabulka C.3: Specifikace REST zdroje Experiment
/api/facet
Metoda
OK HTTP kód
GET
200
POST
201
PUT
200
DELETE
204
Accept
povinné parametry
id
application/xml
application/json
(XML data)
(XML data)
Tabulka C.4: Specifikace REST zdroje Facet
92
id
/api/facet-position
Metoda
OK HTTP kód
GET
200
Accept
application/xml
application/json
povinné parametry
experimentId
visitorId
POST
–
–
–
PUT
–
–
–
DELETE
–
–
–
Tabulka C.5: Specifikace REST zdroje FacetPosition
/api/facet-value
Metoda
OK HTTP kód
GET
200
POST
201
PUT
200
DELETE
204
Accept
povinné parametry
id
application/xml
application/json
(XML data)
(XML data)
id
Tabulka C.6: Specifikace REST zdroje FacetValue
/api/visitor
Metoda
OK HTTP kód
Accept
povinné parametry
GET
200
id
POST
201
application/xml
application/json
(XML data)
PUT
–
–
–
DELETE
–
–
–
Tabulka C.7: Specifikace REST zdroje Visitor
93
C. REST API
Client
REST API
POST /api/experiment
201 Location /api/experiment/«ID»
loop
[for each facet]
POST /api/facet
loop
[for each facet value]
POST /api/facet-value
Obrázek C.1: Vytvoření nového experimentu pomocí REST API.
Client
REST API
PUT /api/experiment/«ID»
DELETE /api/experiment/«ID»
Obrázek C.2: Úprava nebo smazání experimentu pomocí REST API.
94
Příloha
Ukázky UI
95
D
D. Ukázky UI
Obrázek D.1: Lo-fi prototyp založení nového experimentu.
96
Obrázek D.2: Lo-fi prototyp detailu běžícího experimentu.
97
D. Ukázky UI
Obrázek D.3: Lo-fi prototyp nastavení API klíčů pro experiment.
98
Obrázek D.4: Lo-fi prototyp rozhraní pro změnu hesla.
Obrázek D.5: Fasetová navigace v kategorii sprchové kouty v obchodě České
koupelny.
99
D. Ukázky UI
Obrázek D.6: Fasetová navigace v kategorii sprchové vaničky v obchodě České
koupelny.
Obrázek D.7: Fasetová navigace v kategorii umyvadla v obchodě České koupelny.
100
Obrázek D.8: Fasetová navigace v kategorii vodovodní baterie v obchodě České
koupelny.
Obrázek D.9: Počet kliknutí na fasety v kategorii vodovodní baterie.
Obrázek D.10: Počet kliknutí na fasety v kategorii sprchové kouty.
101
D. Ukázky UI
Obrázek D.11: Počet kliknutí na fasety v kategorii sprchové vaničky.
Obrázek D.12: Počet kliknutí na fasety v kategorii sprchové boxy.
Obrázek D.13: Počet kliknutí na fasety v kategorii umyvadla.
Obrázek D.14: Počet kliknutí na fasety v kategorii zrcadla.
Obrázek D.15: Počet kliknutí na fasety v kategorii osvětlení.
102
Příloha
Obsah přiloženého CD
Aktuální verze implementované aplikace je kromě přiloženého CD volně k
dispozici také online jako GIT repozitář na adrese https://github.com/
petrsobotka/facetoptimizer
readme.txt...................................stručný popis obsahu CD
src
project................................zdrojové kódy implementace
application......................................jádro aplikace
library..........................použité knihovny a frameworky
public...........................document root webové aplikace
index.php
temp ....................... místo pro kompilované šablony a logy
tests.................................................unit testy
client ......................... vzorová implementace REST klienta
thesis ...................... zdrojová forma práce ve formátu LATEX
text
thesis.pdf ............................. text práce ve formátu PDF
103
E
Download

Nástroj pro optimalizaci fasetové navigace