Webrichtlijn 2: Gelaagd bouwen (R-pd.1.2)
Deze week de tweede richtlijn: Bouw websites volgens het principe van gelaagd bouwen. (R-pd.1.2)
Probeer jij altijd rekening te houden met Progressive Enhancement en/of Graceful Degradation? Vind jij dat er een verschil is tussen die twee? Spelen budgetten en deadlines een rol bij je beslissingen? Wanneer vind jij iets wat opgeleverd is eigenlijk onacceptabel? In hoeverre test je de verschillende lagen die je maakt?
Reacties
- 1 Sander op 08-01-2008 om 00:46 uur:
- Hoewel de twee genoemde manieren van bouwen natuurlijk tegenovergestelde uitgangspunten hebben komen ze in de praktijk denk ik vaak op hetzelfde neer. Want hoewel je wellicht netjes met de basislaag begint om daar vervolgens extra features aan toe te voegen (ProgEnh) weet je toch al dat het de klant/vormgever/projectmanager om de uiteindelijke, gepimpte versie gaat. En dus is die gepimpte versie feitelijk zoals de site bedoeld was en vormt de basislaag enkel een alternatief voor oudere browsers en andere 'beperkte' user agents (GrDegr).
Ik probeer me zelf wel altijd aan het principe van gelaagd bouwen te houden. En gezien het bouwtraject binnen het bedrijf waar ik werk slaat de term Graceful Degradation misschien het beste op mijn werkwijze. Ik moet er immers voor zorgen dat die flitsende interface waar de klant haar goedkeuring reeds aan heeft gegeven ook toegankelijk is als bv. JavaScript of Flash niet ondersteund worden. - 2 Michel Vos op 08-01-2008 om 09:16 uur:
- Persoonlijk probeer ik ten alle tijden Proggressive Enhancement toe te passen.
Echter tegenwoordig met een diversiteit aan JSlibs die allerlei fancy dingen kunnen (zoals drag and drop) ontwikkelen we soms features die het onmogelijk zullen kunnen doen als JavaScript bijvoorbeeld uit staat.
Gracefull Degredation is uiteraard in concept een mooi principe, maar ik persoonlijk vind dat je op een gegeven moment een streep door bepaalde browsers en user agents moet zetten. Zo houden we nog rekening met IE 5, maar veel lager niet meer. (Mits expliciet anders aangegeven door de klant uiteraard ;) ).
Reden hiervoor sluit ook mooi aan bij de hierboven gestelde vraag aangaande budgetten etc. Het kost simpelweg teveel effort om zaken die in recentere browsers perfect werken goed in lagere versies aan de praat te krijgen. Je zou dan in sommige gevallen onnodig functionaliteit opofferen om maar zo compatibel mogelijk te zijn. - 3 Marcel op 08-01-2008 om 09:37 uur:
- De doelgroep is key lijkt me, in de meeste gevallen zal je voor gebruikersvriendelijkheid kiezen om een grotere markt aan te spreken. Toegankelijkheid is dan niet het doel, maar een middel.
Als je weet dat de doelgroep bestaat uit, bijvoorbeeld, ouderen en/of slechtzienden, kan je de focus leggen op toegankelijkheid. En dan is daar ook het budget wel voor los te peuteren. - 4 Sander v L op 08-01-2008 om 10:30 uur:
- De interessantste uitdaging bij deze richtlijn vind ik aan de server-kant zitten (mag dat, bij deze vereniging?) ;)
Denk bijvoorbeeld aan een standaard applicatie waarbij je een form verstuurd, en dan met ajax dingen iets mooier of vlotter laat lopen (dus wat Jeremy Keith "hijax" noemt) - client-side is het makkelijk genoeg om progressive enhancement op te zetten, want je bouwt iets bovenop de basis functionaliteit van de form; maar aan de serverkant moet je code zo gestructureerd zijn dat deze de input van zowel de form als van de ajax POST goed behandelt, en het juiste resultaat voor elk terug geeft; zonder dat je gigantische duplicatie van logica in je code krijgt. (En denk dan aan extra complexiteit die je aan elk mee kan geven d.m.v. client-side dynamisch gegenereerde form-velden (die, als JavaScript volledig uit staat, ook door de server gegenereerd moeten worden), CSRF beveiliging, mutexen om bij meerdere ajax-streams elkaar te kunnen uitsluiten, e.a.)
Ik ben het niet met de andere Sander (ben jij Sander A, of nog een derde?) eens dat het uiteindelijk om de "gepimpte" versie gaat, en dat progressive enhancement en graceful degradation dus in de praktijk op hetzelfde neerkomen. (Als ze volledig goed gedaan worden, dan voor de gebruiker wel; maar nooit voor de ontwikkelaar - er zit een volledig andere denkwijze achter, die maar al te vaak echt andere consequenties heeft.)
Denk aan, heel simpel, de mogelijkheid om 'gepimpte' links in een nieuwe tab te openen. Als je begint met de link als link, dan denk je bij het opzetten van de hele structuur van de website eraan dat dit kan gebeuren. Maar als je begint met een onclick functie die allerlei mooie dingen gaat doen, dan loop je heel erg snel tegen het probleem aan dat je geen structuur hebt opgezet om deze zelfde dingen te laten gebeuren in het scenario van de nieuwe tab.
Over budget: Net als je geen apart budget zou moeten hoeven los te peuteren voor een CSS layout i.p.v. een tabel-layout, zou je dit ook voor toegankelijkheid niet moeten hoeven te doen. Het is aan ons om deze principes zozeer in onze werkwijze te hebben verweven dat dit ook de realiteit wordt.
(Ik moet eerlijk toegeven dat dit ook voor mij nog enigszins toekomstmuziek is; mijn werkwijze begint zeker steeds meer met de basis elementen die later progressively enhanced worden, maar in het eind-traject is het toch altijd de gepimpte versie die af is, en zijn het de edge-cases van de pure forms die ik tussendoor nog even moet af-checken. Maar, ik blijf steeds dichter in de buurt komen...) - 5 Sander A op 08-01-2008 om 14:41 uur:
- @Sander v L:
Ofwel ik begrijp jou verkeerd ofwel jij hebt mij verkeerd begrepen. In je laatste alinea geef je namelijk al aan dat het wel in eerste instantie toch om de gepimpte versie gaat. Misschien niet zozeer voor front-end developers (alhoewel?), maar vooral voor de klant, vormgever, werkgevers en vrijwel alle andere betrokkenen. Vanuit de wensen van die klant en de aangeleverde vormgeving gezien ga ik te werk volgens graceful degradation (ik krijg geen ontwerp voor de kale basis, maar alleen voor de gepimpte versie). Maar om het voor mezelf, zoals je al aangeeft, niet al te moeilijk te maken bouw ik de code op volgens progressive enhancement. - 6 Sander v L op 08-01-2008 om 15:15 uur:
- Hopen dat dit dingen verduidelijkt: Ik ben het niet met je eens, in dat het (voor de eindgebruiker (de belangrijkste persoon in het hele proces, ook al hebben deze geen inspraak), en voor ons als ontwikkelaars) niet alleen om de gepimpte versie gaat. De basislaag is niet alleen voor oude browsers: een link blijft middle-click-baar (en de enige toegang voor Googlebot); en dit gaat te makkelijk fout (mist functionaliteit, kost veel extra werk) als je graceful degradation doet i.p.v. progressive enhancement.
Maar, ja, voor de directe klant/opdrachtgever (die bijna nooit een normale gebruiker van de website is) is vaak puur de "gepimpte versie" belangrijk (omdat de kennis van / overzicht over alle factoren ontbreekt; hier op letten is tenslotte ons werk), en als je dan tegen de deadline / het eind van het budget aan zit, dan komt het nog te vaak voor dat je je inderdaad alleen richt op de oppervlakte, en dat de toegankelijke versie dus edge-cases aan functionaliteit mist; net zoals een ontwikkelaar die oorspronkelijk uit de tabel-layout wereld kwam en voor wie semantisch werken nog niet volledig natuurlijk komt, rond de deadline een layout probleem op een niet-semantische manier zou oplossen.
Hier is training voor onszelf nodig, om progressive enhancement zo natuurlijk te laten zijn dat we niet meer zouden weten hoe we die gemakkelijke/verkeerde uitweg zouden moeten nemen. - 7 Arjan op 08-01-2008 om 23:31 uur:
- Vaak zie je dat dit soort dingen net niet consequent doorgevoerd worden. Het is echt een richtlijn waar je wat voor moet doen om het toegankelijk te maken. Dit zal gelukkig in de komende jaren veranderen. Eerst gewenning/ervaring van de ontwikkelaar, en uiteraard ook als IE6 langzamerhand op de achtergrond raakt.
Progressive Enhancement en Graceful Degradation verschillen wel, maar zoals hier eerder aangegeven bouw je vaak vanuit het Progressive Enhancement idee. Zeker als er verschillende partijen zijn voor front-end en back-end.
Blijkt maar weer hoe goed je dit af moet stemmen intern. Daarna maakt een budget denk ik niet meer uit voor deze richtlijn, en ligt een goede kans voor Fronteers (die al ingezien wordt vanaf het begin, meeting bij Lost Boys).
Onacceptabel is het als je iets alleen voor IE aflevert, dat kan zeer zeker niet meer anno nu. Als je een beetje gevoel hebt voor JavaScript maak je jezelf al snel gelaagd bouwen eigen, door o.a. gebruik te maken van DOM Scripting. Goed boek hierover vind ik DOM Scripting van Jeremy Keith, zeker als je al een beetje van JavaScript en CSS af weet.
Ooit heb ik een goed idee gehad voor een Firefox extensie voor het bulletproof maken van je website/applicatie. In een paar stappen automatisch afbeeldingen uit, CSS uit, JavaScript uit, default stylesheets veranderen et cetera. (En ook combinaties.) Nooit van gekomen, maar als iemand zich verveeld mag hij het van mij maken! De webdeveloper toolbar kan het wel, maar is toch veel tijd kwijt. Naarmate je het vaker toepast voel je gelukkig aan wat wel en niet kan. - 8 Sander op 09-01-2008 om 03:00 uur:
- @Sander v L
Jammer dat je het niet met me eens bent, ik ben het namelijk volgens mij wel met jou eens ;-) Volgens mij zitten we echter gewoon een beetje langs elkaar heen te lullen.
@Arjan
Dat 'aanvoelen' gaat inderdaad wel steeds beter, maar daar van uitgaan kan ook erg verraderlijk zijn.
De functionaliteit die je beschrijft, en dan met name de combinatie, zou inderdaad een welkome uitbreiding van de front-end developers tools zijn.
Weet iemand hier trouwens een goed JavaScript om te checken of CSS ondersteund wordt? Dus wel/geen standaard ondersteuning, wel/niet disabled, stylesheets wel/niet gevonden, etc. Het feit dat browsers verschillende manieren hanteren om vanuit JS met stylesheets om te gaan en dat wanneer CSS gedisabled is veelal toch de standaard stylesheets van de browser zelf enabled blijven maken het moeilijk om een goede check te schrijven, dat vind ik althans. - 9 Ernst de Haan op 09-01-2008 om 16:59 uur:
- Ik probeer het principe van gelaagd bouwen ook structureel toe te passen. Doel is de sites te laten werken in alle moderne browsers (IE6/7, WebKit, Gecko, KHTML, Opera) met of zonder JavaScript, met of zonder CSS. Ik test de site ook nog af en toe met Lynx en ook dat gaat goed.
Voor een groot deel van de funtionaliteit gaat dat aardig goed. Ik ben echter een aantal hobbels tegengekomen, bijvoorbeeld:
#1 - Het stylen van form submit buttons middels CSS werkt niet goed cross-browser. Dus ik vervang de form submit buttons middels JavaScript door gestylede links. Om te voorkomen dat dit 'flitst' in de browser voer ik in de HEAD-sectie eerst een stukje JavaScript uit dat de buttons eerst even onzichtbaar maakt.
Zie: http://www.enviricompensioenfonds.com/ - met name de Mac Aqua-stijl buttons.
#2 - Een formulier zoals http://www.enviricompensioenfonds.com/regeling/formulieren/waardeoverdracht/ ziet er goed uit met JavaScript ingeschakeld. Wanneer je een veldje aanklikt krijg je context-sensitive help (kader rechts) en je hoeft niet te scrollen (tenzij je op 800x600 of kleiner werkt).
In Lynx werkt dit goed, dan mis je echter de context-sensitive help functie, maar je krijgt de toelichtingen dan gewoon bij de velden te zien.
Echter, met JavaScript uitgeschakeld in een normale visuele user agent heb ik nu echter een nog slechter resultaat: helemaal geen toelichting bij de velden.
Een mogelijke oplossing zou het tonen van de toelichtingen boven de velden zijn (net als in Lynx), maar dan is het hele ontwerp sterk ontkracht... - 10 Ernst de Haan op 09-01-2008 om 17:07 uur:
- Om dit principe goed te hanteren moet je wel allerlei verschillende technieken creatief combineren, anders laat je steken vallen, dat lijkt me duidelijk.
Dit principe doet al snel af aan de consistentie van het uiterlijk van de site. Voor de homepage van genoemde site geldt bijvoorbeeld dat wanneer Flash of JavaScript uitgeschakeld zijn de avatar rechtsboven niet getoond wordt, maar in plaats daarvan een stukje tekst. Vraag is of dat acceptabel is vanuit het oogpunt van vormgeving.
De richtlijnen zijn derhalve nooit rigide door te voeren, mijns inziens. Ze liggen niet compleet zwart-wit en het is altijd een afweging tussen verschillende aspecten, waarbij ook geld, tijd, vormgeving en consistentie een belangrijke rol spelen.
Dat laat wat mij betreft echter overeind dat ik de Webrichtlijnen zeer nuttig vind en ik zou bij duidelijke afwijkingen van deze richtlijnen wel altijd een verklaring willen zien. - 11 Egor Kloos op 11-01-2008 om 02:04 uur:
- Progressive Enhancement kost geld, punt. Hoeveel geld ligt uiteraard aan de schaal van de opdracht.
Zelden kom ik een klant tegen die bereid is om geld op te hoesten voor meerdere versie van hetzelfde inhoud. Dus ben ik voorzichtig hoe ik mijn progressive enhancement verhaal breng. MKB klanten kunnen vaak de extra kosten niet opbrengen en de grote klanten moeten met extra politieke wil interne budget vrijmaken. Mijn ervaring is om dergelijk kosten in een vroeg stadium mee te nemen.
Content editors moeten namelijk voor een enkele artikel meerdere varianten schrijven (ook; omschrijving wat in Google resultaten past, introductie teksten enz) naast dat ook alle alt teksten, title attributen en eventuele flash teksten. Goede content editors zijn moeilijk te vinden en dus moet je vaak met onervaren redactie teams werken en deze persoonlijk de voordelen van deze aanpak uitleggen voordat zij intern gaan klagen. Dus al met al mijn uren voor het bouwen en testen plus uren voor het uitleggen en verdedigen maakt het duurder. De operationele kosten zijn ook hoger omdat een ieder content item ook meer tijd nodig heeft voor de feitelijke invoer en controle.
Je kunt dus niet tegen de klant zeggen dat progressive enhancement weinig kost want het kost wel degelijk iets en soms is iets al te veel. - 12 Koen Willems op 11-01-2008 om 20:24 uur:
- Dat het principe, zoals Ernst stelt, al snel afdoet aan de consistentie van het uiterlijk van de site, is denk ik niet relevant en vormt naar mijn mening beslist geen argument om het principe niet toe te passen.
Het gaat er immers om dezelfde informatie onder alle omstandigheden toegankelijk te maken. Voorbeeld: als je CSS in je browser disabled zal er weinig van het design overblijven; desondanks zou de content toegankelijk moeten blijven. Het is helemaal niet bezwaarlijk als bijvoorbeeld de desktop-versie van je site er anders uit ziet of anders functioneert dan de mobiele versie (sterker nog: in de praktijk is dat vaak gewenst).
Mij ontgaat verder waarom toepassing van progressive enhancement extra geld zou kosten. Ik kan me dat nog voorstellen in het geval van een webbouwer die het principe voor het eerst toepast, maar in de grond van de zaak hebben we het hier over een techniek die een webbouwer anno 2008 zou moeten beheersen.
Ook het voorbeeld dat webredacteuren meerdere varianten zouden moeten schrijven vat ik niet; dat is beslist reden om eens ernstig met een CMS-leverancier te gaan praten. - 13 Raph de Rooij op 14-01-2008 om 13:45 uur:
- De eerste ideevorming rondom 'gelaagd bouwen' stamt bij mij van januari 2003, inmiddels precies vijf jaar geleden. Naar aanleiding van een discussie in een nieuwsgroep (NIWO; nog bekend bij de Fronteers?) is destijds het artikel geschreven dat nog beschikbaar is op http://raph.nl/deprecated/select/
Mijn conclusie van destijds was dat er aan progressive enhancement minder nadelen kleven dan aan graceful degradation. Laatstgenoemde techniek heeft doorgaans als belangrijk nadeel dat de complexiteit van de webinterface erdoor toeneemt (meer code, redundantie van content of code, server-side fall-back nodig), terwijl die door progressive enhancement juist afneemt (semantisch correcte code, scheiding van content en functie, minder overhead).
Volgens mij staat die conclusie nog steeds overeind.
Overigens noemde ik het in het artikel geen progressive enhancement, maar graceful transformation. Volgens Wikpedia is de term progressive enhancement pas geïntroduceerd in maart 2003; zie http://en.wikipedia.org/wiki/Progressive_enhancement
De exercitie in bovengenoemd artikel heeft trouwens een denkproces op gang gezet dat uiteindelijk heeft geleid tot de Webrichtlijnen. R-pd.1.2 is een van de richtlijnen die daaruit is voortgekomen...
Zo, da's wel weer genoeg 'opa vertelt' voor vandaag ;-) - 14 Kristiaan Thivessen op 15-01-2008 om 10:17 uur:
- @Raph
Als de dag van gisteren!! :) - 15 Gerrit Berkouwer op 15-01-2008 om 22:55 uur:
- Nou vooruit: NIWO, wie komt er nog? Dat waren nog eens discussies :-). Ben het met je eens Raph, voor mij is het voordeel van 'PE' een solide basis waar je uiteindelijk het meeste mee kan.