Dans ce dispositif la même question (ou une série de mêmes questions) revient tant que l'utilisateur ne décide pas de sortir. A ce moment il peut enregistrer le suivi qui indique le nombre de questions résolues et le nombre moyen d'essais qu'il a fallu pour cela.

Modèles et variables

La page d'introduction correspond au modèle vtml-1d.xsl qui initialise les variables locales 'cumul' (parent.newLoc('cumul',0)), ['cumul_max', 'suivi',] 'no_qs'. C'est la même que pour les défis. La variable 'cumul' est utilisée pour cumuler le nombre de tentatives infructueuses.

Les questions peuvent faire appel à n'importe quel modèle possédant la variable 'no_rep' et permettant d'aiguiller l'utilisateur:

• vers réponses juste (IDREF=“link” en général) qui va proposer une page adaptée (avec notamment la possibilité de sortir). Il est possible d'utiliser la page util/bc-switch.xml qui automatise la suite. Dans ce cas, il faut implémenter dans la page appelante la variable locale 'bc-suivant' (par exemple <LOC NAME='bc-suivant' VALUE='$mathba1b/ui_1deg1-1.xml'/>, ou “tab_rnd([])” pour tirer un exercice au hasard). La page bc-suivi-ok.htm permet d'enregistrer le suivi.
• vers réponse fausse (IDREF=“msg” en général pourquoi pas error ?) et l'incrémentation de 'no_rep' (le lien vers util/suivi-nok.htm convient).

En liant la page $DOC/util/bc-imsi.htm à l'ancre 'onload', un bref état de situation est fait à chaque chargement.

Pages standard

• bc-suivi-ok.htm (obsolète bcsuivi-ok.htm) : enregistrement du suivi pour le dispositif “en boucle”. (à varier les messages)
• bc-imsi.htm : état de situation pour le dispositif “en boucle” (ancrée dans les modèles IDREF=“onload”)
• bc-switch.xml : feed-back standard et aiguillage (question suivante ou enregistrement du suivi).

Dans ce dispositif, l'apprenant démarre avec un capital de points (constitué de la somme des points des questions à venir). Il répond à une suite de questions (5 ou 6 en général). Les erreurs lui font perdre des points à la question. Lorsque son capital pour la question est épuisé, il est exclu du défi. S'il parvient au bout des questions, un certificat lui est délivré avec la somme des points par rapport au maximum possible.

A noter que cet ancien modèle déroge les règles générales qui offrent des variables de salle (LOC) pour des dispositfs se limitant à quelques activités. En principe, il ne faudrait qu'un défi (sans autres activités) dans une salle. L'introduction de contextes 'super' corrige en partie ce défaut.

Modèles et variables

La page d'introduction correspond au modèle vtml-1d.xsl qui initialise les variables locales 'cumul' (parent.newLoc('cumul',0)), 'cumul_max', 'suivi', 'no_qs' et des variables mieux séparées du reste SUPERmode, SUPERtitre-defit et SUPERcertifiant, grâce à une extension de la notion de contexte:

• <CTXT NAME=“super” SCHEME=“mode” VALUE=“defi”/> (en fait intégré à vtml-1d.xsl)
• <CTXT NAME=“super” SCHEME=“titre-defi” VALUE=“Calcul mental”/>
• <CTXT NAME=“super” SCHEME=“certifiant” VALUE=“CPI-PEC, Fribourg”/>

(obsolète <LOC NAME=“titre-defi” VALUE=“Calcul”/>). (exemple cpi/cpi-cal-def0.xml)

L'introduction du mode est destiné aux modèles qui produisent eux-mêmes l'évaluation (comme flash qui n'utilise pas le nombre d'essais comme mode d'évaluation) sans passer par suivi-ok et/ou le feed-back spécifiques des défis.

Ensuite, il y a alternance de pages de tâches et de feed-back.

Les questions doivent posséder les 'contextes' de contrôle de schèmes:

• [defi (<CTXT NAME=“controle” SCHEME=“mode” VALUE=“defi”/>) obsolète, la page d'intro y procède],
• poids (valeur de la question),
• penalite (ce qui est ôté à chaque erreur, le cas d'estime est un peu particulier),
• nbReprise (en principe il faut s'arranger que le poids reste positif !).

Il faut évidemment utiliser des modèles qui gèrent ces valeurs (qrep-fls.xsl, qrep2-2.xsl, qrep-mult.xsl, qrep-qcm.xsl, qcm-defile et à venir qrep-exp, touchpad.xsl, touchpad2.xsl, qcm-img3,).

A noter qu'une question particulière peut peut-être introduite dans un défi en initialisant les variables 'poids', 'poids_init', 'penalite'.

Elles doivent implémenter un certain nombre de liens:

• vers réponses juste (IDREF=“link” en général) qui va proposer le feed-back.
• vers réponse fausse (IDREF=“msg” en général) annonce réponse fausse et incrémente 'no_rep' (lien vers util/df-msg.htm. par exemple).
• vers bilan intermédiaire (opt.) (IDREF=“onload”) au chargement (lien vers util/df-ims-std.htm par exemple)
• vers sortie (opt.) (IDREF=“exit”) lors les crédits sont épuisés (si non implémenté, l'utilisateur est éjecté sans autre forme de procès) (lien vers util/df-exit.htm par exemple)

La page du feed-back est spécifique à la situation. Pour les autres, il existe des pages standard à utiliser pour le moins lors de la mise en place d'une défi. Les deux dernières sont optionnelles.

Le dernier feed-back doit conduire au formulaire standard util/df-form.xml qui conduit à page du certificat util/df-cert.xml (modèle df-end.xsl) (liée à l'ancre IDREF='envoi' - passage par un script Perl). Cette dernière page charge encore un message de fin util/df-fin.htm. Ces pages remettent le mode à 'standard'. Ces pages peuvent être remplacées par des pages particularisées en tout ou en partie.

util/df-ims-std.htm peut être remplacée par autre chose si on veut une mise en page plus sophistiquée pour le onload. Idem pour util/df-msg.htm et util/df-fin.htm.

Exemple: Voir défi initié par cpi/cpi-cal-def0.xml pour un usage des défauts.

Le feed-back (lié à link lorsque la réponse est juste) doit être implémenté avec le modèle dftml.xsl (fait le cumul, le cumul possible, met les informations dans le suivi, incrémente le numéro de la question ('no_qs').

En cas d'erreur, les pages standards d'erreur déduisent la 'penalite' du 'poids'.

Un tableau (Array) comme variable locale (LOC, liée à la salle) est mis en place pour le suivi (salle.jx, vtml-1d.xsl, dhtml.xsl, df-cert.xsl).

Remarque

• En cas de réalisation d'une sortie non-standard (autre que fin du défi, sortie brutale ou via util/df-exit.htm), il faut penser à remettre le mode à standard (voir util/df-exit.htm).
• Il faut distinguer les modèles qui peuvent indifféremment être utilisés pour les exercices et les défis (qrep2-2, qrep-qcm, qrep-mul) et ceux qui, gérant une partie de leurs messages, “doivent savoir” s'ils font partie d'un défi ou non (qrep-fls, qcm-defile et à venir touchpad.xsl, touchpad2.xsl, qrep-exp, qcm-img3). Pour ces derniers modèles le lien 'msg' n'est pas à implémenter. Ces modèles sont en principe ceux pour lesquelles l'unité de réponse est une suite d'items.
• Conséquence de la remarque précédente, il faut faire tous les items, même si les erreurs accumulées avant la fin rendent l'exercice non réussi (et la sortie du défi). A voir si la sortie ne devrait pas être provoquée dès que le crédit a été épuisé.

Pages standard

• df-imsg.htm, df-imsh.htm : bilan complet (Question, points, nombre d'essais, pénalité) sous forme chiffrée et avec symboles. (IDREF=“onload”)
• df-imsg2.htm, df-imsh2.htm : bilan simple (sans chiffres)
• df-imsi.htm : (IDREF=“onload”)
• df-imsi2.htm :
• df-msg.htm : message d'erreur (IDREF=“msg”)

Ce dispositif permet à l'utilisateur de parcourir un certain nombre de domaines et de recevoir à la fin du parcours le niveau atteint dans chacun d'eux.

Le créateur doit décider des domaines à passer en revue dans la page d'introduction (contexte …). Les questions (composées d'items) ont un niveau de difficulté noté (correspondant à une désignation sous forme d'objectif). Pour chacune d'elle le niveau de réussite est apprécié en fonction d'une nombre de tentatives nécessaires pour obtenir les bonnes réponses ou du nombre d'items réussis.

Il est prévu de prévoir une gestion centralisée. La première version suit néanmoins la philosophie première de l'approche document.

L'introduction (voir corref/test-diag-0.xml) de modèle vtml-1t.xsl, initialise les modules qui font partie du test. Puis, il est fait appel à la première question. Il initialise la liste des modules, indique le nom du test et l'institution certifiante.

Chaque question doit satisfaire les conditions suivantes:

• Utiliser un modèle qui fournisse le système poids / pénalité
• Introduire comme variable locale l'identification du module et l'incrémentation du niveau en cas de succès (pourra se faire ultérieurement par contexte) et, le cas échéant le nombre de fois que

l'activité pourra être reprise (à distinguer des reprises en cours d'activité).

• Contenir 3 liens obligatoires: link (question réussie), exit (échec), msg (message d'état intermédiaire, liaison standard: util/td-msg.htm) et un conseillé: onload (bilan intermédiaire: liaison standard util/td-bil.htm)

L'ui liée à link (réussite) de modèle td-tml.xsl, met à jour l'information concernant le module et sert d'aiguillage pour la suite (question plus difficile ou changement de module, par exemple).

L'ui liée à exit (échec) n'a rien à mettre à jour (modèle ). Par contre, c'est aussi un aiguillage (reprise, question plus simple, changement de module, abandon, etc.).

Le dernier link ou exit conduit au formulaire puis au certificat.

Moyennant l'introduction dans la fiche de l'activité des noms des ui de la question suivante, les ui intermédiaires (liées à link et à exit) pourraient être constituées de fiches standardisée (voir bc-switch.xml). Evidemment dans ce cas les commentaires des feed-back seront réduits (usage de locReponse possible).

Modèles et variables

Pages standard

A venir, il s'agit du dispositif “test diagnostic” avec un choix plus étendus d'items.