Přejít k navigační liště

Zdroják » Webdesign » Graceful degradation vs. progressive enhancement

Graceful degradation vs. progressive enhancement

Články Webdesign

Co je to graceful degradation? A co znamená progressive enhancement? Proč bychom neměli tyto metody ignorovat? Čím se vyznačují a kdy kterou z nich použít? To se dozvíte v dnešním článku.

Tento článek je překladem anglického originálu vydaného na portálu Dev.Opera.

Úvod

V tomto článku probereme rozdíly mezi dvěma vývojářskými přístupy: graceful degradation a progressive enhancement. Abychom se měli od čeho odpíchnout, začneme definicemi:

Graceful degradation

(Lze přeložit jako pozvolné degradování.) Poskytnout alternativní verzi funkcionality nebo upozornit uživatele na možné problémy a zajistit tak použitelnost produktu v různých prostředích.

Progressive enhancement

(Lze přeložit jako postupné vylepšování.) Začít se základní funkcionalitou a poté krok po kroku zlepšovat uživatelský prožitek s tím, že před aplikací daného vylepšení nejprve otestujeme jeho podporu.

Asi si říkáte, že oba tyto postupy znějí velmi podobně a že by vám měly nabídnout přibližně ten samý výsledek. Jsou zde ale rozdíly, o kterých byste měli vědět a na které se podíváme níže.

Nejprve ovšem vysvětlíme, proč tyto technologie vůbec potřebujeme. Poté se podíváme na podrobnější definici a na příkladu si obě metody srovnáme a řekneme si, kdy kterou z nich použít. Nejprve si ale pojďme říci, proč jsou podobné speciální přístupy k webovému vývoji potřeba.

„Mobilis in mobile“ – pohybujeme se v měnícím se prostředí

Tak jako kapitán Nemo z „20 000 mil pod mořem“, i weboví vývojáři se nachází v neustále se měnícím a kolísavém prostředí, které může být velmi nepřátelské k tomu, čeho se snažíme dosáhnout.

Web byl vymyšlen a definován tak, aby byl použitelný na jakémkoli zařízení s displejem, v jakémkoli jazyce a kdekoli chcete. Jediná věc, která se od uživatelů očekává je, že budou používat nějaké zařízení, které se může připojit na web, a rozumí protokolům používaným k přenosu informací – http, https, ftp, atd.

To znamená, že nemůžeme očekávat jakékoli nastavení nebo schopnosti koncových uživatelů. Také si můžeme být celkem jisti, že naše zkušenost jako webových vývojářů je zcela odlišná od té, kterou mají lidé, které chceme oslovit.

Neexistuje žádný povinný upgrade technologie potřebné pro přístupu k obsahu internetu. Lidé a firmy se budou držet určitého prostředí a nezmění ho jen proto, že my chceme, aby to udělali. Řada lidí chce web pouze konzumovat a technologie v pozadí je vůbec nezajímají – očekávají pouze, že budou schopni se dostat k obsahu, který jsme jim slíbili. Je na vývojářích operačního systému a prohlížečů, aby přiměli koncové uživatele udržovat jejich programy aktuální – my jako weboví vývojáři k tomu nemůžeme říct vůbec nic.

Tohle všechno vytváří velmi křehké vývojářské prostředí. Například kanceláře, kde je předinstalován 9 let starý prohlížeč s vypnutými skripty a pluginy (z důvodu bezpečnosti), s malým rozlišením na monitorech a počítači, které sotva zvládají tu tunu běžícího kancelářského softwaru, jsou celkem běžné.

Mohli bychom teď mávnout rukou a prohlásit, že takovým společnostem ujel vlak“, a že podporovat zastaralé technologie nedává žádný smysl. Ale tento přístup může způsobit, že zapomeneme, že tito lidé mohou být velmi důležití pro úspěch našich produktů. V mnoha případech prostě jen nemají dostatečná oprávnění ke změně jejich technického vybavení. A když dojde na přístupnost, věci jsou ještě více zřejmé: dyslektický uživatel nemůže porozumět našim složitým instrukcím a slepý uživatel nemůže „kliknout na zelené tlačítko pro pokračování“, i když jsme prohlásili, že je to nutné k užívání našich systémů.

Pracujeme v neznámých vodách a potřebujeme najít způsob, jak se tím vypořádat. A tady přichází na scénu jak graceful degradation, tak progressive enhancement.

Degrade gracefully

Ilustrační obrázek. Převzato ze SocialSignal.

Graceful degradation a progressive enhancement v kostce

Jednoduchou definici jste již viděli výše. V této části vám poskytnu techničtější popis obou metod a podíváme se, co vlastně obnáší je používat.

Takže, graceful degradation je způsob vybudování funkcionality tak, že poskytnete určitou úroveň uživatelského prožitku v moderních prohlížečích, ale také ji necháme postupně degradovat na nižší úroveň uživatelského prožitku ve starších prohlížečích. Tato nižší úroveň není tak přívětivá pro návštěvníky vašich stránek, ale stále jim poskytuje základní funkcionalitu, když chtějí vaše stránky použít. Stránky se zkrátka nerozsypou.

Progressive enhancement je podobná metoda, ale jde na problém z druhé strany. Nejprve vytvoříte základní úroveň uživatelského prožitku, kterou budou schopny zobrazit všechny prohlížeče, a poté vytvoříte pokročilejší funkcionalitu, která bude automaticky dostupná pro prohlížeče, jenž ji umí použít.

ČTĚTE K TÉMATU: Musí naše webové stránky vypadat zcela stejně ve všech prohlížečích?

Jinými slovy, graceful degradation začíná od určité úrovně komplexity a snaží se předcházet chybám snižováním uživatelského prožitku, zatímco progressive enhancement začíná od naprosto základní funkčnosti a umožňuje konstantní vylepšování pro budoucí prostředí. Postupně degradovat tedy znamená dívat se zpátky, zatímco postupně vylepšovat znamená dívat se dopředu a přitom stát nohama na pevné zemi.

Graceful degradation vs. progressive enhancement – příklad

Pojďme se podívat na příklad ukazující oba přístupy v praxi.

Odkaz pro vytisknutí stránky

Můžeme se dohadovat o tom, že odkazy umožňující uživatelům vytisknout stránku jsou k ničemu – stisknutí ikony tiskárny v prohlížeči udělá to samé. Ale uživatelská testování ukazují, že jako poslední krok v rezervačním procesu (například na stránkách aerolinií) jsou dobré jako potvrzení o proběhlé akci. Uživatelé cítí, že mají věci ve svých rukou a získají dojem, že úspěšně dokončili to, co začali.

Problém s odkazem „vytiskni tuto stránku“ je, že nemáme možnost vyvolat tuto akci přímo pomocí tlačítka v HTML – musíme použít JavaScript. V JavaScriptu je to jednoduché – objekt window v prohlížeči má metodu print(), která při zavolání dá pokyn k tisku. Pravděpodobně nejběžnější způsob, jak to provést, je použít pseudo protokol  javascript:

<p id="printthis">
  <a href="javascript:window.print()">Vytiskni tuto stránku</a>
</p> 

Tohle samozřejmě funguje, pokud je JavaScript dostupný a povolený a prohlížeč podporuje příkaz print. Ale pokud JavaScript povolen není (například na některých mobilních zařízeních), odkaz fungovat nebude a klikáním na něj se nic nestane. To je problém, protože jako vývojáři webu jste vašemu návštěvníkovi tuto funkci slíbili. Pokud klikne návštěvník na odkaz a nic se nestane, bude se cítit zmatený, oklamaný a právem vás bude obviňovat ze špatného uživatelského prožitku.

Aby tento problém vyřešili, používají weboví vývojáři přístup graceful degradation: řekni uživateli, že odkaz nemusí fungovat a proč tomu tak je a možná dokonce navrhni náhradní řešení. Běžný trik spočívá v použití elementu noscript. Cokoli v tomto elementu bude zobrazeno, pokud cílový uživatel nemá povolen JavaScript. V našem případě by to mohlo vypadat třeba takto:

<p id="printthis">
  <a href="javascript:window.print()">Vytiskni tuto stránku</a>
</p>
<noscript>
  <p class="scriptwarning">
    Pro tisk stránky je třeba mít zapnutý JavaScript.
    Zapněte si JavaScript ve vašem prohlížeči.
  </p>
</noscript> 

Tomuto se běžně říká postupně degradovat – vysvětlíme uživateli, že něco je špatně, a jak to obejít. Bohužel ale předpokládáme, že uživatel vašich stránek:

  • ví, co je JavaScript
  • ví, jak jej povolit
  • má práva a možnost ho povolit
  • nevadí mu, že musí zapnout JavaScript jen kvůli tisku jednoho dokumentu

O něco lepší by možná byl následující přístup:

<p id="printthis">
  <a href="javascript:window.print()">Vytiskni tuto stránku</a>
</p>
<noscript>
  <p class="scriptwarning">
    Vytiskněte si kopii pro potvrzení.
    Zvolte ve vašem prohlížeči ikonu "Tisk",
    nebo vyberte položku "Tisk" z nabídky "Soubor".
  </p>
</noscript> 

Tak se zbavíme některých zmíněných problémů, ale předpokládáme, že funkce print je ve všech prohlížečích stejná. Plus stále zůstává tento fakt – problém s tímto přístupem je, že nabízíme určitou funkcionalitu s vědomím, že nemusí fungovat, a poté to musíme vysvětlovat. Technicky tlačítko „vytiskni“ nepotřebujeme, což je důvod, proč při použití progressive enhancement nepředpokládáme, že bude fungovat.

Pokud bychom měli tento problém vyřešit za použití progressive enhancement, první krok by byl zjistit, zda tu není možnost vytisknout stránku bez skriptování. Což není, a proto není odkaz ten správný HTML element, který bychom měli použít. Pokud chcete poskytnout funkci, která je dostupná pouze s JavaScriptem, měli byste použít button (tlačítko): dle definice button existuje proto, aby podporoval skriptovací funkcionalitu. Specifikace W3C k tomu říká:

stisknutelná tlačítka: stisknutelná tlačítka nemají žádné přednastavené chování. Každé takové tlačítko může být ovládáno skriptem na straně klienta. Pokud dojde k dané události (například uživatel stiskne tlačítko, pustí jej atd.), spustí se daný skript.

Druhý krok je nepředpokládat, že uživatel má zapnutý JavaScript a že prohlížeč umí tisknout. Místo toho prostě řekneme uživateli, že by si měl dokument vytisknout a způsob již necháme na něm:

<p id="printthis">Thank you for your order. Please print this page for your records.</p> 

Tohle funguje v každém případě. Pro zbytek funkcionality použijeme unobtrusive (nevtíravý) JavaScript, kterým přidáme tlačítko „tisk“, pokud jej uživatel podporuje.

<p id="printthis">Thank you for your order. Please print this page for your records.</p>
<script type="text/javascript">
(function(){
  if(document.getElementById){
    var pt = document.getElementById('printthis');
    if(pt && typeof window.print === 'function'){
      var but = document.createElement('input');
      but.setAttribute('type','button');
      but.setAttribute('value','Print this now');
      but.onclick = function(){
        window.print();
      };
      pt.appendChild(but);
    }
  }
})();
</script> 

Všimněte si, jak opatrný tento skript je – nepředpokládáme v něm vůbec nic.

  • celou funkcionalitu jsme zabalili do anonymní funkce a rovnou ji zavolali ( function(){})()) – nenechali jsme po sobě žádnou globální proměnnou
  • testujeme podporu DOM a zkoušíme získat element, do kterého chceme přidat tlačítko
  • poté otestujeme, zda element existuje a jestli má prohlížeč objekt window a metodu  print
  • pokud je obojí v pořádku, vytvoříme nové tlačítko a aplikujeme na něj window.print(), jako akci po kliknutí
  • v posledním kroku vložíme tlačítko do našeho odstavce

Toto bude fungovat pro každého uživatele na jakémkoli technickém zázemí. Nikdy jsme uživateli neslíbili element, který nefunguje – místo toho jej ukážeme pouze ve chvíli, kdy funguje.

Kdy co použít

Možná jsem idealista, ale opravdu nemám rád myšlenku graceful degradation. Vytvořením něčeho a poté zajištěním, že to bude aspoň trošku chodit v různých prostředích (a nebo chci-li, aby uživatel upgradoval), totiž předpokládám spoustu věcí o uživatelově prostředí či jeho možnosti upgradovat.

Osobně často používám Blackberry, když na notebooku nemohu chytit WiFi, a opravdu mě vytáčí, když mi webová stránka řekne, že potřebuje povolený JavaScript a měl bych si jej zapnout. Nemůžu a přesto rozhodně jsem právoplatný uživatel té webové stránky – zvláštně pokud platím spoustu peněz za GPRS nebo EDGE za přístup.

Každopádně graceful degradation přichází v úvahu v následujících pár situacích:

  • Vylepšujete starý produkt a nemáte čas, přístup nebo porozumění produktu pro to, abyste vše změnili.
  • Prostě nemáte čas dokončit produkt s plným progressive enhancement (často je to známka špatného plánování nebo toho, že dochází peníze).
  • Váš produkt je jeden z krajních případů, například stránka s ohromným trafficem, kdy každá milisekunda výkonu znamená rozdíl v milionech dolarů.
  • Váš produkt je svou povahou tak závislý na skriptování, že má mnohem větší význam udržovat „základní“ verzi, než nějakou vylepšovat (mapy, emailový klient, RSS čtečka).

Ve všech dalších případech, progressive enhancement je to, co udělá vás i vaše uživatele šťastnější:

  • V jakémkoli prostředí poskytnete produkt, který funguje.
  • Když vyjde nový prohlížeč nebo se rozšíření prohlížeče stane velmi rozšířeným, můžete vylepšit svůj produkt ještě o další úroveň bez toho, aniž byste se dotkli originálního řešení – graceful degradation by vás nutila ke změně originálního řešení.
  • Umožníte technologii, aby byla tím, čím být má – prostředek k rychlejšímu dosažení našeho cíle, ne „nutnost“ k dosažení cíle.
  • Pokud potřebujete přidat novou funkcionalitu, můžete to udělat poté, co zjistíte, zda jsou na určité úrovni podporované potřebné technologie, nebo tuto funkcionalitu můžete přidat do úplně základní kostry a vylepšit v sofistikova­nějších prostředích. V každém případě údržba probíhá na jednom místě a ne na dvou. Udržovat produkt, který používá progressive enhancement, aktuální, je mnohem méně práce, než udržovat dvě verze.

Shrnutí

Někdo možná řekne, že progressive enhancement i graceful degradation se snaží udělat tu samou věc: udržovat náš produkt použitelný pro každého uživatele. Progressive enhancement je sofistikovanější a zároveň stabilní cesta jistoty, ale zároveň zabere trošku více času a přidá práci. Graceful degradation můžeme použít mnohem jednodušeji jako rychlou opravu stávajících produktů; znamená to složitější údržbu, ale nevyžaduje to na začátku tolik práce.

Tento článek je překladem textu Graceful degradation versus progressive enhancement, jehož autorem je Christian Heilmann a je zde zveřejněn s laskavým svolením Opera Software.

Graceful degradation nebo progressive enhancement?

Komentáře

Subscribe
Upozornit na
guest
59 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
mekele

velmi pekny clanek, diky

Petr Staníček

Souhlasím s autorem, dávám rozhodně přednost technice "postupného vylepšování". U webu začínám se základní funkcionalitou na úrovni holého HTML a postupně přidávám CSS, JS atd. coby nepovinná rozšíření. Nic není černobílé, jsou případy, kdy dám přednost druhému způsobu – např. u RIA bez požadavku na funkčnost bez JS, tam pracuji rovnou s plnou funkcionalitou a ve finále doplním redukované funkce či rovnou odříznu nevyhovující klienty. Ale to jsou spíš výjimky, u většiny webů jedu "odspodu", postupným přidáváním funkcí, které jsou koncipovány jako nepovinné nadstavby. Osvědčilo se mi to jako nejefektivnější postup.

martin

Ono slovo "graceful" znamená mj. elegantní, uhlazený, vybraný — a o to tady myslím jde — udělat tu degradaci tak, aby to nerušilo, netvrdilo uživateli něco, co u něj není pravda, nenutilo jej dělat něco co nechce. A to je obvykle docela těžké, takže je lepší na to jít z druhé strany…

Martin Hassman

Ano znamená, já jsem se kdysi dávno pokusil přeložit graceful degradation jako "uhnívat s elegancí", ale nesetkalo se to s úspěchem 8-)

Jinak ti staří webdesigneři patrně dají v životě přednost graceful degradation, už jen podle následujícího stripu: http://www.socialsignal.com/news/2007/08/14/thats-how-i-want-to-go

Martin Hassman

Škoda, že jsem si na tenhle vtip nevzpomněl dřív. Takhle jsem ho do článku přidal až teď.

Borek Bernard

"Pozvolné degradování" mi taky nepřipadá jako vhodný překlad ("grafecul" nemá s pozvolností nic společného), ale když jsem nad tím tak přemýšlel, ono najít nějaký dobrý překlad je hodně těžké (oceňuji, že se v článku povětšinou používá anglický originál).

Jinak věcná poznámka: o graceful degradation se často mluví ve spojení s formuláři odesílanými přes AJAX, kde se za ono řešení s omezeným uživatelským komfortem považuje odeslání formuláře přes běžný submit button. Zde je zajímavé, že podle terminologie použité v článku se vlastně jedná o progressive enhancement – začnu s HTML formulářem a AJAX přidávám až zpětně, i když je využití JavaScriptu od začátku mým plánem. Kdyby si autor vybral tento příklad, rozdíly mezi graceful degradation a progressive enhancement zdaleka nevyniknou tak ostře.

pepak

Rozdíl totiž (IMHO) není ve výsledku toho procesu, ale ve způsobu, jakým se k tomu výsledku dojde – progressive enhancement začne s čistým HTML funkčním všude, graceful degradation začne s dokonalým UI, ale postupně se oba propracují ke stejnému výsledku (klidně i se stejným kódem).

Borek Bernard

Já právě nesouhlasím s tím "graceful degradation začne s dokonalým UI" – příklad AJAXových formulářů ukazuje, že s pojmem graceful degradation se běžně pojí i techniky, které začínají od plain old HTML a JavaScript přidávají postupně.

Martin Hassman

Šlo by najít nějaké historické odkazy? Ono u těchhle uměle zavedených termínů je problém s argumentací pomocí pocitů "já to vnímám takhle". Byly zavedeny uměle (někdo je někdy definovat). Termín se pak začne používat a vyzrávat (nebo postupně degradovat 8-)). Otázka zní: jsme schopní najít, kdo prvně začal (aspoň orientačně to "kdo prvně") používat termín v tomhle kontextu? Třeba pak vystopujeme i proč. Jinak je těžké v téhle diskusi pokračovat (já si mohu pod tím termínem představit tucet věcí a Franta od vedle zas něco jiného)

Borek Bernard

Já zas takový faktograf nejsem :) Jen si zkus vygooglit "graceful degradation ajax forms" nebo mrknout na Wikipedii: http://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Graceful_degradation . Bez ohledu na tvrdá data je fakt, že pojem graceful degradation se ve světě webdesignu používá i pro scénáře, které popisu z článku odporují. Na tento problém jsem chtěl upozornit, nic víc.

Martin Hassman

Tak slovníky ten termín znají a překládají jako „omezený provoz„, jenže ani to pořádně nevystihuje podstatu.

Borek Bernard

Podle toho slovníku by se to taky dalo přeložit jako "rozkošné ponížení", což by nás dostalo do úplně jiného oboru :)

Já si myslím, že někdo kdysi potřeboval do svého článku nebo práce nějaký vznosný pojem a tak si vybral vědecky znějící "graceful degradation", ač má angličtina pro danou situaci řadu jednodušších pojmů, např. fallback. Ale to by asi znělo příliš prostě :)

Martin Hassman

Anebo také "spanilé zbavení úřadu" 8-)

Jan Molič

Nikdy jsem nepřemýšlel, jak ty weby vlastně dělám, ale zjišťuju, že nejraději používám třetí metodu: Degraded :-)

Jde o to, že většina "prožitků" z webu 2.0 pouze obtěžuje. Podle mého názoru mají uživatelé raději, když se web chová předvídatelně, a tudíž vždy stejně. Například upload souborů: 1. vyberou soubor, 2. stisknou submit, 3. stránka se načte znovu změněná -> pokud ale hned po vybrání souboru se tento sám uploaduje a stránka se okamžitě změní, začnou zmatkovat, protože si třeba uvědomili, že chtěli jiný soubor, stisknou Zpět a ono je to dostane úplně někam jinam…

Chci říct, že je to pořád jenom "starý stejný blbý web", ať se mu módně říká "web X.Y", "zážitkový web", nebo se o něm mluví v jiných moderních pojmech. Přeji příjemný prožitek z webu!

mekele

.. chvilku si odpocinout od ilikethis?

karmi

Diky Zdrojáku za překlad skvělého článku! Právě podobný obsah v češtině docela citelně chybí.

Ondřej Mirtes

Nerad bych byl za Howeena a další individua, ale tyto dvě (svým přístupem odlišné) metody mi stále splývají. Osobně se klaním ke graceful degradation, vždycky jsem jí zastával, aniž bych věděl, že to má nějaký název. V praxi to pro mě znamená, že web musí být plně funkční i bez Javascriptu a sémanticky správný, pokud někdo browsí s vypnutým CSS, případně dát správné barvy elementům, pokud uživatel browsí se zapnutým CSS, ale bez načítání obrázků. Jiné rozdíly web mít nemůže, musí všude vypadat stejně, kvůli klientovi. On chce, aby i ve svém IE6 měl všechny ty grafické serepetičky, co si grafik ve Photoshopu vymyslel.

Progressive enhancement, zdá se mi, nemačká z nemoderních browserů maximum. Vždyť i v IE6 jde zpracovat jakýkoli grafikův nápad. Vždyť je jedno, jestli použiji moderní CSS3 features, které nejsou rozšířené a tudíž je nikdo neuvidí, všechno jde udělat i pomocí starších a méně praktických selektorů. Důležitá je funkčnost (i designu, i webu jako struktury) a ta musí být všude stejná. Lidé s Javascriptem uvidí obrázek v Lightboxu, lidé bez něj klasicky v panelu prohlížeče. Klienta nezajímá, jestli rohy udělám v CSS3 nebo pomocí obrázků, on je chce vidět v každém prohlížeči.

IMHO – Pokud bych bral progressive enhancement důkladně, musím se v závěru dostat do pozice, kam bych se dostal s graceful degradation. Neumím si představit featuru, kterou bych v nemoderním prohlížeči (čti: IE6) neuměl zpracovat…

To je jen můj názor. Jsem oproti ostatním diskutujícím a hlavně autorovi článku relativně laik (Honza aka Zahon je můj velký CSS guru ;)), ale s webdesignem pracuji a schopný web vytvořit dokážu. Progressive enhancement je zajímavá myšlenka, nicméně v praxi a komerčním sektoru nepříliš použitelná a náročnější.

Hoween

Relativně laik, ale ten řitní alpinismus vám jde dobře.

Martin Hassman

Pochválit někoho, třeba protože si ho vážím, na tom není nic špatného. Ano, někdy je to těžké a vyžaduje to trochu odvahy, ale jedná se většinou o pěkné vyjádření emocí, bez ohledu na to, zda to všichni ostatní pochopí nebo ne.

Hoween

Mete, zkus si projít většinu článků zde na Zdrojáku a udělej si rešerše komentářů. Dobrá polovina z nich je opravdu jen ve stylu "skvělé díky", což jsou komentáře asi tak přínosné, jako "první", "druhý" až n-tý.

A je to možná jen specifikum Zdrojáku, že se v komentářích leze hlavně autorům do zadku, zatímco na sousedním Rootu se normálně diskutuje a nikdo tam autorům do zadku neleze. A možná jen proto, že zatímco do webdesignu dnes "dělá" každý nevycválaný čtrnáctiletý puboš, tak na provoz serveru s XY je přece jen kus té inteligence a mentální vyspělosti potřeba.

Honza

Odkdy je poděkovat na obtíž? Komentář První, Druhý… atd nevypovídá nic o kvalitě článku. Poděkování za článek jest odezvou od čtenáře, kterému stálo za to obětovat tu trochu času, aby pár zdvořilostních slůvek napsal. Autora jistě potěší a může ho to motivovat k napsání dalšímu článku.

Pokud mám co říci k problematice, vyjádřím se. Pokud mne článek oslovil a obohatil – poděkuji. Pokud s ním nesouhlasím, napíšu proč a v čem. Ne každý, kdo poděkuje, se chce vyhřívat v autorově rektu.

K článku: Já osobně preferuji postupné přidávání život zpříjemňujících prvků. Na stejnou horu se dá dostat více cestami a tato mi vyhovuje.

Jan Jelínek

Jen malá reakce: nevím zda-li jste někdy nějaký článek psal, ale když někdo píše článek tak mu to nějakou tu hodinu zabere. Z vlastní zkušenosti vím, že pokud někdo napíše: Ok, dobrý článek, dík. Tak to potěší a vím že těch pár obětovaných hodin za něco stálo.

Vy uvádíte za příklad server root.cz. Já vám oproti tomu dám příklad 99% zahraničních serverů, kde čtenáři pokud se jim článek líbí vyjádří dík.

Ono jakkoli se na to díváte, poděkování je slušnost, ne slabost.

A co si myslím já? Že je proklatě jednoduché si dát jako avatara kreslenou postavičku a jako jméno prapodivnou přezdívku. Dejte si tam vlastní fotku a svoje skutečné jméno, alespoň ukážete že si skutečně za svými komentáři stojíte.

Takhle mi nezbývá myslet si nic jiného než že jste srab.

Hoween

Ať čtenáři zvyšují autorovi karmu, zvyšují mu honorář… Máme XY možností, jak to vyjádřit. Že zdejší systém žádný nepodporuje a diskuze je tak zaplevelovaná komentáři typu "super dík" je dost smutné.

Mimo jiné, jak vím, že je to vaše fotka a vaše jméno? Za svými názory si stojím stejně, ať už se jmenuju jakkoli – a na internetu jsem pod touto přezdívkou a avatarem na více místech. Změní se něco tím, že se přejmenuju na Františka Kadlece? Nebo Brunhildu Volopichovou? Myslete co chcete, s takovým názorem pro mě nejste partner k diskuzi a jste mi ukradený.

Brbla

Skoro mi to připadá, že Vám za Vaši práci nikdo řádně nepoděkoval. Tak snad za všechny slušné a bez sarkasmu a ironie!, která by v této reakci mohla být cítít:

"Zcela upřímně – a bez jakýchkoliv vedlejších narážek na cokoliv – já Vám děkuji za Vaši práci v CZille. Setkával jsem se tam s Vámi v příspěvcích a mnohokrát mne navedly na správnou cestu, jak problém úspěšně vyřešit. Ať už jste František Kadlec nebo Brunhilda Volopichová, dík ;-)."

A k těm děkovacím komentářům – podle mne je lépší plná diskuze komentářů, než nic. Alespoň je vidět, že to někdo četl a že mu to pomohlo 87).

Ondřej Mirtes

Ne, jen necítím potřebu stát si za svým názorem, pokud vím a umím si připustit, že existují zasvěcenější. A chci se zlepšovat a učit se nové věci.

Přemýšlel jsem nad tím a potřebuji upřesnit pojmy, na příkladech:
Je GD o tom, že poskytnu např. odkaz na vytisknutí stránky, který povede na novou stránku se stylopisem pro tisk a díky window.print() v body->onload se lidem se zapnutým JS rovnou zobrazí i dialog tisku? Lidé bez JS dostanou výsledek stejný, ale čeká je klik navíc, do nabídky prohlížeče.
PE – Dělám veliký formulář. Lidem s JS ho po načtení stránky skryju, nebude jim překážet, pokud si jen chtějí přečíst submity ostatních, které jsou pod formulářem. Navíc ještě udělám kontrolu validity formuláře pomocí AJAXu, která se volá při onchange každého formulářového pole. Lidé bez JS budou mít formulář otevřený stále, tudíž jim může překážet, kontrola validity bude čistě server-side, bude se muset reloadovat celá stránka.

Navíc nevím, jestli jsou oba pojmy aplikovatelné na všechny aspekty webdesignu. (Javascript, modernější featury v nových verzích CSS apod.)

Pokud jsem pojmy prohodil, nebo se v obou případech jedná o ten samý, opravte mě a uveďte mi prosím správné příklady. Díky :)

Hoween

Ajaxová validace při onchange? Chudák server, provádět XY naprosto zbytečných validací, když by stačila jediná na onblur…

Já oba pojmy ignoruju, holt si pár webdesignérů už připadá méněcenných, tak si vymysleli podobné cool pojmy a teď o nich píší podobně "zasvěcené" články. Přitom se to celé dá shrnout do jediného pojmu "funkční web". A pokud dodržím i zásady použitelnosti a přístupnosti, tak je přece úplně jedno, kterou z těch dvou technik jsem toho dosáhl.

Hoween

Celý problém tohoto "tématu" je v absenci jakéhokoli rozdělení obou technik a vymezení hranic. Co je pro koho co? Pro Petra Staníčka je základem HTML, a už jen připojení CSS je pro něj vylepšení. Jenže zákazník by holé HTML nikdy neakceptoval, takže z mého pohledu je základem třeba HTML + CSS a funkční holé HTML je pro mě naopak degradace.

Takže co vlastně články na toto téma řeší? Tisíc slov v podstatě o ho***, které se dají shrnout do jedné věty "Dělejte funkční web". Skvělé, o to se snaží webdesignéři od začátku, ale poslední dobou by to bez těch cool pojmů asi nebylo ono.

Langi


Takže co vlastně články na toto téma řeší? Tisíc slov v podstatě o ho***,

Ne, mě to zajímá, já si to přečtu rád, s chutí a ještě se i něco dozvím ;-) Nelíbí? Nečti.

Hoween

Co se dozvíte? Že máte dělat funkční web? To jste to doteď nevěděl? ;-)

Anonymní
4. 3. 2009 14:24 smazal Martin Hassman, důvod: Spam.
Karell

"delejte funkcni web" je jen hole sdeleni, nejaky cil
V clanku byla popsana metodika, jak tohoto cile dosahnout, cili nejaky postup. Takovy postup muze byt dobry pro zacatecniky, aby vubec vedeli jak na to, muze byt dobry i pro stare harcovniky, aby si uvedomili, jak pracuji a co muzou na svem pristupu vylepsit. Take muze byt dobry pro nekoho, kdo planuje postup vyvoje projektu. V neposledni rade take pro rigidni vyvojare (kteri si mysli, ze vedi vsechno a nic noveho uz se nemohou dozvedet), jako trenink v rozsirovani obzoru.

Co je zakladem je v clanku jasne sdeleno: zaklad je to co dovedou zobrazit vsechny prohlizece – pokud chce nekdo psat pro lynx nebo roboty, tak je to pro nej treba jen to html. Asi nema smysl neco takoveho specifikovat primo v metodice, kdyz to bude pro kazdeho jine.

Mozna jste clanek dobre necetl, mozna mate problem porozumnet psanemu textu. Asi pro vas byl prilis narocny a bude lepsi zacit s nejakou jednodussi problematikou. Treba o tom co znamena postup a co stav. Az tohle zvladnete, tak muzete na slozitejsi kousky. Takovy progressive enhancement ;-)

Hoween

Pokud jako základ berete to, co zvládnou všechny prohlížeče, tak jste někde na holém HTML, a cokoli dalšího je vlastně progressive enhancement. Tak k čemu definovat nějaký gracefull degradation? Jak chcete degradovat holé HTML?

Já problém s psaným textem nemám. Mám problém s tím, proč někdo definoval takovou neskutečnou kravinu, o které se teď píšou články a vůbec se to považuje za děsně kchůl, postavit se na jednu, nebo druhou stranu. Přitom v konečném důsledku je každému úplně ukradené, jak se k výsledku došlo.

Karell

Jak rikal jeden ucitel na MFF: vy mate blok, vidte? Pokud jste sem prisel jen opakovat, ze to je kravina, tak pro vas tato diskuze asi nema smysl. Pokud je to jinak, tak opravdu bude lepsi, kdyz si clanek prectete, zvlaste pasaze o gracefull degradation.

Vysledek praveze zavisi na tom, jak se k nemu dojde, nakonec se podoba muze hodne lisit (napr. podobne, jako kdyz se pro pristupova prava pouziva allow/deny nebo deny/allow) a to prinejmensim udrzbare toho kodu bude zajimat. Z hlediska spolehlivosti a citelnosti kodu to muze byt uplne odlisne.

Hoween

> Jak rikal jeden ucitel na MFF:
U pisoárů stojí strojař a matfyzák. Strojař zapne kalhoty a odchází. Matfyzák udiveně říká: nás ve škole naučili mýt si ruce. Strojař mu odvětí: nás naučili si je nepoch*at.

> Z hlediska spolehlivosti a citelnosti kodu to muze byt uplne odlisne.
EEhh? Výsledek obou "metod" má vést ke stejně spolehlivému kódu. Cílem je podat uživateli informace, které musí být přístupné ve své základní podobě za všech okolností. Že se do návrhu aplikací vrhá každé ucho, co sotva zvládlo stáhnout jQuery a nemá žádné povědomí o nějaké přístupnosti, nebo použitelnosti, je obrovský problém dnešní doby. A podobné pseudometody se to jen snaží omlouvat.

Co se týká čitelnosti kódu, to myslíte vážně jako nějakou seriózní myšlenku? Jak může něco takového ovlivnit čitelnost kódu? Kód se dá napsat buď dobře, nebo špatně, nezávisle na jazyku a použitých metodách vývoje.

Karell

> Výsledek obou "metod" má vést ke stejně spolehlivému kódu.
Otazka je, jak to bude vypadat v praxi a jak narocne bude toho dosahnout. Da se nahlednout, ze vyjmenovat situace, kdy musi byt nejaka featura nepouzita je narocnejsi, ne-li nemozne s ohledem na dalsi vyvoj technologii. Naopak vyjmenovat pripady, kdy se neco pouzit muze je radove jednodussi a snadno resitelne. Je zrejme, ze to bude mit vliv i na design (a jeho narocnost) aplikace. Stejne tak je zrejme, ze vylepsovani lze delat planovane a s rozvahou. Na druhou stranu v pripade degradace se nelze vyhnout pripadum, kdy se az dodatecne po spusteni aplikace zjistuje, kde vsude je jeste potreba degradovat – a to rychle a zbesile. To ma samozrejme neblahy vliv na kvalitu kodu.

Co se tyce citelnosti, tak jsem se asi nevyjadril uplne stastne, myslel jsem tim obecne kvalitu, ted uz je to snad jasnejsi.

> A podobné pseudometody se to jen snaží omlouvat.
kde?

Asi jsem naivni, ale myslel jsem, ze na tohle prijdete sam az pochopite o co v clanku jde.

Ja uz k tomu asi nemam co dodat. Beru, ze genium jako vy staci rict "Dělejte funkční web" a vsechno navic jsou jen kraviny, vy zas muzete prijmout, ze ostatni smrtelnici se radi zamysli nad tim, jake postupy jsou vhodnejsi a jake mene. Jen me zneklidnuje, ze podobne nazory slycham od lidi, kteri ustrnuli nekde pred 20 lety, kdy dosahli dokonalosti a vse co se stalo potom uz pro ne bylo zbytecne. To si ale musite vyrikat hlavne sam se sebou.

Martin Hassman

Jen me zneklidnuje, ze podobne nazory slycham od lidi, kteri ustrnuli nekde pred 20 lety

Zrovna dnes jsem tohle řešil s jedním kolegou, který byl šokován, že si někdo odváží otevřeně psát v češtině o „graceful degradation vs. progressive enhancement“, aniž by pořádně řešil, že Češi k tomuhle většinou ještě nedospěli – on to tedy trochu zobecňoval, je jasné, že je to případ od případu.

Ale sám ze své zkušenosti musím potvrdit, že nejspíš tady někde je ten problém. Jak se říká, starého psa novým kouskům nenaučíš a ačkoliv tohle téma z jednoho úhlu pohledu jakoby neříká nic nového, z druhého úhlu se jedná o „novou školu“, která (zřejmě po právu) bude pro řadu z těch starších (nemyšleno věkěm) hůř pochopitelná. Ale je to škoda, přeci nebudeme čekat, až přijdou ty mladší, že jo? Proto můžu slíbit, že o těchto metodách na Zdrojáku rozhodne neslyšíme naposled. Je vidět, že jsou potřeba jako sůl.

Hoween

Mete, čekal bych od tebe trochu profesionálnější (a tedy konzervativnější) pohled na věc, kterého jsi díky svým zkušenostem schopen. Ale že ti Zdroják až takhle vleze na mozek, že budeš kopat za všechny losery a postavíš se proti těm, kteří články na tvém serveru nepovažují za mantru, to je pro mě docela zklamání.

Problém se opravdu týká nové a staré školy, ale úplně jinak, než tady prezentuješ. Aktuální stav je, že zespodu se derou mladí a agresivní rádobyguru s drsnými přezdívkami typu Chamurappi a Zahoň (nebo Záhon?), kterým chybí jakýkoli kontakt s praxí a realitou. A seshora se na ně dívají ostřílení profíci, kteří se smějí těm mladým a dravým, jak si nenechají poradit a neustále si rozbíjejí hubu na těch samých problémech. Čím větší projekt, tím větší míra konzervatismu je potřeba a jim to nedochází. Je krásné, jak jsou tady předkládány články o rádobymoderních metodách vývoje. Ale tyto metody jsou v řadě případů cucány prstu lidmi, kteří nemají kontakt s realitou a přebírány těmi samými, nezkušenými lidmi. Jsem si jistý, že až guru Zahoň přijde do firmy o víc jak dvou lidech a dostane se k projektu o rozsahu větším, než pitomý web o pár stránkách, tak mu to celé dojde. Tedy doufám.

Martin Hassman

Má zkušenost, kterou mám při setkávání s vývojáři (a tu musím pěstovat, jinak by celý tenhle magazín ani nemohl existovat), je zcela jiná. V žádném případě nemohu potvrdit, že by se zde jednalo o konflikt zkušených vs. méně zkušených, to je omyl. Dokonce i ti, které pouvažuji v této republice za jedny z nejzkušenějších, často dávají podobným tématům, např. tomu zmíněném v tomhle článku, zapravdu. Což je i jeden z důvodů, proč se tohle a podobná témata na Zdrojáku objevují. Prostě jsou potřeba, jejich několikaletá absence se na české komunitě vývojářů podepsala a snažím se to dohnat. Pokud se to podaří alespoň u menšiny vývojářů, bude to úspěch.

Karell

Vidim to podobne. Klidne bych tu zakonitost i otocil – to ze je clovek otevren novym myslenkam je dulezity predpoklad k tomu, aby se z nej stal zkuseny profesional. Sam jsem si prosel obdobim, kdy jsem mel pocit, ze mam vsechno na haku a nic noveho uz neprijde. Nastesti jsem se z toho dostal :-)

Takze se pripojuju k podpore techto temat na zdrojaku.

Martin Hassman

Pokud byste se chtěl k podpoře připojit i aktivní formou, budu moc rád, pokud mě kontaktujete na mém redakčním mailu http://zdrojak.root.cz/autori/martin-hassman/

Chamurappi

Aktuální stav je, že zespodu se derou mladí a agresivní rádobyguru s drsnými přezdívkami typu Chamurappi a Zahoň (nebo Záhon?), kterým chybí jakýkoli kontakt s praxí a realitou.
Já se někam deru? Poslední rok usilovně stagnuji ve své bezkontaktní teoretické realitě, nemám čas na agresivní draní.

A seshora se na ně dívají ostřílení profíci, kteří se smějí těm mladým a dravým, jak si nenechají poradit a neustále si rozbíjejí hubu na těch samých problémech.
Když už zmiňuješ konkrétně mé jméno — kdo se mi směje? Na jakých problémech si rozbíjím hubu?

Asi jsem nepochopil pointu tvého proslovu.

Hoween

Pravda. Poslední dobou o vás, zaplať pánbůh, slyšet není. Ale se slzou v oku vzpomínám na doby, kdy jste řval na každého, kdo jen zmínil cokoli o standardech, jak je omezené hovado a že W3C je zbytečná a omezující organizace ;-)

Hoween

Na druhou stranu v pripade degradace se nelze vyhnout pripadum, kdy se az dodatecne po spusteni aplikace zjistuje, kde vsude je jeste potreba degradovat – a to rychle a zbesile. To ma samozrejme neblahy vliv na kvalitu kodu.

Čímž se ale dostáváme někam úplně jinam, a sice k naprostému nedostatku zkušeností všech těch, kteří se tímhle ohánějí. Pokud se kodér dostane do situace, kdy musí bez hlubšího rozmyslu něco narychlo opravovat, pak je chyba hned na začátku vývoje, kdy s tím prostě někdo nepočítal. A je jedno, jestli s tím nepočítal analytik, nebo kodér.

Jen me zneklidnuje, ze podobne nazory slycham od lidi, kteri ustrnuli nekde pred 20 lety, kdy dosahli dokonalosti a vse co se stalo potom uz pro ne bylo zbytecne. To si ale musite vyrikat hlavne sam se sebou.

Upřímně řečeno, víte kulové o mé praxi a znalostech, tak si podobné ortely laskavě nechte mezi své kamarádíčky, kteří vám je budou tolerovat.

Karell

> kdy s tím prostě někdo nepočítal
A jsme u toho, takhle se premyslelo nekdy pred 10 lety. Predstava byla, ze analytik navrhne aplikaci tak dokonale, ze bude pocitat uplne se vsim co muze nastat a vsechno pujde elegantne opravit. Casem se samozrejme doslo k tomu, ze tohle je utopie a ze se proste na vsechno pamatovat neda (nebo je to neumerne drahe/pomale…). Navic i pri sebelepsim navrhu je jen otazka casu, kdy se narazi na problemy, protoze se s necim nepocitalo. Ovsem prvni nezbytny krok je ten, ze si jeden prizna, ze tohle se proste deje. Ze lidi nejsou neomylni a perfektni a uz vubec sebou nenosi orakulum. Ze chyby se proste deji – samozrejme i na zacatku vyvoje. Pak prijde dalsi krok a sice zamyslet se jak se s tim vyporadat – a myslim ze i o tom, je tento clanek.

Kdysi jsem cetl rozhovor s kymsi a padla tam zajimava myslenka, ze cesi jsou posedli jistym druhem perfekcionismu. Kdyz neco delaji, tak to musi byt hned napoprve dokonale a pokud neni, tak jsou z toho spatni. Docela mi to tenkrat otevrelo oci…

> víte kulové o mé praxi a znalostech
ano, nezbyva mi nez si delat obrazek z tehle a podobnych diskuzi :-|

Martin Hassman

cesi jsou posedli jistym druhem perfekcionismu

Dodal bych, že jim také často obecně nevoní, když mají dnes dělat něco jinak, než jak se to dělalo několik let a brání se změně zuby nehty bez ohledu na to, že jim to může něco přinést.

Karell

Na jednu stranu mam desive zkusenosti s tim, jak tezko se nekdy prosazuji jine postupy i kdyz resi aktualni problemy. Ale docela funguje pristup z opacneho konce – zanadavat si, rict co je spatne a kdyz se lidem da moznost to zlepsit, tak casto prijdou s dobrym resenim sami i kdyz to znamena zmenu. Jen je nutne si zvyknout, ze veci se proste meni.

Hoween

Zkuste si aspoň na vteřinu připustit, že někdo má prostě jiný názor, než autor článku. A zatímco většina se zmůže maximálně na onanování jak je ten článek strašně mega super, tak jsou lidé, kteří mají jiný názor a nebojí se to říct a obhájit si ho. Uvidíte, že pak se vám bude diskutovat mnohem lépe.

Karell

> jiný názor a nebojí se to říct a obhájit si ho
To mi tady prave chybi. Zatim jste rekl, ze je to tema kravina a podeprel to tvrzenim, ktere ukazovalo, ze jste tu metodu nepochopil. Dale jste uvedl neco v tom smyslu, ze vyvoj musi byt od zacatku bez chyb a navrh musi pocitat snad uplne se vsim, coz je prani z rise fantazie.

Hoween

navrh musi pocitat snad uplne se vsim, coz je prani z rise fantazie

Ano, musí. Že si nejste schopný udělat kompletní analýzu sám, nebo máte k dispozici neschopné analytiky, to už je problém vás, a bohužel i vašich zákazníků.

Brbla

>> Jak rikal jeden ucitel na MFF:
>U pisoárů stojí strojař a matfyzák. Strojař zapne kalhoty a odchází. Matfyzák udiveně >říká: nás ve škole naučili mýt si ruce. Strojař mu odvětí: nás naučili si je nepoch*at.
Za nimi odchází biolog, který si ruce omyje až venku. Ono totiž na kliku ke dveřím zevnitř, po použití WC, sahají krom strojařů i matfyzáci…

N

ooo, diky Ti! uz jsem si pripadal, ze jenom ja nerozumim o cem ten clanek je, ze zacinam uz asi byt stary :). Pro me je web na strane klienta informace ulozena v HTML (model), ktere mohu dodat vselijaky vzhled pomoci nejakeho stylopisu – CSS (view) a pripadne vylepsovat funkcnost dynamicky na zaklade udalosti od klienta look&feel pomoci Javascript (controller).

Uzivateli dodavam zejmena HTML, vse ostatni je jen vylepseni vzhledu a funkcnosti na strane klienta. Takhle to dalem jiz 10let. Neni ten vtip na obrazku trosku mimo, nebo jsem jenom ja jiz pred 10lety zacal delat weby timto zpusobem, ktery dnesni moderni developeri shledavaji rozumnym? Je pravda ze pred 10ti lety delat weby jako striktni HTML bez tabulek, vzhled pomoci CSS nebylo zrovna v mode :).

Anonymní
4. 3. 2009 14:24 smazal Martin Hassman, důvod: Spam.
karf

Ještě existuje crossover metoda "progressive degradation" :) Pěkným příkladem by mohl být právě odkaz pro tisk: nevím, který nešťastník to začal používat, ale spustil tím začarovaný kruh – uživatelé si zvykli, že je na webech odkaz pro tisk -> pokud ho tam nenajdou, domnívají se, že stránku nelze vytisknout. Kdyby se odkaz pro tisk nezačal v hojné míře používat, uživatelé by byli nuceni se naučit tisknout normálně z menu prohlížeče. Stejně úplně nevěřím tomu, že to uživatelé neumí. Původ tisku přes odkaz pochází z pre-CSS dob, kdy se připravovaly speciální tiskové stránky. Místo aby to s příchodem CSS zaniklo, tak se to nějak zvrtlo a dneska se v těle používají i odkazy na zvětšování písma, zavření okna atd. Jen se tím podporují špatné návyky uživatelů, a pak si stěžujeme, že neumí ovládat základní funkce prohlížeče.

wind0z3_sux
4. 3. 2009 15:57 smazal Martin Hassman, důvod: Trapný pokus o vtip.
MicMic

Děkuji za výborný článek!

Roman

Ten javascript by měl být ještě zakomentován pro případ, že prohlížeč nezná element script. Sice asi dnes zbytečné, ale pro úplnost..

hotovson

"Osobně často používám Blackberry, když na notebooku nemohu chytit WiFi, a opravdu mě vytáčí, když mi webová stránka řekne, že potřebuje povolený JavaScript a měl bych si jej zapnout. Nemůžu a přesto rozhodně jsem právoplatný uživatel té webové stránky – zvláštně pokud platím spoustu peněz za GPRS nebo EDGE za přístup."
stale marne premyslim, jak vam pristup k internetu, placeny telekomunikacnimu operatorovi, dava nebo posiluje prava na pristup k obsahu libovolne stranky…

bauglir

1/ pro Howeena: zvláštní, že zatímco ostatní masturbují nad hovadinami Vy se oháníte tím, že máte názor, co třeba ale tak, že článkem byl vyjádrěn názor a nějaké ustálené názvosloví a Vám teče cosi po stehně při popisu Vaší výjimečnosti a dokonalosti.

Věřím, že děláte programy s naprosto dokonalou a neprustřelnou analýzou. Jeden jediný uživatel Vaší kalkulačky to určitě ocení, ale pokud byste dělal programy na úrovní Office, nebo projekty, které během 7 let používají stovky tisic klientů, tak se Vám to nemůže podařit. Bude stačit 1 důvod: klienti vždy chtějí něco nového.

2/ A teď, kdy se toto rozdělení PE vs. GD vyplatí. Docela mi to chybí v článku, aby byli přistupy jasně rozdělené. Browser už dávno není jenom prohlížeč webových stránek (v původním zaměření), ale také aplikační GUI platforma. Pokud dělám aplikaci, budu vycházet z GD principu. Prostě se jedná o aplikaci, která vyžaduje určitou funkčnost a mohu poskytnout i nějakou osekanou, bude-li potřeba. Aplikace prostě mají nějaké požadavky na systém, na kterém jsou spouštěny. Příkladem mohou být různe mapy, emailoví klienti, apod. Naopak, pokud budu dělat klasické prezenční stránky (Ahoj, jmenuju se Broňa), měl bych vycházet z PE, kdy by mělo jít o maximální přístupnost ve všech browserech, netradiční funcionalita (z pohledu www) je tam spíše feature.

Broňa

Taurus

Myslím, že by bylo přehlednější primárně hovořit o "přístupnosti" webové stránky, jako o její vlastnosti (podle Špinara: "Přístupné stránky tedy nestaví svým uživatelům žádné překážky, které by jim znemožnily daný web efektivně používat.", tedy není omezeno jen na hendikepované uživatele, týká se i použitých technických prostředků).
Potom lze graceful degradation a progressive enhancement považovat za dvě metody, kterými je tato přístupnost dodahována, jedna odshora-dolů (optimistická), druhá odspoda-nahoru (pesimistická).

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.