}w!"#$%&'()+,-./012345<ya Masarykova univerzita Fakulta informatiky Analýza a návrh internetového obchodu pro knihkupectví Bakalářská práce Otakar Hypš Brno, podzim 2011
Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorských dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při práci používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Taktéž veškeré zdrojové soubory programu Eshop PM jsou mým vlastním autorským dílem, které jsem vytvořil bez cizí pomoci. Vedoucí práce: doc. PhDr. Josef Prokeš, Ph.D. ii
Poděkování Na tomto místě bych rád poděkoval především panu docentu Prokešovi za vstřícnost, cenné rady a připomínky při přípravě této práce. Dále děkuji svým rodičům, kteří mě podporují po celou dobu studia. iii
Shrnutí Cílem této bakalářské práce je dovést vývoj internetového obchodu od samého počátku do fáze spuštění prodeje. Analyzovat podmínky, ve kterých bude obchod vznikat, a jejich analýze se v implementaci a optimalizaci pro vyhledávače přizpůsobit. Praktická část práce spočívá v návrhu a kompletním naprogramování internetového obchodu ve Frameworku Nette. iv
Klíčová slova internetový obchod, www, reengineering, analýza eshopu, analýza konkurence, použitelnost, přístupnost, Nette Framework, PHP, MySQL, mobilní web, uživatelské testování v
Obsah 1 Úvod.................................. 4 2 Reengineering............................ 5 2.1 Reengineering a knihkupectví.................. 6 2.2 Webový reengineering...................... 6 3 Analýza................................ 7 3.1 Analýza požadavků........................ 7 3.1.1 Seznam požadavků.................... 7 3.2 Analýza obsahu webu...................... 8 3.2.1 Layout........................... 8 3.2.2 Obsah stránek horizontálního menu.......... 9 3.2.3 Patička.......................... 9 3.2.4 Administrační rozhranní................. 10 3.3 SWOT analýza.......................... 10 3.3.1 Silné stránky....................... 10 3.3.2 Slabé stránky....................... 10 3.3.3 Příležitosti........................ 11 3.3.4 Hrozby.......................... 11 3.4 Strukturovaná analýza...................... 11 3.4.1 Datový model....................... 11 3.4.1.1 Kontextový diagram.............. 12 3.4.1.2 Diagram datových toků............ 13 3.4.1.3 Entitně relační diagram............ 14 3.4.1.4 Dekompozice.................. 15 3.4.2 Případy užití....................... 16 3.5 Analýza konkurence....................... 17 3.5.1 Cíle analýzy konkurence................. 17 3.5.2 Určení konkurence.................... 17 3.5.3 Faktory hodnocení konkurence............. 18 3.5.4 Analýza konkurence webu www.pavelmervart.cz... 18 3.5.4.1 Nakladatelství Argo.............. 18 3.5.4.2 Academia knihy................ 19 3.5.4.3 Dauphin.................... 19 2
3.5.4.4 Aleš Čeněk................... 19 3.6 Výsledek analýzy konkurence.................. 19 3.7 Analýza původního internetového obchodu........... 20 4 Webdesign............................... 22 4.1 Přístupnost............................ 22 4.2 Použitelnost............................ 23 4.3 Layout............................... 23 4.4 Mobilní verze webu........................ 24 5 Implementace............................. 26 5.1 Použité technologie........................ 26 5.1.1 HTML/XHTML..................... 26 5.1.2 HTML5.......................... 27 5.1.3 PHP............................ 27 5.1.4 MySQL.......................... 27 5.1.5 Nette Framework..................... 28 5.1.5.1 Dibi....................... 28 5.1.6 jquery........................... 28 5.1.7 AJAX........................... 29 5.1.8 Výstupy.......................... 29 5.1.8.1 Zboží.cz..................... 29 5.1.8.2 Mapa webu................... 29 5.1.8.3 RSS....................... 30 5.2 SEO................................ 30 5.3 Zajímavosti............................ 31 5.3.1 Generování obrázků................... 31 5.3.2 Registrace......................... 32 5.3.3 HTML 5.......................... 32 5.4 Mobilní verze webu........................ 33 5.4.1 Možnosti implementace................. 33 5.4.1.1 XHTML-MP[11] (Mobile Profile)....... 34 6 Testování............................... 35 6.1 Uživatelské testování....................... 36 6.1.1 Scénář uživatelského testování.............. 36 6.1.2 Závěry z testování.................... 36 7 Závěr.................................. 38 A Obsah přiloženého CD....................... 42 B Kontextový diagram........................ 43 C Diagram datových toků...................... 44 D Diagram případů užití....................... 50 E Entitně relační diagram...................... 51 3
Kapitola 1 Úvod Již řadu let se věnuji tvorbě webových stránek, doposud nikdy jsem však nepracoval od samého začátku na projektu podobného rozsahu. Cílem této práce je popsat postup při návrhu a implementaci internetového obchodu pro knihkupectví. Výsledný systém bude nasazen v praxi za účelem prodeje knih Nakladatelství Pavel Mervart. Vývoj systému je založen na analýze, které se tato práce rovněž věnuje. Postup, podle kterého je práce vystavěna, je založen na literatuře, studiu aplikované informatiky na Masarykově univerzitě a mé osobní zkušenosti z praxe. Protože se jedná o přepracování již fungujícího internetového obchodu, tak se v první části práce krátce věnuji reengineeringu. Následuje analýza, které je v práci věnováno nejvíce prostoru. Ve čtvrté kapitole jsou zmíněny nejdůležitější pojmy z webdesignu, jež následně uplatním spolu s analýzou při implementaci. V závěru práce se nachází kapitola věnovaná uživatelskému testování a jeho výsledkům. 4
Kapitola 2 Reengineering Podle slovníku cizích slov má reingeneering význam ve smyslu zavádění radikálních organizačních změn v podniku, zlepšení procesů podnikání a podpora způsobu myšlení a chování pracovníků[1]. Z tohoto úhlu nahlížejme na reengineering v této práci. Nejedná se totiž pouze o změnu procesů v informačním systému, ale také se jedná o změnu procesů a jejich vnímání mezi uživateli systému. Z přednášek pana doktora Klužníka v předmětu PV029 Aplikační informační systémy 1 si pamatuji, že v začátcích zavádění informačních systémů nastávala často situace, kdy se uživatelé bránili veškerým informačním systémům, přestože jim měly ulehčovat práci. V současnosti se stav otočil. Uživatelé vyžadují informační systémy i v situacích, kdy nejsou potřeba a možnost jejich zavedení je daleko nákladnější, než ponechání starého řešení. Moderní doba v přetechnizovaném světě vyžaduje neustálé zdokonalování procesů, což s sebou nese nemalé problémy poskytovatelům informačních systémů. Musí čelit faktu, že ne vždy je optimálním řešením modernizace a předělání již fungujícího systému. Některé změny zdánlivě základní funkcionality mohou zasahovat hluboko do systému a tam vyžadovat zásadní přestavbu. Ta je vzhledem k rozsáhlosti systému nepřijatelná, protože by mohla mít katastrofální následky. Reengineering se vyvíjí spolu s dobou a aktuálními nároky na systémy. V historii se objevoval u prvních informačních systémů, takzvaných Legacy systémů[2]. Ty jsou obvykle velmi rozsáhlé, vzhledem k jejich zavedení ve velikých často mezinárodních institucích, které si je mohly jako první dovolit. Typickým příkladem jsou banky. Staré Legacy systémy mají nekompletní dokumentaci, neobjektový návrh a jsou navržené v zastaralých programovacích jazycích. Z tohoto důvodu je velmi náročné na nich provádět celkovou modernizaci, jež by současný stav zlepšila na úroveň, kdy je bude snadnější udržovat a nadále modernizovat. Systémy jsou zdrojem velikých datových toků, nejsou pouze aplikačním softwarem, ale zahrnují podnikatelské pro- 1. <http://is.muni.cz/predmet/fi/podzim2011/pv028> 5
2. Reengineering cesy a vyžadují závislost na systémovém hardwaru. V neposlední řadě jsou zdrojem příjmu, a proto je vývoj nového systému pro provozovatele riskantní. Základním pravidlem vývoje softwaru je, že pokud je systém funkční, i přesto, že je zastaralý, a je s ním provozovatel spokojený, nemá cenu ho měnit. Nikdo nebude ochotný za vývoj nového softwaru platit. Vynucení změny starého systému bývá vyvoláno zahlcením systému, neuspořádaností a narůstající vnitřní logikou, kdy se veškeré změny stávají obtížnými a nákladnými. Jak jsem již zmínil, pokus o nahrazení celého systému nese veliká rizika, proto se zavádí reengineering. Podle publikace Software Renovation in Three Steps[2] v roce 2000 pracovali čtyři ze sedmi programátorů právě na renovaci starého softwaru. A podle prognózy bude v roce 2020 pouze jedna třetina vývojářů pracovat na vývoji nového softwaru. 2.1 Reengineering a knihkupectví Vytvoření internetového obchodu knihkupectví je založeno na reengineeringu původního obchodu, který byl umístěný na adrese www.pavelmervart.cz. Vzhledem k tomu, že původní eshop neměl žádný systém správy a byl spravován pouze změnami přímo v HTML kódu, nejedná se o reengineering informačního systému, ale o reengineering procesů probíhajících při prodeji knih online. Důležitou součástí reengineeringu tohoto obchodu je tedy co nejlepší zajištění rozšiřitelnosti pro další vývoj systému, protože tímto jsou položeny základy informačnímu systému, u kterého se dá v budoucnu další vývoj předpokládat. 2.2 Webový reengineering Webové stránky nejsou tak složitým systémem, jako systémy zmíněné výše, proto tomu odpovídá i náročnost reengineeringu. U menších webových systémů je efektivnějším řešením využití analýzy původního systému a návrh nového založeného na této analýze. 6
Kapitola 3 Analýza Abychom docílili co nejlepšího řešení, je potřeba se rozhlédnout kolem sebe a ještě před začátkem návrhu systému zjistit, jaké jsou možnosti a nástrahy okolí. K tomu nám poslouží celková analýza vyvíjeného systému. Analýza požadavků, obsahu, strukturovaná analýza, analýza konkurence, SWOT analýza a porovnání s původním stavem systému. 3.1 Analýza požadavků Vývojáři věnují mnohem více pozornosti ERD diagramům a diagramům tříd, než seznamu požadavků. [3] Požadavek je něco, co musí systém pro uživatele umět vykonat, může to být specifická funkce, kterou uživatel vyžaduje a systém poskytuje. Přidáním požadavku se typicky vývoj softwaru prodlouží, odebráním zkrátí.[3] Nejdůležitější částí při porozumění požadavkům zákazníka je správné pochopení problému a vyhovění zákazníkovým nárokům. V případě knihkupectví byly některé požadavky obecné, tudíž ponechávaly větší volnost při návrhu, některé byly od zákazníka specifikované velmi přesně a bylo možné nalézt i takové, které se během vývoje softwaru postupně doplňovaly a měnily. 3.1.1 Seznam požadavků Modernizace vzhledu a zpřehlednění obsahu. Zavedení systému pro správu produktů internetového obchodu (knih). Poskytnutí zákazníkům možnosti online objednávky zboží tak, jak jsou zvyklí z jiných obchodů fungujících online. Strukturalizace katalogu knih do edic a oborů. 7
3. Analýza Evidence emailů zákazníků za účelem zasílání informací o novinkách, možnost zasílání emailů jen vymezené skupině uživatelů podle knih, které si již dříve v obchodě objednali. Použití technologií sociálních sítí. Vyhledávání v autorech a knihách, doplněno o vyhledávání v aktualitách. Zveřejňování aktualit. Optimalizace pro vyhledávače. 3.2 Analýza obsahu webu Analýza obsahu webu slouží k vytváření přehledů konkrétního obsahu na jednotlivých webových stránkách. Využití této techniky lze nalézt především v oblasti redesignu webových portálů[4]. Jednotlivé stránky webu jsou zasazeny do celkového layoutu, který je na všech stránkách neměnný. 3.2.1 Layout Hlavička s logotypem a nákupním košíkem. Horizontální menu základní menu celého webu. Navigace slouží k signalizaci, kde se právě uživatel nachází v hierarchii webu. Vertikální menu výběr z oborů a edic. Odběr novinek sběr emailů od uživatelů. Aktuality zobrazení posledních čtyř aktualit. Patička webu. 8
3. Analýza 3.2.2 Obsah stránek horizontálního menu Hlavní strana Carousel 2, právě vychází knižní novinky nakladatelství, navigace Kam dál?. Katalog knih Autoři Jak nakupovat O nás Kontakt Filtr zobrazených knih, výpis katalogu, stránkování výsledků. Seznam autorů. Nápověda pro uživatele. Prezentace společnosti. Kontaktní informace, kontaktní formulář. 3.2.3 Patička Jak nakupovat, poštovné, všeobecné obchodní podmínky, ochrana osobních údajů, RSS, spřátelené stránky, kontakt, o webu, odhlášení z odběru novinek a přepnutí na mobilní verzi. 2. Posuvný prvek sloužící k větší atraktivitě stránky. <http://sorgalla.com/projects/jcarousel/> 9
3. Analýza 3.2.4 Administrační rozhranní Hlavní strana Obsahuje souhrnné informace. Knihy Objednávky Newsletter Aktuality Autoři Edice a Obory Uživatelé Změna hesla Seznam knih, editace knih, přidání nové knihy. Filtrování objednávek dle stavu (zaplacená/nezaplacená/storno) Vyhledávání podle čísla objednávky. Odesílání emailů podle zvolených oborů a edic. Přidání nové aktuality, výpis a úprava starších. Přidání nového autora, výpis, úprava dříve přidaných. Správa edic a oborů. Přehled a správa všech uživatelů systému. Umožňuje změnu hesla pro přihlášení do systému. 3.3 SWOT analýza Zkratka SWOT[5] vznikla spojením čtyř anglických slov: Strengths, Weaknesses, Opportunities, Threats. [5] Vyjadřuje rozdělení vlastností systému do kategorií: silné stránky, slabé stránky, příležitosti, hrozby. Napomáhá lepší orientací při zasazení systému do souvislostí. 3.3.1 Silné stránky Prodej knih přímo od vydavatele. Zkušenosti v oboru. Specifické knihy k prodeji. 3.3.2 Slabé stránky Pozdní start prodeje online. Velmi silná konkurence v prodeji knih na Internetu. 10
3. Analýza Neúčast jiných než vlastních produktů v eshopu. 3.3.3 Příležitosti Využití moderních technologií. Rozšíření prodeje. 3.3.4 Hrozby Neúspěch oproti silné konkurenci. Skryté hrozby. 3.4 Strukturovaná analýza Software nabízený na trhu se obvykle dělí do dvou částí. Jednak jde o generické produkty, které jsou prodávány jako hotový software s jasným využitím. A jednak jde o smluvní software vyvíjený na zakázku konkrétního zadavatele. Ať se jedná o kterýkoliv z nich, na počátku vývoje každého softwaru by měla stát analýza systému[6], protože právě ta slouží k jasné komunikaci se zákazníkem. Není však využívána pouze za tímto účelem. Má za cíle usnadnit zákazníkovi předat do rukou programátora konkrétní představu o vyvíjeném softwaru ve srozumitelné podobě pro obě strany. To se prakticky provádí formou nákresů, rozpisů a podobných metodik. Pro analytika a programátora mají analytické nástroje dvojí účel. 1. Porozumět sdělení zákazníka o potřebách a požadavcích na vyvíjený systém. 2. Uchovat záznamy pro účely dokumentace. Druhý způsob využití výstupů analýzy vede k lepší orientaci v systému i po několika letech, pouze však v případě, že je analytická dokumentace uchovávána v aktuální podobě. Nákresy z dob vývoje software zpravidla ztrácí svůj význam už velmi brzy po prvních úpravách systému. 3.4.1 Datový model Abychom mohli pracovat s reálnými objekty v informačním systému, musíme si k nim vytvořit virtuální alternativy. Ty si do systému zavedeme pomocí datového modelu, který nám zobrazí vztahy a strukturu objektů v přehledné formě. Pro datové modelování se využívá mnoho nástrojů, pro účely naší 11
3. Analýza analýzy byly zvoleny ty nejběžnější: Kontextový diagram, Entitně relační diagram a Diagram datových toků.[6] 3.4.1.1 Kontextový diagram Kontextový diagram znázorňuje jeden proces jako celý systém a jeho okolí jako terminátory spolupracující se systémem akcemi, které se značí šipkami vstupujícími, či vystupujícími z tohoto procesu. Obrázek 3.1: Kontextový diagram s detailem terminátoru Administrátor Jak je naznačeno na obrázku 3.1, tento diagram jasně vykresluje rozdíl mezi systémem a jeho okolím. Lze snadno pozorovat veškeré akce prováděné uživateli nad systémem. Kvůli značnému množství akcí, které Administrátor nad systémem provádí, je na tomto nákresu rozdělen do dvou terminátorů, stále se ale jedná o jednoho uživatele. Schéma je v lepším rozlišení součástí bakalářské práce jako příloha. 12
3. Analýza 3.4.1.2 Diagram datových toků Data flow diagram(dfd) neboli diagram datových toků vychází z kontextového diagramu. Dělí systém na jednotlivé subsystémy řešící konkrétní úlohy. A vytváří tak kompletní síť procesů a toků v celém systému. Má několik úrovní, což slouží k detailnímu náhledu na jednotlivé částí systému a následné složení systému jako celku. Příklad diagramu na úrovni 1.4 (Evidence katalogu) je znázorněn obrázkem 3.2. Můžeme zde sledovat procesy Zobrazení katalogu, Evidence edic, Evidence oborů a Evidence knih, přesně, jak je to rozepsáno v hierarchii níže. Obrázek 3.2: DFD na úrovni 1.4 Hierarchie systému nakladatelství podle DFD 1.1 Evidence uživatelů 1.1.1 Zobrazení registrace 1.1.2 Editace uživatele 1.1.3 Zobrazení uživatelů 1.1.4 Přihlášení 1.2 Evidence objednávek 1.2.1 Vytvoření objednávky 1.2.2 Kontrola platby 13
3. Analýza 1.2.3 Zobrazení objednávky 1.4 Evidence Katalogu 1.4.1 Evidence knih 1.4.2 Evidence edic 1.4.3 Evidence oborů 1.4.4 Zobrazení katalogu 1.5 Evidence aktualit 1.5.1 Zadání aktuality 1.5.2 Správa aktualit 1.5.3 Přehled aktualit 1.6 Evidence autorů 1.6.1 Zadání autora 1.6.2 Přehled autorů 1.6.3 Správa autorů 1.7 Správa newsletteru 1.7.1 Souhlas se zasíláním newsletteru 1.7.2 Vyplnění emailu 1.7.3 Odeslání newsletteru 1.7.4 Vyplnění mazaného emailu 1.8 Hledání Grafické znázornění hierarchie Data flow diagramu se nachází v příloze této práce. 3.4.1.3 Entitně relační diagram Entity relationship diagram(erd) v českém jazyce Entitně relační diagram znázorňuje datový model systému. Pomocí systému entitních množin a vztahů mezi nimi (relací), definuje strukturu dat. Vztahy mezi entitami mají definovánou aritu vztahu 1:1, 1:n, m:n, 1:0..n[6]. Vzhledem k rozsahu datového modelu je na obrázku 3.3 uveden pouze příklad dvou entit a jejich vztahu, kompletní ERD se nachází v příloze práce. 14
3. Analýza Obrázek 3.3: Ukázka části ERD 3.4.1.4 Dekompozice Analytické diagramy je třeba postupně rozkládat na menší oddíly, aby byla zachována přehlednost. K tomu slouží dekompozice systému, která dělí systém na vybrané díly a znázorňuje tak vždy menší část, dokud není systém rozebrán na nejmenší možné součásti. Lze takto sledovat všechny části návrhu velmi podrobně. Obrázek 3.4: Dekompozice (zdroj [6]) 15
3. Analýza 3.4.2 Případy užití Posledním zde zmíněným analytickým schématem je Use case diagram[3]. Jedná se o jazyk UML[7] sloužící k propojení vize zadavatele a práce vývojáře systému, proto diagram vychází především ze seznamu požadavků na systém a následně z DFD a ERD. Je tvořený z důvodu názorné ukázky, jací uživatelé budou k systému přistupovat a jaké operace budou provádět. Dalo by se namítnout, že to všechno nabízí po částech i předchozí analytické nástroje. Tomu se nedá odporovat, ale Diagram případů užití je více názorný a hlavně lépe pochopitelný pro uživatele. Podle případů užití je pochopení systému snazší i pro neodbornou veřejnost, protože systém zobrazuje tak, jak ho sami vidí. Zobrazeny jsou postavy jako uživatelé a oválné bubliny jako jednotlivé případy užití. Na obrázku 3.5 se nachází diagram případů užití knihkupectví, pro názorné odlišení přístupu uživatelů k systému je celý systém ohraničen obdélníkem. Obrázek 3.5: Use case diagram 16
3. Analýza 3.5 Analýza konkurence K proniknutí na trh internetových obchodů s knihami je nutné znát dobře svou konkurenci a řídit své kroky z počátku podle ní. Proto je důležité vytvořit si vlastní analýzu konkurence, zhodnotit důležité prvky konkurenčních webů a porovnat SEO 3. 3.5.1 Cíle analýzy konkurence Zmapování konkurence. Zjištění nedostatků a doplnění funkcionalit námi vyvíjeného systému. Zjištění úrovně SEO u konkurence. 3.5.2 Určení konkurence Konkurence byla vybrána po konzultaci s vedením Nakladatelství Pavel Mervart, podle výsledků vyhledávače Google na dotaz nakladatelství a podle seznamu literatury z oboru společenských věd Almanachu labyrint[8]. Nakladatelství Argo Academia Knihy Nakladatelství Dauphin Aleš Čeněk www.argo.cz www.academiaknihy.cz www.dauphin.cz www.alescenek.cz 3. Search Engine Optimization optimalizace webových stránek pro internetové vyhledávače. Více informací o SEO v kapitole 5.2. <http://www.google.com/support/ webmasters/bin/answer.py?hl=en&answer=35291> 17
3. Analýza 3.5.3 Faktory hodnocení konkurence Kritérium hodnocení Zkoumá se Atraktivita designu Zda je design moderní a přívětivý pro uživatele. Uživatelská zkušenost Zkušební nákup v eshopu, test základních funkcionalit webu. Kvalita zdrojového kódu 4 Procentuální vyjádření kvality zdrojového kódu. Použití moderních technologií Sociální sítě, speciální efekty apod. RSS[9] Použití technologie RSS pro odběr novinek. Rank Číselné hodnocení stránek podle Google Page Rank 5 a S-Rank 6. Mobilní verze Zda web využívá nějakou alternativu zobrazení pro mobilní telefony. 3.5.4 Analýza konkurence webu www.pavelmervart.cz Nakladatelství Kvalita zdrojového kódu Použití sociálních modulů Google Page- Rank S- Rank RSS Mobilní verze Argo 83% NE 5/10 5/10 ANO NE Academia 88% NE 7/10 5/10 NE NE knihy Dauphin 84% NE 5/10 3/10 NE NE Aleš Čeněk 83% ANO 5/10 5/10 ANO NE 3.5.4.1 Nakladatelství Argo Design je zastaralý a neatraktivní. Během krátkého seznámení s webem nebyla pozorována možnost zakoupit knihy online. Sběr emailů pro informování uživatelů takzvaným newsletterem funguje tak, že uživatel musí poslat email na oficiální emailovou adresu nakladatelství s žádostí o přidání do seznamu 4. Analýza zdrojového kódu podle SEO Servis. <http://seo-servis.cz/ source-zdrojovy-kod/> 5. <http://infolab.stanford.edu/~backrub/google.html> 6. <http://napoveda.seznam.cz/cz/hledani-fulltext-algoritmus-vyhledavanirazeni-vysledku-faq-dotazy.html#co-je-to> 18
3. Analýza emailů. Obsah webu je kvalitní, i proto je nejspíše web dobře hodnocen vyhledávači. K silnějším stránkám webu také patří možnost hodnocení a komentáře u každé knihy. 3.5.4.2 Academia knihy Moderní střízlivý vzhled webu budí dojem seriózní společnosti. Nákup je velmi intuitivní a jednoduchý, bez zbytečné registrace. Veškeré důležité informace jsou snadno dostupné a neztrácejí se ve směsi ostatních informací. Na hlavní stránce je v jednom krátkém odstavci shrnuto vše podstatné k nákupu a bez zbytečného hledání následuje nabídka prvních knih. Web je dostupný ve dvou jazykových mutacích. 3.5.4.3 Dauphin Nic neříkající úvodní stránka vítá uživatele fotografií a až po kliknutí jej pustí k opravdovému obsahu webu. Menu v levé částí webu je zmatené a není z něho zcela jasné, že je víceúrovňové. Na úvodní straně hned pod novinkami je seznam nových knih. Ke knihám je přidán zbytečně obsáhlý text, který by mohl být například až v profilech jednotlivých knih. Bohužel tento obchod samostatné profily knih neobsahuje. Největším nedostatkem je bez pochyby stejný titulek na všech stránkách webu. Design webu působí příjemně a neagresivně. Kladně hodnotím jednoduchost objednání z nákupního košíku, bez zbytečné předchozí registrace. 3.5.4.4 Aleš Čeněk Internetový obchod Vydavatelství a nakladatelství Aleš Čeněk s.r.o. disponuje opravdu moderním designem, který nijak nepoškozuje funkčnost webu, naopak vyzdvihuje ty nejdůležitější části. Rozložení webu je ideální s horizontálním menu a seznamem kategorií v levé části. Katalog produktů je přehledný a snadno ovladatelný. Nákup je také velmi intuitivní. 3.6 Výsledek analýzy konkurence Z provedené analýzy vyplynulo: Internetový obchod by měl nabízet své produkty už na hlavní stránce webu. Levý sloupec layoutu by měl obsahovat seznam kategorií. 19
3. Analýza Zvážit využití RSS. Zahrnout do obchodu sekci nejprodávanější knihy. Nikdo z konkurentů nepoužívá žádný typ mobilní verze webu. Sociální moduly jsou využívány pouze jedním z vybraných konkurentů. V polovině případů konkurence nedisponuje kvalitní optimalizací pro vyhledávače, ale má web naplněný kvalitním obsahem, což je také kritérium pro dobré hodnocení od vyhledávačů. 3.7 Analýza původního internetového obchodu Kvalita zdrojového kódu Použití sociálních modulů Google Page- Rank S- Rank RSS Mobilní verze 71% NE 5/10 2/10 NE NE Zastaralý vzhled webu je pouze špatnou vlastností, ale občasné chyby zobrazení už jsou nedostatkem, kterému se musí dobrá webová stránka vyhnout. Na obrázku 3.6 je vidět, že položka katalogu překrývá část nabídky s edicemi. Pro názornost je přiložen obrázek 3.7, kde je nabídka s edicemi zobrazena celá bez chyb. Obrázek 3.6: Chybné zobrazení položek obchodu 20
3. Analýza Obrázek 3.7: Správné zobrazení položek obchodu V původní verzi internetového obchodu je uživatelům nabízena možnost objednávky zboží, ale pouze pomocí emailu, což uživatele zvyklé na jednoduché vyplnění objednávkového formuláře odrazuje a obchod pak ztrácí zákazníky. Orientace v kategoriích je také velmi neintuitivní a zmatená. Vzhledem k hodnocení webu vyhledávači se dá předpokládat, že při nápravě chyb a optimalizaci pro vyhledávače by mohl být web úspěšný, protože i bez SEO se výsledky drží na přijatelných příčkách. 21
Kapitola 4 Webdesign S pojmem webdesign je často spojováno vše, co se týká vývoje webových stránek. Ani v této práci se tomuto pojmu nelze vyhnout. Přiblížíme si jej pomocí jednotlivých oborů webdesignu, které jsou klíčové při tvorbě kvalitních stránek. 4.1 Přístupnost Jedno z nejvíce opovrhovaných odvětví jinak velmi oblíbeného pojmu webdesign se zabývá bezbariérovostí veškerého obsahu webu. Jednodušeji řečeno, určuje pravidla, která umožňují všem uživatelům získat maximum informací poskytovaných na stránce. V předchozí větě je důležité slovo všem, protože právě to je klíčové k pochopení významu slova přístupnost. Jestliže chceme v prostředí Internetu prodávat nějaký produkt, zajímají nás všichni návštěvníci našeho webu, protože každý z nich může být potenciální zákazník. Právě proto je důležité, aby se správně zobrazil veškerý obsah, který poskytujeme, a aby se náš web nestal pro nikoho neovladatelným (nepřístupným). Existuje několik handicapů, které mohou uživateli ztížit prohlížení webu a nemusí se jednat pouze o zdravotní handicap. 1. Zdravotní dispozice Existují uživatelé, kteří nejsou schopni web ovládat například pomocí myši, někteří špatně vidí a další se nedokáží soustředit. 2. Nezkušení uživatelé Internetu Dnes budeme takové hledat hůře, než před několika lety, ale jistě takové nalezneme, například seniory. 3. Technické vybavení Ne všichni disponují nejmodernějším vybavením, někteří uživatelé používají i mnoho let stará zařízení, jiní naopak používají k prohlížení Internetu nejmodernější mobilní telefony. 4. Softwarové vybavení Každý uživatel může používat jiný operační systém i prohlížeč, kterým prochází Internet. 22
4. Webdesign Všechny tyto čtyři typy uživatelů, jak je popsal David Špinar ve své knize o tvorbě přístupných webů[10], jsou možnými zákazníky. Lze namítnout, proč by si nevidomý kupoval knihu, ale proč by ji nemohl koupit příteli k narozeninám? Je důležité uvěřit, že opravdu kdokoliv by mohl mít zájem o nabízené zboží, jen se mu k tomu nesmí klást překážky. 4.2 Použitelnost Jednoduše by stačilo zmínit fakt, že použitelné je to, co uživatelé rádi používají. Toto tvrzení není daleko od pravdy. Pojem použitelnost je však o trochu složitější. Jedná se o soubor pravidel, která určují, jak se má web chovat, v kterých místech stránky uživatel očekává konkrétní funkcionality, co se má skrývat pod jakým odkazem a podobně. Pravděpodobně neexistuje 100% použitelný web, protože velmi záleží na tom, co vyhovuje každému uživateli, ale platí, že při dodržování pravidel použitelnosti se lze zmiňované úplné použitelnosti aspoň přiblížit. Základním pravidlem použitelnosti je nenutit uživatele přemýšlet. [12] 4.3 Layout Obrázek 4.1: Dvousloupcový layout Layoutem webu se rozumí rozložení obsahu na stránce. Rozdělení do základních částí, jako je hlavička, obsah, postranní panel a patička webu. Prvně rozlišujeme layout dle jeho šířky, která může být fixní, roztahovací, fluidní, přizpůsobivá a elastická[4]. Nejjednodušším způsobem, který je také 23
4. Webdesign zvolen v případě této práce, je fixní layout. S ohledem na statistiky rozlišení monitorů dle společnosti Toplist 7, která monitoruje téměř 900 000 českých webů, bylo pro tuto práci zvoleno fixní rozlišení o šířce 1024px. Rozložení webu do dvousloupcového layoutu bylo vyžadováno zadavatelem. Z pohledu analýzy obsahu je dvousloupcový layout pro tuto práci ideálním řešením. Jednosloupcový by byl nedostatečný z hlediska prostoru pro ostatní funkcionality obchodu a třísloupcový layout by zbytečně tříštil prostor pro obsah. 4.4 Mobilní verze webu Prohlížení webových stránek na mobilním telefonu je poměrně starou záležitostí, ale v poslední době toto odvětví zažívá veliký boom. Především kvůli rozšíření takzvaných chytrých telefonů, které jsou k prohlížení webových stránek přívětivé. Mobilní stránky mají několik vlastností[11], které je odlišují od webu, jak jej známe z prohlížení na osobních počítačích. Web si z mobilního telefonu prohlíží uživatelé, kteří jsou obvykle v pohybu, například cestují, proto je pro ně těžší udržet pozornost na displej telefonu. Uživatelé hledají pouze konkrétní informaci, například telefonní číslo. Psaní na telefonu je náročnější, než na plnohodnotné klávesnici, proto by mobilní web měl vyžadovat co nejméně uživatelských vstupů z klávesnice a místo nich nabízet výběr pomocí HTML tagu select. Mobilní telefony mívají pomalejší přístup k Internetu, proto bychom měli zajistit co nejnižší možnou velikost přenášených dat. Mobilní telefony mají omezený výkon a specifické nároky na zobrazení (rozměry displeje). Uživatelé na mobilních zařízeních obvykle využívají 20% nejdůležitějších funkcionalit nabízených na celém webu. Toto je výběr dle mého názoru nejdůležitějších rozdílů mezi mobilním webem a webem pro osobní počítač. Rozdílů však existuje mnohem více. Jedním z nejdůležitějších je fakt, že v roce 2009 používala laptop či osobní 7. <http://www.toplist.cz/global.html> 24
4. Webdesign počítač jedna miliarda lidí. Oproti tomu mobilní telefon používají tři miliardy lidí na celém světě. Nyní už snad není pochyb o důležitosti optimalizace mobilního webu. [11] 25
Kapitola 5 Implementace V této kapitole je uveden výčet technologií zvolených pro vývoj internetového obchodu spolu s jejich krátkým popisem, postup při SEO optimalizaci a nasazení mobilního webu. V závěru lze nalézt několik zajímavostí z implementace celého systému. 5.1 Použité technologie K vývoji systému byly vybrány výhradně Open Source 8 technologie, které jsou hojně využívány v prostředí Internetu. Serverovou část aplikace obstarává skriptovací jazyk PHP a databáze MySQL. V klientské části jsou použité technologie HTML5, CSS 2.0 a JavaScript. 5.1.1 HTML/XHTML HTML je značkovací jazyk určující strukturu obsahu stránky. Například stanovení nadpisů, odstavců, vložení obrázků a další. Spolu se stylopisem CSS zajišťuje oddělení obsahu od vzhledu stránek. V současné době se nejhojněji používá verze HTML 4.01[13] a XHTML 1.0[14]. Od roku 2010 je novinkou verze HTML5[15], právě tato specifikace byla zvolena pro implementaci v této práci. Jaký značnovací jazyk používá konkurence? Argo Academia Knihy Nakladatelství Dauphin Aleš Čeněk HTML 4.01 Transitional XHTML 1.0 Strict HTML 4.0 Transitional XHTML 1.0 Strict 8. <http://www.opensource.org/> 26
5. Implementace 5.1.2 HTML5 Značkovací jazyk HTML5 byl zvolen pro kódování klientské části této práce z těchto důvodů: 1. Jedná se o nejnovější značkovací jazyk, který nyní určuje směr vývoje obsahu Internetu. 2. Přináší vylepšení v mnoha ohledech uživatelského rozhranní. 3. Vychází ze specifikace HTML 4.01, která je podporována ve všech prohlížečích, a pouze ji rozšiřuje, takže je možné použít HTML5 i v internetových prohlížečích, které ho zatím nepodporují. 9. Novinky zavedené v HTML5 se v nich nezobrazí, ale stránka bude plně funkční. Zavedení HTML5 může být pro některé návštěvníky webové stránky výhodou a ostatní tuto změnu nepoznají, protože se jim stránka zobrazí, jako by byla v HTML 4.01. Tímto žádnému zákazníkovi neuškodíme, ale těm, kteří používají moderní prohlížeče s podporou HTML5, bude poskytnuto lepší rozhranní. [16] 5.1.3 PHP Skriptovací jazyk PHP se dá považovat za novinku mezi programovacími jazyky. Do povědomí se dostal v roce 1998 svou verzí PHP 3. Nyní je ve verzi 5.3 hojně využíván po celém světě k vytváření dynamických webových stránek. Umožňuje objektové programování. 5.1.4 MySQL Jak se sami honorují v titulku svéhoho webu, jedná se o nejpopuulárnější volně šiřitelnou databázi[17]. I to bylo jedním z hlavních důvodů k výběru tohoto databázového systému pro účely implementace internetového obchodu. S touto databází se lze setkat téměř u každého poskytovatele hostingových služeb. MySQL, jak název napovídá, komunikuje s databází pomocí dialektu jazyka SQL, obdobně jako jiné SQL databáze. 9. Toto tvrzení platí například pro nové typy formulářových vstupů, ale neplatí komplexně, protože HTML5 zavádí nové značky, které starší prohlížeče mají problém vykreslit. 27
5. Implementace 5.1.5 Nette Framework Obcené pojmenování framework znamená nadstavbu nad programovacím jazykem, která poskytuje dodatečné třídy a metody zjednodušující vytváření aplikace. Nette Framework[18] také zavádí postupy vývoje, které přispívají k přehlednosti a dekompozici zdrojového kódu. Jedná se o objektovou architekturu MVC (Model-View-Controler) 10. Ta slouží k oddělení tří častí aplikace: 1. aplikační logika (model), 2. zobrazení dat uživateli (view), 3. obsluha aplikace (controler). 5.1.5.1 Dibi Pro komunikaci s databází MySQL slouží dialekt jazyka SQL jehož dotazy jsou vytvářeny v aplikaci. Dibi[19] je vrstva mezi databází a aplikací, pomáhá a zabezpečuje vytváření SQL dotazů a zpracování jejich výsledků. Pochází od stejného autora, jako samotný Nette Framework, je proto uzpůsobena primárně k použití právě s tímto frameworkem. 5.1.6 jquery Původně tato sekce měla nést nadpis JavaScript, ale vzhledem k tomu, že spíše než JavaScript je v práci využita jeho knihovna jménen jquery, došel jsem k názoru, že bude lepší tuto kapitolu pojmenovat podle ní. jquery[20] pracuje na straně klienta, pomocí metod objektů specifikace DOM 11. dokáže jednoduše modifikovat HTML kód a tím obsah stránky. V této práci je využit především k animacím, které slouží ke zvýšení atraktivity stránky. Příkladem může být modul jcarousel 12 na hlavní stránce či zaoblení rohů některých prvků webu v prohlížeči Internet Explorer 13. 10. <http://doc.nette.org/cs/presenters#toc-model-view-controller-mvc> 11. Document object model rozhraní, které umožňuje skriptům přistupovat ke struktuře dokumentu jako k objektům a modifikovat tak jejich obsah, strukturu a styly. <http: //www.w3.org/dom/> 12. <http://sorgalla.com/jcarousel/> 13. <http://www.dillerdesign.com/experiment/dd_roundies/> 28
5. Implementace 5.1.7 AJAX Technologie AJAX 14 slouží ke změně obsahu bez nutnosti znovunačtení celé www stránky. Změna funguje tak, že na straně klienta je pomocí JavaScriptu (jquery) vytvořen dotaz, který je odeslán ke zpracování na server. Tam se o jeho vyřízení postará PHP. Výsledek je předán zpět do prohlížeče, kde ho opět JavaScript vykreslí do stránky. V této práci nebylo nutné zavádět AJAX, pouze pro ukázku funkčnosti bylo implementováno zpracování formuláře pro vyhledávání v objednávkách v administrační části systému. Výhodou Nette Frameworku je podpora této technologie a její snadné nasazení. Zároveň se framework stará o zpracování požadavků při nedostupném JavaScriptu, tím splňuje požadavky na přístupnost. 5.1.8 Výstupy Hlavním výstupem je grafické rozhraní, kterým lze systém ovládat. Ostatní výstupy neumožňují ovládání systému, ale data uložená v databázi zpřístupňují pro externí aplikace, které s nimi pracují a díky nim vytvářejí v Internetu další odkazy na vytvářený eshop. Toto je důležité především z hlediska SEO optimalizace. 5.1.8.1 Zboží.cz V České republice je asi nejznámějším agregátorem a vyhledávačem zboží server Zboží.cz, který provozuje společnost Seznam a.s. Tento server čerpá pomocí XML 15 výstupů z internetových obchodů informace, které následně zpracovává a poskytuje uživatelům ve výsledcích vyhledávání. Nabízí další funkce, jako je například porovnávání zboží, řazení dle ceny a podobně. 5.1.8.2 Mapa webu Pomocí další specifikace XML je možné nabídnout vyhledávacím robotům seznam všech stran internetového obchodu. Tato funkce není vyvinuta pouze pro účely jednoho vyhledávače, ale výstup je standardizován dle protokolu Sitemap 16. Soubor tak může sloužit všem internetovým vyhledávačům, které 14. Asynchronous JavaScript and XML <http://www.w3schools.com/ajax/ajax_intro.asp> 15. Specifikace XML pro Zboží.cz <http://napoveda.seznam.cz/cz/zbozi/ napoveda-pro-internetove-obchody/specifikace-xml/> 16. Přesnou specifikaci protokolu Sitemap lze nalézt na <http://www.sitemaps.org/ protocol.html> 29
5. Implementace pravidelně procházejí celý Internet. Není to zaručená cesta k prosazení se na přední pozice vyhledávačů, ale bezesporu je tím podpořeno SEO. Mapa webu pro mobilní telefony Stejná specifikace mapy webu existuje také pro webové stránky určené pro mobilní telefony. Tato funkce je podporována vyhledávačem Google, který za tímto účelem zavedl do původní specifikace Sitemap vlastní namespace 17 sloužící k identifikaci, že se jedná o mobilní verzi webové stránky. 5.1.8.3 RSS RSS je zkratka anglického názvu Rich Site Summary. Jedná se o XML specifikaci, která se hojně využívá k syndikaci nově zveřejněného obsahu na webových stránkách. Tento výstup z aplikace zpravidla odebírají uživatelé ve svých RSS čtečkách, prostřednictvím kterých jsou upozorněni na nový obsah webu. 5.2 SEO Search engine optimization Optimalizace pro vyhledávače je velmi důležitá disciplína, která pomáhá umístit webovou stránku na přední pozice vyhledávačů. Existují jasně daná pravidla, která jsou základem pro optimalizaci, ale nezaručují úspěch. Dodržením základních pravidel je zajištěn pouze možný úspěch. Tato pravidla se nazývají onpage faktory (faktory na stránce). Jejich splnění zajišťuje programátor. Opakem onpage faktorů jsou offpage faktory, které se programátorům ovlivňují hůře, protože se nenachází přímo na webu, ale kdekoli v Internetu. Jedná se především o zpětné odkazy, které mají jednu z nejdůležitějších rolí v celé optimalizaci pro vyhledávače. Mezi onpage faktory patří: Dodržení správného významu HTML značek. Kvalita zdrojového kódu, správná struktura a přístupnost. Dostatek kvalitních textů. 17. Pokud je kombinováno více specifikací XML, mohlo by docházet ke konfliktu jmen, proto jsou zavedeny takzvané namespace, které obalují a oddělují jednotlivé specifikace, ty pak mohou být bez problému použity společně.[21] 30
5. Implementace Nejdůležitější offpage faktor Již zmíněným nejdůležitějším offpage faktorem je získání kvalitních zpětných odkazů. Ty lze získat výměnou odkaz za odkaz s jiným tematicky podobným webem. Lze je také koupit, ale ideálním případem je, když na vyvíjený web někdo cizí odkazuje automaticky. Toho se dá docílit tím, že bude web bohatý na obsah, přehledný a stane se pro některé nepostradatelným. 5.3 Zajímavosti Při vývoji internetového obchodu pro knihkupectví jsem se setkal s několika problémy, které bylo třeba řešit. Zamyšlení nad jejich podstatou mě v několika případech dovedlo k neobvyklému řešení, o které bych se na tomto místě rád podělil. 5.3.1 Generování obrázků Při přidávání nové knihy do systému se spolu s informacemi o knize vkládá obrázek obálky. Pokud uživatel vkládá na server obrázek o velikosti větší než 1GB, ze kterého se zároveň generují další miniatury, může být tato operace časově náročnější. Řešením by bylo umožnit vkládání pouze menších obrázků, ale omezování uživatele není dobrá cesta ke kvalitnímu systému. Framework Nette má implementován systém cest (tvz. rout), které určují, kudy se má ubírat zpracování jednotlivých požadavků. Tato vlastnost ve spojení s konfigurací souboru.htaccess 18 umožňuje zpětné generování obrázků. V praxi to znamená, že při nahrávání obrázku na server se neprovádí žádné časově náročné generování miniatur, ale miniatury se generují až pokud je někdo vyžaduje. Tímto způsobem se generování obrázků rozloží na více dotazů, které trvají kratší čas. Obrázek 5.1: Soubor.htaccess Pomocí definice v souboru.htaccess (obrázek 5.1) se zjistí, zda je fotografie již fyzicky přítomna na serveru. Pokud ano, je obrázek bez dalších prodlev zobrazen. Pokud obrázek v daném umístění není nalezen, je vyžadován po frameworku. Ten pomocí cesty z obrázku 5.2 předá zpracování do presenteru 18. <http://httpd.apache.org/docs/1.3/howto/htaccess.html> 31
5. Implementace Obrázek 5.2: Route Nette Frameworku ImagesPresenter a akci default, proměnné id, velikost a format jsou předány jako parametry. Zde se požadovaná miniatura vygeneruje a následně přímo zobrazí. 5.3.2 Registrace Registraci nových zákazníků obchodu lze realizovat pomocí čtyř scénářů. 1. Vyžadovat registraci do systému ještě dříve, než bude moci uživatel začít nakupovat. 2. Registraci předem nevyžadovat, ale umožnit ji. Uživatele bez registrace automaticky registrovat při odeslání objednávky. 3. Při prvním nákupu uživatele ho automaticky registrovat. Jinou registraci nenabízet. Při každém dalším nákupu nabídnout možnost přihlášení se a tím zjednodušit proces vyplňování údajů o objednávce. 4. Registraci neumožňovat, při každém nákupu vyžadovat zadání osobních údajů nutných k objednávce. Při vyplňování objednávky nabídnout k zaškrtnutí položku pamatovat tyto údaje. Informace o objednávce se pak uloží bezpečně na serveru po dobu 365 dní. Pokud se během této doby uživatel vrátí a vytvoří novou objednávku, automaticky se mu předvyplní předchozí údaje, které bude možno buď změnit, nebo zachovat. Ve snaze o maximální zjednodušení celého procesu objednávky je využito varianty číslo čtyři. 5.3.3 HTML 5 V počátku kódování klientské části jsem se rozhodl implementovat JavaScriptový doplněk Modernizr 19, který dokáže ve všech prohlížečích, které neumí 19. <http://www.modernizr.com> 32
5. Implementace vykreslit novinky z HTML5, nasimulovat veškeré prvky tohoto nového značkovacího jazyka. Doplněk byl implementován bez problémů, ale veliké množství externích JavaScriptových souborů značně zpomalovalo načtení stránky. Proto jsem nakonec od implementace Modernizru upustil. 5.4 Mobilní verze webu Vzhledem k masivnímu rozšíření mobilních zařízení, která podporují prohlížení webových stránek, se stává důležitou součástí moderního webu podpora prohlížení na těchto zařízeních. Jak je uvedeno v této práci v kapitole 4.4, mobilní telefon vlastní 3 miliardy lidí na celém světě, oproti jedné miliardě uživatelů stolních počítačů a laptopů. Pro internetový obchod byly uvažovány tři možnosti implementace podpory mobilního prohlížení. 5.4.1 Možnosti implementace Detekovat přístup mobilního zařízení a nabídnout stažení příslušné aplikace do telefonu. Tato aplikace by po instalaci do telefonu zpřístupňovala veškerý obsah a funkcionality dostupné na webu. Připravit mobilní verzi webové stránky, která bude obsahovat nejdůležitější údaje dostupné na webu. Tuto verzi zobrazit při detekci mobilního zařízení. Ponechat jednu verzi webové stránky a nevyvíjet specializované aplikace. Mobilní prohlížeče jsou z veliké části schopny zobrazovat i obsah, který je přístupný pomocí klasických webových stránek. Každé z těchto řešení má své klady a zápory, první řešení je náročné na vývoj, který by mohl být považován za částečně nadbytečný s ohledem na velikost webu. Poslední řešení je pro vývojáře nejjednodušším, ale uživateli by mohlo zkomplikovat prohlížení kvůli vyšší datové zátěži stránek. V tomto případě by tedy mohlo platit zlatá střední cesta. Vytvoření mobilní verze webu, která poskytuje 20% nejdůležitějších funkcí, by mohlo uživatele omezovat. Proto byla zvolena kombinace obsahu optimalizovaného pro mobilní zařízení a možnosti kdykoliv přepnout na klasické zobrazení. Tím je vyřešena dostupnost všech funkcionalit webu a zároveň optimalizace pro zobrazení na mobilních zařízeních. 33
5. Implementace 5.4.1.1 XHTML-MP[11] (Mobile Profile) Jedná se o jazyk XHTML určený pro mobilní platformu. Ve své podstatě je to klasické XHTML zjednodušené pro využití na mobilních telefonech. XHTML-MP má největší podporu ze všech značkovacích jazyků použitelných v mobilních internetových prohlížečích. 34
Kapitola 6 Testování V závěru práce se zaměříme na testování aplikace uživateli, protože právě pro široké spektrum uživatelů Internetu je aplikace určena. Framework Nette prostřednictvím třídy Debug 20 nabízí bohaté možnosti ladění aplikace. Pomocí frameworku lze lehce odlišit vývojové prostředí od produkčního. Ve vývojovém prostředí se zobrazují veškeré chyby, varování i poznámky. V produkčním režimu přístupném veřejnosti je maximum chybových výstupů potlačeno, aby se uživateli nezobrazila žádná informace, která by jednak mohla odradit od nákupu a jednak by mohla být eventuálním bezpečnostním rizikem. Na druhou stranu by nebylo dobré v produkčním režimu tyto chyby přehlížet. Přišli bychom totiž o údaje, které nám mohou posloužit jako upozornění na chybu v aplikaci. Z tohoto důvodu se veškeré chyby zaznamenávají do speciální složky a aplikace nás na chybu upozorní prostřednictvím emailu. Takto je možné použít veškeřé uživatele jako testery aplikace. Obrázek 6.1: Příklad zobrazení chyby v Nette Frameworku 20. Popis ladění aplikace ve Frameworku Nette <http://doc.nette.org/cs/ debugging> 35