— iOS Human Interface Guidelines
A když půjdeme dále, měli bychom takto uvažovat i o webdesignu na desktopu.
— iOS Human Interface Guidelines
A když půjdeme dále, měli bychom takto uvažovat i o webdesignu na desktopu.
Povzdech uondaného kodéra na Twitteru…
…doprovodily reakce co by se daly shrnout do věty: „Navrhovat newslettery pro Gmail sice je nepříjemné, ale daleko větší nadělení je renderovací jádro MS Outlooku 2007”.
Jasně, MS Word jádro Outlooku 2007 je vážně zastaralé a usilovně se brání všem snahám o náročnější vzhled nebo layout. Jenže Outlook 2007 na rozdíl od Gmailu (a dalších, minimálně českých, webmailů) přináší jeden zásadní vklad do budoucnosti řemesla — podporu stylopisu vloženého do těla dokumentu.
Právě uvnitř elementu <style> se během posledních let odehrává zásadní posun v pracovních postupech kodérů.
Mezi běžně užívanými desktopovými prohlížeči už není žádný co by vložený stylopis nepodporoval. A i když se i na desktopu úroveň podpory různých CSS vlastností liší, kodér se díky media-queries, progressive enhancement nebo vendor prefixům v kapse může zeširoka rozkročit a jeden vzhled jednoho dokumentu navrhout několika způsoby pro dobré, horší i ty nejhorší prohlížeče.
<style> je tlačítko pro zapnutí webdesignu nové generace. Potřebujeme jej ve webmailech.
Prezentace Anthonyho Laforge zajímavá pro každého, kdo se zabývá vývojem software (včetně webů).
Oceňuji zejména přenos myšlenek z jednoho kontextu do jiného. Nemáte-li čas, podívejte se jen na slajdy 2 a 3.
Think of any major website… do they have version numbers? We took the same approach to our client software as an online web service.
A ještě jednu hezkou citaci na závěr:
What would a world look like where we didn’t base our marketing on releases? We market features, not releases.
Výjimečně se stane, že vezmu zakázku nepocházející od klientů Shortcat a navlékám ochranný oblek vývojáře, jež se nechává najímat. A vždy je to zajímavá perspektiva pro mé obvyklé pracovní prostředí s relativně stálými klienty a dlouhodobým hledáním optimálních pracovních postupů v týmu.
Při poslední bokovce šlo o práci na dočasném webu hotelu pro jedno výborné grafické studio, jež s webem přichází do styku jen okrajově. Najímaný kodér se k takovému projektu dostane ve chvíli, kdy grafické studio s klientem dohodlo vizuální styl, způsob prezentace na webu, proběhla diskuze proč je potřeba udělat dočasný web a vytvořen grafický návrh. Vše je vymyšleno, domluveno. Kodér má relativně snadný úkol – web zrealizovat nejlépe jak umí.
Připadá vám takováto kodérova situace normální nebo dokonce optimální? Pak zpozorněte, protože vás chci trochu politovat, ale hlavně vyhecovat k tomu, abyste příště přestali být kodérem a stali se členem týmu. Abyste příště byli při tom.
Analýza, inicializační fáze, úvodní brainstormingy, velký třesk… říkejte si tomu jak chcete, ale určitě se shodneme, že moment, ve kterém se projekt vymýšlí je pro jeho průběh klíčový a hlavně velmi zábavný.
U jednoho stolu sedí klient, programátor, kodér, designér, marketér a další. Návrhy a názory padají hlava nehlava… Sbírka kudel v kapse otevřených a hned zase zavřených. A taky jedinečná příležitost ovlivnit projekt směrem, který z pohledu experta v oboru považujete za správný. Šance jak se na svůj obor podívat z perspektivy ostatních.
Vývojáři často jen chtějí mít fázi třesku rychle za sebou a čekají na výslednou specifikaci, aby se mohli „pustit do práce”. Jenže takový projekt je pak myšlenkově málo pestrý — chybí mu pohled vývojáře.
Technické možnosti velmi ovlivňují práci designéra, ale přinášejí i nový pohled klientovi. Určitě se i vám stává, že klient přehodnotí svůj postoj k řešení webu nebo změní pracovní postupy uvnitř své instituce, když uvidí jak by se mu prodražilo trvání na původních představách.
A bude nezúčastněného kodéra nebo programátora bavit? Nemyslím. Autoři historek o graficích nebo klientech, „co si vymýšlejí blbosti”, přehodnoťte svůj přístup k práci v týmu. Neprošvihněte fázi třesku. Vždy máte šanci blbosti vymýšlet s ostatními.
GitHub Tree Slider z pohledu kodéra — zajímavé nejen díky HTML5 History API, ale také technickým řešením změn obsahu při procházení historií dopředu a dozadu.
Zjednodušeně řečeno: obsah jak jde za sebou v historii je naskládaný jeden vedle druhého zleva v jakémsi karuselu. Oknem (overflow: hidden) z něj vždy vykukuje jen část, které odpovídá aktuální URL. Stránky v pravé části (tedy z pohledu historie v budoucnu) jsou načítány AJAXem. Přesun v historii dopředu a dozadu obstarají extrémně rychlé CSS Transitions.
Inspirativní!