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 2017
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 2017
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 Struktura zobrazení dat ... 36
6.2.2 Přidávání a editace položek ... 36
6.2.3 Vyhledávání dat v aplikaci ... 37
6.2.4 Ovládací prvky ... 38
9
6.3 Hodnocení návrhů ze strany uživatelů ... 39
6.3.1 Struktura zobrazených dat ... 39
6.3.2 Vyhledávání dat v aplikaci ... 40
6.3.3 Přidávání a editace položek ... 41
6.3.4 Ovládací prvky ... 42
6.4.1 Změny v seznamech položek ... 42
6.4.2 Detail položek ... 43
7 Přehled změn v aplikaci ... 44
7.1 Uživatelská oprávnění ... 45
7.2 Změny v seznamech projektů a úkolů ... 45
7.3 Manipulace s položkami ... 47
7.3 Domovská stránka ... 50
7.4 Ganttův diagram ... 50
7.5 Fulltextové vyhledávání ... 51
7.6 Informační zprávy ... 52
7.7 Detail projektu a úkolu ... 53
7.8 Shrnutí změn ... 54
8 Použité technologie ... 55
8.1 DataTables... 55
8.2 YADCF – Yet Another DataTable Column Filter ... 57
8.3 Localstorage ... 58
8.4 AJAX ... 59
8.5 Twitter Bootstrap ... 60
9 Doporučení při tvorbě obdobných aplikací ... 61
10 Závěr ... 62
Seznam literatury ... 63
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ů ... 43
Obrázek 6 Detail projektu ... 44
Obrázek 7 Menu aplikace ... 44
Obrázek 8 Uživatelská oprávnění ... 45
Obrázek 10 Seznam projektů a úkolů ... 46
Obrázek 11 Menu položky ... 47
Obrázek 12 Formulář editace projektu ... 48
Obrázek 13 Javascriptový kalendář ... 49
Obrázek 14 Domovská stránka ... 50
Obrázek 15 Ganttův diagram ... 51
Obrázek 16 Fulltextové vyhledávání ... 52
Obrázek 17 Ukázka zpráv ... 53
Obrázek 18 Detail projektu ... 53
Obrázek 19 Implementace pluginu DataTables ... 56
Obrázek 20 Implementace tabulky potomka ... 57
Obrázek 21 Konstruktor filtru YADCF ... 58
Obrázek 22 Odeslání formuláře pomocí technologie AJAX ... 59
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, jméno 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 data 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žné 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 projektům a úkolům. 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í aplikace 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 změny zmíněné dále. Tyto změny byly implementovány v testovacích verzí aplikace a znovu předloženy uživatelům pro další zpětnou vazbu, na jejímž základě budou změny implementovány do finální verze aplikace.
Požadavky na změny založené na první zpětné vazbě od uživatelů byly:
- přidání doplňujících informací k jednotlivým položkám,
- přesunout více informací z detailu položky do seznamu všech položek, - více se zaměřit na hierarchickou reprezentaci dat,
- možnost úpravy zobrazených dat v seznamech, - zjednodušit proces přidávání a editace položek, - úprava designu aplikace, aby odpovídal vzoru TRW, - zjednodušení uživatelských oprávnění,
- přidávání komentářů a souborů bylo označené za nepotřebné.
36 Některé změny jako přidání doplňujících informací, lokalizace, atp. byly jednoznačné a nebylo třeba u nich vytvářet různé návrhy. U ostatních požadavků bylo uživatelům předvedeno několik různých variant, které měli otestovat a následně vyhodnotit jejich přínos pro implementaci ve finální verzi aplikace. Tyto varianty jsou popsány v následujících kapitolách.
6.2.1 Struktura zobrazení dat
V původní verzi aplikace byla data zobrazena v jednoduché struktuře dvou tabulek. První tabulka obsahovala seznam projektů a druhá seznam úkolů (bylo možné zobrazit obě tabulky odděleně). Uživatelé projevili zájem o zobrazení dat v hierarchické struktuře, která by lépe vystihovala vzájemné vazby mezi jednotlivými položkami.
Potomci v detailu položky
V této variantě by obecný seznam položek (umístěný na hlavní straně) obsahoval pouze položky, které nemají předky (v našem případě se jedná projekty) a veškeré položky, které mají nějakého předka (v našem případě úkoly a podúkoly) by byly zobrazené v obdobném seznamu umístěném v detailu předka. Jednotlivé seznamy jsou tak přehlednější, ale náročněji se provádějí operace vyhledávání a filtrování. Tyto operace musí uživatel nastavit pro každý seznam zvlášť.
Jednotný seznam
Tento návrh se zaměřuje na zjednodušení struktury aplikace, kdy budou veškeré položky zobrazeny v jednom seznamu. Je inspirován strukturou ganttova diagramu, kde jsou zobrazeny veškeré položky v hierarchické struktuře. Seznam, oproti předchozímu návrhu, bude obsahovat veškeré položky, které od sebe budou odlišeny úrovněmi dědičnosti. To znamená, že na první (nejvyšší) úrovni budou položky, které nemají předka a v nižších úrovních budou potomci. Potomci konkrétní položky budou zobrazeny striktně v úrovni pod ní a bude možné je pomocí ovládacího prvku skrývat nebo zobrazovat.
6.2.2 Přidávání a editace položek
Manipulace s položkami, respektive operace přidávání a editace, jsou jednou z častých operací, kterou uživatelé provádí. Tyto operace v původní verzi aplikace postrádaly nějakou formu zjednodušeného zadávání. Cílem těchto návrhů je usnadnit a
37 urychlit zadávání položek do systému a zredukovat opakované zapisování stejných údajů.
Předdefinované možnosti
Jeden z prvních návrhů spočíval v přednastavení možností u položek, u kterých je to možné. U vybraných vlastností položky byly definovány hodnoty, z kterých uživatel mohl vybírat. Cílem tohoto návrhu bylo zbavit uživatele nutnosti opakovaného vypisování, místo kterého by pouze vybíral správné hodnoty z již existujícího seznamu.
Například pro vlastnosti jako produkt, platforma nebo zákazník se tato možnost přímo nabízí. Na druhou stranu přibývá nutnost definice jednotlivých možností, která velice narůstá při různorodosti řešených projektů.
Automatické našeptávání
Návrh automatického našeptávání vycházel z využití automatického doplňování textu. Funkcionalita je podobná našeptávačům využívaným například v internetových vyhledávačích, kdy uživatel začne zadávat text a automaticky jsou mu nabízeny možné varianty. V rámci aplikace byly varianty vybírány z již existujících záznamů v databázi.
Hierarchické dědění vlastností
Následující návrh byl založen na hierarchické vazbě mezi jednotlivými položkami. Předvyplňování bude prováděno automaticky, a to z dat, které byly zadány v předchozí položce. Nevýhodou tohoto návrhu je fakt, že při zakládání projektu (položky bez předka) je nutné vyplnit všechny položky ručně (případně využít alternativní metodu vyplňování), protože nejsou specifikována data, která by byla děděna. Hlavní výhodou je drastické zjednodušení zadávání dat, která mají podobné, nebo málo rozdílné údaje. Což je u projektů a jejich úkolů velmi častý jev.
6.2.3 Vyhledávání dat v aplikaci
Aby bylo možné aplikaci efektivně používat s větším množství dat, je třeba uživateli umožnit specifikovat kritéria, dle kterých mu budou zobrazena konkrétní data, která ho zajímají.
Vyhledávání
Jedná se o základní metodiku, jak blíže specifikovat data, která jsou pro uživatele zajímavá. Jednoduše napíše vyhledávaná slova do textového vstupu a potvrzením se mu
