Každopádně zajímavý prototyp.

Via @jasonfried

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.

Každopádně je to dobrá učebnice CSS, což je hlavní důvod, proč na ně linkuju.

Via @msgre

Via @rsj

Dan Saffer from Interaction Design Association

Via @ondrejvalka

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.

Patterns entrench themselves in our mental library through this process of encountering a situation, designing a solution, recognizing the same situation again, and recalling and applying the earlier solution.

The forces don’t have to be explicit. I never wrote them down before this post. But being aware of the forces makes it possible to critically analyze why you are making a specific design choice and how well that choice fits with the situation.

Understanding design patterns in your everyday work, Ryan Singer

Jednoduchý trik popisuje tutoriál od Ryana Collinse.

Via @enoice

Via @jakubspanihel

Zdroj The new Basecamp: Interface details and power user goodness

Mimochodem, Evan tímto způsobem hledá práci. Myslím, že nebude hledat dlouho.

Via Daring Fireball

Via Jiří Sekera

Zdroj Fluent

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.

Stále mi chybí možnost zadat si tam obrázek na pozadí pro nějaký ten noise, ale jinak už je to skoro ono.

Č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

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.

— Zdroj TUAW

Via @tombarys

Jak v komentáři dodal Honza Řezáč, přednáška je shrnutím knihy Design for emotion.

Via WebAppers

Přesně tohle objevování „nového jazyka”, kterým budeme v dotykových rozhraních mluvit, nás teď bude pár let určitě zaměstnávat.

Via @karimartin, @bdc

Via WebAppers

Sisyphus.js se snaží tomuhle nepříjemnému zážitku předejít tím, že vám umožní automaticky v pravidelných intervalech ukládat obsah formuláře a obnovit vyplněná políčka, pokud to budete potřebovat.

Používá localStorage z HTML5 a má jen 3,5 KB.

Via Smashing Magazine

Via @PetrKaleta

„Coming to know the difference between obvious, easy, and possible takes a lot of practice, deep thinking, critical analysis, and, often, debate. It’s a constant learning process. It helps you figure out what really matters.

But once you’re able to see the buckets clearly, and you begin to think about things in terms of obvious, easy, and possible instead of high, medium, and low priority, you’re on your way to building better products.”

Pokud byste chtěli víc, zkuste moje záložky.

Za tip díky @milancermak

Obzvlášť velká písmena s tím vypadají o poznání líp, takže jsem to zapnul pro celý svůj blog.

Když to zjednoduším, představte si Ajax, ale bez čekání na vykonání požadavku. Změny se v UI projeví okamžitě, uživatel na nic nečeká, nic se nenačítá znovu. Akce se provedou na pozadí a uživatel je vytržen z nerušeného používání pouze pokud se něco nepovedlo.

Zmiňuje javascriptový framework Spine, který mě zaujal už tím, jak se prezentuje.

Takhle by měly fungovat všechny web aplikace. Miluju tuhle dobu.

Via @zdenekkostal

PS: Ten modální dialog při smazání položky v jeho příkladu beru v daném kontextu jako vtip :-)

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? ;-)

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ří.

Jsou weby a web aplikace, na kterých rychle poznáte, že jejich design (ve smyslu celkového dojmu uživatele, ne jen vzhled) navrhoval grafik – příklad za tisíc slov www.divadlo29.cz. Od hvězdiček v title stránky až po to naprosto nesmyslné řešení skrolování obsahu stránky pod velkým obrázkem, které mě přivádí k šílenství, kdykoli se chci podívat na program. Uuuaaa… to mi svírá prsty na nohou v pěst.

1… 2… 3… 4… 5… Uf…

Design správy účtů mBank musel naproti tomu navrhovat programátor.

Obrazovka pro přihlášení

Vezmeme to od začátku. Už adresa je špatně zvolená: https://cz.mbank.eu ? Nebyla by lepší adresa http://mbank.cz / mujucet nebo něco na ten způsob? Ale čert to vem, já se na tu titulku mBank podívám, abych si kliknul na ten čudlík Přihlášení.

Obrázek s formulářem loginu mBank

Dostali jsme se tedy na přihlašovací obrazovku. Přiznejte se, kdo z vás si kdy přečetl ty texty po stranách? Já až teď. O nic jste nepřišli. Ty texty by tam nemusely být a měli bychom čistší stránku. Proč je třeba neumístit až za nějaký odkaz „O bezpečnosti”, na který by si kliknul jen ten, koho to zajímá. A opravdu je nutné mi říkat, že používám „Internetové bankovnictví”?

K přihlašovacímu formuláři samotnému. Když už si popisky zbytečně prodlužujeme o slovo „Vaše” mohly by fungovat, jak správný label má, tj. přesunout mi kurzor do příslušného políčka. A kdo vymyslel popisek „Potvrdit” pro tohle odesílací tlačítko? Nebylo by lepší třeba „Přihlásit”?

Obrázek s mou úpravou login obrazovky

Rozhraní pro správu účtu

Tady se naplno projevuje „programátorský” přístup k designu: Vypisovány jsou informace, které mnohdy nejsou důležité, to vše je nevhodně rozmístěno a špatně typograficky.

Kde začít… Asi u hlavního menu.

Zdaleka největší problém menu je, že sdružuje položky s naprosto rozdílnou prioritou pro uživatele a dává jim všem téměř stejnou váhu. Co dělá „Kontaktujte nás” v hlavním menu? Obdobně „Moje kontaktní údaje”, což je hodně nešťastné pojmenování toho, co obvykle očekáváme pod odkazem Nastavení. „Operace k autorizaci” v hlavním menu, i když prakticky nikdy takové tlačítko nepoužiji, protože potvrzuji zadání ihned při zadání? Nebylo by lepší případné operace k autorizaci zobrazit v obsahové části teprve, až tam nějaké budou?

Perlička je umístění tlačítka „Odhlásit”. Trvalo mi opravdu dlouho, než jsem si zvykl na to, že není vpravo nahoře jako v drtivé většině aplikací, ale v hlavním menu. Pak se tu ještě zbytečně opakuje „Moje” a to až do poněkud absurdního tlačítka „Moje služby” – jako bych jim něco nabízel já :)

K těm zbytečným textům: Opravdu potřebuji mít na prominentním místě informaci o tom, jaké je mé jméno, nebo že jsem se přihlásil naposled včera (zapsáno navíc v tom pěkném, obyčejným lidem dobře známém, formátu) a chybí informace o mém neúspěšném přihlášení?! Už víte, proč jsem říkal, že to navrhoval programátor?

Takhle nějak bych úvodní obrazovku navrhoval já.

Můj nástřel úvodní obrazovky

Berte tohle spíš jako velmi základní wireframe určený pro další další debatu s klientem, ale myslím, že dobře ilustruje, jak by měla úvodní obrazovka fungovat. Co potřebuji přes internet udělat nejčastěji? Podívat se na zůstatek, poslat někam peníze a podívat se, jestli už mi nějaké peníze přišly. To všechno a další se dá na jednu obrazovku celkem přehledně dostat.

Závěr

Proč jsem to celé psal? Hm… nejdřív jsem si myslel, že se mi uleví, ale pak už se to psaní nějak táhlo, takže rychlá katarze se nedostavila. Vzal jsem to tedy jako malé cvičení v uživatelském rozhraní, které snad rozezní strunu i u jiných lidí používajících tu více, tu méně příjemné internetové bankovnictví. Třeba se můj nářek dostane i někam, kde s tím můžou něco dělat. Jeden nikdy neví.

Aby bylo jasno, jinak se mi služby mBank líbí, od nového roku se chystám tam přesunout všechna konta. Mám tedy na dobře fungujícím rozhraní mBank tak trochu vlastní zájem :)

Když jsem si koupil iPhone, dostal jsem k němu sluchátka, která mají na šňůře k pravému špuntu tlačítko s mikrofonem. Díky tomu poznám od pohledu nebo po hmatu, které sluchátko je pravé a nemusím pátrat po písmenku.

To mě vedlo k myšlence, že by mohli podobně odlišit pravé sluchátko i ostatní výrobci. Taky jsem si poprvé uvědomil, že běžné označování sluchátka jen písmenkem je vlastně prohřešek proti přístupnosti.

Kousek přidané umělé hmoty na pravém kabelu by mohl zpříjemnit používání sluchátek, protože obřad nasazování by byl plynulejší.

Hned zítra dopoledne dám ke stažení hrubé výstupy, tj. počty odpovědí u jednotlivých možností otázek. Pak bude potřeba udělat detailní analýzu odpovědí, která nám umožní odvodit třeba platy v jednotlivých regionech apod. Čas, který tahle podrobnější analýza zabere, si momentálně netroufám odhadnout. Jejím výsledkem by mělo být PDF s komentovanými výsledky.

Děkuji všem za účast a jsem zvědav na výsledky téhle „webaři sobě” akce.

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.

Dělám na webu prodejce leteckých motorů. Každý motor má svou dokumentaci – kolem pěti PDF souborů. Měl jsem na stránce dost místa, tak jsem si řekl, že tam můžu umístit i malé ikony jednotlivých dokumentů. (První verzi vidíte na obrázku níže. Ještě na ni nenajíždějte myší, prosím.)

Ale pak klient přišel s tím, že se mu náhledy PDFek tak líbí, že by je chtěl větší. A když už v tom budeme, tak je můžeme udělat tak velké, že uživatel stránek přímo z náhledu přečte, co je to za dokument a můžeme se zbavit těch nadpisů. (Upraveno 24. 7. 2008) Tady bych měl dodat, že cílová skupina webu jsou technici, kteří už ty příručky mnohokrát viděli a poznají je podle vzhledu, proto nepotřebují číst názvy.

Výsledek po najetí myší:

Vidíte, jak se to odstraněním nadpisů zpřehlednilo? Uživatelé mají mnohem rychlejší a pohodlnější přehled – nemusí nic číst, všechny dokumenty vidí.

Poučení tedy zní: Kdykoli předkládáte uživateli něco k přečtení — názvy dokumentů, chybovou hlášku apod. — zkuste se zamyslet nad tím, jestli by nebylo možné mu výsledek přímo ukázat. Proto je mnohem lepší yellow-fade, než nějaký zelený rámeček se zprávou, že úprava proběhla správně.

Najeďte myší nad obrázek pro nový design.

Moje postřehy

1. Hlavní motto bylo očividně „pročistit”.
2. Postranní lišta byla výrazně zpřehledněna a vizuálně propojena s obsahem (pomocí tabů, ale také zmizel border).
3. Zmizel zbytečný řádek s Hi,… your profile a celý blok Currently byl přesunut do obsahu, kde má menší, ale kontextově logičtější místo. Paradoxně je tak vlastně víc na očích, protože ho vidíte, když jdete psát nový příspěvek.
4. Vypíchnuty byly údaje Following_me a Followers_me (BTW, může mi někdo říct, proč se jmenujou takhle blbě, tím myslím nejen to podtržítko).
5. Ale zdaleka nejlepší je samozřejmě přesunutí přepínání mezi Recent, Replies a Everyone, které je teď v sidebaru a je na stejné úrovni s Direct messages a Favorites.
6. Dokonce i invite more bylo zkráceno na add.
7. Jednotlivé příspěvky byly také opticky odlehčeny a to především chytrou typografií – světlejší font, větší odsazení avatarů, ikony pro odpověď, hvězdičku a koš se objeví pouze při :hover.
8. Hlavní menu bylo také zkráceno. Nejvýraznější je odsunutí vyhledávání až na kliknutí.

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.

Listování v článcích

Server treehugger — klasická dlouhá stránka, dva úzké sidebary a obsahový blok s nadpisy článků, ilustračním obrázkem a odkazem na pokračování textu — se snaží umožnit čtenářům „listovat” články pomocí širokého tlačítka na pravé straně.

Tlačítko je tak vysoké jako místo, které zabírá daný článek a po kliknutí se stránka posune přesně na další článek, pokud dojedete až dolů, tak vás kliknutí přenese na další stránku.

Zajímavá fičůra, ne? Ještě víc by se mi líbilo, kdyby se tlačítko dalo aktivovat mezerníkem, protože ten už posunutí stránky standardně obstarává. Nejsem si ale jistý, jestli jde tohle chování prohlížečů přepsat. Počítám, že nějaký javascript by to vyřešil. A pak by ještě pomohlo, kdy se posun animoval, protože ten skok stránky je trochu nepřirozený. Animované posunutí by ještě umocnilo dojem toho listování.

37signals a automatický posun stránky

Když už jsme u toho pohybu po stránce, tak tady je další video od Signálů. Je to přesně ukázka leštění, kterého si uživatel ve výsledku nejspíš nevšimne, ale jeho dojem z interakce s aplikací bude o něco plynulejší. Brambora k bramboře…

Engadget a zvýraznění článků

Po delší době jsem se nějak dostal na Engadget a koukám, že mají nový design. Zaujal mě způsob, jakým upozorňují na zajímavé články. V pravém sidebaru je výrazný blok, ve kterém se střídají obrázky k představovaným článkům a jejich nadpisy. Můžete v nich listovat, kliknutí na nadpis vás přenese na článek. Chytré.

Výběr URL Safari versus ostatní

Když v Safari začnete psát do adresového pole, vyhledá v historii stránky, které odpovídají tomu, co píšete a nabídne vám je k výběru. Na první pohled stejné chování jako všechny ostatní prohlížeče. Jenže Safari vám navíc automaticky nastaví výběr na první položku z nabídky, takže většinou už musíte jen zmáčknout Enter. U všech ostatních prohlížečů musíte ještě navíc aktivovat vybírání adresy tím, že zmáčknete šipku dolů.

Firefox a ostatní

Safari

Apple a vyhledávání na webu

Stránky Applu jsou učebnice pro nás všechny. Občas tam jen tak zajdu a proklikávám se obsahem, abych „nasál” jejich design (v tom širším smyslu, ne jen vzhled). Teď jsem si všiml, že upravili prohledávání webu. Konkrétně mám na mysli tu nabídku, která se vám objeví, když začnete do vyhledávacího pole zadávat slovo. Výsledky, které nejvíce odpovídají zadání jsou zobrazeny podle kontextu, kde byly nalezeny a navíc mají velmi chytře vybíraný ilustrační obrázek. Paráda!

Narazili jste na nějaký zajímavý příklad uživatelského rozhraní, o který se chcete podělit? Napište mi na jsem [zavináč] jankorbel.cz a já ho dám do příští edice.

Ostatní díly série

Leštit, hledat, vkládat, nastavovat

Najměte si mě

Máte zájem moje služby v oblasti uživatelského rozhraní nebo informační architektury?

Kontaktujte mě na jsem [zavináč] jankorbel.cz

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

37signals: Přepínání mezi projekty

Líbí se mi, jak Signálové systematicky „leští” své aplikace. Vezmou řešení, které by pravděpodobně u jiných firem bylo považováno za „good enough” — a energie by se věnovala na nové funkce — a vybrousí mu pár fasetů navíc.

NY Times: Dvojklik na slovo otevře výkladový slovník

Kouzlo náhodně objevené funkce stránek New York Times. Pokud dvojkliknete na slovo v článku, vyskočí okno s výkladovým slovníkem. Ještě elegantnější by bylo, kdyby se objevil panel podobný tomu, který se otevře u Signálů, když přepínáte ten projekt – ne samostatné okno, ale něco se menšího, se zobáčkem k vybranému slovu. Nicméně, hezká funkce a ten článek také stojí za přečtení.

ASAPH: hledání svatého grálu mikroblogování pokračuje

Všichni jsme to řešili už mnohokrát – narazíte na obrázek, video, větu a chcete si je někde uložit a/nebo se o ně podělit s ostatními. ASAPH nabízí jednu z možností, jak to udělat. Všimněte si minimalistického designu administračního rozhraní. Tady je asi minutové video s ukázkou použití (MOV 5,2 MB).

IE 7.0: Živé nastavování okrajů stránky při tisku

Internet Explorer používám pouze při testování CSS, takže k tisknutí z něho jsem se dostal jen díky ladění jedné náročnější stránky pro tisk. Byl jsem mile překvapen tím, že mi dovolí přímo v tiskovém dialogu na náhledu stránky změnit okraje stránky. Možná by se dala tato možnost nějak lépe prezentovat, protože ty šipčičky moc nevybízí k interakci.

Máte nějaký zajímavý příklad uživatelského rozhraní, o který se chcete podělit? Napište mi na jsem [zavinac] jankorbel.cz a já ho dám do příští edice.

Ostatní díly série

Posunovat, hledat, zvýrazňovat

Najměte si mě

Máte zájem moje služby v oblasti uživatelského rozhraní nebo informační architektury?

Kontaktujte mě na jsem [zavináč] jankorbel.cz

Všichni jsou spokojení

Obchodní model se zdá výhodný pro všechny strany. Klient si za menší poplatek pronajme možnost upravovat si stránky kdykoli potřebuje a není vázaný na to, kdy se k tomu dostaneme my, správcové stránek, kteří většinou nemáme čas na nudné aktualizování, protože děláme nový web někomu jinému a poplatek z redakčního systému pro nás představuje „peníze za nic”. Ušetřili jsme čas pro výnosnější činnost, než jsou aktualizace a ještě za to dostaneme zaplaceno.

Po pár letech nasazení redakčního systému u několika klientů jsem dnes přesvědčen, že redakční systémy škodí jak klientům, tak nám.

Problém č. 1 – HTML

Celá výše uvedená úvaha padá s tím, že taková sekretářka na straně zákazníka samozřejmě HTML neumí. Takže nasadíme WYSIWYG editory, které vypadají jako ten Word, co dobře zná. Ale auha, ono to stejně nefunguje. Tuhle si to nechá formátování z Wordu, ze kterého to kopíruje, tamhle nejde zarovnat ten obrázek, tady to má úplně jiný font…

Slavná nezávislost na správci stránek je u šípku.

Výsledkem pak je buď naštvaný nebo omlouvající se telefonát (podle povahy sekretářky), že je to zase celé rozhozené a jestli bychom to nemohli opravit. Takže celá slavná nezávislost na správci stránek je u šípku.

Jsou i klienti, kteří se tím vším nějak prokoušou, stráví třeba i několik hodin zápolením s WYSIWYG editorem, až slavně zvítězí a ten obrázek už nevylétává z okraje stránky. Hurá, hurá, to jsme ale ušetřili. Zaplatili jsme pár set (minimálně) korun na měsíčním poplatku za systém a při každém publikování novinky tím pověřený člověk zabije celé dopoledne a je na pokraji zhroucení.

Kdyby tu aktualizaci předali nám, byla by to práce na čtvrt hodiny a za to dopoledne by se tam objevila taky.

Nechci, aby se moji klienti museli učit HTML a nevěřím, že se někdy objeví takový WYSIWYG, který by zmíněné problémy eliminoval.

Problém č. 2 - Typografie

Sekretářka netuší, že ta oranžová tam sedí asi jako Bobošíková na Hrad.

I kdyby se nakrásně takový editor objevil bude tu stále jiný problém – typografie. Ona totiž sekretářka vybavená hypoteticky neprůstřelným editorem pořád netuší, jaký je rozdíl mezi patkovým a bezpatkovým písmem, že centrované nadpisy nejsou konzistentní se zbytkem webu, a že ta oranžová tam sedí asi jako Bobošíková na Hrad. A to se nezmění nikdy, tím jsem si jistý.

Samozřejmě, na tohle si klienti nestěžují, protože si to neuvědomují, ale každý web je nejen jejich vizitka, ale i naše. To je ten viditelnější důvod, ale pak taky sakra ten web mají, aby jim přilákal zákazníky, takže když bude vypadat špatně, bude jim vydělávat méně a oni pak budou mít i méně peněz na další investice, neřku-li dojdou k závěru, že je to celé naše vina a půjdou k jinému správci stránek, který jim ukáže demo svého redakčního systému, kde tohle všechno funguje bez problémů. Ha, ha…

Problém č. 3 - Ztráta kontaktu s klientem

V neposlední řadě se redakčním systémem okrádáme o to, že víme, co se u klienta děje. Pokud bude jediná komunikace za měsíc o rozhozeném formátování publikovaných článků, není moc prostoru pro zjištění, jaké jiné problémy řeší. Třeba by potřebovali pomoct s komunikací se svými dodavateli, udělat anketu, naprogramovat nějaký systém pro zpracování ceníků atd.

Takový klient se vám po roce placení redakčního systému ozve, že chce změnit nastavení serverů někam jinam, protože mu novou verzi webu udělala jiná firma.

Jaké jsou vaše zkušenosti?

Upraveno 17. 2. 2008: David Grudl reagoval svým článkem. Rozhodně stojí za přečtení, včetně komentářů.

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.

Demo si můžete vyzkoušet na stránce projektu. Když jsem se o to snažil na MacBooku ve Firefoxu i v Safari, tak to nějak nechtělo natáhnout Javu. Možná nemám poslední verzi nebo byl server přetížen, nevím.

Via The Interactions Designer’s Coffee Break

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.

Kam se chceme dostat

Začnu tím, že prozradím konec celé detektivky ;) Podívejte se na výsledek, ke kterému směřuje tento článek.

Líbí? Když navíc zdůrazním, že náhledy jsou dostupné okamžitě po najetí myší nad vzorek polepu – žádná prodleva, ve které by se tahal potřebný obrázek – mohli byste být už správně naladěni na pár řádků HTML a CSS.

HTML pódium

Vystačíme si s jedním div, který nám podrží obrázek letadla bez polepu a s jedním ol seznamem.

<div id="aircraftBlueprint">
  <img src="img/exterior/model.gif" alt="" width="406" height="172"/>
</div>

<ol id="exteriorSwitch" class="floatHolder">
  <li class="ext01"><a href="#"><span><strong>Design exteriéru č. 1</strong></span></a></li>
  <li class="ext02"><a href="#"><span><strong>Design exteriéru č. 2</strong></span></a></li>
  <li class="ext03"><a href="#"><span><strong>Design exteriéru č. 3</strong></span></a></li>
  <li class="ext04"><a href="#"><span><strong>Design exteriéru č. 4</strong></span></a></li>
  <li class="ext05"><a href="#"><span><strong>Design exteriéru č. 5</strong></span></a></li>
  <li class="ext06"><a href="#"><span><strong>Design exteriéru č. 6</strong></span></a></li>
  <li class="ext07"><a href="#"><span><strong>Design exteriéru č. 7</strong></span></a></li>
  <li class="ext08"><a href="#"><span><strong>Design exteriéru č. 8</strong></span></a></li>
  <li class="ext09 clrRgt" class="noMargin"><a href="#"><span><strong>Design exteriéru č. 9</strong></span></a></li>
  <!--  druhy radek vzorku  -->
  <li class="ext10 secondRow clrLft"><a href="#"><span><strong>Design exteriéru č. 10</strong></span></a></li>
  <li class="ext11 secondRow"><a href="#"><span><strong>Design exteriéru č. 11</strong></span></a></li>
  <li class="ext12 secondRow"><a href="#"><span><strong>Design exteriéru č. 12</strong></span></a></li>
  <li class="ext13 secondRow"><a href="#"><span><strong>Design exteriéru č. 13</strong></span></a></li>
  <li class="ext14 secondRow"><a href="#"><span><strong>Design exteriéru č. 14</strong></span></a></li>
  <li class="ext15 secondRow"><a href="#"><span><strong>Design exteriéru č. 15</strong></span></a></li>
  <li class="ext16 secondRow"><a href="#"><span><strong>Design exteriéru č. 16</strong></span></a></li>
</ol>

Jak to funguje

Ve zkratce: Přes obrázek čistého letadla v <div id="aircraftBlueprint"> budeme zobrazovat jednotlivé polepy, které máme uložené všechny v jednom obrázku průhledném na barvu pozadí. Docílíme toho tím, že po najetí myší na vzorek transformujeme span na blok o stejných rozměrech jaké má obrázek letadla a posuneme obrázek na pozadí tak, aby zobrazoval odpovídající náhled polepu.

Dva obrázky je vše, co potřebujeme a to včetně tlačítek se vzorky polepů

Obrázky

Budeme potřebovat dva obrázky – jeden s čistým letadlem a druhý s polepy. Začneme s letadlem, protože to nám určí, jaký rozestup musíme nechat mezi polepy, aby se při posunování obrázku na pozadí zobrazoval vždy jen jeden.

Obrázek č. 1 - čistý obrázek letadla, rozměr 406px × 172px

Obrázek č. 2 - ukázka části obrázku s polepy, celý obrázek obsahuje všech 16 polepů pod sebou

Výhoda posouvání obrázku na pozadí je v tom, že prohlížeč potřebuje stáhnout pouze jeden obrázek a pak už okamžitě reagují všechny vzorky na najetí myši a ihned se zobrazují náhledy. Navíc díky umístění na pozadí, nemusíme být naprosto pixelově přesní v přípravě obrázku se všemi polepy, protože můžeme odchylky pozicování dorovnat v CSS, jak si ukážeme vzápětí.

CSS zaklínadla

Konečně se mrkneme na nějaké CSS. Definice div pro obrázek čistého letadla a definice ol nepotřebují moc vysvětlování:

div#aircraftBlueprint {
  font-size: 0;
  line-height: 0;
}

ol#exteriorSwitch {
  margin: 20px 0;
  padding: 0;
  width: 100%; float: left;
}
  ol#exteriorSwitch li {
    list-style: none;
    float: left;
    margin: 0 15px 15px 0; padding: 0;
    border: 1px solid #ddd; /*kolem tlacitek vzorku*/
  }

U div#aircraftBlueprint jsme si zajistili, že obrázek nebude mít kolem pod sebou nějakou divnou mezeru (Explorer na tebe se dívám), u ol#exteriorSwitch potřebujeme pevné pixelové okraje, protože jakákoli mezera relativní k velikosti písma by mohla rozhodit překrývání polepů a vynulujeme standardní padding. Šířka na 100% a float: left; nám zaručí, že ol bude vědět o floatovaných li.

Nadefinujeme si náhledová tlačítka pro vzorky polepů.

ol#exteriorSwitch li a {
  display: block; width: 32px; height: 32px;
  text-decoration: none;
  background-image: url("../img/polep.gif");
}

Náhledová tlačítka jsou zajímavá tím, že pro ně nepoužijeme zvláštní obrázky, ale opět ten jediný velký obrázek se všemi polepy. V níže uvedených definicích pro každé tlačítko napozicujeme polep přes CSS do takové pozice, která se bude hodit jako vzorek designu. Opět tím přispíváme k rychlosti načtení stránky a k plynulému dojmu, který z ní bude uživatel mít.

A teď složitější. Nadefinujeme hover podobu pro span, který nám překryje nákres letadla designem polepu.

#exteriorSwitch li a span { display: none; }

ol#exteriorSwitch li a:hover span {
  display: block; width: 406px; height: 172px;
  background: url("../img/polep.gif") 0 0 no-repeat;
  position: relative;
    top: -190px;
  margin-bottom: -172px;
  margin-right: -406px;

  padding: 5px 0 0 0;
  font-size: 1.4em;
  color: black;
}
  #exteriorSwitch li.secondRow a:hover span {
    top: -240px; /*jine odsazeni pro druhy radek tlacitek*/
  }

  #exteriorSwitch li a:hover span strong {
    position: relative;
    z-index: 15;
    margin: 0;
  }

Vidíte, že v základu span nezobrazujeme, chceme ho vidět až na hover, kdy mu nadefinujeme stejnou šířku a výšku, jako má obrázek letadla a pomocí position: relative a top ho přesuneme nad něj. Ještě po něm negativními okraji zameteme stopy.

To ani nebolelo, ne? Hm, jenže teď přijde teprve ta dělničina: Potřebujeme napozicovat zvlášť pozadí pro každé tlačítko a pro každý span při hover. Ukážeme si to na příkladu prvních dvou li, pak už je to samé v bledě modrém.

Jako první nadefinujeme pozici polepu pro tlačítko se vzorkem a pak pro hover překrytí.

/*tlacitko vzoru*/
#exteriorSwitch li.ext01 a {
  background-position: -330px -35px;
}
  /*hover stav spanu*/
  #exteriorSwitch li.ext01 a:hover span {
    left: -1px;
  }

Pro první polep je jeho hover stav definován už výše, takže tady nic neměníme. Definice left: -1px; nám dorovnává span do správné pozice – rozhodil nám to border kolem tlačítka a možná i nepřesnost v obrázku. Tady se právě projevuje výhoda, kterou jsem už zmiňoval – nemusíme být naprosto přesní, na správné místo si polep napozicujeme v CSS.

Takže radostně na li číslo dva.

#exteriorSwitch li.ext02 a {
  background-position: -335px -205px;
}
  #exteriorSwitch li.ext02 a:hover span {
    left: -50px; /*32 + 15 + 3*/
    background-position: 0 -172px;
  }

Prostě posouváme obrázek na pozadí po ose y. Pro tlačítko se vzorkem navíc potřebujeme najít vhodnou část polepu, takže budeme muset měnit i souřadnici x. U span je drobná nepříjemnost v tom, že s jinou pozicí mateřského tlačítka se posunuje i výchozí pozice pro span, takže ho pomocí left: -50px vrátíme na správné místo.

A obdobně pro všechny ostatní tlačítka a hover stavy.

Pár poznámek závěrem

Výsledek a zdrojové soubory si můžete prohlédnout na zvláštní stránce.

Funkčnost v prohlížečích: Firefox (Win, Mac), Safari 2.0.4, Opera 9.10 (Win), IE 7.0, IE 6.0. Pro nižší verze IE už netestuju, počítám, že se tam rozhodí něco kvůli jejich chybnému box modelu, ale kdyby někdo chtěl, tak to nejspíš půjde vyladit.

V některých případech se metoda překrytí průhledným obrázkem nebude dát použít, ale to není žádný problém, budeme podklad prostě celý překrývat jiným obrázkem.

No a to je asi vše. Nápady, poznámky, připomínky?

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.