Skip to content

tecg-dw/td-analyse-de-sites

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

24 Commits
 
 
 
 

Repository files navigation

Design Web TD - Analyse de site

Dans le cadre de votre cours de Design Web - TD, nous vous demandons d'analyser un site existant et de faire des propositions de refontes visant à remédier aux problèmes que vous aurez pointés.

L'objectif de votre travail est triple :

  • analyser l'utilisabilité du site en suivant la démarche décrite dans « Ergonomie web » de Amélie Boucher et en argumentant par rapport aux notions développées dans le livre. Cette analyse doit s'appuyer sur un test utilisateur par membre du groupe et être basée sur deux tâches pour chacun d'entre eux ;
  • analyser l'accessibilité du site. Cette analyse doit s'appuyer notamment sur l'examen du code, des audits et résultats de tests (que vous devez interpréter) réalisés avec des logiciels conçus pour (que nous vous avons renseignés au cours). Là, votre source de référence est le site de anysurfer ;
  • proposer une refonte partielle des pages impliquées par les tests utilisateur afin d'améliorer les problèmes que vos avez pointés.

Le point de départ de votre travail est de dégager les objectifs principaux du site et son public-cible, que vous allez caractériser (chapitre 4).

Vous en déduirez deux tâches (scénarios, à rédiger soigneusement, voir chapitre 11) que vous allez soumettre à plusieurs utilisateurs, que vous choisirez là aussi soigneusement comme étant représentatifs du public-cible (chapitre 11).

Ensuite, vous faites les tests utilisateur en filmant, enregistrant, chronométrant, consignant, n'intervenant pas (bref, out ce qu'il faut comme décrit dans le livre, chapitre 11).

Une fois les résultats collectés, vous présentez les mesures (qu'en est-il point de vue efficacité, efficience, satisfaction ?, etc.), vous analysez les résultats et vous les interprétez en les remettant dans le cadre théorique du livre (concrètement, vous donnez un nom aux problèmes relevés, vous essayez de les expliquer grâce aux notions présentées dans le bouquin, voir chapitre 11 mais aussi les chapitres 1, 2, 3, 5, ...). Vous pouvez bien entendu aussi mettre en avant les points positifs, le respect de bonnes pratiques s'il y en a.

En ce qui concerne les problèmes relevés, vous proposez des pistes de solution (votre source d'inspiration principale est là aussi bien entendu les principes exposés dans le livre, ça découle assez naturellement de votre analyse précédente) et vous les mettez en oeuvre dans une refonte partielle du site (uniquement les parties qui concernent les tâches que vous avez analysées).

En parallèle ou avant ou après, vous réalisez les tests d’accessibilité. Là aussi, vous aurez des mesures, que vous analysez et commentez, et vous tirez des conclusions en bon français, dans les termes de la théorie.

Imaginez que vous êtes devant un client (c'est nous :) ) que vous devez convaincre de payer pour une refonte de son site afin qu'il satisfasse aux critères d'accessibilité et d'utilisabilité.

Vous devez être objectifs et crédibles, c'est-à-dire partir des faits, veiller à avoir à chaque fois des preuves de ce que vous avancez (les jugements de valeur – pire des jugements à l'emporte-pièce non fondés – ne nous intéressent pas voire nous indisposent, abstenez-vous !), et interpréter ce que vous avez observé de manière intelligible en sorte que cela constitue des arguments susceptibles de le convaincre.

Consignes plus formelles et détaillées à respecter attentivement

  • Chaque groupe de travail identifiera deux tâches pertinentes afin de mener un test d'utilisabilité sur plusieurs utilisateurs (un utilisateur par membre du groupe). Une des deux tâches doit obligatoirement impliquer l'emploi d'un formulaire.

    Suivez bien les consignes et la méthodologie exposée dans votre livre pour mener le test utilisateur. Nous attirons notamment votre attention sur le fait que vos tâches doivent constituer des scénarios concrets, pertinents et significatifs par rapport aux objectifs du site (à dégager préalablement) et qu'elles doivent être notées sur papier et dictées de la même manière à tous vos utilisateurs. Vous devrez également nous les lire en classe. Nous vous rappelons également que toute intervention de votre part lors du déroulement du test invaliderait celui-ci. Rassurez vos sujets en leur expliquant que c'est pas eux ni leurs performances que vous allez évaluer mais bien celles du site, mais surtout, n'intervenez pas pour les aider ! Lors de votre présentation, vous devrez commenter les problèmes observés lors des tests à la lumière des concepts théoriques exposés dans le livre d'Amélie Boucher.

  • Parallèlement à cette évaluation de l'expérience utilisateur, une évaluation des problèmes d'accessibilité sera faite et des améliorations réalisées.

    Nous attirons votre attention sur le fait que la problématique de l'accessibilité est importante et que nous y accorderons une attention particulière. À toutes fins utiles, je vous rappelle notamment qu'il y a moyen dans FF de régler les paramètres de l'extension HTML Validator pour qu'il affiche les erreurs en fonction de certains niveaux d'accessibilité, et que nous vous avons également parlé au cours de l’initiative de la WAI (dont voici le site officiel) et du guide qu'il a produit en matière d'accessibilité, le WCAG.

    Toutes les ressources et références que vous devez utiliser ont été présentées lors de votre cours de Design Web Théorie du 1er Bachelier. Référez-vous notamment aux outils qui ont été exposés lors du cours, voyez également le rappel ci-dessous concernant le Quickscan.

  • Suite au test, vous réaliserez une refonte de l'interface destinée à améliorer l'expérience utilisateur relative aux tâches réalisées dans vos tests. Il ne s'agit pas de refondre toutes les pages du site mais uniquement de modifier ce qui peut être amélioré en fonction des données récoltées lors des tests et des analyses réalisées pour les séquences impliquées par les tâches de vos tests utilisateurs.

    La refonte doit être réalisée sur un logiciel de prototyping. Toutefois, vous devez être capables de savoir comment réaliser vos propositions en HTML/CSS/JS et l'expliquer à la classe dans les grandes lignes. Votre maquette doit également montrer tout état pertinent de l'interface (par ex., s'il s'agit d'un formulaire, non seulement le formulaire mais aussi des cas d'affichage de messages d'erreurs afin qu'on se rendre compte comment vous avez prévu des les gérer...).

Lors de la séance, vous viendrez avec tout rapport pertinent (capture d'écran, parties de vidéos de l'utilisateur (si possible avec du son), enregistrement sonore, relevé de notes, chronométrage, audits d'accessibilité…) ainsi qu'avec les refontes. Si vos tests utilisateur ne suffisent pas à illustrer vos propos, vous devrez réaliser une capture d'écran vidéo du site au cas où celui-ci changerait/serait hors ligne lors de la présentation.

Chaque groupe disposera de 40-50 minutes pour présenter son travail, suivi de 10-15 minutes de questions et feedbacks sur sa présentation, soit environ une heure par groupe.

Vous compilerez vos observations, slides, fichiers et ressources dans un dossier compressé à remettre selon les modalités précisées en classe.

Vous pouvez venir avec des refontes réalisées dans un esprit différent de celui du site original. Souvenez-vous à quoi vous vous destinez : on attend des refontes dignes d'un infographiste (et pas à ce que vous rendiez le site plus laid que l'original ! ... non mais vraiment, sans rire, faites attention s'il vous plaît, soignez cet aspect du travail.

Nous ne précisons pas un nombre de pages ou des pages particulières à analyser. Le nœud du problème, c'est l'expérience utilisateur, ce qui implique des « séquences de navigation » et donc diverses pages. C'est donc à vous de définir les « pages », étant entendu, et nous insistons, que les tâches à tester doivent être pertinentes vis à vis des objectifs du site et des attentes du public.

Vous répartissez le travail au sein des groupes de travail comme bon vous semble, tant que le jour du séminaire, il nous est possible de vérifier que tout le monde a participé à travers les échanges que nous aurons avec vous.

Cela implique notamment que, quelle que soit votre répartition des tâches et indépendamment de la partie sur laquelle vous vous êtes concentré, vous devez être capable chacun individuellement de répondre à toutes les questions que nous pourrions vous poser.

Je vous rappelle également que la lecture et l'utilisation des références (textes, livre, memento, sites de référence renseignés au cours) est indispensable et permet de dégager une compréhension et une sensibilité plus fines vis à vis de ce qui vous est demandé.

Le QuickScan d'AnySurfer, une ressource incontournable pour vos tests d'accessibilité

Le Quickscan est un instrument de mesure inspiré de la checklist d'anysurfer développé par AnySurfer en collaboration avec K-point, le centre de recherches et de connaissances sur les TIC et l'Institut Supérieur Catholique Campine.

Il a été utilisé dans le cadre du Moniteur de l'accessibilité des sites web belges qui a, en 2007 puis en 2009, évalué l'accessibilité d'un certain nombre de sites belges. Au cours de l'année scolaire 2008-2009, 276 étudiants de 3 instituts supérieurs en informatique ont contrôlé 336 sites Web belges. Voici le lien vers les résultats pour l'année 2015, auxquels la HEPL a participé.

Ce projet vise à sensibiliser les étudiants en informatique, en webdesign et multimedia à l'importance de garantir l'accessibilité de l'internet à tous dans l'espoir qu'ils contribuent au développement de l'internet accessible.

AnySurfer QuickScan

La procédure habituelle d'analyse, l'audit AnySurfer, nécessite un temps relativement important. La checklist d'anysurfer comporte en effet un grand nombre de directives.

Le QuickScan est une sélection de 15 critères considérés comme fondamentaux pour garantir l'accessibilité d'un site Web. Il s'agit donc d'un outil d'évaluation qui permet de se faire une première idée rapide mais fiable de l'accessibilité d'un site web. Notez bien que le QuickScan ne remplace pas la procédure complète d'audit AnySurfer. Cette dernière reste nécessaire pour se prononcer quant à l'accessibilité complète d'un site et obtenir le label anysurfer.

Le QuickScan permet de répondre à la question : « Ce site web satisfait-il aux critères minimum d'accessibilité pour prétendre au label AnySurfer ? ».

Pour obtenir une appréciation quantifiable, chacun des 15 critères est pondéré de 1, de 2 ou de 3. Dans un rapport, chaque critère est apprécié par l'étudiant comme OK, pas OK ou « Je ne sais pas » suivi par un commentaire. Si un rapport contient plus de « Je ne sais pas » , il est écarté des résultats. Un site web réussit le test du QuickScan s'il obtient un score d'au moins 75%.

Le QuickScan implique de contrôler au moins 6 pages représentatives de chaque site web. Parmi la sélection, les pages suivantes sont automatiquement reprises :

  • Page d'accueil
  • Page contact
  • Plan du site
  • Formulaire de recherches
  • Deux pages de conteu type

Vous trouverez un détail complet de la méthode ici et . Cette dernière page reprend, pour chaque critère, une courte explication théorique, des exemples de bonnes et mauvaises pratiques, ainsi que des instructions pour tester ce critère.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •