Moderní uživatelská rozhraní ve webových aplikacích
Diplomová práce
Studijní program: N2612 – Elektrotechnika a informatika Studijní obor: 1802T007 – Informační technologie
Autor práce: Bc. Luboš Suk
Vedoucí práce: Ing. Roman Špánek, Ph.D.
Liberec 2015
Implementing modern user interfaces in web applications
Diploma thesis
Study programme: N2612 – Electrical Engineering and Informatics Study branch: 1802T007 – Information Technology
Author: Bc. Luboš Suk
Supervisor: Ing. Roman Špánek, Ph.D.
Liberec 2015
Poděkování
Rád bych poděkoval především vedoucímu své diplomové práce, panu Ing.
Romanu Špánkovi, Ph.D. za cenné rady a trpělivost. Dále konzultantovi panu Ing Pavlu Tylovi, který mi pomáhal upřesňovat nejasnosti v průběhu celé práce a také rodině a přátelům, kteří mě při studiu podporovali.
Děkuji Vám.
Abstrakt
Tato diplomová práce se zabývá současnými trendy ve vývoji a návrhu uživatelského rozhraní. Popisuje webové aplikace, zkoumá požadavky na webové aplikace a popisuje jejich architekturu. Jsou zde také popsány principy uživatelského rozhraní, jeho prvky, hodnotící kritéria a uvádí moderní trendy a přístupy k tvorbě uživatelského rozhraní u webových aplikací. Dále se práce zaměřuje na technologické možnosti pro vytváření bohatých uživatelských rozhraní jako je HTML5 nebo javascriptové a CSS frameworky.
Dále se zaměřuje na návrh změn uživatelského rozhraní již existující aplikace, aby byla co nejvíce uživatelsky přívětivá. Popisuje jednotlivé návrhy na změny a jejich konkrétní prezentaci v nové verzi aplikace. Dále se zabývá popisem konkrétních technologií, které byly v aplikaci použity a jejich konkrétní implementace. Rovněž obsahuje zpětnou vazbu od uživatelů, z které byly stanoveny doporučení, jak řešit uživatelské rozhraní pro webové aplikace obdobné funkcionality a typu.
Klíčová slova
Uživatelské rozhraní, bohaté webové aplikace, responzivní webdesign, javascript, HTML 5, CSS 3.
Abstract
This thesis deals with modern trends in design and development of user interface.
It describes web applications, researches requirements on web applications and describes their architecture. There are also described principes of user interface, its elements, rating criterias and presented modern trends and approaches in creating user interface in web applications. Thesis further describes technological options to create rich user interface as HTML 5 or javascript and CSS frameworks.
Thesis then focuses on concrete changes in user interface of existing application to make it more user friendly. The thesis describes this suggestions and their concrete implementation in application. Then describes technologies which were used and their concrete implementation. It also concerns recommendations how to create user interface in similar web applications based on user feedback.
Keywords
User interface, rich web applications, responsive webdesign, javascript, HTML 5.
CSS 3.
8
Obsah
Poděkování ... 5
Abstrakt ... 6
Klíčová slova ... 6
Abstract ... 7
Keywords ... 7
Obsah ... 8
Seznam obrázků ... 10
1 Úvod ... 11
2 Webové aplikace ... 11
2.1 Požadavky na webové aplikace ... 12
2.1.1 Technické požadavky ... 12
2.1.2 Ergonomické požadavky ... 12
2.2 Architektura webových aplikací ... 13
2.2.1 Prezentační vrstva ... 13
2.2.2 Aplikační vrstva ... 14
2.2.3 Datová vrstva ... 14
2.3 Stav aplikace ... 15
3 Uživatelské rozhraní ... 15
3.1 Principy uživatelského rozhraní ... 15
3.2 Prvky uživatelského rozhraní ... 18
3.3 Hodnotící kritéria z hlediska norem ... 19
3.4 Hodnotící kritéria z hlediska uživatele ... 19
4 Moderní trendy v tvorbě uživatelského rozhraní ... 20
4.1 Responsivní webdesign ... 20
4.1.1 Desktop first ... 22
4.1.2 Mobile first ... 22
4.2 Bohaté webové aplikace ... 23
4.2.1 Vývoj bohatých webových aplikací ... 24
5 Technologické možnosti uživatelského rozhraní ... 26
5.1 HTML 5 ... 26
5.1.1 Struktura dokumentu ... 27
5.1.2 Nové formulářové prvky ... 27
5.1.3 Local Storage ... 28
5.1.4 Další funkčnost ... 29
5.2 CSS 3 ... 29
5.3 Frameworky ... 29
5.3.1 Twitter Bootstrap ... 30
5.3.2 ZURB Foundation ... 30
5.3.3 jQuery ... 31
5.3.4 MVC Frameworky ... 31
6 Návrh změn aplikace ... 33
6.1 Předchozí stav aplikace ... 33
6.2 Zpětná vazba od uživatelů ... 35
6.2.1 Změny v seznamech položek ... 35
6.2.2 Detail položek ... 36
7 Přehled změn v aplikaci ... 37
7.1 Uživatelská oprávnění ... 38
9
7.2 Změny v seznamech projektů a úkolů ... 38
7.3 Manipulace s položkami ... 40
7.3 Domovská stránka ... 43
7.4 Ganttův diagram ... 43
7.5 Fulltextové vyhledávání ... 44
7.6 Informační zprávy ... 45
7.7 Detail projektu a úkolu ... 46
7.8 Shrnutí změn ... 47
8 Použité technologie ... 48
8.1 DataTables... 48
8.2 YADCF – Yet Another DataTable Column Filter ... 50
8.3 Localstorage ... 51
8.4 AJAX ... 52
8.5 Twitter Bootstrap ... 53
9 Doporučení při tvorbě obdobných aplikací ... 54
10 Závěr ... 55
Seznam literatury ... 56
10
Seznam obrázků
Obrázek 1 Architektura a propojení vrstev typické webové aplikace ... 14
Obrázek 2 Zóna dosahu palce na mobilním telefonu s uhlopříčkou 4,3'' [14] ... 23
Obrázek 3 Struktura menu aplikace ... 34
Obrázek 4 Use case diagram uživatelů v aplikaci ... 35
Obrázek 5 Seznam projektů a úkolů ... 36
Obrázek 6 Detail projektu ... 37
Obrázek 7 Menu aplikace ... 37
Obrázek 8 Uživatelská oprávnění ... 38
Obrázek 9 Seznam projektů a úkolů ... 39
Obrázek 10 Menu položky ... 40
Obrázek 11 Formulář editace projektu... 41
Obrázek 12 Javascriptový kalendář ... 42
Obrázek 13 Domovská stránka ... 43
Obrázek 14 Ganttův diagram ... 44
Obrázek 15 Fulltextové vyhledávání ... 45
Obrázek 16 Ukázka zpráv ... 46
Obrázek 17 Detail projektu ... 46
Obrázek 18 Implementace pluginu DataTables ... 49
Obrázek 19 Implementace tabulky potomka ... 50
Obrázek 20 Konstruktor filtru YADCF ... 51
Obrázek 21 Odeslání formuláře pomocí technologie AJAX ... 52
11
1 Úvod
Tato diplomová práce se zabývá problematikou moderních uživatelských rozhraní ve webových aplikacích. První kapitola bude přibližovat samotné téma webových aplikací pro lepší pochopení následujících částí práce, které jej rozvíjejí. Další kapitoly pak budou popisovat uživatelské rozhraní a současné trendy v jeho vývoji, stejně jako technologie, které lze použít pro vytváření webových aplikací. V praktické části se práce bude věnovat návrhu možných řešení pro konkrétní implementaci pro systém sledování projektů ve společnosti TRW a poté pilotní implementaci navržených řešení. Zahrnuta bude rovněž zpětná vazba od uživatelů, ze které budou vyvozena doporučení pro tvorbu uživatelských rozhraní pro webové aplikace podobného typu.
2 Webové aplikace
Historie samotných webových aplikací je neodmyslitelně spjata s historií klasických webových stránek. V roce 1995 vznikl programovací jazyk PHP [1], který byl určen pro nasazení v oblasti webových stránek, je interpretovaný a vykonává se na straně serveru. Dnes bychom řekli, že je určen pro vývoj webových aplikací, tehdy se ovšem hovořilo o dynamických webových stránkách. Následný nárůst funkcionality webových stránek vedl k tomu, že se Internet začal používat jako médium pro provoz aplikací různého charakteru. V roce 1999 díky tomu vznikla nová disciplína, a to webové inženýrství [2]. Tato disciplína se zabývá specifickými vlastnostmi vývoje aplikací pro Internet a v jejím rámci jsou takové aplikace nazývány jako webové aplikace.
Přesná definice pojmu webová aplikace chybí, ale obecně můžeme říci, že webová aplikace je webová stránka, která neslouží pouze k prezentování statických textových dat, ale obsahuje vykonavatelný kód, umožňující interakci s aplikací. Jinými slovy to znamená, že webová aplikace je rozšíření webové stránky obsahující vykonatelný kód, jenž představuje přidanou funkcionalitu, a nezáleží na tom, zda je vykonáván na straně serveru nebo klienta v prohlížeči. Jelikož by se takto ale dala označit i stránka s jednoduchým vyhledáváním, je nutné zdůraznit, že webová aplikace není určena primárně k prezentaci statických textových dat. Jako příklad takové webové aplikace můžeme uvést různé internetové obchody, internetové bankovnictví, webové e-mailové klienty nebo fulltextové vyhledávací služby.
12 V současnosti je použití webových aplikací velice široké, jsou nasazeny i v takových oblastech, které byly dříve výsadní doménou klasického desktopového software, které nevyužívaly připojení k Internetu. Tyto aplikace mohou plně nahradit desktopové alternativy, ať už například kancelářský nebo geografický sotware, jak si lze všimnout v případě Google Docs nebo třeba Mapy.cz.
2.1 Požadavky na webové aplikace
Na webové aplikace jsou kladeny určité požadavky, které by měly splňovat.
Základem je přiblížit jejich ovládání a funkce co možná nejvíce klasickým desktopovým aplikacím, aby uživatelé při práci s nimi mohli užívat své návyky získané právě z desktopových aplikací. Z toho planou dvě oblasti požadavků, technické a ergonomické.
Obě oblasti budou podrobněji popsány v následujících podkapitolách.
2.1.1 Technické požadavky
Mezi technické požadavky můžeme zařadit následující položky:
- kompatibilita s webovými prohlížeči – typické jsou chyby při zobrazování kaskádových stylů nebo možnosti uživatelských nastavení, které mají vliv na výsledný vzhled stránky, případně na její funkčnost;
- rychlost – rychlost aplikace je doba zpracování požadavku uživatele a vykreslení výsledku, závisí na rychlosti připojení serveru a klienta k síti, což programátor nemůže příliš ovlivnit;
- limity pro uživatele – může se týkat limitů přidělené operační paměti, maximálního času, po který může být vykonáván skript nebo maximální velikosti nahrávaného souboru.
2.1.2 Ergonomické požadavky
Mezi ergonomické požadavky spadají tyto položky:
- uživatelské rozhraní – je očekávána jistá atraktivita, ale zároveň zachování přehlednosti, logického dělení a celkové grafické přívětivosti;
- ovládání – měly by být využívány takové technologie, které uživatelům mohou nabídnout interaktivní ovládání aplikace, dříve dostupné pouze u desktopových aplikací;
- pohyb v aplikaci – uživatelé by měli být informováni, kde se nacházejí, pro pohyb v
13 aplikaci by měli sloužit klasické navigační prvky a informativní část by měla být jasně oddělena od ovládacích prvků.
2.2 Architektura webových aplikací
Co se týče používané architektury webových aplikací, nejčastěji využívají třívrstvou architekturu. To znamená, že obsahují prezentační, aplikační a datovou vrstvu, které mezi sebou vzájemně komunikují.
V některých případech můžeme narazit na drobné rozdíly struktury, například mezi aplikační a prezentační vrstvu může být vložena validační vrstva nebo k aplikační vrstvě může být připojena ještě vrstva s obchodní logikou, ale tyto odlišnosti ve struktuře mohou být vysvětleny jako pouhé rozdělení některé z původních vrstev nebo oddělení části jejích funkcí do nové vrstvy.
Na rozdíl od desktopových aplikací spolu prezentační a aplikační vrstvy webových aplikací komunikují po Internetu, z čehož pak plynou již zmiňované problémy s časovými prodlevami mezi odesláním požadavku uživatele a získáním odpovědi.
2.2.1 Prezentační vrstva
Prezentační vrstva představuje data zobrazovaná uživateli povětšinou v grafické podobě. V případě webových aplikací se skládá nejen ze zobrazovaných dat, ale také z internetového prohlížeče (interpretu). Ten je do této vrstvy zahrnován vzhledem k jeho charakteristickému postavení v celé webové aplikaci. Generování kódu pro prezentaci zajišťují zejména šablonovací frameworky nebo knihovny, které úplně oddělují prezentační a aplikační logiku. Díky tomu je dodržován princip třívrstvé architektury, který byl dříve často opomíjen, což vedlo k míchání oněch dvou zmíněných logik.
14
2.2.2 Aplikační vrstva
Aplikační vrstva obsahuje logiku aplikace a její interpret nebo platforma pro spouštění je obvykle součást aplikačního serveru, který přijímá požadavky od klienta.
Výběr konkrétní technologie se odvíjí od charakteru aplikace a způsobu jejího nasazení.
Pokud má být nasazena na vlastní server, je volba bez jakýchkoli omezení, což se ovšem běžně nestává. Většinou jsou aplikace nasazovány prostřednictvím hostování na serveru, kde se dělí o jeho výkon s dalšími aplikacemi. Z toho vyplývají různé limity, o kterých je již psáno výše.
2.2.3 Datová vrstva
Úloha datové vrstvy zde zůstává stejná jako u desktopových aplikací, konzistentně uchovává data. Nejčastěji je realizovaná databázovým systémem na samotném databázovém serveru, ale můžeme se setkat rovněž s realizací klasickým souborovým systémem nebo kombinací obou. Tento způsob je vhodný především při ukládání velkých především binárních souborů, kdy je vlastní soubor uložen do souborového systému a do databáze je zanesen pouze odkaz na něj s potřebnými informacemi pro jeho vyhledání.
Obrázek 1 Architektura a propojení vrstev typické webové aplikace
15
2.3 Stav aplikace
V případě webových aplikací je potřeba udržovat jejich stav, je kupříkladu nutné si pamatovat naposledy přihlášeného uživatele, obsah nákupního košíku a podobné údaje.
Jelikož je však protokol HTTP, po kterém probíhá komunikace se serverem, bezestavový, server nevidí žádné souvislosti mezi požadavky uživatele a není tudíž schopen s určitostí zjistit, z jaké aplikace a kterým uživatelem byl konkrétní požadavek odeslán. Zde je další rozdíl oproti desktopovým aplikacím. Uchovat stav aplikace lze několika různými způsoby, které jsou využitelné u všech obvykle používané při implementaci aplikační vrstvy. [3, 4]
3 Uživatelské rozhraní
Uživatelské rozhraní, tedy prezentační vrstva, má u webových aplikací velice specifické postavení, proto je mu věnována celá samostatná kapitola. V následujících řádkách bude popsána jeho definice, principy, hodnocení z hlediska norem a z hlediska uživatele a jeho prvky či aspekty. Uživatelské rozhraní může být definováno jako část aplikace sloužící pro interakci s uživatelem, což si laicky můžeme představit jako určitou podobu interakce člověka s počítačem při zpracování a využívání dat.
Vývoj uživatelského rozhraní probíhal postupně spolu s vývojem počítačového zpracování. V závislosti na tom, jak byly vyvíjeny stále lepší operační systémy, přizpůsobovalo se jejich potřebám také uživatelské rozhraní. Tak se vývoj posouval od počáteční příkazové řádky až ke grafickému uživatelskému rozhraní.
Dobře navržené uživatelské rozhraní je výhodné nejen z hlediska uživatele, který hodnotí jeho vzhled, a proto by právě vzhled měl v tomto případě hrát hlavní roli při vývoji, ale také z hlediska nákladů. Kvalitně provedený návrh rozhraní totiž snižuje náklady na používání aplikace. Ve fázi vývoje aplikace se může pozitivně projevit pěkně promyšlený design, aby případné změny v pozdějších fázích vývoje nebyly tolik časově náročné, a tedy i drahé.
3.1 Principy uživatelského rozhraní
Jednotlivé principy uživatelského rozhraní si ukážeme na základě standardů firem Apple a Microsoft. Standardy firem jsou velice rozsáhlé manuály stanovující vzhled a chování uživatelských rozhraní aplikací a nejlepší jsou právě od těchto tvůrců operačních
16 systémů. Od firmy Apple je to dokument Human Interface Guidelines [5], manuál Microsoftu se nazývá Microsoft Official Guidelines for User Interface Developers and Designers [6]. Nyní budou vyjmenovány veškeré základní principy, které tyto standardy uvádějí, a bude k nim připojen stručný popis.
- WYSIWYG - tato zkratka znamená „what you see is what you get“, což lze jednoduše vysvětlit tak, že výstup z počítače by měl být shodný s tím, co vidíme na obrazovce. Tento princip by měl platit nejen pro textové dokumenty, ale rovněž pro webové stránky a další formáty. Jakmile uživatel provede jakoukoli změnu v dokumentu, měla by se změna okamžitě projevit i ve výstupu, díky čemuž uživatel ihned rozezná chybu a opraví ji, aniž by pokračoval v dalších (tím pádem již chybných) krocích. Díky tomuto principu je aplikace také mnohem přehlednější. Jeho nevýhodou ovšem je kupříkladu nedokonalá shoda mezi výstupem a obrazovkou;
- konzistence
-
tento princip umožňuje uživatelům používat jejich naučené návyky nebo postupy z aplikací v nových programech či situacích. Aplikuje se na třech úrovních, a to prezentace, chování a interakční techniky. Prezentace v tomto případě znamená, že informace a objekty jsou zobrazovány v podobné vizuální a logické struktuře v rámci celé aplikace (např. neměnné informace by měly mít stejnou barvu textu, popisky různých funkcí by měly být co nejvýstižnější, použitá terminologie by měla odpovídat ostatním aplikacím atd.). Co se týče chování, podobné prvky by se měly podobně také ovládat a ovládání v různých verzích aplikace by mělo zůstat stejné nebo alespoň hodně podobné.Pod interakčními technikami si můžeme představit třeba použití různých klávesových zkratek (např. CTRL+V nebo CTRL+S) nebo standardní chování při práci s myší;
- přímá manipulace
-
představuje akce s virtuálními objekty (vybírání, zvětšování, přemisťování, mačkání tlačítek apod.). Měla by v uživateli vyvolat pocit, že aplikaci řídí on sám. Uživatel musí vidět předmět své práce na obrazovce a mít veškeré informace o činnosti programu. Výhody tohoto principu jsou, že uživatelé si mohou mnohem rychleji osvojit funkce dané aplikace, změna objektů je okamžitě viditelná a díky srozumitelnosti a bezpečnosti akcí se uživatelé méně bojí neúspěchu a vkládají do aplikace větší důvěru.Má ovšem i své stinné stránky, z nichž lze jmenovat například jistý pokles efektivity při určitých úlohách, což je však možné vhodnými úpravami vyřešit;
- metafory
-
princip metafor zprostředkovává komunikaci uživatele s aplikací a těží z osobních znalostí uživatelů. Předpokladem je, že uživatel už má nějaké znalosti z jiných17 aplikací a očekává podobné chování i od nové aplikace. Aplikace by měla maximum funkcí a prvků znázorňovat pomocí různých symbolů, které odpovídají realitě (př. ikona
„Domů“ znázorněná obrázkem domečku atd.);
- kontrola aplikace uživatelem - prostřednictvím tohoto principu má uživatel získat dojem, že má naprostou kontrolu nad aplikací;
- zpětná vazba a komunikace - do tohoto principu nespadají pouze chybové hlášky, ale také informování uživatele o stavu aplikace, o úspěšnosti zadané akce, o možnostech dalších akcí, případně o důvodu neúspěšného provedení příkazu. K tomu je nejlepší v průběhu akce zobrazovat animaci a při dokončení akce ukázat výsledný stav;
- shovívavost - aplikace by měla uživatele povzbuzovat k širšímu prozkoumání a učení se z vlastních chyb tím, že mu nabídne možnost vrátit se o několik kroků zpět. Díky tomu se nebude bát, že přijde o data. Dále by aplikace také měla uživatele informovat, že daným krokem může nevratně o data přijít;
- vnímaná stabilita - dle principu by všechna okna aplikace měla vypadat podobně, menu nebo posuvné lišty a podobné prvky by se měly zobrazovat na stejných místech a tlačítka podobného vzhledu by měla mít podobné funkce;
- estetická ucelenost - informace v aplikaci by měly být dobře strukturované a mít celkově slušný grafický design tak, aby aplikace byla vizuálně příjemná. Složitá grafika většinou způsobuje jen horší funkčnost a vyšší chybovost, tudíž by na lištách nemělo být příliš mnoho tlačítek a symboly by měly být jasně srozumitelné, aby nedocházelo k záměnám.
Je dobré držet se starého hesla „V jednoduchosti je krása“;
- možnost výběru při ovládání - uživatel by měl mít co nejširší možnost podílet se na ovládání aplikace, proto je například nevhodné použití modelu zamykání, kdy uživatel má přístup jen k části aplikace a ostatní části nemůže využívat. Doporučuje se nabídnout možnosti dodatečného ovládání nebo volby;
- komplexnost a jednoduchost - při vývoji aplikace je nejlepší cestou snaha o navržení co nejjednoduššího software jako například umožnit uživateli zredukovat složitost uživatelského rozhraní pomocí možnosti přizpůsobení aplikace vlastním potřebám nebo výběru jen těch funkcí, které uživatel pro svou práci opravdu potřebuje. Měla by být zachována maximální možná funkčnost při zachování přehlednosti a snadná údržba;
- explicitní a implicitní akce – zatímco explicitní akce zobrazují ihned možnosti daného
18 objektu a není nutné, aby uživatel znal příkazy vykonavatelné na tomto objektu, u implicitních akcí je výsledek zřejmý až při nebo po akci, tudíž si uživatel musí uvědomovat, co danou akcí může způsobit;
- mentální modely a znalosti – uživatelé mají vlastní znalosti, zkušenosti nebo návyky, které nelze ignorovat, proto je potřeba tyto mentální modely znát a využívat je pomocí již zmíněných metafor, navíc je potřeba zohlednit úroveň znalostí uživatelů a v případě obtížnějších úkonů jim umožnit jinou variantu jejich provedení. [5, 6]
3.2 Prvky uživatelského rozhraní
Prvky uživatelského rozhraní přímo ovlivňují jeho vzhled a působení na uživatele.
Mezi ty nejdůležitější z nich lze jmenovat systém oken, což je ta oblast obrazovky, kde jsou zobrazovány objekty a dochází k interakci s uživatelem. Prostřednictvím oken má uživatel dohled nad aplikací, přičemž si může libovolně přizpůsobovat jejich polohu nebo velikost.
Dalším prvkem je například menu, kde si uživatel může vybírat z různých operací nebo objektů. Díky menu si uživatelé nemusejí pamatovat konkrétní příkazy k provedení určité operace, poskytuje jim přehlednou možnost výběru a osvojení nových nebo polozapomenutých znalostí. Rozlišují se dva typy menu, a to široké s několika hlavními položkami, nebo hluboké s mnoha vnořenými podbody. Počet položek by měl zachovat rozumnou míru, aby nedošlo ke zhoršení přehlednosti a dezorientaci uživatele.
Dále sem lze zařadit navigační systém, který by měl uživatele srozumitelně provádět aplikací. Uživatel by z navigace měl snadno pochopit, jak se dostane na následující krok, jak se vrátit zpět, kam jinam se ještě může dostat a také kde vůbec je momentálně. U navigace se rozlišuje několik typů – lokální, paralelní a globální.
Významným prvkem uživatelského rozhraní je také nápověda. Bez té by uživateli trvalo pravděpodobně dosti dlouho než by se v aplikaci vyznal dostatečně dobře a rychle.
Proto dostává možnost nápovědy, která má sloužit jako varianta školení nebo manuál pro pochopení veškerých potřebných funkcí, které jsou v aplikaci k dispozici.
Důležité jsou pro uživatele rovněž ikony. Symbolicky mu znázorňují objekty nebo funkce v aplikaci. Význam použitých symbolů by měl být jednoznačný, lehce odhalitelný a zapamatovatelný a ideálně by měl odpovídat znalostem z reality. Ty ikony, které spolu souvisí, by měly mít podobný tvar, barvu nebo velikost, ale zároveň musejí zůstat
19 rozlišitelné.
Zajímavým prvkem je typografie, na níž závisí dobrá čitelnost textu a tím ovlivňuje přívětivost pro uživatele. Záleží například na použitém druhu písma, jako jsou patková nebo bezpatková písma, ale také na množství použitých druhů, odlišení textů stejného druhu barvou a velikostí písma nebo kontrastu barev. [7]
3.3 Hodnotící kritéria z hlediska norem
Existují různé normy a směrnice, které upravují a určují zásady vývoje uživatelského rozhraní. Není třeba rozebírat jednotlivě každou z nich, pro potřebu této práce postačí věnovat se několika základním zásadám pro vytváření dialogových služeb aplikací.
Jako první je to přiměřenost, k čemuž se normy vyjadřují následovně. Aplikace je přiměřená, pokud umožňuje uživateli provádět pracovní úlohy účinně a efektivně.
Podstatou tohoto kritéria je nezatěžování uživatele technickou stránkou systému. Pod přiměřenost by se dala zahrnout i všechna následující popsaná kritéria, protože právě přiměřenost aplikace je naprostým základem.
Z dalších kritérií lze uvést například ovladatelnost aplikace, což znamená, že uživatel je schopný aplikaci spustit a ovlivňovat její směřování a rychlost za účelem dosažení svého cíle. Dále by aplikace měla odpovídat očekávání uživatelů splněním jejich požadavků. Zároveň by měla být samopopisná a mít jistou toleranci chyb, tedy měla by uživateli vysvětlit postup při různých akcích a každá uživatelova akce by měla vyvolat jasnou zpětnou vazbu, ale rovněž by měla ihned při chybné akci upozornit pomocí srozumitelných chybových hlášek. Uživatelé by také měli mít možnost si aplikaci přizpůsobit do rozumné míry dle vlastních potřeb. [8]
3.4 Hodnotící kritéria z hlediska uživatele
Obecně se dá říci, že pro uživatele je nejdůležitější vzhled aplikace. Celkový design musí být líbivý a dobře použitelný, stejně tak se ale očekává vizuální konzistence a účelnost. Žádná důležitá tlačítka by neměla chybět, ale žádná zbytečná by také neměla přebývat, aby měl uživatel vždy po ruce to, co opravdu potřebuje a nemusel se rozptylovat nadbytečnými věcmi.
Lze však určit několik konkrétních kritérií, které jsou z hlediska uživatele aplikace
20 opravdu důležitá. Jsou to například tato následující:
- první dojem – je v podstatě nejdůležitější, neboť již během prvních několika málo okamžiků má uživatel jasno v tom, zda se mu daná aplikace líbí anebo je mu naopak nepříjemná;
- atraktivita – přítomnost určitých grafických prvků, které odlišují aplikaci od ostatních a činí ji něčím výjimečnou;
- zpracování – schopnost splnit očekávání uživatelů, způsob rozvržení aplikace, jejího celkového stylu a vzhledu;
- ucelená grafika – shodná barevná zvýraznění, rozvržení textu, grafické znázornění prvků v rámci celé aplikace;
- navigace – jednoduché a srozumitelné vedení celou aplikací, intuitivní orientace v systému;
- nabídka dalších nástrojů – možnost využít pomocné nástroje, které uživateli ještě o něco více usnadní práci s aplikací, jako je například kontrola pravopisu;
- účelnost – ve vztahu ke grafickým prvkům v aplikaci možné chápat jako jasné rozdělení tlačítek, zvýraznění důležitých prvků oproti méně významným nebo celkově srozumitelná grafika;
- nezávislost – sem spadá kupříkladu kompatibilita s prohlížeči, nebo zda je aplikace schopna provozu bez doplňujících pluginů atd. [9]
4 Moderní trendy v tvorbě uživatelského rozhraní
V současné době se při vývoji uživatelského rozhraní nejčastěji používají dvě metody. První z nich je responsivní webdesign, druhou potom představují bohaté webové aplikace [10]. V následujících podkapitolách budou oba způsoby podrobně popsány, bude vysvětlen jejich vývoj a zmíněny také výhody a nevýhody obou metod.
4.1 Responsivní webdesign
Responsivní webdesign (RWD) je přístup k tvorbě webových stránek a aplikací, který není vázán na existující druhy zařízení a není jimi ani omezován. Stránky vytvořené touto metodou jsou přizpůsobené pro různé druhy mobilních zařízení, jako jsou mobily nebo tablety. Pojem responzivní webdesign se poprvé objevil v roce 2010.
21 RWD vznikl jako jedno z řešení problémů se zobrazováním webových stránek na mobilních zařízeních. Původně byly stránky optimalizované pouze pro desktopy s rozlišením od 1024px na šířku, ovšem v souvislosti s technologickým rozvojem mobilních zařízení se začal zvyšovat počet uživatelů, kteří se přihlašovali právě prostřednictvím svých mobilů nebo tabletů, pro jejichž malé displeje neměly stránky optimalizace a zobrazovaly se tudíž nekompletně. Dříve byl tento problém řešen samostatnými verzemi webů speciálně pro mobily, což však znamenalo nutnost provozovat několik stránek s odlišnými kódy a vzhledy, přičemž sebemenší aktualizace se musela provádět pro každou verzi zvlášť, nebo byly tyto speciální verze umisťovány na subdoménu nebo jako složka, což bylo pro mobily datově méně náročné. Přesto se stále objevovaly potíže, kromě obtížnější údržby docházelo k duplicitě obsahu nebo přesměrování z mobilní verze na desktopovou verzi.
Poté se ale objevil moderní přístup responsivního webdesignu, díky kterému lze místo tvorby designu pro každý jeden typ zařízení zvlášť využít technologie, které umožní vytvořit adaptabilnější design pro dané zařízení. Jinak řečeno, RWD umožňuje danému zařízení přizpůsobit zobrazení prvků a celé webové stránky. Již není třeba tvořit různé verze pro různé typy, postačuje jedna jediná verze, která se dokáže přizpůsobovat podle potřeby. To zjednodušilo práci nejen uživatelům, ale i samotným vývojářům, kteří nyní mají zdrojové kódy sjednocené na jednom místě a jejich údržba je díky tomu mnohem snazší.
RWD má jako vše také svoje nevýhody. Mezi ně patří zejména náročnost a vyšší náklady na vývoj a testování. Jistou nevýhodu může představovat také rozdílné rozložení prvků na různě velkých zařízeních, což pro některé uživatele může působit trochu nezvykle a chvíli jim potrvá, než si na odlišnosti zvyknou. Na druhou stranu tyto drobnosti vynahradí výhody RWD, které převažují. Využitím tohoto přístupu lze dosáhnout příjemnějšího vzhledu a větší uživatelské přívětivosti, možnosti webu pracovat s obrázky díky javascriptu a tím pádem i dosažení optimalizace datové velikosti stahované stránky a v neposlední řadě již ona zmiňovaná snazší údržba zdrojových kódů.
Ačkoli je RWD v současnosti jedním z nejčastěji používaných způsobů tvorby webových stránek a aplikací, stále ještě uživatelé naráží na stránky, které tímto způsobem řešené nejsou. Obvykle se jedná o stránky, které jsou komplikovanější, případně na svůj redesign teprve čekají. V mnoha případech se do přestavby vývojářům nechce proto, že je RWD dražší a omezuje je v používání některých prvků, jako jsou kupříkladu
22 javascriptové animace. V České republice jsou responsivní weby méně obvyklé nejen z důvodů vyšších nákladů, ale také kvůli neodbornosti vývojářů, neznalosti klientů a pravděpodobně celkové ignorace tohoto trendu. Pokud už je responsivní web v českém prostředí využíván, má zpravidla několik typických chyb. Obvykle neřeší rychlost načítání, přizpůsobují se jen konkrétním rozlišením, nejsou dostatečně otestované, používají desktopové komponenty uživatelského rozhraní, uživatelům tabletů často vnucují rozhraní pro chytré telefony anebo při vývoji mobilní verze jaksi nebylo dost času pro zásah grafika. [11]
V případě RWD lze rozlišit dva přístupy k jeho tvorbě, a to klasický desktop first nebo mobile first. Oba přístupy budou následně teoreticky popsány a porovnány.
Podrobným technologickým postupům se bude věnovat další část práce. [12]
4.1.1 Desktop first
Tento přístup je orientován nejdříve na desktop a teprve poté řeší jiná zařízení, z toho plyne jeho název. Začíná jako rozšíření běžné tvorby webu pro desktopové prohlížeče, ovšem přidává další vrstvu pro potřeby mobilních zařízení. Neklade tak velký důraz na jiná zařízení jako druhý přístup. Dá se říci, že je to v podstatě jen snaha o poskládání desktopového obsahu na mobily a tablety.
Výhodou tohoto přístupu je možnost využít jej i pro takové stránky, u nichž se vůbec nepočítá s responsivní variantou. Nezabývá se tolika problémy a je výrazně levnější.
4.1.2 Mobile first
U mobilních zařízení je nutné zohledňovat velikost obrazovky, rychlost připojení, místo a čas. Mají mnohem menší rozlišení, tudíž je potřeba zahrnout do obsahu jen to nejdůležitější a neplýtvat prostorem na zbytečné reklamy nebo nevýznamné obrázky.
Navíc často využívají omezené připojení, proto musí web být co nejméně náročný na objem dat, aby se načetl dostatečně rychle. Vzhledem k používání mobilních zařízení na nejrůznějších místech se ustálil pojem „jeden palec, jedno oko“, neboť uživatelé často ovládají mobil palcem jedné ruky a část své pozornosti věnují svému okolí. Proto by měl být design navržen tak, aby vyhovoval dosahu palce. Na mobilním telefonu můžeme identifikovat minimálně tři zóny, jak je vidět na obrázku č. 2. Tmavě zelené pole znázorňuje zónu velice dobrého dosahu, světle zelené značí přijatelný dosah a žlutá je
23 zóna obtížnějšího dosahu. Navíc ještě záleží na velikosti obrazovky, velikosti ruky a pravo či levorukosti uživatele. To vše by mělo být při návrhu stránky bráno v potaz.
Tento přístup je modernější oproti klasickému desktop first přístupu, ale je také náročnější na vývoj. Představuje jednodušší řešení nejen pro mobilní zařízení, ale také pro zařízení s větší obrazovkou. [13]
Obrázek 2 Zóna dosahu palce na mobilním telefonu s uhlopříčkou 4,3'' [14]
4.2 Bohaté webové aplikace
Bohaté webové aplikace, jinak řečené Rich Internet Applications (RIA), jsou webové aplikace, které mají vlastnosti a funkcionalitu tradičních desktopových aplikací.
Tradiční webové aplikace využívají architekturu klient-server s tenkým klientem, z čehož plyne jejich nevýhoda, a sice taková, že veškerá interakce s aplikací musí projít přes server. To zahrnuje zaslání žádosti klienta serveru, odpověď serveru a odeslání dat k zobrazení. Pokud jsou využity technologie, které umožní vykonání instrukcí na straně klienta, mohou bohaté webové aplikace obejít tyto pomalé obsáhlé uživatelské interakce.
V RIA se přenese nezbytné zpracovávání uživatelského rozhraní do webového klienta, zatímco převážný objem dat je zachován na straně serveru.
Pro RIA je typické, že nepotřebují ani nevyžadují žádnou instalaci software, běží na webovém prohlížeči a mezi uživatelem a serverem leží client engine. Při prvotním
24 spuštění aplikace se ze serveru stáhne nebo se za chodu aplikace aktualizuje právě tento client engine, který vystupuje jako rozšíření prohlížeče. Přebírá kontrolu a odpovědnost nad vykreslováním uživatelského rozhraní a komunikací se serverem. Většina RIA doplňuje komunikaci klient-server o asynchronní komunikaci se serverem, což znamená, že client engine rozděluje komunikaci mezi uživatelem a serverem na dvě oddělené samostatné části. V popředí je komunikace uživatel-client engine, v pozadí client engine- server. Obě tyto části jsou nezbytné a navzájem bez sebe nemohou existovat. Jejich vzájemný vztah určuje chování aplikace. Díky client engine mohou být aplikace bohatší, nabízejí uživatelskému rozhraní možnosti, které za použití HTML technik nejsou dostupné, jako například technika Drag&Drop, kalkulačky na straně klienta atd. Ty nejlepší RIA dnes mají uživatelské rozhraní téměř nerozeznatelné od desktopových, a díky omezení komunikace se serverem pouze na nejnutnější případy mnohem lépe reagují a jsou pohotovější.
K dalším výhodám RIA patří možnost spustit je z jakéhokoli počítače s jakýmkoli prohlížečem, automatické aktualizace aplikace, jejich menší náchylnost na viry a podobné škodlivé kódy ve srovnání s desktopovými aplikacemi, navíc jsou provozovány lokálně v bezpečném prostředí (tzv. sandbox) a client engine si předehrává některá data do cache paměti, takže webová aplikace běží lépe. Dále mají zdroje lepší rovnováhu v porovnání s běžnými klient-server aplikacím, protože server není tolik vytěžován, díky čemuž je možné provádět více paralelních relací klientů. Stejně tak se projevuje lepší efektivita využití sítě, protože není třeba posílat takový objem dat serveru a ze serveru zpět ke klientovi.
Samozřejmě, že RIA mají i nevýhody, z nichž jmenujme například fakt, že jsou vzhledem ke své komplexnosti těžší na navržení, testování a správu. Dále jejich asynchronní komunikace ztěžuje izolaci výkonnostních problémů, a také jistým způsobem popírají paradigma webových stránek, neboť v RIA se stránky načítají nezávisle na vůli uživatele, nikoli na jeho vyžádání.
4.2.1 Vývoj bohatých webových aplikací
Bohaté webové aplikace prošly během doby dlouhým vývojem. První snahu o dynamičtější web představují skripty CGI (Common Gateway Interface), které jsou nezávislé na programovacím jazyku. Jedinými podmínkami je, aby daný jazyk uměl generovat výstup a bylo jej možné spustit na dané platformě. Tyto skripty propojují
25 aplikaci s webovým serverem, takže uživatel zašle požadavek serveru, který jej zpracuje a navrátí výstup klientovi.
Později se přešlo k používání appletů, což jsou malé softwarové komponenty běžící v kontextu jiného programu, pouze na klientské části. Spouštějí se v kontejneru dodaném webovým prohlížečem a používají část jeho uživatelského rozhraní. Samy o sobě nemají přístup do souborového systému, ani nemohou spouštět další programy, jejich přístupová práva jsou značně omezená.
Naopak servlety běží přímo na serveru, což znamená, že servlety nemají omezení oproti appletům. Uživateli díky nim zmizely starosti se správně nainstalovanými pluginy, neboť autor aplikace si toto vše zajišťuje sám. Servlet zpracuje data odeslaná klientem a vygeneruje výsledný obsah v HTML nebo XML. Jejich problémem ovšem bylo vytváření, kde nedošlo k oddělení prezentace a logiky.
Tato potíž zmizela s nástupem ASP (Active Server Pages) a JSP (Java Server Pages). ASP je skriptovací přístup Microsoftu na straně serveru, o něco později přišly JSP s některými vylepšeními. Jsou to v podstatě abstrakce servletů, u kterých už je oddělen vzhled od logiky webové aplikace.
Svůj význam ve vývoji bohatých webových aplikací má rovněž skriptovací jazyk PHP, jehož kód je spouštěn na straně serveru. Na jeho základě je postaveno mnoho frameworků a jeho další výhodou je, že nezávislý na platformách a je rozšířený po celém světě. Kvůli tomu je ovšem také častým cílem hackerů.
Přelomem ve vývoji webových aplikací bylo použití Flashe, původně určeného pro tvorbu animací nebo reklamních bannerů. Později se však jeho využití rozšířilo a to hlavně po zavedení skriptovacího jazyka ActionScript. Má svoje nevýhody, hlavní je nutnost nainstalovaného pluginu v prohlížeči, což na druhou stranu znamená, že lze spustit ve všech prohlížečích bez toho, aby musel být optimalizován. RIA ve Flashi je také náročnější na výkon procesoru. Mnoha lidem se nelíbí jeho sílící pozice a snaha expandovat dál, ani jeho relativní uzavřenost. Jeho hlavní výhoda, což byla malá velikost díky vektorové grafice, postupem času zmizela, ovšem díky jeho neustálému vývoji dokáže zajistit interaktivitu, velkou robustnost a umožňuje psát komplexní a velice složité bohaté webové aplikace nerozeznatelné od desktopových variant.
Dalším krokem byla technika AJAX (Asynchronous Javascript And XML), která využívá kombinaci XHTML a CSS pro značkování a stylování informací, dále přístup
26 DOM se skriptovacím jazykem pro dynamické zobrazování a práci se zobrazovanou informací na straně klienta, objekt XHTLHttpRequest pro zisk dat ze serveru pomocí asynchronní komunikace na pozadí a XML potom jako obvyklý formát výměny dat klienta a serveru. To znamená, že se naprosto oddělila data, formát, styly a funkce.
V důsledku toho se ovšem pozměnilo chování prohlížeče a některé funkce nejsou dostupné nebo je nelze použít. Na druhou stranu aplikace využívající AJAX nejsou nijak závislé na technologiích serveru. [15]
5 Technologické možnosti uživatelského rozhraní
Uživatelské rozhraní u moderních webových aplikací je realizováno spojením technologií HTML, CSS a javascript. Základní kostra webové aplikace je vytvořena značkovacím jazykem HTML, stylování a vzhled jednotlivých stránek je definován pomocí kaskádových stylů CSS. Kaskádové styly můžeme chápat jako sadu pravidel, která definují, jak budou jednotlivé elementy na stránce vypadat. Tyto styly nejčastěji určují velikost, barvu, okraje a pozici prvku, barvu, styl, zarovnání a velikost písma a mnoho dalších vlastností.
Obsah konkrétní stránky aplikace vytvořené značkovacím jazykem HTML a kaskádovými styly je statický. To znamená, že pro jakoukoliv změnu obsahu, nebo vykonání akce od uživatele je vyžadováno kontaktování serveru, který zpracuje požadavek, vrátí odpověď a celá stránka je znovu vykreslena.
Skriptovací jazyk javascript přináší možnost pracovat s vykresleným dokumentem na úrovni prohlížeče. Tento jazyk umí přistupovat k Document Object Modelu (DOM) což je aplikační programové rozhraní samotné webové stránky. DOM umožňuje přistupovat k jednotlivým objektům (elementy, atributy, text, …) HTML dokumentu a provádět s nimi různé operace. Tímto je přesunuta část logiky ze strany serveru na klienta. Jednoduché operace, u kterých nejsou potřeba data ze serveru, jako například abecední třídění, filtrování nebo jakákoliv práce s DOM mohou být prováděny lokálně bez nutnosti kontaktování serveru. [16]
5.1 HTML 5
Nový standart HTML přináší nové vlastnosti, tagy, sémantiku, formulářové prvky, podporu multimediálních technologií bez nutnosti dalších ovládacích modulů a i offline webové aplikace. Úzce přitom spolupracuje s skriptovacím jazykem javascript, který je
27 u webových aplikací značně rozšířen. Všechny nové prvky jsou zpětně zcela kompatibilní, a pokud nejsou prohlížečem podporovány, chovají se jako řádkové elementy. V následujících kapitolách budou představeny některé nové vlastnosti HTML 5.
5.1.1 Struktura dokumentu
Oproti předchozím verzím jazyku HTML, kde tagy neměly žádný sémantický význam a strukturování dokumentu bylo převážně pomocí vnořování bloků tvořených tagy <div> a <span> Novinkou v HTML 5 je sada nových párových tagů se specifickým sémantickým významem viz tabulka 1 [17]. Tyto tagy prezentují logickou stavbu dokumentu a také zkvalitňují výsledky fulltextového vyhledávání nad daným dokumentem.
Tabulka 1 Seznam tagů pro strukturu dokumentu Název tagu Popis
<section> Jako sekce je označována tematicky sdružená část stránky, typicky s nadpisem.
<article> Tímto tagem je označována část dokumentu, která dává smysl sama o sobě bez závislosti na zbytku obsahu. Například příspěvek na fóru či blogu.
<header> Představuje záhlaví dokumentu nebo sekce. Může obsahovat úvodní text, logo, navigaci, vyhledávání, atd.
<footer> Představuje zápatí dokumentu, nebo sekce, typicky obsahuje informace o autorovi, podmínky použití, kontakty, atd.
<nav> Tímto tagem je obalena navigační část dokumentu, ve které se nacházejí odkazy na další části aplikace.
<aside> Tento tag obsahuje částí stránky s dodatečnými informacemi k okolnímu obsahu.
<figure> Účelem tohoto tagu je sdružit obrázek s jeho popiskem.
Obsahuje tag obrázku <img> a jeho popisku <figcaption>.
5.1.2 Nové formulářové prvky
Formuláře jsou u webových aplikací hlavním prostředkem, kterým uživatel předává data aplikaci. U předchozích verzí jazyka HTML byly formulářové prvky značně
28 omezené funkčností, a rozšíření bylo možné pouze pomocí rozšiřujících knihoven.
Jazyk HTML 5 přináší novou sadu formulářových prvků uvedených v tabulce 2 [18], které obsahují širší funkčnost a pohodlnější ovládání aplikace. U těchto prvků je implementována i základní validace, jako maximální délka vstupu, minimální a maximální hodnota čísla, označení povinného pole a vzor pro zadávání např. emailové adresy, je umožněna přímo na úrovni jazyka bez potřeby externích knihoven.
Tabulka 2 Nové typy formulářových prvků Typ vstupu Popis
url Zadávání URL adresy, která musí mít validní schéma.
tel Zadávání telefonního čísla.
email Zadávání emailu.
search Pole pro vyhledávání, je stylováno podle platformy.
number Zadávání číselných hodnot.
color Výběr barvy.
range Zadávání číselné hodnoty posuvníkem.
datetime Zadávání data a času, časová zóna je GMT.
datetime-local Zadávání data a času, časová zóna je brána z lokálního nastavení.
date Zadávání pouze data, časová zóna není k dispozici.
time Zadávání pouze času, časová zóna není k dispozici.
week Zadávání čísla týdne a roku.
month Zadávání měsíce a roku.
5.1.3 Local Storage
Dalším velkým přínosem HTML 5 je podpora úložiště dat na úrovní klienta, takzvané Local Storage, Web Storage nebo HTML 5 Storage. Předchozí verze jazyku HTML používaly pro ukládání dat malé soubory zvané cookies, které se přenášeli ze serveru při každé odpovědi. Oproti nim je Local Storage záležitostí čistě na úrovni klienta a nabízí větší limit pro uložení dat.
Úložiště je založeno na principu klíč/hodnota, což znamená, že se data uloží pod libolným názvem, který slouž jako klíč k pozdějšímu přístupu k těmto datům. Local Storage zprostředkovává dva objekty pro ukládání dat u klienta, ke kterým se přistupuje
29 pomocí jazyku javascript. První objekt, dostupný pod window.localStorage, se chová obdobně jako cookies a data zůstanou v prohlížeči i po zavření konkrétní stránky, nebo celého prohlížeče. Druhý objekt, přístupný pod window.sessionStorage, ukládá data pouze po dobu session a při zavření stránky nebo prohlížeče jsou data smazána. Uložená data jsou vázána na doménu a je možné k nim přistupovat ze všech stránek dané domény [19].
5.1.4 Další funkčnost
Další rozšíření v HTML 5 je možnost vkládání multimediálních audio a video prvků. V předchozích verzích jazyka HTML bylo pro použití multimediálních prvků nutné použít externí knihovny jako například Adobe Flash. Použití těchto prvků je obdobně jako u obrázku, vložením tagu audio nebo video a definováním zdroje, nebo více zdrojů v různých formátech [20].
HTML 5 také přináší podporu geolokace, kde je možné získat pozici zařízení z GPS modulu. Aby nedošlo narušení soukromí uživatele, není pozice dostupná a je třeba ji povolit.
5.2 CSS 3
Nová verze kaskádových stylů označovaná jako CSS 3 je rozšířena o velké množství možností pro uživatelsky atraktivní prostředí. Předchozí verze kaskádových stylů dovolovaly upravovat elementy pouze pomocí jednoduchých selektorů. V nové specifikaci jsou selektory komplexnější a jsou schopné vybírat elementy například podle umístění v dokumentu, nebo hodnoty některého atributu.
CSS 3 dále přináší možnosti specifikovat obrázek jako rám ohraničení elementu, nebo specifikovat radius zaoblení rámečku. Dále přibyly prostorové transformace, které umožňují elementy otáčet, měnit jim měřítko nebo zkosit. Tyto transformace je možné provádět jak ve 2D tak ve 3D. Podporovány jsou také animace, zrcadlení, nastavení průhlednosti nebo vícenásobné pozadí což přináší více možností při návrhu designu uživatelského rozhraní.
5.3 Frameworky
Programování a vývoj pokročilejších webových aplikací může být často obtížné a časově náročné. Vypořádat se s těmito obtížemi pomáhají softwarové struktury zvané
30 frameworky. Často poskytují hotová řešení velmi běžných problému. Tím má programátor ulehčenou práci, že nemusí znovu vytvářet něco, co již bylo vytvořeno předním. Řešení, která jsou nabízena frameworkem, bývají bez chyb a otestovány množstvím uživatelů. Framework může obsahovat podpůrné programy, knihovny API, podporu pro návrhové vzory nebo doporučené postupy při vývoji.
V první části této kapitoly budou zmíněny dva CSS frameworky pro responzivní webové aplikace. Dále bude představen javascriptový framework jQuery, který nabízí jednoduší vytváření animací, obsluhu událostí, lepší manipulaci s DOM a AJAXem.
Na závěr budou představeny javascriptové frameworky, které stavějí na
„jednodušších“ svých obecnějších předchůdcích a nabízejí komplexnější řešení a vývoj založený na MVC architektuře. Tyto frameworky jsou vhodné k vytvářené Single-Page Application (SPA), což je typ webových aplikací, kde veškerá funkcionalita je umístěná na jedné stránce a data jsou dotahována skrze směrovače dle potřeby pomocí datového rozhraní serveru.
5.3.1 Twitter Bootstrap
Twitter Bootstrap je CSS framework, který byl vyvinut pro sjednocení a urychlení vývoje nástrojů společnosti Twitter. Jeho první verze byla představena v roce 2011.
Zaměřuje se na vývoj responzivních webových aplikací.
Z hlediska rozvržení nepoužívá plně flexibilní mřížku, ale stojí mezi adaptivním a responzivním rozvržením. Mřížka se flexibilně mění pouze na zařízeních se zobrazovací plochy menším než 768 pixelů. Na zařízeních s větší velikostí zobrazovací plochy je mřížka měněna skokově. Dále nabízí množství předpřipravených komponent pro tvorbu webových aplikací. Například podporu vyskakovacích oken, progress bar pro průběh událostí, seznamy, podporu stránkování, jednotné formátování pro tlačítka a další ovládací prvky, podporu typografie a další. Framework nabízí i množství pluginů v jazyce javascript.
5.3.2 ZURB Foundation
Tento framework, jehož první verze byla uveřejněna v roce 2011 je vyvíjen společností ZURB. Jedná se o CSS framework, který se v první řadě se zaměřuje responzivní vývoj webových aplikací. Dále nabízí řadu vizuálních komponent pro uživatelské rozhraní jako například šablony, typografii, podporu pro formuláře, navigaci
31 a mnoho dalších komponent rozhraní. Stejně jako framework Twitter Bootstrap, zmíněný v předchozí kapitole, nabízí javascriptové pluginy.
Framework využívá fluidní mřížku, což znamená, že velikost elementů je udávána procentuálně namísto velikostně statických pixelů. Mřížka se skládá z 12 sloupců, které mohou být libovolně vnořovány nebo přidávány další.
5.3.3 jQuery
Nejvíce populární javascriptový Framework, který začal vznikat začátkem roku 2006. Tento framework je velice dobře zdokumentovaný a díky velké rozšířenosti mezi programátory existuje velké množství ukázek kódu a existujících pluginů. V roce 2014 více než 69% z 10,000 nejnavštěvovanějších stránek používalo jQuery.
Framework jQuery nabízí úpravy kaskádových stylů, změnu DOM elementů na stránce (přidávání, mazání i editace), podporu animací a efektů, reakce na systémové události nebo podporu při AJAXu. Je navržen tak, aby vývojářům co nejvíce usnadnil manipulaci s dokumentem a tvorbu nejrůznějších pluginů.
5.3.4 MVC Frameworky
Frameworky implementující architekturu MVC, nebo její různé obměny umožňují vývojáři webových aplikací stiktně oddělit aplikační logiku od uživatelského rozhraní. U webových aplikací a javascriptových frameworku představuje uživatelské rozhraní dokument vytvořený pomocí značkovacího jazyku HTML a aplikační logiku právě jazyk JavaScript.
Dále budou některé tyto frameworky představeny, které toho mají hodně společného. Všechny jsou to open source frameworky pod MIT licencí, používají MVC (MVP) architekturu, využívají koncept pohledů, událostí, směrování a datových modelů k vývoji SPA.
AngularJS
Jedná se o javascriptový framework, který implementuje architekturu MVC (Model - View - Controller) a je určený pro vývoj dynamických webových aplikací.
Představen byl v roce 2009 společností Google. Rozšiřuje HTML o řadu elementů a atributů, díky kterým usnadňuje vytváření dynamických a SPA webových aplikací.
Veškerý kód je vykonáván u klienta v prohlížeči. Využívá vzájemnou komunikaci
32 mezi View a Modelem takzvaný Two Way Data-Binding. Změní-li se data v modelu, promítnou se změny do šablony a naopak. O tuto výměnu dat se stará Controller pomocí úložného prostoru scope. Součástí frameworku jsou také samostatné moduly, což v praxi znamená, že pro tvorbu aplikace se využívá jádro frameworku a dle potřeby se přidávají rozšiřující moduly pro další funkčnost. Pro práci s DOM využívá spolupráci s knihovnou jQuery a v případě její nepřítomnosti ve webové aplikaci má vlastní podmnožinu jejich funkcí nazývanou jQLite. Využívá vlastní šablonovací systém založený na HTML a vkládání výkonných výrazů do složených závorek. [21]
Ember.js
Framework, obdobně jako AngularJS založený na MVC architektuře, byl vytvořený pro vývoj SPA webových aplikací. Jeho první verze byla představena v roce 2007 a skládá ze tří základních komponent a to modelů (Models), pohledů (Views) a kontrolerů (Controllers). Dále je obohacen o směrovače (Routes) pro tvorbu SPA aplikací a komponenty (Components).
Směrovače představují stav aplikace ve vazbě na konkrétní URL a poskytují konkrétní šablony pro uživatelské rozhraní. Ke každému směrovači se vztahuje právě jeden model, který obsahuje data k aktuálnímu stavu aplikace. Uživatelské rozhraní je zde realizováno pohledy, které využívají jednotlivé šablony popisující části uživatelského rozhraní, a přidávají do nich obsluhu událostí od uživatele. Komponenty jsou speciální druh pohledů, které umožňují tvorbu vlastních elementů.
Tento framework využívá šablonovací systém Mustache, rozšířený o nadstavbu Handlebars. Tato nadstavba se stará o převod systému Mustache na řetězec a DOM nerozumí, a nerozezná, jestli daný výraz je tag nebo atribut. O porozumění DOM se stará rozšíření zvané HTMLBars, které generuje a vkládá místo fragmenty DOM namísto řetězců. [22]
Backbone.js
Framework, jehož první verze byla vydána v roce 2010, je oproti svým dvěma představitelům založen na architektuře MVP. V této architektuře je kontroler nahrazen prezenterem a komunikace modelu s pohledem probíhá skrze něj. Původně se jednalo o malý jednoduchý framework, ale hodně rychle rostl na popularitě a díky tomu i na funkcionalitě.
33 Z hlediska funkcionality frameworku samotného, nabízí spíše podpůrné funkce než komplexnější řešení celé struktury aplikace. Mnoho této funkcionality však může být dosaženo pomocí různých pluginů. Toto řešení dává programátorovi volnou ruku při výběru z různých alternativ pluginů, dle toho jaký bude nejvíce vyhovovat potřebám aplikace. Podpora Two Way Data-Bindingu u tohoto frameworku chybí, a aktualizace pohledu je třeba řešit vlastním kódem.
Co se týče šablonovacího systému, tak na rozdíl od předchozích dvou uvedených frameworků, nechává Backbone.js volný výběr a může být integrovaný s velkým množstvím externích systémů. V základní verzi obsahuje systém Underscore, který je použitelný bez nutností externích pluginů. Tento systém ovšem obsahuje jen velmi základní funkcionalitu a je nutné ho kombinovat s javascriptem. [23]
6 Návrh změn aplikace
Cílem této části práce je navrhnout konkrétní možnosti implementace pro systém sledování projektů ve společnosti TRW s.r.o. Návrh se bude zaměřovat na vylepšení jak celkové funkcionality, tak uživatelského rozhraní již existující aplikace, za účelem zjednodušení ovládání a poskytnutí co nejlepší uživatelské přívětivosti.
6.1 Předchozí stav aplikace
Existující aplikace využívá klasické třívrstvé architektury, kdy na webovém serveru je aplikační logika, na databázovém serveru jsou uložena konkrétní data a uživatel se k ní připojuje pomocí webového prohlížeče. Aplikace je vytvořena jako víceuživatelská s různými druhy uživatelských oprávnění.
Poskytuje základní přehled všech projektů a úkolů k nim náležících, které se v rámci organizace vytvářejí nebo vytvářeli. Seznam poskytuje základní informace o těchto položkách jako například název, vedoucího, termíny začátku a konce, množství úkolů, které pod položku spadají a informaci o stavu splnění. Dále je možné tento seznam třídit dle jednotlivých informací a jsou zobrazitelné pomocí Ganttova diagramu pro lepší přehled o návaznostech a časové náročnosti.
Jednotlivé projekty a úkoly nabízejí i detailnější pohled, kde jsou uvedeny informace o dané položce a je možnost přidávat k nim komentáře, soubory a další podúkoly, které je třeba v rámci položky splnit. Samozřejmostí je možnost editace a mazání stávajících položek, které je dostupná přes menu detailu.
34 Na obrázku 3 je zobrazena struktura hlavního menu aplikace. Černé položky jsou dostupné všem uživatelům, zelené pouze pro uživatele označené jako Vedoucí a zelené pro uživatele s označením Administrátor. Můžeme na ni vidět, že aplikace je rozdělena na pět základních částí. První tři slouží k zobrazení projektů a úkolů. Stránka Domů zobrazuje projekty a úkoly přiřazené uživateli, další dvě zobrazují projekty nebo úkoly s možností základního filtru na všechny, hotové a rozpracované.
Obrázek 3 Struktura menu aplikace
V aplikaci jsou rozlišovány čtyři druhy uživatelů. Běžný uživatel, administrátor a vedoucí, jsou nastavovány administrátorem. Čtvrtý druh uživatele vznikne přiřazením uživatele k úkolu vedoucím projektu.
Na obrázku 4 je vidět use case diagram znázorňující možnosti všech uživatelů v aplikaci. Přihlášený uživatel má k dispozici přehled a detail projektů, úkolů i uživatelů a možnost přidávat soubory nebo komentáře k prvním dvěma. Uživatel přiřazený k úkolu má navíc možnost přidávat podúkoly, které má poté možnost spravovat. Vedoucí má možnost přidávat nové projekty, spravovat stávající a úkoly k nim náležící. Administrátor má oproti přihlášenému uživateli možnost přidávat nové a editovat stávající uživatele.
35 Obrázek 4 Use case diagram uživatelů v aplikaci
6.2 Zpětná vazba od uživatelů
Po představení aplikaci koncovým uživatelům a uplynutí nějaké doby, kdy byla aplikace používána, přišli uživatelé s připomínkami k funkcionalitě aplikace. Na základě těchto připomínek, byly navrženy některé změny, které budou zmíněny v této části práce.
Jeden z prvních požadavků bylo přidání rozšiřujících informací k jednotlivým položkám jak v seznamech, tak v detailech, změna lokalizace jazyka aplikace do angličtiny a změna designu, aby odpovídal webové stránce firmy TRW. Dále byl vznesen požadavek o změnu uživatelských rolí a oprávnění, aby více odpovídali používání aplikace v konkrétním prostředí. Nejvíce změn bylo provedeno v seznamech jednotlivých projektů i úkolů a jejich detailních zobrazení, které budou podrobněji popsány v dalších kapitolách
6.2.1 Změny v seznamech položek
Seznamy položek v předchozí verzi aplikace poskytovaly spíše jen základní přehledy o jednotlivých položkách, než možnosti s nimi pracovat. Na obrázku 5 můžeme vidět, že zde byla pouze možnost abecedně třídit jednotlivé položky dle kritérií a jejich mazání, a manipulace s položkami byla možná pouze přes jejich detail.
36 Obrázek 5 Seznam projektů a úkolů
Jelikož uživatel v rámci aplikace potřebuje nejen sledovat projekty a úkoly, ale také s nimi manipulovat, bylo navrženo přesunutí ovládacích prvků z detailu položky, do seznamu. Základní operace jako přidávání, editace a mazání položek bude přístupná ze seznamu a bude poskytnuta základní možnost filtrování dle jednotlivých sloupců. Tyto změny by měli uživateli zjednodušit jeho běžné úkony.
6.2.2 Detail položek
Původní detail položek, který můžeme vidět na obrázku 6. V horní části obsahuje menu, které umožňuje základní operace s projektem nebo úkolem. Pod ním se nacházejí detailnější informace o položce, dále je seznam podúkolů, které k položce náleží, dále je zde seznam nahraných souborů a v poslední části vložené komentáře.
Jelikož přidávání komentářů a souborů nebylo uživateli aplikace využíváno a bylo rozhodnuto o odstranění této funkcionalitu. Přesunutím ovládacích prvků na seznam položek se stalo menu v horní části nepotřebné a bylo možné ho odstranit. Tím byl detail položky ořezán a ponechána čistě jeho informační část.
37 Obrázek 6 Detail projektu
7 Přehled změn v aplikaci
Aby aplikace odpovídala co nejvíce uživatelským potřebám a bylo v předchozí kapitole popsáno množství požadovaných změn. Byla změněna samotná struktura aplikace, jak můžeme vidět na obrázku 7. Struktura aplikace byla zjednodušena na domovskou stránku, seznam projektů, seznam uživatelů a možnost odhlášení. Základní filtrování projektů a úkolů, které bylo v menu původně obsaženo, je nyní nahrazeno pokročilejším filtrováním nad samotnými tabulkami. Veškeré změny a nové části aplikace jsou popsány dále v této kapitole.
Obrázek 7 Menu aplikace
38
7.1 Uživatelská oprávnění
Na obrázku 8 vidíme use case diagram uživatelských oprávnění. Oproti původní verze aplikace jsou oprávnění značně zjednodušená. Nacházejí se zde tři typy uživatelů.
Běžný uživatel, který má plné možnosti pro správu projektů a úkolů, jejich přidávání, editaci a mazání bez nutnosti mít k ním nějakou vazbu. Dále je zde uživatel typu Leader, který má stejné možnosti jako běžný uživatel s rozšířením o možnost přidávat nebo editovat ostatní uživatele. Třetí a poslední typ je View only, který má přístup pouze k projektům a jejich podúkolům u kterých je přiřazen.
Obrázek 8 Uživatelská oprávnění
7.2 Změny v seznamech projektů a úkolů
Projekty a úkoly byly původně zobrazovány odděleně v tabulkách. Na domovské stránce byly zobrazeny projekty a úkoly, které má uživatel přiřazen. Dále zde byly dvě samostatné stránky, kde se zobrazovali buď projekty, nebo úkoly a v hlavním menu bylo možné zobrazit je se základními filtry dle stavu plnění.
39 Na obrázku č. 9 vidíme nový způsob zobrazení projektů a úkolů. Oproti předchozí verzi přibyly nové sloupce v tabulce obsahující doplňující informace. Dále přibylo stránkování zobrazených dat s možností nastavení limitu zobrazených položek na stránce.
V pravé horní části se nachází políčko pro vyhledávání nad všemi sloupci tabulky, které reaguje v reálném čase. Což znamená, že se data filtrují již od zadání prvního znaku a obnovuje se s každým dalším znakem.
Hlavička tabulky obsahuje tři řádky. První slouží k abecednímu třídění zobrazených dat. Další dva řádky obsahují v prvním sloupci ikonky plus a minus, které slouží k zobrazení nebo skrytí všech podúkolů. V dalších sloupcích jsou prvky typu selectbox, které umožňují filtrování dat v tabulce. Nastavením filtru je možné vybrat data, která budou v tabulce zobrazena a je oddělené filtrování projektů a úkolů.
Nyní jsou ve všech seznamech uspořádány ve struktuře rodič a potomek. Pokud má položka nějaké podúkoly, můžeme u ní v prvním sloupci vidět ikonku plus nebo minus. Tato ikonka slouží k zobrazení tabulky, která bude obsahovat úkoly patřící k dané položce. Takto zobrazená tabulka má stejné možnosti jako hlavní tabulka. Tudíž je možnost abecedně třídit jednotlivé sloupce, provádět textové vyhledávání přes vstupní pole a je dostupné i stránkování s nastavením počtu zobrazených položek.
Obrázek 9 Seznam projektů a úkolů
Filtrování, abecední třídění i zobrazení nebo skrytí jednotlivých položek se ukládá do paměti prohlížeče a při znovunačtení stránky je obnoveno do podoby kdy uživatel seznam
