Discussion:Plateforme pédagogique/Feuille de route

Vous pouvez cliquer sur "ajouter un sujet" ci-dessus, auquel cas mettez "Nom (date)" dans le sujet.

Vincent (16/10)

Utilisateurs : tous les enseignants intéressés

Peut-être indiquer qu'il faudra se créer un compte pour ça et que l'ouverture de compte est sans validation de notre part.

d'organiser les cours qui y sont publiés

Pourrais-tu détailler ça ?

Ces visiteurs incluent notamment

Les visiteurs ont accès en lecture à tout le contenu.

Vu et intégré (Naji 16/10 15h20)

Lionel (16/10 22h45)

Bravo pour la feuille de route ! Après lecture détaillée, ca m'a bien éclairé.

Je me pose une question sur la manière d'enchainer les étapes jusqu'a la beta : Est ce qu'il ne serait pas intéressant d'aller chercher plus tot un feedback utilisateur ? Et donc de suivre le cycle qui est décrit, mais en le répétant sur un périmètre fonctionnel incrémental ?

Par exemple (ce n'est qu'un exemple, c'est lors de la définition des parcours que l'on pourrait faire l'exercice de priorisation/lotissement) :

• on commence par définir l'identité visuelle du site et le contenu statique (=le parcours "accueil visiteur"), on pousse ca en beta, devant des testeurs (enseignants volontaires pour donner un avis, UX, etc...) => collecte d'un premier feedback, on peut corriger directement
• puis on met en place le parcours de saisie/consultation des cours => même chose, sauf que les testeurs connaissent deja un peu le site, ils peuvent donc se concentrer sur les nouvelles features
• puis on travaille sur les forums , etc...

Le feedback plus en amont nous permet de corriger au plus tot et de s'orienter rapidement dans la bonne direction. On peut aussi de paralléliser un peu plus, car on "utilise" les profils de types enseignants, designer des le début

Et une deuxieme question, qui serait peut-etre à ajouter dans les "questions de fond"

J'utilise moodle à la fac, en tant qu'enseignant...et en première approche c'est assez peu intuitif. En particulier parce qu'il y a plein d'options / plugins activés, et qui ne servent jamais.

Par exemple il y a plein de facons différents d'ajouter un cours (et beaucoup d'enseignants finissent par uploader leur support en pdf...)

Du coup est ce que l'on n'a pas intérêt au début à désactiver le plus d'option/plugin possible pour que l'essentiel ressorte ?

Benjamin (22/10 15h30)

Hello ! Bravo Naji pour la feuille de route.

Je rejoins Lionel sur le côté incrémental, plutôt que d'essayer dès aujourd'hui d’être exhaustif sur l'ensemble des fonctionnalités à implémenter. On pourrait s'inspirer du modèle des user stories, utilisées assez souvent au sein des équipes agile scrum. Le template est le suivant : "En tant que [X] je veux [Y] afin de [Z]"

Pour la plateforme, cela donnerait : "En tant qu'enseignant je veux accéder à du contenu de formation en ligne sur le climat pour pouvoir dispenser un cours sur le sujet auprès de mes étudiants" Et puis cela serait décliner en : "En tant qu'enseignant je veux pouvoir faire une recherche sur une plateforme regroupant du contenu structuré sur le climat, afin de m'en inspirer (le réutiliser) pour dispenser un cours" "En tant qu'enseignant, je souhaite pouvoir m'inscrire sur cette plateforme afin d'accéder au téléchargement du contenu"

Il y a aurait aussi, "en tant qu'enseignant, je souhaite partager mon support de formation sur une plateforme dédiée afin d'en faire profiter une communauté" ..

Ce sont juste quelques exemples pour te donner l'idée générale.

Il faudrait idéalement identifier de grandes fonctionnalités plus ou moins décrites dans inscription / recherche / partage / commentaire / historique / modération.., découper en lot et prioriser avec un ou deux "représentants métier", typiquement des enseignants qui vont utiliser la plateforme. Cela permettrait comme le dit Lionel d'avoir un fonctionnement en cycle cours dev - test et pouvoir corriger le tir plus rapidement.

Je suis d'accord aussi avec la désactivation du maximum de plugins (quitte à réactiver plugin par plugin si besoin).

Enfin, je pense que la plateforme pédagogique est un genre de réseau social académique, et comme il en existe déjà on pourrait s'en inspirer. On m'a parlé de research gate, c'est pour chercheurs et scientifiques et apparemment c'est pas mal fait. Moi professionnellement, comme je suis ni l'un ni l'autre je n'ai pu avoir qu'un accès "visiteurs", mais avec ce rôle on peut accéder à la recherche...bref ca vaut peut être le coup de creuser un peu le fonctionnement de cette plateforme pour s'en inspirer.

Naji (23/10 13h15)

Merci Lionel et Benjamin !

1) Je vous rejoins sur l'aspect incrémental + tester au plus tôt.

Parmi les fonctionnalités à développer, on peut identifier des groupes de fonctionnalités indépendantes ("orthogonales") des autres groupes. Disons "périmètres indépendants" histoire d'avoir un terme. Ces périmètres indépendants seraient :

• pouvoir s'informer sur l'initiative
  • étape 1 : page d'accueil, pages de présentation ("c'est quoi ?" + "enseignants"), autres pages statiques. Sur la page d'accueil, pour pouvoir mener les tests d'utilisabilité tôt, remplacer les éléments "quelques discussions récentes" et "des exemples de cours" par des contenus figés, pas du tout issus de la base de données.
  • étape 2 : après avoir connecté les éléments de la page d'accueil à des contenus réellement présents sur la plateforme
• en tant qu'enseignant, pouvoir m'inscrire, me connecter, et changer un mot de passe perdu
• en tant qu'enseignant, pouvoir me présenter (profil) et trouver d'autres enseignants (annuaire + profil)
• en tant qu'enseignant, pouvoir partager un cours
• en tant qu'enseignant, pouvoir discuter autour d'un cours (qu'ils gérés par d'autres ou bien par moi)
• en tant qu'enseignant, pouvoir discuter d'un sujet non attaché à un cours en particulier
• (compléter avec les rôles support)

Possible qu'un de ces éléments soit trop grand ou trop petit ou bien pas tant que ça indépendant d'un autre, corrigez-moi svp.

Merci Benjamin d'avoir parlé d'user stories et donné des exemples :)
Si je comprends bien, l'approche consiste à 1) écrire des user stories décrivant des besoins 2) conjuguer ça autour de fonctionnalités qu'on propose de fournir via la plateforme ; une user story se décline hiérarchiquement en plusieurs user stories 3) grouper ces fonctionnalités en périmètres indépendants.
Faute de temps, et parceque j'ai déjà trainé à répondre à Lionel, j'ai rédigé la liste ci-dessus assez rapidement et je n'ai pas fait les exercices 1) et 2). Faire l'exercice complet nous permettrait peut-être de révéler des choses ? Dans tous les cas, je vous invite à corriger/compléter la liste des périmètres.
Au passage, vu vos professions, vous allez peut-être pouvoir m'aider à clarifier mon vocabulaire. Dans la feuille de route et le document de conception, j'utilise le terme "parcours utilisateur" sans en avoir de définition claire, et quand j'ai l'impression que ça ne colle plus trop je passe à "scénarios d'utilisation", puis "cas d'utilisation", et je cycle entre ces termes :p Si vous avez des définitions en tête qui marchent pour vous, je vous invite à les partager svp :)

J'adhère à l'idée de travailler, sur chacun de ces périmètres, en cycles conception-implémentation-test. Ça nous permettra :

• de dire "ça c'est fait" plus tôt et plus régulièrement. C'est bon pour le moral ♫ Il faut garder en mémoire que les tests en phase "on a intégré tous les périmètres ensemble" révéleront de nouvelles choses, mais ça a moins de chances de se produire que si on teste tout simultanément.
• de concentrer les efforts d'un petit groupe
• si les tests prennent du temps (ce qui ne dépend pas de nous), on gagne du temps en commençant à implémenter le périmètre Y pendant qu'on attend les résultats de test du périmètre X, vu qu'ils sont indépendants
• d'introduire le test tôt dans la pratique de l'équipe, ce qui nous fait adresser des incertitudes (avec qui on les fait ? comment on s'y prend, si on a jamais fait de test d'utilisabilité ?) tôt, ce qui est généralement préférable
• que les discussions au cours des tests soit plus riches. Par exemple, si le périmètre du test est "en tant que visiteur, je souhaite m'informer sur l'initiative Enseigner le Climat" et qu'on n'a pas à passer du temps sur la vue "liste des cours", ça nous laisse du temps pour demander "après avoir lu ces pages, quelles questions vous vous posez au sujet de l'initiative ?"

Actions :

• Lionel, Benjamin, et qui veut : retours sur la liste des périmètres indépendants
• X : éditer la feuille de route, en remaniant "vers la beta" en 2 sections "conception initiale" et "cycles conception-implémentation-test". Inclure la liste des périmètres indépendants ci-dessus, éventuellement corrigée.
  • (Naji) je n'aurai pas le temps de m'en charger avant ce week-end

2) Sur les plugins Moodle, je vous rejoins... dans l'idée. Oui sur l'aspect fouillu de Moodle par défaut, je l'ai utilisé aussi en tant qu'étudiant. Et sur mon installation locale, en effet, une de mes premières recherches a été ce qu'on peut enlever.
Il en est ressorti que des plugins Moodle, dans l'installation par défaut, il y en a un paquet (402 !), et leur nommage n'est pas forcément indicatif de ce qu'ils font. En fait, le code source de Moodle 3.7.x est structuré en plugins. Il me semble qu'il serait fastidieux de les désactiver un par un.
Ce qu'on veut, c'est que l'interface apparaisse claire aux enseignants. (Pour les visiteurs, l'idée est qu'ils ne s'aperçoivent même pas que c'est Moodle.) Pour y arriver, je pense qu'il vaut mieux partir de l'interface qu'il y a, et enlever ce qu'il y a de visible dont on ne se sert pas, limiter les façons de se perdre. Ça peut passer par désactiver des plugins, ça peut aussi passer par configurer l'interface pour les enseignants ("tableau de bord" + "blocs") et les empêcher de la changer, ce qu'un administrateur Moodle peut faire.
On dit peut-être la même chose différemment ?

3) S'inspirer de ResearchGate : pertinent ! Il faudra bien distinguer ce qui est utile à une activité de recherche et ce qui pourrait être utile dans notre cas. Quelqu'un a un compte dessus ? Delphine ? Pour ma part j'avais essayé d'en créer un l'année dernière, et vu que je n'avais pas d'adresse mail dans une institution de recherche, ma demande a été refusée. Et les copains thésards ont fini leur thèse :p

Benjamin (23/10 18h)

Hello Naji,

Concernant le parcours utilisateur vs use cases, la différence est pas énorme pour moi donc c'est pas très grave d'utiliser l'un ou l'autre.

A propos des user stories tu as compris le principe;), mais petite précision tout de même : En fait, il faut le voir comme un objet de communication entre le représentant métier (si possible unique), et l'équipe d 'admin/dev moodle. En principe, elles sont écrites par ce représentant métier qui les regroupe dans un backlog (ensemble des users stories ordonnées par priorité). Donc pour moi la première étape, c'est qu'un représentant des enseignants (qui peut selon moi aussi représenter les simple "visiteurs") s'occupe de constituer ce backlog (premier tableau qu'on positionnera idéalement à gauche sur trello) C'est pas très grave si les US du backlog ne sont pas détaillées, mais à minima elles doivent être catégorisées par périmètre et priorisées. Pour la première , on peut évidemment le faire ensemble en remote si vous voulez, idéalement il faudrait 1 métier, les pilotes, toi et moi. Ensuite, on peut démarrer le 1er cycle, c'est à dire définir ce qu'on met dans la version 1 (sprint 1 pour reprendre le jargon scrum). Idéalement ca se fait en séance entre métier et admin/dev. Le but est de constituer le contenu en US du sprint, en détaillant ensemble les US si besoin. Normalement un sprint a une durée fixe...évidemment dans notre cas ca pourra être variable. Mais je propose qu'on essaye de se fixer une durée de 1 mois, ce qui fera une nouvelle version / mois.

Dernière chose sur les user stories, idéalement il faudrait qu'elles respectent le principe du INVEST : https://yodiz.com/help/what-is-i-n-v-e-s-t/