<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>
<channel>
	<title>AspectWorks &#187; Webdesign</title>
	<atom:link href="http://www.aspectworks.com/category/webdesign/feed" rel="self" type="application/rss+xml" />
	<link>http://www.aspectworks.com</link>
	<description>Vyvíjíme chytré webové aplikace pro střední a velké podniky</description>
	<lastBuildDate>Thu, 26 Jan 2012 14:25:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>3 důležitá nastavení Photoshopu</title>
		<link>http://www.aspectworks.com/2010/12/3-dulezita-nastaveni-photoshopu</link>
		<comments>http://www.aspectworks.com/2010/12/3-dulezita-nastaveni-photoshopu#comments</comments>
		<pubDate>Fri, 03 Dec 2010 16:53:12 +0000</pubDate>
		<dc:creator>Richard Šerý</dc:creator>
				<category><![CDATA[Homepage]]></category>
		<category><![CDATA[Jen tak]]></category>
		<category><![CDATA[Webdesign]]></category>
		<guid isPermaLink="false">http://www.aspectworks.com/cs/blog/?p=893</guid>
		<description><![CDATA[Děláte-li grafický návrh webu v Photoshopu, měli byste dodržet několik základních pravidel. Proč? Pokud je dodržíte, bude kodér schopen větší část Vašeho návrhu převést na web s přesností na pixel.<a href="http://www.aspectworks.com/2010/12/3-dulezita-nastaveni-photoshopu" class="moreLink">více&#160;»</a>]]></description>
			<content:encoded><![CDATA[<p>Děláte-li grafický návrh webu v Photoshopu, měli byste dodržet několik základních pravidel. Proč? Pokud je dodržíte, bude kodér schopen větší část Vašeho návrhu převést na web s přesností na pixel. A to se vyplatí.<span id="more-893"></span></p>
<h3>Pravidlo první: 96 DPI</h3>
<p>Většina návštěvníků současných webů má na počítači nastaveno &#8222;rozlišení&#8220; 96 DPI. Nic na tom nezmění fakt, že tato hodnota DPI je naprostý nesmysl (viz <a href="http://www.unleash.com/knpepper/dpi/">www.unleash.com/knpepper/dpi/</a>). Pro nás je podstatné, že když si nastavíme v Photoshopu 96 dpi, velikost písma v typografických bodech (pt) bude odpovídat velikosti písma v pt na monitoru. Jinými slovy, když grafik nastaví v návrhu velikost písma na 9pt a kodér nastaví v CSS také 9pt, bude písmo ve stránce stejně velké jako v grafickém návrhu.</p>
<p><img src="http://www.aspectworks.com/wp-content/uploads/2010/12/photoshop1.png" alt="" title="Obr. 1" width="652" height="341" class="alignnone size-full wp-image-894" /></p>
<h3>Pravidlo druhé: 960 x 580 px</h3>
<p>Velikost plátna, na kterém budete grafický návrh dělat, nastavte na 960 x 580 px. Proč zrovna takto podivné číslo? Při tomto rozměru stránky je vysoká pravděpodobnost, že návštěvník uvidí vše. Jestliže byste udělali návrh větší, část obsahu by byla skryta &#8222;za ohybem&#8220; stránky (viz mírně zastaralý článek <a href="http://mentalized.net/journal/2006/10/24/browser_size_does_matter_actual_numbers/">Browser size does matter &#8211; Actual numbers</a> &#8211; rozlišení 1024&#215;768 již zdaleka není tak rozšířené jak článek uvádí).<br />
Při rozlišení 1024&#215;768 byste si mohli dovolit šířku až 1000 px, ale 960px je číslo snadno dělitelné třemi, a mřížka se třemi, šesti či dvanácti sloupci je častá a oblíbená.</p>
<p>Jakmile navrhnete základ pro rozlišení 960 x 580 px, nezapomeňte plátno zvětšit a namalovat, jak má stránka vypadat ve větším rozlišení.</p>
<p><img src="http://www.aspectworks.com/wp-content/uploads/2010/12/photoshop-2.png" alt="" title="Obr. 2" width="652" height="341" class="alignnone size-full wp-image-895" /></p>
<h3>Pravidlo třetí: písmo</h3>
<p>Donedávna na webu jednoznačně platilo, že můžete použít jakékoli písmo, pokud je to Helvetica (případně Arial, to je totéž). Ačkoli dnes to už tak úplně neplatí, stejně zvažte, jestli u ní nezůstat. Je to písmo čitelné a nezabere tolik místa jako Tahoma.<br />
Na hladký text nepoužívejte patkové písmo, jeho čitelnost je na monitoru horší, nepoužívejte ani kurzívu (kromě horší čitelnosti přináší i technické obtíže) a podtržení používejte výhradně na označení odkazů.</p>
<p>Co se týče velikosti písma, dejte pozor na čitelnost. Velikost 8pt je na obrazovce pro mnoho lidí na dolní hranici čitelnosti, nikdy nedělejte nápisy menší. </p>
<p>Pro menší písma doporučuji vypnout antialiasing, připraví Vás to na tu horší variantu zobrazení. Některé obstarožní prohlížeče totiž antialiasing nemají vůbec, jiné zase pro lepší čitelnost u menších velikostí písma antialiasing vypínají. Uděláte o tak, že nastavíte antialiasing na &#8222;žádný&#8220;, případně &#8222;none&#8220;.</p>
<p><img src="http://www.aspectworks.com/wp-content/uploads/2010/12/photoshop-3.png" alt="" title="photoshop-3" width="472" height="119" class="alignnone size-full wp-image-896" /></p>
]]></content:encoded>
			<wfw:commentRss>http://www.aspectworks.com/2010/12/3-dulezita-nastaveni-photoshopu/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>GUI Design: Vzhled</title>
		<link>http://www.aspectworks.com/2010/11/gui-design-vzhled</link>
		<comments>http://www.aspectworks.com/2010/11/gui-design-vzhled#comments</comments>
		<pubDate>Tue, 23 Nov 2010 17:03:45 +0000</pubDate>
		<dc:creator>Richard Šerý</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[Homepage]]></category>
		<category><![CDATA[Webdesign]]></category>
		<guid isPermaLink="false">http://www.aspectworks.com/cs/blog/?p=502</guid>
		<description><![CDATA[Vzhled prodává. O tom žádná. Na druhou stranu, neexistuje žádná triviální rovnice typu &#8222;krásný produkt = obchodní úspěch&#8220;. Celá věc je složitější a k tomu, abyste mohli vzhled použít jako<a href="http://www.aspectworks.com/2010/11/gui-design-vzhled" class="moreLink">více&#160;»</a>]]></description>
			<content:encoded><![CDATA[<p>Vzhled prodává. O tom žádná. Na druhou stranu, neexistuje žádná triviální rovnice typu &#8222;krásný produkt = obchodní úspěch&#8220;. Celá věc je složitější a k tomu, abyste mohli vzhled použít jako nástroj, potřebujete o něm určité věci vědět.<br />
<span id="more-502"></span></p>
<p><a href="http://www.flickr.com/photos/dimmerswitch/3519505747/" title="Bulldog Pup by Dimmerswitch, on Flickr" class="imageRight"><img src="http://farm4.static.flickr.com/3656/3519505747_21cd4066c7_m.jpg" width="180" height="240" alt="Bulldog Pup" /></a></p>
<h3>Vzhled je důležitý</h3>
<p>Ačkoli vzhled je zdánlivě jen &#8222;pozlátko&#8220;, pro uživatele je velice důležitý. Nejenže může mít značný vliv na použitelnost (tlačítka s 3d efektem jsou použitelnější než tlačítka bez něj), ale dává také signál, do jaké míry je tvůrce schopný, jak dokáže dbát na detaily a do jaké míry dokáže chápat potřeby zákazníka. Zvláště u komerčních a propagačních webů je třeba si uvědomit, že zákazníci se rozhodují především podvědomím, takže solidní vzhled může zapůsobit účinněji než sebelepší argumenty.</p>
<h3>Vztah formy a funkce</h3>
<p>Existují dvě hlavní cesty, jakými se designér může ubírat při návrhu: &#8222;foma následuje funkci&#8220; a &#8222;funkce následuje formu&#8220;. Ačkoli v jiných oborech designu je forma trochu složitější záležitost, v případě GUI designu se omezuje téměř výhradně na vzhled.</p>
<ul class="bigDots">
<li class="marginBottom">Strategie &#8222;<em>forma následuje funkci</em>&#8220; vede k tomu, že vzhled GUI podtrhuje jeho funkčnost. Funkce je to důležité, vzhled tu je zejména od toho, aby zvýšil použitelnost. Tato strategie je vhodná zejména pro návrh užitkového softwaru &#8211; tabulek, administračních rozhraní, formulářů.</li>
<li class="marginBottom">Strategie &#8222;<em>funkce následuje formu</em>&#8220; je vhodná tam, kde chceme hrát na city, kde nejdůležitější je prožitek uživatele a funkcionalita je až druhořadá. Pozor, neznamená to že by GUI nemělo být použitelné. Vzhled však v takovém případě není pouhým prostředkem ke zvýšení použitelnosti, je nástrojem, který tvoří mezi uživatelem a produktem citový vztah. Tato strategie je vhodná hlavně tam, kde chceme zapůsobit &#8211; třeba u reklamních a uměleckých webů.</li>
</ul>
<h3>Krása není vždy cílem</h3>
<p>Mnoho lidí volně zaměňuje pojmy jako &#8222;design&#8220;, &#8222;vzhled&#8220; a &#8222;krása&#8220;. Ve skutečnosti dobrý design nemusí být vždy krásný. Než začneme navrhovat vzhled, měli bychom mít velmi jasno v tom, kdo budou uživatelé a o jakou estetiku vlastně stojí. Příliš krásné GUI může uživatele odradit, pokud očekávají levný produkt. Jestliže jsou všechny produkty konkurence krásné, můžete šokovat uživatele zdánlivou ošklivostí a tím upoutat jeho pozornost. Pokud uživatel očekává standardní administrační rozhraní, je často lepší přidržet se existujících konvencí, než zavádět vlastní normy, byť i lepší. Dokonce i ošklivý produkt se může prosadit, je-li užitečný. Na druhou stranu, lidé se rádi obklopují krásnými věcmi, takže pokud tomu nic nebrání, mělo by být pěkné elegantní GUI samozřejmostí.</p>
<h3>Opravdu rozumíte grafice?</h3>
<p>Častým nešvarem je přesvědčení, že &#8222;každý je tak trochu grafik&#8220;. V mateřské škole se přeci malovat učí každý. Ale zodpovězte si otázky: opravdu víte jak pracovat s negativním prostorem? Znáte aspoň základní typografická pravidla? Dokážete kombinovat barvy tak, abyste navodili určitý pocit? Dokážete vyjmenovat aspoň 5 způsobů, jak dát vzdálené prvky stránky navzájem do souvislosti? Rozumíte grafické rovnováze a vizuální hierarchii? Pokud ne, nesnažte se říkat grafikovi, jak má dělat svoji práci, nebo snad dokonce patlat grafický návrh sami. A rozhodně si ověřte, zda váš grafik odpovědi na výše uvedené otázky zná.</p>
<h3>Nešikanuje vás grafik?</h3>
<p>Častým problémem grafiků je komunikace. Zákazník přijde s nějakým nápadem, přednese ho grafikovi, grafik obrátí oči v sloup a nápad bez váhání smete ze stolu jako naprostý nesmysl. Ano, jistě, obvykle to naprostý nesmysl je, ale i nesmyslný požadavek může mít zdravé jádro. Neříkejte grafikovi jak má co vypadat, raději mu řekněte, čeho chcete dosáhnout. Když máte dobrého analytika nebo projektového managera, může sloužit jako &#8222;překladatel&#8220; mezi zákazníkem a grafikem. A najdou se i sveřepí grafici, kteří razí svoji &#8222;uměleckou&#8220; vizi i navzdory marketingovým záměrům zákazníka. Ale <a href="http://www.webdesignerdepot.com/2009/09/the-difference-between-art-and-design/">design a umění, to není totéž</a>. Jestliže se nemůžete shodnout, udělejte test (např. A/B testy na tohle fungují dobře).</p>
<h3>Design který prodává a design který funguje</h3>
<p>V marketingu je notoricky známé pravidlo, že každý zákazník jsou vlastně dvě osoby: jedna produkt kupuje a druhá ho používá. Chcete-li jen &#8222;prodat a zmizet&#8220;, volte strategii &#8222;funkce následuje formu&#8220;, investujte do vzhledu a propagace. Chcete-li však mít loajální zákazníky, musíte se zaměřit i na druhou část jejich osoby &#8211; na tu, která Vaši aplikaci používá. A pozor, tohle rozhodnutí by neměl dělat grafik, jde o marketingovou strategii, která by měla být součástí grafikova zadání.</p>
<h3>Pravidla grafického designu</h3>
<p><a href="http://www.flickr.com/photos/johncohen/10421466/" class="imageRight" title="Mission Beauty Shop by John Althouse Cohen, on Flickr"><img src="http://farm1.static.flickr.com/8/10421466_a0d7392d89_m.jpg" width="240" height="180" alt="Mission Beauty Shop" /></a></p>
<p>Ať už se sami pouštíte do grafického designu, nebo se snažíte nějak řídit grafika, je potřeba chápat určité principy. Pokusil jsem se alespoň některá pravidla shrnout do bodů &#8211; rozumíte-li designu, posuďte, jak se mi to podařilo a můžete mi to řádně osolit v komentářích.</p>
<dl class="bigDots">
<dt>Nebojte se rozhodnutí</dt>
<dd class="marginBottom">Někdy bolí, protože musíte zahodit to, co se vám líbí, na čem vám záleží, nebo na čem jste tvrdě pracovali. Je však třeba poznat možnosti a pak se rozhodnout, o tom je design.</dd>
<dt>Jednoduchost a komplexnost</dt>
<dd class="marginBottom"> Jednoduchost a komplexnost jsou dvě strany téže mince. Jednoduchost bez komplexnosti působí primitivně, komplexnost bez jednoduchosti zmateně. Ukazujte uživateli raději tu jednoduchou stranu.</dd>
<dt>Sdělte příběh</dt>
<dd class="marginBottom">Bez příběhu nepředáte myšlenku.</dd>
<dt>Odstraňte zbytečnosti</dt>
<dd class="marginBottom"><a href="http://cs.wikipedia.org/wiki/Occamova_b%C5%99itva">Ockhamova břitva</a> je imaginární nástroj, kterým ořezáváme vše, co není nezbytně nutné, dokud nevynikne pravá, jednoduchá podstata. Když design nefunguje, zkuste se nejprve zbavit všeho zbytečného.</dd>
<dt>Dbejte na konzistenci</dt>
<dd class="marginBottom">Udržet jednotu výrazu, to je stálý boj, který nikdy nesmí polevit, jinak ho prohrajete.</dd>
<dt>Vytvářejte kontrast</dt>
<dd class="marginBottom">Hledejte kontrast všude &#8211; v barvách, písmu, významech, rozmístění prvků, obrazech&#8230; Kontrast je klíčový, bez něj to nejde.</dd>
<dt>Dva, maximálně tři</dt>
<dd class="marginBottom">To je vhodný počet druhů písma a barev. Dva druhy jsou nutné k vyvolání kontrastu. Tři použijte jen tehdy, pokud opravdu dobře víte, co děláte.</dd>
<dt>Pět až sedm</dt>
<dd class="marginBottom">Tolik věcí pojme krátkodobá paměť uživatele. To je vhodný počet prvků v seznamu, položek menu, ovládacích ikon, upoutávek, tlačítek formuláře atd.</dd>
<dt>Upoutejte pozornost</dt>
<dd class="marginBottom">Fungují zde staré principy &#8211; útok na kořist a útěk před šelmou, společenská komunikace, sex, potrava. Primitivní mechanismy jsou nejsilnější. Pohyb, oči, obličej, lidské tělo, ovoce, rudá barva &#8211; to vše jsou silné stimuly, jejichž účinnost zajistila evoluce.</dd>
<dt>Zajistěte vizuální hierarchii</dt>
<dd class="marginBottom">Upoutejte oko diváka na jedno místo, ale pak ho veďte dál, abyste předali celé sdělení.</dd>
<dt>Využijte negativní prostor</dt>
<dd class="marginBottom">Nebojte se prázdného místa. Nic tak nezvýrazní dominantu stránky jako spousta prázdného prostoru kolem. Dívejte se na tvar prázdného prostoru a využijte ho.</dd>
<dt>Cit je důležitý</dt>
<dd class="marginBottom">Můžete znát stovky pravidel dobrého designu, ale bez citu je nedokážete využít. Dejte na svoji intuici a nebojte se porušit pravidlo, pokud se mu váš cit vzpírá.</dd>
<dt>Pravidla jsou důležitá</dt>
<dd class="marginBottom">Pravidlo, které neznáte, nemůžete ani použít ani porušit. Učte se a hledejte pravidla, používejte je, diskutujte a pište o nich. Zlepší to vaše chápání designu.</dd>
<dt>Vdechněte svému designu život</dt>
<dd class="marginBottom">Symetrie je nuda a nuda je smrt. Vytvořte pohyb, nerovnováhu, napětí. </dd>
<dt>Nebojte se chyb</dt>
<dd class="marginBottom">Dělá je každý. Obhajujte svoje názory, dokud se neprokáží jako chybné, jinak bude váš design bez výrazu. Ale když odhalíte chybu, postavte se k ní čelem.</dd>
<dt>Poučte se z chyb</dt>
<dd class="marginBottom">Jen hlupák opakuje stejné chyby stále znovu. Nebojte se přiznat svoji chybu, protože jen takovou chybu, kterou si přiznáte a pochopíte, už nebudete opakovat.</dd>
<dt>Snažte se o dokonalost</dt>
<dd class="marginBottom">Bez snahy o dokonalost je design jen rutinou. Takový design postrádá jiskru a divák to pozná.</dd>
</dl>
<h3>Závěrem</h3>
<p>Grafika je důležitou součástí návrhu GUI &#8211; může produktu velmi pomoci, ale může také hodně zkazit. Stát se dobrým grafikem, to je dlouhá cesta. Podobá se tomu, co popisují zenoví mistři &#8211; jen ten kdo grafiku dělá stále a vytrvale, neustále se snaží zlepšovat, dojde k jednoduchosti úplných základů.<br />
Pokud se po této cestě nechcete vydat sami, nezbyde vám, než důvěřovat těm, kteří po ní jdou. V takovém případě se ale snažte být tak chytří, abyste jim nestáli v cestě.</p>
<p><a href="/cs/blog/2009/10/gui-design-pouzitelnost/">Předchozí díl: Použitelnost</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.aspectworks.com/2010/11/gui-design-vzhled/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Hledání země nezemě</title>
		<link>http://www.aspectworks.com/2009/10/hledani-zeme-nezeme</link>
		<comments>http://www.aspectworks.com/2009/10/hledani-zeme-nezeme#comments</comments>
		<pubDate>Mon, 26 Oct 2009 11:49:24 +0000</pubDate>
		<dc:creator>Tomáš Piňos</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[Webdesign]]></category>
		<guid isPermaLink="false">http://www.aspectworks.com/cs/blog/?p=297</guid>
		<description><![CDATA[Kódy zemí, měn, bank, názvy měst a vesnic, poštovní směrovací čísla&#8230; Většina aplikací pracuje s nějakými číselníky. Kde ale vzít jejich hodnoty a nekrást? V tomto blogu chci projít a<a href="http://www.aspectworks.com/2009/10/hledani-zeme-nezeme" class="moreLink">více&#160;»</a>]]></description>
			<content:encoded><![CDATA[<p>Kódy zemí, měn, bank, názvy měst a vesnic, poštovní směrovací čísla&#8230; Většina aplikací pracuje s nějakými číselníky. Kde ale vzít jejich hodnoty a nekrást? V tomto blogu chci projít a stručně charakterizovat zdroje, které jsem pro potřeby nedávného projektu našel a které se mi osvědčily. </p>
<p><span id="more-2552"></span></p>
<p>Zkusme napřed pojmenovat možné způsoby, jak získat data pro číselníky na novém projektu.</p>
<ul>
<li><em>Přebírání číselníků ze staršího projektu, programu, firmy, …</em> &#8211; asi nejrozšířenější praktikou je vzít data tam, kde už jsme je jednou připravili. Může to být jiný projekt, naše internetové bankovnictví, nebo třeba náš účetní systém. Je to správné a legální? Dá se takový postup snadno zopakovat? Jak řešit aktualizace dat?</li>
<li><em>Placený zdroj dat</em> – některé číselníky si můžeme koupit. Existují dodavatelé, kteří se na přípravu a aktualizaci číselníkových dat specializují.</li>
<li><em>Volně dostupné zdroje dat na internetu</em> – mnohé číselníky neobsahují data, o kterých by se dalo mluvit jako o cenných. Náročný bývá spíše způsob, jak jejich hodnoty zkompilovat a udržovat. Proto je přirozená myšlenka hledat pro číselníky volně dostupné zdroje dat. Existuje jich mnoho, na některé se zaměřím.</li>
</ul>
<p>Ve zbytku příspěvku se budu věnovat právě několika dostupným zdrojům dat pro číselníky zemí, bank, měn, měst, ulic, PSČ a adres.</p>
<h3>Země</h3>
<p>Pro číselník zemí existuje standard <a href="http://www.iso.org/iso/country_codes/background_on_iso_3166/what_is_iso_3166.htm">ISO 3166</a>. Standard má tři části, číselníku zemí odpovídá ISO 3166-1 (dvouznakové kódy, pro Českou republiku je to ČR). Další dvě části standardu popisují jemnější členění zemí a země vyřazené z číselníku. Na typickém projektu není důvod tento standard nepoužít.</p>
<ul>
<li><a href="http://www.iso.org/iso/country_codes/iso_3166_code_lists.htm"><em>ISO</em></a> &#8211; Přímo na stránkách ISO organizace se dají najít číselníky zemí v angličtině a francouzštině. Bohužel jen v upper case.
</li>
<li><a href="http://www.czso.cz/csu/klasifik.nsf/i/ciselnik_zemi_(czem)"><em>Český statistický úřad</em></a> &#8211; Na stránkách ČSÚ je možné volně stáhnout xls soubor s daty odpovídajícími normě ISO 3166-1. Číselník obsahuje kódy předepsané standardem, plný a zkrácený český název a plný anglický název.
</li>
</ul>
<p>Na posledním projektu jsme použili data z ČSÚ. Xls soubor jsme zkonvertovali do csv a pak už jej jednoduchým skriptem transformovali do formátu, kterým plníme databázi. To je postup, který se dá snadno zopakovat a v případě potřeby i automatizovat. I když to asi v případě číselníku zemí není nutné. </p>
<h3>Banky a měny</h3>
<p>Dalšími typickými číselníky jsou seznamy bank registrovaných v České republice a seznam měn. Pro měny opět existuje ISO standard – <a href="http://www.currency-iso.org">ISO 4217</a>. Definuje tříznakové kódy, kde první dva znaky odpovídají číselníku zemí definovanému standardem ISO 3166-1. Nevidím důvod, proč se i pro číselník měn nepřidržet tohoto standardu (pokud potřebujeme všechny) .</p>
<ul>
<li><a href="http://www.czso.cz/csu/2004edicniplan.nsf/p/0010-04"><em>Český statistický úřad</em></a> &#8211; ČSÚ je dobrým zdrojem i pro číselník měn. Na uvedeném odkazu se dá specifikace stáhnout jako xls nebo pdf soubor. Xls soubor je snado převoditelný do csv, které už se dá vhodným skriptem rychle zpracovat.
</li>
<li><a href="http://www.cnb.cz/m2export/sites/www.cnb.cz/cs/platebni_styk/ucty_kody_bank/download/kody_bank_CR_127.pdf"><em>Česká národní banka</em></a> &#8211; Obsahově správným zdrojem dat pro číselník bank je určitě ČNB. Ke stáhnutí je zde k dispozici pdf soubor, který se zpracovává hůř, ale možné to je.
</li>
</ul>
<p>Nabízí se i možnost „převzít“ číselník bank z vašeho oblíbeného <em>internetového bankovnictví</em>. Otázkou je, nakolik je to správné a kolik toho vaše svědomí snese. </p>
<h3>Města, ulice, PSČ, adresy, &#8230;</h3>
<p>Poslední skupinou číselníků, které se budu věnovat, jsou města, ulice, PSČ a adresy. Od těchto číselníků si typicky slibujeme provázanost, aktuálnost dat a také možnost aktualizovatelnosti dat. V bankovním prostředí je častý požadavek na ověření existence a správnosti adresy (např. u scoring systémů, kde je zákazník s existující adresou jistě důvěryhodnější).</p>
<ul>
<li><a href="http://www.cpost.cz/cz/sluzby/prodej-na-postach/prodej-datovych-souboru-id293"><em>Česká pošta</em></a> &#8211; Česká pošta nabízí placený číselník adres. Zmiňuji ho jako alternativu k UIR-ADR (viz níže), ale protože jsem na stránkách pošty nenašel možnost stažení vzorku dat, jeho hodnocení se vyhnu.</li>
<li><em>Český statistický úřad</em> &#8211; Několik číselníků měst a PSČ nabízí i ČSÚ. Vždy ale plní nějaký statistický účel (např. sčítání obyvatelstva) a jako obecné číselníky se mi neosvědčily.</li>
<li><a href="http://forms.mpsv.cz/uir"><em>UIR-ADR: Územně identifikační registr adres</em></a> &#8211; Překvapivě kvalitní a volně dostupnou databázi adres spravuje česká státní správa, konkrétně Ministerstvo práce a sociálních věcí.</li>
</ul>
<div class="imageRight">
<a href="http://www.aspectworks.com/sluzby/outsourcing/118-revision-4" rel="attachment wp-att-321"><img src="http://www.aspectworks.com/wp-content/uploads/2009/10/uiradr-model-200x192.jpg" alt="UIR-ADR - datový model" width="200" height="192" class="aligncenter size-thumbnail wp-image-321" /></a></p>
<div>
Datový model registru UIR-ADR<br />
(zjednodušený, pouze některé tabulky)
</div>
</div>
<p>Registr UIR-ADR toho nabízí mnoho:</p>
<ul>
<li>Typy dat – UIR-ADR obsahuje číselníky okresů, obcí, částí obce, ulic, stavebních objektů, adresních míst, adresních pošt, pražských obvodů,  městských částí/městských obvodů, oblastí, krajů, správních obvodů a některé další typy dat.</li>
<li>Prohlížení registru na webu – jednoduchá webová aplikace pro prohlížení registru.<br />
Webová služba pro ověřování adres v registru – UIR-ADR poskytuje webovou službu pro ověřování adres. Služba je volně dostupná, ale vyžaduje nejprve registraci.</li>
<li>Možnost udržovat si vlastní kopii registru – zdarma si lze objednat CD s instalací UIR-ADR. Instalace znamená vytvoření instance MS SQL s daty a windows prohlížečkou, nebo inicializaci dat v jiné databázi. CD obsahuje data registru v šesti různých databázových formátech (dBase, FoxPro, Oracle, MS SQL Server, SQL_92, CSV).</li>
<li>Aktualizace registru zdarma – v případě udržování vlastní kopie jsou volně k dispozici aktualizace registru (údajně připravované 1x týdně, ale to jsem neověřoval).</li>
</ul>
<p>Na novém projektu bych rozhodně zvolil vlastní kopii UIR-ADR. Vím o několika bankách a dalších firmách, které registr používají. Standardizace dat podle registru UIR-ADR je trend, takže je tu dobrá šance, že v případě integrace a výměny adresních dat budete mít štěstí a adresy půjdou snadno porovnávat. Poslední poznámka se týká ověřování adres – nesmíme zapomenout, že zde neplatí <a href="//en.wikipedia.org/wiki/Closed_world_assumption">předpoklad uzavřeného světa</a>. Absence adresy v registru ještě nemusí zaručeně znamenat, že adresa skutečně neexistuje.</p>
<h3>Shrnutí</h3>
<p>Příspěvek si kladl za cíl nabídnou několik osvědčených zdrojů dat pro různé číselníky. Řešili jste někdy na projektu zdroje dat pro číselníky? Jakou cestou jste se vydali? Podělte se o své zkušenosti v diskuzi pod článkem.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.aspectworks.com/2009/10/hledani-zeme-nezeme/feed</wfw:commentRss>
		<slash:comments>15</slash:comments>
		</item>
		<item>
		<title>GUI Design: Použitelnost</title>
		<link>http://www.aspectworks.com/2009/10/gui-design-pouzitelnost</link>
		<comments>http://www.aspectworks.com/2009/10/gui-design-pouzitelnost#comments</comments>
		<pubDate>Mon, 19 Oct 2009 13:30:25 +0000</pubDate>
		<dc:creator>Richard Šerý</dc:creator>
				<category><![CDATA[Webdesign]]></category>
		<guid isPermaLink="false">http://www.aspectworks.com/cs/blog/?p=278</guid>
		<description><![CDATA[Není to tak dávno, co vývojáři webových aplikací zápasili s problémem, jak vůbec vytvořit GUI které by fungovalo. Díky postupující standardizaci se začátkem 21. století podařilo tyto potíže překonat a<a href="http://www.aspectworks.com/2009/10/gui-design-pouzitelnost" class="moreLink">více&#160;»</a>]]></description>
			<content:encoded><![CDATA[<p>Není to tak dávno, co vývojáři webových aplikací zápasili s problémem, jak vůbec vytvořit GUI které by fungovalo. Díky postupující standardizaci se začátkem 21. století podařilo tyto potíže překonat a do ohniska zájmu se dostal druhý stupeň &#8222;pyramidy potřeb&#8220; &#8211; použitelnost. Móda použitelnosti má ale i svoje stinné stránky &#8211; pro mnoho lidí jde víceméně o buzzword aniž by si pod tím dokázali představit něco konkrétního.<br />
<span id="more-2551"></span></p>
<div class="imageRight"><a href="http://www.flickr.com/photos/nao-cha/29696004/" title="Llama 2 by nao-cha, on Flickr"><img src="http://farm1.static.flickr.com/22/29696004_5bc6891117_m.jpg" width="160" height="240" alt="Llama 2" /></a></div>
<h3>Použitelné &#8211; ale pro koho?</h3>
<p>Když vyrábíme GUI, je třeba se vždy ptát, pro koho je určeno a pro koho naopak není.</p>
<p>Většinou nic nezkazíme, když GUI vyrobíme tak aby ho snadno pochopili a používali i hloupí či nezkušení uživatelé. V takovém případě totiž chytrý uživatel nemusí přemýšlet nad ovládáním a může svou chytrost zaměřit jiným směrem, například soustředit se na činnost kterou dělá.</p>
<p>Jsou ale uživatelé, kteří mají na GUI vyšší nároky než běžná lama. Nevadí jim učit se věci, např. klávesové zkratky a různé zvláštní funkce, pokud to významně zefektivní jejich práci. Můžeme tedy narazit na dilema &#8211; udělat ovládání spíše jednoduché, nebo raději efektivní? A tady je pak nutné vědět co nejvíce o uživatelích, abychom mohli udělat správné rozhodnutí.</p>
<h3>Jednoduchost</h3>
<p>Důležitým, ale nikoli jediným, prostředkem jak zlepšit GUI je jeho zjednodušení. Jednoduchost je na první pohled docela jednoduchá věc, ve skutečnosti však jde o poměrně složitou problematiku, která má svoje pravidla i designové vzory.</p>
<div class="imageLeft"><a href="http://www.flickr.com/photos/maxbraun/2076484890/in/set-1416196/"><img src="http://www.aspectworks.com/cs/blog/wp-content/uploads/2009/10/2076484890_33581bb051-200x200.jpg" alt="Simplicity" title="Simplicity" width="200" height="200" class="alignright size-thumbnail wp-image-281" /></a>
<div xmlns:cc="http://creativecommons.org/ns#" about="http://www.flickr.com/photos/maxbraun/2076484890/"><a rel="cc:attributionURL" href="http://www.flickr.com/photos/maxbraun/">zdroj: flickr</a> / <a rel="license" href="http://creativecommons.org/licenses/by-sa/2.0/">CC BY-SA 2.0</a></div>
</div>
<p>GUI můžeme zjednodušit mnoha různými způsoby &#8211; skrýt nebo zmenšit méně používané ovládací prvky, zavést silné konvence a konzistentně je dodržovat, ubírat na počtech (např. redukovat počet účaří, barev, tlačítek, typů písma, dominant atd.), zbavit se rušivých elementů, pracovat s archetypy které již uživatel má v hlavě&#8230; Důležitým prvkem jednoduchosti je také nenutit uživatele k rozhodnutí tam, kde to není nezbytně nutné, slovy klasika &#8222;zbavit ho tyranie malých rozhodnutí&#8220;.</p>
<p>Albert Einstein vyslovil velkou pravdu: &#8222;Všechno by se mělo dělat nejjednoduší, jak jen to jde, ale ani o píď jednodušší.&#8220; Je tomu tak i v designu, jednoduchost a složitost jsou dvě strany téže mince a nemohou existovat odděleně. Veškeré naše konání a myšlení by mělo být prostoupeno snahou o jednoduchost, ale také vědomím a pochopením komplexnosti, která je za jednoduchostí skryta.</p>
<h3>Je počítač nástroj nebo asistent?</h3>
<p>V konstrukci uživatelských rozhraní lze rozeznat dva poměrně zřetelné trendy. První považuje počítač za bezduchý nástroj ovládaný kvalifikovaným uživatelem. Druhý trend považuje počítač za &#8222;asistenta&#8220;, ktreý dokáže rozpoznat činnost uživatele a značně mu ji usnadnit.</p>
<h3>Počítač jako nástroj</h3>
<p>Při tomto přístupu je důležité, aby funkce byly co nejjednoduší, snadno nalezitelné a spolehlivě fungující. Vývojář UI má tři hlavní úkoly:</p>
<ol>
<li>vytvořit logický a snadno pochopitelný systém, který uživateli umožní snadno najít a spustit kteroukoli funkci</li>
<li>zajistit, aby funkce byly tak jednoduché, aby je uživatel snadno pochopil do všech důsledků (zákon nejmenšího překvapení)</li>
<li>zjistit, které funkce se používají nejčastěji, a zajistit k těmto funkcím co nejsnadnější přístup (jako bonus může dát uživateli možnost upravit si ovládání podle svých potřeb)</li>
</ol>
<p>Koncepce &#8222;nástroje&#8220; dobře funguje pro uživatele, kteří mají čas a motivaci se se systémem blíže seznámit a kteří mají zcela jasnou představu, co by s ním chtěli dělat &#8211; jsou to hlavně programátoři, konstruktéři (CAD), grafici a DTP operátoři a další profesionálové.</p>
<h3>Počítač jako asistent</h3>
<p>Tento přístup vyžaduje ještě lepší poznání uživatelů a jejich potřeb. Principem je, že uživatel dá pokyn k zahájení poměrně složité činnosti, kterou pak počítač samočinně vykonává a uživatele žádá jen o ty vstupy, které nedokáže získat jiným způsobem. Typickým představitelem takovéhoto typu rozhraní je tzv. &#8222;wizard&#8220;. Designér má opět tři hlavní úkoly:</p>
<ol>
<li>co nejlépe popsat typickou činnost uživatele a všechny rutinně prováděné úkony přenést na počítač</li>
<li>statisticky zmapovat vstupy uživatele a ty, které se vyskytují nejčastěji, zanést do systému jako &#8222;přednastavené hodnoty&#8220;</li>
<li>dobře zpracovat zpětnou vazbu, aby uživatel měl pocit jistoty, že počítač dělá přesně to, co má, a věděl, jaké jsou výsledky (a následky) jeho činnosti.</li>
</ol>
<h3>Použitelnost a přístupnost</h3>
<p>V horlivé snaze zpřístupnit webové aplikace pro lidi zrakově, sluchově, pohybově či mentálně postižené,  zapomínají občas tvůrci aplikací na uživatele, kteří žádný handicap nemají. Může se tak stát, že ačkoli v jednotlivostech aplikace splňuje všechny poučky o přístupnosti a bezbariérovosti, celkově je k ničemu, protože nesplní očekávání běžných uživatelů a nikdo ji tedy nebude používat. Je tedy dobré si uvědomit, že <strong>použitelnost a přístupnost není totéž</strong>.</p>
<h3>Přístupnost je dobro</h3>
<p>Občas se člověk setká s příkazem &#8222;na přístupnost se vykašli, postižených je málo a stejně na nich nevyděláme&#8220;. To je amorální a slušný člověk by amorální příkazy neměl uposlechnout. Ale realita je složitá a někdy je krátkodobě nutné spolupracovat i s lidmi, o které bychom si jindy ani neopřeli kolo. Je tedy vhodné vědět, že pro přístupnost mluví i objektivní měřítka &#8211; bezbariérové aplikace přinášejí úspory nákladů i zvýšené zisky.</p>
<p>Jak přístupnost souvisí s úsporami? Máme-li vyjít vstříc handicapovaným lidem, většinou to znamená udělat GUI jednodušší. Jednoduché GUI je však obvykle snazší nejen použít a pochopit, ale dost často je i jednodušší ho naprogramovat, otestovat a udržovat. Chceme-li například zavést automatické testování aplikace, velmi nám usnadní práci, když každý obrázek a každý odkaz má svůj popisek v atributu &#8222;title&#8220;.</p>
<p>Budiž, jednodušší aplikace jistě může přinést úspory, ale zisk? Je třeba si uvědomit, že nejhůře handicapovanými uživateli webových aplikací nejsou lidé, ale stroje. Například takový googlebot &#8211; nevidí, neslyší, dokonce ani nepřemýšlí &#8211; a přesto se potřebuje na stránkách, které indexuje, vyznat. A pokud se v nich snadno vyzná, ocení to lepším  umístěním ve výsledcích vyhledávání, a tedy reklamou zdarma. Způsob, jakým google čte stránky, se velmi podobá způsobu, jakým stránku čte slepecký browser.</p>
<h3>Testy použitelnosti</h3>
<p>Nauka o použitelnosti je v podstatě naukou o lidech, takže má do exaktní vědy velmi daleko. Téměř žádná z pouček o použitelnosti nemá zcela univerzální platnost, proto je důležité naše návrhy neustále konfrontovat se skutečnými uživateli &#8211; a k tomu právě slouží testy použitelnosti.</p>
<p>Test použitelnosti spočívá v tom, že uživateli předložíme naši aplikaci, dáme mu úkoly které má s její pomocí splnit, řekneme mu, aby svou činnost hlasitě komentoval a sledujeme, co doopravdy dělá. Mezi tím, co uživatel říká a co dělá, je obvykle rozpor, a právě ten je nejcennějším zdrojem informací. Umožňuje nám totiž nahlédnout do způsobu jeho uvažování a konfrontovat ho s naší původní představou.</p>
<p>Úkoly, které uživateli předkládáme, jsou vlastně případy použití přeložené do běžné řeči (někdy se jim &#8222;odborně&#8220; říká business use cases nebo user stories), takže uživatel dostává úkoly typu &#8222;přihlašte se do systému&#8220; nebo &#8222;založte nový účet&#8220;. Rozšířeným omylem je, že pro vedení uživatelského testu potřebujeme hotovou aplikaci. Opak je pravdou, většina uživatelských testů se provádí na papírových modelech obrazovek a tyto ranné testy také přinášejí nejcennější výsledky.</p>
<p>Kolik testů provést? Guru uživatelského testování Jacob Nielsen tvrdí že stačí 5 uživatelů, abyste odhalili více než 80% všech problémů. Z vlastní zkušenosti s ním musím souhlasit. U testování opět nejde o exaktní vědu, ale o výsledky, takže v průběhu testování můžete měnit testovaný model i úkoly a v případě že je to nutné, můžete uživateli i napovědět nebo mu pomoci překonat místo, s kterým si neporadí. Každý z uživatelů tak může mít test trochu jiný, podle toho jak postupně odhalujete a odstraňujete různé chyby.</p>
<h3>Opravdu je použitelnost to, co chceme?</h3>
<p>Ve většině případů opravdu chceme hlavně dobře použitelné UI, ale najdou se i výjimky. Typickými představiteli uživatelských rozhraní, kde tradiční přímočará použitelnost není na prvním místě, jsou</p>
<ul>
<li><strong>bezpečná rozhraní</strong>  &#8211; tedy rozhraní odolná proti chybám lidského faktoru</li>
<li><strong>komplexní rozhraní</strong> &#8211; tedy rozhraní určená pro velmi kvalifikovanou obsluhu, která řeší složitý problém</li>
<li><strong>herní rozhraní</strong> &#8211; tedy taková kde stavíme uživateli do cesty určité překážky a chceme aby je překonával</li>
</ul>
<h3>Bezpečná rozhraní</h3>
<p>Tam kde je zásadním požadavkem, aby uživatel neudělal chybu, je nutné vytvořit bezpečné rozhraní. Zatímco běžné použitelné rozhraní se přizpůsobuje stereotypu práce uživatele, bezpečné rozhraní se naopak snaží v kritických okamžicích stereotyp narušit, aby nedocházelo k chybám rutinní práce. To je poměrně náročný úkol, protože hrozí, že naše opatření prostě jen nahradí jednu rutinu druhou. Pokud například při každé operaci mazání vyskočí dialog &#8222;opravdu chcete toto smazat?&#8220;, uživatel si jeho potvrzování zautomatizuje a dialog tak přestane plnit svou ochrannou funkci.</p>
<p>Bezpečná rozhraní jsou nepopulární. Uživatel není rád, že ho vytrhujeme z práce a otravujeme různými bezpečnostními pojistkami, že snižujeme jeho efektivitu omezeními a že ho občas zbytečně vyděsíme varováním. Vlastně děláme pravý opak než obvykle &#8211; obvykle uživatele nechceme rušit v jeho práci, bezpečné rozhraní má naopak za cíl uživatele vyrušit, zastavit jeho práci, rozbít jeho pracovní stereotyp a přinutit ho chvíli přemýšlet o tom, jestli to, co dělá, není chyba.</p>
<h3>Komplexní rozhraní</h3>
<p>U některých vysoce specializovaných aplikací se dá očekávat,  že i obsluha bude kvalifikovaná a zaškolená. V takových případech nemusíme rozhraní dělat tak, aby ho pochopil každý, stačí když ho pochopí obsluha a tu to můžeme naučit. Preferujeme efektivitu práce a kvalitu informací, které rozhraní poskytuje. Typickými představiteli komplexních rozhraní jsou aplikace typu CAD, programátorská vývojová prostředí a geografické informační systémy.</p>
<h3>Herní rozhraní</h3>
<p>Představte si hru Doom optimalizovanou na lepší použitelnost. Spustili byste hru, kliknutím byste označili příšery, které chcete zabít, stiskli byste OK a  hned byste postupovali do další úrovně. Žádné bloudění labyrintem, celou hru byste velmi efektivně dohráli za pár minut. Ale asi by to nebylo ono, že?</p>
<p>Prvek hry spočívá v překonávání překážek a lidé to mají rádi. V některých případech je na místě vkládat herní prvky i do &#8222;neherních&#8220; aplikací, jako jsou např. propagační weby. Ale pozor, je třeba rozlišovat, co jsou překážky motivující, které uživatele zaujmou, a co jsou překážky frustrující, které uživatele odradí. I designér herních rozhraní musí mít jasno v použitelnosti, protože hráč chce řešit zábavné úkoly, ne zápasit s uživatelským rozhraním.</p>
<h3>Závěrem</h3>
<p>Použitelnost je pro obchodní úspěch aplikace nezbytná, ale v posledních letech je stále významnějším faktorem i přístupnost. Jestliže se nám podaří tyto dvě věci vyřešit, přichází na řadu vzhled aplikace, o kterém bude další díl seriálu.</p>
<p><a href="/blog/2009/09/gui-design-funkcionalita/">Předchozí díl: Funkcionalita</a><br />
<a href="/cs/blog/2010/11/gui-design-vzhled/">Následující díl: Vzhled</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.aspectworks.com/2009/10/gui-design-pouzitelnost/feed</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>GUI Design: Funkcionalita</title>
		<link>http://www.aspectworks.com/2009/09/gui-design-funkcionalita</link>
		<comments>http://www.aspectworks.com/2009/09/gui-design-funkcionalita#comments</comments>
		<pubDate>Thu, 17 Sep 2009 08:35:53 +0000</pubDate>
		<dc:creator>Richard Šerý</dc:creator>
				<category><![CDATA[Analýza a modelování]]></category>
		<category><![CDATA[Webdesign]]></category>
		<guid isPermaLink="false">http://www.aspectworks.com/cs/blog/?p=146</guid>
		<description><![CDATA[Tak jako stavba pyramidy, i stavba GUI musí mít solidní základy. A základem je tady funkcionalita. Pokud GUI nezajišťuje potřebnou funkcionalitu, není k ničemu. Dokud nemáme jasno ve funkcionalitě, je<a href="http://www.aspectworks.com/2009/09/gui-design-funkcionalita" class="moreLink">více&#160;»</a>]]></description>
			<content:encoded><![CDATA[<p>Tak jako stavba pyramidy, i stavba <abbr title="Graphic User Interface">GUI</abbr> musí mít solidní základy. A základem je tady funkcionalita. Pokud  <abbr title="Graphic User Interface">GUI</abbr> nezajišťuje potřebnou funkcionalitu, není k ničemu. Dokud nemáme jasno ve funkcionalitě, je zbytečné se zabývat vyššími stupni, jako je použitelnost, design či estetika.<span id="more-2547"></span></p>
<div class="imageRight"><img src="http://www.aspectworks.com/wp-content/uploads/2009/09/uc.png" alt="Model - Use Cases" vspace="10" hspace="10" /></div>
<h3>Analýza funkcionality</h3>
<p>Analýza funkcionality  <abbr title="Graphic User Interface">GUI</abbr> je celkem jednoduchá věc &#8211; v zásadě na to stačí analýza případů použítí (use cases, dále jen UC), kterou bychom stejně měli mít vždy k dispozici.</p>
<p>Oproti běžnému popisu <abbr title="Use Case">UC</abbr> bychom však měli mít trochu více jasno v tom, <strong>kdo je uživatel</strong>. Zajímá nás např. jak bude uživatel zkušený, inteligentní, pracovně vytížený, jestli je pro něj důležité spíš pracovat rychle, bezchybně, nebo se třeba zorientovat ve složitém problému&#8230;  Měli bychom znát také četnost jednotlivých  <abbr title="Use Case">UC</abbr>, tedy <strong>jak často se která funkce používá</strong>. A třetí podstatný faktor je důležitost  <abbr title="Use Case">UC</abbr>, tedy <strong>jak je daný  <abbr title="Use Case">UC</abbr> významný</strong> pro úspěch výsledného produktu.</p>
<div class="example"><em>Příklad:</em></p>
<p>Představte si, že vyvíjíme textový editor a v něm <abbr title="Use Case">UC</abbr> &#8222;Počítání slov v dokumentu&#8220;:</p>
<p><em>Kdo je uživatel?</em> Funkci &#8222;Počítání slov&#8220; běžný člověk nevyužije, ale např. novinář nebo překladatel se bez toho neobejde. Víme tedy, že uživatelem bude někdo, kdo se živí psaním a je placený od slova &#8211; díky tomu si dokážeme  domyslet nebo zjistit spoustu dalších informací. </p>
<p><em>Jak často bude funkce využívána?</em> Počítání slov se spouští většinou tehdy, když je dokument dopsaný. Funkce tedy moc často využívaná nebude a můžeme ji s klidem zastrčit do nějakého rozbalovacího menu.</p>
<p><em>Jak je UC významný?</em> Ačkoli náš <abbr title="Use Case">UC</abbr> není příliš často využívaný a jeho cílová skupina není příliš početná, jeho důležitost je přesto velká &#8211; pro obchodní úspěch textového editoru je nezbytné, aby ho využívali právě profesionálové kteří se živí psaním &#8211; už proto že na něj určitě budou psát recenze a vytvářet tak názor ostatních uživatelů.
</div>
<p>Výsledkem analýzy funkcionality je tedy <strong>seznam případů užití</strong>, který obsahuje<strong> informace o uživatelích</strong>, <strong>četnosti použití</strong> jednotlivých UC a <strong>významu</strong> jednotlivých <abbr title="Use Case">UC</abbr>.</p>
<h3>Design funkcionality</h3>
<div class="imageRight"><img src="http://www.aspectworks.com/wp-content/uploads/2009/09/wireframe.png" alt="Model - Wireframe" vspace="10" hspace="10" /></div>
<p>Jakmile je máme k dispozici analýzu, můžeme přikročit k designu. To je taková zábavná část, která zahrnuje všelijaké malůvky na papír, tabuli i flipchart, později také malování do různých počítačových programů, jako je třeba Enterprise Architect, někdy dokonce vystřihování modýlků z papíru atd. Cílem je udělat si co nejlepší představu o budoucím  <abbr title="Graphic User Interface">GUI</abbr> s vynaložením co nejmenšího úsilí, pokud možno bez programování.</p>
<p>Dost často se během vytváření prototypu <abbr title="Graphic User Interface">GUI</abbr> zjistí, že analýza, ze které vycházíme, je nesprávná nebo nedostatečná. A vždy vyjde mnohem levněji, najdete-li chybu v analýze, než když tutéž chybu najdete ve výsledném produktu. I proto je dobře <strong>dělat prototyp co nejdříve</strong>, v optimálním případě současně s analýzou, abychom po schválení analýzy klientem nezjistili, že pro schválené řešení nelze udělat rozumné <abbr title="Graphic User Interface">GUI</abbr>. </p>
<p>Výsledkem této fáze je model  <abbr title="Graphic User Interface">GUI</abbr>, kterému říkáme &#8222;<strong>wireframe</strong>&#8220; (drátový model) , nebo také &#8222;<strong>papírový prototyp</strong>&#8222;.</p>
<h3>Testování funkcionality</h3>
<p>Jestliže jsme poctivě provedli analýzu i design funkcionality, bude otestování snadné. Jako testovací scénáře použijeme <abbr title="Use Case">UC</abbr>, které jsme si připravili ve fázi analýzy. Vezmeme schéma aplikace, které jsme si namalovali ve fázi designu, představíme si že je to skutečná aplikace a zjišťujeme, zda by uživatel v takové aplikaci dokázal projít naše testovací scénáře. Pokud ne, je třeba schéma upravit.</p>
<h3>Závěrem</h3>
<p>Kvalitně navržená funkcionalita je naprostým základem každého <abbr title="Graphic User Interface">GUI</abbr>. Nenechte se nikdy strhnout k abstraktním úvahám. Naopak, vždy sestavte prototyp, i kdyby aplikace byla velmi jednoduchá, protože většinu problémů člověk pochopí, až když je vidí na papíře.</p>
<p>Máme-li dostatečnou přestavu o funkcionalitě, můžeme začít pracovat na použitelnosti  <abbr title="Graphic User Interface">GUI</abbr>. A o tom bude následující díl tohoto seriálu.</p>
<p><a href="http://www.aspectworks.com/2009/08/gui-design-serial/">Předchozí díl: Úvod seriálu</a><br />
<a href="http://www.aspectworks.com/2009/10/gui-design-pouzitelnost/">Následující díl: Použitelnost</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.aspectworks.com/2009/09/gui-design-funkcionalita/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>GUI Design: Seriál</title>
		<link>http://www.aspectworks.com/2009/08/gui-design-serial</link>
		<comments>http://www.aspectworks.com/2009/08/gui-design-serial#comments</comments>
		<pubDate>Wed, 05 Aug 2009 13:40:00 +0000</pubDate>
		<dc:creator>Richard Šerý</dc:creator>
				<category><![CDATA[Webdesign]]></category>
		<guid isPermaLink="false">http://www.aspectworks.com/cs/blog/?p=13</guid>
		<description><![CDATA[Zjistil jsem že většina lidí, a dokonce i zkušených IT odborníků, nemá vůbec jasnou představu, co je to vlastně GUI design. Rozhodl jsem se tedy napsat krátký seriál o GUI<a href="http://www.aspectworks.com/2009/08/gui-design-serial" class="moreLink">více&#160;»</a>]]></description>
			<content:encoded><![CDATA[<p>Zjistil jsem že většina lidí, a dokonce i zkušených IT odborníků, nemá vůbec jasnou představu, co je to vlastně GUI design. Rozhodl jsem se tedy napsat krátký seriál o GUI designu, který by populárně naučnou formou přiblížil co to je, k čemu je to dobré a jak se to dělá.<span id="more-2544"></span></p>
<h3>“Aplikaci máme napsanou, zbývá jen dodělat GUI”</h3>
<p>Rozšířeným omylem je domnívat se, že GUI je něco co lze k aplikaci jen tak přidat. Což o to, ono by to i šlo. Potíž je ovšem v tom, že z jedné strany toho GUI sedí člověk, a bavit se s člověkem je mnohem složitější než bavit se s počítačem. Ve chvíli kdy začneme připravovat GUI, obvykle se vynoří mraky požadavků, které hotová aplikace nedokáže splnit ale člověk &#8211; uživatel &#8211; na nich trvá.</p>
<p>I zkušení programátoři pravidelně selhávají při úkolu vytvořit GUI. Proč tomu tak je? Podívejme se na rozdíly mezi programováním počítačů a “programováním” lidí:</p>
<table>
<tbody>
<tr>
<th></th>
<th>Počítač</th>
<th>Člověk</th>
</tr>
<tr>
<th>Přesnost</th>
<td>Počítač udělá přesně to, co mu napíšeme do programu.</td>
<td>Uživatel nedělá věci tak jak čekáme, dělá si je po svém a skoro pokaždé trochu jinak.</td>
</tr>
<tr>
<th>Systematičnost</th>
<td>Počítač čte kód tak jak mu ho předkládáme.</td>
<td>Uživatel GUI nečte &#8211; jen si ho tak zběžně prohlédne a pak obvykle klikne na něco co mu připadá nadějné.</td>
</tr>
<tr>
<th>Redundance</th>
<td>Redundance je špatná, snažte se být tak struční jak je to jen možné.</td>
<td>Redundance je nutná, čím důležitější funkce / informace, tím více by se měla vyskytovat na GUI.</td>
</tr>
<tr>
<th>Chyby</th>
<td>Počítač nedělá chyby, pokud něco selže tak jsme to špatně naprogramovali a můžeme to opravit.</td>
<td>Člověk dělá chyby, můžeme jim sice částečně bránit ale nevyhneme se jim.</td>
</tr>
<tr>
<th>Paměť</th>
<td>Počítač má v paměti přesné veličiny a pojmy.</td>
<td>Uživatel má v hlavě chaotické útržky informací a míchá je se svými dojmy.</td>
</tr>
<tr>
<th>Adaptabilita</th>
<td>Dojde-li k chybě, počítač zastaví program a vypíše o tom hlášení. Lze vždy přesně rozhodnout co je a co není chyba.</td>
<td>Uživatel, má li pocit že nastala chyba, zkusí to jinak a obvykle si nějak poradí. Chyba je to co uživatel za chybu považuje, i kdyby to bylo správně a s dobrým úmyslem naprogramováno.</td>
</tr>
</tbody>
</table>
<p>A dalo by se ještě dlouho pokračovat. Je vidět že nároky na komunikaci s lidmi se propastně liší od toho, co musí programátor umět aby se “domluvil” s počítačem. Dokonce se dá říct, že programování na návrh UI jsou dvě vzájemně protikladné činnosti. Takže není divu že když se někdo pokouší dělat obě tyto věci najednou, bolí ho hlava.</p>
<h3>Pyramida potřeb</h3>
<p><img src="http://www.aspectworks.com/wp-content/uploads/2009/08/pyramida.gif" alt="Pyramida potřeb GUI designu" hspace="10" align="right" /><br />
I pro GUI design můžeme sestavit  obdobu <a href="http://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs">Maslowovy pyramidy potřeb</a>. Bráno od základů, bude mít tato pyramida 4 stupně:</p>
<ul>
<li><strong>funkcionalita</strong> (jaké funkce má GUI uživateli poskytovat?)</li>
<li><strong>použitelnost</strong> (dokáže uživatel tyto funkce opravdu využít?)</li>
<li><strong>vzhled</strong> (jak bude GUI vypadat?)</li>
<li><strong>zážitek</strong> (jaký bude mít uživatel z aplikace pocit?)</li>
</ul>
<p>Protože někeré z těchto pojmů lidem splývají nebo si je pletou, v dalších článcích je rozvedu a podrobněji vysvětlím.</p>
<p>Je třeba říci, že jde opravdu o pyramidu potřeb, to znamená že nelze zlepšit použitelnost nebo navrhnout vzhled nějaké části GUI, pokud není vyřešena její funkcionalita. Zní to triviálně, ale grafici by mohli vyprávět jak překvapivě často slyší zadání typu “ještě nevíme co aplikace bude dělat, tak zatím jenom navrhněte vzhled”. Je to jako kdyby stavitel pyramidy velel svým podřízeným “ještě nevíme jak bude pyramida velká, tak ji začněte stavět od špičky a budeme to rozšiřovat směrem dolů”. Zní to sice pěkně ale ve skutečnosti to nefunguje.</p>
<h3>Cíl GUI designu</h3>
<p>Říká se, že dokonalá techologie je taková, o které člověk ani neví že jde o technologii. S designem je to podobné, dokonalý design většinou působí tak přirozeně, že si ho uživatelé ani nevšimnou. Samozřejmě, je mnoho designů které člověka zaujmou nebo dokonce uvedou v úžas, ale vnější dojem je jen špičkou ledovce &#8211; většina designu se skrývá v malých nenápadných věcech, dotažených detailech a v přirozené harmonii celku.</p>
<p><a href="http://www.aspectworks.com/2009/09/gui-design-funkcionalita/">Následující díl: Funkcionalita</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.aspectworks.com/2009/08/gui-design-serial/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

