M A S A RY K O VA U N I V E R Z I TA F A K U LTA I N F O R M AT I K Y
Tvorba přizpůsobivých webových rozhraní
DIPLOMOVÁ PRÁCE
Bc. Jiří Stránský
Brno, jaro 2012
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: doc. Ing. Jiří Sochor, CSc.
Poděkování Děkuji doc. Ing. Jiřímu Sochorovi, CSc. za vedení mé diplomové práce. Děkuji Bc. Jaromíru Coufalovi za spolupráci při tvorbě webového portálu PracujZdravě.cz, jehož vývoj podnítil vznik praktické části této práce, softwarové knihovny Mobvious.
Shrnutí Práce popisuje, jakými technikami je možné přizpůsobovat webová uživatelská rozhraní různým zobrazovacím zařízením (zejména moderním mobilním telefonům, tabletům a osobním počítačům). Zabývá se přizpůsobením na straně serveru i přizpůsobením na straně klienta. Práce dále zkoumá virtualizaci displeje ve webových prohlížečích na mobilních zařízeních. Zabývá se správným nastavením virtualizace pro přizpůsobivá rozhraní se zohledněním rozdílných hustot pixelů na displejích různých mobilních zařízení. Součástí práce je implementace softwarové knihovny Mobvious, jejímž účelem je usnadnit přizpůsobení webových rozhraní na straně serveru v prostředí jazyka Ruby a aplikačního rámce Ruby on Rails.
Klíčová slova webové uživatelské rozhraní, přizpůsobivé rozhraní, mobilní zařízení, mobilní webové prohlížeče, průhled, viewport, kaskádové styly, responsive web design, detekce prohlížeče, Ruby on Rails
Obsah 1 Úvod........................................................................................................................................1 2 Přehled požadavků a technik přizpůsobení..............................................................................3 2.1 Požadavky na tvorbu přizpůsobivých webových rozhraní................................................3 2.2 Techniky přizpůsobení webových rozhraní......................................................................4 2.3 Shrnutí............................................................................................................................12 3 Přizpůsobení na straně klienta................................................................................................13 3.1 CSS media types............................................................................................................13 3.2 CSS media queries.........................................................................................................16 3.3 JavaScript.......................................................................................................................19 3.4 Knihovna Twitter Bootstrap...........................................................................................20 4 Přizpůsobení na straně serveru...............................................................................................21 4.1 Výběr správné verze rozhraní pro dané zařízení.............................................................22 4.2 Úprava výstupu..............................................................................................................24 4.3 Samostatné aplikace.......................................................................................................24 5 Vykreslování webových rozhraní v mobilních prohlížečích...................................................26 5.1 Simulace odlišné velikosti okna prohlížeče....................................................................27 5.2 Simulace odlišné hustoty pixelů na displeji....................................................................28 5.3 Měřítko...........................................................................................................................31 5.4 Shrnutí............................................................................................................................31 6 Knihovna Mobvious..............................................................................................................37 6.1 Motivace........................................................................................................................37 6.2 Funkcionalita..................................................................................................................38 6.3 Hlavní modul (Mobvious)..............................................................................................38 6.4 Modul pro přizpůsobení pohledů (Mobvious-Rails).......................................................40 6.5 Distribuce, testování, dokumentace................................................................................41 6.6 Přínos.............................................................................................................................42 7 Závěr......................................................................................................................................43 Použité zdroje a literatura......................................................................................................45 Přehled elektronických příloh................................................................................................48
Kapitola 1
Úvod
Mezi návštěvníky webových stránek a aplikací globálně vzrůstá podíl těch, kteří přicházejí z mobilních zařízení (mobilních telefonů a tabletů). Agentura Morgan Stanley odhaduje, že počet lidí přistupujících k internetu z mobilních zařízení bude v roce 2014 větší než počet lidí přistupujících k internetu z osobních počítačů [MEE10]. Vzrůstá tedy potřeba zajistit, aby i na mobilních zařízeních byly webové stránky a aplikace dobře použitelné. Webové uživatelské rozhraní, které je dobře použitelné na počítači, však nemusí být dobře použitelné např. na mobilním telefonu [NIE12]. Z toho vyplývá potřeba tvorby přizpůsobivých webových rozhraní, tedy rozhraní, která jsou schopna se měnit v závislosti na zobrazovacím zařízení, aby bylo možné dosáhnout vysoké úrovně použitelnosti na všech zařízeních. Cílem této práce je především popsat, jakými technickými způsoby je možné dosáhnout změny vzhledu webového uživatelského rozhraní dle přistupujícího zobrazovacího zařízení. Práce dále popisuje specifika vykreslování webových rozhraní v mobilních prohlížečích, protože je odlišné od vykreslování v prohlížečích na osobních počítačích. Praktickou část práce tvoří softwarová knihovna pro aplikační rámec Ruby on Rails, jejímž účelem je usnadnit tvorbu přizpůsobivých webových rozhraní (využitím úpravy výstupu na straně serveru). Cílem této práce není popsat, jak by měla vypadat uživatelská rozhraní na různých typech zobrazovacích zařízení, aby bylo dosaženo vysoké použitelnosti. Tato práce popisuje tvorbu přizpůsobivých rozhraní z technického pohledu, nikoliv z pohledu designu a použitelnosti. (Tématice designu a použitelnosti přizpůsobivých webových rozhraní se věnuje diplomová práce Jaromíra Coufala [COU12].) Práce se zabývá pouze těmi nejvýznamnějšími zařízeními, která jsou schopna zobrazit webové stránky. V současné době jsou to osobní počítače, moderní mobilní telefony a počítačové tablety (Apple iPad a další). V budoucnosti pravděpodobně nabudou na významu i další zařízení (např. televizory), jejichž specifika v práci nejsou brána v úvahu, ale uvedené postupy by měly být aplikovatelné i na tato zařízení. V částech práce, kde jsou zkoumány konkrétní mobilní prohlížeče, jsou použity prohlížeče Safari (mobilní varianta), Android Browser a Opera Mobile, protože jsou nejvýznamnější v prostředí České republiky [SCG12].
1
Kapitola 2, Přehled požadavků a technik přizpůsobení, dává čtenáři základní orientaci v problematice přizpůsobivých webových rozhraní. Vysvětluje, proč je potřeba přizpůsobovat, a podává přehled nejpoužívanějších technik. Kapitola 3, Přizpůsobení na straně klienta, se zabývá přizpůsobením aplikovaným ve webovém prohlížeči po obdržení obsahu stránky od webového serveru. Kapitola 4, Přizpůsobení na straně serveru, se zabývá přizpůsobením aplikovaným ještě před odesláním obsahu webové stránky klientovi (prohlížeči). Kapitola 5, Vykreslování webových rozhraní v mobilních prohlížečích, zkoumá virtualizaci zobrazovací plochy prováděnou mobilními webovými prohlížeči a její správné nastavení pro přizpůsobivá webová rozhraní. Kapitola 6, Knihovna Mobvious, popisuje softwarovou knihovnu vyvinutou jako součást této práce. Knihovna usnadňuje přizpůsobení na straně serveru při použití programovacího jazyka Ruby a aplikačního rámce Ruby on Rails. Kapitola 7, Závěr, podává zjednodušené shrnutí poznatků učiněných v této práci.
2
Kapitola 2
Přehled požadavků a technik přizpůsobení
Tato kapitola poskytuje přehled požadavků na tvorbu přizpůsobivých webových rozhraní a technik jejich realizace. Techniky jsou podrobněji popsány v následujících kapitolách.
2.1 Požadavky na tvorbu přizpůsobivých webových rozhraní Existují významné rozdíly mezi zařízeními schopnými zobrazovat webová uživatelská rozhraní. Tyto rozdíly jsou podnětem pro tvorbu přizpůsobivých webových rozrhaní. Hlavní odlišnosti mezi zařízeními, vyžadující zohlednění při tvorbě webových rozhraní, jsou především [COU12], [NIE12]: •
způsob interakce se zařízením, protože navigace prstem je méně přesná než navigace myší a vyžaduje větší plochu aktivních oblastí (tlačítek, odkazů apod.) a také větší vzdálenosti mezi sousedícími aktivními oblastmi. Navíc na dotykovém displeji neexistuje ekvivalentní gesto pro tzv. hover neboli „najetí myší“;
•
velikost displeje, protože rozměry plochy pro zobrazení se mohou napříč zařízeními výrazně lišit, nelze tedy použít jedno rozvržení rozhraní na všech zařízeních;
•
kontext použití, protože lidé používají různá zařízení v rozdílných situacích a za rozdílnými účely. Očekávání uživatelů spojená se vzhledem a funkcionalitou aplikací se liší dle typu zařízení. Např. na mobilních telefonech lidé často používají internet mimo domov, za účelem rychlého získání specifické informace.
Z výše zmíněných odlišností zobrazovacích zařízení je možné vyvodit konkrétnější požadavky na tvorbu přizpůsobitelných webových rozhraní. V závislosti na zobrazovacím zařízení je vhodné mít možnost [COU12], [NIE12]: •
měnit vzhled a uspořádání obsahu, např. upravit velikost písma, zúžit oblast určenou pro výpis textu nebo jiných prvků rozhraní, přeskládat ucelené části rozhraní vedle sebe nebo pod sebe;
3
•
měnit vzhled a chování ovládacích prvků, např. zvětšit nebo zmenšit aktivní oblasti a jejich vzdálenosti od jiné nejbližší aktivní oblasti v souladu s pravidly použitelnosti, měnit způsob přístupu k nabídkám (vždy viditelné vs. viditelné po rozbalení, jednoúrovňové vs. víceúrovňové);
•
skrýt nebo zobrazit některé části rozhraní, např. odstranit boční panely s informacemi doplňujícího charakteru a jiné méně důležité prvky, některé části rozhraní zobrazovat až na pokyn uživatele;
•
celkově měnit obsah a ovládání, např. zestručnit text, vyměnit multimediální obsah za datově úspornější, změnit postup interakce uživatele s rozhraním pro specifické akce.
Podrobnější informace o rozdílech mezi zařízeními a požadavcích, které klade designer na přizpůsobivost webových uživatelských rozhraní, jsou v práci Jaromíra Coufala [COU12].
2.2 Techniky přizpůsobení webových rozhraní Ke tvorbě webových rozhraní, která mohou napříč zobrazovacími zařízeními vypadat a fungovat rozdílně, lze použít techniky: •
detekce vlastností zařízení na straně klienta a přizpůsobení vzhledu,
•
detekce typu zařízení na straně serveru a úprava výstupu,
•
detekce typu zařízení na straně serveru a přesměrování na rozdílné aplikace.
Techniky lze vzájemně kombinovat. V následujících podkapitolách jsou uvedeny základní informace o těchto technikách pro poskytnutí všeobecné orientace. Dále jsou techniky popsány v kapitolách 3 a 4.
2.2.1
Přizpůsobení na straně klienta
Při použití přizpůsobení na straně klienta server posílá všem klientům shodný obsah. Klientský prohlížeč vyhodnotí své zobrazovací vlastnosti a podle toho selektivně aplikuje kaskádové styly, které mohou přeskládávat, schovávat, zobrazovat a jinak měnit obsah a vzhled stránky. Některé vlastnosti zobrazovacího zařízení lze zjistit i v kódu jazyka JavaScript prostřednictvím rozhraní DOM (document object model) a následně selektivně spouštět skripty. Pro návrh webových rozhraní, která využívají přizpůsobení na straně klienta, se často používá pojem responsive web design (volně by se dal přeložit jako návrh reagujících webů, ale běžně se nepřekládá). Pojem nemá jednotně uznávanou přesnou definici. Ethan Marcotte popsal v knize Responsive Web Design [MAR11], jak se staví responsive web pomocí přizpůsobení na straně 4
klienta, ale nevytvořil definici pojmu responsive web design. Z povahy názvu by bylo přirozené zahrnout mezi responsive web design všechny techniky, které umožňují stavbu webového rozhraní, které se samo přizpůsobuje zobrazovacímu zařízení, tedy všechny techniky zmíněné v této práci, včetně přizpůsobení na straně serveru. Komunita webových vývojářů však pojem používá téměř výhradně ve spojitosti s přizpůsobováním na straně klienta pomocí media queries, což je rozšíření jazyka CSS definované doposud nedokončeným doporučením konsorcia W3C. Media queries jsou podrobněji popsány v samostatné kapitole 3. Využívání přizpůsobení webového rozhraní na straně klienta se rozšiřuje až v posledních letech (přibližně od roku 2009) s příchodem media queries a jejich implementací ve webových prohlížečích. Výhody přizpůsobení na straně klienta: •
Pomocí media queries lze o klientském zařízení zjistit více informací než pomocí detekce prohlížeče. Jsou dostupné údaje jako rozlišení, hustota bodů na displeji nebo orientace displeje (režim portrét, nebo krajina). Je vhodné mít možnost provádět úpravy vzhledu a funkce rozhraní až dle detailních parametrů každého zařízení, protože rozdíly mezi zařízeními nemají jasně stanovené hranice. Tak jako se objevily tablety, tvořící stupeň mezi mobilním telefonem a osobním počítačem, objevují se malé tablety, tvořící stupeň mezi mobilním telefonem a tabletem, a velké tablety s dokovatelnými klávesnicemi a stylusy, které tvoří stupeň mezi tabletem a osobním počítačem. U některých zařízení je tedy složité určit, zda je zařadit mezi mobilní telefony nebo tablety, u jiných je problém rozhodnout, zda je zařadit mezi tablety nebo počítače. Na trhu je dostupná téměř spojitá škála zařízení, co se týče velikosti displejů a způsobů ovládání. Media queries s touto situací nemají problém, protože se nesnaží kategorizovat zařízení do skupin, ale umožňují plynulé přizpůsobení dle vlastností zařízení.
•
Pokud dojde ke změně vlastností displeje po zobrazení stránky (např. uživatel přetočí zařízení a tím změní orientaci displeje), lze znovu vyhodnotit informace o zařízení a aplikovat jiné přizpůsobení bez nutnosti opětovného načtení stránky.
•
Údaje o zařízení zjištěné na straně klienta jsou jednoznačné a správné, nejedná se o heuristický přístup náchylný k nepřesnostem při detekci.
Nevýhody přizpůsobení na straně klienta: •
V okamžiku, kdy server odesílá odpověď na HTTP požadavek klienta, není jasné, jakým způsobem se klient rozhodne stránku vykreslit (co z obsahu použije, jaké bude aplikováno přizpůsobení). Je tedy nutné poslat obsah pro všechny varianty přizpůsobení a významný podíl přenesených dat nakonec může zůstat nevyužitý. To je citelné u mobilních zařízení, která se běžně připojují k internetu nízkou přenosovou rychlostí a jsou zatížena datovými limity. Problém lze částečně řešit nahráváním obsahu 5
dodatečně pomocí skriptů JavaScript, ale tím se zvýší vnitřní složitost aplikace a může dojít ke komplikacím při indexaci stránek vyhledávači. •
Pro některé aplikace je žádoucí odlišit mobilní verzi od verze pro počítače výrazněji, třeba i změnit proces interakce s aplikací. Dosahovat takto výrazných změn pouze pomocí přizpůsobení na straně klienta je náročné.
Na obrázku 2.1 je portál Smashing Magazine, používající přizpůsobení na straně klienta.
6
Obrázek 2.1: Portál Smashing Magazine, který používá přizpůsobení na straně klienta. Nejvýraznějším prvkem přizpůsobení je schování pravého panelu s reklamami, zůstává pouze hlavní obsahová část. Přesto je množství přenesených dat u mobilní i počítačové verze shodné, přibližně 1,5 MB. 7
2.2.2
Úprava výstupu na straně serveru
Úprava výstupu na straně serveru by se dala označit za kompromisní techniku mezi vytvářením samostatných aplikací a přizpůsobováním rozhraní na straně klienta. Na HTTP požadavek klienta server reaguje HTTP odpovědí, jejíž obsah upravuje dle typu klientského zařízení. Může se např. odkazovat na jinou sadu kaskádových stylů a jinou sadu skriptů JavaScript pro upravení vzhledu, ale může i úplně vyměnit obsah webové stránky. Zjištění, jaký typ zařízení se serverem právě komunikuje, se zpravidla provádí pomocí detekce prohlížeče z hlavičky HTTP požadavku. Detekce je heuristická a nemusí být vždy bezchybná, proto by uživatel měl mít možnost později mezi verzemi manuálně přepínat. Stav manuálního přepnutí na určitou verzi rozhraní se dá reprezentovat různými způsoby, např. odlišením URL nebo pomocí cookie. Výhody úpravy výstupu na straně serveru: •
Dovoluje posílat velmi odlišný obsah webových stránek. To je výhodou zejména kvůli možnosti posílat mobilním klientům menší množství dat a také provádět náročnější vzhledové úpravy, kterých by se špatně dosahovalo pouze změnou kaskádových stylů.
Nevýhody úpravy výstupu na straně serveru: •
Neprobíhá plynulé přizpůsobení, ale zařízení jsou kategorizována do předem daných skupin (např. mobilní telefony, tablety, počítače). Některá zařízení však nemusejí být snadno kategorizovatelná (vysvětleno výše v části 2.2.1).
•
Technika přejímá nevýhody spojené s použitím detekce prohlížeče: možnost nekorektní detekce prohlížeče/zařízení a potřeba průběžné aktualizace (více v kapitole 4).
•
Vzhledem k tomu, že na všech zařízeních se jedná o shodnou aplikaci, není možné úplně přestavět způsob interakce s aplikací.
Na obrázku 2.2 je portál PracujZdravě.cz, který používá úpravu výstupu na straně serveru, doplněnou o prvky přizpůsobení na straně klienta.
8
Obrázek 2.2: Portál PracujZdravě.cz (nyní ve vývoji), který používá úpravu výstupu na straně serveru, doplněnou o prvky přizpůsobení na straně klienta. Hlavními přizpůsobeními jsou odstranění pravého panelu a změna chování a pozice nabídek. Počítačová verze má velikost 392 kB, mobilní verze 245 kB. 9
2.2.3
Vytvoření samostatných aplikací
Rozšířenou technikou pro přizpůsobení rozhraní zařízením je vytvořit pro daný typ zařízení samostatnou aplikaci. Tento způsob se používá u aplikací s komplexním uživatelským rozhraním a předpokladem zvýšené návštěvnosti z mobilních telefonů, typicky například u sociálních sítí. Jedná se také o přizpůsobení na straně serveru, protože je provedeno ještě před odesláním obsahu klientovi. Přesměrování nově příchozího uživatele na správnou aplikaci běžně probíhá pomocí detekce prohlížeče z prvního HTTP požadavku. Stejně jako u techniky úpravy výstupu na straně serveru i v případě techniky samostatných aplikací platí, že správnost detekce není zaručena a uživatel by měl mít možnost manuálně přepínat mezi verzemi. Výhody samostatných aplikací: •
Samostatné rozhraní pro daný typ zařízení umožňuje přizpůsobení, které není ničím limitované. Lze nejen měnit vzhled aplikace, ale i vytvořit celkově odlišný způsob interakce uživatele s aplikací.
•
Lze snadno dosáhnout snížení množství přenesených dat na mobilních zařízeních.
Nevýhody samostatných aplikací: •
Stavba dvou nebo více samostatných webových rozhraní je oproti ostatním technikám náročnější na vývoj a údržbu.
•
Typů zařízení, pro které je třeba přizpůsobovat webová rozhraní, přibývá. Než přišla společnost Apple v roce 2010 s tabletem iPad, bylo dostačující poskytovat jednu verzi rozhraní pro osobní počítače a druhou pro mobilní telefony. Nyní je vhodné poskytovat i rozhraní pro tablety a v budoucnu možná bude vhodné poskytovat u některých webových služeb rozhraní pro televize. Vytvářet pro každý typ zařízení samostatnou aplikaci při tomto množství různých typů zařízení dále zvyšuje náročnost této techniky.
•
Neprobíhá plynulé přizpůsobení, ale zařízení jsou kategorizována do předem daných skupin (např. mobilní telefony, tablety, počítače). Některá zařízení však nemusejí být snadno jednoznačně kategorizovatelná (vysvětleno výše v části 2.2.1).
•
Technika přejímá nevýhody spojené s použitím detekce prohlížeče: možnost nekorektní detekce prohlížeče/zařízení a potřeba průběžné aktualizace (více v kapitole 4).
Na obrázku 2.3 je portál iDNES.cz, který používá techniku samostatných aplikací.
10
Obrázek 2.3: Portál iDNES.cz, který používá samostatnou mobilní webovou aplikaci. Je vybráno méně hlavních článků, jsou použity menší náhledové obrázky (nejsou zmenšovány na straně klienta). Počítačová verze má velikost 684 kB, mobilní má velikost 75 kB.
11
2.3 Shrnutí Uvedené techniky lze kombinovat pro dosažení nejlepšího výsledku. Například může být vhodné techniku samostatných aplikací nebo úpravy výstupu na straně serveru doladit technikou přizpůsobení na straně klienta. Současné nevýhody přizpůsobení na straně klienta, zejména vyšší náročnost na internetové připojení a nedostačující síla jazyka CSS pro některá přizpůsobení, postupně pozbývají na významu kvůli zvyšování přenosových rychlostí mobilního připojení a neustálému vývoji webových standardů. Přesto Jakob Nielsen, uznávaný odborník na použitelnost webových rozhraní, i v roce 2012 poukazuje na vhodnost tvorby oddělených rozhraní pro mobilní zařízení, protože testování ukázalo, že způsob použití mobilních zařízení je příliš odlišný od způsobu použití počítačů [NIE12]. Jakob Nielsen se však ve svém článku zabývá pouze netriviálními webovými aplikacemi, nezabývá se přizpůsobením jednoduchých informativních webových stránek. Žádná z technik se nedá označit za obecně lepší, jejich vhodnost je třeba zvažovat v kontextu konkrétního projektu. Zjednodušeně by se dalo říci, že čím komplexnější je rozhraní aplikace, tím silnější techniku přizpůsobení je vhodné použít. Například pro firemní prezentační stránky postačí přizpůsobení na straně klienta, naopak rozsáhlé aplikace typu sociálních sítí využívají samostatné mobilní webové aplikace (např. Facebook, Twitter). Přizpůsobení na straně klienta je podrobněji popsáno v kapitole 3. Techniky úpravy výstupu a stavby samostatných aplikací se dají souhrnně označit jako přizpůsobení na straně serveru a jsou podrobněji popsány v kapitole 4.
12
Kapitola 3
Přizpůsobení na straně klienta
Tato kapitola popisuje přizpůsobení webového uživatelského rozhraní na straně klienta pomocí kaskádových stylů (CSS) a skriptů jazyka JavaScript.
3.1 CSS media types Media types jsou rozšíření syntaxe jazyka CSS, definované doporučením konsorcia W3C [W3C11]. Media types umožňují aplikovat rozdílná CSS pravidla na různých zobrazovacích zařízeních. Rozlišovací schopnosti jsou omezené na 9 předdefinovaných typů zařízení. Pro tvorbu přizpůsobivých webových rozhraní nejsou media types dostačující, ale tvoří myšlenkový i syntaktický základ pro pokročilejší rozšíření nazvané media queries. Při vývoji přizpůsobivých webových rozhraní je tedy vhodná alespoň základní orientace v media types.
3.1.1
Typy zařízení
Media types rozlišují typy zařízení následujícími klíčovými slovy [W3C11]: •
braille – zařízení zobrazující Braillovo písmo (k přímému čtení),
•
embossed – tiskárny na Braillovo písmo,
•
handheld – mobilní zařízení (s malým displejem a omezenou rychlostí připojení),
•
print – tiskárny,
•
projection – projektory,
•
screen – primárně zamýšleno pro (barevné) počítačové obrazovky,
•
speech – syntezátory řeči (tento typ má vlastní specifická CSS pravidla),
•
tty – zařízení s pevnou vykreslovací mřížkou (např. textové terminály),
•
tv – televizory (zařízení s nízkým rozlišením a omezenými schopnostmi skrolování).
13
Media types dále sdružují typy do skupin kvůli možnosti zkrátit zápis pravidel: •
all – aplikuje styl na všechna zařízení,
•
continuous – zařízení se spojitým vykreslováním,
•
paged – zařízení se stránkovaným vykreslováním,
•
visual – zařízení schopná vizuálního zobrazení,
•
tactile – zařízení používající Braillovo písmo,
•
speech – zařízení schopná syntézy řeči,
•
audio – zařízení schopná přehrávání zvuku,
•
grid – zařízení zobrazující znaky v pevné mřížce,
•
bitmap – zařízení schopná vykreslení obrazových dat (ne pouze textu),
•
interactive – zařízení interagující s uživatelem,
•
static – zařízení bez interakce.
Příslušnost jednotlivých typů zařízení do zmíněných skupin je stanovena tabulkou v doporučení CSS2: Media types [W3C11].
3.1.2
Zápis pravidel media types
Prvním způsobem použití media types je pravidlo @media přímo v souboru CSS. Do oblasti ohraničené tímto pravidlem se vkládají běžná pravidla jazyka CSS a tato pravidla pak mají efekt pouze na zařízeních specifikovaného typu. Ukázka použití pravidla @media je ve zdrojovém kódu 3.1. Čárka v zápisu má význam logické spojky nebo, styl pro element body v prvním pravidle ukázky je tedy aplikován jak na obrazovkách, tak při tisku. Zápis pravidel je podrobněji popsán v doporučení CSS2: Media types [W3C11]. @media screen, print { body { font-family: serif; } } @media print { a { color: inherit; } }
Zdrojový kód 3.1: Použití media types uvnitř souboru CSS
14
Druhým způsobem použití je vložení externího CSS souboru do HTML pomocí elementu , který má nastaven atribut media. Omezení na specifikovaný typ zařízení pak platí pro všechna pravidla v daném externím souboru CSS. Příkladem je zdrojový kód 3.2, podrobnější informace jsou k nalezení opět v CSS2: Media types [W3C11].
Zdrojový kód 3.2: Použití media types ze souboru HTML, styl pouze pro tisk
3.1.3
Omezení media types
Typ handheld byl doporučením W3C určen pro použití na malých přístrojích, jako jsou mobilní telefony. V době uvedení telefonů schopných lepšího grafického vykreslení stránek však nebylo mnoho webů, které by typ handheld využívaly. Výrobci telefonů se tedy rozhodli, že v mobilních prohlížečích budou raději používat styly stejné jako na osobních počítačích. Moderní mobilní telefony tedy využívají typ screen a media types jsou na nich pro odlišení vzhledu nepoužitelné [MAR11]. Media types se v praxi využívají především k formátování webových stránek pro tisk.
15
3.2 CSS media queries Media queries jsou rozšíření jazyka CSS, obohacující funkcionalitu media types o přesnější cílení jednotlivých pravidel v závislosti na vlastnostech displeje [W3C10] (časté je cílení na základě rozlišení zobrazovací plochy). Media queries se nesoustřeďují na všechny typy zařízení, ale pouze na ty, které jsou schopné vizuálního zobrazení. Media queries umožňují přizpůsobit vzhled obsahu různě velkým displejům pouhou změnou v kaskádových stylech. Doporučení W3C, které media queries definuje, je ve stavu candidate recommendation. Jeho obsah by se ještě mohl změnit, ale výraznější přepracování je nepravděpodobné. Majoritní prohlížeče již media queries podporují (Chrome 4+, Firefox 3.5+, Safari 3.1+, Opera 9.5+, Internet Explorer 9+) [DEV12].
3.2.1
Detekovatelné vlastnosti zařízení
Media queries jsou v současnosti nejpodrobnějším a nejspolehlivějším způsobem zjištění vlastností zobrazovacího zařízení pro webová rozhraní. Umožňují cílení CSS pravidel v závislosti na hodnotách 13 definovaných vlastností. Vlastnosti je možné porovnávat buď způsobem přesné shody se zadanou hodnotou, nebo rozsahově pomocí pravidel s prefixem min- nebo max-. Rozsahové určení je podporováno jen u některých vlastností. Díky možnosti vkládat do zápisu pravidel logické spojky a zároveň a nebo lze vytvářet složitější konstrukce, které cílí pravidla na přesně vymezené skupiny zařízení. Toto je hlavní výhoda media queries (a obecně přizpůsobení na straně klienta), protože srovnatelné přesnosti nelze dosáhnout při použití technik založených na detekci prohlížeče. Přehled vlastností je uveden v tabulce 3.3, podrobnější informace jsou v doporučení CSS3: Media queries [W3C10].
16
Pravidlo
Porovnávaná vlastnost zařízení
width min-width max-width
šířka plochy určené pro zobrazení obsahu
height min-height max-height
výška plochy určené pro zobrazení obsahu
device-width min-device-width max-device-width
šířka celého displeje
device-height min-device-height max-device-height
výška celého displeje
orientation
orientace displeje (landscape/portrait)
aspect-ratio min-aspect-ratio max-aspect-ratio
poměr šířka:výška plochy určené pro zobrazení obsahu
počet bitů na jednu barevnou komponentu v reprezentaci pixelu (Např. 24-bitová barevná hloubka odpovídá color: 8, pro černobílé displeje a displeje s předdefinovanou tabulkou barev má hodnotu 0.)
color-index min-color-index max-color-index
počet záznamů v tabulce barev (Pro displeje bez tabulky barev má hodnotu 0.)
monochrome min-monochrome max-monochrome
počet bitů na pixel u černobílých displejů (Pro barevné displeje má hodnotu 0.)
resolution min-resolution max-resolution
hustota bodů na zobrazovacím zařízení
scan
skenovací proces pro televizní displeje (progressive/interlace)
grid
hodnota 1 při zobrazení s pevnou vykreslovací mřížkou (např. terminálové prohlížeče), jinak 0
Tabulka 3.3: Vlastnosti zařízení zjistitelné pomocí media queries
3.2.2
Zápis pravidel media queries
Zápis media queries se provádí pomocí pravidla @media nebo atributu media, stejně jako zápis media types. K čárce v zápisu pravidla (znamenající nebo) přibylo klíčové slovo and, které reprezentuje logickou spojku a zároveň. Klíčové slovo and má větší prioritu než čárka. Ukázky použití media queries jsou ve zdrojových kódech 3.4 a 3.5, podrobněji jsou pravidla zápisu popsána v doporučení CSS3: Media queries [W3C10]. @media screen and (min-width: 500px) and (orientation: portrait), screen and (min-width: 800px) and (orientation: landscape) { /* * pravidla aplikovaná v režimu portrét a šířkou alespoň 500 pixelů * a v režimu krajina a šířkou alespoň 800 pixelů */ } @media screen and (min-width: 800px) and (max-width: 1200px) { /* * pravidla aplikovaná pro šířku v intervalu 800 až 1200 pixelů */ }
Zdrojový kód 3.4: Použití media queries uvnitř souboru CSS
Zdrojový kód 3.5: Použití media queries ze souboru HTML
18
3.3 JavaScript Přizpůsobení na straně klienta lze aplikovat i pomocí skriptů jazyka JavaScript. Pomocí rozhraní DOM (document object model) lze zjistit velikost okna prohlížeče a velikost displeje (v pixelech). Přístup k hodnotám těchto vlastností je shrnut v tabulce 3.6. Na základě zjištěných hodnot vlastností lze ve skriptu provést libovolné akce s HTML dokumentem. Výraz jazyka JavaScript
Vlastnost
window.innerWidth
šířka plochy určené pro zobrazení obsahu
window.innerHeight
výška plochy určené pro zobrazení obsahu
screen.width
šířka celého displeje
screen.height
výška celého displeje Tabulka 3.6: Výrazy jazyka JavaScript pro přístup k vlastnostem zobrazovacího zařízení
3.3.1
Chvilkové zobrazení nenastylovaného obsahu
Přizpůsobení kaskádovými styly (media queries) se aplikuje automaticky při načítání stránky, přizpůsobení pomocí skriptu je však potřeba aplikovat imperativně, např. jako reakci na události, které definuje document object model. Přizpůsobení je vhodné aplikovat vždy po načtení stránky a znova při každé změně velikosti vykreslovací plochy (např. při změně orientace portrét/krajina). Pro reakci na načtení stránky se používá událost window.onload a pro reakci na změnu velikosti vykreslovací plochy se používá událost window.onresize. S aplikací přizpůsobení pomocí jazyka JavaScript je spojen problém chvilkového zobrazení nenastylovaného obsahu (flash of unstyled content, FOUC) [KEN11]. Webová stránka se načítá postupně a zobrazuje se uživateli. Když je načítání hotovo, je možné aplikovat přizpůsobení pomocí skriptu (spustí se událost onload). Až do tohoto okamžiku však uživatel může spatřit stránku bez skriptového přizpůsobení. Na osobních počítačích může být FOUC téměř nepostřehnutelné, ale na mobilních zařízeních může trvat i několik sekund kvůli pomalému načítání stránky přes mobilní internetové připojení. Je tedy vhodnější používat metody založené na kaskádových stylech vždy, když je pomocí nich možné dosáhnout ekvivalentního výsledku.
19
3.4 Knihovna Twitter Bootstrap Twitter Bootstrap je funkčně rozsáhlá a populární softwarová knihovna, která poskytuje kostru webového uživatelského rozhraní [TWI12]. Kromě nastavení základních prvků (formuláře, navigace, chybová hlášení, uspořádání obsahu na stránce apod.) obsahuje také zásuvné moduly s doplňkovou funkcionalitou (modální dialogy, přepínatelné záložky, našeptávače, obrázkovou galerii apod.). Od verze 2.0 jsou všechny funkce a zásuvné moduly upraveny tak, aby správně pracovaly na různě velkých displejích (včetně mobilních telefonů), a uživatelské rozhraní je přizpůsobeno i pro dotykové ovládání. V současnosti je Twitter Bootstrap vůbec nejsledovanějším open-source projektem na serveru Github, má více tzv. watchers, než mají jiné populární projekty, jako jsou Ruby on Rails, Node.js nebo jQuery [GIT12]. Twitter Bootstrap je nezávislý na použitém programovacím jazyku na straně serveru, jedná se o sadu kaskádových stylů, skriptů jazyka JavaScript a obrázků. Lze jej tedy použít v mnoha projektech a poskytuje dobrý základ pro rozhraní přizpůsobená na straně klienta.
20
Kapitola 4
Přizpůsobení na straně serveru
Tato kapitola popisuje techniky přizpůsobení webových rozhraní na straně serveru: úpravu výstupu a stavbu samostatných aplikací. Jednoduchá webová rozhraní (např. prezentační webové stránky firem) lze dostatečně přizpůsobit na straně klienta pomocí technik popsaných výše (zejména media queries). Pro složitější rozhraní (např. komplexní webové aplikace, rozsáhlé zpravodajské a jiné portály) však nemusí být úpravy na úrovni kaskádových stylů dostatečně silným prostředkem pro odlišení jednotlivých verzí rozhraní. V takovém případě je nutné pozměnit kód HTML posílaný prohlížeči. Tím je možné zejména: •
upravovat vzhled rozhraní způsobem, který není možný pouhou změnou CSS,
•
posílat kód HTML pouze těch částí rozhraní, které budou opravdu zobrazeny,
•
celkově měnit obsah,
•
používat jiné varianty multimédií, které sníží množství přenesených dat.
Při stavbě samostatných aplikací pro každý typ zařízení je navíc možné i upravit způsob interakce uživatele s aplikací (např. změnit kroky nutné pro provedení nějaké akce). Míru používanosti těchto technik není jednoduché určit, protože není v uživatelském rozhraní na první pohled patrná (změny mohou být nevýrazné). Pomocí pokusů s modifikací hlavičky HTTP požadavku bylo zjištěno, že 82 ze 100 nejnavštěvovanějších stránek na internetu (měřeno dle Alexa rank) používá nějakou formu přizpůsobení na straně serveru – vrací rozdílný obsah HTTP odpovědi v závislosti na hodnotě pole user-agent v hlavičce HTTP požadavku [CRE12]. (Výzkum však nerozlišoval mezi přesměrováním na samostatnou mobilní webovou aplikaci a úpravou výstupu na straně serveru tak, jak jak rozlišuje tato práce. Uvedený výsledek je tedy součtem počtu použití obou technik.) V podkapitole 4.1 je popsáno, jakým způsobem se server rozhoduje, kterou verzi rozhraní vykreslit nebo na jakou aplikaci prohlížeč přesměrovat; tato část je společná jak pro techniku samostatných aplikací, tak pro techniku úpravy výstupu. Technika úpravy výstupu je popsaná v podkapitole 4.2 a technika samostatných aplikací v podkapitole 4.3.
21
4.1 Výběr verze rozhraní Přizpůsobení na straně serveru vyžaduje provést výběr verze rozhraní k vykreslení. Volbu rozhraní může nějakým způsobem provést uživatel sám (zadáním specifického URL, kliknutím na přepínací odkaz aj.), nebo může volbu provést aplikace (nejčastěji pomocí detekce pro hlížeče).
4.1.1
Specifické URL
Odlišení verzí rozhraní pomocí vlastního URL je technika používaná především při stavbě samostatných aplikací pro každou verzi. Lze ji však použít i pro přizpůsobení v rámci jedné aplikace. (Všechny použité URL se v tomto případě směrují do dané aplikace a jejich další vyhodnocení se provádí až v aplikaci, např. pomocí regulárních výrazů.) Nevýhodou této techniky je, že ne vždy uživatel přichází na dané (např. mobilní) URL s cílem zvolit si toto rozhraní ze své vlastní vůle. Někdo mohl sdílet odkaz na sociální síti z mobilního telefonu, ale uživatel na tento odkaz kliknul na svém stolním počítači, přichází tedy na špatnou verzi rozhraní. Proto je u této techniky žádoucí kontrolovat pole referer hlavičky HTTP požadavku [FIE99], z níž je možné zjistit, zda návštěvník přichází kliknutím na odkaz, nebo přímo zadáním adresy. Pokud uživatel přichází z externího zdroje kliknutím na odkaz, je dobré nebrat volbu verze rozhraní pomocí URL v úvahu a nechat aplikaci zvolit nejvhodnější verzi.
4.1.2
Paměť prohlížeče (cookie)
Další technikou pro výběr verze rozhraní je uložení informací v prohlížeči. Je relevantní pouze pro uživatele, kteří už aplikaci používají a nepřicházejí poprvé. Provedenou volbu rozhraní (ať už automatickou, nebo manuální) lze uložit v prohlížeči jako cookie a prohlížeč pak tuto informaci posílá na server s každým požadavkem. Aplikace cookie z požadavku přečte a zvolí správnou verzi rozhraní.
4.1.3
Detekce prohlížeče
Vybrat verzi rozhraní lze také pomocí detekce prohlížeče z HTTP požadavku. Prohlížeče do hlavičky požadavku vkládají pole user-agent, kde identifikují samy sebe [FIE99]. Z poskytnutých informací může server získat zejména název prohlížeče a jeho verzi, často jsou však přítomny i další informace, např. název operačního systému nebo přibližné určení typu zařízení (mobilní prohlížeče často v poli user-agent uvádějí slovo mobile). Těchto informací lze využít k detekci typu zařízení. Příklad řetězce user-agent je ve zdrojovém kódu 4.1.
22
Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; es-es) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B367 Safari/531.21.10
Zdrojový kód 4.1: Řetězec user-agent tabletu Apple iPad Detekce je prováděna heuristicky, protože prohlížečů je velké množství, obsah pole useragent je převážně nestrukturovaný a prohlížeče do hlavičky vkládají informace nesourodými způsoby. Knihovny pro detekci typu zařízení z HTTP požadavku obvykle fungují na principu porovnávání řetězce user-agent s různými regulárními výrazy. Detekce prohlížeče má tyto nevýhody: •
Detekce prohlížeče nemusí být stoprocentně spolehlivá. Vzhledem k velkému množství různých zařízení a prohlížečů je nepravděpodobné, že by nějaký algoritmus byl schopen správně určit typ zařízení pro všechna existující zařízení a prohlížeče korektně. V praxi to však nezpůsobuje problémy. Důležité je, aby algoritmus správně rozpoznával hlavně zařízení, která jsou běžně používaná.
•
Není zaručeno, že jednou vyvinutá detekce prohlížeče bude dosahovat uspokojivých výsledků během celé doby životnosti aplikace. Je nutné průběžně aktualizovat detekční heuristiku, aby brala v úvahu nově vyvinutá zařízení.
•
Detekce prohlížeče dokáže zjistit pouze poměrně hrubé informace o zařízení. Určí kategorii (mobilní telefon, tablet, počítač apod.), ale nikoliv přesnější vlastnosti zařízení, např. rozlišení displeje. Může se tedy stát, že bude detekován tablet a vykreslena tabletová verze rozhraní, ale přitom může být daný tablet tak malý, že by se pro něj hodila spíše mobilní verze.
Přes uvedené nedostatky je detekce prohlížeče široce používaná, protože lepší alternativní technika (tzn. technika, která by také umožňovala určit typ zařízení pouze z informací v HTTP požadavku posílaného na server) v současnosti není k dispozici.
4.1.4
Shrnutí
Výše uvedené techniky pro výběr verze rozhraní je možné (a často vhodné) kombinovat. Při použití všech tří technik by volba verze rozhraní probíhala například takto: •
Volba na základě paměti prohlížeče by měla mít nejvyšší prioritu. Pokud uživatel přichází na URL mobilní verze, ale v prohlížeči má nastavenou verzi pro osobní počítač, měl by být přesměrován. Buď automaticky, nebo s jeho svolením.
23
•
Pokud není v prohlížeči informace uložena, lze verzi odvodit z URL, s výjimkou případů, kdy návštěvník přichází kliknutím na odkaz (zdůvodněno v podkapitole 4.1.1).
•
Pokud se předchozími způsoby nepodařilo určit verzi rozhraní, použije se volba pomocí detekce prohlížeče.
4.2 Úprava výstupu Přizpůsobení webového rozhraní na straně serveru, pokud všechny požadavky klienta obsluhuje jediná aplikace, vyžaduje nějakou formu větvení kódu v aplikaci. Odlišení verzí rozhraní lze dosáhnout pouhým nastavením příznaku určujícího verzi rozhraní a následného větvení v kódu aplikace pomocí příkazu if, který by kontroloval hodnotu tohoto příznaku. Při zapouzdření detekční a větvící funkcionality do softwarové knihovny nebo aplikačního rámce lze vývojáři poskytnout pohodlnější proces tvorby rozhraní přizpůsobeného úpravou výstupu na straně serveru. Tyto pokročilejší přístupy už však závisí na zvoleném programo vacím jazyku a aplikačních rámcích (web application framework). Úpravou výstupu na straně serveru se podrobně zabývá praktická část této práce, popsaná v kapitole 6.
4.3 Samostatné aplikace Při použití techniky samostatných aplikací je uživatel po provedení výběru verze rozhraní (ať už manuálně nebo automaticky) přesměrován do aplikace odpovídající jeho typu zařízení. Jedná se tedy také o určitou formu větvení na straně serveru. Větvení však neprobíhá až uvnitř aplikací, ale již výběrem aplikace, která obslouží HTTP požadavek. Výběr aplikace bývá typicky proveden pomocí severového softwaru schopného fungovat jako tzv. reverzní proxy (např. Apache nebo Nginx), případně použitím různých doménových jmen směrovaných na různé servery. Při použití reverzní proxy nemusí být ze strany klienta patrné, zda je rozhraní přizpůsobeno technikou samostatných aplikací, nebo technikou úpravy výstupu. Jednotlivé aplikace pracují nad stejnými daty. Při použití třívrstvé architektury [FOW02] je vhodné stavět více prezentačních vrstev (tj. vrstev zodpovědných za interakci s uživatelem), které sdílí společnou vrstvu doménové logiky (tj. vrstvu zodpovědnou za provádění operací nad vstupy a aplikačními daty). Pod vrstvou doménové logiky se nachází ještě vrstva datová (zodpovědná za ukládání a načítání dat). Toto dělení do vrstev zamezí problematickým redundancím ve zdrojovém kódu, přestože je vyvíjeno více aplikací poskytujících téměř totožnou funkcionalitu.
24
Přizpůsobení technikou samostatných aplikací za použití třívrstvé architektury ilustruje obrázek 4.2. Vrstva doménové logiky může být s jednotlivými prezentačními vrstvami spojena různými způsoby, např. pevně jako softwarová knihovna, nebo volně jako webová služba (web service).
Obrázek 4.2: Třívrstvá architektura přizpůsobení pomocí samostatných aplikací
25
Kapitola 5
Vykreslování webových rozhraní v mobilních prohlížečích
Tato kapitola popisuje specifika vykreslování webových uživatelských rozhraní v moderních mobilních prohlížečích, zejména s ohledem na lišící se kvalitu displejů napříč zařízeními. Informace zde uvedené jsou relevantní pro všechny dříve popsané techniky přizpůsobení. Prohlížeče na moderních mobilních zařízeních mají základní nastavení, v němž jsou schopné uživateli co nejlépe prezentovat webové stránky, které jsou navržené pro prohlížení na osobních počítačích a nejsou přizpůsobené malým displejům. K dosažení tohoto cíle mobilní zařízení virtualizují displej. Nepoužívají skutečné vlastnosti fyzického displeje, ale vykreslí stránku nejprve na virtuální displej s odlišnými vlastnostmi (tzv. viewport, česky průhled) a na fyzickém displeji zobrazují zmenšeninu a/nebo výřez virtuálního displeje [APP11]. Pro webová rozhraní, která jsou navržená s ohledem na existenci malých mobilních zařízení, nemusejí být základní nastavení mobilních prohlížečů vhodná. Mohou znemožňovat detekci skutečných vlastností zařízení a aplikaci správných přizpůsobení (např. ovlivňují hodnoty zjišťované pomocí media queries). Webová stránka však může před svým vykreslením upravit nastavení prohlížeče, případně virtualizaci potlačit a donutit zařízení, aby stránku vykreslovalo s použitím skutečných vlastností svého fyzického displeje. Virtualizace displeje má tři součásti: simulaci odlišné velikosti okna prohlížeče, simulaci odlišné hustoty pixelů na displeji a měřítko.
26
5.1 Simulace odlišné velikosti okna prohlížeče Prohlížeč na malém zařízení simuluje větší displej (používá průhled s většími rozměry, než by odpovídaly skutečným vlastnostem zařízení) a vykreslenou stránku zmenšeně překreslí na fyzický displej. Uživatel tak ihned po zobrazení získá základní orientaci ve stránce a poté může přibližovat, oddalovat a posouvat viditelnou oblast stránky (nejčastěji pomocí prstových gest) [APP11]. Implicitní šířka průhledu se liší napříč prohlížeči. Implicitní výška není stanovena a dopočítává se. Prohlížeč Safari na zařízeních s operačním systémem iOS má implicitní šířku průhledu 980 pixelů [APP11], prohlížeč Android Browser 800 pixelů [GOO11a] a prohlížeč Opera Mobile 850 pixelů [OPE11a]. Průhled lze nastavit v hlavičce HTML dokumentu pomocí elementu meta. Je důležité především stanovit jednu jeho stranu (výšku/šířku), druhá strana se dopočítá tak, aby měl průhled stejný poměr stran, jako má vykreslovací plocha prohlížeče. Příklad použití elementu meta je ve zdrojovém kódu 5.1.
<meta name="viewport" content="width=590">
Zdrojový kód 5.1: Nastavení šířky průhledu na 590 pixelů Pro stránky s pevnou šířkou obsahu se zpravidla stanovuje pevná šířka průhledu, a to tak, aby obsáhl pokud možno celou šířku stránky [GOO11a]. Uživatelé pak ihned po načtení stránky (tj. v základním pohledu s maximálním oddálením) posunují stránku pouze vertikálně, nikoliv horizontálně. Pro stránky s proměnlivou (tzv. fluidní) šířkou, které jsou přizpůsobené i pro zobrazení na malých displejích je vhodnější, aby prohlížeč nesimuloval velké rozlišení a umožnil aplikovat přizpůsobení. Změnou atributu content ve zdrojovém kódu 5.1 na width=device-width lze nastavit, aby prohlížeč použil šířku průhledu přiměřenou šířce displeje. Tímto však stále není zaručeno, že šířka průhledu (měřená v pixelech) bude přesně odpovídat šířce fyzické zobrazovací oblasti (v pixelech), protože některé prohlížeče ještě simulují jinou než skutečnou hustotu pixelů na displeji.
27
5.2 Simulace odlišné hustoty pixelů na displeji V roce 2010 začaly být běžně k dostání mobilní telefony s velmi velkou hustotou bodů na displeji. Například Apple iPhone 4 má 3,5palcový displej s rozlišením 640 ⨉ 960 pixelů, což odpovídá hustotě 326 dpi1. Naproti tomu tablet Apple iPad (první verze) má displej 9,7palcový s rozlišením 1024 ⨉ 768 pixelů, což odpovídá hustotě 132 dpi. Rozlišení displeje současných zařízení nemusí korespondovat s jejich fyzickou velikostí. Tento fakt by mohl způsobit problém při vykreslování rozhraní, jehož prvky mají rozměry udávané v pixelech a nepoužívají simulaci odlišné velikosti okna prohlížeče (mají průhled nastavený hodnotou width=devicewidth). Např. tlačítko použitelné na tabletu iPad by se na displeji iPhone 4 vykreslilo přibližně 2,5krát menší a mohlo by být nečitelné a špatně ovladatelné na dotykovém displeji. Mobilní prohlížeče se s rozdílnými hustotami pixelů na displejích vypořádávají simulací odlišné hustoty pixelů, než má fyzický displej [GOO11a]. Když je v kaskádových stylech nastavena velikost prvku např. na 10 pixelů, neznamená to nutně, že se prvek vykreslí přesně na 10 pixelů na fyzickém displeji. Na displejích s vysokou hustotou pixelů se prvek vykreslí na více pixelů (např. 20 pixelů), aby nepůsobil příliš malý, na displejích s nízkou hustotou pixelů to platí naopak. Implicitní chování a nastavitelnost se napříč prohlížeči liší (pro některé aspekty virtualizace vykreslování prozatím neexistuje standard), podrobnější popis chování prohlížečů je uveden v následujících podkapitolách. Simulovaná hustota pixelů je aplikována pouze při počítání rozměrů a pozic prvků na stránce, ne však při vykreslování [GOO11a]. Lze tedy docílit přibližně stejné velikosti textu a obrázků bez ohledu na skutečnou hustotu pixelů displeje, avšak nemusí tím být dotčena kvalita vykreslení. Na kvalitních displejích zůstanou obrázky a písmo hladce vykreslené i při simulaci nižší hustoty pixelů (pokud jsou rastrové obrázky poskytnuty v dostatečném rozlišení). Přínos simulace odlišné hustoty pixelů na displeji ilustruje tabulka 5.2. (Pro lepší názornost jsou všechny obrázky v tabulce trojnásobně zvětšené oproti skutečnosti.) Když je simulace vypnuta, velikost textu na displejích s výrazně rozdílnou hustotou pixelů se velmi liší. Se zapnutou simulací je velikost sjednocena, ale pro vykreslení textu jsou použity skutečné vlastnosti displejů (text na displeji s vyšší hustotou pixelů je vykreslen hladce).
1 Pro displeje se někdy jednotka hustoty obrazových bodů pojmenovává ppi (pixel per inch), má však stejnou sémantiku jako dpi (dots per inch). V práci je použito pojmenování dpi, aby byla dodržena konzistence s doporučeními W3C (v nich se vyskytuje pojmenování dpi).
28
simulovaná hustota pixelů na displeji simulace vypnuta
medium-dpi (přibližně 160 dpi)
125 dpi skutečná hustota pixelů na displeji 252 dpi
Prohlížeč Android Browser po nastavení width=device-width simuluje neextrémní hustotu pixelů, která není ani příliš vysoká, ani příliš nízká, aby byla zajištěna dobrá čitelnost. Přesná implicitní hodnota se však napříč zařízeními liší [GOO11a], [GOO11b]. <meta name="viewport" content="width=device-width, target-densitydpi=medium-dpi">
Zdrojový kód 5.3: Nastavení simulace hustoty pixelů pro Android Browser V případě potřeby lze simulaci hustoty pixelů upravit opět pomocí elementu meta v hlavičce HTML dokumentu (viz zdrojový kód 5.3). Vlastnost target-densitydpi může nabývat hodnot [GOO11a]: •
low-dpi (přibližně 120 dpi),
•
medium-dpi (přibližně 160 dpi),
•
high-dpi (přibližně 240 dpi),
•
device-dpi (skutečné dpi fyzického displeje, nepoužije se simulace),
•
<číslo> (vlastní hodnota dpi v rozmezí 70–400).
Hodnoty low-dpi, medium-dpi a high-dpi jsou specifikovány pouze přibližně, protože 29
přesnou simulovanou hustotu si každé zařízení mírně přizpůsobí tak, aby docházelo k co nejmenším nepřesnostem při překreslování na fyzický displej [GOO11b].
5.2.2
Safari (mobilní varianta)
Mobilní prohlížeč Safari používají telefony iPhone, které se vyrábí pouze se dvěma typy displejů: do iPhone verze 3 měly displej s rozlišením 320 ⨉ 480 pixelů (163 dpi), od verze 4 mají displej 640 ⨉ 960 pixleů (326 dpi). Na starším displeji neprobíhá simulace odlišné hustoty pixelů, jeho hustota je přiměřená (přibližně odpovídá hodnotě medium-dpi v prohlížeči Android Browser). Hustota pixelů novějšího displeje je přesně dvojnásobná a prohlížeč simuluje vlastnosti staršího displeje, tedy šířku 320 pixelů a výšku 480 pixelů, hustotu 163 dpi [APP11]. Opět platí, že simulace má efekt pouze na velikosti a vzdálenosti, ale nesnižuje kvalitu vykreslení písma a grafiky. Obdobně funguje simulace na zařízení iPad s displejem Retina, který má přesně dvojnásobnou hustotu pixelů oproti původnímu tabletu iPad. Pro Safari neexistuje oficiální způsob, jak přinutit prohlížeč použít skutečné vlastnosti fyzického displeje (nepodporuje target-densitydpi=device-dpi, ani v současnosti nemá vlastní ekvivalentní způsob nastavení).
5.2.3
Opera Mobile
Prohlížeč Opera Mobile neprovádí simulaci odlišné hustoty pixelů jako ostatní prohlížeče, místo toho na zařízeních s vysokou hustotou pixelů aplikuje ihned po zobrazení stránky zvětšení měřítka [OPE11b]. Tato vlastnost je vypnuta, pokud je šířka průhledu nastavena na width=device-width. Prohlížeč pak vykresluje s použitím skutečné hustoty pixelů displeje [OPE11a], což může být nežádoucí kvůli vzájemným odlišnostem mezi zařízeními. Opera Mobile však podporuje nastavení proměnné target-densitydpi shodným způsobem jako Android Browser, včetně všech hodnot, kterých tato proměnná může nabývat [OPE11b]. Po nastavení target-densitydpi=medium-dpi bude Opera Mobile simulovat hustotu pixelů přibližně 160 dpi.
30
5.3 Měřítko Koncový uživatel webového rozhraní nemá pod kontrolou některé vlastnosti průhledu, jako je jeho šířka nebo hustota pixelů, ale může měnit jeho měřítko [APP11]. Změnou měřítka se rozumí přibližování a oddalování výřezu stránky, který je zobrazen v prohlížeči. Měřítko průhledu může nastavit i vývojář webového rozhraní. Lze nastavit výchozí měřítko, které se použije ihned po načtení stránky, a v některých prohlížečích lze uživatele omezit minimálním a maximálním povoleným měřítkem nebo manuální změnu měřítka zakázat. Nastavení výchozího a minimálního měřítka nezpůsobuje problémy, ale omezování maximálního měřítka, případně úplné zakazování změny měřítka by mělo být prováděno obezřetně, s ohledem na zrakově znevýhodněné uživatele. Pro stránky přizpůsobené mobilním zařízením bývá vhodné nastavit minimální měřítko na hodnotu 1.0 a zamezit tak nechtěnému přílišnému oddálení. Ovládání měřítka se provádí opět elementem meta s atributem name=“viewport“, příklad je ve zdrojovém kódu 5.4. Jednotlivé proměnné je možné nastavit takto [GOO11a]: •
Zdrojový kód 5.4: Nastavení minimálního a maximálního měřítka průhledu
5.4 Shrnutí Pro webová rozhraní, která mají být dobře použitelná na mobilních zařízeních, zejména na mobilních telefonech, je vhodné nastavit průhled následovně: •
• •
pro šířku použít device-width a ujistit se, že rozhraní je použitelné i na velmi malých rozlišeních o hraně zobrazovací oblasti přibližně 300 pixelů (tohoto se dá docílit pomocí fluidní šířky a media queries); pro hustotu pixelů použít medium-dpi, což zajistí přibližně stejnou fyzickou velikost rozhraní a jeho ovládacích prvků ve všech zkoumaných mobilních prohlížečích; pro minimální měřítko použít hodnotu 1.0. 31
Toto nastavení ukazuje zdrojový kód 5.5. Uvedené nastavení je pouze doporučení pro běžná rozhraní bez neobvyklých požadavků, pro ostatní případy mohou být vhodnější jiná nastavení. <meta name="viewport" content="width=device-width, target-densitydpi=medium-dpi, minimum-scale=1.0" />
Zdrojový kód 5.5: Nastavení průhledu pro běžná rozhraní přizpůsobená mobilním zařízením Při použití tohoto nastavení je vhodné zkontrolovat čitelnost textu i na méně kvalitních displejích (není vhodné používat příliš malý text). Na následujících stranách jsou obrázky s ukázkami různých nastavení průhledu mobilních prohlížečů. Vykreslují vždy HTML stránku s krátkým textem a obrázkem o velikosti 300 ⨉ 300 pixelů. Na každém obrázku jsou snímky obrazovky čtyř prohlížečů: •
Opera Mobile na telefonu HTC Desire, displej 252 dpi;
•
Android Browser na telefonu HTC Desire, displej 252 dpi;
•
Android Browser na telefonu HTC Wildfire, displej 125 dpi;
•
Safari na telefonu iPhone 3G, displej 163 dpi.
Vzájemný poměr velikostí snímků obrazovky je shodný se vzájemným poměrem velikostí skutečných displejů použitých telefonů. Na každém obrázku je jinak nastaven průhled: •
obrázek 5.8 ukazuje nastavení device-width a device-dpi (vypnuta simulace odlišné šířky displeje a odlišné hustoty pixelů na displeji),
•
obrázek 5.9 ukazuje nastavení device-width a medium-dpi (vypnuta simulace odlišné šířky displeje, nastavení simulace odlišné hustoty pixelů na přibližně 160 dpi; jedná se o výše doporučené nastavení, při kterém dochází k maximálnímu sjednocení vzhledu napříč prohlížeči a zařízeními).
32
Obrázek 5.6: Průhled v základním nastavení. Prohlížeče se snaží nejlépe vykreslit stránky nepřizpůsobené mobilním zařízením. Po načtení stránky se ukáže zmenšený náhled a uživatel by se měl dále po stránce pohybovat pomocí změny měřítka a posouvání průhledu (oboje lze snadno provést prstovými gesty). 33
Obrázek 5.7: Průhled s nastavením width=device-width. Prohlížeče používají skutečnou šířku displeje, nikoliv simulovanou. Stále však není sjednocena simulovaná hustota pixelů a webová stránka se tedy vykresluje v rozdílných velikostech.
34
Obrázek 5.8: Průhled s nastavením width=device-width a target-densitydpi= device-dpi. Prohlížeče používají skutečnou šířku i hustotu pixelů displeje. Toto nastavení není vhodné pro praktické použití, spíše ilustruje, že bez simulace odlišné hustoty pixelů by mobilní prohlížeče na různých zařízeních vykreslovaly značně rozdílně. 35
Obrázek 5.9: Průhled s nastavením width=device-width a target-densitydpi= medium-dpi. Prohlížeče používají skutečnou šířku displeje a simulují hustotu pixelů přibližně 160 dpi. Při tomto nastavení dochází k maximálnímu sjednocení vzhledu napříč zařízeními a prohlížeči. 36
Kapitola 6
Knihovna Mobvious
Tato kapitola popisuje softwarovou knihovnu Mobvious, která tvoří praktickou část této práce. Účelem knihovny Mobvious je zjednodušit přizpůsobení pomocí úpravy výstupu na straně serveru při použití programovacího jazyka Ruby a aplikačního rámce Ruby on Rails.
6.1 Motivace Pro usnadnění přizpůsobení na straně klienta již existují velmi schopné knihovny (např. Twitter Bootstrap zmíněný v kapitole 3). Naopak pro přizpůsobení na straně serveru mnoho významných knihoven není. Knihovny pro přizpůsobení na straně serveru jsou specifické pro konkrétní programovací jazyk, některé i pro konkrétní aplikační rámec, dochází tedy ke štěpení úsilí vývojářské komunity na větší počet menších projektů, než je tomu u přizpůsobení na straně klienta. V prostředí Ruby napomáhají s přizpůsobením na straně serveru hlavně tyto knihovny: •
Knihovna Mobylette [SCO12] detekuje přístup z mobilního zařízení a umožňuje vykreslovat dvě verze rozhraní – mobilní a klasickou. Neumožňuje více metod výběru rozhraní (např. pomocí cookie) a nepočítá s existencí samostatné verze rozhraní pro tablet.
•
Knihovny Rack Mobile Detect [ALI11], Mobile Fu [LIM12] a Is It Mobile [MYR11] pouze detekují přístup z mobilního zařízení, neposkytují funkcionalitu pro větvení kódu aplikace. Neumožňují více metod výběru rozhraní a nepočítají s existencí samostatné verze rozhraní pro tablet. (Knihovnu Rack Mobile Detect by pravděpodobně šlo nastavit, aby použila jinou verzi rozhraní pro tablety, ale pouze tak, že by se vývojář sám pokusil zformulovat regulární výraz, kterému by mělo odpovídat pole useragent HTTP hlavičky pro všechna tabletová zařízení.)
V prostředí jazyka Ruby je žádoucí vytvořit novou knihovnu, která bude schopna detekovat i přístup z tabletů, bude schopna větvení kódu a bude podporovat více metod výběru verze rozhraní než pouze heuristiku pracující s polem user-agent.
37
6.2 Funkcionalita Knihovna Mobvious má dva úkoly: •
vybrat správnou verzi rozhraní k vykreslení s možností použít různé metody výběru (rozdílné URL, cookie, detekce z HTTP hlavičky),
•
usnadnit větvení kódu při vykreslování pohledu (view).
Knihovna je rozdělena na dva moduly – hlavní modul Mobvious je odpovědný za vybrání verze rozhraní k vykreslení, rozšiřující modul Mobvious-Rails je odpovědný za větvení kódu založeném na již vybrané verzi rozhraní.
6.3 Hlavní modul (Mobvious) Hlavní modul knihovny Mobvious poskytuje detekci zařízení a výběr verze rozhraní k vykreslení. Hlavní modul není závislý na rámci Ruby on Rails, ale pouze na knihovně Rack [NEU12]. (Rack je široce používaná nízkoúrovňová knihovna jazyka Ruby pro zpracování HTTP požadavků a HTTP odpovědí.) To znamená, že knihovnu Mobvious lze pro výběr verze rozhraní použít i v jiných rámcích jazyka Ruby pro tvorbu webových aplikací (např. v rámcích Sinatra nebo Ramaze). Proces výběru verze rozhraní je implementován jako tzv. Rack middleware. To umožňuje knihovně Mobvious transparentně vstoupit do zpracování HTTP požadavku ještě před tím, než je HTTP požadavek předán webové aplikaci. Mobvious provede výběr rozhraní a uloží informaci o výsledku výběru do prostředí knihovny Rack. Aplikace nemusí při zpracování HTTP požadavku s knihovnou Mobvious nijak komunikovat, stačí přečíst již připravenou informaci o výsledku výběru rozhraní ze standarního prostředí knihovny Rack. Proces výběru verze rozhraní je nastavitelný a rozšiřitelný. Mobvious zde využívá objektově orientovaný návrhový vzor strategie [GAM95]. Každý detekční algoritmus je zapouzdřen do objektu strategie s jednoduchým, předem stanoveným rozhraním. Strategie vrátí buď identifikátor verze rozhraní, nebo hodnotu nil (hodnota nil znamená, že strategie není schopna určit verzi rozhraní). Vývojář nastaví, které strategie má knihovna Mobvious použít a v jakém pořadí. Výsledek první úspěšné strategie určuje verzi rozhraní. Pokud žádná strategie neuspěje, použije se implicitní verze rozhraní (je nastavitelná, implicitně má hodnotu desktop). Příklad konfigurace strategií je ve zdrojovém kódu 6.1, další podrobnosti o hlavním modulu lze najít v jeho dokumentaci2. 2 Přiložena k práci a dostupná z: http://rdoc.info/github/jistr/mobvious/frames
38
Mobvious.configure do |config| config.strategies = [ Mobvious::Strategies::Cookie.new([:mobile, :desktop]), Mobvious::Strategies::MobileESP.new ] end
Zdrojový kód 6.1: Příklad konfigurace strategií pro výběr verze rozhraní
6.3.1
Strategie výběru verze rozhraní
Pro výběr verze rozhraní lze použít tři strategie distribuované spolu s knihovnou. Pokud by jejich funkcionalita nebyla pro nějakou aplikaci dostačující, vývojář si může vytvořit vlastní strategie. 6.3.1.1
Cookie
Strategie Cookie umožňuje zapamatovat si volbu rozhraní přímo v prohlížeči a je určena pro manuální volbu rozhraní uživatelem. Uživatel provede manuální přepnutí verze rozhraní a strategie Cookie uloží do jeho prohlížeče cookie s informací o vybrané verzi rozhraní. Prohlížeč poté posílá cookie s každým dalším požadavkem na server a knihovna Mobvious podle něj automaticky nastaví verzi rozhraní. Pokud cookie nebylo nastaveno, strategie vrací hodnotu nil. Strategie Cookie by měla být v aplikaci použita jako vysoce prioritní, měla by mít přednost před strategiemi MobileESP a URL, protože vyjadřuje vůli uživatele. 6.3.1.2
MobileESP
Strategie MobileESP volí verzi rozhraní na základě heuristického algoritmu pracujícího nad polem user-agent HTTP hlavičky. Heuristika není součástí knihovny Mobvious, ale je poskytována samostatnou knihovnou MobileESP [HAN12]. Tato strategie má konfigurovatelnou detekční proceduru. Se strategií jsou distribuovány dvě detekční procedury: •
mobile_desktop rozlišující do kategorií mobile a desktop,
•
mobile_tablet_desktop rozlišující do kategorií mobile, tablet a desktop.
Vývojář si může vytvořit i vlastní detekční proceduru využívající heuristiku MobileESP, např. může kategorii mobile rozdělit na dvě kategorie: starší telefony a „chytré“ telefony. 39
6.3.1.3
URL
Strategie URL volí verzi rozhraní podle URL daného HTTP požadavku. Tato strategie je konfigurovatelná objektem typu Hash, který obsahuje detekční pravidla. Každé pravidlo přiřazuje nějakému regulárnímu výrazu nějakou verzi rozhraní. Všechna pravidla se vyhodno cují v pořadí jejich definice. Pokud URL daného HTTP požadavku vyhovuje regulárnímu výrazu vyhodnocovaného pravidla, strategie vybere verzi rozhraní určenou tímto pravidlem. Pokud jsou vyhodnocena všechna pravidla a přesto žádné z nich nevyhovuje, strategie vrací hodnotu nil. Se strategií je distribuovaná sada pravidel mobile_path, která přiřazuje všem URL, jejichž doménová část začíná písmenem m a tečkou, kategorii mobile. Vývojář si může definovat vlastní sady pravidel a také nastavit, aby strategie vybírala rozhraní pouze tehdy, když není v hlavičce HTTP požadavku pole referer, případně pokud toto pole vyhovuje/nevyhovuje zadanému regulárnímu výrazu.
6.4 Modul pro přizpůsobení pohledů (Mobvious-Rails) Modul Mobvious-Rails je primárně určen k rozšíření funkcionality vrstvy pohledů (view) aplikací napsaných pomocí rámce Ruby on Rails. Poskytuje pomocné metody, které mají zjednodušit a podpořit práci s informacemi poskytovanými hlavním modulem knihovny Mobvious. Metoda for_device_type umožňuje provést blok kódu (např. vykreslit kus HTML dokumentu) pouze pro vybrané typy zařízení. Metoda device_type přistupuje k prostředí knihovny Rack a vrací identifikátor verze rozhraní vybrané pro aktuální HTTP požadavek knihovnou Mobvious. Modul Mobvious-Rails tuto funkcionalitu poskytuje i pro vrstvu kontrolerů (controller) a pro skripty na straně klienta (pro jazyk CoffeeScript, který se kompiluje do jazyka JavaScript). Příklad použití v pohledu na straně serveru je ve zdrojovém kódu 6.2, příklad použití ve skriptu CoffeeScript na straně klienta je ve zdrojovém kódu 6.3. Další podrobnosti o použití modulu Mobvious-Rails lze najít v jeho dokumentaci3. <% for_device_type :mobile, :tablet do %> <%= javascript_include_tag 'touch_enhancements' %> <% end %>
Zdrojový kód 6.2: Kód pohledu Ruby on Rails využívající metodu for_device_type 3 Přiložena k práci a dostupná z: http://rdoc.info/github/jistr/mobvious-rails/frames
Zdrojový kód 6.3: Kód jazyka CoffeeScript využívající metodu for_device_type na straně klienta
6.5 Distribuce, testování, dokumentace 6.5.1
Distribuce
Knihovna Mobvious je zabalena do dvou tzv. gems (gem mobvious pro detekční jádro knihovny a gem mobvious-rails pro část, která větví kód pohledů v Ruby on Rails). Jedná se o standardní způsob balení softwarových knihoven v prostředí programovacího jazyka Ruby. Tyto dva balíčky jsou distribuovány přes systém RubyGems.org 4. Spolu s nástrojem Bundler5 tento způsob distribuce umožňuje velmi snadné načtení knihovny Mobvious do libovolného projektu (viz zdrojový kód 6.4). source :rubygems gem 'mobvious' gem 'mobvious-rails'
Zdrojový kód 6.4: Začlenění knihovny Mobvious do projektu nástrojem Bundler Oba moduly jsou šířeny pod svobodnou nerestriktivní licencí MIT [OSI12].
6.5.2
Testování
Moduly Mobvious i Mobvious-Rails jsou pokryté jednotkovými testy (unit tests). Na vývoj většinové části knihovny byla použita metodika Test Driven Development [BEC04]. (Nejprve se píší testy, které udávají, jak má software správně fungovat, a až poté se píše funkční kód tak, aby vyhovoval testům.)
6.5.3
Dokumentace
Oba moduly jsou podrobně zdokumentované. Dokumentace je přiložena k práci, přístupná vývojářům online6 a také generovatelná ze zdrojového kódu nástrojem YARD 7.
4 5 6 7
Více informací o distribuci softwarových knihoven přes RubyGems: https://rubygems.org/ Více informací o správě závislostí pomocí nástroje Bundler: http://gembundler.com/ Dokumentace je dostupná prostřednictvím dokumentačního portálu RubyDoc.info http://rdoc.info/ Více informací o tvorbě dokumentace pomocí nástroje YARD: http://yardoc.org/
41
6.6 Přínos Knihovna Mobvious je schopna zefektivnit vývoj přizpůsobivých webových rozhraní především díky svému rozšiřitelnému a prioritizovatelnému systému výběru verze rozhraní pomocí strategií. Vývojář nemusí řešit vnitřní složitost výběru verze rozhraní, stačí nakonfigurovat seznam strategií, což vývojáři ulehčí práci zejména v případě použití více způsobů výběru (více strategií) najednou. Tři základní detekční strategie distribuované spolu s knihovnou jsou konfigurovatelné a ve vzájemné kombinaci obstarají běžné scénáře pro výběr verze rozhraní. Příklady běžných konfigurací jsou ve zdrojových kódech 6.5, 6.6 a 6.7. Konfiguraci uvedenou ve zdrojovém kódu 6.6 používá portál PracujZdravě.cz (nyní v pokročilé fázi vývoje). Mobvious.configure do |config| config.strategies = [ Mobvious::Strategies::MobileESP.new ] end
Zdrojový kód 6.5: Konfigurace Mobvious: výběr verze rozhraní do kategorií mobile a desktop je proveden pomocí heuristiky nad HTTP hlavičkou. Mobvious.configure do |config| config.strategies = [ Mobvious::Strategies::Cookie.new([:mobile, :tablet, :desktop]) Mobvious::Strategies::MobileESP.new(:mobile_tablet_desktop) ] end
Zdrojový kód 6.6: Konfigurace Mobvious: výběr verze rozhraní do kategorií mobile, tablet a desktop je proveden pomocí heuristiky nad HTTP hlavičkou. Uživatel má možnost manuálně přepnout mezi verzemi rozhraní (stav přepnutí je uložen v cookie prohlížeče). Mobvious.configure do |config| config.strategies = [ Mobvious::Strategies::URL.new(:mobile_path, disable_unless_referer_matches: %r{//www.mojeaplikace.cz/}) ] end
Zdrojový kód 6.7: Konfigurace Mobvious: výběr verze rozhraní do kategorií mobile a desktop je proveden na základě URL z HTTP požadavku (jako mobilní je hodnoceno URL, jehož doménová část začíná řetězcem „m.“). Strategie je neaktivní, pokud uživatel přichází kliknutím na odkaz z externích zdrojů.
42
Kapitola 7
Závěr
Tato kapitola shrnuje nejdůležitější poznatky této diplomové práce. V práci jsem popsal, jak lze přizpůsobovat webová rozhraní různým zobrazovacím zařízením a jak připravit webové rozhraní pro správné vykreslení v mobilních prohlížečích. Implementoval jsem softwarovou knihovnu Mobvious pro přizpůsobení webových rozhraní úpravou výstupu na straně serveru. Webová uživatelská rozhraní lze přizpůsobovat různým zobrazovacím zařízením. Přizpůsobením se rozumí především úprava vzhledu, rozvržení a funkce jednotlivých prvků rozhraní, včetně výrazných změn, např. skrývání částí rozhraní nebo úpravy informačního obsahu. Přizpůsobení lze provést na straně klienta nebo na straně serveru, lze také použít oba přístupy současně. Přizpůsobení na straně klienta je realizováno kaskádovými styly a skripty jazyka JavaScript. Zařízení nebývají pevně kategorizována, spíše se používají plynulé změny vzhledu rozhraní na základě zjišťování přesných hodnot vlastností daného zařízení (např. rozlišení displeje). Přizpůsobení na straně serveru je realizováno úpravou serverového výstupu, nebo přesměrováním na samostatné aplikace pro různé typy zařízení. Na straně serveru není možné zjistit přesné hodnoty vlastností zařízení. Zařízení jsou rozdělena do předem stanovených kategorií (např. mobilní telefon, tablet, počítač) na základě (heuristických) algoritmů pracujících s hlavičkou HTTP požadavku. Softwarové knihovny pro přizpůsobení na straně klienta jsou nezávislé na programovacím jazyku použitém na straně serveru, většinu knihoven tedy lze použít v jakémkoliv projektu. Významnou knihovnou, která poskytuje dobré základy webového rozhraní přizpůsobitelného na straně klienta, je Twitter Bootstrap. Softwarové knihovny pro přizpůsobení na straně serveru jsou svázány s různými programovacími jazyky a některé i s aplikačními rámci. Jako součást práce jsem vyvinul softwarovou knihovnu Mobvious, která usnadňuje přizpůsobení na straně serveru v prostředí jazyka Ruby a aplikačního rámce Ruby on Rails. Je široce konfigurovatelná a rozšiřitelná, avšak její nastavení pro nejběžnější případy je jednoduché. Knihovna je uvolněna pod licencí MIT jako svobodný software.
43
Prohlížeče na mobilních zařízeních („chytrých“ mobilních telefonech, tabletech) používají virtuální vykreslovací plochu (tzv. viewport, česky průhled). Implicitně je průhled nastaven tak, že se přizpůsobivá webová rozhraní vykreslují nežádoucím způsobem. Pro jejich správné zobrazení je nutné upravit nastavení průhledu v hlavičce HTML dokumentu. Tyto úpravy je nutné provést vždy, bez ohledu na použitou techniku přizpůsobení. Nelze obecně určit, zda je lepší přizpůsobovat rozhraní na straně klienta, nebo na straně serveru. Oba přístupy mají různé výhody a nevýhody, nejsou vzájemně zastupitelné a v některých případech může být vhodné je kombinovat. Volbu techniky přizpůsobení je nutné zvažovat v kontextu konkrétního projektu. Současné hlavní nevýhody přizpůsobení na straně klienta (náročnost na internetové připojení a nedostačující síla jazyka CSS pro některá přizpůsobení) ustupují díky růstu kvality mobilního internetového připojení a vývoji webových standardů. Lze tedy očekávat, že přizpůsobení na straně klienta v budoucnosti nabude na významu a stane se primární technikou tvorby přizpůsobivých webových rozhraní.
44
Použité zdroje a literatura [ALI11]
ALISON, Tom. Rack-Mobile-Detect: Rack middleware for mobile device detection [online]. Github Repositories. Poslední změna 31. 7. 2011 [cit. 4. 2. 2012]. Dostupné z: https://github.com/talison/rack-mobile-detect
[APP11]
Apple Inc. Configuring the Viewport [online]. iOS Developer Library. 12. 10. 2011 [cit. 6. 12. 2011]. Dostupné z: http://developer.apple.com/library/IOs/#documentation/AppleApplications/Refere nce/SafariWebContent/UsingtheViewport/UsingtheViewport.html
[BEC04]
BECK, Kent. Programování řízené testy. Praha: Grada Publishing, 2004. Moderní programování. ISBN 80-247-0901-5.
[COU12]
COUFAL, Jaromír. Použitelnost webového rozhraní na různých typech zobrazovacího zařízení . Brno, 2012. Diplomová práce. Masarykova univerzita. Fakulta informatiky.
[CRE12]
CREMIN, Ronan. Server-Side Mobile Web Detection Used by 82% of Alexa Top 100 Sites [online]. CircleID. 11. 1. 2012 [cit. 30. 1. 2012]. Dostupné z: http://www.circleid.com/posts/20120111_analysis_of_server_side_mobile_web_d etection/
[DEV12]
DEVERIA, Alexis. When can I use... CSS3 Media Queries [online]. caniuse.com. Poslední změna 19. 3. 2012 [cit. 3. 4. 2012]. Dostupné z: http://caniuse.com/#feat=css-mediaqueries
[FIE99]
FIELDING, Roy et al. RFC 2616: Hypertext Transfer Protocol – HTTP/1.1 [online]. The Internet Engineering Task Force. 1999 [cit. 10. 1. 2012]. Dostupné z: http://tools.ietf.org/html/rfc2616
[FOW02]
FOWLER, Martin. Patterns of Enterprise Application Architecture. AddisonWesley, 2002. ISBN 978-0321127426.
[GAM95] GAMMA, Erich et al. Návrh programů pomocí vzorů: stavební kameny objektově orientovaných programů. 1. vyd. Praha: Grada, 1995. ISBN 80-247-0302-5. [GIT12]
Github, Inc. Popular Watched Repositories [online]. [cit. 10. 3. 2012]. Dostupné z: https://github.com/popular/watched
45
[GOO11a] Google Inc. Targeting Screens from Web Apps [online]. Android Developer's Guide. 1. 12. 2011 [cit. 8. 12. 2011]. Dostupné z: http://developer.android.com/guide/webapps/targeting.html [GOO11b] Google Inc. Supporting Multiple Screens [online]. Android Developer's Guide. 9. 12. 2011 [cit 14. 12. 2011]. Dostupné z: http://developer.android.com/guide/practices/screens_support.html [HAN12]
HAND, Anthony. The MobileESP Project: Easily detect mobile web site visitors [online]. Poslední změna 21. 1. 2012 [cit. 8. 2. 2012]. Dostupné z: http://mobileesp.com
[KEN11]
KENNEDY, Anthony & DE LEÓN, Inayaili. Pro CSS for High Traffic Websites. New York: Apress, 2011. ISBN 978-1-4302-3289-6.
[LIM12]
LIM, Brendan. Mobile-Fu: Automatically detect mobile requests from mobile devices in your Rails application [online]. Github Repositories. Poslední změna 3. 2. 2012 [cit. 4. 2. 2012]. Dostupné z: https://github.com/brendanlim/mobile-fu
[MAR11]
MARCOTTE, Ethan. Responsive Web Design. New York: A Book Apart, 2011. ISBN 978-0-9844425-7-7.
[MEE10]
MEEKER, Mary, DEVITT, Scott a WU, Liang. Internet Trends [online]. Morgan Stanley. 12. 4. 2010 [cit. 24. 4. 2012]. Dostupné z: http://www.morganstanley.com/institutional/techresearch/internet_trends042010.ht ml
[MYR11]
MYRON, Dave. Is_It_Mobile: Determines if a user agent is for a mobile device [online]. Github Repositories. Poslední změna 20. 4. 2011 [cit. 4. 2. 2012]. Dostupné z: https://github.com/contentfree/is_it_mobile
[NEU12]
NEUKIRCHEN, Kristian. Rack: a modular Ruby webserver interface [online]. Github Repositories. Poslední změna 10. 4. 2012 [cit. 16. 4. 2012]. Dostupné z: https://github.com/rack/rack
[NIE12]
NIELSEN, Jakob. Mobile Site vs. Full Site [online]. Jakob Nielsen's Alertbox. 10. 4. 2012 [cit. 27. 4. 2012]. Dostupné z: http://www.useit.com/alertbox/mobilevs-full-sites.html
[OPE11a]
LAWSON, Bruce. Mobile-friendly: The mobile web optimization guide [online]. Dev.Opera. 28. 6. 2011 [cit. 8. 12. 2011]. Dostupné z: http://dev.opera.com/articles/view/the-mobile-web-optimization-guide/
46
[OPE11b] BOVENS, Andreas. An introduction to meta viewport and @viewport [online]. Dev.Opera. 22. 3. 2011 [cit. 15. 12. 2011]. Dostupné z: http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-andviewport/ [OSI12]
Open Source Initative. The MIT License (MIT) : Licensing [online]. Open Source Initiative. [cit. 15. 12. 2011]. Dostupné z: http://www.opensource.org/licenses/MIT
[SCG12]
StatCounter. Top 9 Mobile Browsers in Czech Republic from Jan 2011 to Apr 2012 [online]. StatCounter Global Stats. [cit. 10. 5. 2012]. Dostupné z: http://gs.statcounter.com/#mobile_browser-CZ-monthly-201101-201204
[SCO12]
SCOLARI, Tiago. Mobylette: Mobile request handling for Ruby on Rails [online]. Github Repositories. Poslední změna 26. 1. 2012 [cit. 4. 2. 2012]. Dostupné z: https://github.com/tscolari/mobylette
Přehled elektronických příloh Součástí práce je softwarová knihovna Mobvious. Je přiložen její zdrojový kód, dokumentace a gem balíčky, vše je rozděleno podle modulů: •
hlavní modul Mobvious, obsahující detekční funkcionalitu,
•
modul Mobvious-Rails, obsahující funkcionalitu pro větvení kódu aplikace.
Aktuální verze všech příloh je možné nalézt online (viz poznámky pod čarou u jednotlivých příloh). Struktura příloh: •
dokumentace/mobvious/frames.html Dokumentace modulu Mobvious.8
•
dokumentace/mobvious-rails/frames.html Dokumentace modulu Mobvious-Rails.8
•
gem_balicky Adresář s distribuovatelnými balíčky modulů Mobvious a Mobvious-Rails.9
•
zdrojovy_kod/mobvious Adresář se zdrojovým kódem modulu Mobvious.10
•
zdrojovy_kod/mobvious-rails Adresář se zdrojovým kódem modulu Mobvious-Rails.10
8 Online verze dokumentace jsou dostupné z: http://rdoc.info/github/jistr/mobvious/master/frames http://rdoc.info/github/jistr/mobvious-rails/master/frames 9 Nejnovější verze balíčků jsou dostupné z: https://rubygems.org/gems/mobvious https://rubygems.org/gems/mobvious-rails 10 Aktuální zdrojový kód v uživatelsky přívětivém rozhraní je dostupný z: https://github.com/jistr/mobvious https://github.com/jistr/mobvious-rails
