Rubrika: Web aplikace

Příklady uživatelského rozhraní, které stojí za pozornost – tentokrát v negativním smyslu.
Čtěte dál

AppleInsider publikoval tip od čtenáře, který vypátral, že přidáním meta tagu do hlavičky stránky získá vaše web aplikace schopnost běžet na iPhonu ve full-screen módu – bez Safari chrome.
Čtěte dál

Při poslechu podcastu Boagworld jsem narazil na Pattern Tap. Rozsáhlý a velmi dobře navržený katalog příkladů designu opakujících se hádanek jako jsou 404 stránky, tlačítka, kalendáře… a mnoho, mnoho dalších.
Čtěte dál

Pencil Project je plugin do Firefoxu (verze 3), který se tváří jako desktopová aplikace a slibuje velmi slušné rozhraní pro návrh webů.
Čtěte dál

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

Ří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

Webové služby Amazonu jako je S3, EC2SimpleDB asi znáte. Google se pouští na stejné pole, ale trochu jinak. Pojďme se ve stručnosti podívat na to, co nabízí vývojářům web aplikací.
Čtěte dál

Za poslední měsíc zaznamenala OpenID Foundation tak výrazné úspěchy, pokud jde o přijetí ze strany velkých hráčů, že si troufám říct: „Obecně přijímaný standard pro jednotné přihlašovací údaje je na světě.”
Čtěte dál

Google přidal do své spreadsheet aplikace funkci, která umožní jednoduše udělat anketu, rozeslat ji na emaily a zpřístupnit ji na internetu. Odpovědi se vám zpátky zaznamenávají do souboru v Google Docs, kde formulář je. Hezké, velmi hezké. Via Daring Fireball
Č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

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

Via Daring Fireball

Apple na svých stránkách pro vývojáře vytvořil novou sekci, která se věnuje tvorbě pro iPhone.
Čtěte dál

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

Hledáte něco na faktury?

Fakturoid – tisk a správa faktur pro živnostníky a malé firmy. Konečně jednoduše.

Mimochodem, dopadlo to nakonec úplně jinak, než v této sérii článků ;)

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čky1.

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 hodin2.

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.


  1. Zdravím Arthura Denta a všechny další příznivce Stopaře :)

    zpět na místo v textu

  2. To je ovšem případ, kdy naskicujeme naši představu na papír tužkou a na tvorbě se účastní jeden, dva lidé, kteří mají rozhodovací pravomoc. Nezapočítávám čas, který je potřeba k převodu tužky a papíru do něčeho, co můžeme prezentovat klientovi (pokud klientem nejsme my) a už vůbec nechci odhadovat, kolik času by tento krok mohl zabrat v nějakém „korporátním prostředí”, kde se k tomu může vyjádřit další pět lidí, z nichž dva mají rozhodovací pravomoc a jejich požadavky jdou proti sobě… no dobře, trochu jsem si zapřeháněl, ale víte, kam mířím.

    zpět na místo v textu