ZEP-31 : les parcours de connaissances

Les parcours de connaissances sont un moyen d'agréger du contenu pour former un tel ensemble. Dans la suite, nous construirons la notion de parcours de la même manière qu'on en créerait un.

Initier un parcours

• On cible un lectorat, un point de départ, avec des pré-requis fixés.
• On définit un point d'arrivée, c'est-à-dire un ensemble de connaissances qu'aura acquises le lecteur.
• L'arrivée est restreinte, comme dans un tutoriel : on ne cherche pas à apprendre les Maths de A à Z par exemple.

Des exemples d'intitulés de parcours :

• Créer son site Web avec PHP et MySQL
• Domotiser sa maison avec une RPi
• Le calcul scientifique en Python

Agréger des contenus

• Tutoriel (ou partie, chapitre, section de tutoriel).
• Article (ou section d'article).
• Sujet sur le forum. Par exemple, un projet qui utiliserait la technologie enseignée.
• Message sur le forum. Par exemple, l'énoncé du défi de Dominus.
• Contenu extérieur, parce qu'on manquera de contenu pour constituer un parcours, qu'il y en a de qualité ailleurs et qu'il n'est pas utile de les reproduire sur ZdS. De plus, c'est en quelque sorte un moyen de collaborer avec des personnes extérieures, de ne pas se cloîtrer, et de faire découvrir d'autres sources d'enseignement.

Guider le lecteur

• Un parcours est un graphe orienté : les contenus sont les sommets, les arêtes représentent la manière dont interagissent deux contenus
• Arête « nécessité » : tel contenu est nécessaire à tel autre
• Arête « utilité » : tel contenu est utile à tel autre
• La nécessité implique l'utilité
• Si A est nécessaire à B, B ne peut l'être à A

Merci pour vos retours.

Je suis absolument contre la réutilisation d'extraits, de chapitres ou de parties de tutoriels. Si on regarde bien, l'idée retombe sur le problème qu'elle doit résoudre : chaque extrait/chapitre/partie importée nécessite aussi des pré-requis pour être comprise, qui sont eux-mêmes potentiellement localisés dans d'autres extraits/chapitres/parties, et ainsi de suite. On ne fait que reporter le problème un peu plus loin, d'autant plus que devoir utiliser ce genre de réutilisation est surtout signe d'un public de lecteurs mal cerné, d'un défaut de structuration du plan de cours. Je suis persuadé que réutiliser des extraits donnera des cours dont le plan sera tout sauf cohérent. La seule solution crédible, de mon point de vue, est de renvoyer le lecteurs vers un tutoriel/article indépendant qui explique convenablement les pré-requis.

Par contre, je suis pour les parcours, mais je ne vois pas ce que cela apporte comparé à une simple fusion de tutoriels. A mon sens, intégrer des mini-tutoriels dans un big/moyen tutoriel devrait largement suffire pour 90% des cas où un parcours est utilisé (du moins, c'est ce que j'observe dans mes écrits, dont beaucoup pourraient être intégrés dans un seul gros tutoriel).

Je ne comprends pas comment tu peux approuver les parcours en refusant la reprise de contenu.

En effet, un parcours est un tutoriel dans lequel certains extraits proviennent de contenus existants. Du coup, il y a bien réutilisation de contenu. Peut-être est-ce le fait de pouvoir réutiliser des extraits qui te gêne ?

Non pas forcément. On peut définir un arbre orienté, liants les tutos entre eux. Ainsi avec les noeuds parents tu peux dire au début "ce contenu suppose que vous avez lu les cours suivants" et à la fin il peut préciser "Vous pouvez continuer votre formation par tel tuto ou tel tuto".

Un parcours serait alors simplement un chemin dans cet arbre : une suite logique de tuto pour aller d'un point A (les connaissances du lecteurs) au point B (ce qu'il veut connaitre).

Pas besoin de reprendre le contenu, on peut simplement les lier entre eux.

C'est justement l'objet de la ZEP que je mentionne en conclusion, et ce qu'artragis m'a fait remarqué en MP. Seulement, comment seraient liés les tutoriels « La conjugaison de l'allemand » et « La déclinaison de l'adjectif en allemand » ? Aucun n'est, me semble-t-il nécessaire à l'autre, ni utile à l'autre. Je pense alors qu'un arbre ne donnerait pas d'ordre précis pour apprendre l'allemand depuis zéro. Un parcours si.

Bah un parcours peut contenir des chemin parallèles des endroits ou il faut plusieurs items indépendant.

Apprendre Django nécessiterait les base de python et du HTML, deux notions indépendante mais nécessaire.

Je me disais que non justement. Un parcours est linéaire de sorte à ne pas contenir d'ambiguïté à propos de l'ordre de lecture. C'est probablement ce que souhaite un débutant, non ?

C'est je pense ton problème. L'idée a le mérite d'être originale et pensée pour ZDS, mais je suis contre car elle va à l'encontre de l'idée d'un parcours par étape.

Quand on présente un ensemble large de connaissances j'ai tendance à penser qu'on n'a que deux choix: Editorialiser, et faire d'immenses big tuto ou bien abandonner la structure linéaire.

Les deux extrêmes sont le livre de 1000 pages indigestes et Wikipédia.

L' expérience du sdz a montré que si les bigtuto (curseur plutôt vers une édition linéaire) sont populaires ils ont deux limites majeures. Ils sont très longs à produire et ils réduisent la capacité de recherche.

A l' heure actuelle, nous semblons nous diriger vers un modèle hybride où des tutoriels de longueur moyenne côtoient une forêt d'articles de découverte ou sur des niches. Le curseur de zds est donc plutôt dans le sens d'une delinearisation du contenu.

Je suis contre ta proposition.

Les deux systèmes peuvent cohabiter, non ? C'est d'ailleurs pour ça qu'il y a la ZEP sur la cartographie des connaissances (bientôt).

En effet, il me semble plus pratique, pour apprendre Python, d'avoir un parcours linéaire qu'une série d'articles à la Sam&Max, surtout si je suis jeune et que je n'ai pas l'habitude d'apprendre en autodidacte.

L' expérience du sdz a montré que si les bigtuto (curseur plutôt vers une édition linéaire) sont populaires ils ont deux limites majeures. Ils sont très longs à produire et ils réduisent la capacité de recherche.

D'où la possibilité d'inclure du contenu (partage du travail d'écriture) et un découplage des extraits et des tutoriels (opérations sur les premiers : recherche, mise en relation…).

Pourquoi pas mais je pense que ta notion de cartographie des connaissances (qui est probablement plus proche de ce que nous on considère etre un parcours) est plus importante et surtout plus facile a mettre en place que des inclusions de tutos les uns dans les autres.

Pour moi la possibilité de définir des chemins dans une cartographie des connaissances (arbre orienté du contenu), c'est la premiere itération des parcours.

Ensuite il sera toujours temps de voir pour considérer la création de contenu hybride avec du contenu qui en contiennent d'autres. Mais c'est pour moi moins important.

Le plus important c'est de pouvoir guider les débutants. Avec un arbre du contenu on pourrait imaginer pleins de trucs sympa :

1
2
3
4
5

Q: Que souhaite apprendre ? 
R: Créer un blog de A à Z

Q: Que connais tu déjà ?
R: Uniquement les bases de Python

A partir de ces questions génériques et des listes de choix, on peut générer une réponse type :

"On te conseil d'apprendre les bases du HTML puis de passer au framework Python de ton choix : Django, Flask, … que tu pourras compléter en parallèle par le tuto sur MySQL"

J'aime beaucoup la conclusion claire de SpaceFox (i.e. un cours a des relations entrantes et sortantes mais il n'existe pas de vue globale au sens parcours ou cartographie) qui serait en effet une implémentation intéressante de carnet de route pour l'utilisateur.

Cela dit, j'aime bien l'idée de la carte sans trop savoir ce que représenteraient les liens au sein d'une carte. Parce que y'a vraiment l'idée de se repérer. C'est con mais "vous êtes ici" (en train de lire l'intro à Python) si vous prenez la troisième à droite "rue du web" vous arrivez à construire un site web en python (cours Django), ça me "parle" bien.

Si ça s'adapte bien à cet exemple simple, on voit que décrire un lien entre deux cours n'est pas si simple. Parfois c'est une progression technique, parfois pas.

C'est sûr que l'approche de SpaceFox est bien plus facile à implémenter (au moins certains points). Pour autant je pense que derrière la modélisation d'un parcours de connaissance (carte ? questionnaire comme le décrit Kje ?) y'a une vraie killer-feature.

Recenser des technos c'est difficile et on s'y perd. On sent que c'est LE truc avec lequel les débutants ont un mal de chien, trouver la bonne techno, le bon cours ou un ensemble de technos/cours pour un besoin donné. On l'a fait, on l'a vu. Le mec qui doit passer par la case html, css, php, MVC, cron, websockets pour arriver à son besoin final aurait besoin d'être bien guidé. Et si on prend l'exemple de la carte, s'il sait que les websockets traînent quelque part dans la section web, pas très loin du javascript, de node, que ça gravite autour quoi, y'a des chances pour qu'il aille voir si ça ne peut pas l'aider à s'intégrer dans la solution à son problème.

C'est un sujet vraiment vraiment difficile à traiter :\

C'est sûr que l'approche de SpaceFox est bien plus facile à implémenter (au moins certains points). Pour autant je pense que derrière la modélisation d'un parcours de connaissance (carte ? questionnaire comme le décrit Kje ?) y'a une vraie killer-feature.

Avant de parler ce ça, pour que tout soit clair, peu importe qu'on parle des inclusion ou de la carte, il y a des questions à se poser. Il suffit de voir le message de spacefox sur les technique d'e-commerce pour comprendre que si on répond aux questions qui suivent d'une manière totalement différente, on ne pourra pas forcément appliquer grand chose.

• Qui est le cartographe/créateur du parcours? Est-ce l'auteur qui dit "mon cours nécessite le cours XXX" ou bien les validateurs qui renseignent la carte?
• La cartographie/parcours est-elle une fonctionnalité du site ou bien de son ecosystème (applications/extensions)?
• La question à laquelle nous répondons est-elle "Où en suis-je?" ou bien "Comment je dois faire ce que je veux faire?" ("je" est un débutant qui veut trouver des renseignement dans nos tuto)
• Les tutos sont-ils la seule composante des parcours (ateliers sur les forums? projets communautaires? articles? tribunes libres (aka serpent de mer de zds)?…)

Je ne préfère pas commencer à détailler des solutions techniques (bien que j'ai des tonnes d'idées à ce propos) tant que ces questions n'auront pas de réponse.

Les propositions de SpaceFox peuvent très bien etre implémentés en première approche. Ça va obliger a alimenter les liens entre contenu. Une fois ça en place on pourra regarder les données et voir comment on peut lier le tout dans un grand ensemble. Après, que ces liens soient exploité avec des questions/réponses ou une carte, c'est un autre problème, de l'exploitation de données.

Autant commencer simple.

Vous avez raison : imposer à un parcours d'être linéaire est stupide. Néanmoins, je pense que cette ZEP à quand même lieu d'être, mais sous une autre forme.

En effet, la ZEP-32 vise à spécifier rigoureusement des relations entre les contenus en vue de guider le lecteur et, sur le long terme, d'un traitement automatique. Mais je doute que l'on parvienne à gérer toutes les possibilités d'ordre de lecture avec ces relations. Par exemple, rien de particulier ne relie certaines parties du programme de Maths de Terminale S si ce n'est qu'elles appartiennent au programme de Maths de Terminale S. Du coup, a priori, aucune relation définie par la ZEP-32 ne permettra de relier les composantes du programme. Le même problème se pose pour la prise en main rapide du protocole WAMP.

Les parcours de connaissances seraient donc des graphes orientés dont les sommets formeraient une unité de savoir cohérente i.e. dont la lecture permettrait de satisfaire une demande particulière. Ainsi, un tutoriel serait simplement un parcours linéaire, dont tous les sommets ont été écrits par le(s) même(s) auteur(s).

Qu'en pensez-vous ?

La ZEP-32 vise à établir les relations que tu mentionnes, i.e. s'intéresse, entre autres, aux six points que tu cites. Mais qu'en est-il des packs et des séries ? Des relations fixes permettent-elles de regrouper les contenus sémantiquement et de créer des parcours du genre « Administrer son site Web avec PHP et MySQL », « De la domotique avec la RaspberryPi », « Le calcul scientifique en Python » ?

Autrement dit, les six points (ZEP-32) permettent-ils de mettre en place des packs et des séries (ZEP-31) ?

Révision totale de la ZEP. Il y a encore beaucoup de choses à spécifier mais, comme indiqué en conclusion, je préfère déjà voir si on est d'accord sur la problématique et si la ZEP-32 n'englobe pas celle-ci.

Est-ce que cette ZEP est morte ?

Je trouvait l'idée vraiment intéressante.

Dans les grandes écoles il y a souvent un certain nombre de cours pas toujours parfaitement articulés entre eux, qui peuvent être reliés par des liens à la Zep-32. Ensuite, la direction de l'école propose des parcours liants ces différents cours pour mener à un point plus précis. On a quelque chose qui est moins rigide qu'un big-tuto/cours, et un cours peut tout à fait servir à plusieurs parcours

Ici, un parcours pourrait être un chemin dans le graphe de la ZEP-32. En pratique on pourrait avoir les arêtes du graphe indiqué au début et à la fin du tutoriel (respectivement pour les arêtes pointant vers le tuto, ou autant du tuto) et à coté un label/symbole indiquant le parcours.

On pourrait aussi avoir une page résumant le parcours, avec le graphe du parcours, et les parcours pourraient être listé sur une page à part.

Sur le plan technique cela peut demander un peu de reflexion, mais le concept émérite vraiment qu'on s'y intéresse.

Est-ce que cette ZEP est morte ?

Non, faut juste que je me bouge le derche.

Ici, un parcours pourrait être un chemin dans le graphe de la ZEP-32.

C'est la question en fait : un parcours est-il nécessairement un chemin dans le graphe de la ZEP-32 ?

Il me semble que non, mais peut-être qu'en définissant des relations judicieuses, on peut gérer tous les cas.

Hier, je réfléchissais à un tutoriel sur la Beaglebone Black (BBB) et je me suis fait la remarque qu'y inclure des leçons d'électronique comme dans le tutoriel Arduino ne serait pas productif vu que répéterait ce dernier. L'idéal serait alors d'avoir trois tutoriels :

• L'électronique de zéro
• Arduino pour les électroniciens
• BBB pour les électroniciens

Et c'est là qu'intervient la notion de parcours : en piochant dans les extraits des deux premiers tutoriels, on en obtiendrait un de la forme de celui du caribou.

Voilà. C'était juste pour donner un autre exemple de parcours, qu'on avait sous les yeux depuis le début. Mais se pose tout de même la question de la fluidité : je ne suis pas sûr que le parcours décrit ci-dessus soit aussi agréable à lire que le tutoriel d'Eskimon.

Peut-on vraiment assembler des extraits comme ça et obtenir un tutoriel agréable ?

Pour moi, non, sauf si ça avait été réfléchi comme tel depuis le début (parce que les extraits se font souvent références l'un l'autres et qu'il y a plusieurs manière d'aborder et de découper un sujet). Après, je pense que enchaîner des chapitre aurait déjà un peu plus de sens, et enchaîner des parties en aurait encore plus.