Martin Cohen: Blog - Články

intype.info: Grid systém 1

mail@martincohen.info (Martin Cohen) — Fri, 28 Mar 2008 11:00:00 GMT

Po 4 článkoch venovaným analýze požiadaviek pre jednotlivé sekcie sa konečne dostávam k niečomu zaujímavejšiemu: Grid systémy. Sú mocnou technikou na vytvorenie vyváženého dizajnu webu.

Grid systém je niečo ako vizuálny framework, základ, nad ktorým sa vystavia vzhľad webu. Je to niekoľko horizontálnych a vertikálnych čiar, ku ktorým zarovnávate stavebné bloky. V tejto časti ukážem ako rozdeliť stránku horizontálne do stĺpcov a ako vyťažiť z gridu maximum.

Existuje množstvo návodov, prístupov a kombinácii na vytvorenie grid systému. Ja som si vzal pár detailov a zostavil si vlastný systém. Hlavne preto, že mám rád veci komplexnejšie s rôznymi hračičkami a fintami.

Grid systém “960”

Na prototypovanie základného delenia používam univerzálnu mriežku, ktorá vychádza z 960.gs. Systém 960 je určený pre fixné rozlíšenie 1024×768, ktoré je dnes štandardom. 15% súčasných navštevníkov intype.info používajú 1024, ostatní používajú vyššie.

960.gs je v podstate dvojica šablon šírky (prekvapujúco) 960px. Šablony delia túto šírku na 12, alebo 16 zvislých pruhov. Každý pruh má navyše 10px priestoru na každej strane. Šablona so 16-timi pruhmi pre Fireworks vyzerá asi takto:

Pre tých čo Fireworks nepoznajú: Zelené čiary su guides, ružové pruhy sú iba obdĺžniky v zamknnutej vrstve na pozadí pre lepšiu orientáciu.

Pomery

V systéme 960/16 je šírka jedného pruhu 40px. Dve 10px pauzy po okrajoch, tvoria 20px priestor medzi jednotlivými pruhmi. Ja som si vytvoril systém, ktorý využíva tzv. zlatý pomer. Pomerov, ktoré sa dajú použiť je niekoľko. Tieto používam často ja:

1:3 a 1:4 – Klasické tretinové a štvrtinové pomery využívané pre konštrukcie všeobecne.
4:3 – Pomer využívaný v obrazovkách televíznych prijímačov, alebo monitorov#4:3_standard).
1:φ (≈ 1:1.618…) – Zlatý pomer využívaný ľuďmi v dielach od čias renesancie a prírodou od “prvopočiatku”. Pekne o zlatom reze písal Pixy.
1:√2 – Pomer využívaný v systéme rozmerov papierov ISO 216.

Môj systém 936/18

V mojom systéme používam 32px pruh a dve 10px pauzy. Dobrá otázka je “Fole proč, fole?”. Lebo ikony, fole! Pri pár predchádzajúcich dizajnoch som používal klasické 32×32 ikony v menu, zoznamoch súborov, tabuľkách, tlačítkach,… Využívaním desiatkových šírok stĺpcov (ako napr. 40px pri 960/16) som vždy narazil na problém so správnou vzdialenosťou medzi ikonou a textom. Za správnu vzdialenosť považujem 32 ÷ φ ≅ 20px. Zavedením systému 10/32/10 sa mi problém vyriešil.

Základná šablona tohto systému má 1000px šírku, pretože počíta s voľným 32px priestorom po oboch stranách. To preto, aby sa dali dizajnovať aj presahy na prípadne voľné pozadie po stranách pre rozlíšenia vyššie ako 1024×768. Efektívna šírka layoutu je teda 936px a je rozdelený na 18 pruhov šírky 52px (len o 10 viac ako magických 42!). Samozrejme nie je problém šablonu rozšíriť, alebo zúžiť.

Keďže som lenivý, napísal som si malý skript do Fireworks, ktorý mi takýto systém vygeneruje z guidelines:

// cohenoff_gs.jsf
var dom = fw.getDocumentDOM();

dom.removeAllGuides( "vertical" );
dom.setShowGuides( true );

// Padding po stranach
var p = 32;
// Definicia vzdialenosti
var g = [ 10, 32, 10 ];
// Pocet stlpcov
var columns = 18;

var x = p;
for( var c = 0; c < columns; c++ )
{
    for( var i = 0; i < g.length; i++ )
    {
        dom.addGuide( x, "vertical" );
        x += g[ i ];
    }
}
dom.addGuide( x, "vertical" );

// Nastavi sirku dokumentu
dom.width = x + p;
// Nastavi vysku dokumentu na fold
// dom.height = 600;

Ak si to chcete vyskúšať, musíte mať nainštalovaný Adobe Fireworks (alebo starší Macromedia Fireworks). Vytvorte si súbor napr. cohenoff_gs.jsf a vložte do neho tento kód. Otvorte Fireworks, vytvorte nový dokument o veľkosti 1000×600 a spustite JSF súbor (napr. dvojklikom). Tento skript vymaže všetky vertikálne línie v dokumente, vloži nové a prípadne zmení veľkosť dokumentu (viď posledné 2 riadky). Je možné ho spúštať niekoľko krát. Vždy pracuje nad aktuálnym dokumentom vo Fireworks.

Späť k analýze

Na vytvorenie mocného grid systému je treba zistiť čo všetko bude musieť zvládať. Mrknime na všetkých 6 wireframes z predchádzajúcich častí:

Ako vidno, všetky WF používajú maximálne 3 stĺpce: jeden zo sidebarov a obsah, ktorý je niekedy rozdelený na dva. Teraz je potrebné si ešte raz premyslieť či nebude existovať nejaká ďalšia alternatívna konfigurácia, ktorá by vyžadovala stĺpce 4 (alebo 2). Ak sa tento fakt ukáže neskôr, toto je miesto kam sa vrátite znova a všetky výpočty budete musieť zahodiť.

Viem teda, že potrebujem jeden stĺpec ako sidebar a dva rovnako veľké, ktoré spoločne budú tvoriť obsahovú časť. Ja si rád tieto typy stĺpcov označujem písmenami, čiže potrebujem layout typu ABB. Ako však čo najlepšie rozdeliť plochu ktorú mám na tieto tri kusy?

Prvé čo človeka napadne je buď to šupnúť od oka, alebo si dopočítať zlatý rez 18 ÷ φ ≅ 11. Ja som ale zvolil ešte jednoduchšíe riešenie: rozdelil som po 6-tich pruhoch každému (čiže na tri rovnaké diely). Používaním rôzne širokých stĺpcov sa stráca istá krása univerzálnosti, ktorú mám rád. Moje riešenie má však jeden drobný háčik: všimnite si ako je vyriešený sidebar:

Obsahová časť sidebaru je nalepená cez ohraničenie samotného bloku. Text píšeme zľava doprava. To znamená, že na ľavej strane bude blok textu tvoriť súvislú líniu, a teda je potrebné aby vľavo od textu bolo viac voľného priestoru kvôli oddeleniu sidebaru od hlavného obsahu (v tomto prípade ide o 30px). Naopak, pravá strana súvislého textu je nesúmerná (teda ak nepoužívate odporný justify). A preto sa tento priestor opticky zmenší prisunutím pravého sidebaru.

Z predchádzajúcej analýzy tiež vieme, že ľavý sidebar bude zobrazovať štrukturované menu. Tesným zarovnaním jeho ľavej strany tak získame možnosť menu podfarbovať v plnej šírke už od kraja samotného layoutu. Pravý sidebar bude väčšinou obsahovať niečo čo by sa dalo prirovnať k bannerom a tie presahy na pravú stranu rozhodne nepotrebujú.

Grid systém a dizajn obsahu

Teraz si určite hovoríte, že kvôli rozdeleniu stránky na tri rovnaké bloky sa neoplatí patlať sa s grid systémom. Áno, určite, ale ešte sme neskončili. (Typo)grafický návrh obsahu veľa ľudí fláka, aj keď práve z neho sa dá vyťažiť najviac. Vďaka grid systému sa môžete veselo hrať s definovaním pozícií blokov. K čomu nech vám Snap to Guides pomáha.

Na nasledujúcom obrázku som skúšal univerzálnosť systému umiestňovaním blokov pre (ilustračné) obrázky. Pre obrázok som, z pochopiteľných dôvodov, zvolil šírku 292px a pre praktickosť výšku 219px, čiže sú v pomere 4:3, čo je pre klasické screenshoty ideálne. Ku každému obrázku som pridal ešte prípadný priestor pre popisok. Dá sa samozrejme použíť aj iný pomer, napríklad 1:φ: 292 ÷ φ ≅ 180.

Už z tohto pohľadu vidno ako krásne do seba veci zapadajú. Všimnite si ikonu pod nadpisom, ktorá môže byť buď odkazom na daný atóm, alebo ikonou, či číslom komentára. Obsah je skrátený o dva pruhy, pretože som chcel obrázky vysunúť z textu von. Vďaka ich rozmeru 292px (šírka jedného stĺpca) je možné ich pohodlne umiestniť vedľa seba.

Ľavá línia obsahu delí obrázok v približnom zlatom pomere. Približnom preto, že počty sa robia už vo vyššej granularite – v granularite grid systému, nie v pixloch. Ak definujeme rozmery v jednotkách grid systému – teda v pruhoch a pauzách – uvidíme ako systém a pomery v ňom fungujú:

Layout – 18 pruhov
Obsahový stĺpec – 12 pruhov (≈ 1:φ k layoutu)
Text – 10 pruhov (≈ 1:φ k layoutu)
Stĺpec (sidebar) – 6 pruhov (≈ 1:φ k textu)
Obrázok – 6 pruhov (≈ 1:φ k textu)
Ikona – 1 pruh
Obrázok je od textu vzdialený 2 pauzy (= 1:φ k pruhu)
Ikona je vzdialená 2 pauzy od textu (= 1:φ k šírke ikony)
Text delí obrázok ≈ 1:φ

Nabudúce

K dizajnu obsahu sa určite ešte vrátim. V ďalšej časti seriálu ukážem ako vytvoriť vertikálne rozdelenie dizajnu, teda ako vyriešiť umiestnenie hlavičky, ribbonu a obsahu.

intype.info: Manual, Roadmap & Forum

mail@martincohen.info (Martin Cohen) — Thu, 27 Mar 2008 13:02:00 GMT

Tri posledné časti základnej sady wireframes. Keďže z pohľadu WF budú jednoduché, spojil som ich návrh do jedného článku.

Manual

Manuál je vec, ktorá projektu momentálne chýba najviac. V súčasnom stave dynamického vývoja a premien funkčností z verzie na verziu, je veľmi ťažké držať krok. Od verzie 0.3.5 by sa aspoň aktuálne zdokumentované malo stabilizovať a nemeniť v budúcnosti nijak závratne.

Dokumentácie pre featúrky v core aplikácie budú vo všeobecnosti statickým obsahom. Dokonca, väčšina súčasných commandov by sa malo presunúť do JavaScriptu. A JavaScriptové API je to čo mi momentálne vŕta hlavou najviac. Z pohľadu návrhu wireframes to nie je nič dôležité, ale aj tak bude potrebné aspoň napísať na čo je potrebné myslieť:

Dokumentácia by mala byť rozsekaná do ďalej nedeliteľných častí (budem tomu hovorit atómy).
Jeden takýto atóm bude popisovať jednu konkrétnu featúrku.
Každý by mal mať vlastný odkaz.
Atómy by malo byť možné spájať do väčších celkov, ktoré budú pre užívateľa vyzerať ako stránky manuálu.
Každý atomický kus dokumentácie (napr. popis jednej JS metódy) musí byť označený rozsahom verzií API v ktorých je daná metóda platná.
Použiť príjemný formátovací jazyk, ktorý je možné použiť ako v CMS, tak v automatoch na generovanie CHM dokumentácie zbalenej k samotnej aplikácii: Texy! vyzerá sexy.
Systém musí podporovať hlavne FLV videá, pretože ich využitie by malo byť masívne.

Čo sa wireframe týka, nebudem potrebovať pravý “promo” sidebar, bolo by zbytočné aby zaberal miesto. Budem ale potrebovať ľavý sidebar s plytkým navigačným stromom. Ribbon využitý nebude vôbec. Maximálne na úvodnom rozcestníku po manuále.

Roadmap

V úvodnej časti som zhruba naznačil na čo je táto sekcia dobrá. Dnes máme komunitu, ktorá sa aktívne zaujíma o ďalší vývoj. Plány sme držali v tajnosti, ale to sa zmení práve s novým webom. Cieľom bude držať isté napätie a progress otvorený širokej verejnosti. Sľubujeme si od toho silnejšiu väzbu používateľov. Keď už nie na aktuálnu verziu, tak na tie budúce.

Vďaka plánovaniu, ktorému venujeme veľa času sa featúry skôr presúvajú, ako menia, alebo rušia. Väčšinou ide o pozitívny presun k skoršiemu dodaniu. Plánovací systém sa nám overil a tým pádom môžeme zodpovedne publikovať a plniť plány. (Pozn. termíny nebudú zverejnené.)

Sekcia roadmap bude organizovaná v jednoduchom dvoj-úrovňovom strome. Featúry a bugy budú uložené v chlievikoch podľa verzie, do ktorej sú naplánované (tzv. milestones). Ak sa nám podarí udržať aj internú kultúru aktualizácie roadmap, budeme dokonca schopný zobrazovať aj percentuálny progress.

V prvej verzii začneme s jednoduchou stránkou s aktuálnym milestone navrchu a s budúcimi pod ním. Popisované budú hlavne featúry. Bugy sa začnú dopĺňať priebežne spolu s plnením ich issue trackeru. Staršie milestones sa budú udržiavať v archíve. V prípade, že aktuálny milestone je splnený, obohatí sa jeho obsah aj o odkaz na download.

Z pohľadu WF, bude táto sekcia využívať ľavý sidebar s jednoduchou štruktúrou. Roadmap bude sekciou pre nadšencov (podobne ako Development releases v download sekcii). Navigácia bude zahŕňať nasledovné:

Milestones – Implicitný obsah sekcie Roadmap.
Bugs – Zoznam všetkých známych bugov.
Features – Zoznam všetkých plánovaných featúr.

Fórum

Súčasné fórum slúži ako hlavný komunikačný kanál medzi nami a komunitou. Vypublikujeme na ňom všetky nám dostupné informácie. To je síce fajn, ale informácie všeobecne prospešné zapadnú v útrobách stránok a tém. Na nových stránkach bude dôležité upraviť hlavne spôsob ako informujeme komunitu, tak aby sa informácie nestrácali a skôr boli publikované jednostrannými kanálmi ako napríklad blog.

Dnes fórum obsahuje tieto kategórie:

Stable Releases
Troubleshooting / Bugs
Bundles / Add-ons
Feature requests
General discussion
UNSTABLE Releases
Offtopic
Maintainers
Classified

Vďaka novej štruktúre a novým kanálom budeme môcť tento enormný počet tém okresať. Stable a Unstable releases sa presťahujú do sekcie Download. Časť informácii o bugoch do Roadmap (hlavne témy zhŕňajúce bugy do jedného zoznamu). Maintainers a Classified kategórie vypadnú úplne. Výsledok:

General Discussion
Bugs & Troubles
Features & Ideas
Bundles & Plugins
Frequently Asked Questions

FAQ, tak ako sú dnes sa presunú do zamknutej kategórie vo fórach. Tým sa zaradia tam kde ich je treba, odľahčí sa hlavná navigácia a zjednoduší sa ich spravovanie.

Organizácia ostane podobná ako je v súčasnosti: ľavý sidebar a obsah. V ľavom sidebare som prispôsobil formu odkazov z klasických kategórii na lepšie formulácie bežných akcií (Report a Bug, Ask a Question,…). Ribbon som podobne ako na blogu, využil na navigáciu medzi jednotlivými kategóriami.

Ďalšie sekcie

Zoznam sekcií ešte dodatočne obohacujem o tieto tri, ktorých obsah bude postupne naplnený. Wireframes pre ne budem robiť “zaživa” po tom ako dokončím celú analýzu. Nasimulujem tým doplnenie zadania za behu a spôsob akým sa dajú využiť patterny, ktoré budeme preberať neskôr.

Bundles – Sekcia venovaná čisto rozšíreniam bundles s dokumentáciami a vlastnými kanálmi.
Screencasts – Sekcia o featúrach vo forme videí.
About – Tím, filozofia, história a podobné kecy.

Finálna štruktúra bude veľmi blízko tomuto:

Čo ďalej?

Máme za sebou tak trošku nudnú analýzu všetkých kritických častí nového webu intype.info. Konečne môžeme prejsť k niečomu zábavnejšiemu a zistiť prečo je dobré si takúto analýzu urobiť. Ďalej sa budem venovať:

konverzii zadania na požiadavky pre layout
návrhu a zrealizácii grid systému čoby vizuálneho frameworku pre rozloženie jednotlivých blokov
vytvoreniu farebnej schémy
typografii pre obsah a navigáciu
definícii vzorov
praktickej aplikácii vzorov pri rezaní dizajnu
a medzi tým kope ďalších drobností a zlepšovákov

Na konci toho seriálu skončím s hotovými návrhmi pre každú dôležitú časť webu a predám podklady na realizáciu svákovi Ivanovi.

intype.info: Download

mail@martincohen.info (Martin Cohen) — Tue, 25 Mar 2008 12:53:00 GMT

Download je pre mňa kontroverzná sekcia. Pri každom sedení nad ňou buď skončím s prázdnou obrazovkou s dvomi tlačítkami, alebo obrazovkou preplnenou nie vždy účelnými informáciami. A keďže toto píšem bez akejkoľvek prípravy, tak bude zaujímavé kam sa táto sekcia nakoniec dostane.

Požiadavky

Nutno priznať, že bez istej dávky simulovanej schizofrénie sa ďaleko nedostanem. V prvom rade zhrniem svoje myšlienkové pochody:

V sekcii potrebujem zobraziť klasické “zelené” tlačítko Download
Aktuálny release-cycle bude počítať s dvomi vetvami s pracovnými názvami Stable Releases (SR) a Development Releases (DR), sekcia by sa s tým mala vedieť vysporiadať
Pre SR vetvu bývajú novinky podstatne dlhšie, pretože zhŕňajú niekoľko cyklov DR (cca 10 odrážok). DR budú naopak kratšie (cca 3 odrážky).
Optimálna dĺžka jednej informácie v odrážke je cca 160 znakov. Odrážky často obsahujú informácie cielné na konkrétnych užívateľov.

Zhrnutím dostanem zoznam vlastností na ktoré je potrebné sa sústrediť:

Dve časti; jedna výraznejšia.
Pre jednotlivé vetvy je nutné zobraziť novinky (opravené chyby, nové featúrky)
Budem potrebovať kratšiu, pekne napísanú informáciu s novinkami per release ktorá sa zobrazí priamo pri odkaze na stiahnutie. Minimálne pre SR vetvu.

Informácii je celkom dosť. Z Visia mi vypadlo totok:

Myslím, že môže byť. Využitie dvoch stĺpcov sa ukázalo ako dobré riešenie. Čo sa týka oddelenia SR a DR releasov: Pre SR som použil plnohodnotné tlačítko, pre DR textový odkaz.

Účelné je odsunutie tlačítka Download od horného okraja textom tak, aby sa dostalo aspoň do približného vertikálneho zlatého stredu. Deregularizácia tlačítka pre SR a odkazu pre DR ma tiež svoj význam: tým, že nie sú zarovnané k sebe, čiže je zrušený vizuálny kontext, ruší sa aj logický kontext a informácie pôsobia nezávisle.

Pravý sidebar zjavne nebude môcť byť statický (rovnaký pre celý web). Odkaz “Download” by v sekcii “Download” pôsobil celkom hlúpo. Tu bude sidebar zobrazovať duplikáty odkazov na RSS jednotlivých vetiev (rovnaké odkazy budú zobrazené aj v okolí tlačítok, prípadne pod textom v stĺpcoch).

Do budúcnosti bude potrebné myslieť na to, že SR a DR budú pravdepodobne potrebovať samostaté stránky. Momentálne je DR zaujímavejší hlavne preto, že je stabilný a obsahuje nové featúry. To sa časom zmení – predpokladá sa pokles stability, ale za cenu častejších stabilných releasov. Momentálne nám však táto schéma sekcie Download postačí.

Vypadol ribbon

Priznám sa, že rozmýšľam o tom, že skúsim urobiť ešte jednu variantu tejto sekcie s ribbonom.

Mno, pacient zomrel. Táto verzia, síce pôsobí uhladenejšie, ale fakt, že je možnosť veľkého omylu v podobe kliknutia na DR miesto SR ho robí nepoužiteľným.

Back to Roots Bloody Roots

Spojením toho, čo je dobré na WF s ribbonom s verziou bez ribbonu, je možné dostať good enough výsledok, ktorý pre ďalší vývoj celkom stačí:

Odkaz na Development som čisto z praktických dôvodov (viď fail-safe function) odsunul až dolu. Týmto zamedzím omylom takmer úplne a taktiež podporím dvojakosť prístupu užívateľov:

Stable releasy budú sťahovať ľudia, ktorí si Intype chcú vyskúšať, väčšinou ich nezaujíma aké nové featúry v ňom sú, chcú prísť, kliknúť a basta. Pre ostatných sú novinky uvedené pod releasom.
Development, naopak, je pre ľudí, ktorí sa zaujímajú o Intype a sledujú jeho vývoj, preto sú informácie o novinkách predsa len o niečo dôležitejšie.

Ribbon som nakoniec predsa len využil, bez nutnosti jeho znásilnenia. Zobrazuje to, čo bolo jednou z jeho úloh už na hlavnej stránke.

Adobe Fireworks Tutoriály

mail@martincohen.info (Martin Cohen) — Tue, 18 Mar 2008 16:59:00 GMT

Ak používate Adobe Fireworks, ako ja, určite vás nadchne sada tutoriálov skompletovaná chlapcami zo SmashingMagazine...

Adobe Fireworks Tutorials and Downloads - Best of at SmashingMagazine.com

Asset a Button

mail@martincohen.info (Martin Cohen) — Tue, 18 Mar 2008 15:10:00 GMT

O tom ako firemný keyword blocker spríjemňuje prácu našu každodennú...

Blocker, ktorý naša firma používa na blokovanie nemorálneho obsahu prináša nejednu slabú chvíľku ako programátorom tak aj dizajnérom. Náš kamarát nám je totiž schopný zablokovať slová ako asset, alebo button.

V slabej chvíľke človeka pobaví snaď iba predstava prekladu: zadkoň a riťúch.

intype.info: Blog

mail@martincohen.info (Martin Cohen) — Fri, 14 Mar 2008 16:21:00 GMT

Podľa štruktúry nového webu pre Intype je na rade Blog. Kto ho číta? Ako by mal vyzerať? Ako vyriešiť kategórie? Poďme na to...

Cielenie

Pri blogu je potrebné sa zamyslieť kto a ako číta blog. Ja blogy priamo nečítam, používam RSS čítačku. Všetci mne známi potencionálny (alebo už kovertovaní) používatelia používajú RSS. Programátori su hnilší ako ľudia.

Ak vychádzame z predpokladu že drvivá väčšina našich čitateľov používa RSS. Je nutné pripraviť sa na to, že na web v podstate nepáchnu. Iba ak ich niečo zaujme. A keď ich niečo zaujme, tak čo? Prečítajú a stlačia J a je to v prdeli. Ak by sme ale článok dovybavili ďalším detailnejším čítaním v podobe odkazov niekam do iných častí webu, môžeme si jeho pozornosť získať na dlhšiu dobu; podržať ho v teritóriu. Navyše publikovaním kratších, “nutrične bohatých” článkov získame podobu taniera s chutnými jednohubkami (ak to môžem pritiahnuť za vlasy ešte trošku silnejšie).

Na druhej strane, blogy dnes slúžia ako metrika aktivity. Pravidelná publikácia článkov, akejkoľvek kvality, pomáha pôsobiť dojmom, že sa niečo deje. Ale bacha, publikovanie bubliniek z bublifuku vedie k úpadku a neskôr k strate užívateľa.

Nebudem teraz všeobecný, napíšem ako organizujem svoj zoznam RSS ja a sami porovnajte či máte podobný postup:

Ak ma nejaký blog zaujme, pridám ho do čítačky. Málokedy študujem konkrétny obsah daného webu, proste ho tam šupnem a časom sa k nemu vrátim, ale už v čítačke.
Snažím sa držať neprečítané RSS položky na nule. Čo ma nezaujíma označím ako prečítané.
Ak po pár týždňoch zistím, že v danom blogu ma nič nezaujalo, blog vyhodím úplne.

Samozrejme takto dokážem hodnotiť iba RSS feedy ktoré boli zmenené. A RSS čítačky obyčajne zobrazujú iba tie feedy, v ktorých je niečo nové. Čiže ak sa nejaký blog ukáže raz za čas s niečím novým a je to zaujímavé, tak si to prečítam a som spokojný. Feed ostane v čítačke. Obsah a stratégia vládnu. Vždy je lepšie byť chvíľku ticho, ako fúkať vatové guličky ako pudel v priemyselnej ventilácii.

Návrh

Na blogu nikdy nepotrebujete viac ako

Úvodnú stránku blogu s niekoľkými novými článkami
Detail článku s komentármi
Odkaz do jednoduchého chronologického archívu (len nie kalendár, preboha!)

Ako užívateľ nemám rád “klasickú formu blogov” s kompletnými článkami na hlavnej stránke. A to z niekoľkých dôvodov:

Ťažko sa to skenuje, nie som schopný poriadne nájsť ani nadpisy.
Ešte ťažšie sa v tom hľadá. Google aj dnes často vypľuje odkaz na stránku na ktorej je už daný post vytlačený novšími.
Obsah sa duplikuje, pretože komentáre niekde musíte zopakovať.
Nemám čas čítať článok za článkom, stačia mi nadpisy, pripadne trefné výťažky.

Organizácia obsahu

Pôvodne som sa chcel ubrániť kategóriám úplne, ale nech rozmýšľam akokoľvek, bude vždy lepšie mať ich. Akosi som vyrástol z taxo-fetišu a menej je niekedy viac. Preto som sa rozhodol použiť tri kategórie:

Announcements na oznamy o nových rilísoch
Development na programátorské onanie typu nový multi-thread systém
Tutorials na náučné čítanie pre zapálených

A to dôležité: Kategórie sú organizované pragmaticky. Kopírujú záujmové skupiny čerstvých a skalných používateľov. Väčšina z nich bude mať záujem o Announcements, kvôli včasnému zachyteniu dôležitej novinky. Tutorials budú obsahovať krátky popis novej, alebo málo známej featúrky a budú väčšinou odkazovať na obsah v dokumentácii, alebo do sekcie s videami. Čítať ich budú hlavne existujúci užívatelia a konkurencia. Development budú určené pre nenásytných a budú informovať o aktuálnom stave a nových zlepšeniach jadra po technickej stránke.

Do zošítku si zapísujem poznámku: Každá kategória musí mať jasne označený RSS feed.

Nič prekvapujúce na wireframe…

…až na divný pruh pod menu

Volám ho Ribbon. Áno, je to referencia na relatívne nový pattern zavedený v UI Microsoft Office. Tu je to niečo podobné, ale minimalistické. Využívam ho práve na drobnú navigáciu. Ako obsah tak aj forma je vždy prispôsobená danej sekcii. V prípade blogu to budú kategórie a odkaz do archívu. Ribbon je už účelový zásah do ďaľšieho návrhu.

Opäť, smelo do mňa, ak sa vám niečo nezdá.

Ako Cohen sluchátka kupoval

mail@martincohen.info (Martin Cohen) — Fri, 14 Mar 2008 11:01:00 GMT

Je to niekoľko mesiacov, odkedy mi začalo vŕtať hlavou že výkon sluchátok pre iPod Shuffle už nie je aký býval. Hádzal som to za hlavu, až kým som na minulej ceste na Vysočinu nepoprosil Janku aby mi požičala jej sluchátka z novej verzie Shuffle...

Rozdiel bol enormný. K svojim sluchátkam som sa správal ako otčim, často ležali dlho na dne mojej tašky v prachu, tabaku, chlpoch (strunách) a inom bordeli. A ruku na srdce, je to Apple. Istý čas v nich nepríjemne praskalo v mojich obľubených basgitarových pasážach, čo neskôr ustalo a zrejme vtedy začali prestávať.

Rozhodol som sa, že si kúpim nové. Dva mesiace som každý týždeň chodil do nablýskaného blízkeho stánku s Apple produktami. Vždy tá istá veta: “Momentálně nemáme, budou příští týden…”. A nasrať!

I rozšíril som svoje kritériá aj na iné, potecionálne obdobné sluchádlá. Vybral som si jedny, ktoré boli k dispozícii. Stáli 950,- Kč. Vďaka extrémne pomalej pokladni na Apple Mac-u, ktorý tam chalanko mal, som sa rozhliadal po predajni. Ako som uvidel aktuálnu cenu nového iPod Shuffle, zrušil som platbu a poprosil som chlanka, nech mi dá radšej ten. Stál 1350,- Kč. (ten Jankin stál okolo Vianoc cca 3500,- Kč)

Nie som síce hračičkár, ale môj súčasný plat mi umožní si tu a tam kúpiť novú hračku a hrať sa. Bez nutnosti hľadať lacnejšie alternatívy, alebo čakať na zľavy. Ale teraz ma skutočne potešil subjektívne výhodný refresh mojej bižutérie. Chalanko totiž ešte dodal, že originálne sluchádla Apple by ma aj tak stáli takmer rovnako (čo ma neprekvapuje).

intype.info: 2008

mail@martincohen.info (Martin Cohen) — Thu, 13 Mar 2008 16:44:00 GMT

Nový web pre Intype je jednou z aktuálnych tém našich Intype Sync stretnutí. Dizajn je na mne, a rozhodol som sa, že odpublikujem moje myšlienkové pochody na blogu. Aj tak sa tu nič lepšie nedeje...

Zadanie

Nasledujúcich pár viet popisuje veľmi hrubú predstavu o výsledku nášho snaženia. Principiálne nám je od začiatku jasné čo chceme dosiahnuť v prvej fáze. Detaily však vynechávame a skôr ich udržiavame vo forme nápadov, poväčšine v hlavách alebo v Google Doc. Ale k tomu obrublému: V zásade sa štruktúra nebude líšiť od tohto:

Obsah sekcií Homepage, Blog, Manual a Forums je jasný, nie je na nich nič čo by ste nečakali, aj keď ich konkrétny význam je dôležitý pre dobrú funkčnosť webu ako celku.

Sekcia Roadmap je prvou z nových. Jej úlohou bude informovať užívateľov (early adopters) o plánovaní ďalšieho vývoja. Featúry a bugy budú z reportov na fórach presúvané do interného issue-tracking systému a plánované do tzv. milestones (mílníkov). Čo milestone to nová minor verzia Intype. Milestones sú zaradené do troch tagov: Past, Current a Future. Teda tie čo už boli dosiahnuté, aktuálny milestone na ktorom sa pracuje a budúce.

Návrh Homepage

Popravde, všetky sekcie sú všeobecne známe, určite sa k nim dostanem, ale najprv hlavná stránka, ktorá je vždy trošku iná.

Naším produktom je textový editor s inými a novými vlastnosťami. Nebudem to naťahovať a poviem, že hlavnú stránku chceme primárne cieliť na promo featúr. Naše úvahy sú založené na tom kto sú naši návštevníci:

Zvedavci, nespokojenci, frikulíni. Každý z nich používa nejaký editor, je teda dôležité povedať, že Intype chce byť ich novým editorom (a teda že Intype je editor) a čo im môže ponúknuť. Následne, ak sa nám podarí návštevníka zaujať prvými ukážkami, dať mu možnosť dozvedieť sa viac.
Konvertovaní early adopters. Tí čo Intype už používajú, majú poväčšine RSS, alebo aspoň bookmarky. Takže hlavnou stránkou si moc neprejdú.

Dalo by sa uvažovať o tom, že na hlavnej stránke zobrazíme “kto sme”, “zoznam noviniek” a podobné klišé, ale to mi príde ako prežitok. Podobne OpenSource model vyblitia všetkého čo sa kde prdlo na celom webe do jedného zoznamu je istá forma alibistického dizajnu “vyberte si čo chcete a neotravujte”. Tak ako je to v designe samotnej aplikácie na prvom mieste, aj tu sa venujeme hneď tomu dôležitému.

A teraz, ako najlepšie predstaviť featúry, ktoré vychádzajú zo známeho, ale novým prístupom k ich dizajnu z nich môžete vyťažit mocné výsledky? V prvom rade je potrebné urobiť čo najefektívnejší sumár (urobiť z obsahu ľahkú korisť). Viď referencie:

písanie pre web: Obrátená pyramída
navigačná teória: Informačné krmivo
a z neho vyplývajúce Dlhé vs. krátke články

S teóriou lenivosti užívateľov v zálohe, je najlepšie začať videami vhodne rozsekanými do menších celkov popisujúcich jednu konkrétnu featúrku s alternatívnymi kombináciami s inými. Cieľom videí bude vytvoriť istú reťaz, aby užívateľ nedostal kompletnú dávku všetkých informácii a aby sme v ňom vzbudili záujem o viac (primárne) videí. V tejto fáze návrhu príde najlogickejšie nasledovné rozloženie.

Všimnite si prácu s pomyselným zlomom scroll-stránky: To dôležité musí byť nastrkané v hornej časti. Taktiež umiestnenie prvkov v pravom sidebare je “formulované” logicky tak aby návrh podporoval model upútania (Features, Take a Tour) a okamžitej možnosti si produkt vyskúšať (Download).

Nuancie a komunikácia návrhu

Ok, možno chýba niekoľko detailov, ako odkaz medzi všetky videá, optické dováženie pravého sidebaru. Je dôležité ustriehnuť si aby sa do neho nepatlali zbytočné veci, veď ešte sme iba pri hlavnej stránke. Momentálne postačí si nedostatky zapísať vedľa a postupovať na ďalšie sekcie.

Pri návrhu je dôležité prejsť najprv tým najdôležitejším, zvlášť pri klientovi, ktorý ma pocit, že vie čo chce. Následnou priebežnou konzultáciou s ním, je možné vytiahnuť nové poznatky z rukáva a uviesť ich v logickom kontexte. Pochopí to ľahšie a otvori to diskusiu o možnostiach úprav štruktúry stránky.

K záveru, ak máte nejaké to strelivo, pálte. Väčšinou považujem svoje návrhy za nepriestrelné – dodáva to istú dôležitú dávku sebaistoty pri prezentácii klientovi a tým celé dizajnérove vystúpenie naberá istý rozmer profesionality.

Prípadné ostré, trefné a premyslené útoky je ale neskôr treba brať s rozumom, nie s aroganciou, a považovať klienta za rovnocenného účastníka diskusie. Zvlášť u žien je dôležité aspoň raz per session dať za pravdu (poznáte z vlastnej skúsenosti). Typicky práve spomenuté drobnosti vyvolajú tú správnu reakciu u klienta: “Hej, to je dobrý nápad! Čo keby sme vytiahli celú sekciu o featúrach do hlavnej navigácie?”. Princíp zelenej kľukatej čiary ako vyšitý.

Drupal

mail@martincohen.info (Martin Cohen) — Tue, 11 Mar 2008 00:52:00 GMT

Nejde to inak, musím,... nechcem ale musím. Fakt to inak nejde. Je ťažké...

…priznať, že Drupal je prvým CMS, ktoré ma naozaj príjemne prekvapilo. Intype.info plánuje zmenu kabátu. Poučili sme sa na vlastných, a vieme kam ďalej. Plán pre nový inweb je megalomanský. Ostatne ako všetko čo sa týka pozadia projektu Intype.

Pôvodným prerodným plánom bolo zjednotiť hlavnú stránku, blog a fórum pod jednu platformovú striešku. Prvým vhodným riešením bol CakePHP, ale Drupal ma dostal svojím modulom Project s Project Releases a modulom Project Issues. Tento pre mňa doposiaľ nevidený (a podvedome odmietaný) kus spĺňa všetky predpoklady na nový web.

Nastávajúce plány pre nový web sú nemalé a teším sa, ako sa so šrácom Ivkom (áno, diakritika je tam správne) zapotíme pri jeho dizajne a implementácii. Pár prvých lastovičiek je už možné vidieť v dokumentácii. Featúrami pre nový web sú nasledujúce:

Zverejnenie Roadmap projektu s popismi featúr
S príchodom 0.4.0 nová screencast sekcia
Zlúčenie Stable a Unstable a zverejnenie tzv. Cutting-Edge releasov.
Single sign-on
Dokumentácie
Prepojenie administrácie webu s Intype pomocou JavaScript-u
Presun na nový Joyent hosting
Zlúčenie pod doménu intypelabs.com

Potím sa už teraz.

FSHL na Google Code

mail@martincohen.info (Martin Cohen) — Thu, 06 Mar 2008 17:45:00 GMT

Rýchla OpenSource knižnica na zvýrazňovanie syntaxe rôznych jazykov pre PHP ešte stále žije...

FSHL (Fast Syntax Highlighter) je malá PHP knižnica určená na dekoračné zvyrazňovanie syntaxe zdrojových kódov. Začala ako SHL (bez F) s jednoduchým stavovým motorčekom. A neskôr bola prekopaná na snáď najrýchlejšiu PHP-based všetkými smermi rozpínateľnú knižnicu svojho druhu na svete (uff (dve F)).

Jej autorom je Jurko “hvge” Ďurech, aj keď, nutno priznať, že v staršej SHL (zase bez F; ktorá sa stále dodáva s FSHL (a teraz zase s F)) možno nájsť aj kúsky môjho kódu (áno, to sú tie pomalé, bez F). Knižnica sama o sebe nemá moc význam a tak ó-veľký-pán David “dgx” Grudl ukázal ako sa FSHL dá pripojiť do úžasnej Texy!. Vďaka čomu sa FSHL dostalo k užitiu v systémoch ako Drupal, WordPress, Symfony, Joomla, alebo Nucleus.

Aby toho nebolo málo, ujo Ivko “centi” Čentéš ju použil v novej CakePHP verzii jeho veľmi úžitočnej paste aplikácie ToothPaste. Takže ak si FSHL chcete vyskúšať hneď, Toothpaste čaká.

Mno a FSHL od dnes sídli na Google Code.