Ce document synthétise les attentes communes relatives aux projets de fin d'études des étudiants du bachelier en technique graphiques, orientation Web, de la Haute École de la Province de Liège.
Dans le parcours de l'élève, le PFE consiste en un moment privilégié d'intégration de tout ce qui a été appris durant le parcours et une occasion de démontrer son autonomie, tant dans la réalisation que dans le monitoring des qualités générales d’une réalisation.
Le parcours vise à la formation de professionnels full-stack, capables d'intervenir dans tous les aspects de la production d'un média destiné au Web. Il est donc attendu de l'élève de démontrer ses qualités dans les aspects suivis :
- analyse de la demande du client ;
- rédaction d’un cahier des charges ;
- conception d’une interface et d'une expérience pour l'utilisation du média ;
- intégration et développement frontend ;
- développement backend ;
- déploiement.
Il est attendu des élèves de communiquer les informations décrites dans la suite de manière professionnelle et marketing, via une newsletter. On peut s’imaginer que les professeurs concernés sont des beta testeurs qui se sont inscrits à la pre-release du projet. Le jour J, les créateurs du projet envoient une newsletter avec toutes les infos requises pour démarrer le test. Cette newsletter doit être en accord avec le branding du projet. Parmi les informations à fournir, citons :
-
un accès au projet déployé. Le plus souvent, il s'agira d'une URL, ainsi que des credentials pour divers comptes d'utilisateurs si des fonctionnalités diverses sont associées à chacun (à travers différents rôles par exemple). Dans le cas d'applications mobiles, les stratégies de déploiement sont différentes. Par exemple, sur IOS, il faut utiliser Testflight ;
-
un accès à un dossier préparatoire du design. Le plus souvent, il s'agira d'un projet figma dans lequel on retrouvera les écrans, des prototypes présentant des parcours utilisateurs, un moodboard, et les étapes de la conception (priority guides, wireframes, personas, …) ;
-
un accès au code source complet avec une explication de comment le redéployer en local ; L’objectif est que les professeurs qui le souhaitent puissent procéder à des tests dans leur environnement de développement (le site en ligne est réputé en production et des outils de monitoring ne sont donc pas accessibles aux visiteurs, mais le professeur doit avoir la possibilité de les utiliser. Par exemple, Laravel Debugbar). Dans ce repository, le fichier readme devra reprendre le cahier de charges complet de l'application ;
-
le cahier des charges devra être rédigé de manière à présenter les parcours utilisateurs réalisables dans l'application. Guidé par des besoins, impliquant des tâches, il sera l'occasion de décrire, fonctionnalité par fonctionnalité, des scénarios d'utilisation types réalisés par des personas. La présentation des personas fera partie du cahier de charges évidemment. Un plan de cahier des charges est disponible dans ce repo.
-
un site github pages annexe, construit dans un autre repo (nom-prénom-doc-PFE) qui servira de documentation technique au projet. Ce dernier jouera le rôle d'écrit. Il devra contenir des documents qui attestent de manière objective des qualités de votre projet :
-
Qualité du code HTML :
- des rendus headings map pour les pages publiques ;
- des captures d’écran attestant de la validation du code HTML, idéalement réalisées à l’aide de Total Validator, outil disponible sur les machines de l’école.
- mettre en évidence les efforts apportés à la sémantique et au respect des bonnes pratiques HTML. La HTML checklist peut-être un bon outil.
- des rendus de microdata pour les pages pour lesquelles c'est pertinent ;
- les efforts apportés à l'affichage des images sur votre site à commencer par un redimensionnement des images côté serveur, si cela est pertinent, et l'utilisation judicieuse d'srcset.
-
un rapport d'audit lighthouse ;
-
un rapport de contraste ;
-
un aperçu des performances côté serveur (laravel debugbar ; telescope ) ;
-
une présentation d'un ensemble d'au moins 30 tests automatisés significatifs côté serveur. Parmi ces tests, 15 seront des tests relevant du browser testing et les autres seront relatifs à des fonctionnalités côté serveur. Naturellement, en présenter 30 ne signifie pas que vous ne devez en faire que 30 ;
-
une observation de votre projet avec la checklist d’Opquast. Vous devez couvrir 2 règles par catégorie (il y en a 23) ;
-
un bilan illustré et commenté de tests utilisateurs des tâches décrites dans le cahier de charges. Vous choisirez cinq tâches prioritaires de votre application et la ferez réaliser par 3 personnes correspondant à la cible. In fine, il s'agit là de démontrer que l'expérience utilisateur obtenue avec votre réalisation est bien conforme aux attentes légitimes découlant du cahier de charges que vous avez annoncé. Ce bilan sera illustré par des captures vidéo de type screencast, avec le son (les utilisateurs doivent être invités à décrire ce qu'ils font), publiées sur une plateforme vidéo de votre choix, et commentés de manière à guider le lecteur dans des conclusions. Le fait qu'un test utilisateur démontre une faiblesse dans la conception ou la réalisation du média n'est pas un problème en soi, aucun produit n'est parfait. La perfection est attendue dans la qualité de l'analyse que vous ferez de l’observation des tests utilisateurs et des conclusions que vous en tirerez.
-
mettre en évidences, si cela se justifie, les efforts que vous avez apportés, pour enrichir l'expérience utilisateur à l'aide de JavaScript. Et si cela est pertinent, la dégradation gracieuse.
-