Optim - Dokiel - Opale

Besoin identifié :
Comme il n’y a pas de « place des évolutions » pour Dokiel, je poste ici.
Dans le même ordre d’idée que la discussion Insérer "Texte à trous" dans un grain de contenu - #13 par sylvain.p, je me posais la question de l’interaction possible entre Dokiel et Opale, je m’explique sur 2 cas.
1- J’utilise Dokiel pour réaliser des tutoriels ou des supports de formations. En fin de chapitre, j’aimerais pouvoir évaluer la compréhension des personnes sur ce qui a été vu.

2- J’ai récupéré un texte juridique très long avec lequel j’ai généré ± 200 fragments de contenus dans OptimOffice. En voulant réaliser un support de formation, je me suis rendu compte que la réutilisation de fragments Optim n’était pas possible dans Dokiel.
Partant de ce constat, j’ai refais tout le boulot dans Dokiel (copié/collé des textes !). Je suis sans doute un peu abruti / je n’ai pas réfléchi avant (ce qui revient un peu au même :wink:) / je n’ai pas trouvé comment faire (entourer la bonne réponse :stuck_out_tongue_winking_eye: )

Évolution proposée :
Pour le cas 1, l’intégration de questions rédigées dans Opale est-elle / pourrait-elle être possible/envisageable ?

Pour le cas 2, peut-on / pourrait-on réutiliser des contenus Optim dans Dokiel et/ou inversement

Interrogation « naïve » : pourquoi avoir « compartimenté » les usages du logiciel en limitant les capacités d’intégration d’items entre les différents modules, alors que la réutilisation « transparente » entre eux pourrait apporter une véritable souplesse et décupler la création des utilisateurs.

NB : en fait, après une période de découverte des possibilités de chaque module, je découvre maintenant des fonctions plus avancées, avec la version serveur, comme les liaisons inter-ateliers ou les calques de dérivation. Ça ouvre des perspectives immenses, mais je me retrouve « frustré » par une réutilisation restreinte des contenus entre des ateliers qui ont été produits avec des modules différents.

Conclusion
J’aimerais pouvoir réutiliser des contenus (textes, questions…) entre Optim, Dokiel et Opale.

Salut, je passe le sujet sur la catégorie Dokiel car en effet c’est plus un sujet centré sur Dokiel.
Il n’y a pas de place des évolutions Dokiel. Kelis, qui édite Dokiel, le fait évoluer en fonction des retours des utilisateurs.

Un élément de réponse sur ta question « naïve » : chaque modèle a des spécificités liées à son métier. Par exemple dans un grain Opale, tu vas avoir des balises pédagogiques. Elles ne font pas partie du modèle Dokiel ou Optim. Dokiel a des blocs métiers (concept, …) qui n’ont pas de sens dans Opale ou Optim…

En plus il y a certaines spécificités comme le filtre « version standard »/« version courte » sur Opale, ou les exclusions selon le support avec Optim.

On pourrait imaginer un outil sous forme de moulinette ou extension qui permettrait de transformer un contenu Opale en contenu Dokiel. Mais il faudrait que quelqu’un se lance dans le codage.

Tu penses bien que ma question n’était pas tout à fait « naïve » à propos de certains items :wink:.

Je pense en effet que plusieurs d’entre eux auraient vocation à être réutilisables dans tous les modules : un concept, une définition ou une référence (web, bilio…) ont la même signification quel que soit le module (même si leur appellation interne peut avoir des cibles différentes). C’est bien sur ce type d’item que porte ma réflexion. Autres exemples :

  • un fragment dans Optim a la même utilisation qu’un fragment dans Dokiel
  • un arbre de concepts dans Optim est l’équivalent d’un arbre synoptique dans Dokiel
  • un exercice interactif dans Dokiel propose les mêmes items qu’une activité d’auto-évaluation dans Opale

Si des items possèdent des finalités similaires dans chaque module, il serait intéressant de pouvoir les utiliser dans chaque module « compatible » avec ce type de besoin/utilisation.
Ainsi, des paragraphes de texte, des définitions, des concepts, des cartes heuristiques, des séquences d’évaluation pourraient faire partie d’un « module central » de Scenari (sorte d’atelier public, de « pot commun ») qui serait accessible aux autres modules pour la réutilisation des contenus.
Cela aurait le double avantage de permettre un travail unique pour plusieurs types d’utilisations (éviter les copié/collé entre modules) et d’éviter le développement de « moulinettes » de conversion toujours problématiques à maintenir (compétences + temps).

Pour les fonctionnalités propres à chaque module, il semble peu envisageable en effet de pouvoir les transposer, mais c’est justement ce qui fait la pertinence de chacun d’eux (variété des besoins/usages/métiers).

L’intention initiale de ce message est de mieux comprendre la philosophie de ce formidable logiciel (plus je fouille dans les documentations, plus je trouve des fonctionnalités de dingue !) et de vouloir participer à son évolution fonctionnelle en simplifiant les usages. Mais je suis peut-être aussi complètement à côté de la plaque : je déboule avec mes questions à la noix après 20 ans de développement logiciel ( :clap: aux dév de Kelis), et j’aurais l’audace de tout remettre en question, quelle prétention :stuck_out_tongue_winking_eye:

Si néanmoins je peux être utile…

Je vois bien ce que tu veux dire.
Le souci aussi je pense, c’est que plus c’est interconnecté, plus c’est difficile de faire évoluer. C-a-d que lorsqu’on fait une évolution d’un item mobilisable dans plusieurs modèles, il faut avoir en tête et prévoir l’impact dans ces différents modèles.
J’imagine que Kelis s’est déjà posé ce genre de question. Poke @spi

En effet, l’interdépendance entre les modèles pose une très grande difficulté d’évolutivité du système.

Mais le problème plus fondamental est que certes le concept de « biblio » ou de « fragment » peut être similaire d’un modèle à un autre, mais leurs « schémas internes », à savoir ce que contient ces objets dans chacun des modèles est différent (par exemple le détail de ce que propose chaque texte riche en terme de balisages, de métadonnées, etc). Ils ne sont donc pas interchangeables et utilisables de façon transparente d’un modèle à un autre. Et même si dans un cas particulier ils le seraient on ne souhaiterait pas favoriser et instrumenter cette possibilité par rapport à l’enjeu d’évolutivité et d’indépendance entre les modèles évoquée précédemment… la boucle est bouclée :wink:

1 « J'aime »

Je comprends bien les problématiques techniques et la volonté de conserver une indépendance entre les ≠ modèles.
Cela a pour conséquence de « figer » l’utilisateur dans un modèle dès qu’il a fait un choix et qu’il commence à l’utiliser. Cela induit donc une certaine rigidité dans le temps, qui peut être regrettable si le choix ne se révèle pas pertinent dès le départ. Il faut le savoir dès le début pour ne pas à devoir refaire le travail une seconde fois (ce qui m’est arrivé comme je l’ai indiqué dans mon premier message).
Je suggère de proposer aux « nouveaux arrivants » un tableau comparatif des modèles pour illustrer leurs réponses aux besoins ou aux usages.

Dans un second temps, un outil de conversion serait bien utile, à condition que les besoins utilisateurs soient à la hauteur de l’investissement de développement nécessaire.

Merci pour toutes ces précisions.

Effectivement, une « passerelle » serait un réel plus et a contrario, je pense que Dokiel fait « une erreur » en proposant un export SCORM qui ajoute de la confusion.

Opale et Topaze sont les deux seules chaînes éditoriales dédiées à la formation.
Encore une fois, la frontière est très mince et je ne dis pas qu’il faut dégrader les fonctionnalités de Dokiel.
Je pense (j’ai peut-être tort) que chaque modèle a sa fonction et il n’existe, à ce jour, aucun modèle universel.

Si nous devions être stricts dans les utilisations, nous devrions utiliser Dokiel pour la rédaction technique et Opale/Topaze pour la formation (présentielle ou non).
Encore une fois, je suis le premier ravi (et en même temps pas content) que Dokiel permette de créer du contenu formatif, mais dès que je veux utiliser une autre ressource formative ou créer des questions (QCU, QCM…) je dois tout refaire sous Opale (ou Topaze).
Alors j’ai pris el parti de spécialiser mes utilisations en utilisant chaque modèle rédactionnel en fonction du besoin (Dokiel : rédaction technique ; Opale/Topaze : formation).
Je vais un jour oser tester Rubis, mais chaque chose en son temps :slight_smile:

Après je ne prétends pas avoir la science infuse ni être le roi de la bonne pratique ; je me permets juste de partager ma réflexion.

Je ne comprends pas cette remarque, Dokiel permet de créer des QCU des QCM etc.

L’enjeux de l’extension Training de Dokeil est de pouvoir créer des ressources pédagogiques en utilisant les MÊMES ressources techniques natifs de Dokiel qui ont déjà été produit pour la documentation.

Merci Sam.
J’avais bien compris l’enjeu :slight_smile:
Pour ce qui est des questionnaires, pour une raison qui m’échappe, je n’avais pas l’option proposée lors de la création d’items sur SC5.
J’attends que l’informatique interne m’installe SC6, car c’est la version que j’utilise à titre perso et je dois changer tous mes réflexes pour passer de l’une à l’autre !

Le but premier de Dokeil est de créer de la documentation technique, mais il est souvent nécessaire de générer des formations à l’objet technique sus-documenté. quoi de plus cohérent que de pouvoir re-utiliser des briques primaires de la documentation dans la formation comme par exemple des images augmentés, les concepts, les procédures etc.
Pourquoi forcer un rédacteur technique à utiliser un autre modèle documentaire qui ne contient pas les objets métiers dédiés ?

1 « J'aime »

La partie training existe depuis dix ans au moins, il suffit d’activer l’extension sur votre atelier :
image
Vous avez alors accès à :
image

C’est l’éternel débat.
Après c’est justement la raison pour laquelle il y a des logiciels auteurs (donc pour écrire les formations).
Les deux points de vue se défendent et chacun a des points forts et des points faibles.
Merci pour le complément sur l’activation de l’option.

C’est bien toute la problématique que je voulais exprimer dans mon message initial, celle de pouvoir utiliser des contenus « bruts » (c.a.d.de l’information) agrégés dans un socle commun, pour ensuite pouvoir réutiliser cette matière dans des circonstances différentes (rédaction d’un document, site Internet, documentation technique/juridique, formation…).

Je suis d’accord avec @coursenligne que le débat pourrait être interminable sur les avantages et les inconvénients de chaque point de vue (concept centralisé ou modules séparés ayant certaines fonctionnalités identiques).

Je ne souhaitais pas mettre de l’huile sur le feu, mais au moins faire prendre conscience du potentiel « emprisonnement » de l’utilisateur dans un modèle documentaire lorsque le choix initial a été fait (peut-être par manque de connaissance des possibilités de chaque modèle).

Il y a des centaines de situations ou il faut concevoir des formations dans des contextes tous très différents. On de travaille pas de la même manière avec des étudiants ingénieurs, des étudiants en langue, des lycéens, des collégiens, des élèves de primaires, des techniciens professionnels suivant une formation technique à l’usage de machines-outils, etc.

Nous concevons donc les modèles documentaires non pas pour tenter de répondre à des besoins très génériques comme « documentation » et « formation » mais de façon bien plus ciblée. Utiliser Opale pour tous les exemples ci-dessus ça n’a pas de sens, Opale est conçu à la base pour produire des cours dans l’enseignement supérieur, Canoprof est conçu pour le primaire et le secondaire, Dokiel pour la formation technique. Vouloir tout faire avec un seul outil résulterait dans un modèle Frankenstein proposant à tout le monde ce qui ne leur est pas adapté.

1 « J'aime »

Faire des passerelles entre les modèles serait en effet une piste à creuser. Mais la migration d’un modèle vers un autre ne pourra jamais être faite sans perte.

Il y eu dans le passé des « passerelles » entre Quezal et Opale, permettant l’usage d’un quiz Quezal directement dans Opale, c’est un exemple pour dire que cela peut être techniquement possible.

La difficulté réside dans le financement et surtout le maintenance de tels passerelles.

Il semble que le sujet soit assez récurent sur le forum (lire Transformation Opale vers Dokiel - #12 par Ariane)

Les précisions de @sam sur le choix d’un modèle sont exprimées dans la présentation générale de Scenari, et merci de le rappeler.
Néanmoins, comme je l’évoquais précédemment, un tableau comparatif des utilisations et/ou fonctionnalités de chaque modèle pourrait aider le néophyte (ou l’utilisateur avancé qui fait face à un besoin particulier) à choisir celui qui serait le plus adapté à ses besoins.

1 « J'aime »

C’est la crainte que j’exprimais hier.

Bonjour,

On en parlait encore récemment ici, ça devrait arriver dans une prochaine de scenari.software :wink:

1 « J'aime »