Devoir-projet : mini-site

2016-2017

Objectifs

Reprendre les concepts vus au cours des différentes séances pour les agréger au sein d'un travail conséquent.
Démontrer votre maîtrise des problématiques fondamentales de la publication sur un site web : ergonomie, accessibilité et référencement d'une part, graphisme, mise en page et traitement de l'information d'autre part.

Sujet

Vous devez réaliser, en binôme (les monômes sont acceptés, mais la notation ne sera pas spécialement adaptée), un mini-site sur un sujet de votre choix. Il doit au moins en partie porter sur des choses listables ; dans la suite de l'énoncé, nous parlerons d'« objets », mais ce ne sont pas nécessairement des objets au sens propre. Cela pourra être par exemple des livres, chansons, pays, mots, disques, arbres, boîtes de camembert, Pokémon…

Préférez un sujet original (en particulier, autre chose que votre page perso) ; mais vous ne serez pas jugé·e sur le choix du sujet. Cependant, ne reprenez pas tels quels les objets « poème », « couleur » et « animal » manipulés en cours et en TP.

Consignes

Votre site devra de plus respecter les contraintes suivantes.

Vous devrez stocker les « objets » et les comptes utilisateur dans une base de données MySQL ou PostgreSQL.
Vous devrez utiliser l'architecture MVCR vue en cours et détaillée lors des TP 4, 5 et 6, avec en particulier une bonne séparation des classes métier (le modèle), de l'affichage (vues), de la gestion des requêtes HTTP (routeur), de la gestion des actions (contrôleurs), et des détails de stockage en base de données.
Les pages générées devront être valides HTML5 (pas la peine qu'elles soient valides CSS, le validateur W3C est trop en retard sur les spécs).
On attend un minimum de recherche pour le design des pages (mise en page, choix des couleurs…), qui doit autant que possible être en adéquation avec le choix du sujet. L'ergonomie et l'accessibilité seront également des facteurs d'évaluation.
Il faudra gérer l'authentification des utilisateurs :
- tout·e internaute devra pouvoir s'inscrire en fournissant certaines informations personnelles ;
- les personnes non authentifiées pourront voir la liste des « objets », mais pas la modifier ;
- les personnes authentifiées pourront ajouter des objets, mais aussi modifier et supprimer leurs propres objets (mais pas ceux des autres).
Le site devra contenir une page de type « à propos », qui contiendra les numéros étudiants des membres du binôme (mais pas les noms, pour permettre une correction un minimum anonyme), mais aussi une courte présentation/justification de vos choix en matière de design, modélisation, code, etc., et tout ce qu'il vous semble utile de nous signaler.

Outre le respect des consignes, nous évaluerons votre travail suivant la qualité du HTML-CSS (séparation fond/forme/comportement, cohérence des balises, propreté et concision du CSS…) et du PHP (lisibilité, propreté, sécurité).

Bonus

N'hésitez pas à enrichir votre mini-site, en contenu ou en fonctionnalités (partie d'administration des comptes utilisateur, possibilité de configurer certains aspects de l'affichage…). À condition que les consignes de base soient respectées, et dans une certaine limite de points (voir plus bas), ce que vous rajouterez comptera comme bonus dans l'évaluation ; n'oubliez cependant pas d'en parler sur votre page « à propos », pour que nous ne rations rien.

Attention, vous pouvez utiliser JavaScript autant que vous voulez pour améliorer l'expérience utilisateur, mais le site doit pouvoir fonctionner sans.

Remarques sur l'architecture

Un des objectifs du DM est de vous faire appliquer l'architecture présentée en cours et détaillée dans le gros exercice filé des TP 4, 5 et 6. Certains des choix faits dans ces exercices sont destinés à en simplifier l'énoncé : ils ne représentent pas une consigne ferme. Par exemple, si vous regardez les sources du site des poèmes ou des couleurs, vous verrez qu'il y a des variations. Vous pouvez vous aussi tout à fait faire des choix différents.

Cependant, les principes de l'architecture MVCR doivent être respectés. Plus vous vous éloignerez de la structure présentée en cours/TP, plus vous vous exposerez à la critique. Réfléchissez bien avant de faire des choix architecturaux trop différents (vous pouvez aussi évidemment en discuter avec moi), et si vous décider de les faire, justifiez-les sur votre page « à propos ».

Remarque pour les spécialistes du PHP : il n'est pas interdit de réutiliser des bouts de code que vous auriez déjà écrits, mais ne reprenez pas tout le super framework perso sur lequel vous travaillez depuis deux ans. C'est très difficile à évaluer, ça prend beaucoup de temps, ce n'est pas très juste par rapport aux autres (⇒ on n'évalue pas un simple DM mais le travail de plusieurs mois/années), et on ne peut pas vérifier votre implication personnelle dans le développement. Ça peut être frustrant pour vous, mais ce type de frustration est courant en informatique — et rien ne vous empêche d'intégrer proprement vos idées dans l'architecture demandée.

Barème indicatif

Le nombre de points pourra être modifié si nécessaire. Voir plus haut pour les détails sur chaque élément.

Respect des consignes : 12 points
- Architecture correcte, site basique fonctionnel : 6 points
- Comptes utilisateur, authentification : 3 points
- Respect des droits d'accès : 3 points
Apparence et utilisabilité : 8 points
- Effort de design : 3 points
- Accessibilité : 3 points
- Ergonomie : 2 points
Bonus et malus : entre -7 et +5 points
- Malus pour la non-validité du HTML : entre -1.5 et 0 point
- Malus pour les problèmes de sécurité : entre -3 et 0 points
- Bonus-malus pour la qualité du code client (HTML/CSS) : entre -1.5 et +1 point
- Bonus-malus pour la qualité du code PHP : entre -1 et +1 point
- Bonus pour les ajouts et fonctionnalités supplémentaires : entre 0 et +3 points

Compléments d'information

Le site devra être hébergé sur le serveur web du département (voir plus bas pour les détails).
La correction se fera avec Firefox sous Ubuntu sur les machines du département. On ne vous demande pas que votre HTML/CSS/JavaScript fonctionne sur d'autres navigateurs ou OS. En revanche le site sera testé avec et sans JavaScript.
Dans la mesure du possible, la correction se fera de façon anonyme. Ne mettez pas vos noms sur le site, dans les sources et dans les noms de fichier (seulement vos numéros étudiants sur la page « à propos »).
Les contenus (textes, images, etc.) peuvent être pris sur diverses sources, à condition de les citer.
Il n'est pas à proprement parler interdit d'utiliser un framework CSS (ou JS), mais nos exigences en matière de design seront plus hautes, et ça impactera probablement sévèrement notre appréciation de la qualité du code.
Si votre site utilise de l'upload de fichiers, les fichiers récupérés devront être placés dans le répertoire upload à la racine du mini-site (voir section suivante).
N'hésitez pas à vous entraider, mais ne copiez pas le code des autres. Nous serons sévères envers les fraudes.
En cas de difficultés, n'hésitez pas à nous contacter.

Rendu du devoir

La date limite de rendu du devoir est le ~~mercredi 8 mars~~dimanche 26 mars à 23h.

Un des membres du binôme devra placer l'intégralité du travail sur le serveur web du département, dans le répertoire /users/NUMETU/www-dev/projet-eci62-2017/ (qui a été créé pour vous). Vous ne devez pas supprimer ou renommer ce répertoire : après la date limite, il sera rendu inaccessible en écriture jusqu'à ce que la correction soit terminée (excepté le répertoire /users/NUMETU/www-dev/projet-eci62-2017/upload/, pour que l'upload de fichiers puisse continuer à fonctionner). Votre mini-site sera donc accessible en ligne à l'URL https://dev-NUMETU.users.info.unicaen.fr/projet-eci62-2017/.

D'autre part, vous devrez déposer sur Moodle une archive contenant toute l'arborescence du site ainsi que tout fichier nécessaire à son déploiement (pensez notamment à faire un dump de vos bases de données, si nécessaire). Un dépôt par binôme suffit.

Attention à ne pas mentionner vos noms sur le site ou dans le code (ou les noms de fichier…), de façon à ce qu'une correction anonyme soit possible.

Si vous développez sur votre propre serveur, prévoyez de la marge pour le déploiement sur le serveur du département. Entre la BD, les différences de versions de PHP et la configuration d'Apache, il peut y avoir énormément de problèmes imprévisibles.

En cas de problème au moment du rendu de votre travail, contactez-nous le plus rapidement possible.