Podpora prodeje osobní elektroniky. Jiří Brhel

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

Bakalářská práce

Podpora prodeje osobní elektroniky Jiří Brhel

Vedoucí práce: Ing. Miroslav Balík Ph.D.

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

iv

v

Poděkování Chtěl bych poděkovat zaměstnancům společnosti mivvy a.s. za spolupráci při tvorbě i finálním nasazení tohoto informačního systému.

vi

vii

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

V Praze dne 26. 5. 2010

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

viii

Abstract The goal of this bachelor thesis is to analyse, project and create aplication for sales promotion of personal electronics via Internet. Primary objective is to satisfy the requirement for multilinguality, expandability and utilisation of system of warranty control.

Abstrakt Cílem této bakalářské práce je analyzovat, navrhnout a vytvořit aplikaci pro podporu prodeje osobní elektroniky prostřednictvím Internetu. Mezi hlavní požadavky patří multijazyčnost, rozšiřitelnost a využití systému pro správu reklamací.

ix

x

Obsah 1 Úvod

1

2 Popis problému, specifikace cíle 2.1 Základní popis problému a jeho řešení . . . . 2.2 Obecné požadavky na systém . . . . . . . . . 2.3 Cílová skupina . . . . . . . . . . . . . . . . . 2.4 Popis struktury ve vztahu k vytyčeným cílům 2.5 Rešerše . . . . . . . . . . . . . . . . . . . . . 2.5.1 CMS aplikace . . . . . . . . . . . . . . 2.5.2 WordPress . . . . . . . . . . . . . . . . 2.5.3 AiPublisher . . . . . . . . . . . . . . . 2.5.4 jNetPublish . . . . . . . . . . . . . . .

. . . . . . . . .

3 3 3 4 4 4 4 4 5 5

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

7 7 7 7 8 8 9 9 10 10 10 11 11 11 11 12 12 12 12 12 14 14

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3 Analýza a návrh řešení 3.1 Životní cyklus produktu . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Dosavadní přístup k životnímu cyklu produktu . . . . . . 3.1.2 Přístup k životnímu cyklu produktu po zavedení systému 3.2 Katalog požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Požadavky pro prezentaci produktů . . . . . . . . . . . . . 3.2.2 Požadavky pro podporu prodeje . . . . . . . . . . . . . . . 3.2.3 Nefunkční požadavky kladené na systém . . . . . . . . . . 3.3 Vícejazyčný systém . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Autorizace koncových prodejců . . . . . . . . . . . . . . . . . . . 3.5 Rozdělení do modulů . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Případy užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Uživatelské role . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Everyone . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.3 Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.4 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.5 Seller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.6 Servis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.7 Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Diagram aktivit průběhu reklamace . . . . . . . . . . . . . . . . . 3.9 Implementační prostředí . . . . . . . . . . . . . . . . . . . . . . . xi

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

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

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

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

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

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

xii

OBSAH 3.10 Dostupné frameworky . 3.10.1 Nette . . . . . . 3.10.2 CakePHP . . . . 3.10.3 Zend framework 3.11 Výběr frameworku . . . 3.12 Wysiwyg editor . . . . . 3.13 Statistiky . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 Realizace 4.1 Využité technologie . . . . . . . . . . . . 4.2 Adresářová struktura . . . . . . . . . . . 4.3 Rozdělení layoutů . . . . . . . . . . . . . 4.4 Modularita systému . . . . . . . . . . . 4.5 Controllery . . . . . . . . . . . . . . . . 4.6 Funkce controllerů . . . . . . . . . . . . 4.7 Použité komponenty Zend frameworku . 4.7.1 Zend_Auth . . . . . . . . . . . . 4.7.2 Zend_Acl . . . . . . . . . . . . . 4.7.3 Zend_Controller_Router . . . . 4.7.4 Zend_PDF . . . . . . . . . . . . 4.7.5 Zend_Validate . . . . . . . . . . 4.8 Implementace nestandardních řešení . . 4.8.1 Zjištění stavu reklamace . . . . . 4.8.2 Zjištění dostupné lokalizace . . . 4.8.3 Genrerování čísla RMA protokolu 4.9 Implementace wysivygového editoru . . 4.10 Implementace Mootools LightBox . . . . 4.11 Implementace grafického rozhraní . . . . 4.12 Problémy během implementace . . . . . 4.13 Implementace instalátoru . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

5 Testování 5.1 Testování front-end části . . . . . . . . . . . . . . . . . . . . 5.1.1 Validace dle standardů W3C . . . . . . . . . . . . . 5.1.2 Zobrazení prezentace . . . . . . . . . . . . . . . . . . 5.1.3 Přístupnost formuláře registrace koncového prodejce 5.1.4 Přístupnost formuláře pro vložení nové reklamace . . 5.1.5 Fulltextové vyhledávání . . . . . . . . . . . . . . . . 5.1.6 Přístupnost vyhledávačů . . . . . . . . . . . . . . . . 5.2 Testování back-end části . . . . . . . . . . . . . . . . . . . . 5.3 Korektnost zobrazení uživatelského rozhraní . . . . . . . . . 5.4 Testování uživatelského rozhraní . . . . . . . . . . . . . . . 5.5 Přínosy testování back-end části . . . . . . . . . . . . . . . . 5.5.1 Formulář lokalizace produktu . . . . . . . . . . . . . 5.5.2 Vyhledávání reklamací . . . . . . . . . . . . . . . . . 5.5.3 Ukládání nastavení filtrů . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

. . . . . . .

14 14 15 15 15 15 15

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

17 17 17 18 18 18 19 19 19 20 20 21 22 22 22 22 23 23 24 24 24 24

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

27 27 27 27 27 28 28 28 28 28 29 29 29 29 29

OBSAH

xiii

6 Závěr 31 6.1 Naplnění cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2 Další rozvoj projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Literatura

33

7 Seznam použitých zkratek

35

8 UML diagramy

37

9 Instalační a uživatelská příručka 9.1 Zkopírování souborů na server . 9.2 Spuštění instalace . . . . . . . . 9.3 Nastavení služby Cron . . . . . 9.4 Spuštění systému . . . . . . . . 9.5 Vývojové prostředí . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

41 41 41 41 42 42

10 Obsah přiloženého CD

43

11 Obrázky ze systému

45

xiv

OBSAH

Seznam obrázků 3.1 3.2

Typický životní cyklus produktu na Internetu . . . . . . . . . . . . . . . . . . 7 Uživatelské role v systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8.1 8.2 8.3 8.4

Řešení požadavku na vícejazyčný systém Diagram aktivit průběhu reklamace . . . USE-CASE diagram správy produktu . USE-CASE diagram správy reklamace .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

37 38 39 40

10.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1 11.2 11.3 11.4

Úvodní stránka administračního rozhraní . . . Přehled produktů . . . . . . . . . . . . . . . . Úvodní vzhled stránek mivvy a.s. - EN verze Výstupní reklamační protokol . . . . . . . . .

xv

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

45 46 47 48

xvi

SEZNAM OBRÁZKŮ

Kapitola 1

Úvod Zadání práce vzniklo na podnět společnosti mivvy a.s. [1], jež se zabývá distribucí a prodejem výpočetní a komunikační techniky nejen v České republice, ale také v zahraničí. V dnešní době je součástí úspěchu bezesporu také kvalitní webová prezentace společnosti, s jejíž pomocí jsou prezentovány jak samotné produkty, tak další důležité informace pro spotřebitele i distributory. Z tohoto důvodu je potřeba vytvořit systém, jež umožní spravovat obsah prezentace s důrazem na informace o produktech. Nedílnou součástí je i využití systému k evidenci koncových prodejců a jejich možnou bonifikaci, v rámci této podpory je zahrnuta i možnost vyřizování reklamací prostřednictvím Internetu.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle 2.1

Základní popis problému a jeho řešení

Výsledný systém by ve své podstatě měl fungovat jako CMS z hlediska správy obsahu, navíc však obohacený o prvky obstarávající podporu prodeje. Cílem pak je navrhnout a implementovat systém, který bude nejenom splňoval požadavky ze strany mivvy a.s., ale bude jednoduše přizpůsobitelný požadavkům jiných klientů.

2.2

Obecné požadavky na systém

Celá architektura systému by měla být navržena s ohledem na rozšiřitelnost a možnou variabilitu použití dle konkrétních požadavků. Z tohoto důvodu by měl být systém navržen tak, aby přidání jakéhokoli dalšího funkčního prvku neovlivňovalo stávající prvky systému. Systém tohoto typu je pak možné označit za modulární. Dalším základním požadavkem je možnost prezentovat obsah v tzv. front-end části systému ve více jazycích. Tento systém bude především zaměřen na produkty jako jsou mobilních zařízení, mini-notebooky, MP4 přehrávače, apod. Z tohoto důvodu je potřeba spravovat také položky související s těmito produkty. Do této kategorie spadají například ovladače, software ke stažení a další. Je důležité, aby vytvoření produktové stránky, která bude popisovat daný produkt spolu s jeho příslušenstvím bylo pokud možno co nejjednodušší a celý proces působil intuitivně. Nedílnou součástí tohoto systému budou také moduly pro podporu prodeje. Tyto moduly musí umožnit registraci koncových prodejců, jejich evidenci a vyhledávání v seznamech prodejců. Úkolem systému také bude možnost zadávání a zprávy reklamací. Tyto reklamace budou zadávány on-line a mimo uložení informací o reklamaci, je nutné také zajistit generování reklamačních protokolů. Systém podpory prodeje pak bude dostupný pouze pro koncové prodejce, jejichž místem podnikání je Česká republika a Slovenská republika. Díky tomto požadavku pak odpadá nutnost lokalizace sekce podpora prodeje do jiného než českého jazyka. 3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

2.3

Cílová skupina

Cílovou skupinu můžeme rozdělit na dvě části. První skupinou jsou návštěvníci, kteří prohlížejí webovou prezentaci firmy, tzv. front-end. S ohledem na ně musí systém splňovat určité základní požadavky, především na přístupnost a na snadnou orientaci. Do této skupiny patří i koncoví prodejci, kteří do systému budou zadávat různá data. S tímto faktem je nutno počítat během implementace. Druhou skupinou jsou pak uživatelé, kteří budou využívat administračního rozhraní, tzv. back-end (typicky zaměstnanci mivvy). U těchto uživatelů se předpokládá znalost základních principů na poli internetových aplikací. Proto při návrhu administračního rozhraní budu vycházet ze standardních návrhových vzorů.

2.4

Popis struktury ve vztahu k vytyčeným cílům

V první části práce popisuji analýzu daného problému, možná řešení a odůvodňuji volbu implementačního prostředí. V druhé části se pak popisuji realizaci a samotnou implementaci ve zvoleném implementačním prostředí, navíc se zaměřením na nestandardní části řešení.

2.5

Rešerše

Aplikací CMS existuje v současné době celá řada a to jak ve formě placených, tak i volně šiřitelných systémů. S ohledem na požadavky však bylo nutné použít vlastní řešení, neboť tyto požadavky na funkční prvky podpory prodeje jsou natolik specifické, že jdou zcela nad rámec možností standardních CMS systémů. Přesto jsem pracoval také s dostupnými CMS systémy nebo pouze analyzoval jejich práci s obsahem, tak abych mohl s jistotou říct, že můj systém dává uživateli nadstandardní možnosti přizpůsobení uživatelského rozhraní se zachováním jednoduchosti editace.

2.5.1

CMS aplikace

K analýze jsem využil následujících aplikací: • WordPress[2] • AiPublisher[3] • jNetPublish[4]

2.5.2

WordPress

WordPress patří mezi velmi populární blog systémy. Tento systém patří mezi volně šiřitelné a jak z podstaty blogů vyplývá, je zaměřen především na textový obsah. V rešerši mi tento systém pomohl z hlediska uživatelského rozhraní - GUI. Jednoduché a přehledné rozhraní tohoto systému přispělo k finálnímu minimalistickému vzhledu kompletního administračního rozhraní.

2.5. REŠERŠE

2.5.3

5

AiPublisher

AiPublisher patří do skupiny placených aplikací. Za cenu cca 10 000 Kč představuje poměrně silný nástroj pro správu obsahu. Avšak za velkou nevýhodu považuji nepřiměřenou složitost elementárních operací a také nepříliš propracované uživatelské prostředí. Na druhou stranu lze prostřednictvím administračního rozhraní změnit kompletní vzhled webové prezentace, což považuji za neoddiskutovatelnou přednost.

2.5.4

jNetPublish

Aplikace jNetPublish již spadá do kategorie nadstandardních a poměrně nákladných systémů. Je pravděpodobné, že by se bylo možné dohodnout s firmou Et netera s.r.o. na implementaci nových funkcionalit pro potřeby podpory prodeje, neboť jNetPublish stojí za prezentacemi firem jako např. TicketPro, Siemens, Staropramen a dalších. Tento systém také disponuje širokými možnostmi modifikace prezentovaného obsahu. Avšak klade také nadstandardní požadavky na ovládání a jeho cena přesahuje finančními požadavky společnosti mivvy a.s.

6

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

Kapitola 3

Analýza a návrh řešení 3.1

Životní cyklus produktu

Po analýze požadavků ze strany mivvy a.s. jsem byl schopný vytvořil diagram popisující typický životní cyklus produktu na Internetu.

Obrázek 3.1: Typický životní cyklus produktu na Internetu

3.1.1

Dosavadní přístup k životnímu cyklu produktu

V současné době jsou všechny procesy, které jsou na obrázku 3.1 vyobrazeny zelenou barvou prováděny přímým zásahem do zdrojového kódu. To znamená, že administrátor stránek vytváří pro každý produkt novou statickou stránku. S tím souvisí nutnost editovat stránky, které na tento produkt odkazují (tzn. menu apod.). Tento přístup je velmi náročný na čas, přehlednost a validitu kódu.

3.1.2

Přístup k životnímu cyklu produktu po zavedení systému

Po zavedení systému do provozu bude uživatel, pokud mu to jeho systémová role umožní, moci jednoduše přidat produktovou kartu s podrobnými informacemi. Tvorba produktové karty bude podřízena produktovému formuláři, který bude obsahovat veškeré potřebné údaje určené k publikaci. Mimo jiné bude na produktové kartě k dispozici možnost výběru souborů ke stažení (ovladače, manuály, apod.). 7

8

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

Uživatel tak bude moci každému produktu jednoduše přidat soubor či soubory, jež se ve výsledku zobrazí spolu s informacemi o vlastním produktu. V souvislosti s životním cyklem produktu bude také potřeba zajistit možnost dočasného skrytí produktu nebo přesunutí produktu do archívu.

3.2

Katalog požadavků

Katalog požadavků rozdělím do dvou sekcí a to podle toho, zda jde o požadavky na prezentaci produktů, nebo oblast podpory prodeje. V níže uvedením katalogu považuji za editaci možnost danou položku vytvořit, smazat nebo upravit.

3.2.1

Požadavky pro prezentaci produktů

Systém musí umožnit • nastavení jazykových verzí, • správu sekcí, možnost editace a změny pozice položek, • správu produktů, editaci produktů, • přesunutí produktu do archívu a zpět, • nastavení produktu jako neviditelný, • správu lokalizací produktů, • vyhledávání produktů v administrační části, • fulltextové vyhledávání, • správu položek ke stažení a jejich editaci, • lokalizaci položek ke stažení, • základní editace stylů produktových karet, • vkládání krátkých zpráv (novinek) na úvodní stránku, • editaci vybraných statických stránek (kontakt, o nás, atd.), • částečnou editaci vzhledu prezentovaných dat, • vkládání krátkých aktualit, • správu úvodní stránky - reklamních ploch, • rozdělení do rolí a jejich oprávnění k přístupu, • správu uživatelů

3.2. KATALOG POŽADAVKŮ

3.2.2

9

Požadavky pro podporu prodeje

Systém musí umožnit • evidenci koncových prodejců, • přihlášení prodejců do zabezpečené sekce, • on-line vkládání reklamací, • generovaní reklamačního PDF na straně prodejce, • generovaní reklamačního PDF na straně servisního centra, • generovaní přístupových údajů prodejcům, • správu reklamací a jejich vyhodnocování, • vyhledávání v reklamacích

3.2.3

Nefunkční požadavky kladené na systém

Mezi nefunkční požadavky lze zařadit, tzv. SEO optimalizaci. Na bázi návrhu a implementace systému je jedním z hlavních požadavků využití tzv. hezkých URL, které napomáhají k správné indexaci obsahu internetovými vyhledávači. Grafická reprezentace dat musí odpovídat webovému manuálu společnosti mivvy a. s. a systém musí být přizpůsoben stávajícímu vzhledu prezentační části. Dalším požadavkem je vytvoření přístupné prezentace (front-endu). Zde patří také korektní vykreslení webové prezentace v internetových prohlížečích Internet Explorer 7/8, Firefox, Opera, Safari a Chrome. Spolu s tím je nutné zajistit také validní kód prezentace a využití netabulkového layoutu. Systémové nároky byly stanoveny s ohledem na běžné hostingové služby: • PHP 5.1.2 a vyšší, • MySQL 5.0.41, • phpMyAdmin, • Cron, • zálohování databázi, • diskový prostor 5 GB a vyšší, • rozsáhlé možnosti administračního prostředí, • dostupnost on-line podpory

10


3.3

Vícejazyčný systém

Jedním ze základních požadavků bylo zobrazení obsahu ve více jazykových verzích. Původní verze měla nastaveny pevně tři jazyky (čeština, angličtina a němčina). Nový systém by měl řešit tento problém mnohem komplexněji a bez ohledu na počet jazykových rozhraní. Bylo tedy nutné nalézt řešení tohoto problému, a to stále s ohledem na zachování dalších požadavků (především na SEO). Rozhodl jsem se tento požadavek vyřešit pomocí separace obsahu, který se neliší mezi jednotlivými jazykovými verzemi (kategorie produktu, fotografie, soubory ke stažení) a obsahu, který se mění v závislosti na zvoleném jazyku (specifikace a další textové informace). V implementační rovině toto rozdělení zajistí dvě tabulky, kdy jedna bude uchovávat informace textového charakteru, tedy závislé na jazykovém nastavení a druhá bude uchovávat pouze informace nezávislé na zvoleném jazyku. Toto řešení zjednodušeně popisuje diagram na obrázku 8.1. Na základe požadavků společnosti je možné využít přístupu, kdy produkty v jednom jazyce jsou množinou všech dostupných produktů v systému. Tento jazyk můžeme označit za primární. To znamená, že pokud bude uživatel chtít přidat produkt v jiném než primárním jazyce, bude muset pro tento produkt nejprve existovat vzor v jazyce primárním. Od tohoto vzoru pak dědí informace další jazykové mutace. Při nasazení systému pro společnost mivvy a.s. je tímto jazykem čeština. Tato volba však nebude v systému implementována nastálo, ale lze ji změnit dle požadavků klienta.

3.4

Autorizace koncových prodejců

Autorizace koncových prodejců je zavedena z důvodu omezení přístupu uživatelů nespadajícím do kategorie koncových prodejců společnosti mivvy a.s. do sekce podpory prodeje. Každou žádost o zařazení do seznamu prodejců bude ověřovat pracovník společnosti mivvy. Po autorizaci prodejce budou vygenerovány přihlašovací údaje a tyto pak budou odeslány prostřednictvím emailu koncovému prodejci.

3.5

Rozdělení do modulů

Pro další analýzu a následnou implementaci je potřeba všechny požadavky rozdělit do modulů, ke kterým bude možné přistupovat jako k samostatným prvkům. Toto rozdělení nám také pomůže při určení uživatelských rolí vyskytujících se v systému. Rozdělení do modulů je tedy následující: • Informační stránka • Sekce • Produkty • Soubory ke stažení

3.6. PŘÍPADY UŽITÍ

11

• Vzhled • Prodejci • Servis • Nastavení • Koncoví prodejci • Default

3.6

Případy užití

Některé z uvedených případů užití jsou zobrazeny v příloze v kapitole USE-CASE diagramy. Pro snadnější orientaci jsem také rozebral možnosti jednotlivých rolí slovně.

3.7

Uživatelské role

Pro správu systému je potřeba rozdělit uživatelské role tak, aby uživatelé systému měli přístup pouze do těch modulů, které jsou schopni a zároveň oprávnění spravovat. Systém bude tedy obsahovat následující role: everyone, vendor, seller, servis, editor a supervisor. Vztahy mezi jednotlivými rolemi a jejich přístup do modulů popisuje obrázek 3.6. Navíc je zde role Zákazníka (Customer), která zde znázorňuje nutnost kontaktovat Prodejce (Seller) pro vyřízení reklamace. V diagramu na obrázku 3.6 nemá ’uživatel’ zákazník žádnou roli, jde o osobu která může reklamovat produkt bez nutnosti interakce se systémem.

3.7.1

Everyone

Toto je základní role, která umožňuje komukoliv prohlížet front-end část webu, vyhledávat produkty, stahovat soubory ke stažení, prohlížet statické stránky a také umožňuje přístup k formuláři pro registraci koncového prodejce. Tato role je generována systémem automaticky a je přidělena každému uživateli systému, který do systému není přihlášen.

3.7.2

Vendor

Tato role dědí vlastnosti role Everyone a zároveň opravňuje uživatele pro přístup do sekce koncového prodejce. V této sekci může koncový prodejce zadávat nové reklamace, kontrolovat stav zadaných reklamací a může si zde změnit své osobní údaje vedené v systému.

12

3.7.3


Admin

Základní administrační role systému opravňující uživatele k přístupu do administrace a samozřejmě prohlížení front-end části, jelikož dědí vlastnosti Everyone. Tento uživatel má možnost pouze editovat své osobní údaje, prohlížet si informační stránku a vidí informace o tom, kdo mu může změnit jeho přístupová privilegia. Oproti zažitým pravidlům nedisponuje tato role neomezeným přístupem k administračnímu rozhraní.

3.7.4

Editor

Tato role dědí vlastnosti role Admin, poskytuje uživateli přístup do modulů Sekce, Produkty, Soubory ke stažení. Uživatel s touto rolí má možnost přidávat nové sekce, editovat jejich názvy a měnit pozici (řadit položky menu). Dále umožňuje přidávat produkty a jejich následnou editaci či lokalizaci. Také je uživateli s touto rolí umožněno přidávat nové položky ke stažení a k dispozici má také správu kategorií položek ke stažení.

3.7.5

Seller

Tato role dědí vlastnosti role Admin, navíc umožňuje uživateli přístup do modulu Prodejci. Zde může uživatel prohlížet prodejce, prohlížet nové registrace a následně tyto registrace autorizovat nebo odstranit.

3.7.6

Servis

Tato role dědí vlastnosti role Seller a umožňuje uživateli přístup do modulu Servis. V modulu Servis má uživatel k dispozici přehled reklamací zadaných uživatelem s rolí Vendor. V těchto reklamacích může vyhledávat, prohlížet zadané reklamace, případně tyto reklamace řešit. Přístup do modulu Seller je povolen z praktických důvodů. Je totiž možné, že servisní technik bude potřebovat získat některé informací o koncovém prodejci, které nejsou uvedeny v reklamačním protokolu. Zavedením této role jsem omezil nutnost komunikace mezi servisním a obchodním oddělením společnosti.

3.7.7

Supervisor

Tato role má přístup do všech modulů. Jde o roli která má mimo jiné možnost editace vzhledu webové prezentace a zároveň jí je umožněno přidávat a mazat uživatele. Jako jediná má možnost přidávat nové lokalizace webu.

3.7. UŽIVATELSKÉ ROLE

Obrázek 3.2: Uživatelské role v systému

13

14


3.8

Diagram aktivit průběhu reklamace

Pro potřebu analýzy průběhu reklamace byl vytvořen diagram aktivit, obrázek 8.2, znázorňující vložení a průběh on-line reklamace. Reklamaci ukládá do systému uživatel s rolí vendor. Při uložení do systému se zároveň vygeneruje reklamační protokol, který je pak odeslán spolu se zásilkou. Od této chvíle je možné reklamaci sledovat v systému. Tato reklamace může mít hned několik stavů: • Čeká se na doručení • Reklamace se zpracovává • Reklamace vyřízena Stav ’čeká se na doručení’ je stav, který nastane bezprostředně po vyplnění RMA formuláře a trvá až do doby, kdy bude zásilka od prodejce doručena do servisního střediska. Zde ji servisní technik přijme a změní její stav na ’reklamace se zpracovává’. Tento stav indikuje prodejci, že zásilka úspěšně dorazila do servisního centra. Po dokončení reklamace již může technik zvolit stav ’reklamace vyřízena’ a reklamaci odeslat. Při tomto procesu systém zároveň vygeneruje reklamační protokol o provedené reklamaci.

3.9

Implementační prostředí

Implementační prostředí volím z řady PHP frameworků, které podporují práci z databázemi MySQL. Implementace pomocí frameworku má hned několik výhod: • Frameworky poskytují velké množství užitečných knihoven • Frameworkový přístup udržuje logickou architekturu systému • Frameworky nabízejí dobrý základ pro modulární systémy Pro tento projekt využiji některého z frameworků založeného na architektuře typu MVC, která rozděluje datový model aplikace, uživatelské rozhraní a řídicí logiku do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. Mezi tyto komponenty patří model, view a controller. K dispozici je několik MVC frameworků, mezi volně šiřitelné patří například Nette, CakePHP či Zend Framework.

3.10 3.10.1

Dostupné frameworky Nette

[5] Nette framework patří k open-source projektům. Za vývojem stojí v současné době skupina Nette Foundation, která je složena převážně z českých vývojářů. Mezi výhody tohoto frameworku patří čistě objektový návrh využívající interface, vysoká výkonnost a také existence českého fóra.

3.11. VÝBĚR FRAMEWORKU

3.10.2

15

CakePHP

[6] Framework distribuovaný pod licencí MIT patří taktéž k oblíbeným frameworkům. Dokumentace k tomuto frameworku je většinou v anglickém jazyce. Co se týče rychlosti je vesměs srovnatelná s Zend frameworkem.

3.10.3

Zend framework

[7] Zend framework je distribuován pod licencí BSD. Jde o velmi rozšířený a v současné době populární framework. Jeho nespornou výhodou je rychlý vývoj a velmi kvalitní dokumentace. Dokumentace se nesoustředí jen na vysvětlení základních pojmů, ale vše podstatné demonstruje na příkladech. V poslední verzi frameworku se také podstatně zvýšila rychlost práce s databází. k nimž lze přístupovat pomocí knihovny PDO.

3.11

Výběr frameworku

Pro implementaci jsem nakonec zvolil Zend framework a to především z toho důvodu, že v něm již delší dobu pracuji a po čas jeho vývoje od verze 1.5 až po dnešní 1.8.2 jsem zaznamenal velký pokrok nejenom v rychlosti, ale také ve snaze držet se doporučených standardů. Další výhodu je kvalitní IDE vývojové prostředí s nativní podporou Zend frameworku. Jde o Zend Studio 6[8], které je z dílny společnosti Zend. Podobnost v názvu frameworku a názvu společnosti Zend není náhodná, právě tato silná společnost stojí za vývojem Zend frameworku, což mimo jiné zaručuje stabilní vývoj tohoto frameworku.

3.12

Wysiwyg editor

Dalším důležitým krokem je umožnit uživateli základní modifikaci textového výstupu. Jelikož však není možné klást na uživatele požadavky na modifikaci textů pomocí tagů nebo CSS stylů je třeba zahrnout do systému wysivigový editor. Mezi nejběžněji používané volně dostupné wysivigové editory patří TinyMCE nebo FCKeditor. Oba z těchto editorů poskytují široké možnosti a jsou prakticky srovnatelné. Osobně jsem zvolil TinyMCE z důvodu, že s ním mám dlouhodobé zkušenosti.

3.13

Statistiky

Jedním z požadavků bylo zajištění statistik návštěvnosti webové prezentace pro marketingové účely. Nejprve jsem chtěl tento požadavek implementovat do systému svépomocí. Avšak v době kdy jsem na systému začal pracovat se do podvědomí dostávala aplikace Google Analytics. Tato služba je poskytována zdarma a nabízí mnoho užitečných informací prostřednictvím přivětivého rozhraní. Jelikož už systém samotný poskytuje vcelku široké možnosti rozhodl jsem se pro účely evidence statistik využít právě Google Analytics.

16


Kapitola 4

Realizace 4.1

Využité technologie

Implementaci jsem prováděl s aktuálními verzemi následujících technologií: • Zend framework 1.8[7] • PHP 5.1.2 • MySQL 5.0.41.

4.2

Adresářová struktura

Prvním důležitým krokem bylo navržení vhodné adresářové struktury. V tomto směru práci ulehčí použitý framework, který má doporučenou adresářovou strukturu. Použité IDE prostředí Zend studio 6 navíc tuto strukturu generuje vždy při vytváření nového Zend framework projektu. Poté stačilo již jen doplnit adresáře, jež budou potřeba navíc. Adresářová struktura projektu je následující: /application /admin /default /htdocs /index.php /styles /images /library /MyLibrary /Zend 17

18

KAPITOLA 4. REALIZACE

4.3

Rozdělení layoutů

Layoutem se dá nazvat uspořádání stránky. Stránky, které se skládají z administračního a prezentačního rozhraní většinou vždy potřebují minimálně dva takovéto layouty. V tomto systému tedy rovněž využívám dvou layoutů, jeden pro sekci default a druhý pro sekci admin. Součástí každého layoutu je kostra stránky obsahující základní konstrukční elementy jako jsou tagy, definice css stylů a externích javascriptů. Tato kostra má pak jednotný vzhled v celém systému a mění se pouze obsah uvnitř této kostry.

4.4

Modularita systému

Oproti předchozí verzi systému, kdy jsem s každým modulem vytvářel novou složku modulu ve složce application jsem se nyní rozhodl reprezentaci modulů ponechat pouze na zvolených controllerech. Systém tedy obsahuje složky ’admin’ a ’default’. Ve složce admin soustřeďuji skripty společné pro back-end a ve složce "default"pak skripty společné pro front-end. Rozdělení modulů na controllery zpřehlednilo systém a umožnilo jednodušší zprávu uživatelských rolí, resp. jejich přístupu do jednotlivých sekcí.

4.5

Controllery

V části back-end se vyskytují tyto controllery: • IndexController • SectionsCotrnoller • ProductsController • DownloadController • AppeareanceController • SellerController • ServisController • SupervisorController • UserController Z názvů controllerů je celkem zřejmá jejich souvislost s moduly. Oproti rozvržení do modulů je zde ještě jeden ’interní’ controller User, který se stará o záležitostí týkající se uživatelského nastavení (jméno, heslo, atd.). Výchozím controllerem je IndexController jež reprezentuje modul s názvem informační stránka.

4.6. FUNKCE CONTROLLERŮ

19

V části front-end se vyskytují tyto controllery: • IndexController • VendorController Z názvů je opět zřejmá souvislost s modulem pro koncové prodejce Vendor a s prezentačním modulem Index. Controller Vendor je vlastně rozšířením prezentační části o funkce potřebné k podpoře prodeje.

4.6

Funkce controllerů

Většinu controllerů administrační části reprezentuje standardní funkce správy obsahu jimiž je přidání, editace a mazání položek. Velkou výhodou během implementace byla možnost znovupoužití kódu. Tyto funkce pracují většinou se vstupy zadanými uživateli prostřednictvím formulářů. Zde se osvědčí použití frameworku, neboť ten disponuje řadou tříd sloužících k omezení bezpečnostních rizik, které vznikají při získávání dat z formulářů. Do těchto tříd patří především třídy z komponenty Zend_Filter. Pro představu uvádím funkci ošetřující uživatelský vstup od nežádoucích znaků. $filter = new Zend_Filter_StripTags(); $username = $filter->filter($this->_request->getPost(’username’)); $vocative = $filter->filter($this->_request->getPost(’vocative’));

4.7

Použité komponenty Zend frameworku

V této kapitole se chci zaměřit na komponenty, které mi výrazně zjednodušily implementaci nebo zvýšily kvalitu systému. Většina z těchto komponent patří k hojně užívaným, proto k nim lze nalézt dostatek zdrojů, ze kterých lze při práci s těmito komponentami čerpat.

4.7.1

Zend_Auth

Užitečná komponenta, kterou využívám v procesu přihlašování uživatelů. Tento interface je použit v IndexControlleru a VendorControlleru pro přihlášení buď do administrace, nebo do sekce pro podporu prodeje, to vše v závislosti na zvoleném controlleru. Interface Zend_Auth by bylo možné zapsat pouze v IndexControlleru a umožňoval by totéž, pouze by bylo třeba ověřovat uživatelskou roli a na jejím základě uživatele přesměrovat do příslušné sekce (administrace nebo podpora prodeje). Důvod, proč jsem zvolil tuto metodu použití prakticky totožné funkce v obou controllerech je především v použítí funkce Zend_Auth. Tomuto interface se zadávají informace o tabulce v níž máme uživatele uloženy, typicky uživatelské jméno a heslo, a on sám se již postará o výběr dat a jejich vyhodnocení. Může

20


se tedy stát, že uživatele rozdělíme do dvou tabulek na správce systému a koncové prodejce. Pokud by jsem tedy použili tuto funkci v pouze v IndexControlleru, museli bychom před samotným provedením autorizace vyhodnotit, kterou tabulku má Zend_Auth pro porovnávání použít. Tento způsob by pak byl již velmi nepřehledný a také by zvýšil délku samotného přihlašování. Z tohoto důvodu jsem tuto komponentu využil v obou controllerech. Další výhodnou Zend_Auth je fakt, že informace o přihlášeném uživateli máme k dispozici po celou dobu přihlášení v session. K těmto údajům se pak můžeme dostat jednoduše pomocí následujícího kódu: $auth = Zend_Auth::getInstance(); $identity = $auth->getIdentity(); $this->view->user = $identity; Objekt user, který máme nyní dostupný v šabloně view je vlastně reprezentací řádku tabulky na němž se nachází daný uživatel. Informaci o uživatelském jméně pak v šabloně zobrazíme například takto:
Uživatel - user->username; ?>

4.7.2

Zend_Acl

Zend_Acl řeší jednoduchým způsobem definici uživatelských rolí a jejich oprávnění. Protože systém, který implementuji využívá hned několik typů uživatelských rolí, bylo použití přístupu pomocí Zend_Acl opravdu výhodné. Na Zend_Acl mi především vyhovuje jednoduchý přístup k dědění rolí. Tímto jsem jednoduše dosáhl požadavku na vzájemné vztahy mezi rolemi, vizte diagram rolí na obrázku 3.2. Ukázka dědění rolí: $this->addRole(new Zend_Acl_Role(’everyone’)); $this->addRole(new Zend_Acl_Role(’admin’), ’everyone’); $this->addRole(new Zend_Acl_Role(’seller’), ’admin’); $this->addRole(new Zend_Acl_Role(’servis’), array(’admin’, ’seller’)); $this->addRole(new Zend_Acl_Role(’editor’), ’servis’); $this->addRole(new Zend_Acl_Role(’supervisor’), ’editor’); //role koncového prodejce $this->addRole(new Zend_Acl_Role(’vendor’), ’everyone’);

4.7.3

Zend_Controller_Router

Jedním z požadavků bylo také použítí hezkých URL. K tomuto účelu je možné využít abstraktní třídy Zend_Controller_Router_Abstract s níž jsem si vytvořil potomka MivvyRouter. Tomuto routeru jsem nadefinoval pravidla, podle nichž hezké URL zaměňuje za volání action a controllers.

4.7. POUŽITÉ KOMPONENTY ZEND FRAMEWORKU

21

Výsledná adresa URL pak může vypadat následně: http://www.mivvy.eu/kategorie/mp4prehravace/mivvy-record-h2/47. Oproti zažitému trendu uvádím v adrese také ID přístroje. Může totiž nastat nejednoznačnost ve jméně zobrazovaného produktu a právě pro tyto případy uvádím id produktu na konci adresy. Podobný systém užívá například server novinky.cz. Systém pravidel pak vypadá takto: switch ($path[2]) { case LOGIN: $actionName = "login"; break; case PRODUKTY: $actionName = "products"; break; case "..." ... ... ... Při implementaci této záležitosti jsem však narazil na problém, který byl v rozporu s požadavkem na vícejazyčný systém. Obsah stránek se sice generoval v závislosti na zvoleném jazyce, ale URL zůstávala stále ve stejném jazyce. Proto musely být definovány sady jazykových konstant. Tyto sady se pak mění v závislosti na zvoleném jazyce. Nevýhodou tohoto řešení je to, že v případě kdy je třeba přidat další jazyk, je nutné pro tento jazyk vytvořit soubor obsahující kromě původní i novou sadu konstant, a tato se pak musí přepsat stávajícím souborem.

4.7.4

Zend_PDF

Jedním z požadavků bylo také vytvoření reklamačního protokolu v PDF (ukázku tohoto PDF protokolu naleznete v příloze). Pro tento účel jsem tedy využil komponenty Zend_PDF. Postup vytváření PDF je podobný jako pro dvou-dimenzionální kreslící programy. Výsledné PDF je totiž sledem příkazů určujících pozici prvků. Nejlépe však tento postup vyjádří ukázka kódu: $PDF1 = new Zend_PDF(); $PDF1->pages[] = ($page1 = $PDF1->newPage(’A4’)); $width = $page1->getWidth(); $height = $page1->getHeight(); $page1->drawLine(40,$height-90,40,$height-198); $page1->drawLine($width-40,$height-90,$width-40,$height-198); Problém se však vyskytl v podpoře češtiny, jejíž znaková sada není zcela optimálně podporována. Z tohoto důvodu je nutné nadefinovat i typ použitého písma plně podporujícího české znaky. Toto písmo je pak exportováno společně s výsledným PDF.

22


Nevýhodou tohoto postupu je velikost výsledného PDF souboru. Původní systém generoval PDF soubory o velikosti 480 kB, což bylo opravdu mnoho. Zvolením optimálního písma pak klesla velikost souboru na 250 kB.

4.7.5

Zend_Validate

Další užitečnou komponentou je Zend_Validate. Tato slouží k validování uživatelských vstupů, v případě chybného vstupu pak systém vrátí chybovou zprávu. Zde jsem si z třídy Zend_Validate_Abstract vytvořil potomka PasswordStrength pro kontrolu hesla. U hesla kontroluji minimální délku a shodu zadaných hesel. Této metody jsem užil také v některých dalších controllerech.

4.8

Implementace nestandardních řešení

V systému se vyskytlo několik méně standardních řešení. K takovým patří například ty, ve kterých je nutno použít fragment logické vrstvy ve vrstvě prezentační. Pro tyto účely slouží v zendu tzv. view helpery. Jádrem view helperu je funkce, která vrací hodnoty na základě parametrů získaných z views. Těchto helperů jsem pak využíval především při výpisech dat z databáze (typicky v přehledu produktů).

4.8.1

Zjištění stavu reklamace

Tento helper má za úkol na základě vstupní hodnoty, kterou představuje informace o stavu objednávky, vrátit objekt, který říká jaký obrázek se má použít a také obsah atributu alt a title. Volání tohoto helperu z views vypadá následovně: $status = $this->getStatusIcon($rma[’status’]);

Proměnná i zajišťuje také načtení obrázku na základě aktuálního řádku. Obrázky jsou totiž uloženy ve formátu edit_0.gif a edit_1.gif a každý z těchto obrázků má jiné pozadí. Cílem je zvýšit přehlednost tabulky.

4.8.2

Zjištění dostupné lokalizace

K zobrazení dostupných lokalizací opět využívám view helperu. Funkci tohoto helperu předávám ID a tabulku, v níž se má vyhledávat.

4.9. IMPLEMENTACE WYSIVYGOVÉHO EDITORU

4.8.3

23

Genrerování čísla RMA protokolu

K účelům rychlé orientace a možnosti zakládání reklamačních protokolů dle daného pravidla bylo potřeba jednoznačně určit číslo protokolu. Tento požadavek jsem zajistil vygenerováním čísla, jež se skládá z data zadání reklamace spojeného a pořadím reklamace v daném měsíci. Označení RMA protokolu pak může vypadat například takto: 120209/13. Problémem bylo vynulování tohoto pořadí vždy prvního dne v měsíci. V úvahu přicházela různá, avšak poměrně složitá řešení v podobě kombinace MySQL dotazů, čemuž jsem se vyhnul poměrně zajímavým a jednoduchým řešením. Pořadí reklamací uchovávám ve zvláštní tabulce kterou vynuluji pomocí skriptu spouštěného službou Cron, jež běží na webovém serveru. Cron tedy spustí skript, vždy první den nového měsíce. Z důvodu tohoto řešení pak plyne požadavek na dostupnost služby Cron na hostovaném serveru.

4.9

Implementace wysivygového editoru

Implementace wysivygového editoru spočívá ve zkopírování souborů do adresáře v nichž uchovávám javascriptové skripty. Následně pak v definici javascriptového odkazu v hlavičce layoutu. Jedním z problému byl fakt, že wysivigový editor nebyl potřebný na všech stránkách a na některých přímo vadil. Tento editor totiž explicitně využívá elementu textarea a každý takovýto element měl v systému poté vlastnost wysivigového editoru. Toto působilo problém především v části servis, kde textarea předávala kromě vlastního obsahu i strukturu HTML kódu, který nebylo možné odfiltrovat, následkem čehož se tento kód vytiskl jako prostý text do reklamačních protokolů. Wysivygový editor je však v podstatě potřeba pouze v modulu produktů. Proto byl do layoutu administrace doplněn následující kód: <script type="text/javascript"> tinyMCE.init({

Parametr mode nastavuje v jakém režimu se má wysivyg použít. V případě, že je mód nastaven na FALSE se nebude editor vůbec inicializovat.

24

4.10


Implementace Mootools LightBox

Jelikož se na stránce budou prezentovat produkty, u nichž hraje vzhled a tudíž i ilustrační fotografie velkou roli, bylo žádoucí implementovat některý z nástrojů pro slideshow obrázků. K tomuto účelu jsem využil LightBox postavený na frameworku Mootools. Instalace tohoto nástroje je podobná jako u instalace TinyMCE. Nejprve je třeba zkopírovat zdrojové soubory Mootools a LightBox do adresáře s javascripty a poté inicializovat tento skript v hlavičce šablony. Pakliže chceme obrázek zobrazit pomocí LightBox je potřeba uvést do odkazu následující kód: LighBox

4.11

Implementace grafického rozhraní

Nedílnou složkou systému je grafické prostředí. Zde jsou požadavky kladeny především na přehlednost a intuitivní ovládání. Důležitým faktorem je také rychlost načítání stránek, která je nepřímo úměrná počtu bitmapové grafiky použité na stránkách. Vzhled tohoto prostředí jsem navrhl v grafickém programu Adobe Photoshop CS4. Následně jsem tento design převedl do XHTML šablony s využitím kaskádových stylů. Pro administrační rozhraní jsem volil standard CSS 3. Tento umožňuje vytvářet například stíny a kulaté rohy kontejnerů, to vše bez použití bitmapové grafiky. Tímto se výrazně zmenší velikost načítaných stránek a zvýší se celková rychlost. Bohužel tyto vlastnosti standardu CSS 3 zatím není možné použít ve front-endu, jelikož mnoho dnes používaných prohlížečů tento standard zatím nepodporuje a na rozdíl od administračního rozhraní nelze podmínit používání určitého typu prohlížeče.

4.12

Problémy během implementace

Největší problémy během implementace jsem měl s některých javascriptovými funkcemi. Většinu funkcí se mi podařilo zprovoznit na testovacích statických stránkách avšak po přesunutí do frameworku se tyto funkce nepovedlo zprovoznit. A tak se systém musel obejít bez náhledu obrázků během uploadu, vyjíždějících tooltip nabídek a validace vstupních dat. Naštěstí stěžejní funkce jako TinyMCE a LightBox byly implementovány bez problémů.

4.13

Implementace instalátoru

Instalace aplikace je prvním setkáním uživatele se systémem. Proto je důležité zjednodušit tento postup na přijatelnou úroveň. Instalátor je řešen pomocí dynamické PHP stránky s formulářem, kterou jsem postavil mimo Zend framework. Tato stránka má za úkol získat data o databázi, kterou bude systém využívat jako uložiště dat.

4.13. IMPLEMENTACE INSTALÁTORU

25

Tento instalátor ověří zda-li zadaná databáze existuje, v případě že ano připojí se k této databází a vytvoří v ní potřebné tabulky s počátečním nastavením. Dále provede změnu přístupových privilegií u adresářů, do kterých musí mít aplikace právo zapisovat data. Dalším krokem je také vytvoření konfiguračního souboru na základě zadaných informací o databázi. Tento konfigurační soubor pak využívá systém k přístupu do databáze. Po ukončení instalace se tato stránka odstraní a to proto, aby nedošlo k další instalaci, čímž by byla přepsána stávající databáze.

26


Kapitola 5

Testování 5.1

Testování front-end části

Jelikož byl kladen požadavek na využití stávajícího grafického rozhraní webové prezentace zaměřil jsem se pouze na faktory, které přímo neovlivňovaly vzhled prezentace.

5.1.1

Validace dle standardů W3C

Tato validace probíhala prostřednicím on-line nástroje konzorcia W3C dostupného na adrese validator.w3.org. Stránky dostupné ve front-end části, které byly po provedených testech nevalidní, dle standardu XHTML Strict 1.0 (UTF-8), byly opraveny a validovány znovu, dokud neprošly úspěšně testem validace.

5.1.2

Zobrazení prezentace

Ověřování korektnosti zobrazení prezentace probíhalo testováním prezentace ve většině hlavních webových prohlížečích. Webová prezentace se zobrazuje korektně na běžně používaných prohlížečích jako jsou Internet Explorer 7/8, Mozilla Firefox 3, Google Chrome 2, Opera 9/10 a Safari 3/4.

5.1.3

Přístupnost formuláře registrace koncového prodejce

Na vzorku deseti uživatelů bylo testováno zda-li formulář působí srozumitelně a požadováné položky jsou jednoznačné. Zde muselo dojít k několika úpravám. Pro zajištění větší přehlednosti byl výsledný formulář rozdělen do několika části. Dále bylo třeba jednoznačně rozdělit vstupní položky. A to na položky prezentované na Internetu v rámci seznamu koncových prodejců a na položky sloužící pouze pro interní účely společnosti. Bylo nutné zavést javascriptovou kontrolu vstupních dat. 27

28

5.1.4

KAPITOLA 5. TESTOVÁNÍ

Přístupnost formuláře pro vložení nové reklamace

Tento formulář byl odladěn během ostrého provozu, dále doplněn o javascriptovou validaci a o položky, které během analýzy a v době implementace nebyly známy.

5.1.5

Fulltextové vyhledávání

Jedním z požadavků byla implementace fulltextového vyhledávání. Během testování se však tato metoda vyhledávání příliš neosvědčila, jelikož vracela příliš velké množství dat, což snižovalo relevanci. Toto si vysvětluji tím, že databáze produktů, ve které se vyhledává, obsahuje příliš mnoho stejných řetězců, zejména pak ve specifikacích. Tato metoda se v praxi využívá především u systémů se značným množstvím textových dat, a to zejména pro její rychlost. Tato výhoda zde nehraje velkou roli, jelikož se nepočítá s velkým objemem textů v databázi. Z tohoto důvodu bylo místo této metody vyhledávání implementován jednoduchý princip vyhledávání pomocí operátoru Like.

5.1.6

Přístupnost vyhledávačů

Grafické zpracování prezentace bohužel příliš neodpovídá požadavkům na SEO optimalizaci, jelikož obsahuje malé množství relevantního textu (např. úvodní stránka) a velké množství obrázků. Ve vyhledávačích Google a Seznam jsem tedy testoval zejména řetězce charakteristické pro jména produktů a to cca 5 týdnů po ostrém spuštění systému, kdy již bylo možné předpokládat že již proběhlo indexování stránek v databázích prohlížečů. Výsledky byly přinejmenším uspokojivé. Na rozdíl od staré verze stránek vyhledávaly prohlížeče odpovídající výsledky. Úspěch v tomto testu přikládám především optimalizaci URL adresy na hezká URL a automatickém generování atributů alt a title ze jména produktu.

5.2

Testování back-end části

Během vývoje systému se na testech a konzultacích podílel pracovník společnosti mivvy primárně zodpovědný za webovou prezentaci. To napomohlo k celkové optimalizaci systému dle přání zadavatele.

5.3

Korektnost zobrazení uživatelského rozhraní

Tento test probíhal stejně jako při testování front-end části. Uživatelské rozhraní se zobrazuje korektně v prohlížeči Safari. Na tento prohlížeč byl kladen důraz se strany pracovníka zodpovědného za webovou prezentaci.

5.4. TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ

29

S menšími rozdíly se pak stránky zobrazují v prohlížečích Chrome, Firefox 3, Opera 9.6. Vliv na odlišné zobrazení mají především grafické prvky samotných prohlížečů (typicky tlačítka, výběrová menu, aj.) Hlavním požadavkem na prohlížeč je podpora standardu CSS 3. V prohlížečích nepodporujících tento standard není zajištěno vykreslení kulatých rohů a celkový vzhled se může mírně lišit.

5.4

Testování uživatelského rozhraní

Tento test probíhal tak, že jsem pozoroval práci uživatele se systémem aniž bych jej podrobně seznámil s funkcionalitou systému. Na základě získaných informací jsem pak upravil průchody mezi jednotlivými stránkami a provedl potřebné změny v popisech sekcí, formulářů atd. Dále bylo třeba některé vstupní formuláře doplnit o tlačítko zpět a ve formulářích, které obsahují více prvků, bylo třeba odlišit hlavní tlačítko, které vyvolává požadovanou akci.

5.5

Přínosy testování back-end části

V následujících podkapitolách popíši některé příklady změn, ke kterým došlo na základě testování pracovníkem společnosti mivvy.

5.5.1

Formulář lokalizace produktu

Během lokalizace produktu do jiného jazyka bylo vždy třeba opětovně zadat kompletní specifikaci produktu v daném jazyce. Pro zjednodušení práce načítám do formuláře produktu v další lokalizaci data primárního jazyka (češtiny). Lokalizovaný text technických specifikací se totiž mnohdy liší jen v předložkách. Vložením vzoru specifikace v českém jazyce se tak podstatně zjednodušila práce při přidávání dalších lokalizací.

5.5.2

Vyhledávání reklamací

Oproti původní myšlence filtrování zobrazených reklamací pouze podle jejich stavu se objevil požadavek na vyhledávání podle zadaného řetězce. Shoda s tímto řetězcem se pak vyhledává v RMA i sériových číslech. Mnohdy je totiž třeba vracet se k zadaným reklamacím, případně může nastat situace, kdy má technik k dispozici opravený výrobek z továrny, kde jediným jednoynačným údajem je sériové číslo produktu.

5.5.3

Ukládání nastavení filtrů

Další záležitostí, která vyšla na povrch až během testování byla nutnost uchovat stav třídících filtrů i během práce s produktem.

30

KAPITOLA 5. TESTOVÁNÍ

Často vykonávaným úkolem je například změna parametrů u všech produktů splňující určité kritérium. Pro efektivitu tohoto úkolu bylo třeba zajistit, aby se uživatel po úspěšné editaci produktové karty vrátil zpět na výpis produktů, který si v předešlém kroku dle zadaných parametrů vyhledal.

Kapitola 6

Závěr 6.1

Naplnění cíle práce

Z hlediska zadání bakalářské práce se domnívám, že systém splňuje veškeré požadavky na tuto práci kladené. Výsledný systém, jak se zdá, bude také spolehlivě splňovat požadavky společnosti mivvy a.s.[1], a co více, především na úrovní zpracování jde daleko za rámec těchto požadavků. Celý projekt jsem se snažil řešit tak, aby výsledek tvořil kvalitní platformu pro další případná použití systému. Během implementace systému jsem se naučil pracovat s mnoha novými technologiemi, což osobně považuji za největší přínos této práce.

6.2

Další rozvoj projektu

Další rozvoj projektu spatřuji zejména v jeho směřování k uživatelsky přivětivému a jednoduchému CMS, s nímž bude možné najít mnoho uplatnění na trhu. Jako ideální příležitost pro využití systému se mi jeví právě ty, které mimo běžnou správu obsahu vyžadují další funkční prvky - podobně jako mivvy a.s. sekci pro podporu prodeje. V implementační rovině se nachází celá řada vylepšení, která ještě plánuji do systému zahrnout, jde především o zapracování technologií hromadného odběru, dokonalejší editaci vzhledu stránek či širší možnosti ve správě sekcí.

31

32

KAPITOLA 6. ZÁVĚR

Literatura [1] mivvy a.s. — oficiální stránky zadavatele projektu. http://www.mivvy.eu. [2] Wordpress 2.8 — populární blogovací systém šířený pod GPL licencí. http://wordpress.org/download/, verze 2.8., ke dni 5.6.2009. [3] AiPublisher — redakční CMS systém http://www.aipublisher.cz/, verze Standard, ke dni 5.6.2009. [4] jNetPublish — Profesionální web content management systém pro realizaci a snadnou správu dynamických www prezentací. http://wordpress.org/download/, verze 2.8., ke dni 5.6.2009. [5] Nette 0.8 — MVC framework z dílny Nette Foundation šířený pod GPL licencí http://nettephp.com/cs/download, verze 0.8 stable, ke dni 13.5.2009. [6] Cake 1.2 — MVC framework http://cakephp.org/, verze 1.2 stable, ke dni 13.5.2009. [7] Zend — oficiální stránky použitého frameworku. http://www.zendframework.com, verze 1.8.1, ke dni 13.5.2009. [8] Zend Studio 6 — výkonné IDE s přímou podporou Zend frameworku. http://www.zend.com/products/studio/, verze 6.1.2, ke dni 13.5.2009.

33

34

LITERATURA

Kapitola 7

Seznam použitých zkratek CMS Content management system CSS ascading Style Sheets IDE Integrated Device Electrocnics PHP Personal Hypertext Processor RMA Return merchandise authorization SEO Search engine optimization

35

36

KAPITOLA 7. SEZNAM POUŽITÝCH ZKRATEK

Kapitola 8

UML diagramy

Obrázek 8.1: Řešení požadavku na vícejazyčný systém

37

38

KAPITOLA 8. UML DIAGRAMY

Obrázek 8.2: Diagram aktivit průběhu reklamace

39

Obrázek 8.3: USE-CASE diagram správy produktu

40

KAPITOLA 8. UML DIAGRAMY

Obrázek 8.4: USE-CASE diagram správy reklamace

Kapitola 9

Instalační a uživatelská příručka 9.1

Zkopírování souborů na server

Prvním krokem instalace je upload souborů na server. Veškerý obsah adresáře Project tedy zkopírujte do kořenového adresáře vašeho webového serveru. Pokud obsah kořenového adresáře serveru vypadal například takto: /htdocs /logs Po zkopírování souborů by měl vypadat takto: /application /htdocs /library /logs

9.2

Spuštění instalace

Po úspěšném zkopírování souborů vytvořte novou databázi ve vaší MySQL databázi. Poté spusťte instalaci pomocí instalátoru, který bude dostupný na adrese: www.vasedomena.cz/instalace/install.php. K úspěšnému provedení instalace je potřeba znát údaje pro připojení do vaší databáze MySQL. K vyplnění údajů jména databáze, serveru na němž běží databáze, přístupového jména a hesla budete vyzvání během instalace.

9.3

Nastavení služby Cron

V administračním rozhraní vašeho hostingového programu, nastavte novou úlohu Cron. Tato úloha se spouští z adresáře: www.vasedomena.cz/_service/rma/Reset.php. Datum pravidelného spuštění této úlohy nastavte na počátek prvního dne v měsíci. 41

42

KAPITOLA 9. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

V případě, kdy nemáte možnost využívat služeb Cron, nebudou se čísla vašich RMA protokolů odvíjet od počtu zadaných reklamací v daném měsíci, ale budou určovat počet přijatých reklamací celkem.

9.4

Spuštění systému

Nyní je možné spustit webovou prezentaci na adrese www.vasedomena.cz. K přístup do administrační sekce slouží odkaz www.vasedomena.cz/login. Výchozí údaje pro přístup do systému s oprávněním uživatele typu suprevisor jsou nastaveny následovně: Jméno: Supervisor Heslo: supervisor Ihned po přihlášení je doporučeno změnit tyto výchozí údaje!

9.5

Vývojové prostředí

Do toho systému je také možné přistupovat na adrese vývojového serveru: dev.djjuris.com/

Kapitola 10

Obsah přiloženého CD

3URMHFW DGUHViĜREVDKXMtFtVRXERU\V\VWpPX

([DPSOHV DGUHViĜREVDKXMtFtGDWDSURWHVWRYDFtSOQČQtV\VWpPX

%3 DGUHViĜREVDKXMtFtEDNDOiĜVNRXSUiFLYHIRUPiWX3')

5($'0(W[W WH[WRYêVRXERUREVDKXMtFtSRN\Q\NLQVWDODFL

Obrázek 10.1: Obsah přiloženého CD

43

44

KAPITOLA 10. OBSAH PŘILOŽENÉHO CD

Kapitola 11

Obrázky ze systému

Obrázek 11.1: Úvodní stránka administračního rozhraní

45

46

KAPITOLA 11. OBRÁZKY ZE SYSTÉMU

Obrázek 11.2: Přehled produktů

47

Obrázek 11.3: Úvodní vzhled stránek mivvy a.s. - EN verze

48

KAPITOLA 11. OBRÁZKY ZE SYSTÉMU

280209388

Reklamační formulář Zákazník

Prodejce

Firma

GSM Mobilní telefony s.r.o.

Firma

TMobile Czech Republic a.s.

Jméno

Petr Vochmelka

Ulice

Národní třída 1920/23

Ulice

Národní třída 1920/23

Město/PSČ

Praha 1, 110 00

Město/PSČ

Praha 1, 110 00

Telefon

603 123 456

Telefon

603 123 456

Email

petr.vochmelka@tmobile.cz

Email

[email protected]

Předmět reklamace Produkt

mivvy M310

Přístroj

ano

USB kabel

ne

IMEI/SN

2008X203030DHJW

Akumulátor

ano

Headset

ano

Typ reklamace

Záruční

Napájecí zdroj

ne

Stylus

ne

Další

záruční list, faktura, obal

Datum koupě

31. 12. 2009

Datum reklamace

31. 12. 2009

Popis závady Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Adresa pro vyzvednutí zásilky Karlovo náměstí 2029/23, Praha 2, 120 00, telefon: 777 777 777

Reklamace je OPRÁVNĚNÁ

NEOPRÁVNĚNÁ

Zdůvodnění Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Kompletní znění reklamačních podmínek společnosti mivvy a.s. naleznete na: http://www.mivvy.eu/support/documents/ podminky_pro_uplatneni_zaruky.pdf

.................................... reklamační oddělení mivvy a.s.

mivvy a.s. | Poděbradova 4, Plzeň 301 00, Česká republika | mivvy.eu | [email protected] | (+420) 371 120 046

Obrázek 11.4: Výstupní reklamační protokol

Podpora prodeje osobní elektroniky. Jiří Brhel

Recommend Documents

Uživatel - user->username; ?>