Travail 3 (T3)

Code source et donnés: ExpenseVisualization.zip (ancienne version)

Code source et donnés: ExpenseVisualization-v2.zip (nouvelle version)

Pour ce travail, vous avez à développer une visualisation interactive de dépenses gouvernementales. On vous fournit deux ensembles de données ("hospitality expenses", concernant des repas dans des restaurants, et "travel expenses", concernant des dépenses pour des voyages) et le code source d'un logiciel de base qui lit un des ensembles de données et permet de faire une visualisation simple de certains aspects des données. Vous aurez à modifier le code source pour permettre des visualisations interactives plus riches.

Le code fourni est écrit en Java, et se sert de l'API de Processing (en héritant de la classe PApplet), et aussi de la librarie Interfascia pour les widgets.

Les données brutes sont dans les fichiers de texte hospitality_expenses-utf8.txt et travel_expenses-utf8.txt. Des petits échantillons de ces fichiers se trouvent dans hospitality_expenses-sample.txt et travel_expenses-sample.txt, qui pourraient vous être utiles pour tester et déboguer votre code avec des petits ensembles de données. Le code fourni se sert d'une base de données SQLite (stockée dans le fichier log740.db) créée à partir de hospitality_expenses-utf8.txt.

Notez que les fichiers .jar pour l'API de Processing, Interfascia, SQLite, et la documentation pour Interfascia sont inclus dans le .zip qui vous est fourni. Vous n'avez pas besoin d'installer ces choses separément.

Vous avez à concevoir et réaliser des modifications au code pour permettre différentes visualisations des données. En un premier temps, vous devez

• Réaliser un graphique 2D montrant le temps sur un axe et les dépenses sur l'autre axe. Ce graphique pourrait être un graphique à ligne brisée, ou bien à barres, ou quelque chose de semblable. L'utilisateur doit pouvoir voir les dépenses en fonction du temps, soit jour-par-jour, ou bien mois-par-mois, sur l'ensemble du temps couvert par les données (2003 à 2008). Vous pouvez utiliser un méchanisme approprié, comme des boutons radio, pour permettre de sélectionner entre une vue par jours et une vue par mois. Dans la vue par jours, comme il vous manquera probablement d'espace à l'écran pour allouer au moins un pixel par jour et voir tous les jours en même temps, vous devez réaliser une façon de défiler ("scroller") le graphique dans le temps, et aussi de changer l'échelle ("zoomer") pour voir soit l'ensemble des données, ou bien pour concentrer la vue sur une période de temps donnée. Le "zoom" peut se faire juste dans la direction de l'axe du temps; vous n'avez pas besoin de permettre aussi un zoom dans la direction de l'axe montrant les dépenses. Quand l'utilisateur a fait un "zoom-out" complet, il faut montrer une vue globale des donnés, et dans ce cas ce n'est pas grave si certains jours prennent moins de 1 pixel, ou bien certains jours chevauchent ou disparaissent. Une façon simple de permettre de faire un scroll ou bien un zoom serait d'associer chaque action avec une touche ou un bouton de souris différent (exemple: Ctrl+bouton de gauche pour scroller, Shift-bouton de gauche pour zoomer) et de permettre à l'utilisateur de glisser directement sur le graphique, mais vous pouvez également utiliser des widget dédiés comme des barres de défilement pour le scroll et zoom.

1. Voir qui a dépensé de l'argent, et combien. Par exemple, cette vue devrait permettre de voir quel individu a dépensé le plus d'argent par rapport aux autres individus.
2. Voir quels départements ont dépensé de l'argent, et combien, et lesquels ont dépensé le plus. Notez: il y a moins de 50 départements uniques dans les ensembles de données.
3. Voir où de l'argent a été dépensé, et combien, et où le plus d'argent a été dépensé. Il y a déjà du code de base pour voir les dépenses par ville dans une province donnée. Vous pouvez garder cette approche et l'améliorer (par exemple: en montrant la somme des dépenses pour chaque province dans la carte du Canada), ou bien adopter une approche différente (par exemple: voir toutes les villes du Canada en même temps, mais regroupées par province; ou voir aussi les villes à l'extérieur du Canada; ou voir les dépenses par restaurant en ordre alphabétique).
4. Voir quand l'argent a été dépensé par rapport à des évènements connus ou des périodes de temps particulières. Par exemple, est-ce que plus d'argent est dépensé en campagne électorale par rapport au reste du temps? Durant l'été? Les vendredi? Durant d'autre évènements internationaux (conférence de l'OMC, ...)?
5. Permettre de lire et visualiser le deuxième ensemble de données ("travel expenses") avec les mêmes genres de vues que vous avez réalisées pour le premier ensemble de données ("hospitality expenses").

Si vous êtes une équipe de 3 (ou 2) personnes, vous pouvez choisir trois (3) des items de la liste ci-haute à réaliser. Si vous êtes une équipe de 4 personnes, vous devez faire quatre (4) des items dans la liste ci-haute.

En faisant la conception et la réalisation de vos différentes vues des données, essayer de penser à des manière intéressantes d'utiliser

• Des effets de surbrilliance (highlighting) des items (points, barres, pointes de tarte, provinces, etc.) de données en dessous du curseur, par exemple pour montrer à l'utilisateur qu'on peut cliquer sur l'item pour avoir plus d'informations.
• Des infobulles, ou simplement des étiquettes de texte affichées pour donner plus de détails sur un item en dessous du curseur
• Des étiquettes sur les axes, sur les items, ou ailleurs, pour donner plus d'informations, sans surcharger la vue de trop d'informations

De plus, dans chacune de vos vues, il devra être possible d'aller chercher des informations plus détaillées sur chaque item (point, barre, pointe de tarte, province, etc.) dans la vue. Cela peut se faire via une infobulle qui apparaît lorsque le curseur est par dessus l'item, ou bien apparaître dans un "popup" lorsqu'on clique sur l'item, ou bien apparaître dans le bas de la vue (dans un champ spécial), etc. L'important et de permettre à l'utilisateur d'aller chercher des "details on demand" (détails sur demande).

La version finale de votre code doit étre un applet qu'on peut intégrer dans une page web.

Vous avez à remettre un rapport (avec votre code) et aussi à présenter votre projet en classe.

Le rapport devra contenir les sections suivantes:

• Une section "Documentation" expliquant succintement le fonctionnement de l'interface utilisateur de votre logiciel. Identifiez au début les vues parmi la liste que vous avez choisies de réaliser. Votre chargé de laboratoire devra être capable de lire cette section et comprendre facilement les fonctionnalités que vous avez réalisées sans voir votre code en exécution devant lui, et comprendre aussi comment fonctionner votre logiciel (exemple: boutons, touches, options spécials ou cachés) lorsqu'il l'exécute. Entre 2 et 4 pages de texte (simple interligne), plus captures d'écran totalisant un maximum de 8 pages.
• Une section "Implémentation" (1-2 pages, simple interligne) qui discute brièvement des détails de votre code. Parlez des classes, des structures de données, des méthodes ou sous-routines ou des endroits clés dans votre code qui réalisent vos changements. Imaginez que cette section est déstinée à un programmeur qui connais déjà le code fourni pour le cours, et qui doit prendre charge de votre code pour faire de la maintenance.
• Une section "Améliorations" (1-2 pages, simple interligne) où vous suggérez des façons que votre interface pourrait être améliorée pour la rendre meilleure ou plus flexible. Par exemple, y a-t-il des fonctionnalités que vous aurez voulu réaliser, mais pour lesquelles vous avez manqué de temps ? Aussi, y a-t-il des questions qu'un utilisateur pourrait se poser concernant les données que l'interface actuelle ne permet pas de répondre? Par exemple: "Parmi les individus qui dépensent le plus, où et quand dépensent-ils le plus ?" Ou "Dans le villes où on dépense le plus, quels départements sont les plus actifs ?" Vous pouvez inclure un croquis fait à la main (et numérisé) pour montrer le fonctionnement d'une interface améliorée.
• Une section "Opinion de Processing" (un paragraphe) où vous donnez votre opinion de l'utilisation de (l'API de) Processing pour ce projet: est-ce que cela a été utile ? Dans les futures versions du cours, est-ce que cela vaut la peine de continuer à utiliser Processing, ou devrait-on simplement utiliser du Java "pur" ?

Remise

À remettre par courriel à l'adresse log740remise@... mentionnée sur la page principale du site web du cours:

• Le rapport (format .pdf s.v.p. - vous pouvez utiliser PDFCreator pour générer des fichiers .pdf à partir de Microsoft Word)
• Le code source, et tout autre fichier nécessaire pour compiler et exécuter, dans un fichier qui s'appelle T3-nn.zip, où nn est votre numéro d'équipe (01, 02, ... 12). Lorsqu'on "dézip" ce fichier, le contenu devrait se retrouver dans un répertoire qui s'appelle T3-nn.

À remettre dans la chute du département:

• Le rapport imprimé

Notez: En collaboration avec VisibleGovernment, un organisme à but non-lucratif qui nous a fourni les ensembles de données, nous aimerions bien pouvoir utiliser le code (ou des parties du code) de certains projets d'étudiants pour monter un applet disponible en ligne pour le public, pour faciliter l'accès à ces données. Si vous ne voulez pas que votre code soit utilisé à ces fins, veuillez l'indiquer dans votre rapport et aussi dans un fichier README.TXT (ou LISEZMOI.TXT) dans votre code source. Si vous êtes d'accord que votre code puisse être utilisé à ces fins, et qu'en plus vous voulez que vos noms paraissent dans des remerciements et/ou comme (co-)auteurs de l'applet sur le site web public qui sera éventuellement mis sur place, veuillez aussi l'indiquer dans votre rapport et dans un fichier README.TXT (ou LISEZMOI.TXT) avec votre code.

Évaluation de T3 (15% de votre note finale au cours)

Rapport (incluant la qualité des images et de la langue):
   section "Documentation"                     20%
   section "Implémentation"                    15%
   section "Améliorations"                     15%
   section "Opinion de Processing"              1%
Logiciel:
   vue temps-dépenses                          12%
   changements au choix                        24%
   détails sur demande                          3%
   bonne utilisation de surbrilliance,
      infobulles, étiquettes                    5%
   qualité et originalité de l'interface        5%
      (qualité visuelle, utilisation simple,
      espace ni surchargé ni sous-utilisé)
Total:                                        100%

Présentation orale en classe (5% de votre note finale au cours)

Chaque équipe doit présenter leur projet en classe. La présentation sera évaluée par le prof du cours.

Les présentations auront lieu le 6 avril pendant le cours. Chaque présentation aura une durée de 10 minutes + une courte période de questions. L'ordre des présentations sera établi au hasard. Si certaines équipes veulent présenter leur projet une semaine d'avance, au cours du 30 mars, veuillez contactez le prof par courriel.

Évaluation des présentations en classe: sur un total de 5 points

• [3 points] Présentation des 3 (ou 4) changements choisis par l'équipe, et comment ces changements ont été réalisés. Pour chaque changement, expliquer et montrer comment les entrées, les sorties visuelles, et le code source a été changé. N'allez pas trop en détail avec le code source; vous pouvez décrire en termes généraux la stratégie employée pour chaque changement (exemples: que vous avez utilisé un timeout ici, ou une liste d'objets là, etc.) et peut-être montrer des bouts de code ou bien de pseudo-code. Notez bien: les équipes qui passent une semaine d'avance n'ont pas besoin d'avoir fini leurs changements. Ces équipes peuvent présenter les changements complétés à date, et aussi les changements prévus (par exemple, avec une esquisse de l'interface conçue) qui sont à venir.
• [0.5 points] Présenter 2 changements supplémentaires, n'apparaissants pas sur les listes de changements donnés, que vous aimeriez réaliser si vous aviez le temps. Décrire comment ces changement pourraient être réalisés.
• [1 point] Qualité vocale (parler clairement et assez fort, ne pas regarder trop souvent un aide-mémoire, éviter une façon trop familière (informelle) de parler) et qualité des diapos (choix de couleurs qui donne un bon contraste, polices claires et cohérentes; pas trop de polices différentes, diagrammes et images clairs, pas trop de texte sur chaque diapo)
• [0.25 points] Réponses précises et concises aux questions, en reformulant la question au besoin.
• [0.25 points] Respect de la limite de 10 minutes pour la présentation.

Dans l'intérêt du temps, vos présentations n'ont pas besoin d'avoir d'introduction ou de conclusion formelle.

Il y aura aussi un prix pour le meilleur projet, choisi par un vote.

Voici des captures d'écran montrant ce que le code qu'on vous fournit peut déjà faire: