GROUPE B2 : 
- ALVAREZ Malori
- HUARD Louis
- PETILLON Ulysse
  

# Dépôt GitLab
https://gitlab.univ-lille.fr/sae2.01-2.02/2025/B2
# Prototype basse fidélité et captures d'écran

[Lien](https://www.figma.com/design/XRFiYyaUiOVbgUsyDpXwuU/Untitled?node-id=0-1&t=Ic7jDMYDq8GnwuCd-1) vers mockups Figma  
> Aller dans la section "Application"
  
# Justification conception et captures d'écran 

**Une partie sur la justification de vos choix de conception au regard des critères ergonomiques, guide de conception...(cela servira notamment à évaluer la compétence 5 "identifier les besoins métiers des clients et des utilisateurs" de R2.02). Il ne s'agit par de se contenter de quelques phrases, mais de justifier vos choix en passant en revue les critères ergonomiques vus en cours et en expliquant comment vous les avez pris en compte dans votre conception.**

Notre application est conçue pour être simple, modulable et facile à utiliser, afin de ne pas surcharger l'utilisateur·ice. Elle permet de gérer les appariements librement, tout en offrant un accompagnement discret et efficace.

Les interfaces respectent les principes de [guidage de Scapin](https://lagrandeourse.design/blog/ux-research/les-criteres-heuristiques-de-bastien-scapin/), avec une signalétique claire, des icônes explicites et des codes visuels conformes [aux lois de la Gestalt](https://www.usabilis.com/definition-theorie-de-gestalt/) (proximité, similarité) permettant une compréhension rapide des éléments. La grande majorité des pages sont responsives pour permettre à l'utilisateur.ice de moduler son environnement de travail et de mieux en visualiser les retours.

La page d’**accueil** sert de portail vers _Appariement_ et _Historique_, organisés selon une hiérarchie visuelle claire. Elle a été ajoutée mi-projet pour ne pas alourdir visuellement l’interface d’appariement avec d'autres redirections vers des pages annexes.

![Capture d'écran de la page d'accueil](../renduIHM/screenshots/accueil.png)

L’**historique** présente une vue synthèse des sauvegardes (date de création, taille, pays, année), la suppression rapide est sécurisée par une confirmation en pop-up, par gestion d'erreur, évitant toute suppression accidentelle. La navigation est intuitive : retour au menu ou double-clic pour une visualisation dynamique des données. Un double-clic ouvrira une fenêtre de visualisation des données,

![Capture d'écran de l'historique et apercus](../renduIHM/screenshots/history.png)

La **page d'appariement** constitue le cœur de l’application : toutes les fonctionnalités en découlent et s’y articulent. Nous avons consacré l’essentiel de nos efforts à faciliter sa prise en main et sa modularité. 
Comme presque toutes les pages, celle-ci est responsive : elle s’adapte à la taille de la fenêtre et ajuste ses éléments pour que l’utilisateur·ice selon ses préférences.
Celle-ci possède deux fenêtres complémentaires afin de ne pas saturer l'interface principale : une de **restriction** et une d'**import**. 

La **fenêtre de restriction** permet de visualiser et d'ajouter / retirer des paires "*Obligatoires*" et "*Impossibles*".  Elle fut ajoutée après plusieurs utilisations de l'application, afin de faciliter la gestion et la visualisation des paires ayant une relation particulière. L'on peut la quitter en la fermant ou en cliquant sur le bouton prévu à cet effet. 

La **fenêtre d'import** permet, comme son nom l'indique, de gérer les imports de *guest* et d'*host* depuis l'explorateur de fichier, ne montrant que les fichiers '.csv' . Notre idée initiale était d’extraire les données directement depuis les fichiers, mais nous y avons finalement renoncé. En effet, distinguer les fichiers importés de ceux initialement présents risquait de rendre l’utilisateur.ice confus.e. L'on y retrouve nos fichiers importés, leur taille, nom et date de création. Double-cliquer sur un fichier le déploie dans la fenêtre d'appariement ouverte à côté, le sélectionner et appuyer sur l'icône de poubelle le supprimera (uniquement de la liste d'import).

![Capture d'écran de la page d'appariement et de ses fenêtres associées](../renduIHM/screenshots/appariement_resctriction.png)
![Capture d'écran de la page d'appariement et de ses fenêtres associées](../renduIHM/screenshots/appariement_import.png)
La **page de pondération** fait suite à celle d'appariement et permet de visualiser les résultats obtenus. 
Elle offre à l’utilisateur.ice la possibilité d’ajuster librement les poids des critères et d'obtenir la valeur de "favorabilité" du critère pour chaque paire. 
Cet ajustement se fait par des sliders gradués pour chaque critère, étant un widget facile d'utilisation dont la représentation et l'expérience utilisateur 
Les cas défavorables sont mis en évidence par un feedback visuel (code couleur), facilitant l’interprétation de l’affinité et l’évitement des paires non désirées. 
Cliquer sur le bouton calcul renvoie un chargement à l'utilisateur selon le principe de guidage des  [8 critères ergonomiques de Scapin & Bastien](https://lagrandeourse.design/blog/ux-research/les-criteres-heuristiques-de-bastien-scapin/) consistant à donner des indications claires sur ce qu’il se passe après une action, dans ce cas là, le lancement du calcul. 
L'on peut également exporter ces données dans nos fichiers (ouvrant l'explorateur) via l'icône explicite à son effigie, revenir au menu ou à l'appariement.

![Capture d'écran de la page de gestion de pondération](../renduIHM/screenshots/ponderer.png)
  

# Justification contributions

**Une partie qui détaille les contributions de chaque membre du groupe. Comment vous avez réussi à exploiter au mieux les compétences de chacun? (cela servira notamment à évaluer la compétence 6 "identifier ses aptitudes pour travailler dans une équipe" de R2.02), toute autre information utile permettant de mettre en valeur votre travail.**

Cette SAE est arrivée en même temps que de nombreuses autres, ce qui nous a privé de temps et nous a empêchés de nous y consacrer pleinement.  

### **Début de SAE**
Nous avons estimé et réparti les tâches en tenant compte des préférences, des forces et des faiblesses de chacun.e :

**Ulysse et Louis**, doués en développement orienté objet, ont pris cette partie en charge dès le début avec *l'implémentation des classes de base* et donc du fonctionnement global de l'appariement, et de l'*UML*.  

**Malori**, maîtrisant particulièrement bien le graphisme, s'est occupée de la maquette et de la majeure partie de l'aspect graphe, se chargeant du *système d’appariement*, ainsi que du sujet et rapport de graphe.

### Partie POO 
Cette partie s'est souvent trouvée complémentaire à celle du graphe, nous permettant d'échanger, partager nos avancées et nous entraider sur certaines notions ou implémentations compliqués en les décomposant pour les autres.  

(du 29 avril au 5 mai 2025) **Sur la semaine 1** : L'équipe POO (Ulysse et Louis) a conçu les **classes de base**. 
**Ulysse**, particulièrement à l’aise avec la modélisation, s’est concentré sur la **structure des classes** du programme. Il a rédigé l’ossature UML du projet et défini les entités principales. **Malori**, de son côté, a commencé par **proposer une maquette visuelle** du projet.

(du 6 au 12 mai 2025) **Sur la semaine 2** : Mise en place du **système d’appariement algorithmique** et implémentations de plusieurs approches, dont _PairPlus_, _Adoplus_, **Louis** a pris en charge l’algorithme **Adoplus** ainsi que l’intégration d’un **début d’algorithme hongrois**, bien que partiel, extensible. **Ulysse** a implémenté et validé les tests, préparé la documentation (`javadoc`), et intégré les bibliothèques nécessaires à l'exécution.

(du 13 au 19 mai 2025) **Sur la semaine 3** : **Louis** s’est concentré sur la gestion des exceptions, la correction des critères logiques, et l'amélioration de la structure du projet. **Ulysse** débute la sérialisation et ajoute quelques test, notamment sur `Adolescent` ainsi que des CSV pour les essayer.

(du 20 au 26 mai 2025) **Sur la semaine 4** : **Louis** a nettoyé l’ensemble du code back-end, revu les conventions de nommage, et ajouté des **tests unitaires complémentaires**. **Ulysse**, de son côté, a complété la **documentation UML** et remis à jour d'autres fichiers.

(du 27 mai au 2 juin 2025) **Sur la semaine 5** : **Louis** a mis à jour l’UML, ajouté des diagrammes (Draw.io), et intégré les fichiers FXML. **Ulysse**, quant à lui, a renforcé la sérialisation des objets, ajouté des tests, et amélioré la lecture de fichiers CSV pour les invités et hôtes.

(du 3 au 7 juin 2025) **Sur la semaine 6** :  **Malori**, ayant fini la partie graphe, a enrichi l’interface graphique avec de nouvelles pages (`History`, `Restriction`), ajouté des éléments visuels, et nettoyé les fichiers du dépôt. **Ulysse** a restructuré l’IHM et intégré le traitement des critères et valeurs par défaut à partir de fichiers externes et **Louis** a consolidé le code, effectué de multiples corrections, et mis en place le gestionnaire de scènes (`SceneManager`)

(du 9 au 13 juin 2025) **Sur la semaine 7** : **Louis** a finalisé l’interface graphique (`Appariement.fxml`, `Pairing.fxml`) et l’intégration visuelle de l’application,**Malori**, rattrapant le retard, a géré les erreurs liées à l’historique de l'application. **Ulysse** a effectué les dernières intégrations de fichiers CSV, optimisé la gestion des poids et des critères, et corrigé les valeurs par défaut.

### Graphe
La pondération sera convenue par **Malori** avec l'aide et l'aval du groupe, permettant de poser le pseudo-code pour décider du poids de chaque critère, embrayant sur l'ensemble du rapport dans ses 3 versions. Sur les derniers jours, l'ensemble de l'équipe s'est mobilisée pour finaliser les calculs d'appariements sur des adolescent.es fictives pour tester la pondération.


### **IHM**
Le travail a été réparti équitablement, sur nos rythmes et méthodologie respectives,
*Pour plus de précisions sur les points abordés, se référer à la décomposition par semaine de la partie POO qui comprend une partie de l'IHM*

**Ulysse** aura effectué une grande partie des pages en FXML, en accord avec la maquette, ainsi que l'ensemble des controllers de celles-ci, et donc réalisé la majorité de la **liaison POO - IHM**, par la lecture et implémentation des csv, données et de leurs sérialisation utilisées dans les listView d'Adolsecent.es. Il aura également réalisé de nombreux test et d'optimisations, notamment pour les données hôte·sse·s & invité·e·s, garantissant une IHM fluide et validant le bon fonctionnement des interfaces.

**Louis** se chargera de faire de retranscrire des pages de maquettes en FXML, notamment (`Appariement.fxml`, `Pairing.fxml`. Ainsi que de rendre la plupart des pages **responsive**, aspect important du projet, en mettant l'accent sur la page d'appariement qui serait en toute logique la plus utilisée, il réalisera également la **page d'accueil**. C'est grâce à tout cela que l'on pourra commencer l'organisation de l'architecture de l’IHM à travers ces fichiers. A l'aide de son implémentation de `SceneManager` en POO, classe permettant de centraliser et simplifier la gestion des interfaces, il a pu réaliser le système de navigation entre les différentes scènes de l’application par la suite. Pour ce qu'il en est de l'intégration, il aura réalisé de nombreux commits de corrections d’éléments graphiques ou de bugs visuels ainsi que des ajustements des comportements liés à l’**interaction utilisateur** (réponse aux clics ou aux sélections par exemple). Pour finir, il terminera sur l'intégration visuelle complète en dernière semaine (Semaine 7), notamment avec l’harmonisation des vues et le peaufinage de l’interface pour la version finale, ainsi que la réalisation de la vidéo de présentation de l'application.

 **Malori** s’est penchée sur la **maquette graphique** de l’application. Elle a esquissé les premières interfaces utilisateur, commencé à structurer les vues, et proposé des choix esthétiques guidant l’identité visuelle du projet (voir page DA du [Figma](https://www.figma.com/design/XRFiYyaUiOVbgUsyDpXwuU/Untitled?node-id=0-1&t=Ic7jDMYDq8GnwuCd-1)). Elle aura aussi réalisé l'ensemble de l'**historique** et ce qui en est relatif (tel que les aperçus de données, la gestion d'import/suppression de celles-ci et d'erreurs qui en découlerait), participé à la gestion des événements utilisateurs (clics, validations, erreurs...), la réalisation de ce rapport et la **présentation orale** de l'application. 

**Les dernières fonctionnalités essentielles** ont été implémentées durant la dernière semaine, ce qui nous a ensuite permis d’ajouter des éléments plus secondaires, axés sur le confort, la praticité, et le respect des règles d'ergonomies enseignées.
 

# Présentation Vidéo

  ### Vidéo de présentation de notre projet conforme aux [exigences](https://gitlab.univ-lille.fr/gery.casiez/videomaker) destinée aux recruteur.ices.
![vidéo présentation](../../IHM/video/videoPROCESSED.mp4)