1

J'ai lu à propos de ces deux différentes approches de conception, je comprends la différence théorique entre Prog.Enhancement et Graceful Degradation, mais je ne reçois pas l'exemple que vous pouvez lire à ce lien: Progressive enhancement and Graceful degradation exampleAmélioration progressive et exemple de dégradation gracieuse, je ne comprends pas

Avec GD il crée un lien qui par Javascript imprime la page. Avec P.E. fait la même chose, mais il utilise les "boutons" au lieu de "liens".

Ceci est le code utilisé avec P.E. processus:

<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> 

Ne pouvait-il faire la même chose continuer à utiliser des liens? Je veux dire que le problème du support Javascript subsiste même en P.E. et est résolu exactement comme dans G.D., en disant à l'utilisateur d'imprimer la page par lui-même.

Merci d'avance

Répondre

0

Non. Dans cet exemple, il n'y a pas de lien. Juste un <p>. Mettre dans un <a> normal signifierait que n'importe qui avec JS désactivé et n'importe qui dont le navigateur ne peut pas faire window.print() verra un lien qui ne fait rien ou aller n'importe où (et pourrait éventuellement lancer une boîte d'erreur si le navigateur est assez vieux) . L'interface utilisateur serait visiblement cassée. Pour améliorer la page d'une autre manière, l'auteur pourrait changer le <p> en un <a>, mais il a choisi d'aller avec un <input type="button">. Il y a beaucoup d'options. Mais le but de cet exemple est de commencer avec une interface utilisateur qui n'est pas cassée en aucune façon pour quiconque - y compris les utilisateurs qui ont désactivé JS et les navigateurs qui n'ont pas les fonctionnalités requises - et ensuite construire. C'est le point de PE. D'un autre côté, la méthode GD est de construire la page pour votre public principal et de trouver des moyens de cacher les choses qui se cassent, donc les navigateurs de moindre qualité obtiennent toujours quelque chose de gentil sans voir beaucoup de choses cassées partout.

Je sais que vous n'avez pas demandé, mais dans mon expérience personnelle, la distinction entre PE et GD est complètement artificielle et très 2009. Beaucoup de ceci avait à voir avec IE6 (un navigateur de 2001 qui ne mourrait pas), mais le mobile lui a donné une nouvelle urgence. À l'époque, le mobile était considéré par de nombreuses personnes comme un système distinct nécessitant un traitement spécial. Il s'agissait donc d'une question importante: construisez-vous pour le mobile et le bureau, puis ajoutez des fonctionnalités à votre audience principale? Ou construisez-vous le site pour votre public de base de bureau, puis réduit sur les choses qui pourraient casser sur le mobile.

+0

Merci beaucoup, vous avez très bien expliqué l'exemple :) Alors vous pensez que la distinction entre PE et GD est superflue de nos jours? Je le vois plutôt actuel et surtout applicable à tous les types de design et pas seulement à l'UX. Je travaille actuellement sur ma thèse de doctorat, je deviens fou en essayant d'expliquer la philosophie et les techniques de design et surtout UX Design, tout change si vite ... – Maxxd

+0

La distinction est toujours valable comme un moyen de décrire comment vous vous adaptez à disponibilité partielle des fonctionnalités. Vous pouvez injecter un bouton de géolocalisation (PE) ou en ajouter un par défaut et le garder caché pour les utilisateurs qui ne peuvent pas l'utiliser (GD). D'une certaine manière, vous pouvez considérer la mise en page réactive comme un point de rencontre parfait entre PE et GD - ajouter et supprimer, afficher et masquer, de manière dynamique en fonction des capacités de l'utilisateur. Et je pense que c'est pourquoi la distinction devient moins importante: nous avons tendance à penser maintenant à faire à la fois PE et GD en même temps pour les mêmes problèmes que nous construisons la page. – Andrew

0

L'amélioration progressive et la dégradation gracieuse peuvent souvent sembler similaires parce qu'elles le sont. Toutes les conceptions progressivement améliorées se dégraderont gracieusement, mais toutes les conceptions dégradant gracieusement ne seront pas progressivement améliorées. C'est une question de perspective. L'amélioration progressive, comme le dit Andrew, consiste à partir d'une expérience de base universellement utilisable et à améliorer cette expérience (avec HTML, CSS et JavaScript) comme vous le pouvez. Des personnes différentes ayant des besoins et des capacités différentes auront des expériences différentes - des expériences qui leur seront utiles et appropriées - et c'est bon. Une dégradation gracieuse, en revanche, vous permettrait de bloquer l'accès à un site car la personne n'utilise pas un navigateur sur lequel vous ne souhaitez pas effectuer de test, car vous ne lancez pas d'erreur, vous ne faites que les empêcher d'accéder au site. site (et recommandant probablement un navigateur différent que vous avez testé).

Les sites progressivement améliorés créent plus d'opportunités pour les utilisateurs d'utiliser vos produits et de lire votre contenu, car la philosophie reconnaît la variabilité inhérente et la fragilité du Web en tant que mécanisme de livraison.Les concepteurs/développeurs suivant une approche purement et simplement dégradante peuvent limiter leur audience de manière non intentionnelle et réduire la stabilité de leur site parce qu'ils ne tiennent pas compte de cette variabilité.

J'ai écrit longuement à propos de l'est dans mon livre Adaptive Web Design. La première édition est disponible gratuitement en ligne. La deuxième édition est sortie à la fin de l'année 2015.