jan korbel

Dnes už jsem dvakrát narazil na špatně použitý select (nebo rozklikávací menu, drop-down menu nebo jak tomu vlastně říkáme), z toho jednou jsem si ho maloval sám pro stránku, na které teď pracuji. Takže připomenutí…
Čtěte dál

Další zastavení nad příklady zajímavých uživatelských rozhraní. Tentokrát o posunu po stránce, zvýrazňování článků, adresovém poli v prohlížečích a náhledu výsledků vyhledávání.
Čtěte dál

Říkal jsem si, že nebude od věci oprášit pár základních pojmů v teoriích kolem uživatelského rozhraní. Pro začátek jsem vybral Fittsův zákon.
Čtěte dál

Fascinují mě uživatelská rozhraní. Snažím se soustředit na ty momenty, kdy je uživatelské rozhraní tak dobré, že si ho ani nevšimnete, tak plynulá je vaše cesta aplikací. Budu občas publikovat nějaké zajímavé příklady. Tady je první edice.
Čtěte dál

Když jsem se někdy kolem roku 2000 poprvé setkal s redakčním systémem, přišlo mi to jako skvělý nápad. Klient si může sám spravovat stránky, platí za to a my máme víc času na jiné výnosné aktivity. Už si to nemyslím.
Čtěte dál

Já už nějaký ten rok vývoj hardware sleduju jen z povzdálí, ale tohle představení nového procesoru od Intelu mě zaujalo. Uvědomil jsem si díky němu, že to, co mi nedávno přišlo jako mlhavá budoucnost, už klepe na dveře.
Čtěte dál

Originální způsob psaní, kdy navigujete mezi prolétavajícími písmeny. Vím, takhle to zní dost divně, ale mají tam zabudované předvídání následujících písmen. No, video je za tisíc slov, takže se mrkněte na níže vložené.
Čtěte dál

Po delší době jsem se zase podíval na blog The Interaction Designer’s Coffee Break a dostal jsem se tak k tipu na dvě služby, které nám umožní přímo sledovat pohyb a akce uživatelů na stránkách. Výsledky jsem nadšen tak, že se s vámi musím podělit.
Čtěte dál

V minulém díle jsem shrnul teorii přístupu k uživatelskému rozhraní a ukázal jsem svou představu o titulní stránce naší aplikace. Dnes se naplno ponoříme do wireframů všech ostatních obrazovek, se kterými se uživatelé setkají.
Čtěte dál

Předcházející díly:

1. 
   1. díl – Návrh databáze
   
2. 
   1½. díl – Dokončení návrhu databáze
   

Před sebou máme bílý papír a v hlavě ne právě konkrétní představu o tom, co od aplikace chceme. Každý, kdo si zkusil nějaké to rozhraní navrhnout, se mnou bude souhlasit, že i zdánlivě jednoduchý problém nabízí mnoho možností jak k němu přistupovat. Snadno se dostaneme do situace, kdy nás jedna funkce rozhraní inspiruje k jiné, která by „taky byla dobrá” a dřív než se nadějeme máme na krku nezvladatelné monstrum, jehož početné hlavy „užitečných funkcí” nás rozsápou na fidloprcičky¹.

Za každou funkci platíme nejen časem investovaným do naprogramování

Především si musíme udělat jasno v tom, co naše web aplikace musí umožňovat nezbytně nutně hned od začátku. Ušetříme tím čas, který bychom strávili nad něčím, co vlastně není potřeba. Navíc, za každou funkci platíme nejen časem investovaným do naprogramování, ale musíme odvést desátky i v podobě složitějšího uživatelského rozhraní, což se může odrazit ve špatném dojmu, který uživatelé budou mít a/nebo ve vyšších nákladech na jejich podporu. Rozumí se samo sebou, že každá funkce komplikuje také testování, vývoj aplikace, zaškolení programátorů a další záležitosti na straně vývojářů.

Proto je velká výhoda, když navrhujeme web aplikaci, kterou budeme sami používat, nebo se týká něčeho s čím máme osobní zkušenost. Pouze pochopení toho, jaký problém řešíme nám dovolí navrhnout správné funkce, teprve používáním získáme opravdový cit pro to, jak to v aplikaci tiká, kde to skřípe. Zprostředkovaná zkušenost nám může být na překážku.

To jsou základní teoretická východiska a teď zpátky k naší web aplikaci pro tisk a správu faktur.

Primární cíle

V našem případě jde především o:

1. Tisk faktur
2. Přehled vystavených faktur
3. Základní statistiku příjmů a výdajů

Pojďme si udělat inventuru toho, co ke splnění těchto cílů nezbytně potřebujeme.

Pro tisk faktur:

• Zadat, upravit, smazat dodavatele
• Zadat, upravit, smazat odběratele
• Zadat, upravit, smazat faktury a jejich náležitosti (doby vystavení a splatnosti, položky faktury, ceny, sazby DPH)

Pokud jde o přehled vystavených faktur:

• Vystavené, nezaplacené faktury
• Přehled všech vystavených faktur za určité období a pokud se budeme chtít rozšoupnout, tak i pro určitého klienta

U statistiky příjmů a výdajů použijeme pro začátek jen pasivní výpisy důležitých veličin a neumožníme žádné specifikování parametrů výpisu ze strany uživatele.

• Příjmy a výdaje za jednotlivá čtvrtletí aktuálního roku
• Příjmy a výdaje za poslední čtvrtletí rozepsané po 14-ti dnech

Faktury přijaté od našich dodavatelů nebudeme pro začátek nikde vypisovat, projeví se nám jen ve statistikách výdajů. Později uvidíme, jestli se nám budou hodit nějak podrobněji vypsané.

OK, to by pro začátek stačilo, pojďme to hodit na papír.

Wireframy – teorie

Jenom pro jistotu: wireframy nejsou o grafické podobě, jsou to nákresy toho, jaké informace a jakým způsobem chceme zobrazovat a měly by sloužit jako podklady pro grafika, který tuto kostru potáhne svaly a kůží.

Teprve až používáním v reálných podmínkách zjistíme, co opravdu potřebujeme

Pro web aplikace platí, že nemá cenu trávit nad wireframy příliš mnoho času ve snaze vytvořit něco, co bude na 100% vystihovat výsledek (ani na 90% ne). To se nám nikdy nemůže povést. Proč? Protože si nejsme schopni představit, jak to v aplikaci bude fungovat ve skutečném provozu. Teprve až používáním v reálných podmínkách zjistíme, co opravdu potřebujeme. A tím nemyslím, že musíme u aplikace sedět dva měsíce. Čím větší bude problém, který jsme “neviděli na papíru”, tím rychleji ho odhalíme. Moje zkušenost je, že opravdu zásadní chyby vyjdou na světlo během pár dnů. Takže wireframy ano, ale přiměřeně – mluvíme rozhodně v řádu hodin².

Někomu vyhovuje i první úvahy o uživatelském rozhraní web aplikace rovnou budovat v HTML. Já si myslím, že nás může tento přístup odvést od dobrých řešení, protože HTML přeci jen není tak pružné jako tužka a papír, kde se můžeme nechat unést a naskicovat něco, co se nám bude špatně programovat, ale co bude velmi dobře fungovat.

Wireframy – praxe

Rád bych tu publikoval návod, který by ukázal postup, jakým jsem se dostal k tomu, co uvidíte níže, ale těch rozhodnutí je i na takto malé aplikaci hodně a o některých pravděpodobně ani nevím, protože je dělám podvědomě. Proto ukážu své výsledné wireframy, stručně popíšu, proč jsem se na jednotlivých místech rozhodl, jak jsem se rozhodl a pak to můžeme v komentářích probrat.

Úvodní stránka aplikace

Uvažoval jsem takhle: Náš nejčastější důvod návštěvy úvodní stránky bude podívat se na to, které faktury jsou zaplacené, blíží se splatnosti, nebo jsou po splatnosti. Pak budeme chtít vidět statistiku příjmů a výdajů za poslední dobu a nějakou formu celkového přehledu za delší období. Samozřejmě dalším důvodem bude to, že chceme vystavit fakturu nebo přidat do databáze přijatou fakturu, takže se musíme postarat i o to.

A už v tomhle kroku se mohou naše názory lišit. Web aplikace, kterou zde navrhuji, je určena pro malé firmy, kde se faktury vystavují jednou do týdne nebo spíš jednou za čtrnáct dní a ti, co je vystavují, mají přímý zájem vidět, jak si firma vede, protože jejich výplaty na tom přímo závisí.

Jakým způsobem vypsat faktury, které čekají na zaplacení? Faktura má řadu náležitostí — číslo, odběratele, položky faktury, datum vystavení, datum splatnosti — pokud bychom je prostě vypsali do tabulky zahltíme stránku údaji, které vlastně nepotřebujeme. Co nás zajímá na vystavených, nezaplacených fakturách? Komu jsme ji vystavili, na jakou částku a kdy je splatná.

Obrázek č. 1 – Přehled vystavených, nezaplacených faktur

Přišlo mi užitečné barevně zvýraznit doby splatnosti, kdy blížící se jsou zelené, vzdálenější než 5 dní jsou běžnou barvou a faktury po splatnosti jsou červené. Jak je na obrázku naznačeno po najetí myší nad řádek s fakturou se objeví nabídka s tlačítkem pro označení faktury jako zaplacené a malá ikona pro její úpravu.

Musíme také počítat s tím, že přehled vystavených faktur bude mít proměnlivou výšku, nebo dokonce nebude co vypisovat. Osobně bych v případě, kdy nebude žádná faktura čekající na zaplacení, nechal vypsat přehled posledních 10 vystavených faktur. Ale možná v reálném provozu přijdeme na lepší obsah, takže se s tím, teď nebudeme trápit.

Pak chceme vypsat statistiky příjmů, které nám dají představu o tom, jakou výplatu si můžeme dovolit a jak si vedeme v krátkodobém a střednědobém pohledu. Zvolil jsem dva jednoduché přehledy – výpis příjmů a výdajů za tři měsíce zpátky rozepsaný zhruba po 14-ti dnech a celkový roční přehled rozepsaný po účetních čtvrtletích.

Obrázek č. 2 – Příjmy a výdaje za předcházející tři měsíce rozepsané podrobně

Obrázek č. 3 – Přehled za aktuální účetní rok

Přidání nové faktury pokryjeme tím, že přidáme výrazné tlačítko „Přidat fakturu” na exponované místo. Pak ještě potřebujeme globální navigaci. Zatím se mi zdá, že vystačíme s tlačítky:

• Přehled – úvodní stránka
• Faktury – podrobnější výpis přijatých a vydaných faktur
• Subjekty – prostor pro správu dodavatelů a odběratelů
• Nastavení – určitě se nám bude na něco hodit (minimálně pro definici momentálních sazeb DPH)

Když to celé složíme, dostaneme to, co vidíte na obrázku č. 4:

Obrázek č. 4 – Celý wireframe úvodní stránky aplikace

No, myslím, že pro dnešek by to stačilo. Další díl bude brzy následovat, protože už mám vytvořené i wireframy pro další sekce naší web aplikace, jen se mi zdálo, že už by jejich rozbor zabral víc místa než je vhodné pro jeden článek a taky vám chci nechat čas zamyslet se nad tou teorií, která zabrala většinu dnešního článku.

Pokud by měl někdo zájem, tak tady je zdrojový soubor pro OmniGraffle a exportovaný wireframe jako PDF.

Označování obsahu tagy se stalo neodmyslitelnou součástí mnoha stránek a webových aplikací. Nadefinujeme klíčová slova a podle nich své informace zase najdeme – krásně jednoduché. Jak už to bývá, převést jednoduchou myšlenku do života před nás postaví nejednu výzvu. Pokusím se tu rozvést základní koncept tagování a nadhodit další možnosti jeho využití.

Čtěte dál