jan korbel

Proč byste si měli od začátku klientům své aplikace říkat o peníze.

Via @paveldolezal

Weby už se u nás dělají nějaký ten rok a ačkoli všichni vědí, že „content is the king,” jsme stále mile překvapení, když narazíme na stránku, kde si úsilí autora(-ů) textů všimneme s tím, že někdo odvedl dobrou práci.

Texty — microcopy, mikro-texty chcete-li — jsou ve web aplikacích asi ještě důležitější než u webů. Náš uživatel často začíná v „prázdné aplikaci”, protože většinu obsahu musí sám vytvořit. Chceme ho provést řadou kroků, ve kterých mu vysvětlíme nejdříve základy fungování naší aplikace a postupně z něj vychováme profíka, který s pomocí naší aplikace válí, a proto ji miluje.

Čtěte dál

Tutoriál na NETTUTS, který vám ukáže řešení pro layout typu iGoogle nebo Netvibes s uživatelem definovanými boxy.

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

Cappuccino is an open source framework that makes it easy to build desktop-caliber applications that run in a web browser.

Je na něm postavená třeba aplikace 280Slides.

Podrobný článek na Vitamin popisující nasazení automatizovaného testování pomocí open source projektů Hudson a Selenium.

Dlouho se spekulovalo nad tím, jestli Google pracuje na vlastním operačním systému. Ta myšlenka se zdála příliš fantaskní. Byla. Byla v tom smyslu, v jakém jsme zvyklí vnímat operační systémy.
Čtěte dál

Rychlejší JavaScript = rychlejší web aplikace a nárůst v řádu 20-ti násobku už by mohl být znát.

Krátce před půlnocí našeho času Twitter na chvíli zapnul nové uživatelské rozhraní. Pojďme si ho porovnat s tím minulým. Myslím, že hodně vylepšili.
Čtěte dál

Ryan ve svém článku na TechCrunch stručně shrnuje svoje zkušenosti s vývojem aplikace Matt, kterou v devíti lidech vybudovali za čtyři dny. Zajímavé složení týmu.

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

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.