IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Comprendre l'amélioration progressive

Cet article est la traduction de Understanding Progressive Enhancement disponible ici.

Translated with the permission of A List Apart Magazine and the author.

Retrouvez toutes les traductions disponibles de A List Apart Magazine sur alistapart.developpez.com.

Commentez : 4 commentaires

Depuis 1994, la communauté du développement web a battu le tambour de la dégradation élégante. Transposition du monde de l'ingénierie, le concept était, à sa base, de réserver un repas complet aux navigateurs les plus récents et les plus performants tout en laissant quelques restes aux tristes sires assez malchanceux pour utiliser Netscape 4. Cela a fonctionné, bien sûr, mais ça ne correspondait pas vraiment à la vision originelle de Tim Berners-Lee d'un web universellement accessible.

Une dizaine d'années plus tard, des personnes intelligentes se sont interrogées sur la dégradation élégante et l'ont trouvée insuffisante à de nombreux niveaux. Préoccupées par la disponibilité du contenu, l'accessibilité globale et les capacités des navigateurs mobiles, elles ont cherché une nouvelle méthode d'approche du développement web - une méthode qui se concentre sur le contenu et ne se contente pas de faire semblant avec les anciens outils.

Au SXSW en 2003, Steve Champeon et Nick Finck ont présenté une conférence intitulée "Conception Web Inclusive pour le Futur". Ils ont alors dévoilé un modèle pour cette nouvelle méthode d'approche du développement web. Steve lui a aussi donné un nom : l'amélioration progressive.

Article lu   fois.

Les deux auteurs

Site personnel

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

Il y a une (subtile) différence

Au cas où vous vous creuseriez la tête en essayant de trouver en quoi la dégradation élégante et l'amélioration progressive diffèrent, je vous dirais ceci : c'est une question de perspective. La dégradation élégante et l'amélioration progressive considèrent toutes deux le fonctionnement d'un site dans de nombreux navigateurs, sur de nombreux systèmes. La clé est leur point d'intérêt et la façon dont il affecte l'organisation du développement.

La perspective de la dégradation élégante

La dégradation élégante se concentre sur la création de sites web pour les navigateurs les plus avancés / évolués. Tester sur des navigateurs considérés "plus anciens" ou moins évolués est généralement fait dans le dernier quart du cycle de développement et est souvent restreint à la précédente version des principaux navigateurs (IE, Mozilla, etc.).

Dans le cadre de ce paradigme, le résultat donné par les navigateurs plus anciens est censé être pauvre, mais suffisant. De petites corrections peuvent être faites pour s'adapter à un navigateur particulier. Comme ils ne sont pas le centre d'intérêt, peu d'attentions sont portées au-delà de la correction des erreurs les plus flagrantes.

La perspective de l'amélioration progressive

L'amélioration progressive se concentre sur le contenu. Notez la différence : je n'ai même pas mentionné les navigateurs.

A l'origine, nous créons des sites web pour leur contenu. Certains sites le propagent, d'autres le collectent, d'autres en demandent, d'autres en manipulent et même certains font tout ça, mais tous en ont besoin. C'est ce qui fait de l'amélioration progressive un paradigme plus approprié. C'est pourquoi Yahoo! l'a rapidement adopté et l'utilise pour créer sa stratégie de support noté des navigateurs.

Mais alors, comment ça marche ?

Se faire à la mentalité de l'amélioration progressive est assez simple : pensez simplement contenu. Le contenu constitue la base solide sur laquelle vous appliquez votre style et votre interactivité. Si vous êtes fan de bonbons, représentez-vous l'amélioration progressive comme une cacahuète M&M's :

Les couches de chocolat de l'amélioration progressive
Les couches de chocolat de l'amélioration progressive

Commencez avec votre cacahuète de contenu, balisée avec du (X)HTML riche et sémantique. Habillez ce contenu d'une couche de CSS riche et crémeux. Finalement, ajoutez du JavaScript en coque de sucre dur pour faire un bonbon merveilleusement savoureux (et éviter qu'il fonde dans vos mains).

Si vous êtes familiarisés avec le mantra du mouvement des standards Web - séparation, séparation, séparation - c'est parfaitement logique. Le développement basé sur les standards Web a souvent été comparé à un gâteau fourré (ou, si vous voulez vraiment frimer, un trifle).

Je préfère l'analogie à la cacahuète M&M's, parce qu'avec, les couches enrobent complètement le contenu, de la même façon que les styles et les scripts enveloppent notre contenu.

Si vous suivez mon analogie culinaire un peu plus longtemps (j'espère que je ne vous donne pas faim), je vous expliquerai pourquoi cette approche est meilleure et comment les couches communiquent dans ce paradigme.

La cacahuète

Certaines personnes aiment les cacahuètes ; en fait, certaines personnes préfèrent les cacahuètes aux M&M's. De la même façon, certains (et des éléments comme les moteurs de recherche) veulent uniquement le contenu.

Ensuite, il y a des personnes qui ne supportent pas le chocolat et les couches de sucre sur la cacahuète (les diabétiques, par exemple). Comme eux, certaines personnes sur des appareils mobiles ou de vieux navigateurs peuvent être incapables de voir vos belles présentations ou interagir avec vos astucieuses interfaces gérées par AJAX.

S'assurer que vos balises expriment le meilleur niveau de détail sur le contenu qu'elles entourent est essentiel pour offrir une expérience de base à ces utilisateurs.

L'enrobage de chocolat

Après, vous pouvez délicatement faire baigner votre contenu dans un bain chaud de CSS, mais avant de sauter sur la gangue de sucre dur, il y a certaines considérations supplémentaires.

Il y a des gens qui aiment que le chocolat recouvre les cacahuètes. Ces gens sont comme le tiers moyen des utilisateurs qui ont un certain niveau de support CSS, mais ne peuvent avoir de support décent pour JavaScript, ou ils peuvent travailler dans une entreprise où les gens de la sécurité IT sont plus qu'un peu phobiques envers JavaScript. Pour eux, JavaScript peut être complètement désactivé.

Qu'elles préfèrent le Goober [NdT : cacahuète enrobée de chocolat, mais sans couche de sucre], ou soient limitées au Goober, ces personnes méritent d'être accueillies. Il existe plusieurs techniques d'amélioration progressive permettant d'appliquer des styles à votre contenu et ce sera le sujet du deuxième article de cette série.

La coque de sucre dur

Pour finir, vous pouvez introduire JavaScript dans le mélange. Avec les riches possibilités d'interaction qu'il propose, ainsi que sa capacité à manipuler et interagir avec les couches de contenu et de présentation, JavaScript est réellement l'ingrédient qui peut pousser un site dans son ensemble vers une "expérience".

Je ne suis pas vraiment sûr de la façon dont la coque de sucre dur est ajoutée à un M&M's (je suppose qu'il s'agit d'un bain supplémentaire), mais ajouter des fonctionnalités et de l'interactivité basées sur JavaScript à vos sites web est un jeu d'enfant quand vous pensez à l'amélioration progressive. Et, de la même façon que les M&M's sont disponibles dans une variété de couleurs, l'expérience JavaScript peut varier en fonction des possibilités du navigateur ou du système qui essaie de l'utiliser.

Comme vous le savez certainement, ce type de développement est appelé JavaScript non-intrusif. Je traiterai ces techniques et pratiques dans le troisième et dernier article de cette série.

Tout rassembler

Développer avec l'amélioration progressive est en fait assez simple une fois que vous avez compris le concept et commencé à le mettre en pratique ; peut-être même plus simple que de faire du sucre. Les deux prochains articles de cette série vous aideront à aiguiser vos compétences en amélioration progressive avec CSS (1) et JavaScript (2) et vous montreront comment cette philosophie se traduit en code.

Remerciements

Tous mes remerciements à Diane Ménard, Alexandre T et Kerod pour leur relecture !

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   



Copyright © 2009 Aaron Gustafson. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.