« STIC:STIC II - exercice 15 (Yoshi) » : différence entre les versions
mAucun résumé des modifications |
mAucun résumé des modifications |
||
(4 versions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
{{ | {{stic archive}} | ||
<categorytree mode="pages" depth="0" style="float:right; clear:right; margin-left:3px; border:1px solid gray; padding:0.7ex; background-color:#f9f9f9;">STIC</categorytree> | <categorytree mode="pages" depth="0" style="float:right; clear:right; margin-left:3px; border:1px solid gray; padding:0.7ex; background-color:#f9f9f9;">STIC</categorytree> | ||
Ligne 90 : | Ligne 88 : | ||
** Vous pouvez également estimer le temps que chaque modification va vous prendre et utiliser une application de type "Time-Tracker" pour calculer le temps effectif (e.g. [https://www.toggl.com Toggl]) | ** Vous pouvez également estimer le temps que chaque modification va vous prendre et utiliser une application de type "Time-Tracker" pour calculer le temps effectif (e.g. [https://www.toggl.com Toggl]) | ||
'''À noter''' : le but de l'exercice et de faire mieux, pas de faire plus. Vous ne devez pas forcément ajouter des contenus ou des interactions, mais améliorer ce qui existe déjà. | {{ bloc important | '''À noter''' : le but de l'exercice et de faire mieux, pas de faire plus. Vous ne devez pas forcément ajouter des contenus ou des interactions, mais améliorer ce qui existe déjà. }} | ||
=== Critères d'évaluation === | === Critères d'évaluation === | ||
Ligne 134 : | Ligne 132 : | ||
=== Délai === | === Délai === | ||
{{ bloc important | Date limite pour rendre l'exercice : ''' | {{ bloc important | Date limite pour rendre l'exercice : '''mercredi 5 juin à 12:00''' }} | ||
Cette date n'est pas négociable car nous devons rendre les notes au secrétariat. Elle est donc valable également pour tout exercice non rendu pendant le semestre. | Cette date n'est pas négociable car nous devons rendre les notes au secrétariat. Elle est donc valable également pour tout exercice non rendu pendant le semestre. |
Dernière version du 15 avril 2020 à 11:24
Cette page fait partie des archives des cours Cours STIC (STIC I, STIC II,STIC III,STIC IV)
Introduction
Pour cet exercice vous allez reprendre et « finaliser » l’un de vos exercices STIC I (sauf le premier) ou STIC II. L'objectif est d’améliorer ce que vous avez fait et rendre votre dispositif plus abouti.
Ne modifiez pas directement votre exercice, vous devez rendre une nouvelle version en tant qu’exercice 15.
Connaissances/compétences envisagées
Cette activité vous permettra de :
- Remobiliser et consolider vos connaissances par rapport à la technologie liée à l’exercice que vous allez choisir
- Réévaluer ce que vous avez fait auparavant en fonction de ce que vous avez appris pendant l’année (en STIC mais également dans d’autres cours)
- Reprendre un dispositif qui existe déjà, comprendre sa logique, sa structure, etc. à distance d’un certain temps, ce qui arrive souvent (même avec des dispositifs que vous n’avez pas créés vous-même)
Dans une perspective plus appliquée, vous pouvez imaginez cet exercice comme une sorte de deuxième sprint dans une méthodologie de type Agile, voir par exemple :
Types d’amélioration possibles
On vous demande d’apporter des améliorations substantielles, pas simplement « cosmétiques ». Nous vous proposons trois axes d’intervention principaux :
- Technique
- Ergonomique
- Pédagogique
Vous n’êtes pas obligés d’améliorer chacun des trois axes (pour certains exercices qui utilisent des outils auteurs l’amélioration technique est parfois difficile, voire impossible), mais si vous choisissez un seul axe, alors les modifications doivent être conséquentes. Pour les améliorations vous pouvez vous appuyer sur les feedbacks (individuel et collectif) que vous avez reçus pour chaque exercice. Idéalement, il faudrait également faire des liens avec les connaissances que vous avez acquis pendant l'année dans les différents cours du MALTT!
Amélioration technique
Vous pouvez améliorer votre dispositif d’un point de vue technique, par exemple :
- Créer un layout responsive (qui s’adaptent à différent taille d’écran et dispositifs) en utilisant par exemple un framework CSS (e.g. Bootstrap)
- Améliorer la logique de l’application de votre dispositif (e.g. améliorer votre code, utiliser des boucles, etc.)
- Utiliser une ou plusieurs bibliothèques JavaScript (e.g. Vue.js)
- Créer des tests automatiques pour évaluer que votre dispositif marche correctement (voir Test Driven Development, mocha.js, should.js)
- Améliorer la qualité d'une vidéo, réduire sa taille sans perdre en qualité, ...
- Mieux intégrer un outil externe avec Moodle
- ...
Amélioration ergonomique
Vous pouvez améliorer votre dispositif par rapport à l’expérience utilisateur, par exemple :
- Faciliter l'identification du dispositif et de son utilité (e.g. éviter titre "Exercice X", layout commun à tout exercice, etc.)
- Utiliser vos connaissances acquises en ERGO (e.g., heuristiques de Bastien & Scapin) pour identifier et remédier à des difficultés d’utilisation
- Vous pouvez faire un petit test utilisateur avec des amis ou collègues si vous voulez/pouvez
- Rendre globalement l’interaction avec votre dispositif plus aisée (instructions plus claires, regroupement des éléments, etc.)
- Ajouter des « micro-interactions » qui améliorent la perception des transitions ou changements dans l’interface suite à des manipulations directes
- Insérer des indices visuels qui dirigent l'attention sur des aspects importants (e.g. dans une vidéo)
- ...
Amélioration pédagogiques
Vous pouvez améliorer votre dispositif par rapport aux apprentissages qu’il est censée faciliter, par exemple :
- Améliorer la qualité des feedback
- Identifier et rendre plus évidente le lien avec une théorie pédagogique sous-jacente
- Créer des évaluations plus variées et qui nécessitent d’un traitement profond de l’information
- Mieux identifier et expliciter les objectifs de votre dispositif en termes d'acquis/savoir faire
- Utiliser des stratégies pour adapter votre contenu d'apprentissage au niveau des apprenants (e.g. segmentation, ...)
- Définir précisément la scénarisation de votre dispositif (qui? quand? où? comment? pourquoi? ...)
Projet 15 / Tâche
Dispositif
Créez une nouvelle version de l'exercice de votre choix en suivant les contraintes spécifiques pour cet exercice, plus les améliorations indiquées plus haut.
Modalités de rendu selon le type d'exercice choisi :
- Si vous choisissez un exercice qui prévoit la publication de fichiers sur le serveur tecfaetu.unige.ch, publiez les nouveaux fichiers HTML5/CSS/JS vidéo, etc. dans un autre dossier
- Si vous choisissez un exercice lié à Moodle, créez un nouveau élément dans la section que vous avez à disposition et labellisez l'élément afin qu'on puisse l'identifier facilement (e.g. Deuxième version du ..., Version pour l'exercice 15 du ..., etc.)
Contraintes
- Vous pouvez choisir parmi tous vos exercices de STIC I et STIC II, sauf l’exercice 1 de STIC I.
- Vous devez respecter toutes les contraintes qui ont été données pour l’exercice de référence.
- Vous avez une certaine flexibilité en ce qui concerne les modifications, c’est-à-dire que vous ne devez pas forcement réutiliser tous les éléments que vous avez créés pour la première version de l’exercice. Cependant, il faut maintenir une certaine continuité avec les éléments principaux (e.g. si vous avez fait un exercice sur l’apprentissage d’une langue, vous pouvez à la limite changer la langue, mais pas le transformer en apprentissage de recettes de cuisine…).
- Vous devez clairement identifier les améliorations de manière objective, pas d’amélioration générale/subjective (e.g. "maintenant c’est plus joli").
- Une bonne pratique serait d’écrire d’abord une liste de tous les éléments que vous voyez améliorable, et enfin choisir les plus importants.
- Vous pouvez utiliser des applications de type "To-Do" (avec quelques fonctionnalités en plus) comme par exemple Trello. Vous pouvez séparer les listes en utilisant une méthode style Tableau kanban :
- To-Do : ce que vous voulez faire en ordre de priorité
- In Progress : travaillez juste sur un élément à la fois
- Done : si tout marche et vous êtes satisfait
- Vous pouvez également estimer le temps que chaque modification va vous prendre et utiliser une application de type "Time-Tracker" pour calculer le temps effectif (e.g. Toggl)
Critères d'évaluation
Nous allons utiliser la même grille que d’habitude, mais nous allons bien entendu tenir compte des critères en fonction des améliorations. C’est-à-dire que si vous avez obtenu le maximum des points dans un critère pour votre exercice original, cela ne signifie pas que vous obtiendrez encore le même score. En gros on va être plus sévère sur chaque critère (sauf documentation, voir plus bas) car on s’attend à un dispositif plus abouti par rapport à sa version originale.
Pour la documentation :
- Nous n'allons pas évaluer explicitement le critère de la grille relatif à la documentation (vous aurez tous le maximum des points) car les exercices diffèrent sensiblement par rapport à ce critère.
- Si vous faites un exercice pour lequel vous pouvez améliorer la documentation (e.g. code), nous la considérons une amélioration technique et nous allons en tenir compte dans d'autres critères d'évaluation (e.g. complexité, qualité technique, ...). SVP spécifiez clairement dans le rapport si vous avez amélioré la documentation.
Rapport
Faites un rapport selon les guidelines habituelles :
En particulier pour cet exercice :
- Dans la section Liens doivent figurer :
- Le lien à la première version de l'exercice (seulement dispositif final, pas fichiers, etc.)
- Tous les liens demandés par l'exercice original et qui pointent aux nouvelles versions
- Divisez la section Objectifs en au moins deux sous sections :
- Une section pour les objectifs spécifiques de votre dispositif (que vous pouvez maintenir depuis la première version si vous êtes satisfaits de ce que vous avez écrit)
- Une section dans laquelle vous illustrez les objectifs d'amélioration
- Divisez la section Design en au moins deux sous sections :
- Une section "traditionnelle" dans laquelle vous explicitez le design de votre dispositif
- Une section "comparative" dans laquelle vous énoncez les changements apportés en fonction des améliorations identifiées plus haut
- Dans la section Production énoncez comment vous avez apporté les modifications envisagées dans les objectifs (ne répétez pas la partie de comment vous avez produit le dispositif en premier lieu)
- Dans la section Auto-évaluation concentrez-vous sur les effets des améliorations
Contribution Wiki
Pour la contribution Wiki également on vous demande de reprendre/finaliser des pages déjà existantes, notamment si vous en avez créées vous-mêmes pendant l’année. Concentrez-vous sur une page plutôt que faire plein de petits changements, et là aussi essayez de déterminer des objectifs à l’avance :
- Rendre la page plus « lean » (e.g. organisation en section, titres des sections bien choisis, ...)
- Ajouter du contenu (pas forcément textuel, penser à des schémas, des cartes conceptuelles, etc)
- Modifier du contenu pas assez clair ou spécifique
- Enlever des parties inutiles/plus à jour
- Choisir des catégories adéquates
- Trouver des pages liées et insérez des liens hypertextuels à des endroits utiles
- Etc.
La page ne doit pas être liée à l'exercice de référence
Délai
Cette date n'est pas négociable car nous devons rendre les notes au secrétariat. Elle est donc valable également pour tout exercice non rendu pendant le semestre.
Attention : si vous ne rendez pas un ou plusieurs exercices avant cette date, ou vous rendez un ou plusieurs exercices après cette date, ils seront automatiquement notés avec un 0. Pour éviter ceci, vous devez nous annoncer (email à M. Schneider, en copie Mattia et Stéphane) que vous vous inscrivez à la session de rattrapage. Toute exercice rendu pendant la session de rattrapage est pénalisé d'un point sur la note finale, cette pénalité peut être évitée en concordant un travail supplémentaire avec M. Schneider (voir la page du cours pour plus d'info).
Ressources
Pour en savoir plus sur la méthode Agile :
- Manifesto for Agile Software Development
- What is scrum
- Extreme programming
- Agile software development (MOOC sur EdX)
- Voir également le livre Meyer, B. (2014). Agile! The Good, the Hype and the Ugly. Springer