1 2 3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Webový dotazníkový systém Jan Búda Vedoucí práce...
České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářská práce
Webový dotazníkový systém Jan Búda
Vedoucí práce: Ing. Jiří Matějka
Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 10. července 2009
Poděkování Děkuji vedoucímu mé práce, panu Ing. Jiřímu Matějkovi, a panu Ivanu Brhlíkovi za jejich ochotu a mnoho rad týkajících se zejména správného sestavování a funkčnosti dotazníků v sociologických průzkumech a obecných zásad správného vedení a zpracovávání sociologických průzkumů.
iii
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 dodržování etických principů při přípravě vysokoškolských závěrečných prací. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Abstract This bachelor thesis discusses design of a web application offering a user friendly sociological questionnaires design and administration. It firstly discuss general requirements for sociological surveys, existing market solutions and known requirements of the application. Subsequently there is a detailed description of the produced application, including complete documentation and user guide.
Abstrakt Tato bakalářská práce se zabývá návrhem webové aplikace, umožňující uživatelsky přívětivý návrh a správu sociologických dotazníků. Práce nejprve pojednává o obecných požadavcích na sociologické průzkumy, existujících řešeních na trhu a předem specifikovaných požadavcích aplikace. Dále je uveden podrobný popis vytvořené aplikace, včetně kompletní dokumentace a uživatelské příručky.
Menu . . . . . . . . . . . Přehled dotazníků . . . . Editace dotazníku . . . . Editace parametrů otázky Editace obsahu otázky . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
82 82 83 84 85
KAPITOLA 1. ÚVOD
Kapitola 1
Úvod Aplikaci, jejímž popisem se budu zabývat, jsem nazval Webový dotazníkový systém. Tento název, ač mírně krkolomný, považuji za nejvýstižnější. Systém by se, tak jako podobné, již existující aplikace, mohl nazývat Anketní systém. Nicméně dotazník v sociologickém smyslu slova zahrnuje mnohem komplexnější a sofistikovanější produkt, než jaký si představíme pod pojmem anketa.
1.1
Motivace
Při rozmýšlení tématu mé bakalářské práce jsem se rozhodl pro práci implementační viz [1]. Chtěl jsem vytvořit aplikaci, která by měla reálný užitek. Několikrát jsem se na internetu setkal s prosbami od studentů či studentek nejen sociologických oborů o vyplnění nějakého dotazníku či ankety. Typické pro tyto prosby přitom vždy byla velmi špatná technická, popř. i grafická úroveň dotazníků. Je pochopitelné, že student humanitních oborů nemá dostatečné technické znalosti pro tvorbu vlastního, byť jednoduchého, internetového dotazníku. Je tedy nucen použít existující nástroje pro tvorbu dotazníků, které však ve většině případů neobsahují, alespoň v neplacené verzi, dostatečnou funkcionalitu a flexibilitu a v České Republice je jejich nabídka velmi omezená. Následným průzkumem trhu jsem zjistil, že o podobný systém je zájem i ve firemní sféře. Mnoho společností, zabývajících se sociologickými průzkumy, podobný systém nemá vůbec nebo má jen desktopovou ( offline ) verzi apod. Zejména z důvodu poskytnutí potřebného know-how a požadavků na plně využitelný systém tvorby dotazníků jsem se rozhodl pro spolupráci se společností STEM/MARK. Mým úkolem bylo vytvořit uživatelsky přívětivou aplikaci, schopnou reálného nasazení a vyznačující se jednoduchostí při zachování funkčnosti.
1.2
Terminologie
V práci je použito mnoho pojmů, které jsou pro větší přehlednost definovány v příloze A.
1
1.2. TERMINOLOGIE
2
KAPITOLA 2. POPIS PROBLÉMU, POŽADAVKY NA ŘEŠENÍ
Kapitola 2
Popis řešeného problému, specifikace požadavků, existující řešení 2.1
Rozsah práce
Při sestavování požadavků na aplikaci se ukázalo, že množství využitelných funkcionalit aplikace je příliš velké. Rozsah práce by překročil doporučenou dobu cca 200 hodin (dle ECTS (viz [2]) odpovídá 1 kredit 25 - 30 hodinám práce, bakalářská práce studijního programu Elektrotechnika a informatika, strukturovaný, Bakalářský je hodnocena 7 kredity) Vyvíjená aplikace proto obsahuje především základní funkcionality, potřebné pro tvorbu dotazníků. Je navržená tak, aby byla relativně snadno rozšiřitelná např. o nové typy otázek. Rozsah by bylo možné téměř libovolně zvětšovat a s určitým rozšiřováním se do budoucna počítá.
2.2
Obecný popis problému
Základní ideou je umožnit uživateli neznalému webových technologií jednoduše sestavit a spravovat vlastní dotazník. Aplikace by měla být co nejvíce intuitivní. Pokud uživatel nerozumí některým jejím volbám a je nucen pátrat v nápovědě, je to špatně. Uživatelem se v našem případě rozumí člověk s jistými minimálními znalostmi či zkušenostmi týkajícími se sociologických průzkumů. Můžeme tedy předpokládat, že typický uživatel bude rozumět pojmům jako Rotace, Multiple-choice, Polootevřená otázka či Respondent (výklad některých pojmů viz příloha A).
2.3
Specifikace požadavků
Některé následující požadavky mají poznámku o prioritě. Jedná se o požadavky na funkcionality, které není nezbytně nutné implementovat a nemají většinou vliv na základní použitelnost aplikace, ale jejich použití usnadňuje komfort vytváření dotazníku, přidávají více možností formátování apod. Požadavek může mít prioritu 2 nebo 3 (není-li priorita uvedena, předpokládá se priorita 1)
3
2.3. SPECIFIKACE POŽADAVKŮ
priorita 1 - funkcionalita by v aplikaci neměla chybět. priorita 2 - Méně důležitá funkcionalita, bez které aplikace bude použitelná. Její implementování by ale přineslo určité výhody. priorita 3 - Nejméně důležitá položka. K implementaci se přistoupí pouze pokud budou implementovány všechny položky s vyšší prioritou. Specifikaci požadavků pro přehlednost rozdělíme do několika sekcí: Obecné požadavky na systém Požadavky na tvorbu dotazníků Specifikace jednotlivých typů otázek 2.3.1 Obecné požadavky K základním požadavkům na výsledný systém patří: Klientské účty - Aplikace by měla umožňovat tvorbu a správu více klientských účtů. V rámci každého účtu bude možné vytvářet a spravovat vlastní dotazníky. Základní atributy, nastavitelné pro každého klienta jsou: email login heslo Jméno a příjmení adresa telefon firma
Administrátorský účet - Administrátor může přidávat či blokovat klientské účty a má, pro snadnou možnost technické podpory, plný přístup ke všem těmto účtům. Účet respondentapriorita 3 - Stálí respodenti mohou mít jednotné přihlašovací heslo ke všem dotazníkům. Mohlo by tedy být možné vytvořit respondentovi účet s přehledem jím vyplněných dotazníků, náhledem do výsledků průzkumů jichž se zúčastnil apod. Logování přístupu - Aplikace bude ukládat informace o všech přihlášeních do systému. Zveřejnění dotazníku - Vytvořený dotazník je možné jednoduše rozšířit mezi respondenty. Zamezení opakovanému vyplnění - Jeden respondent smí každý dotazník vyplnit maximálně jednou. Zobrazení výsledků - Aplikace by měla umožňovat jednoduchý export získaných dat. Především by ale mělo být možné prohlédnout si výsledky průzkumu přímo v aplikaci.
4
KAPITOLA 2. POPIS PROBLÉMU, POŽADAVKY NA ŘEŠENÍ
2.3.2 Požadavky na dotazník Při samotné tvorbě dotazníku by aplikace měla mít následující možnosti: Typy otázek - Do dotazníku je možné přidat následující typy otázek: (jejich podrobnější popis viz 2.3.3 ) -
Multiple-choice ( žádná až všechny odpovědi) Single-choice (právě jedna odpověď) Scale (škála odpovědí, např. od 0 do 10) Otevřená otázka (vlastními slovy)
Všechny otázky mohou být buď uzavřené nebo polootevřené.
Sloupce - Možnost umístit jednotlivé odpovědi na otázku do sloupců. Například v případě otázky typu Multiple-choice, která bude obsahovat 30 možností (odpovědí) bude možné jednotlivé odpovědi vypsat vedle sebe do několika sloupců. Editace otázek - Do každého dotazníku je možné dynamicky přidávat libovolné množství otázek, případně otázky kdykoli odstranit či editovat. Pozice otázek - Lze posunovat otázku na předchozí či následující pozice v dotazníku. Pozice odpovědí priorita při editaci otázky.
3
- Možnost měnit pořadí jednotlivých odpovědí na otázku
Umístění otázek priorita 2 - Je možné umístit 2 otázky vedle sebe. Každá otázka tedy může být umístěna pod předchozí nebo vedle předchozí otázky. Povinnost otázek - Otázku je možné označit za povinnou. V takovém případě respondent nemůže přistoupit k další části dotazníku, dokud na otázku neodpoví. Rotace odpovědí - Jednotlivé odpovědi na otázku se v každém rozhovoru (viz příloha A.2) vypisují v náhodném pořadí. Rotace otázek priorita ném pořadí.
2
- Zvolené otázky se v každém rozhovoru vypisují v náhod-
Podmínky - Je možné definovat sadu podmínek pro zobrazení otázky. Podmínky je možné vzájemně řetězit logickými spojkami AND a OR. Příklad podmínky: Je-li odpověď na otázku číslo 3 „ano“ a odpověď na otázku 4 není „42“, skryj tuto otázku. Intro, Outro - Možnost připojit před dotazník úvodní text ( Intro ) a na konec dotazníku závěrečný text ( Outro ) (např. poděkování za čas strávený vyplňováním dotazníku). Progress bar - Při vyplňování dotazníku se respondentovi bude zobrazovat „progress bar“, znázorňující, kolik procent dotazníku již vyplnil. HTML v otázce - Text otázky je možné upravit pomocí HTML kódu a např. tak vložit do nadpisu otázky obrázek. Obrázkypriorita 2 - Možnost nahrát k otázce jeden či více obrázků, změnit jejich velikost, nastavit jejich umístění. Logo v záhlavípriorita velikost.
2
- Lze nahrát do záhlaví dotazníku vlastní logo, změnit jeho
5
2.4. EXISTUJÍCÍ ŘEŠENÍ
Formátovánípriorita 2 - Nastavení velikosti písma a typu písma jednotlivě pro intro, outro, text otázky, upřesnění otázky, text odpovědí Barvypriorita 2 - Nastavení barvy pozadí celého dotazníku, názvu dotazníku, intra, outra, jednotlivých otázek. Multimédiapriorita 3 - Možnost jednoduše (ne psaním HTML kódu do textu otázky) vložit do otázky audio či video. Možnost kontroly, zda respondent audio/video nepřeskočil. Například aplikace neumožní odpovědět na další otázku, dokud video neskončí. 2.3.3 Specifikace typů otázek 2.3.3.1
Multiple-choice
Respondent může zvolit žádnou až všechny možnosti odpovědí. Bude realizováno HTML elementem Check box. 2.3.3.2
Single-choice
Respondent může zvolit maximálně jednu odpověď. V základním provedení bude realizováno HTML elementem Radio button. Později(priorita 2 ) je možné doimplementovat realizaci pomocí rozbalovacího seznamu. To může být vhodné v případě velkého množství možností. Navíc by pak, díky úspoře místa, bylo možné umístit do jedné otázky více rozbalovacích seznamů a jedna otázka by se tak mohla skládat z více „podotázek“ typu Single-choice. Pozn.: V aplikaci bude tento typ otázky nazván Právě jedna odpověď. Termín Single-choice se, na rozdíl od Multiple-choice, obvykle nepoužívá. Termín Právě jedna odpověď je pak mírně zavádějící (v případě nepovinné otázky respondent volí maximálně jednu odpověď), nicméně běžně používaný.
2.3.3.3
Scale
Též stupnice, škála. Respondent vybírá odpovědi na stupnici od X do Y (například 010, nejhorší-nejlepší, vždy-nikdy apod. Při zobrazování respondentovi se budou vypisovat pouze krajní intervaly, není nutné vypisovat hodnotu (název) každého stupně. Může být realizováno pomocí HTML elementů Radio button. Preferovaná je ale realizace pomoci posuvníku (Scroll bar). 2.3.3.4
Otevřená otázka
Respondent zadává vlastní, otevřenou odpověď do HTML elementu TextArea. Jedna Otevřená otázka smí obsahovat více otevřených odpovědí, tedy více elementů TextArea.
2.4
Existující řešení
V této podkapitole se zaměřím na popis již existujících řešení na trhu.
6
KAPITOLA 2. POPIS PROBLÉMU, POŽADAVKY NA ŘEŠENÍ
2.4.1 Řešení ve světě Ve světě existuje mnoho podobných řešení. Lze nalézt i propracované aplikace, nabízející mnoho možností a velkou svobodu při tvorbě dotazníku. Jejich základní společnou vlastností je ovšem ve většině případů zpoplatnění. Nenašel jsem žádnou webovou aplikaci, která by umožňovala tvorbu složitějších dotazníků zdarma. Mezi nejznámější anglické stránky umožňující návrh a správu dotazníků patří http://www.esurveyspro.com/ (obr. 2.1 ) nebo http://www.questionpro.com/ (obr. 2.2 )
Obrázek 2.1: eSurveys Pro - survey services
Obrázek 2.2: QuestionPro - online research Největší nevýhodou je, kromě ceny, která je kupodivu někdy nižší než u českých ekvivalentů, jazyk - typicky angličtina. Jednak musí umět anglicky tvůrce dotazníku, aby byl vůbec schopen se v aplikaci orientovat a dotazník vytvořit, a jednak často i respondent. V aplikaci zůstávají anglicky psané názvy ovládacích prvků, instrukce pro vyplňování apod. Některé aplikace mají problém s korektním zobrazením českých znaků. Respondent neovlá-
7
2.4. EXISTUJÍCÍ ŘEŠENÍ
dající angličtinu tak pravděpodobně bude mít problémy dotazník vyplnit, případně bude angličtinou odrazen. Nepodařilo se mi získat informace o jazykových znalostech obyvatel ČR (Český Statistický Úřad tyto údaje neposkytuje zdarma), nicméně lze provést přibližný odhad: Dle dat Českého statistického úřadu [3] mělo v roce 2007 cca 72% obyvatelstva středoškolské vzdělání a 18% pouze základní vzdělání. Dle Statistického zpravodaje [4] téhož úřadu se cizí jazyk učí přibližně 73% studentů základních škol a 79% studentů středních škol. Maximálně 80% z nich se učí angličtinu (platí pro SOŠ, např. na SOU je to pouze 44%). Jednoduchým výpočtem dojdeme k závěru, že maximálně 56% obyvatelstva bez vysokoškolského vzdělání (přičemž tato skupina bývá nejčastějším cílem komerčních průzkumů) se učilo anglicky. Dále bychom mohli s úspěchem polemizovat o úrovni angličtiny na středních a základních školách. Pro vyvození závěru ale myslím tato čísla postačí. Anglické dotazníky by odradily mnoho potenciálních respondentů a proto jsou pro Českou Republiku v praxi nepoužitelné. Nebudu se jimi dále zabývat. 2.4.2 České aplikace 2.4.2.1
Ankety
Pro úplnost zde zmíním i jednoduché ankety, s nimiž se lze na českém internetu často setkat, a které mnoho serverů poskytuje zdarma (obr. 2.3). Je možné nalézt i stránky pro tvorbu složitějších anket, obsahujících více otázek. Otázky jsou však v takovém případě pouze typu Single-choice a neumožňují žádné složitější konstrukce ani definování složitější vnitřní logiky dotazníku (např. podmínky). Pro komplexnější průzkumy jsou tedy nepoužitelné.
Obrázek 2.3: primitivní anketa ze serveru http://blueboard.cz
2.4.2.2
Existující řešení zdarma
V této podkapitole jsou uvedena řešení, která jsou, alespoň v základní verzi, zdarma a jsou lokalizovaná do češtiny. V tomto segmentu je český trh obecně poměrně chudý. Pokud vynecháme stránky nabízející ankety, zmíněné v podkapitole 2.4.2.1, nalezneme jen několik málo existujících řešení. Naproti tomu lze nalézt větší množství společností, které nabízejí vytvoření dotazníků a provedení celých průzkumů na míru. Dá se tedy předpokládat, že tyto společnosti mají
8
KAPITOLA 2. POPIS PROBLÉMU, POŽADAVKY NA ŘEŠENÍ
vlastní řešení. Pokud si ale budeme chtít dotazník vytvořit a spravovat sami a zdarma, možnosti jsou velmi omezené. Google docs Společnost Google v rámci svého projektu Google docs nabízí i tvorbu jednoduchých dotazníků. Dotazníky neumožňují definování podmínek, mají pouze několik základních typů otázek a neposkytují statistiku přístupů. Jejich výhodou je jednoduchost a rychlost použití. Příklad dotazníku vytvořeného pomocí Google docs je na obr. 2.4 (převzato ze stránky http://sites.google.com/site/onlinedotazniky/seznam/digifoto )
Obrázek 2.4: jednoduchý dotazník z Google docs Výhody a nevýhody Google docs: Jednoduchost Zdarma Všechny základní typy otázek Málo druhů otázek Chybí podmínky Nelze formátovat Chybí statistika přístupů Všechny otázky musí být na 1 stránce
9
2.4. EXISTUJÍCÍ ŘEŠENÍ
Vyplňto.cz Portál http://vyplnto.cz se poprvé objevil v roce 2008. V současné podobě začal fungovat krátce po oficiálním zadání této práce a rychle se dostal do povědomí veřejnosti. Je zaměřen především na SŠ a VŠ studenty. Splňuje většinu požadavků stanovených pro mou aplikaci. Má verzi zdarma i placenou verzi. Placená verze umožňuje vlastní formátování dotazníku pomocí CSS souboru, zahrnuje technickou podporu a podobně, základní funkčnost ale zůstává stejná jako ve verzi zdarma. Dále se budu zabývat pouze neplacenou verzí.
Obrázek 2.5: Tvorba dotazníku na portálu Vyplnto.cz Mezi hlavní nevýhody patří přesycenost a těžkopádnost systému. Design je zbytečně složitý a „přeplácaný“ (obr. 2.5), stejně tak přidávání otázek. Je zde na výběr velké množství typů otázek. Mnoho typů by se však dalo shrnout do jednoho. Uživatel si může zvolit například tyto typy otázky: Seznam - právě jedna Seznam - právě jedna - rozdělující Seznam - právě jedna - polouzavřená
Přehlednější by byla možnost zvolit otázku Právě jedna a až následně vybrat, zda bude polouzavřená nebo uzavřená, případně stanovit podmínky. Tento systém navíc například neumožňuje vytvořit polouzavřenou otázku s podmínkami (rozdělující). Podmínky jsou celkově řešeny nedostatečně. Je možné určovat podmínky pouze u otázek
10
KAPITOLA 2. POPIS PROBLÉMU, POŽADAVKY NA ŘEŠENÍ
typu Právě jedna a lze zvolit pouze odskok v závislosti na jedné konkrétní odpovědi. Není tedy možné vytvořit složitější konstrukce, spojovat více podmínek za sebe apod. Všechny otázky jsou umístěny na jedné straně (podmíněné otázky se dynamicky zobrazí až po zvolení odpovědi na otázku, která jejich zobrazení podmiňuje). To vede u delších dotazníků ke značné nepřehlednosti, systém dynamického skrývaní a zobrazování otázek navíc respondenta snadno dezorientuje. Otázka typu Scale je zde zastoupena celkem 8 typy otázek s pevně definovanou škálou možností (Otázka ano-ne-nevím, otázka 1-2-...10 atd.). V celém systému je velké množství vysvětlivek a popisků. To je výhodné pro naprostého laika, který v životě žádný dotazník nesestavoval a nedokáže si logicky odvodit vhodnou strukturu a podobu dotazníku. Pro jen trochu zkušenějšího uživatele budou všudypřítomné nápovědy na obtíž, neboť silně ztěžují orientaci v systému. Přes řadu nedostatků je však systém na českém trhu nejlepší. Je jediný zdarma, přičemž poskytuje dostatečné množství možností a volnosti při tvorbě dotazníku. Výhody a nevýhody Vyplňto.cz: V základní verzi zdarma Neomezený počet dotazníků a otázek Mnoho typů otázek Podmnínky Rychlost
( moderní technologie-AJAX )
Omezení 1 vyplnění na 1 IP/1 email Přehledné zobrazení výsledků průzkumu Export získaných dat Zbytečně moc typů otázek Nelze zapojit obrázky nebo multimédia Nepřehlednost Nelze formátovat
( ve verzi zdarma )
Primitivní podmínky otázek Všechny otázky na 1 stránce Nelze zcela zamezit opakovanému vyplnění Max. délka 1 průzkumu 2 měsíce Max. 5000 respondentů / měsíc Zobrazení reklamy
( ve verzi zdarma )
( ve verzi zdarma )
11
2.4. EXISTUJÍCÍ ŘEŠENÍ
2.4.2.3
Existující placená řešení
Budeme-li si chtít vytvořit dotazník od začátku do konce sami, je na českém trhu v současné době pravděpodobně jen jedno placené řešení, které nám to umožní: EasyResearch Portál http://easyresearch.biz nabízí tvorbu dotazníků na profesionální úrovni. Kromě vytvoření vlastních dotazníků poskytuje i možnost nechat si navrhnout a sestavit dotazník na míru. Dotazníky jsou skinovatelné, obsahují všechny základní typy otázek a umožňují definovat podmínky. Je k dispozici velké množství nastavení zobrazení a chování dotazníku i otázek (obr. 2.6). Přesto celá aplikace zůstává přehlednou a intuitivní. Na hlavní stránce je možnost přihlásit se do veřejného Demo účtu, kde si lze vyzkoušet tvorbu dotazníků před zakoupením vlastního účtu.
Obrázek 2.6: Tvorba jedné otázky na portálu EasyResearch.biz Hlavním nedostatek je tak cena, která odpovídá profesionální aplikaci a zaměření na firemní sféru. Zákazník si může vytvořit libovolný počet dotazníků a platí za počet povolených responsí. Cena začíná na 9 900,- Kč za 500 respondentů a končí na 170 000,- Kč za 10 000 resopndentů. V případě tisícovek respondentů a pravidelnějších průzkumů by pravděpodobně vyšlo levněji vyvinout vlastní systém.
12
KAPITOLA 2. POPIS PROBLÉMU, POŽADAVKY NA ŘEŠENÍ
Ač aplikace celkově budí dojem profesionality, má i mnohé nedostatky. Například nelze řetězit podmínky. Lze nastavit pouze přeskočení na zvolenou otázku v případě vybrání konkrétní odpovědi. Systém je poměrně pomalý - nevyužívá moderních webových technologií, při sestavování dotazníku se při každém kroku celá stránka znovu načítá. Je možné vložit do dotazníku vlastní obrázky, ty ale mají maximální velikost 500x500 pixelů. Na větší obrázky a multimédia (audio, video) je pouze možné vložit odkaz. Výhody a nevýhody EasyResearch.biz: Profesionální vzhled Neomezený počet dotazníků a otázek Mnoho typů otázek Mnoho možností nastavení Podmínky Filtrace respondentů Přehlednost Skinovatelnost Zobrazení obrázků Demo verze Velmi vysoká cena Nelze zapojit multimédia Primitivní podmínky otázek Rychlost
( častý refresh stránky )
13
2.4. EXISTUJÍCÍ ŘEŠENÍ
14
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Kapitola 3
Analýza a návrh řešení 3.1
Použité technologie
Vzhledem k plánovanému reálnému nasazení aplikace byly použity technologie používané v místě nasazení. 3.1.1 Databáze Jako databáze byla zvolena MySQL. Hlavní důvody pro zvolení této databáze: • Osvědčené řešení, používané v místě nasazení aplikace. • Je zdarma. • Dostatečná funkčnost pro naše potřeby. Aplikace byla vyvíjena pod verzí MySQL 5.0.22. Všechny použité příkazy jsou ale jednoduché, základní příkazy jazyka SQL, které bez problémů umí vykonat všechny používané databázové technologie. V případě potřeby lze proto aplikaci snadno migrovat a provozovat na jakékoli jiné databázi. Snadné kontrole nad databází a použitými příkazy byl přizpůsoben i datový model (podkapitola 3.2). 3.1.2 Programovací jazyk - serverová část Byl zvolen programovací jazyk PHP ve verzi 5.2.0. Hlavní důvody pro zvolený jazyk: • Technologie používaná v plánovaném místě nasazení • Snadná přenositelnost aplikace • Vyzkoušená technologie
15
3.1. POUŽITÉ TECHNOLOGIE
• Nejrozšířenější serverový jazyk • Běží na široce používaném serveru Apache Při výběru vhodného programovacího jazyka jsem bral v úvahu také jazyk Java. Java Enterprise Edition poskytuje velký komfort při vývoji webových aplikací. Vývoj složitých, rozvětvených aplikací je v Javě EE jednoduchý a díky návrhovému vzoru MVC (viz příloha A.1) je zajištěna přehlednost zdrojových kódů. Další výhodou je velmi dobrá bezpečnost Java EE aplikace, která je typicky méně náchylná na některé typy útoků než aplikace psané v PHP (například SQL injection). Je zde však i několik podstatných nevýhod: • Špatná přenositelnost aplikace • Nutný Java server (GlassFish, Apache Tomcat) • Větší systémové nároky aplikace • Technologie není ve firemním prostředí, pro které je určena tato aplikace, téměř vůbec rozšířena Jazyk PHP se tedy jeví jako lepší volba. Jednu z výhod Javy EE - dobrý návrhový vzor - lze navíc úspěšně simulovat i v PHP. K tomu byl použit šablonovací systém Smarty Smarty je volně šiřitelný šablonovací systém pro PHP. Základní myšlenkou Smarty je oddělit prezentační a aplikační logiku programu. Lze tak snadno přejít na návrhový vzor MVC a mít oddělenou aplikační, datovou a prezentační vrstvu aplikace. PHP skripty psané ve Smarty neobsahují HTML kód stránky - ten je umístěn ve zvláštních souborech, které lze vypsat příkazem display(). Libovolný řetězec lze ze skriptu vypsat na zvolené místo v HTML šabloně příkazem assign(). Dokumentace k balíku Smarty viz [5]. Aplikace byla vyvíjena ve Smarty verze 2.6.12. Pozn.: koncovky šablon (souborů s HTML kódem) jsem změnil z původních .TPL na .HTML pro snadnější práci se soubory (automatické zvýraznění syntaxe v editorech). Změna nemá vliv na funkčnost Smarty.
AJAX plugin Byl použit také volně šiřitelný AJAX plugin pro Smarty, umožňující jednoduché odesílání formulářů a volání PHP metod přes AJAX. Autorem pluginu je Dmitrij Štefljuk, dokumentace viz [6]. Plugin je volně šiřitelný pod licencí GNU Lesser General Public License [7]. 3.1.3 Protokol Serverová a klientská část aplikace komunikuje pomocí protokolu HTTP. Další možností bylo zvolení protokolu HTTPS. Aplikace ale nebude obsahovat žádná extrémně citlivá data a nebezpečí útoku je minimální. Vystačíme si proto se standardním protokolem. Přenos hesla při přihlašování do aplikace je navíc zvlášť chráněn hashem - viz podkapitola 4.3.
16
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.1.4 Klientská část Aplikace je vyvíjena jako HTML 4.01 Strict validní (specifikace viz [8]). Validnost HTML stránek, JavaScriptových skriptů i CSS stylů byla ověřována W3C validátorem [9]. Prototype Byl použit JavaScriptový framework Prototype [10]. Na tomto frameworku je postavena klientská část AJAX pluginu pro Smarty, jeho využití bylo tedy nutné. Je určen pro ulehčení vývoje moderních, dynamických webových aplikací. Má například zabudované metody pro usnadnění AJAX volání. Ukázal se ale být užitečným i při psaní JavaScriptových skriptů s AJAXem nesouvisejících. Nejvíce jsem využil konstrukci $(ID_OBJEKTU), která nahrazuje volání document.getElementById(ID_OBJEKTU) a značně tak zpřehledňuje kód. Podobným způsobem jako získání objektu s určitým ID lze například získat všechny objekty s určitou CSS třídou. I při využití jen menší části potenciálu tohoto frameworku je programování s ním komfortnější a výsledný kód přehlednější. Framework Prototype je šiřitelný pod MIT licencí [11].
17
3.2. DATOVÝ MODEL
3.2
Datový model
3.2.1 Databázové diagramy Databázové diagramy jsou v notaci UML 2.1. V příloze C je podrobný popis všech atributů, jejich datový typ, důležité parametry. U atributů, jejichž význam nemusí být na první pohled zřejmý, je tamtéž uveden stručný popis použití. Vysvětlivky: PK Primární klíč * Povinný (nenulový) atribut Podtržení Unikátní atribut
Obrázek 3.1: Datový model 1
18
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.1 zobrazuje hlavní část aplikace. Informace o klientovi (specifikace uživatelských rolí viz podkapitola 3.3) jsou uloženy v tabulce klient. Klient může mít 0 až N záznamů o aktivování či deaktivování svého účtu a o přihlášení. Tyto jsou v tabulkách ucet_aktivovan, ucet_deaktivovan a prihlaseni. Klient dále vlastní 0 až N dotazníků a 0 až N respondentů. Respondent vyplňuje rozhovor. Rozhovor vždy patří k právě jednomu dotazníku a obsahuje, kromě obecných informací, informace o odpovědích respondenta (tabulka odpoved) a informace o všech přihlášeních respondenta k tomuto rozhovoru (tabulka prihlaseni_respondent). Respondent má tedy přístup k dotazníku pouze pokud byl vytvořen rozhovor pro daného klienta a daný dotazník. Tabulka odpoved obsahuje vlastní text odpovědi (atribut odpoved_text a informace umožňující nalézt otázku, ke které odpověď. Atributy answer_type a answer_id jednoznačně určují možnost, kterou respondent v odpovědi na otázku zvolil. Tabulka respondent obsahuje atributy first_name, last_name, note, které jsou momentálně nevyužité. Jsou připraveny do budoucna pro vytvoření komplexnější správy respondentů a pro vytvoření účtu respondenta. V současné verzi aplikace lze respondenty spravovat pouze skrze jejich emailové adresy. Dotazník obsahuje vždy právě jeden prázdný (atribut empty=1) rozhovor. Tento rozhovor slouží pro testovací účely, kdy si klient vytvářející dotazník může zkusit dotazník vyplnit do tohoto prázdného rozhovoru. Prázdný rozhovor je jediný případ rozhovoru, který nepatří žádnému respondentovi. Diagram na první pohled obsahuje smyčku klient - respondent - rozhovor - dotaznik - klient. Při bližším pohledu je ale tato smyčka v pořádku, neboť neumožňuje průchod celou smyčkou ani v jednom směru. Zároveň ji nelze v žádném místě přerušit: Klient musí mít přístup ke všem svým respondentům, aby je mohl editovat. Nemusí mít přitom žádný dotazník - je tedy nutné přímé napojení na tabulku respondent. Respondent musí být přímo napojen na tabulku rozhovor, aby bylo možné zajistit vyplnění dotazníku respondentem maximálně jednou. Toho je docíleno díky tabulce rozhovor, která propojuje respondenta s konkrétním dotazníkem. Dotazník patří vždy právě jednomu klientovi. Dotazník obsahuje 0 až N otázek.
19
3.2. DATOVÝ MODEL
Obrázek 3.2: Datový model 2 - Otázka Na obrázku 3.2 je znázorněna struktura jedné otázky dotazníku. Každá otázka patří maximálně k jednomu dotazníku. Otázka nemusí patřit k žádnému dotazníku. V budoucnu tak případně bude možné přidat možnost uložení samostatných otázek a snadné použití jejich struktury ve více dotaznících. Otázka může být součástí vnější rotace - rotace celých otázek, kdy jsou otázky při každém zobrazení zobrazeny v náhodném pořadí. Tabulka vnejsi_rotace obsahuje pouze atribut id, bylo by ji tedy teoreticky možné vynechat a každá otázka by měla atribut vnejsi_rotace typu Integer. Otázky, které by byly součástí jedné rotace by tento atribut měly stejný. Řešení přes další tabulku je ale přehlednější a jednodušší na správu rotací. Navíc je v budoucnu jednoduše možné doplnit k vnější rotaci další atributy, upřesňující chování rotace. Otázka obsahuje 0 až N podmínek. Jedna podmínka obsahuje číslo podmiňující otázky (atribut precondition_id) a atributy answer_type, answer_id, které jednoznačně určují odpověď na otázku, kterou musí respondent zvolit pro splnění podmínky. Příklad: Klient nastaví podmínku „Skryj otázku číslo 4, jestliže odpověď na otázku číslo 3 není ANO“. Vytvoří se tedy podmínka, patřící k otázce číslo 4, která bude mít následující parametry:
20
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
precondition_id Id podmiňující otázky, v tomto případě id otázky číslo 3. answer_type bude „radio_button“, neboť odpověď „ANO“ je typu radio_button. answer_id Id radio_buttonu „ANO“. isEqual Bude rovno 0, neboť otázka číslo tři NENÍ rovna „ANO“ Nakonec se ještě nataví atribut show_if_true otázky číslo 4 na 0, neboť otázka se má skrýt, jsou-li její podmínky splněny.
Podmínky patřící jedné otázce se spojují logickými spojkami AND a OR, uloženými v atributu connector. Otázka obsahuje 0 až N odpovědí na otázku (příloha A.2). Na obrázku 3.2 jsou uvedeny tři tabulky, které mohou obsahovat odpověď na otázku: check_box, radio_button a otevrena_odpoved. Chceme-li najít konkrétní odpověď, musíme znát její typ = název tabulky, ve které je uložena, a její id. Proto tabulky podminka a odpoved obsahují atributy answer_type a answer_id. Jiným řešením by byla tabulka odpoved_na_otazku, mající atribut answer_type. Jednotlivé typy odpovědí (radio_button, check_box, otevrena_odpoved) by pak byly podentitami (ISA childs) entity odpoved_na_otazku. Obsahovaly by tedy, kromě svých atributů (v našem případě pouze atribut text), ještě atribut odpoved_na_otazku_id. V praxi by tedy jediná změna spočívala v nutnosti vytvoření další tabulky. Atribut answer_type tabulek podminka a odpoved by stejně nebylo možné vynechat: Musíme být schopni otestovat, jestli byla daná odpověď zvolena. To je potřeba nejen u podmínek, ale i u tabulky odpoved při kontrole, zda respondent zodpověděl povinnou otázku = zvolil nějakou její odpověď. Odpověď typu check_box byla zvolena je-li atribut odpoved_text tabulky odpoved roven „1“. Naproti tomu odpověď typu otevrena_odpoved byla zvolena je-li v atributu odpoved_text uložen jakýkoli nenulový řetězec. Pro otestování zda byla daná odpověď zvolena respondentem je tedy nutné znát i její typ. Atribut answer_type tabulek podminka a odpoved by, v případě implementace druhého řešení, nepředstavoval název tabulky, ve které je odpověď uložena, ale hodnotu stejnojmenného atributu tabulky odpoved_na_otazku. 3.2.2 Flexibilita Důležitým kritériem při návrhu databáze byla flexibilita. Zejména je třeba umožnit jednoduché přidávání nových typů otázek. Tento požadavek byl splněn. Tabulka otazka obsahuje pouze obecné atributy, společné pro všechny otázky. Vnitřní struktura otázky je pak poskládaná z jednotlivých odpovědí na otázky (check_box, radio_button).
21
3.2. DATOVÝ MODEL
Budeme-li chtít přidat nový typ otázky, vytvoříme pouze nové tabulky odpovědí na otázky, pokud si nevystačíme se stávajícími. Pokud otázka nového typu bude potřebovat více atributů, jednoduše vytvoříme novou tabulku, která bude obsahovat potřebné atributy, chybějící v tabulce otazka. Například otázka typu „Ohodnoť obrázek“ by měla atribut cesta_k_obrazku a skládala by se z radio_buttonů. Potom by stačilo vytvořit tabulku ohodnot_obrazek s atributy cesta_k_obrazku a otazka_id. Výsledná otázka by se pak skládala z jedné položky z tabulky ohodnot_obrazek a více položek z tabulky radio_button.
22
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.3
Případy užití
Případy užití, neboli Use Case, dávají představu o rozsahu aplikace. Definují všechny funkcionality, které daná aplikace bude mít. Diagramy byly sestaveny před začátkem návrhu celé aplikace a ukázaly se být poměrně užitečné při specifikaci požadavků. Jejich diskuzí bylo možné nastínit výslednou strukturu aplikace a byly přínosné pro vyjasnění všech požadovaných funkcionalit aplikace a upřesnění požadavků. Všechny diagramy případů užití, včetně podrobnějšího popisu, jsou připojeny v příloze D. 3.3.1 Uživatelské role
Obrázek 3.3: Uživatelské role • Respondent Může pouze vyplňovat existující dotazníky.
• Klient Může vytvářet, prohlížet a editovat dotazníky. Může rozesílat dotazníky respondentům. Může editovat svůj profil.
23
3.3. PŘÍPADY UŽITÍ
• Administrátor Může přidávat klienty. Může editovat, aktivovat a deaktivovat klienty. Může vše co klient.
3.3.2 Správa respondentů
Obrázek 3.4: Rozeslat dotazník • Editovat Respondenty Aktualizuje v databázi seznam emailů pro oslovení Respondentů. Klient může přidat emaily nebo smazat již přidané emaily.
• Změnit email Klient změní text emailu s výzvou k vyplnění dotazníku, rozesílaného Respondentům.
• Rozeslat email Rozešle email s výzvou k vyplnění dotazníku všem respondentům, přiřazeným k tomuto dotazníku. Dotazník má 2 stavy: - dosud nerozeslaný dotazník je podbarven žlutě - rozeslaný dotazník je podbarven zeleně
24
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Na obrázku 3.4 jsou znázorněny možnosti klienta v sekci aplikace pro rozeslání dotazníku. V této části aplikace může klient editovat respondenty. Může přidat nebo smazat emaily respondentů, na které bude rozeslán email s výzvou k vyplnění dotazníku. Nad každým emailem se vytvoří objekt Respondent, který bude uložen do databáze do tabulky respondent. Aplikace je tak připravena pro případné rozšíření správy respondentů. Distribuce dotazníku je řešena pouze pomocí emailů. Dotazník tedy nelze volně zpřístupnit. Při provádění většiny průzkumů je pro šíření dotazníku využívána externí databáze stálých respondentů. Není tedy třeba dotazník zpřístupňovat jakýmkoli jiným způsobem. Vázání přístupu na email zároveň zajistí, že každý respondent vyplní dotazník maximálně jednou. Další případy užití jsou k nahlédnutí v příloze D. Nepotřebují dodatečný výklad, bylo by proto zbytečné je uvádět i na tomto místě.
25
3.4. ANALYTICKÝ MODEL
3.4
Analytický model
3.4.1 Návrhový vzor Aplikace je postavena na návrhovém vzoru MVC [12]. Odděluje datovou, aplikační a prezentační vrstvu aplikace. 3.4.1.1
Datová vrstva
Nad tabulkami databáze klient, dotaznik, rozhovor, otazka a respondent jsou vytvořeny objekty. Atributy objektů odpovídají jednotlivým atributům tabulek. Například objekt Klient má tak atributy id, login atd. Nad zbylými tabulkami se objekty nevytváří. Obsahují menší množství atributů a není nutné k nim v aplikaci přistupovat příliš často. Vystačíme si proto s ponecháním dat z těchto tabulek ve 2D poli. Diskutabilní je objektová reprezentace tabulek odpoved, check_box, radio_button a otevrena_odpoved, ke kterým se v aplikaci přistupuje často a je nad nimi vykonáváno mnoho operací. Pro většinu operací, vykonávaných nad těmito tabulkami, je ale uchovávání dat v poli výhodné nebo přinejmenším není nevýhodné. Tabulky mají také poměrně malé množství atributů. Rozhodl jsem se tedy nad nimi objekty nevytvářet. Odpadne tím velká režie vytváření mnoha objektů a zdrojové kódy jsou, díky menšímu množství souborů, přehlednější. 3.4.1.2
Aplikační vrstva
Jádro aplikační vrstvy je tvořeno statickými třídami, které pracují nad objekty datové vrstvy. Například nad objektem Otazka pracuje statická třída Otazka_manager. Dále je zde několik pomocných tříd (Email, Otazka_writer) a třídy pro práci s databází. Poslední částí jsou pak skripty zaštiťující logiku jednotlivých webových stránek. 3.4.1.3
Prezentační vrstva
Šablonovací systém Smarty umožňuje velmi pohodlné oddělení prezentační vrstvy aplikace. Veškerý HTML kód je umístěn ve zvláštních souborech, které se zobrazují jednoduchými PHP příkazy a dohromady skládají webovou stránku.
26
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.4.2 Třídní model V této podkapitole jsou uvedeny diagramy tříd aplikace. V příloze E je kompletní návrhový model aplikace. Návrhový model obsahuje podrobnější diagramy tříd, s výpisem všech metod a atributů.
Obrázek 3.5: Analytický model 1 Instance třídy Databaze na obr. 3.5 obstarávají veškeré přístupy k databázi. Výsledky SQL dotazů při výběru z databáze třída vrací v podobě 2D pole. Třídy Prikazy a Prikazy_otazka obsahují metody sestavující všechny SQL příkazy v celé aplikaci. Obě mají pro vykonávání SQL příkazů jako atribut instanci třídy Databaze. Ve třídě Prikazy_otazka jsou příkazy týkající se otázek dotazníku, ve třídě Prikazy pak všechny ostatní (týkající se klienta, dotazníku, rozhovorů, respondentů apod.) Umístění všech SQL příkazů na jednom místě je velmi výhodné z hlediska přehlednosti a případných úprav databáze. Přispívá i k vyšší bezpečnosti, neboť je jednoduché zkontrolovat správné ošetření veškerých přístupů k databázi.
Obrázek 3.6: Analytický model 2
27
3.4. ANALYTICKÝ MODEL
Statické třídy Klient_manager, Resp_manager a Rozhovor_manager na obr. 3.6 zajišťují práci s objekty Klient, Respondent a Rozhovor. Většina metod těchto tříd se týká práce s databází (editovat údaje Klienta, updatovat seznam Respondentů v databázi apod.) Mají jako atribut instanci třídy Prikazy pro vykonávání potřebných SQL příkazů.
Obrázek 3.7: Analytický model 3 Statické třídy Dotaznik_manager a Otazka_manager na obr. 3.7 obsahují metody pro práci s dotazníky a otázkami, reprezentovanými objekty Dotaznik a Otazka. Některé operace potřebují přístup i k SQL příkazům, které přímo nesouvisí s otázkami, obě třídy proto vlastní instanci třídy Prikazy_otazka i Prikazy.
Obrázek 3.8: Analytický model 4 Třída Email na obr. 3.8 umožňuje rozesílání emailů. Statická třída Otazka_writer obsahuje metody pro vypsání HTML kódu jedné otázky. Umožňuje vypsat otázku pro editaci nebo pro zobrazení respondentovi. Pomocí statické třídy Menu lze vypsat HTML kód systémového menu v aplikaci, umístěného vlevo. Vypíše vždy příslušné menu podle uživatelské role právě přihlášeného uživatele. Dále obsahuje metody pro vypsání JavaScriptového kódu na konci HTML stránky. Statická třída Styly nastavuje cestu k adresáři s CSS styly a s obrázky.
28
KAPITOLA 4. IMPLEMENTACE
Kapitola 4
Implementace Princip fungování aplikace by měl být zřejmý z analýzy řešení (kapitola 3). Jednotlivé metody všech tříd jsou vypsány v příloze E. Názvy metod byly, pokud možno, voleny tak aby vystihovaly jejich účel. Součástí veškerých zdrojových kódů jsou navíc podrobné komentáře, orientace v kódech by tedy neměla činit větší potíže. Dále se budu zabývat pouze částmi implementace, o kterých se domnívám, že zaslouží samostatnou pozornost. V příloze F je popsána adresářová struktura celé aplikace.
4.1
Serverová část
Serverová část se skládá z PHP skriptů, které zajišťují vnitřní logiku jednotlivých stránek a ze souborů obsahujících PHP třídy. Skripty pro jednotlivé stránky mají název shodný s názvem stránky (otazky.php, research.php) a jejich názvy začínají vždy malým písmenem. Všechny objekty (třídy, viz podkapitola 3.4.2) jsou vždy umístěny ve stejnojmenném souboru (Otazka.php, Respondent_manager.php). Názvy začínají velkým písmenem. 4.1.1 Statické třídy Třídy zajišťující práci nad objekty datové vrstvy aplikace (tedy třídy Otazka_manager, Klient_manager ad.) jsou statické. Stejně tak několik dalších tříd - například Otazka_writer a Menu. Obecně jsou jako statické implementovány ty třídy aplikace, ke kterým se často přistupuje z mnoha různých míst. Statické třídy zpřehledňují kód a usnadňují programování. Není nutné při každém přístupu k metodám těchto tříd vytvářet jejich novou instanci nebo kontrolovat, zda již instance třídy existuje. Statické metody jsou navíc rychlejší [13]. Jedinou nevýhodou je, že PHP neumožňuje vytvořit v konstruktoru statické třídy objekt. Například třída Klient_manager má atribut Prikaz, který je instancí třídy Prikazy. Instanci třídy Prikazy ale nelze vytvořit při vytváření statické třídy Klient_manager. Tento problém jsem vyřešil metodou prepare(), která je volána vždy před prvním použitím každé statické třídy, a která naplní všechny její atributy - objekty.
29
4.1. SERVEROVÁ ČÁST
4.1.2 AJAX Důležitou součástí aplikace je technologie AJAX. Všechny složitější formuláře jsou odesílány na server pomocí AJAX volání. To je velmi výhodné zejména při editaci otázek, sestavování nových otázek a odesílání odpovědí na otázky. Otázky mohou mít složitou vnitřní strukturu a obsahují mnoho elementů. Počet elementů lze navíc dynamicky měnit. Díky AJAXu není nutné webovou stránku při odeslání formuláře znovu načíst. V případě chyby proto server pouze vrátí chybovou hlášku a nemusí posílat nazpět odeslaná data pro opětovné vyplnění formuláře. AJAX přispívá i k rychlosti aplikace díky minimalizaci množství odesílaných dat - klient a server si při zpracovávání formulářů vyměňují jen nezbytně nutné informace. Nevýhodou AJAXu je složitější implementace. V některých jednodušších případech, např. na stránkách detail_admin.php a detail.php, si proto vystačíme s klasickým způsobem odeslání a zpracování formulářů.
4.1.3 Přihlašování Přihlašování k aplikaci je řešeno pomocí relací (dále jako session). Při pokusu o přístup na libovolnou webovou adresu aplikace je zkontrolována existence a validnost session a je buď povolen přístup na stránku nebo zobrazen přihlašovací formulář. Způsoby ověřování uživatele a údaje ukládané do session se mírně liší podle uživatelských rolí:
4.1.3.1
Administrátor
Kód kontrolující oprávnění uživatele ke vstupu na stránku je v souboru prihlaseni_admin.php a je vložen na začátek každé stránky (tzn. každého PHP skriptu), na kterou má přístup pouze administrátor. Do session se ukládají tyto údaje: id - id klienta v databázi. role - role klienta. Nabývá hodnot „admin“ a „klient“. logged - má hodnotu „true“ je-li klient přihlášen. Při pokusu o přístup na stránku se zkontroluje, zda je session[„logged“] rovna „true“ a session[„role“] rovna „admin“ a poté se zobrazí obsah stránky. Pokud je session[„role“] rovna „klient“, provede se přesměrování na stránku index.php, tedy hlavní stránku klienta. Pokud session neexistuje nebo není validní, zobrazí se pouze přihlašovací formulář. Při zadání správného přihlašovacího jména a hesla se pak nastaví všechny parametry session a zobrazí se obsah požadované stránky. Informace o každém přihlášení jsou ukládány do databáze do tabulky prihlaseni.
30
KAPITOLA 4. IMPLEMENTACE
4.1.3.2
Klient
Přihlášení klienta probíhá analogicky k přihlášení administrátora. příslušný PHP kód je v souboru prihlaseni_klient.php a je vložen na začátek každé stránky, na kterou má přístup pouze klient. Na všechny stránky klienta má přístup i administrátor. Stránka se tedy zobrazí je-li session[„role“] rovna „klient“ i je-li rovna „admin“. V případě klienta je ještě kontrolována aktivace účtu. Byl-li účet deaktivován administrátorem (poslední datum deaktivování účtu je novější než poslední datum aktivování), je přístup odepřen. 4.1.3.3
Respondent
Respondent má přístup pouze na stránky research.php, questions.php a research_out.php (pro větší přehlednost jsou všechny stránky, na které má přístup jen respondent, pojmenovány anglicky). Kód pro kontrolu oprávnění přístupu je uložen v souboru prihlaseni_resp.php. Systém povolí přihlášení pouze respondentovi. Klient tyto stránky navštívit nemůže. K zobrazení a testování dotazníku má přístup ze svého účtu. Informace o každém přihlášení jsou ukládány do databáze do tabulky prihlaseni_respondent. 4.1.4 Společné metody Metody, které používá více různých stránek, jsou uloženy v souboru common_functions.php. Jedná se například o metody pro vypsání chybové hlášky, ověření validnosti emailové adresy nebo metody pro kontrolu splnění podmínek otázky (viz 4.1.6). 4.1.5 Ověřování formulářů Aplikace obsahuje velké množství nejrůznějších formulářů pro editování účtu klienta, vytváření dotazníků, editování otázek, respondentů ad. Ověřování správných údajů ze všech formulářů probíhá pouze na straně serveru. Komunikace s klientskou stranou aplikace je většinou řešena pomocí AJAXu, ověření je tedy ve většině případů velmi rychlé. Ověřování mnoha formulářů navíc vyžaduje přístup k databázi (např. ověření unikátnosti názvu dotazníku apod.). Kontrola vyplněných údajů také pomocí JavaScriptu by proto byla zbytečnou komplikací a přinesla by minimum užitku. Pokud server objeví nekonzistenci v přijatých datech, vrátí chybu. Aplikace provádí tyto kontroly přijatých formulářových dat: • Délka zadaného řetězce - Byla překročena maximální délka řetězce.
31
4.1. SERVEROVÁ ČÁST
• Špatně zadané číslo - Má-li být obsah přijatých dat nenulové číslo (např. PSČ, Číslo Popisné, velikost písma dotazníku), server testuje, zda operace intval(), popř. floatval(), provedená nad přijatým číslem, nevrátí nulu. • Prázdné povinné pole - Při kontrole povinného pole jsou nejprve vymazány znaky ze třídy regulárních výrazů [[:space:]] (viz [14]) a poté jsou data otestována na nulovou délku řetězce. • Logické chyby - Chyby vztahující se ke konkrétnímu formuláři. Například duplicita unikátního atributu, špatný formát emailové adresy apod. • Nesmyslná data - Server přijal nekonzistentní data. Př.: Nebyly odeslány všechny parametry editované otázky (chybí údaj o počtu sloupců). 4.1.6 Vyhodnocování podmínek V souboru common_functions.php jsou, mimo jiné, metody pro testování splnění podmínek otázky. Základem je rekurzivní metoda check_rest($conditions, $rozhovor_id). $conditions je pole podmínek, které zbývají k vyhodnocení, $rozhovor_id je id rozhovoru (slouží k nalezení odpovědi na podmiňující otázku). Metoda začne vyhodnocovat splnění podmínek od začátku pole $conditions. Pokračuje, dokud jsou podmínky spojeny logickou spojkou AND. Narazí-li na spojku OR, zavolá sebe samu a do parametru $conditions předá zbylé podmínky, čekající na vyhodnocení (následující za spojkou OR). Spojka AND má tedy při vyhodnocování přednost - nejprve se vyhodnotí řetězce podmínek spojených pomocí AND. Je-li alespoň jeden takový řetězec (logický výrok), sestávající se z jedné podmínky nebo z více podmínek spojených AND, pravdivý, je celkový výrok pravdivý. 4.1.7 Potvrzovací formulář V souboru admin.php je univerzální metoda potvrz_form(), která zobrazí potvrzovací ANO/NE formulář. V současné verzi aplikace je metoda nevyužitá a všechny potvrzovací formuláře jsou rovnou začleněny do HTML kódu a zobrazují se pomocí JavaScriptu. Původní způsob má výhodu dvojí kontroly přes PHP, kdy se formulář, požadující potvrzení, zobrazí až poté co server zkontroluje oprávněnost požadavku. Jedná se ale o složitější řešení, které navíc vyžaduje více komunikace se serverem. Rozhodl jsem se proto pro implementaci pomocí JavaScriptu. 4.1.8 Výkon Kromě AJAXu je výkonnost aplikace zlepšována i v serverové části, použitím některých obecně doporučovaných optimalizačních technik [13]: Objekty jsou, je-li to vhodné, předávány dalším metodám jako reference (prefixem „&“ před parametrem v hlavičce metody).
32
KAPITOLA 4. IMPLEMENTACE
Cykly používají zápis for ($i = 1; $i < = $delka_dat; $i++) místo zápisu for ($i = 1; $i < = count($data); $i++) Není tak nutné počítat délku pole znovu při každém průchodu cyklem. Foreach cyklům, jsou-li použity, je procházené pole předáno pomocí reference. V opačném případě totiž PHP pole zbytečně zkopíruje. Přístupy do databáze jsou pokud možno minimalizovány. Například editování dotazníku, otázky, klienta apod. je prováděno vždy jedním SQL příkazem, který aktualizuje všechny editovatelné sloupce. To je mnohem rychlejší než vykonání mnoha SQL příkazů, kdy každý aktualizuje pouze jeden sloupec tabulky. Výpis řetězce je realizován příkazem echo, který je rychlejší než příkaz print. Pozn.: Příkaz echo je používán pouze ve skriptech zpracovávajících AJAX volání. Jinde je výpis na stránku řešen pomocí Smarty příkazu assign().
Popsané techniky nejsou použity vždy. V některých případech by jejich použití znamenalo složitější či méně přehledný kód, přičemž přínos by byl minimální.
4.2
Klientská část
4.2.1 Požadavky aplikace Pro správnou funkčnost aplikace je vyžadováno splnění těchto požadavků: • Povolené cookies (pro uložení session) • Povolený JavaScript • Webový prohlížeč splňující W3C standardy[8] nebo webový prohlížeč Microsoft Internet Explorer 6.0 a vyšší (viz podkapitola 5.2 ). Povolený JavaScript má, vzhledem k jeho velké rozšířenosti, většina uživatelů internetu, stejně tak cookies. Aplikaci bude navíc používat uzavřená skupina uživatelů (klientů). Ti tak mohou být předem seznámeni s požadavky pro bezproblémový chod aplikace. Také respondenti, kteří budou oslovování s výzvou k vyplnění dotazníku, budou často stálými respondenty. Použití náhodným návštěvníkem, jehož webový prohlížeč nesplňuje požadavky aplikace, tedy prakticky nehrozí.
33
4.2. KLIENTSKÁ ČÁST
Obrázek 4.1: Plovoucí hláška 4.2.2 Systém oken Při vypisování chybových hlášek, požadování potvrzení prováděné akce, vytváření nového dotazníku nebo editování otázky aplikace zobrazuje plovoucí formuláře (obr. 4.1). Formuláře mají poloprůhledný rámeček a mají nastavenu CSS vlastnost position:fixed (kromě IE6, který tuto CSS vlastnost neumí). Systém tak budí dojem více oken otvíraných přes sebe, simuluje desktopové aplikace a zvyšuje komfort práce s aplikací. 4.2.3 Editace otázek Nejdůležitější a také nejsložitější částí aplikace je editace otázek. Pod tento pojem spadá vytváření nových otázek, mazání stávajících, editace všech parametrů otázek (např. povinnost otázky, umístění otázky, podmínky) i editace otázek samotných (tzn. textu otázky, odpovědí apod.). 4.2.3.1
Vytvoření nové otázky
Obrázek 4.2: Vytvoření nové otázky Na obr. 4.2 je zachyceno vytváření nové otázky. Text otázky lze formátovat pomocí HTML a lze zobrazit jeho okamžitý náhled.
34
KAPITOLA 4. IMPLEMENTACE
Pozn.: Momentálně není nijak ošetřeno zadání špatného HTML kódu. Pokud bude klient ignorovat náhled textu otázky a uloží otázku obsahující nesmyslný HTML kód, může např. rozbít strukturu zbytku stránky. Ošetření by však znamenalo návrh složitého syntaktického analyzátoru. Při záměrném zadání špatného kódu přitom klient může poškodit pouze svůj vlastní dotazník. Jakékoli protiopatření by tedy bylo zbytečné a nerentabilní. To platí i pro některé další části aplikace. Například při zadání příliš dlouhého textu otázky bez mezer bude tento přesahovat ven z rámečku otázky.
Lze dynamicky přidávat a mazat libovolné množství odpovědí podle zvoleného typu otázky. Odpovědi lze řadit do sloupců. Lze také pro větší přehlednost změnit šířku polí pro text odpovědi (například jsou-li odpovědi řazeny do mnoha sloupců, je vhodné šířku polí zmenšit). Všechny operace jsou přitom prováděny pomocí JavaScriptu pouze na straně klienta. Aplikace díky tomu na všechny změny reaguje okamžitě, klient není nucen čekat na komunikaci se serverem. Po zvolení možnosti Uložit se otázka pomocí AJAX volání odešle na server a uloží. V případě neúspěchu systém vypíše příslušnou hlášku. Díky ověřování přes AJAX přitom nedojde ke ztrátě vytvořené struktury otázky. 4.2.3.2
Editace existující otázky
Editace otázky je rozdělena do dvou částí: • Editace obsahu otázky. Po zvolení možnosti Editovat aplikace zobrazí formulář shodný s formulářem pro vytvoření nové otázky. Klient tak může změnit text otázky, upřesnění otázky a editovat jednotlivé odpovědi. • Editace obecných parametrů otázky. Klient nastavuje parametry související s chováním a zobrazením otázky v dotazníku. Viz obr. 4.3.
Obrázek 4.3: Otázka Pod každou otázkou (obr. 4.3) jsou možnosti pro editaci otázky. Veškeré provedené změny, včetně přesunu otázky na jinou stranu nebo smazání otázky, jsou opět vykonávány
35
4.2. KLIENTSKÁ ČÁST
pouze pomocí JavaScriptu a uloženy až po stisknutí tlačítka Uložit, umístěného nad a pod výpisem otázek. Práce s otázkami je tak rychlá a komfortní. Při provedení jakékoli editace systém červeně zarámuje všechny otázky pro zdůraznění nutnosti uložení změn (obr. 4.5).
Pozice otázky vůči předchozí Otázky lze přesunout vedle předchozí otázky (obr. 4.4). Jsou-li umístěny 2 otázky vedle sebe a dojde k přesunu nebo smazání levé otázky, pravá se automaticky roztáhne přes celou šířku stránky. Otázkou nelze přesunout vedle předchozí otázky, je-li tato také umístěna vedle předchozí.
Umístění otázky Klient může změnit umístění otázky v rámci současné strany nebo otázku přesunout na jinou stranu dotazníku. Ve druhém případě se otázka přesune vždy na konec zvolené strany. Díky tomu není nutné komunikovat se serverem a zjišťovat počet otázek na zvolené stránce. Při přesouvání otázky v rámci aktuální strany je nutné vzít v úvahu její pozici vůči předchozí otázce. Aplikace se snaží nezasahovat do umístění otázek vůči předchozí. Například při přesunu otázky z dolní části strany zcela nahoru se otázky, umístěné mezi výchozí a koncovou pozicí přesouvané otázky, nemohou pouze posunout o jednu pozici dozadu a uvolnit tak na začátku strany pozici pro přesouvanou otázku. Došlo by tím k narušení pozic otázek. (Například otázka umístěná vpravo od předchozí by se přesunula o jednu pozici ke konci strany a byla by umístěna vlevo. Naopak otázka jí předcházející by byla přesunuta vpravo a došlo by k narušení klientem zvoleného umístění.)
Přesouvané otázce je proto vždy nastavena pozice pod předchozí otázkou. Tím je zajištěno intuitivnější chování aplikace. Jedinou výjimkou je posun otázky o jednu pozici dopředu nebo dozadu. V takovém případě se otázka s vedlejší otázkou prohodí, včetně nastavení umístění vůči předchozí otázce.
Obrázek 4.4: Umístění otázek vedle sebe
36
KAPITOLA 4. IMPLEMENTACE
Podmínky Klient může k otázce přidat libovolné množství podmínek. Více podmínek je spojeno do logického výrazu spojkami AND nebo OR (obr. 4.3). Spojku klient volí při přidávání podmínky (vedle tlačítka přidat podmínku) a lze ji kdykoli změnit. Jednotlivé podmínky lze negovat nastavením operátoru „rovná se“ nebo „nerovná se“. Lze negovat i výsledný výraz nastavením, zda se má otázka při splnění podmínky zobrazit nebo skrýt (obr. 4.4). Aby podmínka dávala smysl, musí být podmiňující otázka na nějaké předchozí straně dotazníku. V opačném případě aplikace zobrazí varovnou hlášku, ale vytvoření podmínky povolí - otázky je možné kdykoli přesunout. Je-li podmiňující otázka na stejné straně dotazníku, podmínka bude při zobrazení respondentovi ignorována - dynamické skrývání otázek v závislosti na zvolené odpovědi na podmiňující otázku v rámci jedné strany dotazníku by působilo rušivě. Povinnost otázky Je-li zaškrtnut Check box Povinná otázka, aplikace respondentovi nedovolí přejít na další stranu před zodpovězením otázky. Při vyplňování dotazníku je vyplnění povinných otázek kontrolováno přes AJAX. V případě chyby tak respondent nepřijde o jím vyplněné odpovědi na stránce. Pozn.: Kontroluje se pouze zodpovězení zobrazených povinných otázek. Dojde-li ke skrytí povinné otázky (otázka nesplní nastavené podmínky), respondent na ni samozřejmě odpovídat nemusí. Vnitřní rotace U otázky číslo 8 (obr. 4.3 a 4.4) byly jednotlivé odpovědi přidány ve vzestupném pořadí od 1 do 24. Díky zaškrtnuté možnosti Rotovat odpovědi se ale vypisují v náhodném pořadí. Při zvolení možnosti Editovat se odpovědi pro větší přehlednost do formuláře pro editaci otázky (obr. 4.2) vypíší v původním pořadí. Stejně tak při vypnutí rotace se odpovědi seřadí v pořadí, v jakém byly přidány.
Obrázek 4.5: Výzva k uložení otázky
37
4.3. ZABEZPEČENÍ
Aplikace při najetí myší zobrazuje krátké nápovědy (obr. 4.5). 4.2.4 Ikony Systém používá 2 sady ikon ze stránek http://e-lusion.com/design/greyscale/ a http://www.wefunction.com/function-free-icon-set. Obě jsou zdarma k volnému použití pod Royalty free licencí [15]. 4.2.5 Stylování Stylování všech elementů je zajištěno pomocí kaskádových stylů. Všechny kaskádové styly jsou uloženy v soubory styly.css v adresáři s názvem daného skinu. Umístění všech stylů do jednoho souboru má výhodu ve snadné editaci a v možnosti mít jednotnou HTML hlavičku na všech stránkách. Na stránkách dotazníku jsou některé CSS třídy vypsány přímo do hlavičky HTML stránky. Jedná se o třídy, zajišťující formátování dotazníku a otázek (barvy, fonty), které je unikátní pro každý dotazník. Vypsání CSS tříd pomocí PHP a Smarty přímo do hlavičky je tak nejjednodušší řešení. Při prohlížení v různých webových prohlížečích lze narazit na drobné odlišnosti - typicky o několik pixelů větší nebo menší vertikální odsazení elementů. Domnívám se ale, že to je malá daň za možnost mít jednotné styly pro všechny prohlížeče. Některé rozdíly v chování prohlížečů jsou korigovány pomocí JavaScriptu (viz podkapitola 5.2). V současnosti má aplikace jen jeden skin, umístěný v adresáří styly/default.
4.3
Zabezpečení
Ke zvýšení bezpečnosti přispívají tato opatření: • Inicializace proměnných - V místech kódu, kde hrozí bezpečnostní riziko podstrčením proměnné zvenku, jsou proměnné před použitím vždy inicializovány.
• Heslo v SHA1 - Hesla klientů jsou v databázi uložena jako SHA1 hash. K heslu je před zašifrováním připojen salt v podobě loginu klienta, který je vždy unikátní. Tím je zajištěna unikátnost ukládaného hashe. Naproti tomu hesla respondentů jsou uložena v nešifrované podobě. K těmto heslům aplikace musí mít přístup pro možnost jejich rozeslání respondentům spolu s výzvou k vyplnění dotazníku. Bezpečnostní riziko je zde minimální - pokud se hesel někdo zmocní, může pouze za respondenty vyplnit dosud nevyplněné dotazníky.
• Přenos hesla v SHA1 - Přenos hesla klienta při přihlašování je také uskutečněn v SHA1. Tím je zajištěna bezpečnost hesla v případě útoku odchytáváním paketů. Útočník se při zachycení hashe sice může přihlásit do aplikace, ale nedostane se k nešifrované podobě hesla. Heslo samotné je totiž mnohem cennější než přístup do systému, neboť velké množství uživatelů internetu používá jednotné heslo pro přístup k více aplikacím.
38
KAPITOLA 4. IMPLEMENTACE
Při generování hesla respondentů není použit žádný salt, teoreticky tedy může dojít k vygenerování dvou stejných hesel. Heslo respondenta má 4 znaky a je generováno z množiny číslic a velkých i malých písmen abecedy - celkem z 62 znaků. Při generování nového hesla je šance, že bude vygenerováno
1
již existující heslo N 1 4 , kde N je počet respondentů v databázi. ( 62 )
1 6 1 )4 = 14, 78 · 10 , respondentů budou celkem tisíce, maximálně několik desítek tisíc. ( 62 1 Při 10 000 respondentech je tedy riziko již 1478 Po vygenerování nového hesla proto systém zkontroluje, zda je unikátní. Dokud ne, generuje nové. Tím je zajištěna unikátnost a zároveň je zachována výhoda krátkého hesla.
4.4
Zdrojové kódy třetích stran
V aplikaci jsou použity tyto externí zdrojové kódy: • JS funkce sha1Hash() pro vytvoření SHA1 hashe je ze stránky http://www.movable-type. co.uk/scripts/sha1.html
• JS funkce getStyle() pro získání aktuálního CSS stylu elementu ze stránky http:// www.javascriptkit.com/dhtmltutors/dhtmlcascade4.shtml
• CSS styl přihlašovacího formuláře je částečně převzat ze stránky http://internet. stemmark.cz/iquest/
39
4.4. ZDROJOVÉ KÓDY TŘETÍCH STRAN
40
KAPITOLA 5. TESTOVÁNÍ
Kapitola 5
Testování Aplikace je v současnosti zprovozněna na staging serveru (viz příloha A.2) na adrese http://stemmark.bstudio.cz.
Přihlašovací údaje pro účet administrátora: admin/admin Přihlašovací údaje pro účet klienta (obsahuje vzorový dotazník): karel/karel Pozn.: Všechny odesílané emaily (např. při přidávání nového klienta nebo při rozesílání dotazníku respondentům) jsou přesměrovány na k tomuto účelu zřízenou emailovou adresu. Lze tedy neomezeně testovat i části aplikace rozesílající emaily.
5.1
Testování serverové části
Při ověřování funkčnosti serverové části aplikace jsem testoval postupně jednotlivé moduly - případy užití. Po implementování každého případu užití byla nejprve ověřena funkčnost modulu při zadání všech možných očekávaných vstupů. Dále byla prověřena funkčnost při přijmutí nestandardních, neočekávaných vstupů. Důraz byl kladen také na ověřování úspěchu všech databázových transakcí. Při vkládání dat do databáze aplikace vždy ověřuje, zda vložení proběhlo úspěšně. Naopak při výběru dat z databáze program počítá s možnou chybou a před další prací se získanými daty kontroluje, zda výběr proběhl v pořádku (SQL příkaz nevrátil prázdná data). 5.1.1 PHPUnit PHPUnit je framework určený k testování PHP skriptů. Má velmi dobrou dokumentaci [16] a psaní testů je poměrně jednoduché. Základní princip spočívá v testování správného obsahu zpracovávaných dat. Například zpracováváme-li pole dat a v určitém místě kódu má být délka tohoto pole rovna 1, napíšeme jednoduchou metodu pro ověření délky, jejíž tělo bude obsahovat konstrukci $this->assertEquals(1, count($pole)); assertEquals() je funkce PHPUnit frameworku. Po spuštění testu framework přehledně vypíše všechny testovací metody, které skončily chybou (testovaná podmínka nebyla splněna).
41
5.2. TESTOVÁNÍ KLIENTSKÉ ČÁSTI
Serverová část aplikace je poměrně jednoduchá, zvolený návrhový vzor umožňuje tvorbu jednoduchého a přehledného kódu. Širší nasazení PHPUnit testů nebylo proto potřebné. Psaní PHPUnit testů vyžaduje, i přes jejich jednoduchost, více programátorského času než například testování pomocí výpisu echo. Vyvíjená aplikace je sice rozsáhlá, ale struktura kódů je transparentní, neobsahuje složitější konstrukce. Rozsáhlost aplikace je dána pouze množstvím funkcionalit. Ty většinou spočívají v jednoduchých akcích (přejmenuj otázku, nastav povinnost otázky apod.), u kterých by testování pomocí PHPUnit bylo časově nerentabilní.
5.2
Testování klientské části
Testování a ladění klientské části se ukázalo být podstatně náročnější, než testování části serverové, a to zejména kvůli požadované funkčnosti ve všech nejčastěji používaných webových prohlížečích. Přestože jsou všechny stránky HTML 4.01 Strict validní, bylo nutné provést mnoho změn a úprav kvůli odlišnosti v chování různých prohlížečů. 5.2.1 Webové prohlížeče Funkčnost aplikace byla testována v těchto webových prohlížečích
(řazeno dle jejich podílu na
trhu - viz obr. 5.1 ):
• Mozilla Firefox 3.0.9 a 3.5 • Microsoft Internet Explorer verze 6, 7 a 8
(Pozn.: Pro testování ve více verzích Internet
Exploreru na jednom počítači byly používány programy IETester v.0.3.3 a IE6 standalone.)
• Google Chrome 2.0 • Safari 4 • Opera 9.62 a 9.64
Obrázek 5.1: Podíly webových prohlížečů na trhu podle w3schools [17] Statistiky na obr. 5.1 jsou celosvětové, zastoupení prohlížečů na českém trhu se mírně liší. Například podle stránky http://rankings.cz/ je podíl Firefoxu v ČR jen 34,05%. Důležitý je ale podíl všech testovaných prohlížečů dohromady. Dle obr. 5.1 je to 99,2%.
42
KAPITOLA 5. TESTOVÁNÍ
Stránka http://rankings.cz/ se zaměřuje na český trh a poskytuje statistiky i podle verzí jednotlivých prohlížečů. Podle těchto statistik pokrývají testované prohlížeče 96,37% českého trhu. Chování prohlížečů se však ve většině případů v jejich jednotlivých verzích neliší. Firefox 2.x bude stránku velmi pravděpodobně zobrazovat stejně jako Firefox 3.x. Zahrneme-li do výsledné sumy podílů z http://rankings.cz/ i prohlížeče Firefox 2.x (2%) a 1.x (0,63%), dostaneme pokrytí 99% prohlížečů, používaných v České republice. 5.2.2 Rozdíly v zobrazení Z důvodu použití jednotného CSS stylu pro všechny prohlížeče se zobrazení v různých prohlížečích může mírně lišit. Největší rozdíly v zobrazení má prohlížeč Microsoft Internet Explorer 6. Nejmarkantnější rozdíl je na stránce otazky_edit.php. Na obr. 5.2 je část této stránky zobrazené v prohlížeči Firefox 3.0.9. Na obr. 5.3 pak v IE6. IE6 má problémy s absolutním i relativním pozicováním elementů a vůbec neumí fixní pozicování. Potvrzovací formuláře a systémové hlášky, které jsou ve všech ostatních prohlížečích plovoucí (nereagují na posouvání zbytku stránky a zůstávají stále na stejné pozici), musí být v IE6 pozicované absolutně. Tlačítka Další a Předchozí strana jsou posunuty dolů. Poloprůhledný rámeček ve formátu .png zobrazuje IE6 neprůhledný. Šířka potvrzovacího formuláře je rozebrána v podkapitole 5.2.3.
Obrázek 5.2: Rozdíly zobrazení - Firefox 3.0.9
Obrázek 5.3: Rozdíly zobrazení - IE6
5.2.3 Korekce rozdílů v zobrazení a funkčnosti V této podkapitole jsou popsány rozdíly v chování různých webových prohlížečů a některá řešení těchto rozdílů. Nejedná se o úplný výčet. Zejména korekcí pro IE6 je v aplikaci více.
43
5.2. TESTOVÁNÍ KLIENTSKÉ ČÁSTI
Přestože prohlížeče MSIE (v čele s IE6) dodržují webové standardy nejméně, určité problémy se, zejména díky masivnímu nasazení JavaScriptu a práce s DOM, v průběhu vývoje objevily ve všech prohlížečích. 5.2.3.1
HTML, CSS
Plovoucí formulář používaný například pro potvrzování prováděné akce (obr. 5.2) zobrazují všechny verze MSIE roztažený přes celou šířku stránky, místo nastavení šířky podle obsahu. Šířka formuláře v těchto prohlížečích je proto pevně nastavena. Absolutně pozicované elementy a IE6 IE6 neumí překrýt elementy <select> absolutně pozicovaným elementem. Pokud na stránce otazky_edit.php systém zobrazí formulář pro editaci otázky a pod tímto formulářem se nachází HTML elementy <select> (např. rozbalovací seznamy pro výběr podmínky či pozice otázky), v IE6 budou „prosvítat“ skrz formulář (formulář je nepřekryje). Řešení: V IE6 se pod všechny plovoucí formuláře, systémové hlášky apod. vloží element <iframe> o stejné velikosti. IE6 hack V kaskádových stylech je několikrát použit tzv. podtržítkový hack[18] pro IE6. Cols Prohlížeč Safari zobrazuje mnohem větší šířku elementu TextArea než ostatní. Stejná hodnota parametru cols způsobí v Safari větší šířku. Problém je vyřešen použitím CSS atributu max-width. Odřádkování za formulářem Firefox jako jediný neodřádkovává za formulářem. Zbylé prohlížeče vloží za formulář prázdnou řádku. Vyřešeno CSS atributem display: inline. Overflow:hidden Opera neumí skrýt posuvník (Scroll bar) u elementů TextArea. Řešení tohoto problému jsem nenalezl. Například na stránkách dotaznik_send.php nebo dotaznik_edit.php je posuvník v prohlížeči Opera vždy zobrazen. Odsazení tabulky Opera v některých případech odsazuje element
jinak než ostatní prohlížeče. Všechny tabulky, které jsou součástí elementu
jsou proto obaleny dalším elementem
. 5.2.3.2
JavaScript a DOM
Pro testování některých JavaScriptových kódů jsem použil doplněk prohlížeče Firefox - Venkman JavaScript Debugger [19]. Tento debugger bohužel neumí monitorovat AJAX volání a v některých případech způsobuje pád celého prohlížeče, nebylo ho tedy možné použít vždy.
44
KAPITOLA 5. TESTOVÁNÍ
OffsetHeight Prohlížeče IE7 a IE8 špatně počítají DOM atribut document.documentElement.offsetHeight, který vrací výšku elementu. Pravděpodobně, jako jediní, započítávají do výsledné hodnoty i absolutně pozicované elementy. V některých případech (např. JS funkce show_edit_question() v souboru JSInquiry.js) je proto nutné počítat pozici elementu pro tyto prohlížeče zvlášť. Obsah TextArea Prohlížeče Firefox a Opera neumí přes DOM ani přes vlastnost innerHTML změnit obsah elementu TextArea, jehož obsah byl změněn uživatelem. Obsah sice dovolí změnit, ale provedené změny se objeví až po aktualizaci zobrazení (např. při přepnutí na jiný panel v prohlížeči a zpět). Řešení: Na stránce dotaznik_send.php se (při aktualizaci seznamu emailů respondentů přes AJAX) celý element TextArea pomocí DOM zkopíruje, vymaže z toku dokumentu a na jeho místo se vloží vytvořená kopie. Událost OnBeforeUnload Opera (testováno ve verzi 9.64 a 10.00 Beta) nezná JS událost OnBeforeUnload, používanou pro upozornění klienta, že neuložil provedené změny na stránce otazky_edit.php. Používá-li klient Operu, je použita událost OnUnload, která neumí odchod ze stránky zastavit (navíc se nespustí při zavření okna nebo panelu prohlížeče). Událost OnUnload zobrazí hlášku o ztracení provedených změn. Odesílání hesla Při přihlašování je SHA1 hash hesla odesílán ve skrytém poli () a původní pole je vynulováno. Google Chrome totiž jinak při volbě Uložit heslo uloží hash hesla a při příštím zobrazení přihlašovacího formuláře do pole Heslo vyplní tento hash. ScrollTop Prohlížeče Google Chrome a Safari (oba jsou postaveny na stejném renderovacím jádře) neznají DOM atribut document.documentElement.scrollTop (respektive znají ale vracejí vždy nulu), používaný pro pozicování otázek. Lze jej u nich nahradit atributem document.body.scrollTop, který naopak neznají zbylé testované prohlížeče.
5.3
Známé chyby aplikace
Vzhledem k malému množství všech chyb jsou zde bez roztřídění zahrnuty chyby aplikace i chyby některých komponent, které se ve výsledné aplikaci neprojeví, ale vyžadují pozornost programátora (např. podkapitola 5.3.3). 5.3.1 IE6 bug (01) IE6 si nepamatuje zaškrtnutí Check boxu, pokud se Check box pomocí DOM a JS vyjme ze stránky a následně do ní opět vloží. Tento bug se projeví v následujícím scénáři: Klient zaškrtne u otázky1 přesun na jinou stranu, ale nechá v rozbalovacím seznamu zvolenou současnou stranu. Poté vyvolá přerovnání otázek na stránce (smaže nějakou otázku nebo ji přesune v rámci strany či na jinou stranu). Aplikace pomocí JS vyjme z DOM všechny otázky, přerovná je (přesouvanou / mazanou otázku přesune na novou pozici nebo skryje) a vloží nazpátek. V IE6 bude nyní u otázky1 Check box pro přesun na jinou
45
5.3. ZNÁMÉ CHYBY APLIKACE
stranu odškrtnutý, rozbalovací seznam pro výběr strany ale zůstane zpřístupněný (<select> nemá nastaven atribut disabled). Zaškrtne-li nyní klient opět Check box pro přesunutí otázky na jinou stranu, znepřístupní se rozbalovací seznam pro výběr strany.
Řešení: Klient musí znovu načíst stránku (uložit provedené změny) nebo Check box pro přesun otázky na jinou stranu nezaškrtávat - přesun funguje i při nezaškrtnutém Check boxu, stačí v rozbalovacím seznamu vybrat číslo požadované strany. 5.3.2 IE bug (02) IE nedovolí zaškrtnout Radio button přidaný na stránku pomocí JS a DOM. To nijak nevadí funkčnosti, ale při přidávání nových odpovědí na otázku typu radio_button si klient nemůže zkusit radio_button zaškrtnout. Po uložení otázky a jejím výpisu na stránku to již samozřejmě jde. Pozn.: Na stránce otazky_edit.php lze v rámci jedné otázky typu Single-choice zaškrtnout všechny odpovědi (Radio buttony). Nejedná se o bug - jednotlivé Radio buttony musí mít při editaci unikátní atribut name, aby je server mohl rozpoznat a aktualizovat v databázi při editaci otázky. Při zobrazení dotazníku respondentovi pak samozřejmě všechny Radio buttony v rámci jedné otázky mají atribut name stejný.
5.3.3 SmartyAjax bug (03) U Smarty konstrukce {ajax_form} nefunguje parametr ”params”, který má podle dokumentace k AJAX pluginu pro Smarty [6] předávat serveru požadované proměnné. Podívámeli se ale do zdrojových kódů SmartyAjax (soubor smarty_ajax.js), zjistíme, že tento parametr není implementován a v dokumentaci je tedy uveden chybně. Řešení: Dodatečné parametry, které je třeba odeslat na server při odesílání formuláře pomocí AJAXu lze poslat pomocí skrytého pole (). 5.3.4 Čeština v emailech (04) Při odeslání emailu ze staging serveru jsou špatně zobrazeny české znaky. Problém pravděpodobně spočívá v nastavení poštovního serveru. Jeho konfiguraci bohužel není možné provést, přístup k němu má pouze poskytovatel hostingu. V předpokládaném místě reálného nasazení aplikace je k dispozici poštovní server s fungující češtinou.
46
KAPITOLA 6. ZÁVĚR
Kapitola 6
Závěr 6.1
Splnění zadání
Oficiální zadání bakalářské práce obsahuje výčet požadovaných součástí práce. Provedu proto jejich diskuzi. Jednotlivé body jsou pro větší přehlednost zkráceny či přeformulovány, původní smysl je však zachován. • Prostudujte existující řešení. Na českém trhu není příliš podobných aplikací, podkapitola 2.4 tak obsahuje jejich poměrně ucelený výčet a rozbor. • Navrhněte podobnou aplikaci Návrhu aplikace jsem věnoval velkou pozornost (viz kompletní dokumentace). Díky implementaci v PHP je aplikace snadno přenositelná. Soustředil jsem se na nevýhody existujících řešení a snažil jsem se těmto vyhnout. Výsledná aplikace tak například obsahuje mnohem propracovanější systém podmínek než rozebíraná existující řešení. Výhodou je také zapojení moderních webových technologií. Díky širokému použití JavaScriptu a AJAXu je práce s hlavní částí aplikace - tvorbou otázek - velmi rychlá a pohodlná. • Implementujte alespoň 5 základních typů otázek. V současnosti aplikace nabízí méně typů otázek, tento bod tedy nebyl zcela splněn. Záleží ale na způsobu dělení otázek. Bylo by například možné po vzoru serveru http://vyplnto.cz (podkapitola 2.4.2.2) považovat uzavřenou otázku, polootevřenou otázku, otázku obsahující podmínky a povinnou otázku stejného typu za 4 různé typy. Toto řešení je přehnané, ale domnívám se, že například možnost přidat ke každé otázce otevřenou odpověď a tím z ní vytvořit otázku polootevřenou rozhodně za zmínku stojí. • Dbejte na možnost budoucího rozšíření o nové funkce, nové typy otázek. Aplikace je psaná objektově a je k dispozici obsáhlá dokumentace, včetně četných komentářů všech zdrojových kódů. Přidání nového typu otázky je věnována příloha G. Postup při přidávání nové otázky je podrobně popsán krok za krokem. Většina nutných úkonů je přitom spojená s obsluhou nového typu otázky (vytvoření potřebných komponent otázky, formulářů pro
47
6.2. ROZSAH PRÁCE
její editaci apod.). Skripty pro práci s otázkami jsou psané pokud možno univerzálně a při přidávání nových typů otázek by neměla být potřeba jejich modifikace. • Spusťte aplikaci na webovém serveru. Testujte v nejčastěji používaných webových prohlížečích. Aplikace je zprovozněná na staging serveru (kapitola 5) a její použitelnost je prokázána v prohlížečích pokrývajících minimálně 99% trhu. Funkčnost lze předpokládat i v dalších, netestovaných prohlížečích, splňujících alespoň základní standardy. Většinu bodů oficiálního zadání bakalářské práce je tedy možné považovat ze splněné. Další možností hodnocení je kontrola implementování všech případů užití (příloha D). Všechny klíčové funkce aplikace implementovány byly. Mnoho vedlejších funkcí bohužel z časových důvodů implementováno dosud nebylo. Jsou to například: • podrobnější výpis informací v detailu účtu • podrobnější zobrazení výsledků dotazníku • možnost změny barev a fontů - Aplikace je na tuto funkcionalitu připravena, barvy a fonty jsou v databázi uloženy individuálně pro každý dotazník, chybí tedy pouze formulář pro jejich změnu.
• možnost nahrát do záhlaví logo
Při projití specifikace požadavků (podkapitola 2.3) zjistíme, že byly implementovány všechny funkcionality s nejvyšší prioritou a některé s prioritou 2 (Umístění otázek vůči předchozí, Obrázky - lze vložit pomocí HTML kódu, Barvy a fonty - téměř hotové). Současný stupeň dokončení aplikace již dostačuje k jejímu použití v reálném provozu. Některé funkcionality, které jsem nestihl implementovat do data odevzdání této práce, plánuji dokončit v nejbližší možné době. Dosavadní vývoj zabral cca 270 hodin času, z časového hlediska je tedy rozsah aplikace dostatečný (doporučený rozsah dokonce přesahuje).
6.2
Rozsah práce
Doporučený rozsah bakalářské práce je 20 - 60 stran [1]. Celková délka mé práce je větší, nicméně délka textu bez příloh toto doporučení splňuje. Vzhledem k očekávanému reálnému nasazení a dalšímu vývoji aplikace je podrobná dokumentace důležitá a může značně usnadnit převzetí vývoje dalšími programátory. Domnívám se tedy, že větší obsáhlost není na závadu.
48
KAPITOLA 6. ZÁVĚR
6.3
Přínos práce
Největším přínosem pro mne byl návrh aplikace. Postupný vývoj, od případů užití přes návrh databáze po samotnou implementaci, se ukázal být vzhledem k poměrně velkému rozsahu aplikace výhodný a důkladné promyšlení struktury aplikace velmi usnadnilo její programování. Dalším velkým přínosem bylo důkladnější poznání jazyka PHP a především jazyka JavaScript a technologie AJAX. Naučil jsem se využívat všechny výhody modelu DOM a lépe s ním pracovat. Dozvěděl jsem se, že JavaScript je mnohem mocnější jazyk, než za jaký jsem ho dosud považoval, o čemž svědčí i existence rozsáhlých frameworků.
49
6.3. PŘÍNOS PRÁCE
50
PŘÍLOHA A. POUŽITÉ ZKRATKY A POJMY
Příloha A
Použité zkratky a pojmy V této příloze je výpis použitých zkratek a použitých pojmů. V případě zkratek se ve většině případů jedná o zkratky běžně používané v dané problematice. Pojmy jsou pak buď používané sociologické termíny nebo mnou definované pro větší přehlednost textu.
A.1
Zkratky
2D 2 dimenzionální AJAX Asynchronous JavaScript and XML CSS Cascading Style Sheets DOM Document Object Model ECTS European Credit Transfer and Accumulation System HTML Hypertext Mark-up Language HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IE Internet Explorer (IE6 - Internet Explorer 6) IP Internet Protocol, Internet Protocol address Java EE Java Enterprise Edition JS JavaScript MSIE Microsoft Internet Explorer MVC Model–View–Controller, návrhový vzor PHP Hypertext Preprocessor SHA Secure Hash Algorithm
51
A.2. POJMY
SQL Structured Query Language SOŠ Střední odborná škola SOU Střední odborné učiliště SŠ Střední škola UML Unified Modeling Language VŠ Vysoká škola W3C World Wide Web Consortium
A.2
Pojmy
Bug - Původně anglický termín pro programátorskou chybu. Dotazník - Soubor otázek a pravidel pro jejich zobrazení respondentovi. Intro - Úvodní text dotazníku, který si respondent přečte před zahájením vyplňování dotazníku. Může obsahovat instrukce pro vyplňování apod. Multiple-choice - Typ otázky Otázka sestávající se z elementů Check box. Je možné vybrat (zakšrtnout) žádnou až všechny odpovědi. Odpověď na otázku - Jedna konkrétní odpověď na otázku. Například Otázka typu Singlechoice může mít 10 různých odpovědí, z nichž respondent může vybrat maximálně právě jednu. Nezaměňovat s odpovědí respondenta. Mezi základní komponenty, které mohou tvořit odpověď na otázku, patří tyto HTML elementy: Check box Radio button TextArea
Odpověď respondenta - Odpověď, kterou respondent vybral na danou otázku. Například otázka typu Multiple-choice obsahuje 10 různých odpovědí na otázku. Odpověď respondenta bude 1,4 a 7. Respondent zaškrtnul možnosti 1, 4 a 7. Otevřená otázka - Typ otázky Otázka sestávající se z elementů TextArea. Odpověď vlastními slovy, resopndent může zadat libovolný text. Outro - Závěrečný text dotazníku. Typicky obsahuje poděkování za čas strávený vyplňováním dotazníku. Podmínka - Logický výrok, podmiňující zobrazení nebo skrytí otázky. Otázka může obsahovat více podmínek, zřetězených logickými spojkami.
52
PŘÍLOHA A. POUŽITÉ ZKRATKY A POJMY
Podmiňující otázka - Otázka, která vytváří podmínku k aktuální otázce. Příklad: Je-li odpověď na otázku číslo 3 „ano“, skryj tuto otázku. V tomto případe je Podmiňující otázkou otázka číslo 3 a Podmiňující odpovědí odpověď „ano“. Podmiňující odpověď - Odpověď na Podmiňující otázku, která utváří podmínku (viz Podmiňující otázka). Polootevřená otázka - Též Polouzavřená otázka (druhý termín používá například server http://vyplnto.cz). Otázka, jež kromě základní odpovědi (Check box, Radio button) skýtá i možnost otevřené odpovědi, zadáním textu do elementu TextArea. Opakem je Uzavřená otázka. Průzkum - Obecný pojem zahrnující konkrétní dotazník a k němu se vázající odpovědi respondentů. Rotace - Objekty, jež mají nastavenou rotaci, se v každém rozhovoru vypíší v náhodném pořadí. Rotace odpovědí Též vnitřní rotace nebo pouze rotace. Rotace jednotlivých odpovědí v rámci jedné otázky. Rotace otázek Též vnější rotace. Rotace celých otázek. Předpokládá se, že otázky budou umístěny na stejné straně dotazníku.
Rozhovor - Dotazník vyplněný jedním respondentem. Jeden dotazník může obsahovat mnoho rozhovorů. Jeden rozhovor obsahuje všechny odpovědi na dotazník od jednoho respondenta a obecné informace o rozhovoru (čas rozhovoru, délku trvání rozhovoru ad.). Respondent - Uživatel, účastnící se průzkumu a tedy vyplňující dotazník. Scale - Typ otázky. Též Sémantický diferenciál (v práci není použito). Respondent vybírá odpověď na určité předem definované škále. Single-choice - Typ otázky Otázka sestávající se z elementů Radio button nebo rozbalovacího seznamu. V aplikaci se tento typ otázky nazývá Právě jedna odpověď, ve zdrojových kódech je použit výraz Single-choice. Respondent může zvolit nejvýše jednu odpověď. Staging server - Též staging site. Webový server, používaný pro otestování webové aplikace. Aplikace je před ostrým nasazením spuštěna na staging serveru, kde může být testován její provoz bez rizik spojených s nasazením do ostrého provozu. Typ otázky - Každá otázka v dotazníku je určitého typu, který definuje strukturu otázky, způsob odpovědi na otázku, zpracování otázky a její uložení do databáze. Uzavřená otázka - Otázka, která nemá možnost otevřené odpovědi, zadáním textu do elementu TextArea. Odpověď na takovou otázku je tedy přesně definovaná a jednotná.
53
A.2. POJMY
54
PŘÍLOHA B. ADRESÁŘOVÁ STRUKTURA PŘILOŽENÉHO CD
Příloha B
Adresářová struktura přiloženého CD
Obrázek B.1: Adresářová struktura přiloženého CD Na přiloženém CD je v adresáří dokumentace/EA přiložen projekt programu Enterprise Architect v.7, ve kterém byla vytvořena veškerá dokumentace k aplikaci (databázový model, případy užití, analytický model a návrhový model). V adresáři text je, dle pokynů pro zpracování bakalářských prací na katedře počítačů ČVUT [1], umístěna elektronická verze této práce ve formátu PDF. V adresáři LaTeX je text práce ve zdrojovém formátu LaTeX. Obsah podadresářů adresáře LaTeX: • appendices - přílohy • bib - použitá literatura ve formátu BibTeX • chapters - jednotlivé kapitoly práce • img - použité obrázky • macro - šablona pro psaní bakalářských prací, doporučená katedrou počítačů ČVUT
55
56
PŘÍLOHA C. DOKUMENTACE - DATABÁZOVÝ MODEL
Příloha C
Dokumentace - Databázový model Zde je ve dvou diagramech uvedena kompletní struktura použité databáze. Pod každým diagramem je podrobný popis všech atributů. Mohou být uvedeny tyto údaje: • Datový typ atributu. Může nabývat těchto hodnot: Integer VarChar(MAX_DELKA) DateTime
• Povinnost atributu (Null nebo Not Null) • Unikátnost atributu (Unique) Dále může být uveden význam atributu. Je-li význam zcela zřejmý z názvu atributu, je vynechán. Všechny tabulky obsahují atribut id, který je primárním klíčem a je tedy unikátní a nenulový. Je autoinkrementační. V popisu není pro větší přehlednost uváděn. Některé atributy jsou momentálně nevyužité. Jedná se o atributy s jejichž využitím se počítá v budoucnu. Je tedy výhodné předpřipravit je do databáze, zejména díky následné snazší implementaci funkcionalit, které je budou využívat.
57
Obrázek C.1: Datový model 1 Obr. C.1 - popis atributů: • ucet_aktivovan klient_id Integer Not Null, Primary Key date DateTime Not Null - datum aktivování účtu. První datum aktivování daného účtu = datum založení účtu.
• ucet_deaktivovan klient_id Integer Not Null, Primary Key date DateTime Not Null - datum deaktivování účtu. Je-li poslední datum deaktivování novější, než poslední datum aktivování, účet je deaktivovaný.
58
PŘÍLOHA C. DOKUMENTACE - DATABÁZOVÝ MODEL
• prihlaseni klient_id Integer Not Null date DateTime Not Null - datum přihlášení. ip VarChar(255) Null - IP adresa, ze které bylo provedeno přihlášení. user_agent VarChar(2000) Null - Pužitý webový prohlížeč, obsah PHP proměnné $_SERVER[’HTTP_USER_AGENT’] referer VarChar(2000) Null - Adresa, ze které návštěvník přišel, obsah PHP proměnné $_SERVER[’HTTP_REFERER’]. Je-li atribut nulový, návštěvník zadal adresu stránky přímo do adresního řádku webového prohlížeče. display_resolution VarChar(255) Null - Rozlišení monitoru, získané při přihlašování pomocí JS.
• klient email VarChar(255) Not Null Unique login VarChar(63) Not Null Unique password VarChar(255) Not Null Unique - SHA1 hash přístupového hesla. first_name VarChar(255) Null last_name VarChar(255) Null city VarChar(255) Null street VarChar(255) Null street_nr Integer Null post_code Integer Null telephone VarChar(255) Null Unique - Je ukládán jako VarChar kvůli předčíslí, které může obsahovat „+“. company VarChar(2000) Null - Společnost klienta. admin_note VarChar(2000) Null - Poznámka administrátora ke klientovi, kterou vidí a může měnit pouze administrátor. is_admin Integer Null - 1 bitový atribut udávající, zda má tento klient administrátorská práva (0, Null=Ne, 1=Ano). email_subject VarChar(255) Null - Předmět emailu, který klient rozesílá respondentům jako výzvu k vyplnění dotazníku. email_text VarChar(2000) Null - Text emailu, který klient rozesílá respondentům jako výzvu k vyplnění dotazníku. Obsahuje položky „“ a „“, které jsou při rozeslání nahrazeny adresou dotazníku a přístupovým heslem respondenta.
• dotaznik klient_id Integer Not Null date DateTime Not Null - Datum vytvoření dotazníku. name VarChar(255) Not Null - Název dotazníku. published Integer Not Null - 1 bitový atribut udávající, zda byl dotazník publikován - rozeslán respondentům (0=Ne, 1=Ano). web_page VarChar(2000) Null - Momentálně nepoužito. Webová adresa dotazníku. V současné implementaci mají všechny dotazníky jednotnou adresu, lišící se pouze PHP GET parametrem dotaznik_id. background_color VarChar(255) Null - Barva pozadí celého dotazníku. q_bg_color VarChar(255) Null - Barva pozadí všech otázek. q_title_font VarChar(255) Null - Typ písma textu otázky. q_title_fontsize VarChar(255) Null - Velikost písma textu otázky. q_subtitle_font VarChar(255) Null - Typ písma upřesnění otázky. q_subtitle_fontsize VarChar(255) Null - Velikost písma upřesnění otázky. q_choice_font VarChar(255) Null - Typ písma textu odpovědi na otázku. q_choice_fontsize VarChar(255) Null - Velikost písma textu odpovědi na otázku. intro VarChar(2000) Null - Úvodní text dotazníku.
59
intro_font VarChar(255) Null - Typ písma úvodního textu dotazníku. intro_fontsize VarChar(255) Null - Velikost písma úvodního textu dotazníku. outro VarChar(2000) Null - Závěrečný text dotazníku. outro_font VarChar(255) Null - Typ písma závěrečného textu dotazníku. outro_fontsize VarChar(255) Null - Velikost písma závěrečného textu dotazníku. path_to_logo VarChar(2000) Null - Momentálně nepoužito. Adresa a název loga, umístěného v záhlaví dotazníku. name_bg_color VarChar(255) Null - Barva pozadí názvu dotazníku. intro_bg_color VarChar(255) Null - Barva pozadí úvodního textu dotazníku. outro_bg_color VarChar(255) Null - Barva pozadí závěrečného textu dotazníku.
• respondent klient_id Integer Not Null password VarChar(255) Not Null Unique - Přístupové heslo. Není použit hash - je nutné umožnit rozesílání hesla respondentům. date DateTime Not Null - Datum přidání respondenta. email VarChar(255) Null first_name VarChar(255) Null - Momentálně nepoužito. last_name VarChar(255) Null - Momentálně nepoužito. note VarChar(2000) Null - Momentálně nepoužito. Poznámka klienta k respondentovi.
• rozhovor date DateTime Not Null - Datum vytvoření rozhovoru = datum přidání respondenta k dotazníku, ke kterému patří tento rozhovor. finished Integer Not Null - 1 bitový atribut udávající, zda byl dotazník již vyplněn = respondent zodpověděl všechny povinné otázky a potvrdil odeslání dotazníku na poslední stránce (0=Ne, 1=Ano). K rozhovoru s finished=1 respondent nemůže dále přistupovat. start_time DateTime Null - Čas prvního přihlášení respondenta k tomuto dotazníku. end_time DateTime Null - Čas ukončení vyplňování dotazníku. Nastavuje se najednou s atributem finished. empty Integer Null - Rozhovor je prázdný, nepatří žádnému respondentovi. Každý dotazník má 1 prázdný rozhovor pro testování klientem. dotaznik_id Integer Not Null respondent_id Integer Not Null
• prihlaseni_respondent date DateTime Not Null - datum přihlášení. ip VarChar(255) Null - IP adresa, ze které bylo provedeno přihlášení. user_agent VarChar(2000) Null - Použitý webový prohlížeč, obsah PHP proměnné $_SERVER[’HTTP_USER_AGENT’] referer VarChar(2000) Null - Adresa, ze které návštěvník přišel, obsah PHP proměnné $_SERVER[’HTTP_REFERER’]. Je-li atribut nulový, návštěvník zadal adresu stránky přímo do adresního řádku webového prohlížeče. display_resolution VarChar(255) Null - Rozlišení monitoru, získané při přihlašování pomocí JS. rozhovor_id Integer Not Null - Id rozhovoru, ke kterému se respondent přihlásil. Přes tento rozhovor lze zjistit id respondenta.
• odpoved rozhovor_id Integer Not Null - Id rozhovoru, ke kterému patří tato odpověď. answer_id Integer Not Null - Id odpovědi na otázku. answer_type VarChar(255) Not Null - Typ odpovědi na otázku. Př.: check_box, radio_button, otevrena_odpoved. odpoved_text VarChar(2000) Null - Odpověd zvolená respondentem. U answer_type check_box a radio_button znamená hodnota „1“ zatržení příslušného Check boxu nebo Radio buttonu.
60
PŘÍLOHA C. DOKUMENTACE - DATABÁZOVÝ MODEL
Obrázek C.2: Datový model 2 Obr. C.2 - popis atributů: • otazka dotaznik_id Integer Null type VarChar(255) Not Null - Typ otázky (např. Otevřená otázka, Multiple-choice, Scale). title VarChar(2000) Not Null - Text otázky. mandatory Integer Not Null - 1 bitový atribut udávající, zda je otázka povinná (0=Ne, 1=Ano). page Integer Not Null - Strana dotazníku, na které je umístěna tato otázka. post Integer Not Null - Pozice otázky v dotazníku (první otázka má pozici 1). subtitle VarChar(2000) Null - Upřesnění otázky. vnitrni_rotace Integer Null - 1 bitový atribut udávající, zda jednotlivé odpovědi na otázku náhodně mění pořadí při každém zobrazení otázky (0=Ne, 1=Ano). position Integer Null - Prostorová pozice otázky vůči předchozí otázce. Nabývá hodnot 2 a 6, které odpovídají pozicím čísel 2 a 6 na numerické klávesnici. Hodnota 2 = umístění otázky pod předchozí otázkou. 6 = umístění vpravo od předchozí otázky. columns Integer Null - Počet sloupců, do kterých budou vypsány jednotlivé odpovědi na otázku. show_if_condition Integer Null - 1 bitový atribut udávající, zda se má otázka zobrazit, jsou-li splněny podmínky přiřazené k této otázce (0=Ne, 1=Ano).
61
vnejsi_rotace_id Integer Null
• check_box otazka_id Integer Null text VarChar(2000) Not Null - Text, zobrazovaný u Check boxu.
• radio_button otazka_id Integer Null text VarChar(2000) Null - Text, zobrazovaný u Radio buttonu. Může být nulový - např. u otázky typu Scale nemusí být popisky u všech možností.
• otevrena_odpoved otazka_id Integer Null text VarChar(2000) Null - Text, zobrazovaný nad HTML elementem TextArea pro otevřenou odpověď. Může být nulový - obsahuje-li otázka pouze jednu otevřenou odpověď, popisek není povinný.
• podminka otazka_id Integer Not Null precondition_id Integer Not Null - Id podmiňující otázky. answer_id Integer Not Null - Id odpovědi na otázku. answer_type VarChar(255) Not Null - Typ odpovědi na otázku. Př.: check_box, radio_button, otevrena_odpoved. Vybere-li respondent odpověď na podmiňující otázku typu [answer_type] s id [answer_id], je podmínka splněna. isEqual Integer Not Null - 1 bitový atribut udávající, zda je podmínka splněna pokud respondent zvolí na podmiňující otázku odpověď, která tvoří podmínku (tzn. odpověď typu [answer_type] s id [answer_id]) (0=Ne, 1=Ano). connector VarChar(255) Null - Logická spojka, spojující tuto a případnou předchozí podmínku otázky. Nabývá hodnot „AND“ a „OR“.
62
PŘÍLOHA D. DOKUMENTACE - PŘÍPADY UŽITÍ
Příloha D
Dokumentace - Případy užití Diagramy zahrnují všechny základní případy užití aplikace. Pod každým diagramem jsou jednotlivé případy užití podrobněji rozepsány.
Obrázek D.1: Uživatelské role • Respondent Může pouze vyplňovat existující dotazníky.
• Klient Může vytvářet, prohlížet a editovat dotazníky. Může rozesílat dotazníky respondentům. Může editovat svůj profil.
• Administrátor
63
Může přidávat klienty. Může editovat, aktivovat a deaktivovat klienty. Může vše co klient.
Obrázek D.2: Správa klientů • Přidat Klienta Administrátor zadá přihlašovací jméno Klienta a jeho email. Administrátor může vyplnit poznámku ke Klientovi, kterou vidí pouze Administrátor. Systém vygeneruje Klientovi heslo a odešle ho na email. Systém vypíše hlášku o úspěšném přidání Klienta a opět zobrazí stránku pro přidání Klienta.
• Editovat Administrátor zvolí možnost Edit v seznamu Klientů nebo klikne na Klienta v seznamu Klientů. Systém vypíše údaje z profilu Klienta, především: - login - jméno a příjmení - email
64
PŘÍLOHA D. DOKUMENTACE - PŘÍPADY UŽITÍ
-
firmu adresu telefon datum založení účtu data deaktivování a aktivování účtu datum posledního přihlášení Klienta počet dotazníků Klienta celkem počet Respondentů na Klientovy dotazníky celkem název a čas naposledy vyplněného dotazníku
• Změnit údaje Klienta Administrátor může změnit: -
email Klienta jméno a příjmení Klienta firmu adresu Klienta telefon Klienta
Administrátor může smazat heslo Klienta a vygenerovat nové. Po potvrzení změn systém odešle informační email Klientovi.
• Změnit poznámku u Klienta Administrátor může u Klienta změnit poznámku, kterou vidí pouze on.
• Aktivovat Klienta Po potvrzení systém uloží do databáze datum a čas aktivování účtu. V seznamu Klientů je Klient barevně označen jako aktivovaný.
• Deaktivovat Klienta Po potvrzení systém uloží do databáze datum a čas deaktivování účtu. V seznamu Klientů je Klient barevně označen jako deaktivovaný.
• Zobrazit Správu dotazníků Klienta Systém zobrazí menu Klienta pro Správu dotazníků.
65
Obrázek D.3: Systémové menu klienta Obrázek D.3 popisuje menu, které klient uvidí na levé straně stránky. Po přihlášení systém automaticky zobrazí stránku Správa dotazníků. • Detail účtu Zobrazí detaily o účtu Klienta - zejména: -
login jméno a příjmení email firmu adresu telefon datum založení účtu data deaktivování a aktivování účtu datum posledního přihlášení Klienta počet dotazníků Klienta celkem počet Respondentů na Klientovy dotazníky celkem název a čas naposledy vyplněného dotazníku
• Změnit heslo Klient může změnit své heslo. Je nutné zadat původní heslo.
66
PŘÍLOHA D. DOKUMENTACE - PŘÍPADY UŽITÍ
• Změnit osobní údaje Klient může změnit následující osobní údaje: -
jméno a příjmení email firma adresa telefon
• Přehled Zobrazí stránku Správu dotazníků Klienta.
• Správa dotazníků viz diagram D.4
• Odhlásit se Odhlásí Klienta ze systému.
67
Obrázek D.4: Správa dotazníků • Vytvořit nový dotazník Zobrazí formulář pro vytvoření nového dotazníku. Klient zadá název nového dotazníku a poté bude přesměrován na stránku Editovat dotazník.
• Editovat dotazník Otevře stránku Editace dotazníku. Viz diagram D.5
• Rozeslat dotazník Otevře stránku Rozeslání dotazníku. Viz diagram D.6
• Zobrazit dotazník Zobrazí náhled dotazníku tak, jak ho vidí Respondent. Nad dotazníkem je menu s tlačítkem Zpět pro návrat do správy dotazníků. Odpovědi na otázky se ukládají do databáze pro kontrolu funkčnosti definovaných podmínek.
• Zobrazit výsledky dotazníku Otevře stránku s výsledky dotazníku. Na stránce s výsledky je: - statistické shrnutí návštěvnosti dotazníku zahrnující: - datum vytvoření dotazníku - počet Respondentů celkem - počet Respondentů, kteří dokončili vyplňování dotazníku - průměrný čas vyplňování dotazníku - název a čas naposledy vyplněného dotazníku - možnost exportu dat - výsledky jednotlivých otázek dotazníku
68
PŘÍLOHA D. DOKUMENTACE - PŘÍPADY UŽITÍ
Obrázek D.5: Editovat dotazník • Změnit obecné parametry dotazníku V sekci Obecné parametry Klient může změnit: -
název dotazníku barvu pozadí dotazníku, intra, outra, otázek, názvu dotazníku font otázek, odpovědí, intra, outra logo v záhlaví
• Změnit Intro Klient změní intro dotazníku.
• Změnit Outro Klient změní outro dotazníku.
• Přidat otázku Vytvoří novou otázku. U otázky Klient nastavuje tyto parametry: -
Typ otázky Pozice otázky v dotazníku Povinnost otázky Vnitřní rotace Text otázky Upřesnění otázky Jednotlivé odpovědi na otázku Podmínky Umístění otázky vůči předchozí (pod / vpravo)
69
- Vnější rotaci - Fonty - Barvu pozadí
• Editovat otázku Klient zvolí Editovat u vybrané otázky. Klient má stejné možnosti jako u Přidání otázky ale nelze změnit typ otázky.
• Smazat otázku Klient zvolí Smazat u vybrané otázky. Systém požádá o potvrzení, poté vymaže otázku z databáze.
Obrázek D.6: Rozeslat dotazník • Editovat Respondenty Aktualizuje v databázi seznam emailů pro oslovení Respondentů. Klient může přidat emaily nebo smazat již přidané emaily.
• Změnit email Klient změní text emailu s výzvou k vyplnění dotazníku, rozesílaného Respondentům.
• Rozeslat email Rozešle email s výzvou k vyplnění dotazníku všem respondentům, přiřazeným k tomuto dotazníku. Dotazník má 2 stavy: - dosud nerozeslaný dotazník je podbarven žlutě - rozeslaný dotazník je podbarven zeleně
70
PŘÍLOHA E. DOKUMENTACE - NÁVRHOVÝ MODEL
Příloha E
Dokumentace - Návrhový model V této příloze jsou uvedeny UML2 diagramy nejdůležitějších tříd aplikace. Vysvětlivky: + (plus) Veřejný atribut nebo metoda (public) - (mínus) Privátní atribut nebo metoda (private) Podtržení Statický atribut metoda
Třídy Klient, Respondent, Rozhovor (obr. E.2 ), Otazka a Dotaznik (obr. E.3 ) mají dále veřejné settery a gettery pro všechny své atributy (pro větší přehlednost nejsou uvedeny). Ty jsou použity ke čtení i nastavování všech atributů těchto tříd v celé aplikaci. Některé metody tříd Prikazy a Prikazy_otazka vrací podle diagramů objekty (např. Dotaznik, Respondent, Otazka) nebo pole těchto objektů. Ve skutečnosti vrací pole dat, získaných z databáze a objekt se nad tímto polem vytvoří až v jejich obsluhující třídě (Klient_manager apod., viz podkapitola 3.4.2). Pro větší přehlednost jsou v diagramech uvedeny názvy objektů, které jsou nad polem vytvářeny. V některých případech je také jako návratový typ uveden název tabulky, ze které data pochází.
71
Obrázek E.1: Návrhový model 1
72
PŘÍLOHA E. DOKUMENTACE - NÁVRHOVÝ MODEL
Obrázek E.2: Návrhový model 2
73
Obrázek E.3: Návrhový model 3
74
PŘÍLOHA F. DOKUMENTACE - ADRESÁŘOVÁ STRUKTURA
Příloha F
Dokumentace - Adresářová struktura
Obrázek F.1: Adresářová struktura Celá aplikace je umístěna v adresáři smarty (lze libovolně přejmenovat). Adresáře cache, configs, plugins, smarty a templates_c jsou systémové adresáře Smarty. Adresář smarty obsahuje jádro šablonovacího systému, v adresáři templates_c jsou přeložené stránky, sestavené Smarty z HTML souborů a k nim příslušejících skriptů. V kořenovém adresáři jsou umístěny všechny PHP skripty obsluhující jednotlivé stránky (mají vždy název začínající malým písmenem) a všechny PHP soubory obsahující PHP třídy (názvy začínají velkým písmenem). Názvy skriptů, které zajišťují komunikaci pomocí AJAX technologie, začínají prefixem „ajax_“. V adresáři templates jsou umístěny veškeré soubory obsahující HTML kód aplikace, js obsahuje JavaScriptové skripty a styly obsahuje složky s různými skiny aplikace. V současnosti má aplikace pouze jeden skin, umístěný v adresáři default. V něm je soubor s CSS styly a všechny obrázky.
75
76
PŘÍLOHA G. DOKUMENTACE - PŘIDÁNÍ OTÁZKY
Příloha G
Dokumentace - Přidání otázky V této příloze jsou popsány kroky potřebné pro přidání nového typu otázky do aplikace. Je zde používán termín „komponenta otázky“. Termín zahrnuje tabulky odpovědí na otázky (např. radio_button nebo check_box) i případné tabulky s dodatečnými atributy otázky, tak jak je popsáno v podkapitole 3.2.2. Obecně řečeno je komponentou libovolný objekt (tabulka), který je třeba pro sestavení otázky. Pozn.: V souboru ajax_otazky.php by bylo možné zmenšit délku kódu, neboť momentálně mají všechny otázky společně parametry, které se přitom ošetřují u každé zvlášť (v konstrukci switch, která je dominantní součástí skriptu ajax_otazky.php). Pokud by ale v budoucnu přibyly nestandardní typy otázek, bylo by nutné celý skript předělat. Zpracování každé otázky zvlášť také přispívá k větší přehlednosti kódu. Změny, které je nutno provést při přidání nového typu otázky: • Přidat do databáze případné nové komponenty otázky. • Přidat do třídy Otazka_writer do metody write() volání metod pro výpis nového typu otázky a ve stejné třídě doplnit tyto metody. • Přidat do Prikazy_otazka.php metodu getAll_[Nova_komponenta](), pokud byly nové komponenty vytvořeny - použije se např. v Otazka_writer.php. • Přidat do Prikazy_otazka.php metodu deleteAll_[Nova_komponenta](), pokud byly nové komponenty vytvořeny - použije se např. při smazání otázky v Otazka_manager::deleteOtazka(). • Přidat do Prikazy_otazka.php metodu get[Nova_komponenta](), pokud byly nové komponenty vytvořeny - použije se např. v Otazka_writer.php, otazky_edit.php. • Přidat do Prikazy_otazka.php metodu edit[Nova_komponenta](), pokud byly nové komponenty vytvořeny - použije se např. v Otazka_manager::editAnswer(). • Přidat do Prikazy_otazka.php metodu deleteUnused_[Nova_komponenta](), pokud byly nové komponenty vytvořeny - použije se např. v Otazka_manager::deleteUnused_answers() (volá se při editaci otázky).
77
• V metodě Otazka_manager::deleteUnused_answers() doplnit do switche smazání nové komponenty, byla-li vytvořena. • V metodě Otazka_manager::editAnswer() doplnit do switche editaci nové komponenty, byla-li vytvořena. • V metodě Otazka_manager::getAll_answers() přidat prohledávání nového typu otázky - tuto metodu využívá např. ajax_otazky.php pro nalezení všech možností odpovědi při editaci otázky, otazky_edit.php a Otazka_writer.php. • V metodě Otazka_manager::deleteOtazka() přidat do switche nový typ otázky a doplnit vše, co je nutné smazat pro smazání otázky tohoto typu. • V metodě Otazka_manager::getAnswer_by_type() přidat do switche nový typ otázky - tuto metodu využívají např. otazky_edit.php a Otazka_writer.php při vyhodnocování a nastavování podmínek. • V metodě Otazka_manager::addAnswer() doplnit do switche přidání nového typu odpovědi, byl-li vytvořen. Doplnit také způsob přidání nového typu odpovědi do databáze, nelze-li použít univerzální Prikaz.php -> addAnswer(). • V metodě Otazka_manager::getOtazka_types() přidat název nové otázky do výsledného pole ve formátu [název ot. v databázi] => [zobrazovaný název]. • V metodě Otazka_manager::getAll_odpoved() (vrátí všechny odpovědi na otázku) přidat prohledávání nových komponent otázky, byly-li vytvořeny. • V common_functions.php v metodě check_one_condition() přidat kontrolu, zda byla vyplněna podmiňující odpověď, pokud byl vytvořen nový typ odpovědi, který v případě nezvolení nemá hodnotu null nebo 0 (v opačném případě stačí doplnit nový typ odpovědi do již existující možnosti switche). • V metodě research_out.php->research_done() přidat kontrolu, zda byla otázka zodpovězena, pokud byla vytvořena komponenta otázky, která v případě nezvolení nemá hodnotu null nebo 0 (v opačném případě stačí doplnit nový typ odpovědi do do již existující možnosti switche), podobně jako v common_functions.php v metodě check_one_condition(). • V ajax_otazky.php doplnit do switche kontrolu a uložení nového typu otázky. • V ajax_submit.php v metodě check_filled() doplnit do switche kontrolu vyplnění nového typu otázky. • V ajax_submit.php v metodě safe_answers() doplnit do switche uložení nového typu otázky do databáze. • V otazky_edit.html doplnit na konec souboru formulář pro editaci daného typu otázky. Je možné použít pro editaci více typů otázek pouze jeden formulář a ten případně vždy mírně upravit v js/JSinquiry.js ve funkci show_edit_question(), tak jako to již je pro otázky single_choice, multi_choice a vlastnimi_slovy (všechny tři používají stejný formulář pro editaci otázky).
78
PŘÍLOHA G. DOKUMENTACE - PŘIDÁNÍ OTÁZKY
• V js/JSinquiry.js ve funkci show_edit_question() doplnit do switche, který formulář pro editaci otázky se má na otazky_edit.html zobrazit, případně v něm provést potřebné změny je-li společný pro více otázek, tak jako to již je pro otázky single_choice, multi_choice a vlastnimi_slovy. • V js/JSinquiry.js ve funkci edit_question() doplnit switch o nový typ otázky - doplnit do jakého formuláře se mají zkopírovat hodnoty otázky ze stránky. Současné typy otázek a jejich možné komponenty: (jsou použity termíny ze zdrojových kódů) Typ otázky otevrena_otazka single_choice multiple_choice
Možné komponenty otevrena_odpoved radio_button, otevrena_odpoved check_box, otevrena_odpoved
79
80
PŘÍLOHA H. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
Příloha H
Instalační a uživatelská příručka H.1
Instalační příručka
V kořenovém adresáři aplikace (viz příloha F) v souboru Database.sql jsou SQL příkazy pro vytvoření všech potřebných tabulek. Ve stejném adresáři v souboru insertion.sql jsou SQL příkazy pro vytvoření několika uživatelů a dotazníku pro testovací účely. Pro připojení k databázi je nutné ve třídě Databaze v souboru Databaze.php v metodě setDatabaseHost() nastavit parametry pro připojení k databázi a v konstruktoru téže třídy zvolit, které z přednastavených připojení se má použít. Všechny URL adresy v aplikaci jsou zadané relativně, kořenový adresář je možné libovolně přemístit či přejmenovat. Aplikace funguje pod standardním nastavením PHP prostředí, nemělo by tedy být třeba provádět jakékoli změny v natavení.
H.2
Uživatelská příručka
Aplikace poskytuje tři druhy uživatelských účtů: administrátorský účet, klientský a účet respondenta. Účet respondenta umožňuje pouze vyplnit dotazník, uživatelská příručka pro tento účet proto není potřeba. Administrátorský účet umožňuje oproti klientskému účtu navíc pouze vytváření a (de)aktivování klientů. Administrátorský účet může být v současné implementaci pouze jeden. Bylo by neefektivní vytvářet uživatelskou příručku pouze pro jednoho uživatele. Budu se proto zabývat pouze klientským účtem. H.2.1 Klientský účet Po přihlášení do aplikace se v levé části stránky zobrazí systémové menu a nad ním informace o právě přihlášeném uživateli (obr. H.1).
81
H.2. UŽIVATELSKÁ PŘÍRUČKA
Možnosti menu: • Přehled - přejde na hlavní stranu aplikace s přehledem všech dotazníků (viz H.2.1.1) • Detail účtu - přejde na stranu Detail účtu (viz H.2.1.2) • Odhlásit se - odhlásí uživatele ze systému
Obrázek H.1: Menu H.2.1.1
Přehled
Na této straně je zobrazena tabulka s přehledem dotazníků (obr. H.2). Dotazníky, které již byly rozeslány respondentům, jsou v dolní části tabulky a jsou podbarveny zeleně. Dosud nerozeslané jsou podbarveny žlutě. Zda byl dotazník rozeslán indikuje také sloupec Rozeslán.
Obrázek H.2: Přehled dotazníků (1) Nový dotazník - Zobrazí okno pro zadání názvu nového dotazníku. Poté přesměruje aplikaci na stranu editace dotazníku (viz H.2.1.3). (2) - Kliknutím na název dotazníku se zobrazí náhled dotazníku tak, jak ho vidí respondent. (3) - Přejde na stranu editace dotazníku (viz H.2.1.3). (4) - Přejde na stranu rozeslání dotazníku respondentům (viz H.2.1.5). (5) - Zobrazí výsledky průzkumu. Vypíše obecné informace o proběhlém průzkumu a výsledky jednotlivých otázek (viz H.2.1.6). H.2.1.2
Detail účtu
Na této straně jsou informace o účtu a jeho majiteli. Aplikace vypíše datum založení účtu a datum posledního přihlášení. V tabulce Osobní údaje je možné změnit osobní údaje jako Jméno a Příjmení, Telefon, Firmu apod. V tabulce Změna hesla je možné změnit heslo k účtu. Je nutné zadat původní heslo.
82
PŘÍLOHA H. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
H.2.1.3
Editace dotazníku
Obrázek H.3: Editace dotazníku Na straně Editace dotazníku (obr. H.3) lze změnit obecné parametry dotazníku. (1) - Vlevo nahoře je zobrazeno číslo aktuální strany dotazníku. Jednotlivé otázky začínají na straně 2. (2) - Vpravo nahoře je datum vytvoření dotazníku. (3), (4), (5) - Volby pro změnu názvu dotazníku, intra (tzn. textu, který bude respondentovi zobrazen v úvodu dotazníku) a outra (text, který bude zobrazen na konci dotazníku). Po stisknutí tlačítek (5) se zobrazí formulář pro změnu zvolené položky a tlačítka Uložit a Storno. (6) - Umožňuje změnit barvy jednotlivých částí dotazníku. Po vybrání požadované barvy z rozbalovacího seznamu je nutné potvrdit změnu stisknutím tlačítka Uložit! (7) - Umožňuje změnu typu písma určité části dotazníku. Po kliknutí myší zobrazí rozbalovací seznam s náhledem různých typů písem. (8) - Umožňuje změnu velikosti písma určité části dotazníku. Po kliknutí myší zobrazí rozbalovací seznam s náhledem různých velikostí písem. Po vybrání typu a velikosti písma požadované části dotazníku je nutné změny potvrdit stisknutím tlačítka Uložit! Zcela dole na stránce editace dotazníku je tlačítko Přejít na editaci otázek pro přechod na stranu editace otázek.
83
H.2. UŽIVATELSKÁ PŘÍRUČKA
H.2.1.4
Editace otázek
Na straně pro editaci otázek je možné vytvářet, editovat a mazat jednotlivé otázky dotazníku.
Obrázek H.4: Editace parametrů otázky (1) - Veškeré změny provedené na této straně je nutné potvrdit tlačítkem Uložit v dolní nebo horní části stránky. Provedené změny je možné zrušit tlačítkem Reset. Byly-li na stránce provedeny změny, které vyžadují uložení, jsou všechny otázky červeně zvýrazněny. Aplikace také upozorní při odchodu ze stránky na neuložené změny a umožní odchod zrušit (nefunguje v prohlížeči Opera). (2) - V horní i dolní části stránky jsou umístěna tlačítka pro přechod na předchozí a následující stranu dotazníku. (3) - Umožňuje změnit pozici otázky v rámci aktuální strany dotazníku (volba je deaktivována byl-li zvolen přesun na jinou stranu - viz (5) ). (4) - Nastavení umístění otázky vůči předchozí otázce. Každou otázku je možné umístit pod předchozí nebo vedle předchozí. Otázku není možné umístit vedle předchozí otázky, je-li tato již umístěna vedle předchozí. (5) - Při zaškrtnutí zpřístupní rozbalovací seznam pro přesun otázky na jinou stranu. (6) - Umožňuje přesun otázky na jinou stranu dotazníku. Při výběru poslední položky (s poznámkou „Nová strana“) je vytvořena nová strana na konci dotazníku a otázka je na ni přesunuta. (7) - Při zaškrtnutí zpřístupní nastavení podmínek otázky. Pokud jsou podmínky nastaveny a dojde k vyškrtnutí políčka, všechny natavené podmínky se při uložení změn vymažou. Při nastavování podmínek je možné změnit: • Zobrazení otázky, je-li podmínka splněna. V rozbalovacím seznamu je možné zvolit Zobrazit nebo Skrýt otázku, jsou-li podmínky splněny. • Podmiňující otázku - tzn. otázku, jejíž odpověď tvoří podmínku. Lze zvolit v rozbalovacím seznamu vedle textu „odpověď na otázku“.
84
PŘÍLOHA H. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
• Negaci - v rozbalovacím seznamu vedle výběru podmiňující otázky lze zvolit možnost „rovná se“ nebo „nerovná se“. Je-li zvolena možnost „nerovná se“, podmínka je považována za splněnou, pokud odpověď na podmiňující otázku NENÍ rovna podmiňující odpovědi. • Podmiňující odpověď - odpověď na podmiňující otázku. Zvolí-li respondent tuto odpověď na podmiňující otázku a není nastavena negace (je zvolena možnost „rovná se“), je podmínka splněna. • Logickou spojku - Je-li nastaveno více podmínek (viz (8) ), lze nastavit způsob napojení podmínky na předchozí pomocí logické spojky AND nebo OR. Vyhodnocování více podmínek za sebou se řídí pravidly výrokové logiky - spojka AND má přednost.
Zvolí-li respondent více odpovědí na Podmiňující otázku a mezi nimi i Podmiňující odpověď, je podmínka považována za splněnou. Podmiňující otázka musí být umístěna na libovolné předchozí straně dotazníku, jinak bude podmínka ignorována. Přidanou druhou a další podmínku je možné odstranit stisknutím křížku vedle podmínky. (8) - Stisknutí tlačítka přidat podmínku připojí k otázce novou podmínku. Bude napojena na předchozí logickou spojkou, zvolenou v rozbalovacím seznamu před tlačítkem (spojku lze později kdykoli změnit). (9) - Při zaškrtnutí je otázka povinná. Respondent nemůže pokračovat ve vyplňování dotazníku, dokud na otázku neodpoví. Dotazník je považován za vyplněný odpověděl-li respondent na všechny povinné otázky. (10) - Nastaví vnitřní rotaci otázky. Odpovědi na otázku budou při zobrazení respondentovi vypsány v náhodném pořadí. (11) - Po potvrzení vymaže danou otázku z dotazníku. (12) - Zobrazí formulář pro editaci obsahu otázky (obr. H.5 ). (13) - Při najetí myší nad libovolnou možnost editace parametrů otázky je zobrazena krátká nápověda.
Obrázek H.5: Editace obsahu otázky Vpravo nahoře na straně editace otázek je tlačítko Přidat otázku. Pokud je na aktuální straně alespoň jedna otázka, je pod tímto tlačítkem také tlačítko Přidat otázku na novou
85
H.2. UŽIVATELSKÁ PŘÍRUČKA
stránku. Obě zobrazí nejprve okno pro výběr typu otázky a poté okno editace otázky (obr. H.5). Při výběru možnosti Přidat otázku na novou stránku je nově vytvořená otázka přidána na novou stranu dotazníku. Okno pro editaci otázky je možné vyvolat také stisknutím tlačítka Editovat u již existující otázky. Obrázek H.5: (1) - Pole pro zadání textu otázky. Lze používat HTML tagy. (2) - Zobrazí v novém okně HTML náhled textu otázky. Tlačítko Zavřít(3) náhled skryje. (4) - Pole pro zadání upřesnění otázky (bude vypsáno pod textem otázky). (5) - Tlačítko pro přidání nové odpovědi na otázku. Rozbalovací seznam vedle tlačítka umožňuje výběr typu odpovědi, která bude přidána. (6) - Pole pro text odpovědi na otázku. Přidanou odpověď na otázku lze opět odstranit stisknutím křížku vedle odpovědi (7). (8) - Rozbalovací seznam pro zvolení počtu sloupců, do kterých budou seřazeny jednotlivé odpovědi na otázku. (9) - Umožňuje změnit šířku pole pro text odpovědi (6). Nastavení nemá vliv na výslednou podobu otázky, pouze umožňuje pohodlnější editaci. (10) - Provedené změny je možné uložit příslušným tlačítkem nebo zrušit tlačítkem Storno. Byl-li formulář vyvolán stisknutím tlačítka Přidat otázku nebo Přidat otázku na novou stránku, při stisknutí tlačítka Storno otázka nebude vytvořena. H.2.1.5
Rozeslání dotazníku
Stránka pro rozeslání dotazníku umožňuje správu respondentů, přiřazených k dotazníku a rozeslání emailu s výzvou k vyplnění dotazníku. V poli Emaily respondentů je možné přidávat nebo mazat emaily respondentů. Každý dotazník má svůj unikátní seznam respondentů. V sekci Rozesílaný email je možné změnit předmět a text emailu s výzvou k vyplnění dotazníku, který bude rozeslán respondentům. Email je společný pro všechny dotazníky. Email je možné uložit pro pozdější rozeslání stisknutím tlačítka Uložit email nebo ihned rozeslat stisknutím Rozeslat email. Při volbě rozeslání emailu bude použit předmět a text emailu vyplněný v okamžiku stisknutí tlačítka. Text i předmět bude zároveň uložen. H.2.1.6
Výsledky průzkumu
Na stránce s výsledky průzkumu jsou obecné informace o průzkumu - například počet respondentů, kteří začali vyplňovat dotazník, počet respondentů, kteří dokončili vyplňování dotazníku, průměrný čas vyplňování dotazníku (započítávají se pouze časy menší než 40 minut). Je možné přejít na stránku Výsledky otázek, kde jsou zobrazeny procentuální výsledky jednotlivých otázek dotazníku.
86
Literatura [1] K336 Info — pokyny pro psaní bakalářských prací. https://info336.felk.cvut.cz/clanek.php?id=504, stav ze 4. 5. 2009. [2] European credit transfer and accumulation system (ECTS). http://ec.europa.eu/education/lifelong-learning-policy/doc48_en.htm.
[3] Český Statistický Úřad - vzdělání obyvatelstva 2007. http://czso.cz/csu/2008edicniplan.nsf/t/0E00307430/\protect\T1\textdollarFile/ 14090822.pdf.
[4] Český Statistický Úřad - Statistický zpravodaj 2006. http://www.czso.cz/xl/redakce.nsf/i/E922222FA239AB05C125713F0042B6D1/\protect\ T1\textdollarFile/0306.pdf.
