Vzhůru dolů

Příliš velké, příliš myšlenkově chudé

Mon, 02 Aug 2010 10:36:06 +0200

“(…) paneláková sídliště nejsou plnohodnotným městem. Jsou myšlenkově chudá tím, že tak velké celky vznikly v hlavně jednoho architekta, případně jednoho týmu. (…) Opravdové město je střetem velkého množství různých názorů, pokud možno během velmi dlouhé doby. Je to poutavě vyprávěný příběh čitelný různými směry, který má svou dynamiku, mnohovrstevnatost a svá tajemství.”

— Vlado Milunič o panelákových sídlištích v Literárních novinách.

Původně jsem si poznamenal jako hezký postřeh k architektuře. Na kole mě ale o víkendu ťuklo, že to vlastně dokonale sedí na vývoj webů nebo jakéhokoliv software.

Chystáte se programovat projekt, na kterém v týmu strávíte několik měsíců? Navrhujete design pro web s “50+ šablonami”? :) Děláte takovému projektu informační architekturu nebo SEO? Můžete takový projekt vůbec myšlenkami pojmout a udělat každou jeho část dostatečně dobře? Jen pozor, ať nevyrobíte webový Jižák.

Co bych zlepšil na Weblogy.cz?

Fri, 30 Jul 2010 08:52:00 +0200

Vytvořit agregátor jakéhokoliv internetového obsahu se jeví jako poměrně snadný úkol („To dáš da večer, woe.” – Vláďa, programátor, 16 let) a technicky tomu tak do jisté míry je.

Jenže agregátory by neměly obsah jen triviálně seskupovat, ale také o něm přemýšlet. Kromě náznaků u Facebooku jsem neviděl žádný co by to uměl dobře. A to včetně agregátoru co provozuji. Předkládám tedy na pohled Weblogy.cz sice kritický, ale snad také konstruktivní.

Problém Weblogů před redesignem jsem neviděl ve vzhledu (i když ten nový je mi subjektivně příjemnější), ale v práci s obsahem, jeho rozlišování a třídění. Weblogům chybí editorský pohled člověka nebo alespoň chytrý algoritmus, který by takovou práci zčásti zastal. Změnil bych tři konkrétní věci:

1) Detailnější rozpoznávání kvality

Ano, je sice pravda, že systém Weblogů u každého zdroje umožňuje určit zda je kvalitní a jeho posty se pak odlišují. Jenže zvýraznit zajímavé posty v záplavě jiných tak jak jdou v čase za sebou není dobrý nápad. Když jsme si jistí, že obsah je kvalitní, neměl by za pár hodin zmizet z čelních pozic vytlačený nekvalitními zprávami, jež mají jedinou výhodu — byly vydány později.

A pak — je skutečně každý článek „kvalitního zdroje” kvalitní? Nemyslím, že by všechny články Vzhůru dolů kvalitní byly a naopak PHP triky do Weblogů neposlaly jediný výborný článek. Rozlišovací lupu je myslím potřeba zaměřit na konkrétní články, nikoliv celé zdroje.

2) Rozlišování typů článků

Typy obsahu, jež Weblogy.cz zobrazují bez odlišení vedle sebe, staví uživatele před těžké rozhodování. Třeba: Zdroják zde rozumně publikuje jen články, zatímco Intervalu na Weblogy.cz vychází každá přežvýkaná zprávička ze zahraničního webu. Vsadím se, že neexistuje čtenář, který by se uměl a chtěl rozhodovat, který článek Intervalu bude „zprávička” a který pak „článek”. Zřejmě pak bude tenhle zdroj ignorovat.

3) Třídění obsahu

Weblogy navštěvuje sice určitá konkrétní skupina lidí (web-geekové), ale ta se dále dělí do menších skupin, jejichž témata se překrývají jen částečně. Webové podnikatele, marketéry, programátory, grafiky … všechny zajímají trochu jiná témata.

Na zmiňovaném agregátoru jsem zkoušel automatické třídění obsahu do ručně vytvářených kategorií, které šlo dále kombinovat tak, že čtenář může odebírat jen obsah, který ho skutečně zajímá. Pokud by ji autoři Weblogů zvládli lépe, je to další zajímavá funkce, sice náročná ale dávající existenci agregátoru smysl.

Jsem přesvědčen, že vytvořit a spravovat dobrý agregátor lze, ale ne v nadšeneckých podmínkách nebo jako „bokovku”. Podobně jako u jiných „chytrých” webových služeb, potřebujete spoustu energie, dobrý vývojářský tým nebo editora s vizí a množstvím času. Weblogy.cz i po kosmetické změně tváře bohužel zůstávají na začátku cesty.

Dejte stylopis pro všechna média do jednoho souboru

Mon, 26 Jul 2010 23:26:36 +0200

Mám rád princip tumblelogu. Skvěle funguje pro šíření myšlenek napříč webem. Do blogu si skrze vlastní ego nikdo cizí nápady neprotlačí. Vzhůru dolů je tumblelog. :-)

Mít blog, nemůžu celý post postavit na myšlence Nicolase Gallaghera…

Don’t see the point of setting media queries in the HTML (on ) when setting them in your CSS file is more flexible and informative.

For example, if I’m editing a CSS file I dont want to have to look at the HTML to find out what conditions result in the use of that CSS.

Furthermore, multi-author maintenance is simplified if using one CSS file (media queries set in the CSS) & performance is improved.

Rough rule: Does it affect the site’s presentation? Does someone editing the CSS need to know this? Yes. Then control it in the CSS file.

…jenže k té myšlence nemám co dodat a tak ji pomocí svého tumblelogu šířím dál. Dobrou noc. :-)

Na obranu IE6

Sun, 18 Jul 2010 22:39:00 +0200

Málo věcí je ve webdesignu tak jednoznačných jako image Microsoft Internet Exploreru verze 6 mezi vývojáři. Lze to považovat za kolorit, asi jako nadávky na politiku před volbami. Dvě obvyklá trvzení vývojářů mě ovšem nutí stavět se do opozice ustáleného názoru:

„IE6 je tak málo rozšířený, že jej mohu již nyní směle ignorovat.”
„Ladění webů pro IE6 vyžaduje nadlidské množství nepříjemné práce.”

Obávám se totiž, že jsou často produktem lidské liknavosti, která našla obhajobu ve většinově přijímaném názoru. Takže brousím modré „é”, sundávám brýle a vyrážím na pomoc drahému staříkovi…

V článku uvažujeme v intencích HTML/CSS vrstvy prezentačních webů, v případě aplikací a Javascriptu bude situace jiná.

Můžete ho nenávidět, ale ne ignorovat

Budeme všichni jistě rádi, až si budeme moci dovolit uživatele s IE6 zařadit do nepočetné skupiny „zoufalci používající starý šrot” vedle uživatelů IE5 a Netscape 4.7. Ta situace u velké části webů ještě ale nenastala a dlouho nenastane. Víme jak je šestka zažraná v korporátních systémech a jen tušíme jakou ty mají setrvačnost. (Dožití systémových administrátorů? :-)) Pokud neděláte geekovské weby nebo prostě nemáte štěstí, budete ještě dlouho muset uvažovat s podílem lidí vybavených IE6 na návštěvnosti vašich stránek nad hranicí 5 %.

Průběžné ladění v IE6 — nebolí to

Přátelé, třeba se budete divit, ale i dnes mám skoro u každého webu v sadě testovaných prohlížečů otevřený Microsoft Internet Explorer verze 6. Proč to dělám v případě prohlížeče, který považován za softwarovou verzi ďábla?

Hlavně proto, že to je daleko příjemnější a časově úspornější, než rozšířená metoda „odladím všechny moderní prohlížeče a pak na web mrknu v IE6”. Ta musí zákonitě končit nahromaděním nepříjemné práce, frustrací kodéra, vymýšlením speciálních zjednodušených verzí pro IE6 a následně často nespokojeností uživatelů.

Daleko snazší je uvažovat už při návrhu technického řešení konkrétních prvků stránky v intencích současného stavu rozšíření prohlížečů mezi lidmi. Většina zásadních problémů s IE6 je dobře známých a zdokumentovaných — hasLayout, nepodpora fixního pozicování, PNG alfaprůhlednosti nebo některých CSS selektorů. Naše znalosti promítneme do hledání řešení, které bude fungovat i v IE6.

Pozor, metoda průběžného ladění také v IE6 nespočívá v tom, že moderním prohlížečům nedopřejete jejich CSS3 vlastnosti a že budeme ignorovat technický pokrok. Cílem je prostě mít v kapse základní skupinu ověřených postupů, které fungují ve všech moderních prohlížečích a v IE6. A u toho konkrétního prvku stránky, kde si budeme jistí, že nás IE6 už trochu moc brzdí, zvážíme zda jej prostě neignorovat.

Je dokonalý kód smyslem práce kodéra?

Ano, váš kód nebude nejčistší. V HTML se občas vyskytnou nějaké ty mazací divy atd. Ale položte si otázku, jaký je smysl toho být kodérem: čistota kódu nebo zlepšení uživatelského prožitku technickými prostředky pro co nejširší skupinu lidí?

Patřím k těm co v čistotě kódu ten pravý smysl vývojařiny nevidí. A patřím k těm, kteří se nebojí udělat práci navíc, i když ji ocení jen pár lidí. Začíná to poctivě vyplněnými alt parametry, končí hojným využíváním mikroformátů. Proto například v IE6 obvykle nahradím všechny poloprůhledné PNGéčka pomocí GIFů, protože web pak vypadá výrazně lépe než když to neudělám a načítá se rychleji než když bych nasadil některý z javascriptových fixů pro PNG alfaprůhlednost. I na středně velkém webu je to celkově operace na pár minut, zlepšený uživatelský prožitek lidí s IE6 za to stojí.

Mimochodem, druhý důvod, proč mívám IE6 větší část pracovního dne puštěný a nemám přitom potřebu namazat si každé ráno klávesnici česnekem je tento: S vědomím výjimek lze říct, že co se správně zobrazuje v IE6, bude fungovat v IE7. Proto je šestka spolu s IE8, Firefoxem, Chrome v základní čtyřce prohlížečů, ve kterých šablony ladím průběžně. IE7 pouštím jen jednou za čas — třeba pro závěrečný test šablony.

Vstřícnost vůči IE6 musí být časově obhajitelná

Kolega Kahi při nedávné mailové diskuzi zmiňoval, že se snaží netrávit s laděním pro IE6 větší podíl času na celkovém rozpočtu než je jeho aktuální podíl na návštěvnosti v daném segmentu. Nemůžu než souhlasit a tvrdím, že postupem průběžného ladění je časový podíl rozhodně ještě menší.

Máme tedy stále používaný prohlížeč, kterým web v průměru navštěvuje v průměru dvacetina lidí. Máme také způsob jakým můžeme lidem s tímhle prohlížečem s odpovídajícím vypětím sil nabídnout srovnatelný uživatelský prožitek jako těm ostatním. Co nám tedy brání tu práci udělat? Image vývojářského drsňáka? ;-)

Podtržený hover v Cufónu

Wed, 14 Jul 2010 10:07:00 +0200

Vypadá to superjednoduše, ale není to tak. Chcete-li zmiňovaný efekt zajistit i mimo Firefox, nejdříve totiž musíte povolit hover stav, který Cufón z výkonnostních důvodů defaultně vypíná…

Cufon.set('hover', true)

Metodu set() musíte volat ještě před replace().

Druhý problém je, že CSS vlastnost text-decoration: underline Cufón (ve verzi 1.09) na hover stav nepodporuje.

Pomůže tedy jedině nahrazení podtrhávacího efektu rámečkem: border-bottom: 2px solid blue.

Můžete si jako já ťukat na čelo, ale ono platí — malé technologie, malé starosti… :-)

"Using a browser detect means that you have to constanly maintain the site that contains it:..."

Mon, 28 Jun 2010 10:19:00 +0200

“Using a browser detect means that you have to constanly maintain the site that contains it: professionalism requires you to keep an eye on new browsers, check all your sites in them, and update the special rules for or against this or that browser that you’ve added. This quickly leads to a maintenance hell—one of your own making.”

- … píše Mark Pilgrim v článku The dangers of browser detect z roku 2006. Neuškodí si ho jednou za rok přečíst. U sebe mám odsledováno, že potřeba a chuť detekovat prohlížeče a jejich verze pro potřeby CSS se ke mě cyklicky vrací.

Mark Pilgrim má samozřejmě pravdu, ale znáte to … prvek vypadá všude stejně, ale například v Opeře je posunutý o několik pixelů doprava. (Nemluvě o IE verzí 6 a 7 kde je detekce skoro vždy nutná a pomocí podmíněných komentářů i elegantně řešitelná.) V tom případě je ale detekce vždy až poslední možnost když všechny ostatní byly vyčerpány. Navíc ne vždy je odchylka ve zlobivém prohlížeči tak zásadní, aby se ji vyplatilo řešit.

Najít ji je těžké, ale vyhnout se nekonečnému kruhu aktualizace webu ve chvíli aktualizace prohlížeče je dobrá motivace. Mě se to zatím vždycky podařilo. Co vám?

"Just because you can use a script font to display your primary content doesn’t mean that you should...."

Fri, 28 May 2010 08:16:52 +0200

“Just because you can use a script font to display your primary content doesn’t mean that you should. Save that for headings and accents, keep main content readable and clear.”

- Na Mashable shrnují základní fakta o Web Fonts. Díky Google je teď velmi snadné na web vlastní fonty nasadit, ale dávejte moc velký pozor v případě „chlebového” písma (písma pro delší texty). V naší kotlině jsem na takovýto nešťastný způsob použití narazil u Klábosení, které je na zařízeních bez vyhlazování a také díky nepřítomnosti některých českých znaků ve znakové sadě fontu, špatně čitelné.

Webfonts jsou díky Google zase blíže lidem. Jen ne všem

Wed, 19 May 2010 23:03:00 +0200

Co ale my webdesignéři uděláme s těmi cca 20% lidí, kteří nemají zapnutý antialiasing (například Firefox na WinXP)? Těm Google Webfonts nepomohou. Buď je všechny navedeme k jednomu zatržítku :-) nebo najdeme cestu jak detekovat uživatele bez antialiasingu a nabídneme jim alternativu.

Tumblr nebo Posterous? Nejdřív jeden a pak druhý

Mon, 17 May 2010 15:51:00 +0200

Na Tumblr publikuji aktuální verzi Vzhůru dolů a mám za sebou řadu nasazení pro klienty Shortcat. Dnes jsem konečně pořádně prošel také Posterous. Oba blogovací systémy jsou srovnávány a i když na otázku „Který vybrat?” asi neodpovím všem, několik postřehů bych měl…

Předně — je chybou oba porovnávat jako aplikace pro stejné použití. Tumblr se skvěle hodí pro lidi, kteří chějí publikovat tumblelog, tedy něco mezi blogem a mikroblogem s velkým množstvím multimediálního obsahu. Posterous je čistě blogovací systém, tedy konkurence spíše pro Wordpress nebo dnes už přežitý Blogger.

Posterous je proto nabitý funkcemi, Tumblr jich má myslím trošku méně, ale zato (nebo proto) má výrazně lépe zvládnuté rozhraní. Je to krásně vidět na dashboardu, kde se v případě Posterous dostavuje známý pocit pohledu na řídící panel Temelína, ale „nástěnce” Tumbleru hned rozumíte.

Tumblr tak na první pohled bude srozumitelnější — promiňte to spojení — „obyčejným lidem”. Geeky, kteří se chtějí chlubit počtem zatržítek zatržených během dne, osloví Posterous. :-)

Tumblr mě proto připadá daleko lepší pro ty, co s publikování začínají nebo od blogovací aplikace očekávají hlavně jednoduchost. Tady se opravdu nebudete muset moc učit.

Pokud vám Tumblr začne být malý, nebudete mít problém k Posterous přejít. Ten totiž umí obsah vašeho tumblelogu kompletně importovat a to včetně šablon, pokud je máte vyrobené na míru.

Radek Pavlíček na Zdrojáku skvěle ukazuje jak vidí přístupnost...

Sat, 15 May 2010 09:25:00 +0200

Radek Pavlíček na Zdrojáku skvěle ukazuje jak vidí přístupnost stará a nová norma WCAG.

A mě napadá, že přesně takhle je to s novými webovými technologiemi — HTML5 a CSS3. Dříve webdesignéři čekali, až prohlížeče budou technologii podporovat a pak ji začali hromadně aplikovat. Černá se v jednu chvíli změnila na bílou.

HTML5 a CSS3 ale tvoří velká řada modulů, které se vyplatí nasazovat postupně. Různé moduly se navíc hodí v různých situacích a tak je potřeba každé jejich použítí zvažovat.

Cesta mezi HTML4 a HTML5 tedy nemá zlomový bod, kdy se černá změní v bílou. Je to postupný přechod a ten webdesignér, který čeká na jasně bílou, se ještě načeká…

Dirk Jesse, autor YAML, o CSS frameworcích

Fri, 02 Apr 2010 22:00:00 +0200

Zvládnete němčinu? Kvůli téhle prezentaci byste mohli. :-) Autor YAML v ní představuje svůj pohled na CSS frameworky.

Layout Frameworks im professionellen Webdesign

View more presentations from djesse.

Několik vzájemně nesouvisejících poznámek…

Dirk zmiňuje také nevýhody resetovacích CSS: Meyerova a YUI. Dá se souhlasit s tím, že reset, který mění nativní způsob zobrazování prvků (neboldový nebo seznamy zbavené odrážek) nám trošku přidává práci.

Ostatně, nic takového mě neťuklo, což bude tím, že všechny CSS frameworky, které jsem dosud použil, tyto vyresetované vlastnosti vracely zase zpět. Taky zde slyšíte absurdno a humor?

Neměl jsem tušení, že jeho YAML využívají takhle velké německé weby — Stern, ZDF … To je slušný úlovek! Ale při proklikání webu jeho frameworku vám to dojde — je zde uplatněna zásada, že nikoliv zdrojový kód, ale dokumentace a informační ekosystém dělí technologie na úspěšné a neúspěšné.

Závěrečný výkřik k prezentaci zní: Forma! Vážně — dělal ji člověk, který ví, že forma a obsah se nesmí rozcházet a z každé slídy je patrná (až se chce klišovitě říct německá) preciznost a hlavně úcta a empatie vůči publiku a jeho tužbě nikoliv jen vzdělávací ale také emocionální. Tuzemští prezentující, zamyslete se nad tím. .-)

Milí čtenáři, velikost prezentace není chyba, ale aplikace úmyslu s lepším využitím prostoru pro obsah jež k tomu vybízí, který jsem měl už s redesignem tohoto blogu. Ať se vám dobře prohlíží!

Jak v Internet Exploreru zjistit, zda prvek má hasLayout?

Sat, 27 Feb 2010 00:17:00 +0100

javascript:alert(id_hledaneho_prvku.currentStyle.hasLayout);

Občas se může zdát, že MSIE bug, který právě proklínáte, nemůže ze špatného nastavení vlastnosti hasLayout vycházet, protože ji má určitě nastavenou správně. Ověřte to vždycky raději tímhle způsobem v adresním poli prohlížeč, nejspíš se totiž mýlíte. Vím o čem mluvím. .-)

Manuál stylopisů (a jednoduchost CSS můžeme zase chválit)

Wed, 24 Feb 2010 21:36:00 +0100

Jak se ve změti CSS pravidel webového projektu dobrat systému, který bude snadno přenositelný na jiného člověka? Jak to udělat s technologií, jejíž esencí je jednoduchost? Supergeeky proklínaná a amatéry zbožňovaná vlastnost kaskádových stylů.

Jednoduchost technologie špatný kód neospravedlňuje

„Ach, kdyby jen specifikace CSS obsahovala proměnné!” a další geekovské povzdechy si můžeme odpustit, protože a) právě teď nic takového CSS neobsahuje a b) není jisté, že by to CSS bordelářům skutečně pomohlo. Myslím si, že jednoduchost je velmi dobrá vlastnost jakékoliv technologie, CSS nevyjímaje.

Hezky to dříve popsal Honza Sládek, takže pro argumenty zajděte k němu. My můžeme pokračovat směrem k návrhu řešení palčivé otázky.

Jak z jednotlivých opakujících se pravidel extrahovat informaci o typech písem, barvách či layoutu obecně používaném na webu tak, aby stylopisy splňovaly alespoň základní parametr udržovatelnosti — že jim bude rozumět sám autor, když se ke své práci za tři měsíce vrátí?

Jelikož se snažím se upřednostňovat jednoduchá řešení a vyhýbat se vrstvení technologií, z našich úvah vyřazuji CSS preprocesory jako LESS, čímž ale neříkám, že pro ně nevidím uplatnění.

Poněkud tupý, přesně takový jaký jej chceme — manuál stylopisu

Po mnoha pokusech se mi nakonec obrovsky osvědčila úplně nejtupější varianta — manuál v externím souboru. V adresáři se stylopisy u každého svého projektu najdu soubor README.txt, ve kterém všechny potřebné informace jsou. Kdykoliv pak na webu vytvářím nový prvek, podívám se sem a zjistím jaké by měl mít vlastnosti.

Obsah manuálu

Pojďme se podívat co takový manuál stylopisu může obsahovat.

Kontakty na autora
Seznam souborů a jejich obsah
Písma a jejich varianty
Index z-indexů
Barvy a jejich varianty
Rozměry opakujících se prvků laoyutu

Než plýtvat detaily, odkážu vás na tři své manuály stylopisu, které jsou součástí projektů vyrobených v Shortcat studiu.

BioOKO Pražské jaro Hipposdesign.com

Jedna část manuálu tedy nahrazuje velmi málo se vyskytující manuály designu a také vizuální identity. Další část supluje nedokonalost CSS jako technologie — například pro varianty barev budeme moci brzy začít široce využívat RGBa. Index z-indexů a varianty písem zase sjednocují na jedno místo informace, které bývají rozptýlené po různých pravidlech ve stylopisu.

Manuál stylopisu v žádném případě nenahradí dobře organizovaný, komentovaný a srozumitelně psaný CSS kód. Přidává vrstvu abstrakce, kterou kaskádové styly neumožňují.

Milí čtenáři, více než jindy zde ocením váš feedback a vlastní zkušenosti se správou CSS.

Díky Ondrovi Válkovi za výstřel z Aurory, kterým mě donutil článek oprášit a publikovat.

Otcovsky o organizaci času

Wed, 17 Feb 2010 21:52:00 +0100

Toto je skutečný příběh. :-)

Jedna z věcí, o které mě narození syna obohatilo, je zvýšená ostražitost k neúčelnému trávení vlastního času. Ne tak jak se to říká v knížkách nebo školeních GTD, myslím doopravdy. Jako rodiče mě Honzík vybavil kruhy pod očima a výborným čichem na infiltraci blbostí do času stráveného prací.

Spousta lidí má proti blbostem dobrý imunitní systém. Jenže hlavní hygienik je proti prasečí chřipce odolnější než já proti nesmyslné práci. Důvodům proč ji dělat říkám vnitřně pragmatizmus nebo taky služba vyšším cílům. To se pak dobře zdůvodní blbosti jako:

čtyři roky spravovat web s cizím strašidelným uživatelským rozhraním a stejně strašným technickým zpracováním —— protože se mi jednou určitě klienta podaří přesvědčit, že investice do rozhraní je potřebná a projekt se rázem stane zajímavým
rychle vyšvihnout malý prezentační web, na kterém naprosto nehrozí, že bych se něco naučil —— protože je to pro člověka/instituci, které mám rád a pomůžu jim tím
dvakrát týdně ručně aktualizovat statické HTML stránky různých webů —— protože to zabere chvilku a nestojí za to vymýšlet jak to udělat efektivněji

Pár dní v měsíci takovou práci dělám. Jsem z toho pak trochu otrávený. V nejhorším si vnitřně vynadám, že to je naposledy a zajdu si zaplavat. Zase bude dobře a za měsíc takovou práci vezmu znova.

Pak si znova řeknu, že jsem kůň a v nejhorším si zajdu zaplavat.

Jenže když jsem uprostřed blbé práce a odvedle se ozve synek, to už si nestačí vynadat a večer na bazén. Na protilehlé misce vah není jen můj ztracený čas, ale taky čas, který jsem mohl věnovat jemu. Ono přebalování bývá výrazně smysluplnější než HTML značky sedm let starého webu.

A pak zjistím, že…

klienta se špatným přístupem k uživatelskému rozhraní nemůžu nikdy přesvědčit, protože mu to takhle bude vyhovovat navěky
malý prezentační web budu díky nezáživnosti „vyšvihávat“ pomalu, příteli nepomůžu a projekt skončí oboustrannou frustrací
aktualizaci statického obsahu si nakonec klient rád zrealizuje sám, a mě bude bavit vymýšlet způsob jakým to bude dělat

A tak jako v jiných, i v tomto skutečném příběhu stojí za to opakovat i ta největší klišé: Jediný důvod proč něco dělat, je ten, že nás to baví. Nemusíme dělat cokoliv jiného. Z žádného důvodu.

"Apple si definoval zariadenie, ktoré nebude vyhovovať montérom so skrutkovačom, ktorí okrem..."

Sat, 30 Jan 2010 09:47:07 +0100

“Apple si definoval zariadenie, ktoré nebude vyhovovať montérom so skrutkovačom, ktorí okrem používania prístroja sa v ňom musia venovať aj jeho “administrovaniu”. To u Apple vlastne ani nie je nič nové. Prekvapení sú iba montéri. Ajťákom to bude musieť dôjsť, že Apple nechcel urobiť netbook či laptop.”

- Spravodaj.Madaj.sk o iPadu

Squarespace — aplikace, která vám vezme práci :-) Zatím...

Tue, 26 Jan 2010 22:13:00 +0100

Squarespace — aplikace, která vám vezme práci :-)
Zatím nejpropracovanější webCMS, jaké jsem viděl a také učebnice uživatelskému rozhraní webové aplikace. Doporučuji přihlásit se a učit se, učit se, učit se.

Titulek je samozřejmě nadsazený. Nicméně jsem přesvědčený, že je tady doba, kdy klienti přestanou s poptávkou na prezentační web chodit za námi webdesignéry a budou si nás pouze najímat tam, kde jejich síly ve webových redakčních systém přestanou stačit. A nemusí to být zrovna Squarespace. Už dříve jsem psal o LightCMS, úspěšně se snaží také české Webnode.

Co my na to? Můžeme jít zhrzení do důchodu nebo se radovat ze zajímavější práce než je omílání stále stejných postupů na stále stejných prezentačních webech.

Cufón nebo Typeface.js — který vybrat?

Mon, 25 Jan 2010 19:09:00 +0100

Než budeme moci v prohlížečích začít široce používat @font-face, Typekit a další písně typografické budoucnosti, musíme se rozhodnout mezi třemi hlavními technologiemi sloužícími k nahrazení písma přímo v prohlížeči. sIFR, Cufón a nebo Typeface.js.

sIFR díky komplikovanému nastavování a velmi špatné rychlosti při načítání stránky postupně nahrazujeme jeho současnějšími sourozenci. Oba používají k náhradě canvas, respektive VML v Internet Explorerech a vypadají velmi podobně.

Který z nich zvolit? Na základě dostupných informací se rozhoduje jen těžce. Rozhodl jsem se pro vlastní hloubkový průzkum.

Ovládnout Typeface.js je snadné jako složit skříň z IKEA. Ale kdo by to chtěl dělat bez návodu?

Do dneška čistě intuitivně na všechny projekty používám Cufón. Dnes, při cíleném podrobném prozkoumávání Typeface.js jsem dospěl k tomu, že intuice byla v tomto případě jen synonymem pro dokumentaci.

Typeface.js můžete mít jako vývojáři na první pohled jen těžko rádi. Neexistuje pro něj prakticky žádný podrobnější manuál (na rozdíl od velmi slušně popsaného Cufónu.) Jako vývojářské rozhraní Typeface.js používá Launchpad, což je něco jako Github, kde sídlí Cufón. Ovšem Github z roku 2005.

Tady se znovu ukazuje, že chcete-li uspět jako geek, nestačí vám k tomu technické znalosti. Autoři Typeface.js svým přístupem k dokumentaci a absencí efektivního dialogu s komunitou svůj software dobrovolně degradovali do pozice hříčky, kterou berou vážně jen nadšenci do webové typografie.

Už v tuhle chvíli bychom mohli říct co je a co není dobrý software. Vyhrál by Cufón. Dejme ale Typeface.js ještě šanci.

Typeface.js: Pozor na licenční podmínky

Na webu Typeface.js si písmo vygenerujete poměrně snadno. Původně uměl jen TrueType formát, ten je teď doplněný o OpenType, který je výrazně rozšířenější u písmolijen. Formulář generátoru písma pro Cufón je naproti tomu složitější a zpočátku z něj budete asi docela na větvi.

Jedna z věcí, kterou Cufón ale umožňuje nastavit, je velmi užitečná — jde o omezení funkčnosti písma na určitou doménu. Náhradou písem pomocí sIFR nebo Cufón jste totiž obvykle na hraně licenčních podmínek většiny písmolijen i když vlastní licenci koupenou máte. Omezení na konkrétní doménu písmo alespoň trochu chrání před hromadným zneužíváním a s menšími písmolijnami se na něm určitě domluvíte.

Pokud písmo nahrazujete pomocí Typeface.js, buďte na pozoru. Omezení na určitou doménu nastavit nelze a tak budete pravděpodobně za hranicí toho, co bude vaše písmolijna ochotná překousnout. Raději se ptejte, protože někteří informovanější typografové užití písma pomocí Typeface.js dokonce vyloženě zakazují.

Implementace, rychlost — remíza

Výhodou Typeface.js je o fous snadnější implementace — k prvku, který chcete nahradit prostě přidáte class="typeface-js" a vše důležité si pak nastavíte ve vlastním stylopisu včetně řezu písma. CSS pravidlo pak může vypadat moc hezky i s dopřednou kompatibilitou: font-family: 'Můj řez písma', Arial, sans-serif.

Rychlost obou je v běžných případech srovnatelná. Javascript Typeface je pomalejší, když nahrazujete větší množství nadpisů. Testoval jsem 100 nadpisů na stránce, kde si vzal výkon Firefoxu na dobu o pár vteřin delší než Cufón a z pohledu uživatele byl jistý „zásek” znát.

Je ještě pár drobných rozdílů, které ovšem zrovna na vašem projektu mohou být zásadní:

	Typeface.js 0.14	Cufón 1.09
:hover efekt	neumí	umí
označování textu pomocí myši	umí	neumí, s určitou dávkou štěstí označování funguje v MSIE

Jelikož mám od Cufónu daleko dostupnější informace, budu dále standardně používat jej. Typeface.js ovšem nezahazuju a v případech kdy potřeba označit text myší bude zásadní a zároveň nebudu narážet na problém s licencováním, sáhnu po něm.

Důležité je, že oba dobře přebírají CSS vlastnosti nahrazovaných písem a jsou tedy vzájemně poměrně snadno nahraditelné. Nemusíte se tedy bát, že vás případný přechod na jinou technologii bude nějak zvlášť otravovat jako to mohlo být v případě sIFRu.

Kterou technologii používáte vy a jaký pro to máte důvod? Rád uslyším váš názor v komentářích nebo na Twitteru.

„…a vývojáři v publiku viděli další bodyček, které Yahoo...

Sun, 24 Jan 2010 23:10:00 +0100

„…a vývojáři v publiku viděli další bodyček, které Yahoo dostalo od Google.” Tvrdým nárazem myslím Google Page Speed, dle mých čerstvých zkušeností aspirant na přinejmenším konkurenta vynikajícího rozšíření YSlow pro Firebug.

Yahoo dalo YSlow k dispozici, aby měli vývojáři méně práce s hledáním způsobů jak zrychlit své weby. Google Page Speed přidává navíc některé zajímavé funkce pro kodéry: výpis CSS pravidel, která nepoužívá aktuální stránka (obrázek nahoře) a nebo seznam pravidel, která mu připadají neefektivní z pohledu rychlosti parsování.

"When we filed for our IPO, we attached to the document a statement about how we wanted to run our..."

Sun, 17 Jan 2010 00:27:42 +0100

“When we filed for our IPO, we attached to the document a statement about how we wanted to run our business. We said we were going to be different. We said that we were going to be motivated by concerns that were not always or strictly business ones. This is an extension of that view. This was not a business decision—the business decision would obviously have been to continue to participate in the Chinese market. It was a decision based on values. We tried to ask what would be best from a global standpoint.”

- Eric Schmidt vysvětluje více než sympatický fakt, že Google se nerozhoduje vždy jen na základě byznys cílů a akcionáři s tím musí počítat.

"There’s never really a great way to apologize, but there are plenty of terrible ways. If you’re at a..."

Sun, 03 Jan 2010 20:39:59 +0100

“There’s never really a great way to apologize, but there are plenty of terrible ways.
If you’re at a coffee shop, and you spill coffee on someone by accident, what do you say? You’ll be horrified and say “Oh my god, I’m so sorry!” When you mean it you say you’re sorry - it’s a primal response. You wouldn’t say “Oh my god, I apologize for any inconvenience this may have caused!” But that’s exactly how most companies respond when they make a big mistake.”

- Jason Fried má s omlouváním jisté zkušenosti. Citace z jeho příspěvku do ebooku Setha Godina What Matters Now.