WEBOVÁ APLIKACE PRO EFEKTIVNÍ KOMUNIKACI MEZI KLIENTEM A GRAFICKÝM DESIGNÉREM

ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY

ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˇ ´ITAC ˇ OVE´ GRAFIKY A MULTIME´DII´ ´ STAV POC U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA

´ APLIKACE PRO EFEKTIVNI´ KOMUNIKACI WEBOVA ´ M DESIGNE´REM MEZI KLIENTEM A GRAFICKY

´ PRA´CE DIPLOMOVA MASTER’S THESIS

AUTOR PRA´CE AUTHOR

BRNO 2014

ˇ ´I KVAPIL Bc. JIR

ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY

ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˇ ´ITAC ˇ OVE´ GRAFIKY A MULTIME´DII´ ´ STAV POC U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA

´ APLIKACE PRO EFEKTIVNI´ KOMUNIKACI WEBOVA ´ M DESIGNE´REM MEZI KLIENTEM A GRAFICKY WEB APPLICATION FOR EFFECTIVE COMMUNICATION BETWEEN CLIENT AND GRAPHIC DESIGNER

´ PRA´CE DIPLOMOVA MASTER’S THESIS

AUTOR PRA´CE

ˇ ´I KVAPIL Bc. JIR

AUTHOR

VEDOUCI´ PRA´CE SUPERVISOR

BRNO 2014

¨ KE, Ph.D. Ing. IGOR SZO

Abstrakt Cílem diplomové práce je vytvořit webovou aplikaci pro efektivní komunikaci mezi klientem a grafickým designérem. Aplikace byla otestována na dostatečném množství uživatelů a na základě tohoto testování byla upravena. Na závěr byly zhodnoceny dosažené výsledky a navržen směr dalšího vývoje. V textu je popsán kompletní postup od analýzy požadavků, přes návrh až po implementaci a testování.

Abstract The main goal of the master’s thesis is to create the web application for effective communication between a client and a designer. The application was tested on a sufficient number of users and it has been modified according to results of performed tests. The text includes future possibilities of development, evaluation of achieved results, analysis of requirements, design, implementation and testing.

Klíčová slova webová aplikace, návrh, testování, implementace

Keywords web application, design, testing, implementation

Citace Jiří Kvapil: Webová aplikace pro efektivní komunikaci mezi klientem a grafickým designérem, diplomová práce, Brno, FIT VUT v Brně, 2014

Webová aplikace pro efektivní komunikaci mezi klientem a grafickým designérem Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením pana Ing. Igora Szökeho Ph.D. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. U částí práce, které nejsou původní jsem vždy uvedl jejich autora. ....................... Jiří Kvapil 28. května 2014

Poděkování Tímto bych rád poděkoval panu Ing. Igoru Szökemu Ph.D. za poskytnuté rady při vypracování diplomové práce.

c Jiří Kvapil, 2014.

Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

Obsah 1 Úvod

3

2 Neformální specifikace aplikace 2.1 Pro koho je tedy aplikace určena? . . . . . . . . . . . . . . . . . . . . . . . .

5 6

3 Analýza požadavků 3.1 Technické požadavky . . . . . . . . . 3.2 Požadavky ze strany graf. designéra 3.3 Požadavky ze strany klienta . . . . . 3.4 Aktéři systému . . . . . . . . . . . . 3.5 Diagram případů užití . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 7 7 8 8 9

4 Návrh aplikace 4.1 Výběr technologií . . . . . . . 4.1.1 HTML . . . . . . . . . 4.1.2 Javascript . . . . . . . 4.2 Výběr PHP frameworku . . . 4.3 Konvence . . . . . . . . . . . 4.4 Hierarchie souborů a adresářů 4.5 Ukládání souborů . . . . . . . 4.6 Sdílení . . . . . . . . . . . . . 4.7 Návrh schéma databáze . . . 4.8 URL . . . . . . . . . . . . . . 4.9 Portfolio . . . . . . . . . . . . 4.10 Layout a design . . . . . . . . 4.11 SEO . . . . . . . . . . . . . . 4.12 Plán . . . . . . . . . . . . . . 4.12.1 1. iterace . . . . . . . 4.12.2 2. iterace . . . . . . . 4.12.3 3. iterace . . . . . . . 4.12.4 4. iterace . . . . . . . 4.12.5 5. iterace . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10 10 10 10 10 12 13 13 14 16 16 17 18 20 20 20 21 21 21 22

. . . .

23 23 25 25 26

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

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

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

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

5 Implementace 5.1 Chybějící funkce frameworku . . . . 5.2 Použitá existující řešení . . . . . . . 5.2.1 Javascript a CSS . . . . . . . 5.2.2 Moduly frameworku Kohana 1

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

6 Testování a úprava aplikace 6.1 Plán testování . . . . . . . . . . . . . . . . . 6.2 Výsledky testování verze 0.1 . . . . . . . . . 6.3 Vyhodnocení výsledků z testování verze 0.1 6.4 Výsledky testování verze 0.2 . . . . . . . . . 6.5 Vyhodnocení výsledků z testování verze 0.2 6.6 Závěrečné vyhodnocení . . . . . . . . . . . . 6.7 Rychlost aplikace . . . . . . . . . . . . . . . 6.7.1 Návrh a implementace zlepšení . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

28 28 29 30 33 33 34 34 35

7 Výsledná aplikace 7.1 Zprovoznění aplikace . . . . . . . . . 7.1.1 Hlavní systémové požadavky 7.1.2 Instalace . . . . . . . . . . . . 7.2 Směr dalšího vývoje . . . . . . . . . 7.2.1 Současné stádium . . . . . . 7.2.2 Scénáře dalšího vývoje . . . . 7.2.3 Rozšíření . . . . . . . . . . . 7.3 Metriky . . . . . . . . . . . . . . . . 7.4 Ukázka aplikace a webová prezentace

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

37 37 37 37 39 39 39 39 40 41

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

8 Závěr

42

A Seznam příloh

45

B ER diagram

46

C Test uživatelského rozhraní

47

D Výsledky testování

49

E Changlog pro verzi aplikace 0.2

53

F Seznam funkcí aplikace

55

G Obsah CD

57

H Náhledy aplikace

58

I

63

Plakat

2

Kapitola 1

Úvod Diplomová práce se zabývá problematikou komunikace designérů s klienty, které jsem se věnoval už v bakalářské práci s názvem Webová aplikace založená na frameworku ASP.NET MVC 3/Razor [1]. V té byla provedena analýza existujících systémů, které mají podobné zaměření nebo se používají v komunikaci designérů s klienty. Dále byla navržena webová aplikace a implementován funkční prototyp. V rámci této práce bude navržena a implementována kompletně funkční aplikace. Ovšem s pozměněnými požadavky a s ohledem na zjištěné nedostatky u vytvořeného prototypu. Hlavním úkolem je, aby byla aplikace otestována na dostatečném množství uživatelů. Na základě zpětné vazby budou odhaleny případné chyby nebo možná zlepšení. Následně bude podle toho aplikace upravena. Na závěr budou zhodnoceny dosažené výsledky a navržen směr dalšího vývoje. Součástí projektu bude i plakát formátu A2 a webová prezentace propagující aplikaci. V následujícím textu si nejprve v kapitole 2, Neformální specifikace aplikace, přiblížíme na co a pro koho přesně aplikace bude. Následuje část 3, Analýza požadavků, ve které rozebereme technické a uživatelské požadavky. Další a velice rozsáhlou kapitolou je Návrh aplikace (4). V té budeme věnovat větší část výběru PHP frameworku a technologií. Navrhneme schéma databáze, ukládání a hierarchii souborů nebo vzhled aplikace. Na závěr této kapitoly naplánujeme vývoj aplikace do několika logicky rozčleněných iterací. Po návrhu bude následovat sekce 5 Implementace popisující nejzajímavější části při programování aplikace. Dozvíme se o funkcích, které nám ve vybraném frameworku chyběly a museli jsme tedy navrhnout a implementovat řešení. Na spoustu jiných problémů jsme naopak mohli použít dostupná existující řešení. Jednou z nejrozsáhlejších částí práce je Testování a úprava aplikace, kapitola 6. Testování bylo jednou z nejdůležitějších částí vývoje naší aplikace. Nejprve jsme testování naplánovali do dvou běhů. Přičemž na základě prvního byla aplikace upravena a vznikla tak její druhá verze. Abychom ověřili správnost změn, provedli jsme opět stejné testování. Vyhodnotili jsme veškeré výsledky uživatelského testování a nemalou část jsme se v této kapitole věnovali zrychlení aplikace. Nakonec jsme spočítali, o kolik se aplikace zrychlila a jaký dopad měly změny na práci uživatelů. V kapitole 7, nazvané Výsledná aplikace, popíšeme, jak aplikaci zprovoznit. Dozvíme se také, jaké jsou požadavky na prostředí, ve kterém má aplikace běžet. Důležitou částí této kapitoly je návrh dalšího vývoje aplikace a v neposlední řadě sekce o metrikách. Zde, kromě klasických metrik jako je počet řádků kódu, uvádíme počet provedených úprav, počet objevených chyb nebo velikost aplikace. Na závěr dodáme odkazy na demoverzi, stažení a 3

další informace. Poté už následuje Závěr a zhodnocení aplikace a celé práce. V přílohách za zmínku stojí plakát, jehož vytvoření bylo dáno zadáním, veškeré výsledky testování, seznam provedených změn v aplikaci, seznam funkcí aplikace nebo její náhledy. Tato práce přímo navazuje na Semestrální projekt. Přebírá z ní kapitoly Neformální specifikace požadavků, Analýza požadavků, Návrh aplikace a část kapitoly Implementace. V těchto kapitolách bylo provedeno pouze několik malých změn, jinak byla převzata doslovně.

4

Kapitola 2

Neformální specifikace aplikace Základním cílem je navrhnout a implementovat aplikaci pro efektivní komunikaci mezi klientem a designérem. V této kapitole si nejprve blíže specifikujeme řešený problém. Při reálné práci designéra se najde spousta opakujících se okamžiků, činností, které by šly vhodným způsobem zefektivnit, zrychlit či zpříjemnit. A přesně takový cíl si klade naše aplikace. Mezi nejčastější nedostatky v takové komunikaci patří: • Cílení přípomínek na konkrétní místa v návrzích (obrázcích). • Celá písemná komunikace není na jednom místě. • Přístup k dokumentům odkudkoli. • Znovupoužitelnost obrázků. • Nepořádek v dokumentech (obrázky, návrhy, apod.). • Sdílení. Cílení připomínek na konkrétní místa v návrzích, jako nejdůležitější požadavek. Mít připomínku přímo v konkrétním místě obrázku, namísto slovního navádění designérovi, nepochybně usnadní práci. Přístup k dokumentům odkudkoli. Pokud nemáte práci v cloudu, musíte vždy mít zařízení, na kterém máte všechna data. Pokud by byla data na vaší webové stránce, není problém ukazovat pak vaši práci na klientově zařízení apod. Znovupoužitelnost obrázků. Když už byl jednou obrázek ukazován klientovi, nabízí se funkce typu vložit obrázek do portfolia“. ” Sdílení. Naprosto zásadní stěžejní rys budoucí aplikace. Důraz na co nejjednodušší sdílení, zaheslované položky, omezení viditelnosti jen pro určité jedince apod. Většina uvedených problémů plyne z nástrojů, které se používají, ale nejsou pro tuto komunikaci primárně vytvořené. Tím nejpoužívanějším nástrojem je e-mail. Klient a designér si vymění desítky e-mailů, mezi ně se pak v e-mailové schránce pletou další, které k tomu nepatří. Historie je též problematická. Portfolio ze stejných souborů použitých v e-mailech je nemožná, apod. Používané nástroje jsou: e-mailová pošta, nebo specializovaná aplikace www.prevue.it. Analýze používaných existujících aplikací/systémů se podrobně zabývá bakalářská práce Webová aplikace založená na frameworku ASP.NET MVC 3/Razor. Zjištěné informace nám poslouží při návrhu naší aplikace.

5

2.1

Pro koho je tedy aplikace určena?

Pokud by byla aplikace použitelná pouze pro profesi grafického designéra, byla by tak jeho použitelnost striktně vymezena a potenciální zákaznická základna by tím zásadně trpěla. Tento systém budou ale moci použivat i jednotlivci či skupiny všech profesí, které mohou svoji práci sdílet s klientem v obrázkové formě. Například tedy interiéroví návrháři, reklamní agentury, architekti, návrháři kuchyní, nábytku, oblečení apod. Aplikace se snaží oslovit především jednotlivce, začínající designéry, nebo menší skupiny. Bude počítáno s podporou více uživatelů, kteří pak budou pod správou uživatele s právy administrátora. Cílem je vytvořit specializovaný systém pro komerční sféru dostupný všem bez velkých nákladů na pořízení. Pro úplnost musíme zmínit, že v následujícím textu budou v komunikaci zmiňováni dva aktéři: klient a grafický designér (nebo obecně návrhář), přičemž pod druhým aktérem si můžeme představit i jiné, již zmíněné, profese.

6

Kapitola 3

Analýza požadavků Analýze požadavků na budoucí aplikaci se opět zabývala bakalářská práce Webová aplikace založená na frameworku ASP.NET MVC 3/Razor. V této kapitole tedy zmíníme bez vysvětlování jen ty nejdůležitější požadavky a podrobněji se budeme věnovat pouze změnám oproti zmíněné práci.

3.1

Technické požadavky

V následujícím seznamu jsou základní technické požadavky na aplikaci: • Webové technologie. • Hlavním kritériem je funkčnost aplikace s ohledem na existující hostingové služby. Druhá položka plyne z požadavku, aby byla aplikace instalovatelná na co nejvíce webových serverů. Bude tedy nutné vybrat takové technologie (programovací jazyk, databázový systém, . . .) aby byly spustitelné na většině existujících serverů, včetně těch zdarma. Právě hostingy poskytované zdarma nám dají největší informace o tom, jaké technologie použít. Ty totiž používají dostupné servery, jazyky, systémy a jako takové jsou nejvíce rozšířené. Pokud by měla být naše nová aplikace poskytována zdarma, je tato symbióza s dalšími takovými systémy logická. Nebude se tedy jednat o centralizovanou webovou aplikaci. Zvolený způsob má několik výhod. Odbourává potřebu starat se o velké množství cizích“ dat. Samotným designérům ” umožňuje s ohledem na jejich webhosting určovat si velikost, nebo počet souborů (narozdíl od webové aplikace www.prevue.it, kde je toto omezeno či zpoplatněno).

3.2

Požadavky ze strany graf. designéra

Následující seznam obsahuje jen nejzajímavější nebo nejdůležitější požadavky. Některé z nich je potřeba hlouběji popsat a budou tedy podrobněji rozebrány v kapitole 4, Návrh aplikace. Z důvodů přehlednosti a větší stručnosti správa“ v následujícím seznamu zahrnuje ” kromě jiných hlavně CRUD operace (create, read, update, delete). Oproti původní verzi odebíráme ze základní verze živou komunikaci v podobě chatu. Její případné navrácení ponecháme až podle ohlasů ze strany uživatelů. Pro aplikaci musíme určit rozumnou míru toho, co v ní bude, samozřejmě s ohledem na čas, který pro její návrh a implementaci máme. A to je hlavní důvod, proč jsme chat odstranili.

7

• Chráněný vstup do systému. • Uspořádanou práci s klienty, projekty, návrhy, soubory, apod. • Správa poznámek (připomínek k návrhům) a komentářů. • Sdílení práce. • Soukromé zprávy. • Oznámení změn. • Změna vzhledu prostředí u konkrétních návrhů. • Možnost vytvoření portfolia. • Statistiky systému. • Modularita.

3.3

Požadavky ze strany klienta

Zde nastává velká změna oproti původnímu konceptu. Bylo navrhováno, že klientovi bude vytvářen plnohodnotný účet a bude si tak moci v systému udržovat jaké projekty si zadal apod. To je opět odstraněno. Hned z několika důvodů. Prvním je stejný jako zmíněný u živé komunikace. Nechceme, aby nám aplikace příliš nabotnala. Druhým důvodem je komplikovaná správa projektů a souborů zapříčeněná skutečností, že nad stejnými soubory by pracovali jak klient, tak i designér. Ovšem naše aplikace je primárně určena pro designéry. Ti si ji budou instalovat do svého webového prostoru. Budou tak mít vše pod vlastní správou a bez limitů, které by s sebou nesla varianta 2. Neboli cetralizovaná aplikace, ve které by si v našem webovém prostoru dělal designér pouze účet a za službu by musel s největší pravděpodobností i platit. • Chráněný vstup do systému. • Přidávání poznámek (připomínek k návrhům). • Přidávání komentářů k jednotlivým návrhům.

3.4

Aktéři systému

To byly tedy rize uživatelské požadavky. Na jejich základě budou vybírány technologie, postupy řešení apod. Analýzou uvedených požadavků jsme zjistili následující aktéry: • Návrhář. • Administrátor. Speciální uživatel s právy stejnými jako má Návrhář. Funkce má ale rozšířené o vytváření dalších návrhářů v rámci jednoho systému. • Klient.

8

3.5

Diagram případů užití

Z nadefinovaných požadavků a zjištěných aktérů systému vytvoříme následující diagram případů užití 3.1. Z důvodů přehlednosti byly do diagramu zahrnuty jen důležité akce. Chybí tak některé akce typu “zobrazení“. Jiné akce byly sdruženy pod jeden obecný případ užití. “Správa“ v sobě nese opět veškeré CRUD akce nebo také v případě projektů akci “Označit projekt jako hotový“ apod.

Správa klientů/projektů/návrhů/poznámek/komentářů/portfolia

Sdílení s klientem

Správa zpráv

Změnit vzhled prostředí u návrhu

Návrhář

Vyhledání klientů/projektů/návrhů

Změnit nastavení systému

Správa návrhářů Administrátor Zobrazení projektů/návrhů

Přidávání poznámek/komentářů Klient Odeslat zprávu návrháři

Obrázek 3.1: Diagram případů užití.

9

Kapitola 4

Návrh aplikace 4.1

Výběr technologií

Výběr technologií bude veden především hlavním požadavkem, tedy funkčnost aplikace vzhledem k dostupným hostingovým službám. Vybrané hlavní technologie jsou PHP, MySQL, HTML, CSS, Javascript. Jedná se o nejpoužívanější1 technologie v oblasti webových aplikací. Tyto jsou funkční na drtivé většině hostingů, včetně těch zdarma. Při výběru jsme se řídili jejich rozšířením tak, aby se případně na vývoji aplikace a jejího rozšiřování v budoucnu mohlo podílet co nejvíce lidí. Důležitým faktorem je i to, aby byla aplikace upravovatelná co největší skupinou lidí. Například aby si každý mohl vytvořit novou šablonu pro své portfolio. A proto je nezbytné použít technologie široce známé. Je to silným argumentem i pro výběr dalších sekundárních technologií, pomocných aplikací nebo modulů.

4.1.1

HTML

Vybraná verze bude HTML5. Aplikace bude vyvíjena pro nejnovější prohlížeče a bude tak plně využívat nejrůznější výhody této verze (např. drag&drop nebo upload více souborů). Stejně tak ale bude kladen důraz na co největší kompatibilitu se staršími verzemi nejpoužívanějších webových prohlížečů. Jejich uživatelé se ovšem budou muset obejít bez některých rysů, které v nich nefungují, např. zmíněný drag&drop.

4.1.2

Javascript

Javascript nebude až na výjimky používán ve své základní podobě, ale použijeme knihovnu, která nám usnadní mnoho práce. Opět vybereme nejpoužívanější, tedy JQuery. Nebudeme mít problém dohledávat existující řešení a moduly. Kromě základních funkcí, jako je práce s DOM od JQuery, očekáváme podporu AJAX.

4.2

Výběr PHP frameworku

Základem aplikace bude nějaký PHP framework. Musíme z nepřeberného množství vybrat právě ten, který nejvíce vyhovuje našim potřebám. Hlavními požadavky jsou MVC architektura, jazyk PHP a podpora MySQL databází. Z nadefinovaných požadavků nyní dokážeme určit důležité rysy a funkce, které musí framework obsahovat. Sestrojili jsme si 1

Statistiky nejpoužívanějších jazyků a knihoven: http://w3techs.com/technologies.

10

tabulku (4.1), která nám přehledně prezetuje jak si vybrané frameworky stojí v porovnání k našim požadavkům. V řádcích budeme kontrolovat jednotlivé požadované funkce, ve sloupcích budou jednotlivé frameworky. PHP frameworků je velice mnoho, analyzovat všechny by bylo na samostatnou práci. Na internetu se můžeme setkat s mnoha porovnáními PHP frameworků a z mnoha také bylo vycházeno při naší analýze. My se omezíme pouze na 3. Vybrány byly Nette, CakePHP a Kohana. K několika požadovaným funkcím následuje krátký komentář. Pomocné funkce. Těmi jsou myšleny funkce pro generování elementů HTML, pro práci s cookies, řetězci, soubory apod. Takové funkce bývají standardním obsahem frameworků, ale jejich existenci pro jistotu prověříme. Podpora manipulace s obrázky. S obrázky jako s hlavním objektem bude rozsáhlá manipulace. Požadovány jsou funkce pro ořezávání, změnu velikosti, otáčení nebo vodoznak. Internacionalizace i18n/l10n. Vestavěná možnost překladu. Některé frameworky mají neúplnou, pouze předpřipravenou třídu, ale funkce na samotný překlad chybí (například Nette). Rychlost a Paměťová náročnost. Podle několika českých srovnání PHP frameworků2 byla porovnána rychlost a paměťová náročnost mezi našimi třemi vybranými. Stupnice nejlepší, střední a nejhorší je jen v kontextu našich 3 vybraných. U některých atributů byla hodnocena spíše kvalita, případně množství. Proto používáme subjektivnější hodnocení jako “střední“, “nejlepší“, “špatné“, apod.

Dokumentace Návody Autorizační podpora Autorizace OAuth Internacionalizace i18n/l10n ORM Podpora manipulace s obrázky Routování Pomocné funkce Rychlost Paměťová náročnost

CakePHP dobrá dobré ano ne ano ano ano ano ano nejhorší nejhorší

Kohana střední střední ano ano ano ano ano ano ano střední nejlepší

Nette střední střední ano ne neúplné ano ano ano ano nejlepší střední

Tabulka 4.1: Porovnání PHP frameworku na základě požadovaných funkcí Nakonec byl vybrán framework Kohana. Z tabulky vidíme, že si frameworky vedou velmi podobně, přesto byl vybrán právě Kohana framework. Především pro svou rychlost, paměťovou náročnost i velikost zdrojového balíčku. Dalším velmi dobrým rysem je jeho architektura, která je HMVC, Hierarchical MVC. Tento architektonický vzor se vyznačuje “hledáním“ potřebných zdrojových kódů (tříd, views, . . .) hierarchickým způsobem a právě tento princip využijeme například pro šablony portfolia (pokud chybí nějaký hledaný soubor na vyšší úrovni, šáhne se do nižší). Rozhodujícím rozhodováním byl nakonec faktor rozšířenosti frameworku. CakePHP už je příliš robustní a těžkopádný. Nette zase nejméně rozšířené. Na obr. 4.1 vidíme graf rozšíře2

Srovnání PHP frameworků http://www.root.cz/clanky/velky-test-php-frameworku-zend-nette-php-a-ror/ nebo test zaměřený na databáze http://www.zdrojak.cz/serialy/test-php-frameworku/.

11

nosti nejznámějších PHP frameworků převzatý z článku Best PHP Frameworks for 2014 3 publikovaném na www.sitepoint.com. Z grafu vidíme Kohana má pouze 1.50%. Důležitým faktem ale je, že Kohana vznikla přepracováním mnohem rozšířenějšího frameworku Codeigniter (7.62%), čímže jsme se přiblížili k většímu počtu vývojářů, kteří by si s naší aplikací v Kohaně poradili a mohli vytvářet šablony, moduly apod. Posledním a neopomenutelným faktorem je licence, pod kterou je framework nabízen. Potřebujeme takovou, která nám umožní dělat jak nekomerční, tak případně i komerční aplikace a Kohana má jednu z nejsvobodnějších licencí, BSD.

Obrázek 4.1: Graf rozšířenosti PHP frameworků.

4.3

Konvence

Komentáře, jména proměnných, názvy databázových tabulek, atributů apod. budou v anglickém jazyce. Dále si určíme jednotná pravidla pro psaní zdrojového kódu. Ve většině převezmeme stejná pravidla používaná ve vybraném frameworku tak, aby kód celé aplikace byl v tomto jednotný. Názvy tříd budou začínat velkým písmenem. Pokud se skládá z více slov, budou obě začínat velkým. Např. SecureController. 3

Best PHP Frameworks for 2014: http://www.sitepoint.com/best-php-frameworks-2014/.

12

Názvy metod a funkcí budou celé z malých písmen, více slov se bude oddělovat podtržítkem. Např. before nebo html entity decode. Názvy proměnných stejně jako názvy funkcí. Např. $template nebo $main template.

4.4

Hierarchie souborů a adresářů

V této kapitole si řekneme jak bude vypadat balík aplikace z pohledu hierarchie souborů a adresářů. Vše je vidět na 4.2. Význam u většiny položek je zřejmý, ostatní si rozebereme blíže. /app je hlavní úložiště pro veškeré zdrojové kódy, díky kterým aplikace funguje. Tento adresář prakticky představuje celou naši aplikaci. Především je zde framework Kohana obohacený o některé moduly, které nejsou v základní verzi. /www je kořenový adresář webu. Chceme aby naše aplikace fungovala pouze stylem nahrání zdrojových kódů na hosting a spuštění instalace. Bohužel už v tomto kroku můžeme narazit na problém. Prvním je jméno kořenového adresáře, to se může u poskytovatelů hostingu lišit (např. /web u endora.cz). Druhým problémem je, že uživatel nemá přístup do adresáře, který je v hierarchii před kořenovým (například u free hostingu ic.cz). Pro hierarchii jsme použili dobrý zvyk dávat do kořenového adresáře veřejné soubory (jako css, js, obrázky,. . .) a data aplikace do adresáře, kam není veřejný přístup. Řešení, jak prvního, tak druhého problému už vyžaduje vetší usilí a rozchází se to s potřebou, aby byla aplikace jednoduše zprovoznitelná i uživateli bez hlubších znalostí. Situaci vyřešíme uvolňováním dvou verzí. Jedna s kořenovým adresářem, jedna bez. Obeznámený uživatel sáhne po první variantě, ostatní budou směrováni na druhou. /app/modules. Počítáme, že by mohla být aplikace rozšiřitelná moduly. Například modul pro diskuzní knihu v portfoliu apod. Pro tyto účely je adresář /app/modules. Jedná se o složku s moduly frameworku Kohana.

4.5

Ukládání souborů

Musíme počítat s tím, že se v aplikaci budou vyskytovat i desítky tisíc souborů. V takovém případě je nežádoucí, aby byly v jednom jediném adresáři, například nazvaném /designs/. Tak velké množství souborů zapříčiní pomalou práci s tímto jedním adresářem. Celkově to může zpomalovat web a zbytečně to vytěžuje souborový systém a diskové pole. Stejný problém nastává u takového množství adresářů v jednom adresáři. Limity jednotlivých souborových systémů jsou mnohem výše, než je pouhých 10000 souborů (např. NTFS má limit4 až 4,294,967,295). Na základě vlastních zkušeností, kdy byl vysoký počet u nejmenovaného poskytovatele problémem a bylo vyžadováno vyřešení, musíme navrhnout jiné řešení, ve kterém k tomuto problému nedojde a neuvrhneme uživatele našeho systému do podobných potíží. Řešení můžeme vidět na 4.2, kdy hlavním uložištěm všech obrázků je adresář images, pro jednotlivé projekty pak následuje podadresář projects a v tomto další se jmény korespondujícími s identifikátorem jednotlivých projektů. Jiným řešením by mohlo být automatické vytváření adresářů, když se překročí kapacita. Ovšem to by mělo dvě nevýhody. První je třebaže jen hypotetická možnost, že by uživatel chtěl své obrázky hromadně stáhnout z FTP a shodou okolností jen z některých projektů. Námi navrhovaná adresářová/souborová struktura mu to pohodlně umožní. Další problém by byl, že by u každého záznamu obrázku v db musela být informace o jeho umístění. Tedy id adresáře, ve 4

Počet souborů v adresáři pro NTFS: http://technet.microsoft.com/en-us/library/cc781134.aspx.

13

Obrázek 4.2: UML diagram adresářové a souborové struktury aplikace. kterém existuje. V našem návrhu je pro tyto potřeby využit již existující atribut a tím je informace o projektu, ke kterému obrázek patří.

4.6

Sdílení

Přístup do systému bude mít hned několik skupin uživatelů. Jsou jimi interní administrátoři a návrháři, ti mají v systému každý svůj účet. Poté musíme počítat s možností přístupu pro klienty, aby mohli návrhářům okomentovat výsledky jejich práce. Další skupinou by mohla být celá veřejnost nebo jen určitý počet lidí, kterým chce návrhář svoji práci prezentovat. Designér může chtít mít možnost povolovat nebo naopak zakazovat přidávání komentářů nebo poznámek k danému návrhu. Pro všechny tyto případy musíme navrhnout řešení. Vychází nám tedy, že musíme rozlišovat různé druhy uživatelů, včetě přístupu pro celé skupiny a také práva. Nejprve nadefinujeme práva, která může designér přiřadit uživatelům při prohlížení nějakého jeho projektu. Pro přehlednost v tabulce 4.2. Tyto práva budou nadefinována ve vlastní databázové tabulce, aby bylo možné je párovat s daným projektem a uživatelem. Půjde tak tabulku snadno rozšířit o další možnosti. V další tabulce 4.3 pro přehled rozdělíme různé skupiny s nějakou motivací k přístupu k projektům. Uvedeme u každé jaká forma přihlašování bude dané skupině umožněna a jaká bude mít oprávnění. Z tabulky vidíme jasnou příležitost pro sloučení několika rolí, alespoň co se týče jejich realizace. Totiž klienti, návštěvníci a veřejnost je v podtstatě to stejné. Kdo a co může dělat u nějakého projektu tedy plně určuje tvůrce projektu (případně administrátoři s neomezenými právy). Dalším důležitým faktorem je zabezpečení. Když se rozhodneme, že má být projekt sdí14

Tajné Vše Komentování Poznámky Prohlížet

nově vytvořený projekt, přístup má pouze autor a administrátoři subjekt s takovými právy může v rámci daného projektu komentovat nebo dávat poznámky pouze možnost zadávat komentáře pouze možnost zadávat připomínky do obrázků pouze prohlížení

Tabulka 4.2: Definice oprávnění uživatelů nad určitým projektem Skupiny Administrátoři Návrháři Klienti

oprávnění vidí práce všech v daném systému své projekty + ke kterým má potřebné oprávnění vidí pouze projekty, ke kterým dostane přístup

Návštěvníci

vidí pouze projekty, ke kterým dostane přístup

Veřejnost

vidí pouze projekty, ke kterým dostane přístup

přihlášení email + heslo email + heslo heslo nebo bez přihlášení heslo nebo bez přihlášení heslo nebo bez přihlášení

Tabulka 4.3: Definice oprávnění uživatelů nad určitým projektem len ale také zabezpečen, je možné jej ochránit heslem. Druhým zabezpečením je generovaná URL odkazu pro sdílení (více o URL v kapitole 4.8). Tuto adresu pak designér zveřejňuje podle svého uvážení. Když shrneme předešlé skutečnosti, sdílení projektů bude možné na třech úrovních. Dvě pro sdílení s veřejností, jedna pro sdílení mezi kolegy pro práci v týmu. Náhled na dialogové okno se sdílením můžeme nalézt v příloze H. 1. Nastavení viditelnosti. Zde bude mít uživatel na výber ze 3 následujících možností. (a) Private. Projekt nemůže být zobrazen přes odkaz na sdílení. (b) Public. Projekt je viditelný na daném odkazu bez zabezpečení heslem. Dále u této možnosti lze zadat povolení k zadávání komentářů nebo poznámek. (c) Protected. Stejná možnost jako Public, jen je možné odkaz zabezpečit heslem. 2. Portfolio. Vybráním této možnosti budou projekt a jeho obrázky viditelné v portfoliu. 3. Práce v týmu. Vybráním této možnosti bude designérovi umožněno vybrat ze seznamu dostupných designérů teamové kolegy, kteří uvidí projekt a budou k němu mít veškerá práva. Z uvedeného nám vychází další možnost jak usnadnit práci designérovi. A totiž vytvářet si skupiny uživatelů např. i s přednastavenými oprávněními tak, aby návrhář mohl jednoduše k návrhu přidat jen tuto skupinu (např. skupina Přátelé), přičemž by tímto přiřazením povolil přístup celé skupině lidí. Opět toto ponecháme jako možné rozšíření pro další verze.

15

4.7

Návrh schéma databáze

Máme vše abychom přistoupili k návrhu schéma databáze. Na základě požadavků si nejprve nadefinujeme všechny hlavní entity, které v systému vystupují. Budou to: uživatel, klient, projekt, návrh a nakonec obrázky. Výsledné schéma ukazuje ER diagram B v příloze. Jako hlavní médium pro prezentování výsledků práce designéra jsou obrázky. Do budoucna je ale dobré počítat s rozšířením o další formáty, jako je video nebo zvuk. Za zmínku stojí databázové řešení přidávání komentářů k obrázkům. Ke každému je možné přidat neomezeně komentářů, jde tedy o klasický vztah 1:N. Když se ale podíváme do ERD B vidíme, že komentáře jsou nejprve navázány na tabulku discussions a až tato tabulka je navázána vztahem 1:1 na tabulku images. V podstatě by tabulka discussions byla zbytečná. Nám ale poslouží s ohledem právě na možná rozšíření o zmíněné formáty dat. Diskuze, a tedy možnost komentování, tak bude o to lehčí přidat např. pod zvukovou stopu, video, apod. Přidání by se provedlo zavedením nové buňky v tabulce discussion, která by byla cizím klíčem do tabulky pro další objekt, nad kterým bychom chtěli nechat uživatele diskutovat (stejně jako je to mezi tabulkami discussions a images). Naznačení tohoto postupu můžeme vidět na ERD 4.3. Na závěr ještě posledn úvaha. Možnost diskutování se nemusí týkat jen obrázků, videí, atd. Co když bude chtít designér shromažďovat komentáře např. pod celým projektem? Nebo vytvořit diskuzní knihu v portfoliu svých prací? Právě pro všechny tyto situace, které mohou nastat, necháváme vztah mezi komentáři a daným obrázkem skrz tabulku discussions. To i přesto, že v sočasné chvíli se dají přidávat komentáře právě jen k obrázkům. Ovšem díky tomu, že schéma databáze s něčím takovým počítá už dopředu, navázání diskuze i jinam než k obrázkům bude mnohem jednodušší. comments int(11) PK id image id text text varchar(255) email created datetime int(11) FK client id int(11) FK user id

0. .1 ...

0. .n

PK FK FK FK

0. .1 videos int(11) PK id FK design id int (11) varchar(255) filename description text created datetime

1 discussions int(11) id image id int (11) video id int (11) ... 1

0. .1 images int(11) PK id FK design id int (11) varchar(255) filename description text created datetime

Obrázek 4.3: Naznačení principu přidávání diskuzí k dalším objektům na úrovni databáze.

4.8

URL

URL adresy budou samozřejmě ve formátu tzv. hezkých url. K jejich co nejsnadnějšímu parsování nám pomůže od frameworku požadovaná funkce Routování. V administraci i portfoliu bude formát trochu odlišný. Vše vidíme v 4.4, kde additional parameters jsou

16

případné další parametry oddělené amprsandy, seo-friendly-text je text vztahující se k dané stránce tak, aby i URL pomáhala k lepší SEO optimalizaci pro webové vyhledávače. Třetím typem vyskytujícím se v aplikaci bude URL pro sdílení. Ukázka takové URL je opět v tabulce 4.4. Sdílené projekty, které jsou v podstatě veřejné, nemohou mít v adrese přímo identifikátor projektu, jako to může být v administraci. Mohlo by se jinak stát, že bude někdo hádat tyto id čísla projektů. Toto se vyřeší zastoupením tohoto identifikátoru náhodně generovaným hash řetězcem, který bude skrz databázi spárován s konkrétním id číslem projektu. Tedy pro každý sdílený projekt je odlišná URL adresa, taková aby se nedala lehce odhadnout. Administrace

formát příklad

Portfolio

formát příklad

Sdílení

formát příklad

/admin/controller/action/id?additional parameters /admin/projects/add/89 /admin/clients?page=2 /controller/action/id-seo-friendly-text?additional parameters /projects/89-navrh-designu-jizdniho-kola /contacts /share/hash/controller/action/id /share/7686eda8f95534b7a79788f3ad72f69c/images/detail/12 Tabulka 4.4: Formát URL adres

4.9

Portfolio

Často bylo v předešlém textu zmiňované portfolio. Pro designéry je to jistě nedílnou součástí jejich práce. Pokud si má tedy návrhář instalovat naší aplikaci na svůj hosting, bylo by to přinejmenším plýtvání jeho časem i prostředky, aby si musel ještě navíc obstarávat webovou prezentaci, kam by musel znovu přidávat obrázky svých prací, které už stejně má v našem systému. Tento problém ovšem vyřeší naše palikace Bude možné generovat z jednotlivých projektů a návrhů portfolium prací. Pokud bychom se omezili pouze na přehlídku obrázků, bylo by to málo. Stále by návrhářům chyběly stránky jako kontakt, o nás, diskuze apod. Dále bude nutné navrhnout tvorbu tohoto webu (portfolia) takovým způsobem, aby bylo možné jednoduše měnit, přidávat, vytvářet šablony tak, aby nebyl pouze jeden vzhled stránek pro všechny. Použijeme stejný princip, který se používá v široké míře u jiných CMS systémů. My se inspirujeme konkrétně u systému Prestashop5 . Pro tyto potřeby je adresář themes, jeho umístění můžeme vidět v adresářové struktuře na obr. 4.2. V tomto adresáři se nachází všechny dostupné šablony. Podrobnější popis, jak je vše realizováno je v kapitole Implementace 5. Obsahem každého adresáře šablony musí být vše potřebné pro její vzhled a funkčnost. Od CSS a javascriptových souborů, přes obrázky až po řídicí třídy. V tabulce 4.5 vidíme možný obsah šablony. Portfolio bude umožňovat zobrazovat jen ty projekty a obrázky, které chceme. Vytvoření šablony bude jednoduché a novou šablonu si může vytvořit každý. Vše je vhodně oddělené od zbytku aplikace. Pokud má uživatel v systému více šablon, jednoduchým výběrem šablony v administraci bude mít možnost měnit ihned vzhled portfolia. 5

E-shop systém Prestashop: http://www.prestashop.com/.

17

soubor/adresář css/ js/ images/ i18n/ views/ classes/Controller info.php preview.jpg|png|gif ...

popis všechny css soubory potřebné pro daný theme všechny javascriptové soubory potřebné pro daný theme potřebné obrázky se soubory cs.php, en.php apod. s překlady pro jednotlivé jazyky view soubory, stejný význam jako u MVC architektury řídicí soubory, stejný význam jako u MVC architektury informace o šabloně, autor, verze, . . . náhled šablony ve formátu jpg, png nebo gif

Tabulka 4.5: Obsah jednoho theme (balík šablon)

4.10

Layout a design

Při návrhu vzhledu aplikace bylo čerpáno z knihy Inspirativní webdesign: Průvodce nejlepšími tématy, trendy a styly [3]. Následující věta pochází právě z této knihy a je vysvětlením, proč byl vybrán pro naši aplikaci minimalistický až extra strohý design. Pokud bych si musel vybrat jediný styl nebo přístup k webovému designu, pak by to byl tento. Designy v této části knihy pro mě nepředstavují jen styl, ale ideál z hlediska čistoty a funkčnosti designu. Extra strohé weby se kloní k minimalismu, ale nezaměřují se tak na to, aby byly méně než křišťálově čisté. Na tyto weby je tak potěšení se dívat a snadno se používají. Poskytují skvělé zacílení z hlediska krásy i funkcí. Pro administraci, která je jádrem aplikace, je navrhnut zcela jednoduchý a velmi rozšířený koncept. Skládá se ze 3 základních částí. Menu s tlačítky, kde budou použity již zmíněné ikony z frameworku Bootstrap. Menu bude mít fixní pozici tak, aby bylo vždy připravené pro uživatele. Dále následuje pochopitelně obsahová část a ve spodní části patička pro zobrazení např. copyright, informaci o verzi, názvu našeho systému apod. Návrh layoutu si můžeme prohlédnout na obr. 4.4. Konkrétní návrh designu administrace, v tomto případě v situaci, která zobrazuje poslední projekty, můžeme vidět na 4.5. V poortfoliu bude layout určovat aktuálně použitá šablona. Pro některé prvky designu vycházíme z nejnovějších trendů6 . Jsou to responzivní design, plochý design, výrazné barvy, statické záhlaví stránky, velká tlačítka nebo výhody CSS a HTML5.

6

Inspirace nawww.pagerank.cz/ohlednuti-modni-trendy-ve-webove-grafice-v-roce-2013.

18

Menu Obsah Patička Obrázek 4.4: Layout, návrh rozvržení prvků na stránce.

Obrázek 4.5: Návrh designu administrace.

19

4.11

SEO

Kapitola SEO je obrovská a věnovat se jí v plné její šíři a potenciálu by zabralo textu na samostatnou práci. Pokud ale chceme, aby uživatelé mohli aplikaci používat i jako svůj web, je dobré SEO nepřehlížet. Při čerpání z knížky Velký průvodce SEO [2] se dozvíme základní SEO techniky, které je vhodné udělat za uživatele nebo co nejvíce automatizovaně, neboť se jedná o takové techniky, kdy je nutný zásah do kódu. Opět nechceme, aby uživatelé museli nakládat mnoho usílí, když jim v tom může aplikace pomoci. Pro některé použité SEO techniky jsme si vzali příklad z existujících CMS systému (Prestashop). Jmenovitě to jsou techniky pěkné URL, vyplňování html meta tagů keywords, description nebo tag alt u obrázků.

4.12

Plán

Nejprve je nutné vývoj naplánovat. Bude použit iterativní životní cyklus vývoje. Navrhneme několik iterací. Realizace jedné iterace zpravidla zabere řádově jednotky týdnů. Výsledkem každé iterace bude funkční prototyp. Nadefinované požadavky můžeme rozdělit do logických seskupených celků. Pořadí iterací bude kopírovat reálnou situaci při používání aplikace. Tedy například následující postup: 1. Instalace aplikace. 2. Vytvoření uživatele s právy administrátor. 3. Přihlášení do systému. 4. Přidání návrháře. 5. Přidání klienta. 6. Přidání projektu. 7. Přidání návrhů. 8. Komunikace s klientem. 9. Vytvoření portfolia. Z tohoto postupu vidíme, že musíme například nejprve realizovat přidání projektu a poté až přidání návrhu. Postupnou realizací jednotlivých iterací bude narůstat funkčnost aplikace až k jejímu úplnému dokončení.

4.12.1

1. iterace

Instalace aplikace. Vytvoření uživatele s právy administrátor. Poté, co se všechny potřebné soubory nahrají na server, spustí se na určité adrese instalace aplikace. Tento proces bude rozdělen na 3 části v následujícím pořadí: • Kontrola způsobilosti serveru. Zjištění, zda jsou přítomny potřebné funkce, soubory, adresáře, nadefinovány proměnné, zkontroluje verzi PHP, apod. • Samotná instalace. Vytvoření tabulek v databázi. 20

• Vytvoření administračního účtu. Uživatel při instalaci bude muset zadat údaje pro vytvoření prvního účtu s právy administrátor. Instalace bude navržena způsobem spouštění několika skriptů, ty půjde dodatečně doplňovat a rozšiřovat.

4.12.2

2. iterace

Přihlášení do systému. Změna nastavení. Správa návrhářů. Správa klientů. Přihlášení do systému bude možné realizovat klasickým způsobem. Pomocí e-mailu a hesla. Na obr. 4.6 vidíme případy užití spadající pouze pod 2. iteraci.

Změnit nastavení systému Správa klientů. Správa návrhářů Návrhář

Administrátor

Obrázek 4.6: Diagram případů užití pro 2. iteraci.

4.12.3

3. iterace

Správa projektů. Správa návrhů. Změnit vzhled prostředí u návrhu. 3. iteraci můžeme vidět přehledně na diagramu 4.7. Sdílení s klientem Změnit vzhled prostředí u návrhu

Správa projektů/návrhů

Návrhář

Administrátor

Zobrazení projektů/návrhů Klient

Obrázek 4.7: Diagram případů užití pro 3. iteraci.

4.12.4

4. iterace

Přidávání komentářů, poznámek k návrhům. Sdílení s klientem. 21

4. iteraci můžeme nazvat Komunikační“. Realizujeme v ní veškerou komunikační fun” kčnost. Komentování návrhů, apod. Viz. obr. 4.8. Sdílení s klientem Správa zpráv

Správa poznámek/komentářů.

Návrhář

Administrátor

Přidávání poznámek/komentářů Klient Odeslat zprávu návrháři

Obrázek 4.8: Diagram případů užití pro 4. iteraci.

4.12.5

5. iterace

Vytvoření portfolia. Ostatní. V této fázi jsme schopni do aplikace přidávat projekty i jednotlivé obrázky, ty komentovat nebo sdílet. Aplikaci můžou desinéři využít dvojím způsobem. Jako podpůrnou aplikaci. Pouze její administraci a funkce pro sdílení a správu svých návrhů. K tomu může mít samostatnou aplikaci pro webové stránky, které nemají nic společného s naším systémem. Druhou možností je, využívat na vše pouze naši aplikaci. Jako webové stránky bude fungovat Portfolio, jedna z funkcí aplikace. A právě Portfolio bude realizováno v 5. iteraci. Další náplní implementace v 5. iteraci jsou menší ale neméně důležité součásti, některé si popíšeme v následujících odstavcích. Notifikační emaily. Odeslání e-mailů s informováním o různých skutečnostech. Naše aplikace informuje uživatele, že mu byl vytvořen nový účet. Dále zasílá zprávy o nových obrázcích, komentářích a obrázkových poznámkách.

22

Kapitola 5

Implementace Po návrhu můžeme přistoupit k implementaci. Z ní si v této kapitole popíšeme jen to nejzajímavější. Dozvíme se například, co nám chybělo ve frameworku Kohana a popíšeme si, jak jsme situaci řešili. V další sekci si popíšeme části aplikace, ke kterým jsme použili existující moduly a řešení poskytované k volnému používání.

5.1

Chybějící funkce frameworku

Jak jsme zmínili, několik věcí nám ve frameworku chybělo a tak jsme si museli pomoci sami. V této sekci si rozebereme naše řešení. Odkazy aktivní stránky. Snad v každé webové aplikaci potřebujeme označovat odkazy v menu jako právě aktivní“ pro případ, že jsme zrovna na stránce, na kterou odkaz ” vede. V našem případě se jedná o možnost dodat HTML atribut class na hodnotu active k elementům odkazu () nebo elementům položka seznamu (

). Protože se pohybujeme ve view vrstvě, použijeme k řešení rozšíření Kohana třídy Html o metodu active. Ta nám určí, zda jsme na stránce, na kterou vede odkaz a označí daný HTML element zmíněnou třídou. CSS styl už nám pak jednoduše graficky označí, že se jedná o aktivní prvek. Kontrola práv a přihlášení. Ve frameworku samozřejmě existují třídy pro pohodlné kontrolování, zda je uživatel přihlášen a jestli má potřebná práva. Vždy se musí testovat návratová hodnota metody logged in instance třídy Auth a reagovat na její výsledek. Abychom to nemuseli psát do každé metody ostatních tříd, kde je to potřeba, lze zavolat test na práva v konstruktoru. Takových míst by ale také bylo mnoho. My si tedy navrhneme vlastní, pohodlnější řešení. Chybí nám podobná funkcionalita jako je v ASP.NET MVC a totiž možnost přidat jednoduchým způsobem1 zabezpečení ke konkrétní třídě. K řešení jsme si vytvořili třídu Controller Secure, ve které máme test na přihlášení uživatele (požadované zabezpečení). Všechny třídy, které tak chceme mít zabezpečené, dědí od této. Ovšem jedná se pouze o kontrolní (Controllers) třídy, u kterých jsme toto požadovali. Třídy, které potřebují umožnit akce i nepřihlášeným uživatelům, např. třídy pro zpracování komentářů nebo obrázkových poznámek dědí od původní třídy Kohana Controller Template. Další nedostatek nastal ve zpracování view souborů. Klasický model je následující. Zavolá se statická metoda factory() třídy View s parametrem cesty k view souboru, který chceme zobrazit. Po zavolání metody render() se na daná místa v souboru doplní data 1

Zabezpečení v ASP.NET MVC 4: http://blogs.msdn.com/b/rickandy/archive/2012/03/23/ securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx.

23

předaná z kontroleru a vrátí se hotová stránka ve formátu textového řetězce. Takto zpracováváme každou stránku. Jsou ale takové části, které se na stránce opakují a museli bychom pokaždé manuálně tyto části renderovat a komponovat dohromady. Jsou to část s odkazy na CSS a Javascript soubory, menu, patička, apod. Kohana neposkytuje bez zásahu takovou možnost, aby se každý zpracovaný view soubor doplnil do hlavní šablony automaticky. Vytvořili jsme si tedy šablonu, obyčejný PHP soubor s HTML, ve kterém je proměnná $content. Namísto této proměnné se vždy dosadí textový řetězec reprezentující daný view. Vše můžeme vidět na zdrojovém kódu 5.1. Šablona se určuje podle první části URL, tedy admin pro administrační část, share pro část sdílení. Pro portfolio je situace trochu jiná, tam se bere jako hlavní template vždy soubor main.php z auktuálně používané šablony (www/themes/aktualni sablona/views/main.php). Celé to probíhá v třídě Kohana Controller Template, zde se takto zkomponované view soubory opět vyrenderují a vrátí se jako výsledná stránka. Je to klasický způsob skládání view souborů, podobný řešením, jako ve frameworcích Nette nebo CakePHP. I následující chybějící funkce se týká view souborů. Je zcela běžné, že potřebujeme mít na každé stránce stejnou část. V našem případě např. menu nebo naopak patičku. Opět se inspirujeme ASP.NET MVC frameworkem. Zde existují tzv. Partial Views2 . Ty nám umožňují umístit jeden view do jiného view takovým způsobem, aby mohl dostávat jiná data, než má jeho otcovský view. V Kohaně je možnost jak jednotlivé view dávat dohromady. Vždy ale v místě, kam jej přidáváme, musí být naplněn daty. To v důsledku znamená, že takový view musí být vždy svázán s nějakým controllerem. Pro naší situaci je toto řešení nevhodné, neboť chceme přidat menu a patičku už v hlavní šabloně (o té byla řeč v minulém odstavci) a ta je renderována controllerem, od kterého ostatní řídicí třídy dědí. Proto není vhodné, aby právě v této třídě docházelo i k plnění těchto našich částěčných view. Za druhé toto odporuje dobrému stylu programování a totiž k logickému rozdělování kódu do částí. Pro lepší představivost vidíme na 5.1 část zdrojového kódu hlavní šablony. Na místech, kde je volání tříd PartialView::factory() se dosazují příslušné části, které jsou viditelné na všech stránkách, které používají tuto šablonu. Tím už se dostáváme k našemu řešení. Vytvořili jsme si vlastní třídu s názvem PartialView, která dědí od hlavní třídy Kohana View. Tato třída dostane v parametru cestu k view, který má zpracovat. Podle této cesty sama zavolá potřebnou řídicí třídu (controller), ktera vrátí data potřebná ve view. Nakonec se vše vykreslí pomocí klasické třídy View a vrátí se výsledný textový řetězec, který reprezentuje například menu. Pro přehlednost jsou tyto view soubory a jejich příslušné řídicí třídy stejných jmen a v adresářích s názvem partials. Na části zdrojového kódu 5.1 vidíme v HTML tagu lang php proměnnou $html lang. Aplikace je v současné chvíli plně přeložena do dvou jazyků, čeština a angličtina. V administraci je možné nastavit jazyk systému, podle tohoto nastavení se dosazuje právě obsah uvedené proměnné $html lang. Podle ISO kódů3 řetězec cs pro češtinu a en pro angličtinu. Nastavení tohoto jazyka není jen pro tento atribut, nastavuje se tím i defaultní jazyk pro všechny uživatele. Stále si ale každý může vybrat z nabídky pro svůj účet jiný preferovaný jazyk. To je například pro takové situace, kdy systém používá česká firma a zaměstnává cizince. Ti si můžou v nastavení zvolit právě zmiňovaný anglický jazyk.

2

Views a Partial Views v ASP.NET MVC aplikacích: http://msdn.microsoft.com/en-us/library/ dd410123(v=vs.100).aspx. 3 ISO jazykové kódy: http://www.w3schools.com/tags/ref_language_codes.asp.

24

Zdrojový kód 5.1: Část zdrojového kódu hlavní šablony.

5.2 5.2.1

Použitá existující řešení Javascript a CSS

V první řadě to bude framework Bootstrap4 . Získáme tak i CSS styly pro většinu klasických prvků webu. Využijeme funkcionalitu pro responzivní web nebo ikony, např. pro hlavní menu administrace. Ty jsou šikovně vytvořeny jako font (narozdíl od řešení ikon přes obrázky), tudíž budeme mít jednodušší práci s jejich nastylováním (především barva, rozměr). Dále obsahuje vlastní javascriptovou knihovnu postavenou na JQuery. Dále použijeme javascriptový modul jquery-notes5 , který je také postaven na jQuery knihovně. Ten se nám postará o vkládání poznámek do obrázků. Obsahuje funkce pro jejich schovávání, editaci a další. A velkým pozitivem je slibovaná nová verze s dalšími funkcemi. Nejdůležitějšími daty v aplikaci jsou obrázky. Ty jsou hlavním nositelem a reprezentantem práce uživatelů aplikace. Musíme tedy zvolit vhodné řešení pro jejich zobrazování, nějakou javascriptovou galerii. Na tu máme následující požadavky. Musí být postavena na jQuery nebo Bootstrap Javascript, případně kombinace. Vzhled si musí brát z Bootstrap CSS knihovny, abychom respektovali jednotný vzhled aplikace. Dále musí podporovat kromě obrázků i videa a nakonec aby tato galerie uměla zobrazovat obsah na celou plochu obrazovky (fullscreen). Na tuto funkčnost je opět myšleno hlavně s ohledem na budoucnost, neboť jedna z variant zobrazování návrhů je právě ve fullscreen. Výhoda tohoto přístupu je v tom, že daný návrh se v tu chvíli stává jediným prvkem na stránce a není kolem nic rušivého, jako menu, lišta webového prohlížeče apod. Nakonec jsme vybrali rozšíření Bootstrap Image Gallery6 , jehož autorem je Sebastian Tschan. Příjemným bonusem k vyjmenovaným funkcím je responzivní chování a podpora dotykových zařízení (bylo testováno na zařízení Google Nexus 7). 4

Bootstrap: http://getbootstrap.com. Webové stránky jquery-notes pluginu: http://jquery-notes.rydygel.de/index.php, najdeme zde i demo ukázky. 6 Bootstrap Image Gallery http://blueimp.github.io/Bootstrap-Image-Gallery/. 5

25

Nakonec potřebujeme vybrat řešení pro realizaci několika potřebných komponent. Jako první hledáme vhodnou Javascriptovou knihovnu pro realizaci více výběrového prvku. Je to pro situaci, kdy bude u sdílení projektu možnost přidávat více uživatelů pro práci v týmu na daném projektu. Jako nejlepší řešení se jeví bootstrap-select7 . Svým vzhledem připomíná klasický HTML select element, ale je v něm možné vybrat více položek. Tedy po rozbalení možností budeme moci naklikat přesně ty uživatele, kteří mají tvořit nějaký projektový team. Jednou z dalších funkcí, které jsme naplánovali, je možnost nastavení barvy pozadí pro každý obrázek. Pro výběr barvy tak, aby byla v hexadecimálním tvaru, jsme vybrali rozšíření pro jQuery knihovnu jQuery MiniColors8 . Umožní nám doplnit výběr barvy pro input HTML element. Vybranou barvu pak vrací právě do tohoto formulářového prvku. Kromě tohoto umí zobrazovat barvy různým stylem (obdelník nebo krůh) nebo nastavit k barvě i průhlednost. Autorem je Cory LaViska. Při vývoji byla aplikace průběžně testována. Nejen na počítačích, ale i na tabletu, konkrétně na Google Nexus 7. Při tomto testování jsme narazili na problém s HTML elementem textarea. Ve chvíli, kdy do něj uživatel píše na PC a překročí napsaným textem jeho základní počer řádků, může pomocí myši rozměry tohoto pole pro psaní zvětšit (v prohlížeči Google Chrome) nebo může jednoduše použít kolečko myši a scrollovat. Na tabletech a v některých prohlížečích na situaci, kdy bude uživatel psát více textu, nejsme připravení. Použijeme proto rozšíření jQuery Autosize9 pro automatickou změnu výšky textového pole podle množství napsaného textu. Na tabletu a všech ostatních menších zařízeních vždy uvidíme co píšeme. A vhodné to bude i pro uživatele na osobních počítačích, kteří se tak obejdou bez myši. Posledním prvkem aplikace, ke které potřebuje komponentu, je výběr času a data. Datum a čas je potřeba nastavit pro deadline projektu. Použijeme DateTime Picker10 . Poskytuje nám vzhled z CSS knihovny Bootsrap nebo je možné nastavit pro datum a čas formát.

5.2.2

Moduly frameworku Kohana

Nejprve musíme zmínit několik modulů, které Kohana obsahuje ve svém základu. Auth modul pro podporu uživatelských účtů, jejich vytváření, přihlašování, apod. Modul Database a ORM pro veškerou práci s různými typy databází a modul Image pro práci s obrázky. Nyní popíšeme takové, které v základní verzi Kohana nejsou a většinou nepochází ani od jejích tvůrců. Funkcionalitu šablonovacího systému budeme řešit s pomocí modulu Kohana Theming Module 11 jehož autorem je Dwayne Charrington. Používá výhody HMVC architektury a umožňuje nám mít odděleně view soubory od těch aplikačních. Přesně tak jak to požadujeme. Pro každý theme bude složka s vlastními /views/, /controllers/, /modules/. Další modul budeme potřebovat pro odesílání e-mailů. Ty potřebujeme posílat v přípa7

Výběrový prvek postavený na knihovně Bootstrap: http://silviomoreto.github.io/ bootstrap-select/. 8 O rozšíření jQuery MiniColors se více dozvíte na http://labs.abeautifulsite.net/ jquery-minicolors/. 9 Více o jQuery Autosize na http://www.jacklmoore.com/autosize/. 10 Více o použité DateTime Picker komponentě na http://www.malot.fr/bootstrap-datetimepicker/ demo.php. 11 Kohana Theming Module na GitHub: https://github.com/Vheissu/Kohana-Theming-Module.

26

dech notifikačních zpráv nebo zasílání přihlašovacích údajů. Použijeme modul12 postavený na knihovně SwiftMailer. Ta nám prostřednictvím modulu umožňuje mnoho nastavení, jako např. SMTP servery, HTML e-maily, přílohy a mnoho dalšího. Jednou z velkých výhod aplikace měla být od začátku neomezená velikost přidávaných obrázků. Vždy ale není vhodné vykreslovat obrázek v jeho maximální velikosti. V klasických případech, jako náhledy, je dobré načítat obrázek v menší velikosti. Pro automatické zmenšování obrázků za běhu použijeme modul Imagefly, jehož autorem je Fady Khalife13 . Kromě obyčejného zmenšování tento modul umí vytvořit i výřez nebo vložit do obrázku vodoznak. U všech neautorských modulů byl kladen důraz na licenci, pod kterou jsou vydávány. Pečlivě bylo zjišťováno, za jakých podmínek jsou jednotlivé práce poskytovány a požadovali jsme, aby licence povolovala i komerční použití.

12 13

Odkaz na email modul od Johna Richarda: https://github.com/digitaljohn/kohana-email. Imagefly modul na http://fkportfolio.com/.

27

Kapitola 6

Testování a úprava aplikace V tuto chvíli máme aplikaci naimplementovanou, budeme říkat verze 0.1. Velmi důležitou částí v životě softwaru je etapa jeho testování a i tu můžeme rozdělit do několika fází. Stejně jako jsme si naplánovali implementaci, naplánujeme testování do několika iterací. Musíme určit, kdo bude v dané iteraci testovat a jaká část aplikace se bude testovat. Tomu se budeme věnovat v sekci Plán testování. V dalších kapitolách uvedeme výsledky testování a rozebereme si je. Navrhneme řešení zjištěných nedostatků a provedeme druhé testování.

6.1

Plán testování

Musíme rozdělit aplikaci na části, které má smysl samostatně testovat. Poté si musíme uvědomit, kdo by měl testování provádět. Jestli pouze vývojář nebo už uživatelé. Jednotlivá stádia vývoje už jsou mnoha lety standardizována a tak se jimi inspirujeme, přesněji knihou Rona Pattona [4]. Testování programátorem (Developer’s Unit testing). Testování správné funkčnosti metod, funkcí, apod. Během implementace bude nastaven takový styl vývoje, při kterém každý modul, funkce, metoda bude po naprogramování okamžitě programátorem otestována. Půjde tedy o nepřetržité testování malých částí už během samotného vývoje. Tento styl vede k odhalení naprosté většiny chyb ještě předtím, než se k testování dostanou samotní uživatelé. V podstatě tím nahrazujeme odhalování chyb během alfa testování. Testování funkcionalit. To nejdůležitější co uživatele zajímá je, co aplikace umí, jaké má funkce. Tuto fázi testování už tedy budou provádět uživatelé. Etapa slouží pro odhalení chyb, ale primárně pro zjištění, jestli jsou funkce naprogramovány logicky, jestli se uživatel neztrácí. Také chceme z tého fáze zjistit, co uživateli vadí nebo chybí. Testování uživatelského rozhraní. Neopomenutelná část. Uživatel nikdy nevidí kód, co běží v pozadí a nezajímá se, proč to vlastně funguje. Aplikace zaujme především tím, jak vypadá a jak se ovládá. Poslední dvě fáze se vzájemně doplňují. Můžeme mít skvělé funkce, ale pokud půjdou složitě ovládat nebo na ně uživatel vubec nepříjde, jsou k ničemu. Navrhli jsme tedy sadu úkolů vedoucích k otestování jak funkcí, tak uživatelského rozhraní. Tyto úkoly jsou v příloze C. Někoho by mohlo zajímat, proč jsme použili právě takový zápis testu. Pro naši situaci, kdy testujícími budou naprosto libovolní uživatelé, i bez širších IT vědomostí, jsou odborné testy podobné formátu z tabulky 6.1 nevhodné. Riskovali bychom, že si s položkami jako identifikátor, zvláštní požadavky, procedura nebudou vědět

28

rady. Při vytvoření úkolů jsme se řídili standardní prací v systému. Tedy takové úkony, které jsou typické a časté. Jedná se celkem o 11 úkolů. Jsou úmyslně seřazeny a záleží na pořadí jejich plnění. Uživatel během nich projde většinou funkcí, proto tato sada úkolů může sloužit i jako nouzový průvodce aplikací, což byl účel. Identifikátor Účel Zvláštní požadavky Kroky procedury Procedura Měření výsledků Tabulka 6.1: Jedna z možností zápisu testovací procedury. Tato je převzata z [4]. Hlavním úkolem pro testující je zjistit celkový čas, který strávili plněním všech úkolů a za druhé, zjistit co uživatelům dělalo problémy, co jim chybělo, co nepochopili apod. Účelem je tedy zjistit průměrný čas, potřebný k tipické práci v systému. Poté, na základě zpětné vazby, aplikaci upravíme, dodáme požadované funkce, apod. Tím nám vznikne verze aplikace 0.2 a opět necháme proběhnout testování se stejnou sadou úkolů na co největším počtu uživtelů. Nakonec provedeme porovnání rychlosti práce s novou a starší verzí.

6.2

Výsledky testování verze 0.1

V této kapitole si uvedeme několik ukázkových výsledků testování, více jich bude v příloze. Tyto výsledky zpracujeme, vypočítáme průmerné hodnoty času plnění tetovacích úkolů a zhodnotíme. Z tohoto vyhodnocení a doprovodných komentářů uživatelů dále nadefinujeme změny, které budou základem pro novou verzi 0.2. Kratkým komentářem se vyjádříme ke skladbě testujících uživatelů. Kromě širokého spektra IT vědomostí, byli uživatelé i různých profesí či studijního zaměření. Od studentů IT a programátorů, přes ekonomy, grafické designéry až po architekty, fotografy nebo stavební inženýry. Důležitou skupinou jsou právě poslední jmenované profese, které mohou systém používat. Výstupy své práce mohou sdílet formou obrázků a tedy jejich připomínky byly pro aplikaci velice důležité. V následující tabulce 6.2 přehledně prezentujeme jen část výsledků testování, především ty s komentářem od testujích. U každého je dosažený čas ve formátu minuty:vteřiny a případně komentář.

29

Výsledný čas (mm:ss) 08:37 13:30

14:29

15:27 09:17

14:38

10:28 11:23

Komentář Chybí mi u tlačítek v detailu obrázku bubliny, když se na ně najede myší. Nelíbí se mi ten výběr datumu a času pro deadline. Mám mrtě lagy. Úplně v posledním kroku jsem místo obrázku smazal celý projekt. Problém mi dělala z počátku orientace, ale pak už to bylo ok. Nepochopil jsem tak uplně co se po mě chce v bodě 10. Moc mi nesedí ty měnící se nabídky pod kolečkem. A ještě jak přidáváš do obrázku ty komentáře, tak bych to potvrzovací a rušící tlačítko udělal výraznější. Ale líbila se mi ta veřejná část, to co vlastně vidíš bez přihlášení. Jak jsem dělala ten uživatelskej účet pro designéra a neměla jsem vkládat heslo, tak jsem si přečetla pozdě a heslo jsem tam dala. Nechápu kdo je uživatel, designér, zákazník. . . Chybí mi tam možnost odpovídat na poznámky v obrázcích. Designove se mi to hodne líbí, vypadá to velice pekne, jen se mi to zdá málo přehledný, změnil bych nějak tu uvodní stránku

Tabulka 6.2: Ukázka výsledků testování první verze aplikace.

Obrázek 6.1: Graf výsledků z 1. a 2. testování aplikace.

6.3

Vyhodnocení výsledků z testování verze 0.1

Předtím, než se pustíme do vyhodnocení výsledků testování, musíme zmínit důležitá fakta, která měla nezanedbatelný dopad na výsledný čas. Takových faktorů můžeme nalézt hned několik. Technické, někteří uživatelé měli k dispozici 2 monitory, na jednom měli pdf s našimi 11 30

úkoly, na druhém měli otevřenou naši aplikaci. Ušetřili tak čas, který uživatelé potřebovali k přecházení mezi úkoly a aplikací. Počítačová gramotnost. V tomto případě máme na mysli uživatele s pokročilejšími znalostmi, které mohli použít. Např. klávesové zkratky, apod. Internetové připojení. Uživatelé sami udávali jako jejich největší problém internetové připojení. To dokáže zásadně ovlivnit rychlost načítání jednotlivých stránek a tedy i čas. Veškeré tyto faktory, a jsou jistě i další, jako např. soutěživost, kdy se někdo snažil pro co nejlepší čas, jsou neovlivnitelné. Jakoukoliv změnou v dalších verzích tyto faktory nemůžeme eliminovat. Ani to není naším cílem. Budou se stejně opakovat i v dalších testováních, proto je můžeme opomenout. Vyhodnocením testování ale zjistíme, co změnit můžeme, abychom práci s naší aplikací zefektivnili. V následující tabulce 6.3 je uveden medián, průměrný, nejkratší a nejdelší čas, který uživatelé potřebovali na splnění úkolů. Medián (mm:ss)

Průměr (mm:ss)

12:26

12:36

Nejkratší (mm:ss) 8:37

čas

Nejdelší (mm:ss) 15:27

čas

Tabulka 6.3: Statistika časů testování první verze aplikace. Vyhodnocení času je jen první částí. Druhou je vyhodnocení té subjektivnější a méně kvantifikovatelné části, komentářů. Z tohoto vyhodnocení očekáváme, že se dozvíme s čím měli uživatelé největší problémy, čemu neporozumněli nebo co jim chybí. A rozebereme si ty nejzajímavější a nejpodnětnější. Například jeden z testujích přesně nepochopil, kdo je designér, uživatel, zákazník a jaký je mezi nimi rozdíl. I přesto se však úkoly danému uživateli podařilo splnit. Můžeme tedy předpokládat, že je systém srozumitelný. I přes nepochopení k čemu systém slouží, testující zjistil, jak se do systému přidává nový zákazník (úkol 2.) nebo designér (úkol 3.). Cílem testovacích úkolů bylo především ověřit správnost navrženého uživatelského rozhraní. Při žádání o testování byla samozřejmě podána informace k čemu aplikace slouží. Jinému testujícímu chyběly “bubliny“ s nápovědou. Při najetí kurzoru počítačové myši nad odkazy a tlačítka. Tuto funkci nám poskytuje prostřednictvím webového prohlížeče atribut title1 , ten je od verze HTML5 pro libovolný HTML prvek s podporou u všech hlavních webových prohlížečů. Uživatel byl zvyklý, že tímto stylem dostane rychlé vystvětlení, co jaké tlačítko dělá tak, aby mohl úkol splnit. V tomto případě měl uživatel pravdu a bude tento problém v další verzi odstraněn. Při vyhodnocení i při sledování některých uživatelů při plnění úkolů, se objevil zásadní nedostatek aplikace. V hlavním menu je položka s klasickou ikonou ozubeného kola reprezentující nastavení (zvýrazněné tlačtko na obr. 6.2). Toto tlačítko bylo koncipováno jako multifunkční, kontextové. To znamená, že záleží na tom, kde se uživatel zrovna nachází. Pokud v projektu, vedla by ikona na nastavení projektu, pokud v detailu obrázku, vedla by na nastavení obrázku apod. A právě tato změna funkce tohoto tlačítka nejvíce uživatele mátla a dalo jim velké usilí splnit úkoly 5., 8. a 9. Ve většině však poté uváděli, že po nalezení tohoto tlačítka v prvním z úkolů už nebyl problém nalézt jej i v dalších. Nicméně jsme se rozhodli tuto funkcionalitu tlačítka zrušit a nechat jej pouze jako odkaz pro hlavní systémové nastavení. Hned několikrát si uživatelé stěžovali na velkou chaotičnost domácí stránky adminis1

Atribut title pro libovolný HTML prvek: http://www.w3schools.com/tags/att_global_title.asp.

31

Obrázek 6.2: Náhled na tlačítko pro nastavení. trace. Její obsah je rozdělen na čtyři vertikální sloupce. V prvním jsou poslední přidané obrázkové poznámky, v druhém nejnovější komentáře, v dalším nejnovější obrázky a nakonec ve čtvrtém jsou nejnovější projekty. Lepším řešením by mohla být spíše časová osa, ve které by po jednotlivých dnech byla vhodným způsobem viditelná veškerá aktivita. Další problém byl v samotném přidání poznámky do obrázku. Uživatel v jednom známém případě vůbec nenašel funkci pro přidání poznámky a šel v testu dál. Asi považoval za poznámku komentář pod obrázkem a úkol měl za splněný. Narážíme na problém, kdy v testované verzi aplikace byly ikony pro přidávání poznámek velice malé a špatně viditelné. Ikona se symbolem plus, která slouží pro přidání poznámky, svým vzhledem a umístěním zmátla uživatele, kteří si namísto toho mysleli, že je pro zvětšení obrázku. Tento problém vyřešíme vytvořením viditelného menu s ikonami. Ty budou opět doplněny atributem title, který tak bude vysvětlením, která z ikon k čemu slouží. Jsou to obecně načítané soubory, které zpomalují stránku, nejen obrázky, ale také Javascriptové a CSS soubory. Jako zakladní opatření používáme pouze jejich zmenšené verze (tzv. minified verze). Naše stránka se však

32

6.4

Výsledky testování verze 0.2

Výsledný čas (mm:ss) 13:36 11:00

15:08 10:47

10:53

20:00

15:54 23:00

07:50

Komentář Mam linux a firefox a ty dialogove (resp ty formulare) mam rozhazene. To jen btw. Jinak to vypada zajimave. Ale je pravda, ze sem tam neco neni intuitivni a musel jsem trochu patrat. Treba to menu pro obrazek jsem hned nevidel. Ale good job. Ještě bych doplnil nápovědy kdyz najedeš na tlačítka v horni liste. . . je tam jen ikonka a pro upresnění co to presně dělá by se to hodilo. Některý dialogy byly hodně rozhozený, že ulítávalo tlačítko do boku, nebo to nemělo pozadí, používám firefox. A nešlo by u toho nahrávání obrázku dát někam tlačítko zrušit? Omylem sme vybral 10megovej soubor. Trochu jsem tápal kde přidat klienta, už. Účet pro des. a ostatní, to plus je sice logický, ale v první chvíli mne to netrklo. . . Z mého pohledu byl největší problém s poznámkou - když jsem odjel myší z textboxu, abych klikl na save note, tak ten textbox zmizel včetně toho save note“. Plus bych asi ” přivítal nějakou informaci o tom, že je to přidávání poznámky aktivní (intuitivně jsem čekal, že ten textbox se objeví vedle kurzoru a kliknutím ho umístím kam chci), např. změnou barvy pozadí příslušné ikony. . . Jen teda při změně nastavení obrázku to mám nějaký rozhozený.

11:41 12:40 Tabulka 6.4: Ukázka výsledků testování druhé verze aplikace.

6.5

Vyhodnocení výsledků z testování verze 0.2

Stejné vyhodnocení jako jsme dělali v 1. testování uděláme i v 2. testování. Ukázalo se, že několik problémů přetrvává, jiné se podařilo eliminovat úpravou aplikace po prvním testování. V následujících několika odstavcích se krátce zastavíme nad zajímavějšími komentáři a problémy. Při testování se podařilo odhalit závažnou chybu v zobrazování formulářů. Tato chyba byla způsobována pouze ve webovém prohlížeči Firefox. Jak chybné vykreslování formuláře vypadalo, je možné vidět na CD v adresáři s chybami. Na chybu poukázali asi 4 uživatelé. Chybu způsoboval špatně plovoucí prvek odesílacího tlačítka formuláře, pro nápravu bylo

33

nutné přidat před tlačítko prvek s CSS atributem clear a hodnotu both. V jedom z případů dostal testující chybu, kterou však nebylo možné zopakovat a tím pádem odhalit i její příčiny a chybu opravit. Jednalo se o situaci, kdy z PDF souboru s testujícími úkoly kopíroval přihlašovací údaje (e-mail, heslo) do formuláře pro přihlášení. Pokus o odeslání formuláře vedl k chybě v SQL (vytisknutá obrazovka s touto chybou je na přiloženém CD). Podle kapitoly 3 Podstata testování softwaru v [4] můžeme tuto chybu s mírným rizikem prohlásit za nepodstatnou. Vyskytla se během několika týdenního testování a používání aplikace pouze jednou a navíc nebylo možné chybu ani úmyslně způsobit po aplikování přesného postupu, při kterém vznikla. Na závěr druhého hodnocení přikládáme tabulku 6.5 důležitých hodnot z výsledků 2. testování, stejnou jako v případě testování prvního. Medián (mm:ss)

Průměr (mm:ss)

11:08

12:16

Nejkratší (mm:ss) 06:24

čas

Nejdelší (mm:ss) 23:00

čas

Tabulka 6.5: Statistika časů testování druhé verze aplikace.

6.6

Závěrečné vyhodnocení

Máme za sebou hned dvojí testování. Objevili jsme mnohé nedostatky v uživatelském rozhraní. Dozvěděli jsme se, čemu uživatelé nerozumí. Na druhou stranu jsme zjistili i to, co se uživatelům líbí. A tím je design aplikace. Aplikaci jsme podle připomínek zákazníků upravili a jako poslední nám zbývá vyhodnotit nasbíraná data. Výsledky z obou testování se poměrně zásadně liší. U prvního testování jsou výkony (dosažené časy) mnohem konzistentnější. Musíme předpokládat, že jsme měli pouze štěstí na šikovné uživatele. Při druhém testování už byla situace jiná a extrémních hodnot bylo hned několik. Proto budeme z obou testování počítat s mediánem. Úpravami ve druhé verzi jsme docílili zlepšení o 10,46%, to se rovná 1 minutě a 18 vteřinám pro naše testování. To je nezanedbatelná částka. Jak probíhali výpočty, můžete vidět v souborech programu Microsoft Excel na přiloženém CD. Můžeme tedy prohlásit, že testování vedlo ke zlepšení aplikace. K jejímu zrychlení. Zlepšování tím ale nekončí. Hned v další kapitole aplikaci zrychlíme zavedením dalších úprav. Kromě rychlosti načítání stránky jsme zjistili důležité informace od uživatelů, které daly jiný a velice potřebný náhled na aplikaci a její ovládání.

6.7

Rychlost aplikace

Jedním z nejdůležitějších parametrů webové stránky je rychlost načítání. Několika testujícím uživatelům se zdálo, že je aplikace pomalá. Je spousta příčin, které mohou způsobovat zpomalení načítání stránek. Jednou z příčin je samozřejmě internetové připojení, to ale neovlivníme. Navrhneme několik opatření a změn, kterými se budeme snažit rychlost načítání zvýšit. Této problematice se budeme věnovat podrobněji a tak se o ní rozepíšeme v samostatné kapitole. Necháme aplikaci otestovat v programech na zjištění nedostatků v rychlosti načítání a navrhneme možná zlepšení. Kromě těch klasických hlavně navrhneme zlepšení v ovládání uživatelského rozhraní. Opět upravujeme a testujeme verzi 0.1. Výsledkem budou 34

změny už ve verzi 0.2. Nakonec budeme muset zajistit to nejdůležitější. Způsob, jak ověřit, že námi vylepšená aplikace je skutečně lepší, rychlejší. Navrhneme tedy co nejlépe měřitelný způsob testování.

6.7.1

Návrh a implementace zlepšení

Pomocí rozšíření PageSpeed2 pro Google Chrome, můžeme zjistit některé z klasických nedostatků a zároveň i jejich řešení. Analýzou stránky v tomto programu jsme zjistili, že naše aplikace už podporuje celkem 20 z 27 opatření pro rychlost načítání stránky. Mezi ty chybějící patří např. poskytování zmenšených obrázků, zadávání rozměrů obrázků nebo minifikovat kód. Tyto zlepšení do naší aplikace zaneseme. Teď se ale zaměříme na uživatelské rozhraní. V kapitole Vyhodnocení výsledků testování verze 0.1 jsme už navrhli několik řešení, které také souvisí s rychlostí, např. zrušení kontextového tlačítka pro nastavení. V první verzi bylo nutné vždy provést o jeden klik navíc. Zrychlení práce s formuláři Dalším místem, kde můžeme práci s aplikací zrychlit, je u té nejfrekventovanější operace, při přidávání. Když vytváříme nového klienta, projekt nebo přidáváme obrázek, vždy je uživatel přesměrován na novou stránku s daným formulářem. Zde je místo pro zlepšení. Uživatel čeká na znovunačtení stránky a to můžeme eliminovat. Místo toho jsme navrhli a implementovali zobrazování všech formulářů do javascriptového okna (do tzv. lightboxu). Pro ověření správnosti řešení musíme provést testování, které se dá měřit. Máme dvě verze. Klasický formulář na samostatné stránce, která se musí načíst, na druhé straně máme formulář v javascriptovém okně. Pro každou variantu provedeme manuálně 20 testů a nakonec porovnáme a zhodnotíme důsledek pro uživatele. Testování probíhalo následovně. Celkem 40 manuálních testů při kterých se ze stejného místa aplikace iniciovalo přidávání obrázku do systému. Tím místem byla domácí stránka administrace (demo.workhaven.com/admin). Výběr této stránky byl čistě náhodný. V tomto případě mohlo jít o jakoukoli jinou, kromě stránky s daným formulářem. V tomto místě se z hlavního menu zvolila akce přidání obrázku a vždy se nahrával stejný obrázek (o velikosti 846 KB). Výsledky pouze prvních a posledních tří testování jsou v tabulce 6.6. Celou tabulku můžeme vidět v příloze D. Z tabulky vidíme, jak šlo o poměrně rychlou akci, trvání v řádu desítek vteřin. Ale i v tak jasně definované a pořád stejné aktivitě vidíme velké rozdíly. Nejlepší čas od nejhoršího se liší až o 6 vteřin. Z tohoto důvodu budeme dále pracovat s mediánem, nikoli s průměrem, abychom vyloučili extrémní hodnoty. Pro doplnění a lepší názornost uvádíme graf 6.3, na kterém je průběh jednotlivých testů. Jasně vidíme, že první pokusy zabrali vždy delší čas. Poté se už činnost zautomatizovala a čas pokusů se zlepšil. 2

Více o PageSpeed zde: https://developers.google.com/speed/pagespeed/.

35

Pokus č. 1 2 3 ... 18 19 20 Nejlepší čas Nejhorší čas Medián Průměr

Lightbox 00:16 00:16 00:14 ... 00:11 00:14 00:11 00:10 00:16 00:11,00 00:12,15

Bez lightboxu 00:17 00:16 00:16 ... 00:12 00:12 00:13 00:12 00:17 00:13,00 00:13,30

Tabulka 6.6: Ukázka testů na rychlost práce s formuláři.

Obrázek 6.3: Porovnání výsledků testování dvou typů zobrazení formulářů. Co nám tedy přesně vyšlo a jaký to má důsledek na práci uživatele? Z výsledků testování plyne následující. Rychlost práce s formuláři v javascriptovém okně je o 18,8% rychlejší. Když tedy budeme přidávat do systému obrázky např. tempem 10 denně po dobu jednoho roku a jen v pracovní dny, ušetříme na této malé činnosti 80 minut. Vzhledem k tomu, že formulářů v javascriptovém okně je v aplikaci více a používají se takřka pro veškeré vstupy uživatele, bude úspora času při práci ještě větší.

36

Kapitola 7

Výsledná aplikace Nyní, potom, co si aplikace prošla vývojovým procesem máme její výslednou verzi. V této kapitole se dozvíme hlavní požadavky na prostředí, kde bude aplikace nasazena. Dále se dočteme, jak aplikaci zprovoznit (část 7.1.2). Její metriky (7.3), mezi které patří, mimo jiné, velikost instalačního balíčku, počet tabulek v databázi nebo množství nalezených chyb při testování. Jednou z důležitých podkapitol je Směr dalšího vývoje (7.2), kde navrhneme rozšíření do dalších verzí, ale také si popíšeme možné varianty dalšího vývoje. Nakonec uvedeme v kapitole 7.4 odkazy na demoverzi a webovou prezentaci projektu. V celé této písemné práci bylo navrženo, popsáno a implementováno mnoho funkcí. Velká část nebyla z důvodu triviálnosti zmíněna vůbec. Pro nejlepší představu o tom, co všechno aplikace umí, je v příloze F seznam všech funkcí aplikace. A pro ukázku vzhledu jsou v příloze H náhledy aplikace.

7.1

Zprovoznění aplikace

U zprovoznění aplikace byl kladen velký důraz na co nejjednodušší sprovoznění. Spektrum poteciálních uživatelů, kteří aplikaci budou instalovat je široké hlavně z pohledu pokročilosti jejich IT znalostí. S tím počítáme a pro zprovoznění aplikace existují dva způsoby. Automatická instalace a manuální. Nejprve ale uvedeme nejdůležitější požadavky na prostředí aplikace.

7.1.1

Hlavní systémové požadavky

Prostředí, na kterém má aplikace správně fungovat musí vyhovovat následujícím požadavkům. • Verze PHP >= 5.3.3. • MySQL server musí podporovat engine InnoDB.

7.1.2

Instalace

Pokud naše prostředí vyhovuje požadavkům, můžeme přistoupit k samotnému zprovoznění aplikace. Typicky jsou dva způsoby instalace, manuální a automatická. V následujících podkapitolách si tyto varianty popíšeme.

37

Automatická Od počátku byl kladen velký důraz na co nejjednodušší způsob zprovoznění aplikace. Naší cílovou skupinu mohou tvořit i mírně pokročilejší uživatelé, je tedy potřeba, aby instalace proběhla co nejvíce automaticky. Popíšeme si postup zprovoznění aplikace. Úplně prvním krokem je samozřejmě stažení balíčku aplikace ve formátu zip, rozbalení a nahrání na server. Dalším krokem je obstarání databáze, kterou použijeme pro ukládání dat aplikace. Tuto databázi si musí uživatel vytvořit sám za podmínek, jaké mu umožňuje webhostingový poskytovatel. Dále se na příslušné adrese, podle toho kam byla aplikace nahrána, spustí instalace. Pokud jsme aplikaci nahráli do kořenového adresáře webu www.nasweb.cz, stačí jít na tuto hlavní stránku, kde se spustí instalátor. V následujícím seznamu jsou uvedeny jednotlivé kroky instalátoru. 1. Uvítací stránka s výběrem jazyka instalace. 2. Testy prostředí. Zde probíhají testy dostupnosti potřebných funkcí, verze PHP, rozšíření, apod., které jsou potřebné pro chod frameworku Kohana. 3. Nastavení databáze. Zadání údajů k databázi, na kterou se naistaluje inicializační sql skript. 4. Vytvoření účtu administrátora. 5. Dokončení. Posledním krokem je smazání nebo přejmenování instalační složky a poté se uživatel může přihlásit pomocí administrátorského účtu. Manuální Zde si popíšeme jak zprovoznit instalaci vlastnoručně. Někdo má rád, mít vše pod svou kontrolou, nebo z neznámých důvodů nemusí instalátor fungovat. Tento postup by však měl fungovat vždy. Rozebereme každý krok, který jinak při automatické instalaci za nás dělá sám instálátor. 1. Rozbalíme obsah ZIP souboru s naší aplikací a nahrajeme jej do webhostingového prostoru našeho webu. Budeme tak mít /app/ a /www/. Poslední jmenovaný adresář musí být kořenovým adresářem webu (cesta k němu můžeme získat v PHP proměnnou $ SERVER[’DOCUMENT ROOT’])! 2. Adresářům /www/cache/, /www/images/projects/, /application/logs/, /application/ cache/ musíme nastavit práva zápisu (CHMOD 755). 3. Pro tento krok potřebujeme existující MySQL databázi, ke které máme ze zdrojových kódů na našem hostingu přístup (na některých se nelze přihlásit na jiné databáze než na lokálním serveru). V SQL souboru /www/install/install.sql zaměníme řetězec {prefix} za libovolný prefix tabulek a takto upravené SQL importujeme do vytvořené databáze. 4. V souboru /app/application/config/database.php vyplníme údaje potřebné pro připojení k databázi. 38

5. Smažeme nebo přejmenujeme instalační adresář /www/install/. 6. Nakonec, aby bylo možné se k aplikaci vůbec přihlásit, musíme vytvořit administrátorský účet. Nejrychlejší cestou k jeho vytvoření lze zrušit zakomentování posledních dvou řádků v SQL souboru install.sql a tyto dva řádky spustit v naší databázi (opět se správným řetězcem namísto {prefix}). Vytvoří se účet s přihlašovacím e-mailem [email protected] a heslem admin123. Není bezpečné tento účet poté používat. Ihned v administraci tedy vytvoříme nový administrátorský účet s jinými údaji a tento smažeme.

7.2

Směr dalšího vývoje

Jméno této kapitoly je více než výmluvné. Nejprve zmíníme, v jakém stádiu existence se aplikace nachází právě ve chvíli psaní této práce. Poté si rozebereme možné scénáře dalšího pokračování aplikace a nakonec navrhneme možná rozšíření, která vyplynula z testování a vývoje dvou prvních verzí.

7.2.1

Současné stádium

Aplikace se právě (25.5.2014) nechází ve fázi Beta verze. Ke stažení je z dostupných odkazů k dispozici zdarma. Je poskytována pod licencí MIT. To znamená, že ji a její součásti může používat kdokoli pro komerční i nekomerční použití. Tato licence ale musí být vždy dodávána s tímto SW. Použita byla právě tato, z důvodu použití mnoha modulů, které jsou právě pod touto licencí. V jiném případě by kombinování licencí bylo komplikované.

7.2.2

Scénáře dalšího vývoje

Takových může být hned několik. Hlavním cílem bude aplikaci stále ještě testovat a upravovat a dostat se tak z fáze Beta verze ke zcela hotové verzi. Jelikož je aplikace v podstatě klasickým krabicovým SW, musíme dbát na stálém testování a hlavně vylepšování. Být v kontaktu s uživateli a uvolňovat další verze aplikace. Mezi potenciální scénáře patří, vývoj v uzavřené komunitě. Vývoj ve zcela otevřené komunitě, např. skrz různé projekty sdílející portály jako github.com. Dále musíme zhodnotit i finanční potenciál aplikace. Je prostor pro poskytování vylepšených nestandardních verzí za peníze? Nebo je lepší vydat se cestou poskytování zpoplatněných modulů a šablon? Abychom se mohli správně rozhodnout pro co nejvhodnější další vývoj a odpovědět na všechny otázky, provedeme ke zjištění potenciálu aplikace rozsáhlé dotazníkové kampaně.

7.2.3

Rozšíření

Zde budou popsány náměty pro rozšíření funkčnosti. Některé vycházejí od připomínek testujících, jiná vyplynula z různých situací. Většina z nich nebyla implementována do aktuální verze z důvodů velké složitosti a časové náročnosti. Zároveň mohou být lákadlem v dalších verzích. Přihlašování V současné verzi je v aplikaci pouze klasická možnost přihlašování, pomocí e-mailu a hesla. Druhou možností v nějaké z dalších verzí aplikace bude přihlášení pomocí aplikace třetí

39

strany. Například pomocí aplikací Facebook nebo Google. K autorizaci u cizích aplikací použijeme framework OAuth1 . Nahrávání souborů V kapitole o použitých nechnologiích byla v souvislosti s HTML5 zmíněna funkce Drag and drop. Konkurenční aplikace tuto funkci podporují, je tak vhodné s touto funkcí do budoucna počítat. Právě proto bylo do aplikace od začátku počítáno s jazykem HTML5, ve kterém je implementace drag and drop nejsnažší díky mnoha dostupným existujícím řešením, modulům, návodům apod. Osobní obrázek u příspěvků V současné verzi chybí tzv. avatar obrázek, neboli osobní obrázek uživatele. Mít takový obrázek je dobré pro lepší orientaci v diskuzních příspěvcích. Je rychlejší identifikovat příspěvky od autora který nás zajímá podle obrázku, než podle textu jména autora. Soukromé zprávy Některým testujícím uživatelům chyběla možnost odeslat designérovi do systému zprávu, která by se netýkala žádného projektu ani obrázku. Jsou situace, kdy není vhodným místem pro zprávu v komentář ani poznámka v obrázku. Rozšiřující funkcí by mohli být soukromé zprávy, kde by bylo možné psát vybranému internímu uživateli systému (designér, administrátor), ten by měl schránku s přečtenými, nepřečtenými a odeslanými zprávami. Chat Další funkcí přidanou do některé z příštích verzí bude chat. V aktuální verzi simulují tuto komunikaci komentáře (diskuze). Několik potenciálních uživatelů samo řeklo, že živou komunikaci, nebo komunikaci přes telefon nic nenahradí. Což přesně ladí s principem této aplikace, aby byla v komunikaci s klientem podpůrná, nikoliv vše nahrazující. Ovšem to nám ovšem funkci chat v současné chvíli odsouvá na vedlejší kolej. Abychom přesně odhadli jaký by byl o tuto funkci zájem, bylo by nutné udělat v budoucnu průzkum.

7.3

Metriky

Pro přehled uvádíme základní metriky kódu a aplikace (druhé verze). Hodnoty se měřili 26.5.2014 na systému Windows 7.1. • Velikost balíčku aplikace: 3,01 MB • Velikost balíčku aplikace (ZIP): 1,29 MB • Počet řádků kódu vlastních souborů: 4747 (ve 100 souborech o celkové velikosti 214 KB) • Počet tabulek v databázi: 15 • Počet obrázků: 2 1

Více o autorizačním frameworku na http://oauth.net/.

40

• Počet a velikost Javascript souborů: 13 (438 KB) • Počet a velikost CSS souborů: 9 (153 KB) • Testování a úprava aplikace – Počet nalezených závažnějších chyb po prvním testování (ve verzi 0.1): 7 – Počet zásadnějších úprav provedených ve verzi 0.2 oproti 0.1: 22 (viz. changelog E)

7.4

Ukázka aplikace a webová prezentace

Abychom nenutili uživatele hned aplikaci instalovat u sebe, vytvořili jsme webovou prezentaci, kde naleznou ukázkovou verzi. Uvedeme tedy v tabulce 7.1 všechny důležité odkazy jako, kde si aplikaci vyzkoušet, stáhnout a další informace. A jak můžeme vidět z odkazů, pro aplikaci jsme vybrali název Work haven. Je tedy hned z názvu patrné, že je vytvořena pro usnadnění práce. Webová prezentace Demoverze administrace aplikace Demoverze portfolia aplikace Download

http://getworkhaven.com http://demo.getworkhaven.com/admin http://demo.getworkhaven.com http://getworkhaven.com/download

Tabulka 7.1: Důležité odkazy.

41

Kapitola 8

Závěr Hlavním cílem této práce bylo navrhnout, implementovat a poté otestovat webovou aplikaci zaměřenou na zlepšení komunikace mezi klientem a grafickým designérem. Na základě testování byla aplikace upravena. Práce přímo čerpá z bakalářské práce Webová aplikace, založená na frameworku ASP.NET MVC 3/Razor [1], kde byl prototyp aplikace se stejným zaměřením také navržen a implementován. Naše se ale liší v zásadních aspektech. V použitých technologiích nebo v navrženém konceptu využívání aplikace. Ve zmíněné bakalářské práci byla aplikace navržena jako sdílená. Kdy každý potenciální uživatel musel mít v aplikaci účet a sdílel tak kód aplikace a webový prostor (nikoli data) s množstvím dalších uživatelů. Naproti tomu aplikace, která je výsledkem této diplomové práce, je poskytována jako krabicový software. Uživatelé si jej musí instalovat do vhodného prostředí, které splňuje minimální požadavky. Zde se dostáváme k jednomu z hlavních úkolů, který aplikace musela splnit. Musela být pokud možno instalovatelná na co největším množství webových serverů. To kladlo důraz na výběr takových technologií, které jsou co nejvíce rozšířené. Druhým důležitým úkolem bylo zvolit takový způsob instalace aplikace, aby byl co nejjednodušší. Zvládnutelný i méně technologicky zkušenými uživateli. To vedlo k návrhu automatizované instalační procedury. Zde je stále prostor pro zlepšení, například eliminací nutnosti měnit přístupová práva k několika adresářům. Zásadní částí práce bylo testování, ze kterého vycházela i část upravování aplikace. Testování bylo prováděno uživateli, kteří aplikaci viděli poprvé a nebyli nikým proškoleni. To kladlo velký důraz na dobré zpracování uživatelského rozhraní. Během testování bylo objeveno několik chyb a nedostatků. Práce o všech chybách referuje a je navrženo jejich řešení. Po provedení změn aplikace, na základě testování, je provedeno testování druhé. Nakonec jsou zhodnoceny dosažené výsledky a dopad změn. Důležitou částí bylo i zrychlení aplikace. Podařilo se úpravami v aplikaci její rychlost načítání zmenšit. To s sebou neslo analýzu problémových míst a jejich řešení. V této fázi bylo pro ověření a vyhodnocení změn provedeno vlastní testování, pomocí kterého jsme se dostali ke konkrétním číslům, o kolik byla práce uživatelů zrychlena. I zde je stále prostor pro zlepšení. Bylo by například vhodné zoptimalizovat načítání CSS, javascriptových a obrázkových souborů. Ve chvíli psaní této práce byla aplikace ve fázi beta testování. V textu bylo navrženo a rozebráno několik možných variant dalšího vývoje. Aplikace bude po dobu několika měsíců poskytována ke stažení zdarma pod licencí MIT. Bude stále testována a vyvíjena. Hlavním úkolem v této fázi bude zjistit potenciál aplikace, jak z pohledu finančního, tak vývojového. Na základě této analýzy bude rozhodnuto, jak bude aplikace nadále vyvíjena. Zda jako 42

otevřený a zcela veřejný projekt nebo v uzavřeném týmu. Uživatelé povětšinou vůbec netuší, že aplikace podobného zaměření existuje. To je důležitá skutečnost, se kterou se s aplikací budeme muset v budoucnu vypořádávat. Na samotný závěr tedy můžeme prohlásit, že se podařilo splnit zadaný cíl. Výsledkem je plně funkční aplikace, tak jak bylo navrženo.

43

Literatura [1] Kvapil, J.: Webová aplikace založená na frameworku ASP.NET MVC 3/Razor. Bakalářská práce, Brno, FIT VUT v Brně, 2012. [2] Michal Kubíček: Velký průvodce SEO: Jak dosáhnout nejlepších pozic ve vyhledávačích. Computer Press, a.s., 2010, ISBN 978-80-251-2195-5. [3] Patrick McNeil: Inspirativní webdesign: Průvodce nejlepšími tématy, trendy a styly. Computer Press, a.s., 2011, ISBN 978-80-251-3517-4. [4] Ron Patton: Testování softwaru. Computer Press, 2002, ISBN 80-7226-636-5.

44

Dodatek A

Seznam příloh • B ER diagram schéma databáze • C Test uživatelského rozhraní • D Výsledky testování • E Changlog pro verzi aplikace 0.2 • F Seznam funkcí aplikace • G Obsah CD • H Náhledy aplikace • I Plakat

45

Dodatek B

ER diagram

Obrázek B.1: Návrh schéma databáze.

46

Dodatek C

Test uživatelského rozhraní Celková časová náročnost: 10 - 15 minut Co mě zajímá? • Jakýkoliv váš názor. • Ale hlavně, jak dlouho dlouho budou tyto testy trvat vám. Před započetím testů prosím zapněte stopky a odměřte váš čas. Využít můžete jednoduché stopky: http://www.stopky.eu 1. Přihlaste se do systému pod účtem administrátora. na adrese: http://demo.getworkhaven.com/admin/ login: [email protected] heslo: admin123 2. Přidejte do systému nového klienta. (a) Vyplňte jméno, příjmení a e-mail. 3. Přidejte do systému uživatelský účet pro designéra (vašeho zaměstnance), který bude na zakázce pro klienta pracovat. (a) Zvolte roli uživatele jako Internal“. ” (b) Nevyplňujte heslo, systém heslo pro nového uživatele vytvoří sám. (c) Zvolte Vytvořit. 4. Přidejte do systému nový projekt. (a) Jako klienta projektu zvolte vámi vytvořeného klienta. (b) Vyplňte i datum ukončení projektu (Deadline). (c) Zvolte Vytvořit. 5. U vámi přidaného projektu zvolte následující možnosti sdílení: (a) V Nastavení viditelnosti zvolte možnost Zabezpečené“. ” (b) Zadejte do pole Heslo libovolné heslo. (c) V Nastavení oprávnění zaškrtněte možnost Vše. 47

(d) Dále povolte zobrazování projektu v Portfoliu. (e) Povolte práci v teamu a zařaďte do teamu uživatele, kterého jste přidali v bodu 3). (f) Zvolte Uložit. 6. Přidejte k vašemu projektu obrázek. 7. Přejděte na adresu http://demo.getworkhaven.com. (Ocitnete se ve veřejném portfoliu, kde bude vidět váš projekt i s obrázkem.) 8. Přejděte zpět do administrace, do systémového nastavení: http://demo.getworkhaven.com/admin/system/settings. (a) Ve formuláři změňte šablonu a dejte Uložit. (b) Změní se vzhled portfolia, změnu zkontrolujte opět na adrese: http://demo.getworkhaven.com. 9. Přejděte v administraci do detailu obrázku, který jste přidávali. (a) Najděte tlačítko pro úpravu obrázku a změňte pozadí obrázku. (b) Zvolte Uložit. (c) Přidejte pod obrázek libovolný komentář. (d) Přidejte do obrázku libovolnou poznámku. Nejprve vyberte správnou akci v menu a poté klikněte do libovolného místa v obrázku. 10. Vraťte se zpět na možnosti sdílení projektu (v detailu projektu). (a) V horní části vyskakovacího boxu sdílení se nachází odkaz pro sdílení, otevřete jej (ocitnete se ve sdílení vašeho projektu, který je viditelný jen tak, jak jste si sami určili v části sdílení. Zadejte heslo, které jste určili). 11. Nakonec smažte váš obrázek ze systému. Děkuji mnohokrát. Jakékoli dotazy a připomínky pište na [email protected]

48

Dodatek D

Výsledky testování Výsledný čas (mm:ss) 08:37 13:30

15:27 17:23 09:17

14:38

11:39 10:28 11:23

10:13 12:26 14:29

Komentář Chybí mi u tlačítek v detailu obrázku bubliny, když se na ně najede myší. Nelíbí se mi ten výběr datumu a času pro deadline. Nepochopil jsem tak uplně co se po mě chce v bodě 10. Moc mi nesedí ty měnící se nabídky pod kolečkem. A ještě jak přidáváš do obrázku ty komentáře, tak bych to potvrzovací a rušící tlačítko udělal výraznější. Ale líbila se mi ta veřejná část, to co vlastně vidíš bez přihlášení. Jak jsem dělala ten uživatelskej účet pro designéra a neměla jsem vkládat heslo, tak jsem si přečetla pozdě a heslo jsem tam dala. Nechápu kdo je uživatel, designér, zákazník. . . Chybí mi tam možnost odpovídat na poznámky v obrázcích. Designove se mi to hodne líbí, vypadá to velice pekne, jen se mi to zdá málo přehledný, změnil bych nějak tu uvodní stránku

Mám mrtě lagy. Úplně v posledním kroku jsem místo obrázku smazal celý projekt. Problém mi dělala z počátku orientace, ale pak už to bylo ok.

12:34 12:48 10:13 09:54 19:20 Tabulka D.1: Výsledky testování první verze aplikace

49

Výsledný čas (mm:ss) 10:32 13:36 15:00 14:06 11:00

11:08

13:30 15:08 10:47

06:24 10:53 09:30

08:34 08:45 07:50

Komentář

Mam linux a firefox a ty dialogove (resp ty formulare) mam rozhazene. To jen btw. Jinak to vypada zajimave. Ale je pravda, ze sem tam neco neni intuitivni a musel jsem trochu patrat. Treba to menu pro obrazek jsem hned nevidel. Ale good job. Čas jsem měl 11:08. Přičemž mi dost dlouho trval bod 10. “Vrátit se zpět na možnosti sdílení“ není tak snadný jak se to může zdát (alespon pro osobu mých IT schopností). Osobně bych ocenil, kdyby ty ikony měli i nějaký text (třeba když na ni najedeš kurzorem, že se tam napíše třeba nový“ nebo ” přidat“. . . zpětně je to logický, že “+“ se asi něco přidá, ale ” novej uživatel na to chvílí kouká a ztrácí cený vteřiny z časovky). Smazání obrázku sem vůbec netušil, to jsem proklikal všechny možnosti co tam byly než se to tam našel. Jinak bych řekl, že dobrý. . . Akorát mě trochu mátlo, kdo presne jsem, to zadávání projektu, klient apod. . . Ale v reálu by mi tohle bylo jasný. 13.5 minuty, a to jsem k tomu odbíhal k práci, když se koukal šéf, takže tak 11 minut čistý čas. Ještě bych doplnil nápověkdy kdyz najedeš na tlačítka v horni liste. . . je tam jen ikonka a pro upresnění co to presně dělá by se to hodilo. Některý dialogy byly hodně rozhozený, že ulítávalo tlačítko do boku, nebo to nemělo pozadí, používám firefox. . . Tak mi to zabralo 9 a pul minuty, ale jak tam bylo ze zmenit sablonu tak jsem tam mela sablonu Look at my projects a kdyz jsem mela dat jinou tak tam bylo jen default a zadna zmena tam neprobehla nebo sem si nevsimla.

Jen teda při změně nastavení obrázku to mám nějaký rozhozený.

11:41 12:40 Tabulka D.2: Výsledky testování druhé verze aplikace.

50

Výsledný čas (mm:ss) 20:00

15:54 23:00

07:37

Komentář Trochu jsem tápal kde přidat klienta, už. Účet pro des. a ostatní, to plus je sice logický, ale v první chvíli mne to netrklo. Není to úplně pro počítačový analfabety, aby aplikaci člověk pochopil, potřeboval by min. manuál a nějakou malinkou praxi. Ale to potřebuje člověk k drtivé většině aplikací. Funkčně ale vše bylo v pořádku, nepochopil jsem akorát poslední úkol. Z mého pohledu byl největší problém s poznámkou - když jsem odjel myší z textboxu, abych klikl na save note, tak ten textbox zmizel včetně toho save note“. Plus bych asi ” přivítal nějakou informaci o tom, že je to přidávání poznámky aktivní (intuitivně jsem čekal, že ten textbox se objeví vedle kurzoru a kliknutím ho umístím kam chci), např. změnou barvy pozadí příslušné ikony. . . Můj první dojem byl “co to s. . . .a je“ a první úkol (“Přidejte do systému nového klienta.“, ještě bez návodu kam klikat) mi dal docela zabrat, a to si nepřipadám jako idiot. To tlačítko pro přidání nikdy nebylo tam, kde jsem ho čekal - chci přidat klienta, na homepage to není, tak kliknu Klienti, tam to není, hm co dál?

Tabulka D.3: Výsledky testování druhé verze aplikace.

51

Pokus č. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Nejlepší čas Nejhorší čas Medián Průměr

Lightbox 00:16 00:16 00:14 00:16 00:12 00:11 00:10 00:10 00:12 00:11 00:11 00:11 00:12 00:11 00:12 00:11 00:11 00:11 00:14 00:11 00:10 00:16 00:11,00 00:12,15

Bez lightboxu 00:17 00:16 00:16 00:13 00:12 00:13 00:13 00:13 00:13 00:12 00:13 00:13 00:12 00:14 00:12 00:14 00:13 00:12 00:12 00:13 00:12 00:17 00:13,00 00:13,30

Tabulka D.4: Výsledky testů na rychlost práce s formuláři.

52

Dodatek E

Changlog pro verzi aplikace 0.2 17.5. 2014 - Jednotlivé šablony byly přesunuty do webroot/themes/, tak jak bylo navrhováno. 13.5.2014 - V detailu obrázku ve sdílení bylo pro všechny návštěvníky viditelná volba pro smazání, editaci a další manipulaci s obrázkem. Toto bylo zrušeno. 24.4.2014 - Opraveny chyby při instalaci. - Při smazání uživatele jeho projekty v systému zůstávají. 21.4.2014 - Při přidání nového obrázku/komentáře/poznámky se odesílají notifikační e-maily zainteresovaným lidem. 20.4.2014 - Nový vzhled formulářů. - V administraci v systémovém nastavení lze přidat logo (to se pak zobrazuje např. v portfoliu - podle použité šablony). 19.4.2014 - V administraci lze vybral hlavní jazyk systému (pro překladový systém a nově i pro html atribut lang: ). ” - Při vytvoření účtu nového uživatele je mu na e-mail odeslána zpráva s přihlašovacími údaji. 18.4.2014 - V administraci v systémovém nastavení lze přidávat hlavní e-mail systému/firmy a poté tento e-mail např. vystupuje jako odesílatel notifikačních e-mailů apod. - V detailu obrázku byly zrušeny malé ikony pro přidávání poznámek do obrázku. Byly nahrazeny většími ikonami a přesunuty do menu akcí. - Pokud přidáváme obrázek do projektu přímo z detailu daného projektu, ve formuláři zobrazeném v lightboxu se nezobrazuje položka Projekt (jak bylo dříve). - Formuláře pro přidávání klienta, uživatele, obrázku, projektu (pod tlačítkem + v hlavním menu) se zobrazují do lightboxu. 10.4.2014 - Přidána funkce zaslání nového hesla v případě jeho zapomenutí. 4.4.2014 - Úvodní stránka administrace byla doplněna o výpis poslední aktivity. - Detail klienta ma stejnou strukturu jako detail projektů. Do detailu klienta byl přidán i výpis jeho projektů. 53

- K položkám menu v detailu projektů byly přidány bubliny“ při najetí myší (atribut title). ” - Menu akcí v detailu obrázku. - Opravena chyba přiřazení diskuze k novému obrázku, při uploadu více obrázků najednou. - Nové zobrazování detailu projektu. - Nový způsob editace projektu. - Pro detail projektu byly zrušeny volby Smazání a Sdílení nacházející se pod tlačítkem Nastavení“ v hlavním menu. Tyto akce byly přesunuty pod odkazy přímo v detailu pro” jektu.

54

Dodatek F

Seznam funkcí aplikace 1. Systém s rozsáhlou administrací a správou uživatelských účtu se dvěma rolemi. (a) administrátor (b) designér 2. Evidence a správa projektů. 3. Evidence a správa obrázků. 4. Evidence a správa klientů + přiřazení projektů ke klientům. 5. V administraci je možné nastavit obsah meta tagů description, keywords, copyright a tagu title. Dále logo pro použití v šablonách pro portfolio. 6. Pokud uživatel zapomene heslo může si nechat poslat nově vygenerované na e-mail. 7. Uživatel si může v administraci změnit heslo ke svému účtu. 8. Více dostupných jazyků. V tuto chvíli angličtina a čeština. 9. Jazyk je nastavován pro celou aplikaci (html tag lang) a zároveň si každý uživatel může nastavit jazyk preferovaný pro svůj účet. 10. Aplikace automaticky odešle na e-mail nového uživatele zprávu o vytvoření účtu a informace o přihlášení. 11. Systém odesílá zainteresovaným uživatelům notifikační e-mail zprávy při přidání nových obrázků, komentářů, poznámek. 12. Široké možnosti práce s obrázky. (a) Každému obrázku může být nastavena barva pozadí. Designér tím může ovlivnit co nejhezčí zobrazování svého návrhu. (b) Možnost komentování obrázků. (c) Možnost poznámek přímo do obrázků. 13. Zařadit projekt do portfolia nebo jej z portfolia vyloučit. 14. Zařadit obrázek do portfolia nebo jej z portfolia vyloučit. 55

15. Šablonovací systém portfolia (pro snadnou změnu vzhledu, funkcí, obsahu portfolia). 16. Široké možnosti sdílení. Projekt může být sdílen s následujícími možnostmi: (a) soukromý (b) veřejný (c) zaheslovaný (d) teamová práce (pro vybrané uživatele)

56

Dodatek G

Obsah CD /aplikace/v0.1-Hadaikum/ /aplikace/v0.2-Hadaikum/ /plakat/ /nahledy/ /vysledna-zprava/ /text/ /text/fig/ /errors/ /excel/

První verze aplikace. Druhá verze aplikace. Plakát. Náhledy aplikace. Výsledná PDF zpráva. Latex šablona s textem práce. Obrázky použité v práci. Obrázky v textu zmíněných chyb. Excel soubory s výsledky testování, grafy a výpočty.

57

Dodatek H

Náhledy aplikace

Obrázek H.1: Domácí stránka aplikace s nejnovější aktivitou v systému.

58

Obrázek H.2: Detail klienta s jeho projekty.

Obrázek H.3: Detail projektu.

59

Obrázek H.4: Detail návrhu s přidáváním poznámky.

Obrázek H.5: Detail návrhu se změnou barvy pozadí.

60

Obrázek H.6: Ukázka formuláře. Přidání nového projektu.

Obrázek H.7: Portfolio. Vlevo s šablonou orientovanou na projekty. Vpravo šablona zobrazující pouze obrázky.

61

Obrázek H.8: Možnosti sdílení projektu.

Obrázek H.9: Veřejně sdílený obrázek s možností komentování i poznámek.

62

Dodatek I

Plakat

63