Getting the details right is the difference between something that delights, and something customers tolerate.

A ještě jeden citát:

This is all your app is: a collection of tiny details.
– Wil Shipley

Via @dmajda

Simple HTML5 page edits. Storage.js uses the new HTML5 contenteditable attribute and localStorage to bring you HTML5 awesomeness.

Prezentační stránka není moc hezká, ale technologie vypadá dobře.

Device.js is a starting point for doing semantic, media query-based device detection without needing special server-side configuration, saving the time and effort required to do user agent string parsing.

Dovolí vám měnit DOM, nejen načítat jiné CSS pro jiný rozměr displeje.

Filepicker.io je řešení připravené pro použití.

Via @rjs

Meteor is a set of new technologies for building top-quality webapps in a fraction of the time, whether you’re an expert developer or just getting started.

Zatím jsou ve verzi Preview 0.3.2, ale rozhodně mrkněte na tohle 10 minutové video. Vypadá to hodně zajímavě.

Via @keff85

Co jsem neviděl, byla výhoda web aplikací v právě se rodícím trhu mobilních aplikací. Inu, iPhone byl představen teprve tři měsíce předtím, než jsem to psal.

Aby bylo jasno, netvrdím a nidky jsem netvrdil, že web aplikace bude to jediné, nebo snad to nejdůležitější v softwarové branži. Co tvrdím, je, že pořád hodně lidí nedoceňuje, jaká příležitost se tu otevřela.

Což mi připomíná: Ještě jsou 2 volná místa na školení ;-)

Celkově se dá říct, že školení je ideální pro lidi, kteří mají zkušenost s tvorbou webů a chtěli by se nasměrovat na tvorbu web aplikací.

Byznys část hodnotili přínosně i zkušení tvůrci web aplikací, kteří na školení byli.

Wireframovací část odhalila slabinu mého záměru vymyslet příkladovou aplikaci přímo na školení. Jeden z účastníků přišel s reálným příkladem aplikace, kterou se chystá dělat. Znělo to zajímavě a všichni jsme souhlasili, že to bude dobrý výchozí bod pro wireframování.

Problém se ukázal být v tom, že ještě neměl dostatek informací pro to, aby řekl, co je správně a co ne, takže ve výsledku se nedalo ponaučit z chyb a ukázat dobré postupy, protože nebyla kritéria, jak je posoudit.

Proto upravím wireframovací část ve směru návrhu aplikace, kterou jsem dělal (nebude to Fakturoid) a jsem tedy schopen ji popsat z pozice klienta a zároveň budu schopen zodpovědět vaše otázky při cvičení a lépe zhodnotit, co dává smysl a co ne.

Termín dalšího školení

Kdy: 25. dubna (středa) od 9.30 do 17.00 hod
Kde: Hub Praha, oranžová místnost
Počet účastníků: 10 (už jen 2 místa volná)
Cena: 5000 Kč Release Candidate cena 4000 Kč (nejsem plátce DPH)

Přihlašte se přes email

Hodí se školení pro vás?

Vidíte v tvorbě web aplikací otevírající se příležitost? Uvažujete o tom, že byste vytvořili nějakou vlastní? Máte už firmu, která dělá webové prezentace a chcete rozšířit záběr a/nebo získat stabilní příjem z vlastní aplikace? Chcete získat slušný základ v obchodní strategii a v organizaci procesu tvorby web aplikace?

Pokud jste na něco odpověděli „Ano“, nemělo by vás školení zklamat.

Školení přímo u vás ve firmě

Nabízí se možnost kombinace školení a konzultace nad vaším produktem. Ozvěte se.

An interaction model is a design model that binds an application together in a way that supports the conceptual models of its target users. It is the glue that holds an application together. It defines how all of the objects and actions that are part of an application interrelate, in ways that mirror and support real-life user interactions. It ensures that users always stay oriented and understand how to move from place to place to find information or perform tasks. It provides a common vision for an application. It enables designers, developers, and stakeholders to understand and explain how users move from objects to actions within a system. It is like a cypher or secret decoder ring: Once you understand the interaction model, once you see the pattern, everything makes sense. Defining the right interaction model is a foundational requirement for any digital system and contributes to a cohesive, overall UX architecture.
– Defining an Interaction Model: The Cornerstone of Application Design, UXmatters

Dobré shrnutí teoretického přístupu a zajímavé nahlédnutí do procesu budování interakčního modelu pro rozsáhlou aplikaci ve velké firmě (HP).

Popisovaná aplikace — jakýsi cestovní portál, který má „transform the future of travel”, ehm — byla komplikovaná v tom, že potřebovali pokrýt více uživatelů s naprosto jinými cíli a tedy jinými interakčními modely. Vlastně je to jako navrhovat několik aplikací a ještě střechu nad nimi.

Pokud máte malý projekt, může vám dobře k zachycení interakcí posloužit třeba i jednoduchá technika, protože ten vysoko-úrovňový pohled se dá shrnout třeba do toho, že „zákazník potřebuje vystavit fakturu”. Každopádně i tak potřebujete tuhle oblast promyslet.

Autor je malinko jetej v „corporate speaku”, takže to si musíte přefiltrovat, ale za přečtení rozhodně stojí.

Za odkaz díky @janrezac

Další termín školení bych viděl někdy na polovinu dubna, ale to ještě upřesním tady na blogu.

Mimochodem, to je taky jeden z důvodů, proč jsou web aplikace stále v zárodku boomu: HTML5 je jediná jednotná platforma pro velkou většinu mobilního trhu.

Via @venca

Via @enoice

Co vás můžu naučit je, jak nad tím vším uvažovat a kde se dál učit.

Mým cílem je udělat školení, které bych býval velmi rád absolvoval před nějakými třemi roky a koneckonců bych si ho dal i dnes, abych věděl, jak uvažuje a pracuje někdo jiný.

Program školení

1. Byznys strategie: CO a JAK vůbec dělat
Zamyšlení nad situací na trhu, kam chceme proniknout, jak určit záběr a cílovou skupinu zákazníků. Jak organizovat samotný proces tvorby aplikace.

2. Wireframy, flow a prototypování
Jak se dostat od představy o obchodním modelu k něčemu, co se dá testovat.

3. Copywriting
Váš produkt hovoří všemi texty, představují důležitou část UI/UX.

4. Typografie
Pokud šaty dělají člověka, typografie dělá UI.

Jednotlivé obsahové celky jsou proloženy zhruba 6 praktickými cvičeními, na která se budu snažit vyhradit většinu času. Věřím, že to bude nejlepší cesta, jak opravdu ukázat způsob myšlení nad řešením výzev tvorby web aplikace. Školení bude maximálně pro 10 lidí, aby dobře fungovala interakce při cvičeních.

Odvyprávím kousek teorie, pak zadám cvičení, které by pro úvodní část wireframů mohlo znít třeba „Představte si, že banka po vás chce udělat lepší rozhraní pro správu účtu. Na co se budete ptát?“ Nechám 10 minut na rozmyšlenou, pak si projdeme, co jsme vymysleli a posuneme se do další fáze.

Beta test pořádám proto, že chci ověřit, kolik se toho dá stihnout, kolik času věnovat jednotlivým částem výkladu a hlavně kolik času si vyžádají cvičení.

Co ve školení nebude je výuka CSS, HTML ani JavaScriptu. Počítač byste neměli potřebovat, ale klidně si ho vezměte. Určitě vás nasměruji na zdroje, kde se o HTML5 z pohledu web aplikací můžete dozvědět dost a dost. Možná na to udělám časem extra školení, ale tohle to nebude. Jen aby bylo jasno ;-)

Pro koho se školení hodí

Vidíte v tvorbě web aplikací otevírající se příležitost? Uvažujete o tom, že byste vytvořili nějakou vlastní? Láká vás založení startupu? Máte už firmu a potřebujete nastavit svůj tým správným směrem? Baví vás tvorba uživatelských rozhraní a chcete se zlepšit? Chcete získat slušný základ v obchodní strategii a v organizaci procesu tvorby web aplikace?

Pokud jste na něco odpověděli „Ano“, nemělo by vás školení zklamat.

Školení přímo u vás ve firmě

Nabízí se možnost kombinace školení a konzultace nad vaším produktem. Ozvěte se.

Kdy, kde a za kolik

Kdy: 29. března, 10:00-19:00
Kde: Praha, místo upřesním
Počet účastníků: 10
Cena na osobu: 5 000 Kč Beta test cena 2 500 Kč vč. DPH

Jak se přihlásit?

Prostě mi napište.

Via @dnna

Ještě méně abstrakce, méně tlačítek, plynulé flow, rychlost, rychlost, rychlost.

— Zdroj Jason Fried, Basecamp Next: UI preview

Za přečtení rozhodně stojí vysvětlení DHH, jak se jim podařilo dosáhnout takové rychlosti odezvy. Spoiler: HTML5 pushState a cacheování až za hrob.

Přídáno 19. 2. 2012: DHH blíže vysvětluje cacheování v Rails.

What’s new with SaaS (Software as a Service) products like Basecamp is that legacy doesn’t just build up in the code base, it builds up in customer expectations. People get used to the way things are. Even things that are broken or complicated become things some customers want to protect from change because they’re familiar with the intricacies of how those things work.

— SaaS: Change starts easy and then gets really hard

Nemyslím, že by to byl nový problém. „Normální software” tohle přece řeší už dávno. Microsoft si taky nemůže dovolit udělat Word úplně jinak. Souhlasím s tím, že jediné rozumné řešení je oddělená nová aplikace.

Článek Box sizing předkládá celkem snadné řešení: Přepněte si box model do toho, co měl IE 6, tj. deklarovaná width bude ta skutečná a padding + border se „odčítají dovnitř”. Příklad pro jeden element:

textarea {
	-webkit-box-sizing: border-box; /* Safari/Chrome, other WebKit */
	-moz-box-sizing: border-box;    /* Firefox, other Gecko */
	box-sizing: border-box;         /* Opera/IE 8+ */
}

Paul Irish doporučuje to rovnou hodit na všechny elementy, ale tím si nejsem tak jistý.

Via Pavel Bier

Here’s a look at some of the most prominent changes:

• Completely overhauled documentation for nearly every component
• A brand new Customize page to tailor your Bootstrap experience
• New 12-column, responsive grid system
• New table styles with a common base class for improved compatibility with other tools
• New form styles with smarter defaults, requiring less HTML
• Icons, graciously provided by Glyphicons
• New, smarter navigation components
• New buttons, button groups, and button dropdowns
• New, simpler alert messages
• New javascript plug-ins like carousel, collapse, and typeahead

— Twitter Developers, Say hello to Bootstrap 2.0

Via Pavel Moravec

Mimochodem, pokud by snad některá banka měla zájem o moje služby jako konzultanta na UI, ozvěte se. Upřednostnil bych FIO, protože tam máme účet s Fakturoidem.

HP today announced it will contribute the webOS software to the open source community.
…
HP will engage the open source community to help define the charter of the open source project under a set of operating principles:

— Tisková zpráva HP

Ha, kdo by to byl řekl! Osobně jsme tipoval, že ho koupí Amazon, nebo nějaký výrobce hardwaru, třeba HTC. To, že HP uvolní webOS jako Open Source si těžko dovedu vysvětlit jinak, než že ho nikdo nechtěl koupit, což je celkem zarážející.

Rád bych věřil, že to povede k rozkvětu webOS, ale spíš se obávám, že umře pro nezájem výrobců zařízení i vývojářů.

Via Daring Fireball

<form action="/cesta_zpracovani" method="post">
  <p>
    <label for="user_name">Uživatelské jméno</label>
    <input type="text" id="user_name" name="user_name">
  </p>
  <p>
    <label for="email">Váš email</label>
    <input type="text" id="email" name="email">
  </p>
  <p>
    <input type="submit" value="Odeslat">
  </p>
</form>

Jak zabránit spamům, aby nám otravovali život, aniž bychom zatěžovali uživatele nějakou tou CAPTCHA ochranou?

Trik

Náš jednoduchý trik spočívá v tom, že přidáme do kódu další políčko, které nám poslouží jako past na spam boty.

<form action="/cesta_zpracovani" method="post">
  <p>
    <label for="user_name">Uživatelské jméno</label>
    <input type="text" id="user_name" name="user_name">
  </p>
  <p>
    <label for="email">Váš email</label>
    <input type="text" id="email" name="email">
  </p>
  <p id="very_important">
    <label for="comment">Nevyplňujte</label>
    <input type="text" id="comment" name="comment">
  </p>
  <p>
    <input type="submit" value="Odeslat">
  </p>
</form>

Pomocí CSS naši pastičku schováme před lidmi. Třeba takto:

#very_important
{
  overflow: hidden;
  position: absolute;
    left: -5000px;
  visibility: hidden; /* kvuli prepinani tabelatorem */
}

Pak už je to opravdu jednoduché. Jelikož lidé tohle políčko nevidí, nemohou ho vyplnit, kdežto spam boti jedou v kódu a budou se snažit přes něj protlačit svůj obsah. Nám už při zpracování formuláře jen zbývá zkontrolovat, jestli se něco chytlo do pastičky.

Nevýhody

Očividná nevýhoda je, že ať už z jakéhokoli důvodu návštěvník políčko uvidí, bude ho mást, dost možná ho vyplní a spadne nám do spamu. Pravděpodobnost dostatečně malá, abych ji byl ochoten podstoupit místo toho, abych zatěžoval uživatele CAPTCHAou (nebo jak by se to mělo psát).

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.

Společné body s copywritingem

Pro psaní mikro-textů si můžeme vypůjčit pár východisek z „normálního” copywritingu.

• Mluvte jazykem čtenáře
• Udržte si vlastní styl
• Pište tak, abyste si chtěli výsledek sami přečíst
• Vynechte zbytečná slova

Web aplikace ale vytváří zvláštní prostředí, které před nás staví jiné výzvy.

Specifika mikro-textů ve web aplikacích

Předně je tu ještě větší tlak na stručnost. Tam, kde můžeme v prezentaci nebo článku vysvětlovat něco odstavcem textu, musíme v aplikaci vystačit s pár slovy. Jednak proto, že jsme omezeni uživatelským rozhraním, které není nafukovací, ale také proto, že potřebujeme uživatele rychle zaujmout, nebo ho rychle provést nějakým úskalím, aby se dostal ke svému cíli.

Pokud se nám nedaří něco stručně vysvětlit, může to být dobrý ukazatel toho, že máme problém se samotným návrhem dané části aplikace.

Potíž je také v tom, vědět, kdy vůbec něco psát, nebo kdy a jak se nutnosti něco psát vyhnout. Určitě znáte situaci, kdy z nějakého seznamu mažete položku a celá stránka se znovu nahraje, koukáte se na vršek stránky, ať jste třeba byli odskrolovaní někde uprostřed a v lepším případě vidíte zelný obdélník s kreativní zprávou „Položka byla smazána.” Místo toho bychom mohli po kliknutí na tlačítko Smazat zavolat AJAX, zanimovat zmizení řádku, nevypisovat nic a uživatel by měl naprosto plynulý zážitek.

Pak si musíme dát pozor na konzistentní slovník. Nazýváme části naší aplikace vždycky stejně? Používáme ke stejným akcím stejné výzvy? Dobrý tip je vytvořit si seznam všech textů, abychom měli přehled o tom, jaké výrazy používáme a taky se tam lépe odhalují překlepy a jiné chyby.

S tím souvisí i třešnička na vývojářově dortu – myslet při tom všem ještě na charakteristický hlas naší aplikace, styl, jakým k uživatelům mluví. Ve Fakturoidu se třeba snažíme, aby vše říkal robot za sebe, v první osobě. Jsem přesvědčen, že to pomáhá na několika rovinách, jednak je to netradiční a odlišuje nás to, pak to dává prostor k různým vtípkům, které se podílí na lepším dojmu uživatele a v neposlední řadě, to posiluje vztah lidí k Fakturoidu. Největší radost nám pak dělá, když uživatelé hrají tu hru s námi a emaily na podporu se obrací přímo na robota. My se pak podepisujeme třeba: „Za robota z nul a jedniček přeložil…” :-)

Vybral jsem pár typických míst, která vyžadují největší pozornost a na ty se podíváme příště.

Prázdné obrazovky

Prázdné stránky (blank slate) jsou obrazovky aplikace, kde uživatel ještě nevytvořil žádná data a není tedy, co vypisovat.

Příklad z Fakturoidu: Po prvním přihlášení se objevíte na úvodní obrazovce, kde později budou statistiky vašich příjmů za poslední tři měsíce, posledních šest vystavených faktur, nejbližší pravidelné faktury, přehled posledních události ve vašem účtu a pár dalších věci. Nic z toho tam ale není, protože jste ještě nevystavili žádnou fakturu. Jako tvůrci aplikace máme v tomto okamžiku protichůdné cíle.

Chceme čerstvému uživateli ukázat, co tady později bude, ale jak na to? Nejčastější způsob je screenshot zaplněného rozhraní. Výhodou tohoto řešení je, že ho vytvoříme velmi jednoduše. Nevýhodu vidím v tom, že může být poměrně matoucí. Zaplněná úvodní obrazovka, kde nepoznáváte názvy firem, částky, datumy… Navíc screenshot není interaktivní a musíme ho nějak „zašednout” nebo jinak odlišit od skutečného obsahu, aby se uživatelé nesnažili klikat na nefunkční obrázek a nebyli hned na začátku malinko frustrovaní.

Zároveň potřebujeme nasměrovat uživatele do Nastavení, kde musí ještě vyplnit jedno políčko a když už tam jsou, chceme, aby si nastavili výchozí hodnoty pro splatnost, DPH a to si vyžádá odstaveček textu, který musí být dobře vidět.

A nezapomínejme na to, že uživatel není zrovna nadšený a plně soustředěný na naši aplikaci. Dorazil přes nějaký odkaz na Facebooku, otevřel si naši prezentační stránku v tabu a pokračoval v prohlížení fotek přátel. Pak se mrknul na prezentaci a z nějakého důvodu patřil k těm, kteří nám zvedají konverzní poměr a vytvořil si účet. Právě prošel registrací a zrovna mu někdo volá. O pět minut později se přihlásí, ale zároveň myslí na to, že mu volala manželka, co má koupit, až půjde z práce a do toho potřebuje ještě rychle vystavit fakturu.

OK, možná to nebude úplně typický příklad, ale víte, kam tím mířím.

Jako v tolika jiných věcech při budování aplikací, je příprava obsahu pro prázdné obrazovky o hledání správného přístupu a vyvažování mezi protichůdnými požadavky.

Chybové a jiné hlášky

Hlášky jsou vopruz. Vypsat hlášku skoro vždy znamená přerušit plynulý uživatelský zážitek. Pokud můžete vyhněte se tomu.

Tak třeba, pokud uživatel vidí výsledek své akce, dost možná mu nemusíme nic psát. (Alá scéna „Stěrače stírají.” z Vrchní, prchni.)

Příklad: Když ve Fakturoidu odešlete vyplněný formulář s novou fakturou, který neobsahuje chyby, nahraje se obrazovka právě vytvořené faktury a to je všechno. Žádná hláška se nevypíše.

Myslím, že vypisovat „Faktura byla úspěšně vytvořena” nebo něco takového, je ukázkové zbytečné rušení, protože uživatel vidí, že byla vytvořena a je na stránce, kterou zná z jiných vytvořených faktur a může plynule přejít na to, že v sidebaru klikne na Poslat emailem.

Přístup „show, don’t tell” dal vzniknout Yellow Fade Technique (Bože, to už je to 7 let!… tyjo…), kdy se zvýrazní aktualizované části obsahu.

Když se hlášce nemůžete vyhnout, zkuste vymyslet, jestli by se nedala nějak zvednout její „hodnota”. Pro ilustraci opět do Fakturoidu: Když vytvoříte nový kontakt vypíšeme hlášku, která vám kromě oznámení, že byl vytvořen, nabídne, jestli nechcete vložit další kontakt, nebo mu rovnou vystavit fakturu.

Ještě krátce k chybovým hláškám, které by také samy o sobě vydaly na článek. Pokud to jde, zvýrazněte celý chybný input, ať uživatel nemusí hledat místo, kde se chyby dopustil, a někde blízko stručně vysvětlete, co je špatně a jak to má napravit. A nebojte se dát do toho trochu kreativity a vtipu – uživatel se právě „praštil do hlavy”, zkuste mu bolístku trochu „pofoukat”.

Tlačítka

Texty na tlačítkách jsou mikro-texty svlečené do naha. Musíme být maximálně struční. Víc než dvě slova už jsou často problém jak z hlediska toho, co nám dovolí uživatelské rozhraní, tak proto, že nechceme zbytečně zatěžovat mozek uživatele.

Ze všeho nejvíc tu platí: Myslete z pohledu uživatele. Při hledání vhodného výrazu se snažím představit, co bych jako uživatel sám očekával a hledal.

Příklad: Ve formuláři nové faktury jsme chtěli nabídnout možnost přepnout se na proforma fakturu. Jaký text zvolit? „Přepnout na proformu”? Tři slova, moc dlouhé. Jen „Proforma”? To je zase málo. Co se mi honí hlavou, když chci vystavit proformu? No, „Chci proformu”!

Je jasné, že tohle jsou hodně domněnky a pokud děláte na aplikaci, kterou sami nepoužíváte, rozhodně byste měli všechny své závěry testovat na skutečných uživatelích, což ostatně platí pro všechno výše uvedené.

Když jsem ho začínal psát, myslel jsem, že to bude kratší článek, teď je mi tak akorát jasné, co jsem všechno nezmínil. Ale proto zase připravuju to školení, kde bude víc času hlavně na praktická cvičení. Budete mít někdo zájem, žejo? ;-)

MailChimp – freemium až později

MailChimp v článku Going Freemium: One Year Later píší, že původně žádný free tarif neměli a to „původně” tu znamená několik let. Dočtete se, že k vyzkoušení freemia se rozhodli, až když měli fungující byznys a mohli si ten risk dovolit.

Bidsketch – zrušené freemium

Ruben Gamez v Why Free Plans Don’t Work* popisuje svou zkušenost, kdy se rozhodl na chvíli free tarif odstranit z přehledu, protože si všiml, že i jiné firmy je, jemně řečeno, upozaďují. Zjistil, že díky tomu má 10× lepší konverze.

Vzpomněl jsem si přitom na Jasona Frieda, který v téhle přednášce na FOWA Miami 2009 už před časem řekl: „Free converts, but paid converts even better.”

Takže nebuďte jako já a zamyslete se, jestli je pro vaši aplikaci freemium model opravdu nutný/vhodný.

* Za odkaz děkuji @MarekP

Zdroj ilustrační fotografie

Cílem bylo motivovat a ukázat směr. Hodně jsem toho nachodil a vyjadřování taky pokulhává. Dal bych si tak 6 z 10. Na druhou stranu to byla teprve moje druhá přednáška, tak snad se ještě zlepším ;-)

Předem se omlouvám za školáckou chybu, kdy jsem neopakoval dotazy z publika, takže nejsou slyšet.

Nebudu se rozepisovat o tom, co pro mě tenhle projekt znamená, věřím, že to bude znát z příspěvků na jeho blogu a hlavně z web aplikace samotné.

Dejte si nás do čtečky nebo přidejte svůj email, sledujte Fakturoida na Twitteru a držte nám palce.

Díky!

Ne moc OK

Pardubičtí OK Computers nahrávají uživatelům na to, aby si sami smazali obsah košíku, když se do něj chtějí podívat. Řešení: Odkaz na vyprázdnění košíku bych dal klidně až na stránku, kde se obsah košíku zobrazuje. Bude snadnější mu tam najít vhodný prostor. Minimálně to chce ten odkaz oproti linku na zobrazení košíku znevýraznit a oddálit.

Přidat sloupec, he?

phpMyAdmin je celkově ukázka programátorského UI, ale málo co to ukazuje tak, jako tahle tlačítka. Najdete je při přidávání sloupce do tabulky. Představte si, jak vyplňujete ty kolonky, přemýšlíte, jestli budete potřebovat VARCHAR, nebo TEXT, nacvakáte zbytek a pak automaticky kliknete na ten čudlík vpravo, protože tam jsme zvyklí vždy najít potvrzení právě prováděné akce. Takže kliknete a co se nestane – objeví se vám políčka pro další sloupec. Řešení: Vpravo má být větší „Ulož”, nebo ještě lépe „Přidat sloupec” a rozhraní pro zobrazení více políček by mělo být vlevo s textem „Políčka pro [ 2 ] sloupce (OK)”.

Koupit lístky?

A do třetice, tentokrát Ticketpro.cz. Velmi podobná chyba jako u phpMyAdminu. Jsem ve fázi, kdy zadávám počet lístků, které chci koupit. Myší kliknu na okýnko, vyplním číslo a jedu doprava, kde si v lepším případě všimnu ikonky lupy a řeknu si, že něco není v pořádku. Tahle čtyři tlačítka prostě nemají mít stejnou váhu a už vůbec by neměla být v tomhle pořadí. Řešení: „Přidat do košíku” má být výrazně větší než ostatní a umístěné vpravo pod políčky na počet lístků. Pod něj, bych dal obyčejný odkaz na zobrazení obsahu košíku. „Zpět” umístit doleva a „Nové hledání” doprava nad tabulku.

Nedělejte nízká futra

Doufám, že si nikdo ze čtenářů nemyslí, že jde o prkotiny. Tohle jsou chyby, které se dají snadno napravit, ale to neznamená, že by byly malé. Mohou velmi pokazit dojem, který uživatel ze stránek bude mít. Navíc ve všech výše uvedených příkladech je pravděpodobné, že bude tomuto rozhraní vystaven opakovaně. Je to, jako si pravidelně na návštěvě u kamaráda na chalupě dát o nízká futra dveří.

Řečený meta tag má tvar:

<meta name="apple-mobile-web-app-capable" content="yes" />


Pokud přidáte web aplikaci ošetřenou tímto meta tagem na hlavní obrazovku iPhonu a máte firmware verze 2.1, otevře se bez panelů Safari, které jinak web aplikace a webové stránky na iPhonu mají. Bude k nerozeznání od nativních aplikací.

Vyzkoušejte na téhle demo aplikaci

Tak si říkám, že je na čase se pořádně podívat na obsah sekce Apple Developer Connection věnované vývoji web aplikací pro iPhone.

Normálně bych býval přidal Pattern Tap jen do svého feedu pro odkazy, ale ta stránka je tak dobrá, že by mi bylo líto, kdyby ji vidělo jen nějakých těch 20 lidí, kteří zatím můj odkazový feed odebírají.

Pattern Tap vás nechá založit si na stránce účet, kam si pak můžete ukládat příklady, které se vám obzvlášť líbí. Co víc, můžete si dokonce najít některé uživatele a sledovat jejich sbírku.

Pencil Project je a bude k dispozici zdarma – alespoň to tvůrci hrdě prohlašují.

Nepočítám s tím, že by v blízké době nahradil skvělý program OmniGraffle, který na wireframy používám teď, ale někomu by se hodit mohl.

Select má smysl použít pouze tam, kde máme omezený prostor a potřebujeme nabídnout výběr z více možností. Za úsporu platíme jednak tím, že uživatel musí jednou navíc kliknout — pro rozbalení nabídky — ale pak také tím, že ihned nevidí jaké možnosti se mu nabízejí. Možná se vám to na první pohled nezdá, ale je to velká daň.

Pozor na takovéhle situace:

Celý zbytek stránky je volný

Tady select nedává smysl

Takže až příště budete uvažovat o selectu, položte si otázku, jestli náhodou nemáte místo pro radio buttony nebo checkboxy.

Sám jsem měl pro sebe Fittsův zákon zjednodušený zhruba do podoby „čím větší objekt, na který se kliká, tím jednodušší je trefit se na něj”. Ve skutečnosti je to složitější, ale o to užitečnější.

Matematika nuda je, má však cenné údaje

Nebojte, nebude to bolet. Nejdřív postraším vzorečkem:

MT = a + b log₂(2A/W)

• MT je průměrný čas pro dokončení pohybu
• A je vzdálenost počátečního místa pohybu do středu cílového objektu (např. tlačítka)
• W zastupuje šířku cíle podél osy pohybu
• a, b jsou empiricky zjišťované konstanty týkající se rychlosti pohybu (podrobněji viz Wikipedia)

Tento vzoreček můžeme interpretovat asi takhle: „Čas potřebný pro dosažení cílového objektu odpovídá logaritmické funkci vzdálenosti a velikosti cíle”

Logaritmická funkce má zajímavé důsledky. Pokud je cílový objekt malý, tak i jeho malé zvětšení povede k výraznému zkrácení potřebného času. Analogicky pro vzdálenost objektu. Typickým příkladem jsou prosté textové odkazy v porovnání s tím, když jim dáme ještě padding a roztáhneme tak aktivní oblast. Myslím, že snadno poznáte, který je který. Zkuste si párkrát přijet z různých míst na oba odkazy. Rozdíl je výrazný.

Tohoto efektu můžeme samozřejmě použít i „opačně” – pro ztížení přístupu k funkcím, které by měl uživatel aktivovat s větší pozorností (typicky mazání).

Všimněte si také, že šířka cíle se počítá podél osy pohybu, takže u pohybu zdola nahoru je to vlastně výška. Pří návrhu tedy musíme myslet i na to, který rozměr se vyplatí zvětšit, což může být samozřejmě mnohdy těžké určit (nějaká pomoc by se našla).

Nekonečné rohy a okraje

Virtuální prostor displejů našich počítačů dává Fittsovu zákonu další zajímavý „rozměr”. Představte si totiž takové tlačítko (nebo jinou aktivní plochu) umístěné na okraji obrazovky. Pokud na něj najíždíme myší, nemusíme se starat o to, jestli ho přejedeme, protože nás zastaví pevný okraj plochy. V tu chvíli má pro nás tlačítko v tomto směru vlastně nekonečnou šířku. Nejvýhodnějším místem jsou tedy rohy displeje, protože ty jsou „nekonečné” ve dvou směrech.

Okno webového prohlížeče tuto tvrdou zarážku sice nenabízí, ale přesto mám takový pocit, že podvědomě začneme brzdit pohyb myši dřív, když najíždíme k okrajům, protože nechceme „vypadnout z okna”.

Nožičky a závěr

Je hezké vidět, kolik složitosti se skrývá za něčím zdánlivě tak triviálním, jako je pohyb a klikání myší, ne? Rozhodně doporučuji, abyste se mrkli na tenhle kvíz, protože ukáže aplikaci Fittsova zákona na řešení praktických problémů. Nějaké připomínky, nápady na jiná témata kolem uživatelského rozhraní, která si zaslouží vypíchnout?

Související odkazy

• Particletree, Visualizing Fitts’s Law
• Mind Hacks, Size and selection times: Fitts’s Law
• Kvíz na použití Fittsova zákona v praxi
• Usability Tools Podcast: Applying Fitts’ Law
• Doktorandská dizertace na téma Fittsův zákon

Google App Engine je zatím v otevřeném beta testování pro prvních 10.000 vývojářů. Nabídne zdarma:

• 500 MB místa pro aplikaci
• Dostatek výpočetního výkonu a propustnosti pro 5 miliónů zobrazení stránek na den měsíc

Zatím nejsou zveřejněny ceny za překročení těchto omezení, ale Google zaručuje, že tyto služba zůstana zdarma v těchto parametrech i po ukončení beta testování.

Na rozdíl od webových služeb Amazonu, které můžete použít nezávisle na sobě — tj. třeba jen úložiště S3, nebo jen výpočetní výkon EC2 — je Google App Engine navržen jako ucelené prostředí, kde využijete služeb Googlu vše kolem vaší webové aplikace. To může být výhoda i nevýhoda.

Prozatím App Engine podporuje pouze Python skripty, ale do budoucna je plánována podpora i dalších jazyků.

Hlavní přínosy pro vývojáře by měli být ve snadném nasazení aplikace a v automatické škálovatelnosti – nemusíte se bát, že by servery Googlu nezvládly nečekaný nápor uživatelů.

No, uvidíme, co se z toho vyklube a jaké budou dojmy betatesterů.

Další zdroje

Video ukazující klasickou Hello World aplikaci v App Enginu a něco navíc. Na mě to působilo poněkud nepřehledně, ale to může být tím, že neznám Python.

Odkazy na články:

• TechCrunch
• Google App Engine Blog

Asi před dvěma týdny ohlásilo Yahoo, že všechny jeho uživatelská ID budou fungovat také jako OpenID. A včera bylo oznámeno, že se do výboru (board) OpenID Foundation přidali zástupci IBM, Google, Verisign a pozor … Microsoftu!

Třikrát sláva!

Moje OpenID identita sídlí na jankorbel.myopenid.com

Aktualizováno: Díky Ivanovi za tip na českou odnož OpenID.cz

Aktualizováno: Mnohem podrobnější příspěvek na toto téma najdete na Všemi osmi Marka Prokopa.

Vezmu to trochu oklikou, tak mějte následující dva odstavce strpení.

Když jsem někdy v polovině roku 2005 kupoval od bráchy jeho tehdy asi 3 roky starý notebook Acer s Pentium M na 1,6 GHz, říkal jsem si, že si na tom vyzkouším, jak mi půjde používat přenosný počítač jako hlavní pracovní stanice a pak případně investuju do něčeho nového, výkonnějšího.

Ke svému překvapení jsem zjistil, že nic výkonnějšího nepotřebuju. Na tom notebooku mi pár věcí vadilo, ale ty byly spíš na straně Aceru. Rozhodně bych si nestěžoval na výkon procesoru.

A včera jsem narazil na zprávu, kde Intel zveřejňuje detailnější informace o své nové generaci procesorů pro ultramobilní zařízení.

Jak už jsem prozradil v nadpisu, výkon těchto čipů bude někde na úrovni právě toho Pentia M, který mi klidně nahradil můj tehdejší desktopový počítač. Zdůrazňuji, mluvíme tu o procesorech, které jsou určeny pro mobilní telefony a PDA! Zjednodušeně řečeno: Pro běžné aplikace se velmi brzy smaže rozdíl mezi tím, co nám sedí na stole a tím, co nosíme v kapse.

A pak mi došlo jaká obrovská práce a jaké obrovské možnosti tu čekají vývojáře. Tyhle věcičky budou potřebovat úplně jiné uživatelské rozhraní, jak pro systém, tak pro aplikace. Bude potřeba vymyslet jiný přístup k synchronizaci dat, mnohem plynulejší. To, že takové zařízení budete mít stále u sebe, dá vzniknout ještě netušeným použitím. Jsem přesvědčen, že nějaké ty reklamy cílené podle GPS pozice budou jen první dětské krůčky k mnohem zajímavějším aplikacím.

Já vím, že o tomhle všem už se nějaký čas mluví, ale v tom srovnání s Pentiem M mi to konečně nějak docvaklo. Tak snad nejsem sám ;-)

Aktualizováno: Aha, tak třeba autor tohohle článku na Ars Technika si nemyslí, že by to byl nějaký převrat na poli mobilních procesorů. Podle něj je to jen takový uvítací pozdrav Intelu, který zatím může nechat ostatní výrobce klidnými.

Další zdroje

• PC World
  
• Register Hardware

Aktualizováno 3. 3. 2008: Silverthorn je nyní znám jako Atom, zdroj Intel.

Je to jednoduché: Zaregistrujete se na jedné z níže uvedených služeb, umístíte do stránek, které chcete sledovat kus javascriptu a pak už jen čekáte, až se vám zpřístupní rekonstruované video sekvence chování uživatelů.

Přínos pro ladění stránek a web aplikací je zřejmý. Levně a jednoduše můžete sledovat, jestli vše funguje, jak jste plánovali, můžete rychle reagovat na místa, kde se uživatelé ztrácí, ladit formuláře atd. atd… A co je důležité, po nasazení javascriptů jsem nezaznamenal žádné zpomalení načítání nebo odezvy stránek.

Zkusil jsem dvě služby: RobotReplay a ClickTale. Tady jsou moje dojmy.

RobotReplay

Služba je zatím zdarma, neuvaluje na vás žádná omezení, pokud jde o počet stránek, které chcete sledovat nebo počet video sekvencí, které vám zpřístupní. Bohužel, je zdarma jistě také proto, že je dost chybová. Některé sekvence se vůbec nerozjedou, jiné se podivně zaseknou. Ale určitě se vyplatí sledovat, jak bude pokračovat vývoj, protože i přes chyby vypadá projekt slibně.

Promo video služby RobotReplay

ClickTale

Nabízí free verzi, která vás omezí na 100 zaznamenaných stránek týdně. Pro vyzkoušení rozhodně stačí, i pak je cenová politika přijatelná. ClickTale poskytuje mnohem spolehlivější výsledky, je vidět, že je to už odladěná služba.

Zaznamenaná sezení si můžete uložit lokálně a příjemné je, že výsledné soubory jsou velmi malé.

Podívejte se na příklad jak výsledné video vypadá…

(Pozor! Zaškrtněte si Automatic next, abyste nemuseli ručně přepínat na další zaznamenané navštívené stránky. Jo, a jak upozornil v komentářích honza, nefunguje to v Opeře.)

Shrnutí

Zatím se mi víc líbí ClickTale, ale budu sledovat i RobotReplay, když odstraní bugy, bude jejich služba rovnocenná. Pro obě pak platí, že budou potřebovat daleko lepší nástroje na třídění zaznamenaných sezení. Rád bych třeba tvořil výběru typu „Uživatelé začli na titulce a pak se během sezení dostali na stránku Ceník to vše za posledních 14 dní”. To zatím není možné. Ale i tak jsem ještě v rauši z toho, co se před námi otevírá za možnosti.

Zdá se mi, že sekce byla šita horkou jehlou. Nemá vůbec applovskou pečeť dokonalé typografie, která je jinak pro jejich web typická. Nicméně už zde můžeme najít základní doporučení, jak pro iPhone vyvíjet.

Myslím, že použité členění textu s javascriptovým rozklikáváním je nešťastné a brzy dozná úprav.

Každopádně je to tu, stojí to za shlédnutí a občasnou návštěvu v budoucnu, protože obsah bude určitě přibývat.

http://developer.apple.com/iphone/

Upraveno:Apple asi od včerejška (24. 10. 2007) vyžaduje pro přístup do developerské zóny pro iPhone registraci. Zároveň rozšířili obsah sekce a obdařili jí hezčí typografií.

Ještě než začneme s ostatními částmi, mám tu drobnou úpravu titulky, uvádím ji spíš proto, aby pak byly všechny wireframy na jednom místě, než že by na tom extra záleželo. Jde o to, že v minulém díle jsem navrhoval po najetí myši nabídnout uživateli možnost označit fakturu jako zaplacenou a menší ikonu pro úpravu faktury. Když jsem o tom pak přemýšlel, přišlo mi užitečnější dát tam spíš možnost zobrazit celou fakturu na obrazovku — ikona lupa — s možností rovnou ji vytisknout.

Obrázek č. 1 – Úvodní stránka aplikace, PDF verze

Mohli byste se ptát, proč odkaz „Zaplaceno” tvoří slovo, zatímco odkaz na náhled jen malá ikona? Jde o aplikaci obecného pravidla, kdy se snažíme dát větší prostor a usnadnit přístup k tomu, co bude uživatel dělat častěji a znesnadnit to, co by ho mohlo odvést na špatnou cestu nebo mu jinak „ublížit”. Je to motiv, který budu opakovat často, takže stojí za vypíchnutí.

Ale teď už pojďme dál.

Stránka přidání/upravení faktury

Obrázek č. 2 – Přidání/upravení faktury, PDF verze

Obsah této stránky máme z velké části daný náležitostmi faktury, ale výzva, jak to všechno přehledně poskládat, není zanedbatelná. Rád používám layout, ve kterém jsou popisky polí formuláře (tag label) formátovány nalevo, zarovnané ke svým pravým okrajům. Umožňuje nám to, rychle je přeletět pohledem, nemusíme oko a mozek zatěžovat tak, jako je tomu v případě, kdy jsou popisky nad jednotlivými políčky.

Jak vidíte, porušil jsem tento přístup pro políčka s datumy. Jednak už by pod sebou zabírala zbytečně moc místa a pak patří druhem obsahu k sobě, takže proč to nezdůraznit tím, že je dáme na jeden řádek.

Pak tu máme položky faktury. Platné sazby DPH máme pod kontrolou v sekci nastavení. Aplikace by mohla sama poznat, jestli je dodavatel plátce DPH a podle toho zobrazovat nebo nezobrazovat sazby DPH, ale i plátce nepřidává daň k fakturám do zahraničí, takže se nám bude hodit i třetí možnost „Ne”.

Při vstupu na stránku přidání faktury budou zobrazena jen políčka pro jednu položku, další si budeme moct přidat pomocí tlačítka (perfektní místo pro použití trošky Ajaxu). Na ubrání položek bude samozřejmě sloužit červené tlačítko vlevo od labelu položky.

Obvyklým výsledkem zadávání faktury je, že ji chceme uložit a vytisknout, proto je přesně tohle náplní největšího tlačítka, ale občas chceme fakturu jen uložit nebo jen vytisknout, odtud ta menší tlačítka.

Za zmínku stojí ještě malé odkazy na přidání dodavatele/odběratele. Už se mi několikrát stalo, že jsem šel přidávat fakturu a zjistil jsem, že v databázi ještě není odběratel, takže tady je řešení.

Vlastně stejné rozložení nám poslouží i při úpravě již vložené faktury. Drobné úpravy, které budou vhodné, nechám vaší představivosti. Pojďme se mrknout na stránku, kde se nám budou přidané faktury hromadit.

Stránka přehledu faktur

Obrázek č. 3 – Přehledu faktur, PDF verze

Jak vidíte z obrázku, nejvíce místa zabírá tabulka podobná té z úvodní stránky. Obsahuje všechny vydané faktury za dané období, přičemž nejnovější nahoře. Myslím, že teď už se v mém systému wireframů vyznáte, takže chápete, jaké možnosti se nabízí po najetí myší nad řádek s fakturou.

Na stránce máme k dispozici ještě menu pro přepnutí zobrazovaného období a druhu faktur. Později se nám možná bude hodit možnost vyfiltrování faktur pomocí podrobnějších kritérií, ale zatím to nebudeme řešit.

Stránka přehledu subjektů

Obrázek č. 4 – Přehledu subjektů, PDF verze

Uvažoval jsem tak, že nejčastější důvod, proč se budeme chtít podívat na subjekty, bude jejich úprava nebo smazání. Proto je pro přidání subjektu na této stránce vyhrazeno je velké velké tlačítko – obdobně jako bylo na titulní stránce pro přidání faktur.

Vidíte, že jsem zvolil výpis s výrazným řádkováním a velkými písmeny z abecedy, která nám pomohou při rychlém projíždění stránky. Od určitého počtu subjektů se nám bude hodit i možnost skočit přímo na dané písmeno, kterou nám dává menu pod tlačítkem „Přidat subjekt”.

Ve sloupcích Odběratel, Dodavatel jsem umístil symboly, které zároveň fungují jako přepínače — výchozí pozice je ta, kterou jsme zadali při vkládání subjektu, viz níže — kliknutím daný subjekt přiřadíte nebo naopak odeberete jako dodavatele/odběratele. K čemu to? No, pamatujete si ty selecty pro výběr subjektů při vkládání faktury? V databázi máme všechny subjekty v jedné tabulce, takže je v základu budeme mít všechny v obou selectech, což ale rozhodně nemůžeme potřebovat, protože drtivá většina z nich budou pouze odběratelé, tak proč si s nimi zbytečně zaplňovat select, kde nás nezajímají.

To samozřejmě znamená, že budeme muset odpovídajícím způsobem upravit model databáze, ale to se rozhodně vyplatí.

Stránka přidání subjektu

Obrázek č. 5 – Přidání subjektu, PDF verze

Teď už můj „wireframový rukopis” určitě znáte dost na to, abyste se v tomhle nákresu vyznali sami. Obdobně jako u faktur nám stejný layout poslouží i pro úpravu jíž vložených subjektů.

V komentářích k dílu o návrhu databáze mě Karel Benák upozornil, že budeme muset nějak pořešit mazání adres, protože smazaná adresa nám bude chybět při výpisu archivované faktury. Budeme tedy muset přihodit sloupec do tabulky, kde uložíme, jestli je adresa aktivní nebo ne.

Troufám si říct, že případ mazání adresy bude dostatečně výjimečný na to, abychom si v uživatelském rozhraní dovolili postarat se o něj tak, že neaktivní adresy vypíšeme až po aktivních s jiným, „zašedlým”, vzhledem. To bude pro začátek úplně stačit.

Stránka nastavení

Obrázek č. 6 – Nastavení, PDF verze

Nastavení je asi nejjednodušší stránka. Zatím mě napadlo, že budeme potřebovat nastavit aktuální sazby DPH, ale také musíme ze subjektů vybrat „sebe”, to jest subjekt(-y), jejichž faktury se mají započítávat do výnosů. Faktury všech ostatních subjektů půjdou do nákladů. A opět budeme muset upravit databázi, ale klidně na to budeme moci použít ten samý sloupec, který už jsme nuceni přidat pro rozlišení, jestli jde o dodavatele nebo odběratele.

Co dál s naší aplikací

Za normálních okolností by wireframy sloužily jako podklad pro grafika, který by naše nákresy oblékl do slušivého kabátku a my bychom zatím začali záměr implementovat v nějakém našem oblíbeném programovacím jazyku.

Já jsem se rozhodl, že pojmu další práci na web aplikaci jako praktickou lekci při mém učení Ruby a frameworku Ruby on Rails. Jsem totiž přesvědčen, že moje zkušenosti v PHP nejsou na takové úrovni, abych nějak výrazně přispěl k tomu, co se můžete dočíst jinde (viz zdroje níže). Moje základní rada, na kterou bych přísahal, je dodržujte architekturu MVC. Zjistíte, že vám vznikají kostky stavebnice a vy jste schopni z nich stavět různé výtvory. O přehlednosti, úspoře času a dalších výhodách nemluvě.

Samozřejmě se budu chtít se svými zážitky s Ruby on Rails podělit, takže tohle není poslední díl, jen nedokážu říct, kdy bude další. Už teď vidím, že budu minimálně následující dva týdny pracovně tak vytížen, že se k tomu dostanu jen zřídka. Ale uvidíme…

Shrnutí odkazů

• Všechna PDF wireframů a zdrojové soubory OmniGraffle (ZIP, 280 KB)
• Filosofie přístupu k budování aplikací – Getting Real
• Architektura Model View Controler (MVC)
• Ruby
• Ruby on Rails

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

Ostatní díly:

1. 
   1. díl – Návrh databáze
   
2. 
   2. díl – Uživatelské rozhraní
   

Naši databázi vidíte na obrázku č. 1, zde je soubor s SQL create příkazy a výsledný soubor DBDesigneru.

Obrázek č. 1 – Nová databáze pro jednoduchou aplikaci na tisk a evidenci faktur

Stručně o tom, co se měnilo:

• V původním návrhu by se nedala vůbec vystavit faktura, protože tam nebyl prostor pro částky a DPH, jak mě vtipně upozornil Jirka Pech. Ehm, inu tak. Tady si můžete přečíst mou chabou obhajobu.
• Byl jsem nucen uznat, že Jakub Vrána má pravdu, když říká, že zvláštní tabulka invoice_has_subjects je zbytečná a supplier_id i customer_id se nám přesunuli přímo do tabulky invoice.
• fous přispěl poznámkou o potřebě různých adres pro subjekty (sídlo, fakturace apod.)
• Sám jsem pak ještě vyhodil z tabulky subject pole pro kontaktní osobu a dal jsem je do tabulky person.

Taky vás tak fascinuje, když se začnete zabývat naprosto jednoduchým problémem a postupně zjišťujete, že v sobě skrývá složitosti, které se před vámi rozkrývají a každá cesta nabízí mnoho odboček a ty zase další a další?

Proto je důležité stanovit si nějaký základní cíl, což v našem případě je tisk a jednoduchá evidence faktur, toho se držet a zaměřit se pouze na to, co je naprosto nezbytné pro jeho dosažení a rychle se snažit dostat k uživatelskému rozhraní, k něčemu, co bude reálné. Mnohem lépe popsané to najdete v Getting Real.

Trik je v tom, kde udělat tu dělící čáru, co je naprosto nutné a co už je bonus.

Zároveň musíme myslet na možnosti budoucího rozšíření. V naší databázi je to třeba tabulka person nebo možné navázání dalších tabulek na task pro podrobnou evidenci času.

Trik je v tom, kde udělat tu dělící čáru, co je naprosto nutné a co už je bonus. Tady to bylo ještě celkem jednoduché, protože nutné je to, co se musí vytisknout na fakturu, u jiných aplikací je řez mnohem složitější.

Ještě jednou díky všem za připomínky. Budu snažit rychle napsat další díl. Reálně to vidím tak na 14 dní, protože v práci máme rozjeté projekty, které si v následujících dnech vyžádají většinu mého času. V hlavě mám ale pár menších článků, které snad stihnu publikovat dřív.

Zatím se mějte.

Ostatní díly:

1. 
   1½. díl – Dokončení návrhu databáze
   
2. 
   2. díl – Uživatelské rozhraní
   

Uvedu vás do děje. Se dvěma kamarády jsme začátkem roku 2003 začali podnikat jako tři živnostníci. Asi po půl roce ručního vyplňování faktur bylo jasné, že takhle to nepůjde. Jednak já strašně škrábu, ale hlavně jsme potřebovali mít jednoduše přístupný přehled, kdo kolik fakturoval, abychom se mohli podělit o kořist.

Vytvořit webové rozhraní pro tisk faktur a to rychle, rychle

Úkol zněl jasně…

Zadání tedy bylo: Vytvořit webové rozhraní pro vystavování faktur, jejich tisk a evidenci se základními statistikami. Znáte tu poučku, že projekt můžete udělat rychle, levně, dobře – vyberte si dvě? No, tenhle projekt byl pro nás, takže jsem vybral rychle a rychle. Levně se nám transformovalo do rychle, protože každá hodina strávená na tomhle, byla hodina nestrávená na práci, za kterou by někdo zaplatil. Jelikož jsem měl o svých programátorských schopnostech vcelku reálné představy, věděl jsem, že „dobře“ ani nebylo na výběr.

Návrh databáze

Uvažoval jsem asi takhle: Prioritu má tisk faktur. Nejdřív se budu zabývat tím, co je potřeba k tomu, aby z tiskárny vyjela faktura a pak tím ostatním.

K evidenci se dostanu později a budu chtít jen výpis podle data, vědět, kdo fakturu vystavil, komu ji vystavil, na jakou částku a jestli už je zaplacená.

Jaké entity tu mám? Faktury, klienty a nás jako dodavatele.

Jaké náležitosti má faktura: kromě informací o dodavateli a klientovi, které budou v příslušných tabulkách, tu ještě jsou datumy vystavení, splatnosti a zaplacení, text poskytnuté služby a částka.

Co musí obsahovat tabulka Dodavatel? Tady nám stačí jen to, co je nutné pro tisk faktury, protože dodavatelé jsme přece my. Název subjektu, ulice, město, PSČ, IČO, DIČ, číslo účtu a jako bonus jsem tam dal telefon (už nevím proč, asi jsem uvažoval, že by se mohlo číslo vypisovat na faktuře).

Tabulka Klient bude obsáhlejší, protože kromě údajů nutných pro tisk faktury, chci zaznamenat i informace, které by se mohly hodit později, kdybych chtěl na tenhle zárodek napojit nějaký systém správy kontaktů.

Když to propojíme dostaneme databázi, na které nám tisk faktur běží až do dnešních dnů.

Obrázek č. 1 - Celá původní databáze

Opravdu? Já myslím, že ne…

Kolika z vás se asi zatínaly nohy v pěst a kroutily nehty, když jste pročítali předchozí řádky? :) Přiznávám, byla to past a za případnou psychickou újmu se omlouvám. Chtěl jsem ukázat, jak bylo snadné udělat chyby, nad kterými mi dnes zůstává rozum stát. Pojďme se na to mrknout ještě jednou.

Předně je nesmysl oddělovat dodavatele a klienty do dvou tabulek. Jeden důvod je, že obě tabulky by obsahovaly prakticky stejné informace, kdybych neořezal dodavatele, kvůli tomu, že dodavatelé jsme byli jen my a o nás přece nepotřebuji podrobnější informace, ale hlavně budu určitě chtít evidovat i příchozí faktury, kdy někdo fakturuje nás, protože jinak se nedobereme k tak základním statistikám, jako je zisk za čtvrtletí. A co případ, kdy firma je jednou náš klient a jindy náš dodavatel? Pak už je úplně jasné, že jediné rozumné řešení je mít pouze jednu tabulku na subjekty, se kterými jsme v obchodním styku.

Obrázek č. 2 – Upravený vztah mezi fakturou a podnikatelskými subjekty

Druhý zásadní problém je, že do tabulky Faktura, jak jsem ji navrhl výše, nebudeme schopni zaznamenat fakturu, která má více položek. Jediná cesta, jak z toho ven, je vytvořit novou tabulku pro položky faktur. Možná by vás lákalo přímo do ní vložit cizí klíč faktura_id a tím provázat fakturu s položkou, ale to by byla také chyba. Zamysleme se v širších souvislostech. Třeba se rozhodneme později přidat rozhraní, kde budeme evidovat, na čem zrovna v daném projektu děláme a budeme chtít tuhle evidenci použít přímo pro tisk faktury. Pak nevyhnutelně vzniknou úkoly, které ještě nebudou položkami na faktuře a některé z nich tam nebudou nikdy. Potřebujeme tedy vztahovou tabulku invoice_has_task, kde si přiřadíme úkoly k fakturám.

Obrázek č. 3 – Předelaný vztah mezi fakturou a položkami faktury

Když už jsme v tom plánování budoucích rozšíření, bude dobré podchytit do samostatné tabulky i všechny projekty, na nichž pracujeme. Rozhodnutí, jestli vztah mezi úkolem a projektem zachytíme v samostatné tabulce, se bude odvozovat od toho, jestli potřebujeme/dovolíme, aby se jeden úkol vázal na víc projektů. Já jsem se rozhodl zahrát to na jistotu a radši tam vztahovou tabulku dám.

Nad rámec toho, co jsem chtěl dnes stihnout, je úvaha na téma navázání úkolů na pracovníky, propojení projektů se subjekty a mnoho dalších záležitostí, které si můžeme kolem fakturování a práce na položkách faktur vymyslet.

Až když uděláme k modelu nějaké rozhraní, ukáže se, co nás všechno nenapadlo.

Nožičky a závěr

Při návrhu databáze se vždy snažím dívat na daný problém z více stran, snažím se představit si možný budoucí vývoj. Zároveň se mi několikrát potvrdilo, že čím rychleji navržený model prověříme na skutečném nasazení, tím rychleji zjistíme, co jsme nedomysleli. Až když uděláme k modelu nějaké rozhraní, začneme databázi plnit a vypisovat reálná data, teprve pak se ještě ukáže, co nás všechno nenapadlo.

Proto bude příští díl o uživatelském rozhraní, které jsem pro fakturační systém vytvořil předtím a o tom, jak bych ho dělal teď.

Finální model databáze pro jednoduchý fakturační systém vidíte na obrázku č. 4. Pokud by měl někdo zájem, zde je soubor s SQL create příkazy a výsledný soubor DBDesigneru ¹. Rozhodně si o sobě nemyslím, že bych byl v návrhu databází nějaký expert, takže jsem zvědav na připomínky od vás.

Upraveno 26. 4. 2007

Jirka Pech mě upozornil, že mi z návrhu vypadly „drobnosti“ jako cena jednotlivého úkolu a sazba DPH. V komentáři vysvětluji, jak k tomu došlo, nicméně velký dík za upozornění. Aktualizoval jsem obrázky i soubory ke stažení.

Upraveno 29. 4. 2007

Nemohl jsem jinak (i když jsem se bráníl ;) ), než dát za pravdu Jakubu Vránovi a uznat, že vztahová tabulka mezi fakturou a subjekty je zbytečná. Zrušil jsem ji a supplier_id i customer_id jsou nyní součástí tabulky invoice

Na návrh fousa (jestli komolím, tak se omlouvám), jsem oddělil adresu do tabulky address a přidal ještě address_kind pro jednotlivé druhy adres.

Navíc jsem vyhodil informace na kontaktní osobu a dal jsem je do zvláštní tabulky. Vedlo mě k tomu hlavně to, že v dalším díle se chci zabývat uživatelským rozhraní a zjednodušení nutných tabulek mi umožní, soustředit se opravdu jen na to důležité: položky faktury, subjekty a jejich náležitosti potřebné pro tisk faktury a pro základní evidenci faktur.

Aktualizoval jsem opět jak obrázky tady, tak zdrojové soubory, které jsou ke stažení.

Obrázek č. 4 – Nová databáze pro jednoduchou aplikaci na tisk a evidenci faktur

W3C pracuje na standardu XHTML 2.0, který má za cíl nahradit dva zmíněné. Potíž je v tom, že jeho vývoj trvá konsorciu už hodně dlouho a navíc ho nevyvíjí jako zpětně kompatibilní a to budou hlavní důvody, proč se k jeho podpoře nepřihlásil žádný výrobce webového prohlížeče. Naopak Mozilla Foundation a Opera Software založili Web Hypertext Application Technology Working Group (WHATWG), kde pracují na vlastním standardu HTML5 (někdy také Web Application 1.0). Později se k nim přidali i Google a Apple.

HTML5 je zpětně kompatibilní a klade si za cíl být lepším základem pro vývoj web aplikací, než je HTML 4.01 a podstatně snadněji implementovatelný než by byl XHTML 2.0.

Poslední vývoj je takový, že WHATWG vyzvalo W3C, aby s nimi zahájilo jednání o použití HTML5 jako základu pro společný postup. Myslím, že W3C bude muset jejich nabídku přijmout, protože bez podpory na straně prohlížečů (a tu zastupuje WHATWG) se žádný standard prosadit nedá.

Jak vidíte, článek je spíš takový uzel na kapesníku, abych vývoj na tomto poli sledoval, než nějakým detailním pojednáním.

Zdroje:

• HTML 4 5 6 – český blog pouze o vývoji kolem HTML5
• Digital Web Magazin: HTML5, XHTML2, and the Future of the Web
• Web Hypertext Application Technology Working Group (WHATWG)
• W3C
• Aktuální stav standardu HTML5
• Aktuální stav standardu XHTML 2.0

Nuly a jedničky v krabicích

Když se před masívním rozšířením sítě sítí řeklo „software“, všichni jsme si představili krabici a v ní manuál a CD. Software jsme nainstalovali, používali, stěžovali si na nedostatky nebo chyby a po určité době, závislé na výrobci, jsme si koupili novou verzi.

Takový koloběh měl několik důsledků pro nás uživatele:

1. Jakmile byl software jednou „v krabici“ byly tam i všechny chyby, které v něm programátoři nechali.
2. K programu jste měli samozřejmě přístup pouze z jednoho počítače — z toho, kde byl nainstalován.
3. Komplikace se sdílením dat z „našeho“ programu s někým jiným.
4. Různé verze programu a jejich (ne)kompatibilita.

A teď z pohledu firem software vydávajících:

1. Komplikovaný, zdlouhavý a tím pádem drahý vývoj.
2. Náklady na fyzickou distribuci softwaru (krabice s CD se někde musí prodat).
3. Co s chybami, které v softwaru zákonitě zůstanou i po jakkoli důkladném beta testování?
4. Co kompatibilita mezi různými verzemi? Neomezí nás ve vývoji (viz Windows)?
5. Pokud chcete prodat novou verzi, musíte do ní dát další užitečné funkce, které zákazníky přesvědčí ke koupi. Pokud už to nejde začnete uměle odřezávat uživatele starších verzí (viz nekompatibilita souborů z různých verzí Illustratoru).
6. Méně hmatatelné, ale neméně důležité, jsou problémy vyplývající z toho, že programování museli dělat úplně jiní lidé, než kteří dělali design – nebo jste viděli někoho, kdo je alespoň schopen číst C++ a k tomu je grafik?

Brouzdáním vpřed

S rozšířením internetu se softwarovým firmám otevřela možnost vyřešit alespoň některé výše uvedené problémy. Za všechny jmenujme automatické udpaty, které výrazně urychlují produkční cyklus a pomáhají s odstraněním chyb.

Ale tím to neskončilo, pokrok na poli webových technologií a především stále se zlepšující podpora standardů (ať už je to HTML, CSS nebo JavaScript) však vytvořila nové vývojové prostředí pro aplikace: webový prohlížeč.

Vezmu to stručně, ale uvedené body mají rozsáhlé implikace, tak si je nechte projít hlavou¹.

Co prohlížeč jako vývojové prostředí umožňuje vývojářům:

• Jednoduchý a rychlý vývoj — snadněji zvládnutelné programovací jazyky, okamžitě viditelné výsledky, rychlá implementace grafického rozhraní, snadné úpravy atp.
• Cílení menšího trhu — levnější vývoj nám umožní oslovit i klienty, pro které se dřív nevyplácelo zvláštní software programovat. Otevírá se obrovský prostor pro malé softwarové firmy, které budou rentabilně nabízet levný produkt, šitý na míru úzkému okruhu zákazníků.
• Snadná distribuce — aplikace běží na serveru, uživatelé si ji otevírají jako stránku v prohlížeči – nemusí nic instalovat, funguje na všech operačních systémech.
• Pronájem softwaru — samotný princip hostování web aplikací přímo vybízí k pronájmu softwaru uživatelům na základě pravidelných poplatků, nikoli jednorázového prodeje.
• Bleskové odstraňování chyb — jsme schopni chybu najít, opravit a správnou verzi „nainstalovat“ všem uživatelům třeba během pár minut – něco takového krabicový software rozhodně nezná.
• Menší problémy se správou verzí — z podstaty fungování vyplývá, že všichni uživatelé mají stejnou verzi, takže máme jednodušší technickou podporu, mnohem snadněji se řeší zpětná kompatibilita.
• Přístup odkudkoli — Uživatelé mají ke „své“ aplikaci přístup všude tam, kde je připojení na internet, což bude v brzké budoucnosti znamenat prostě všude.
• Sdílení zdarma — webové aplikace mohou klienti téměř automaticky sdílet mezi sebou – je to přece jen webová stránka, kterou si může otevřít každý s přístupem na internet. Samozřejmě, že budeme muset zvlášť řešit sdílení konkrétních dat mezi uživateli navzájem, ale i to se bude implementovat určitě mnohem lépe než u krabicového softwaru.
• Dobrá omezení — prohlížeč nám neumožňuje vše, co třeba operační systém a je to dobře. Omezení nás nutí soustředit se na základní funkce a nemáme tak prostor pro mnoho výstřelků typu pan Sponka. Ale i tak je třeba mít se na pozoru.

Z výše uvedeného chci vypíchnout hlavně možnost oslovit levnou aplikací klienty, kteří nemají statisíce na implementaci SAPu, ale s radostí zaplatí $50 měsíčně za jednoduchou, dobře fungující webovou aplikaci — viz Basecamp a úspěch 37signals vůbec.

Vidím aplikací pole široké…

Stručný pohled do blízké budoucnosti, berte ho s nadhledem.

Web aplikace se budou, tam kde to bude mít smysl, víc integrovat s desktopem (widgety nebo přidání offline funkčnosti).

Web aplikace budou přes veřejná API stále více komunikovat mezi sebou a s desktopovými aplikacemi.

S rozšiřující se podporou plnohodnotného internetu na mobilních telefonech se otevře další prostor, na kterém se uplatní schopnost web aplikací fungovat ve stejné verzi na mnoha různých platformách.

A co vy?

Prohlížeč jako vývojové prostředí nabízí skvělou možnost pro malé firmy nebo jednotlivce, kteří se mohou chytit tím, že dobře vyřeší potřeby třeba i úzkého okruhu firem. Vždy je tu možnost expanze a to i do zahraničí — počítat při vývoji s více jazykovými verzemi nepředstavuje mnoho komplikací navíc a distribuce do zahraničí je možná „automaticky“.

Zajímalo by mě, jaké jsou vaše zkušenosti s vývojem web aplikací? Co jste programovali, v čem, jak dlouho to trvalo, bylo to výdělečné atd. Zajímá mě cokoli, co jste ochotni sdělit. Chci tu začít dialog, který mi v českém prostředí chybí. Samozřejmě, že budu postupně publikovat naše zkušenosti s budováním web aplikací, naše postupy, naše designérská rozhodnutí…

Tak je tam někdo? ;)

Aktualizováno 28. 10. 2007: Hezký příklad probíhající integrace web aplikací s desktopem přináší Prism od Mozilla Labs. Via Marek Prokop

Aktualizováno 17. 2. 2007: Na OS X umožňuje funkcionalitu Prism slibná aplikace Fluid

Začnu dvěma problémy, kterými tagování trpí¹:

1. Komplikované vyhledávání v rozsáhlém seznamu tagů
2. Velké množství výsledků i po výběru jednoho tagu

Příliš těžké mraky

Obrázek č. 1 ukazuje seznam tagů (tag cloud), které byly použity pro označení fotografií na Flickru. Když kliknete na clouds objeví se fotografie s tímto tagem.

Obrázek č. 1 - příklad seznamu tagů (tag cloud) na Flickru

Z obrázku je dobře patrný první problém tagování: Časem vytvoříme tolik různých tagů, že je obtížné v nich najít ten, který hledáme². K čemu nám pak jsou vlastní dveře, když je nedokážeme v záplavě jiných dveří najít?

K čemu nám jsou vlastní dveře, když je nedokážeme v záplavě jiných dveří najít?

Příliš mnoho kapek

Další problém vyvstane s přibývajícím tagovaným obsahem: Když už konečně najdeme hledaný tag, zúžíme sice množinu výsledků, ale ještě pořád bude výsledků tolik, že bude obtížné v nich najít ten váš.

Příklad hledání fotografií je přitom relativně jednoduchý. Představme si, že používáme tagy pro označování odkazů na stránky a tyto odkazy jsou přístupné i  dalším uživatelům. Třeba jsme někde viděli skvělý návod na fotogalerii vytvořenou čistým HTML kódem, javascriptem a formátovanou pomocí CSS. Víme, že jsme nejspíš použili tagy html, javascript, css. Jenže přesně tyto tagy použili jiní uživatelé pro svoje odkazy, takže se velmi rychle dostaneme do situace, kdy na námi zvolený tag vyběhne tolik “šumu”, že je systém nepoužitelný.

Solení mraků

Pojďme se podívat na možná řešení prvního problému: Najít v seznamu tagů ten svůj.

Obrázek č. 1 nám opět udělá dobrou službu, protože na něm vidíte jedno oblíbené řešení – zvýraznění nejčastěji používaných tagů zvětšením jejich velikosti.

V případě “most popular” tagů Flickr používá ještě, řekněme opačnou metodu – nezobrazování tagů, které jsou používány relativně málo. Kompletní seznam tagů je k dispozici zvlášť.

Pokud opravdu hledáme obsah otagovaný zvýrazněnými tagy, je to fajn, když nás ale zajímají tagy jiné, je orientace ještě těžší, protože naši pozornost zaměstnávají pro nás nepodstatné objekty³.

Počáteční písmeno následujících tagů usnadní orientaci v seznamu

Ne tak očividnou, rozhodně však důležitou pomůckou je abecední řazení tagů. Umožňuje nám to téměř podvědomě odhadnout, kde zhruba náš tag bude. Já osobně ještě preferuju, od určitého množství tagů ulehčit orientaci navíc tím, že výrazně zobrazíme počáteční písmeno následujících tagů, viz obrázek č. 2. Je to screenshot z aplikace, kterou jsem si naprogramoval, abych mohl snadno vyhledávat v různých odkazech, které si chci archivovat. Pro srovnání jsem nechal tagy jednou vypsat i bez úvodních písmen.

Obrázek č. 2 - Výpis seznamu tagů s úvodnímu písmeny

Obrázek č. 3 - Výpis seznamu tagů bez úvodních písmen

Kombinací výše uvedených pomůcek jsme schopni obstojně vyřešit problém přehledného vypisování seznamu tagů pro většinu aplikací, na které můžeme narazit. Je potřeba mít na paměti, že každá aplikace bude mít svoje specifika a proto nebude existovat nějaký jediný správný způsob, jak při tvoření seznamu tagů postupovat. Vžijte se do myšlení uživatelů, zaměřte se na to, v čem jim má aplikace pomoci.

Druhý problém – příliš mnoho výsledků i po zúžení pomocí jednoho tagu – bude mnohem zajímavější oříšek.

Okap pro silný déšť

Už jsem zmiňoval svou aplikaci na archivaci různých odkazů, poznámek, kusů kódu apod. Říkám jí Matrix a vytvořil jsem ji proto, že mi možnosti organizace bookmarků v prohlížeči naprosto nevyhovovaly. Uložil jsem si to do složky /esej, /články nebo snad /to read?

Problém je v tom, že komplexní údaje si při větším množství žádají složitější třídění, takže jsem měl složku /css, která dále obsahovala něco ve stylu /layout, /rohy, /forms apod. V jiných oblastech obdobně nebo ještě více úrovní zanoření. Nevyhnutelně docházelo k tomu, že jsem pak při pokusu o vyhledání uložené informace (kterou obvykle člověk potřebuje hned), neměl náladu na procházení podadresářů složek a hledání toho správného článku – Google byl pořád o dost rychlejší.

Přitom jsem ale častokrát naprosto jistě věděl, že už jsem věc, která mě zrovna trápila viděl někde vyřešenou, na nějaké stránce, nebo blogu, nebo kde… Znáte ten pocit?

Což takhle zkombinovat klasickou stromovou strukturu s tagy?

Pak jsem se dozvěděl o Delicious. Nejdřív jsem jásal a podivoval jsem se, jak to, že mě něco tak prostého nenapadlo – prostě přidám k bookmarku ještě klíčová slova a je to. Sdílení s jinými uživateli je bonus.

No jo, jenže Delicious trpí přesně tím problémem, o kterém je tahle část článku – vyberete tag a vyběhne na vás tolik výsledků, že jste stejně ztraceni.

A pak mě napadlo “Což takhle zkombinovat klasickou stromovou strukturu s tagy?”, ten proces zanořování a logického zužování s tím, že hledaná informace vlastně není na jednom konkrétním místě, ale je pouze popsaná klíčovými slovy – tagy.

Přišlo mi přirozené, že by tagování mělo fungovat následovně:

1. Vybereme tag
2. Jsou zobrazeny výsledky, které daný tag mají
3. Zároveň se ale seznam tagů změní a bude obsahovat už jen ty tagy, které mají příspěvky, jež mají zároveň i tag vybraný v kroku 1
4. Můžu pokračovat v dalším zužování nebo se vrátím o tag zpět

Názorný příklad: „Jak se sakra jmenuje taková ta javascriptová fotogalerie… taková ta pěkná, s animacema při otevírání fotky…“ První tag, který mě napadne je javascript.

Obrázek č. 4 - Část stránky aplikace Matrix po výběru tagu javascript – klikněte pro zvětšení

Kliknu tedy na javascript v seznamu tagů a vyjedou mi všechny příspěvky, které jsou jím označeny. Ačkoli aplikaci používám sám, výsledků už je tolik, že by mi takovéhle zúžení nebylo nic platné (celý screenshot, PNG 600 KB). Ale jak vidíte na obrázku č. 4, můj seznam tagů se nyní změnil – obsahuje už jen tagy, které mají příspěvky, které zároveň mají i můj tag javascript⁴.

Všimněte si, jak se mi vypisuje tagová cesta, kterou jsem se k aktuálním výsledkům dostal. Můžu se kdykoli vrátit o krok zpět a vybrat jiný tag, pokud bych nebyl s výsledky spokojen.

Já už ale vidím tag fotogalerie, klikám na něj a jásám “Lighbox, jasně… to je taky název pro fotogalerii…” ;-)

Obrázek č. 5 - Stránka po výběru tagů javascript, fotogalerie

Samozřejmě jsem nemusel jít jen cestou javascript > fotogalerie. Mohl jsem začít u kteréhokoli z tagů, kterým je daná informace označena. Mám tedy stejný pocit postupného zanořování jako u klasického adresářového stromu, jenže s tou výhodou, že můj cíl není na jednom jediném místě a já se nemusím hned na začátku jednoznačně trefit, jinak ho nemám šanci najít – ne, k mému cíli vede tolik cest, kolik je kombinací tagů definovaných pro popis informace.

K cíli pak vede tolik cest, kolik je kombinací tagů definovaných pro popis informace

Možnosti použití

Vsadil bych se, že vás napadá pár příkladů, kde by se vám tenhle způsob navigace mohl hodit. Obecně je to vždy tam, kde je hodně položek, ve kterých se vyhledává a nestačí nám pouze jedno kritérium třídění, jedna úroveň adresářů, např. /javascript.

Kromě různých aplikací na archivaci bookmarků, poznámek, dokumentů apod., mě láká třeba použítí pro online obchody. Nevím jak vy, ale já někdy opravdu trpím, když hledám něco, řekněme na stránkách Alza.cz. Jejich základní menu produktů čítá 57 kategorií! Dovedu si představit, že použití stromového tagového systému⁵ by uživatelům umožnilo vyhledávat rychleji.

Příklad: Hledám toner do tiskárny. Vídím seznam kategorií a můj myšlenkový pochod je asi takovýhle: „Toner do tiskárny… toner, toner… T… T… T… ne, tonery tu jako kategorie nejsou. Hm, tak vezmu Tiskárny„, klik a načte se stránka příslušné kategorie. Teď musím očima projít submenu (což mi zabere nějaký čas), abych zjistil, že v této kategorii tonery také nejsou. Zpátky do hlavního menu kategorií. Ale teď ho nejspíš budu muset projet očima celé a zkusit, jestli mě nějaká kategorie neupoutá. „Hele, kancelářské potřeby“. Klik. Prozkoumání submenu. „Aaaa, ne…“ Zpátky očima do hlavního menu. Míjím očima všechny kategorie a musím u toho myslet. Vynechám nástrahu v podobě „Smíšeného zboží“ a kliknu na „Spotřební materiál“. Projedu submenu. „Ha, tonery!“ Teď ještě vyklikat filtry na moji značku a je to doma. Uf, to byl výkon.

A teď to samé ve stromovém tagovém systému: „Toner do tiskárny… toner, toner… T… T… T…“, písmeno T najdu snadno, protože je zvýrazněno jako počáteční písmeno skupiny tagů, „A hele tag toner!“ Klik. Vyjede stránka a seznam tagů se změní už jen na tagy, které mají položky, které mají také tag toner. „HP, HP…“ Klik. Načtení stránky, nový seznam tagů, který už bude velmi konkrétní a jsem u cíle.

Já vím, šedá je teorie a zelený strom života, ale věřím, že by to fungovalo lépe, než stávajících 57 kategorií.

Další příklad použití může být třídění firemních kontaktů. Náš klient, firma Nextlan, má několik webů, kde se uživatelé registrují, aby si mohli stáhnout ceník, přičemž vyslovují souhlas s tím, že jim budou zasílána obchodní sdělení. Těch kontaktů je přes 10000. Po registraci je každému automaticky přidělen tag s názvem webu, ze kterého jde a tag koncák. Kontakt je zařazen do fronty a čeká na schválení. Při schvalování, nebo kdykoli později může pracovník Nextlanu změnit koncák na distributor nebo cokoli jiného. Před rozesílávkou zúžíme celou skupiny kontaktů přes výběr příslušných tagů, např. netcam > dealer a máme velmi dobře cílenou skupinu, kterou náš email zajímá.

Tyhle všechny, a určitě mnohé jiné, aplikace můžou ze stromového tagového systému něco vytěžit.

Je mi jasné, že jsem tady jen tak škrábnul povrch a spoustu věcí nezmínil (kombinace s full-textovým prohledáváním třeba), ale zároveň věřím, že jsem vám nasadil brouka do hlavy, a že se vám bude můj koncept v nějakém projektu hodit.