« Wikiversité:Prise de décision/Autoriser la création de pages gadget-MOOC » : différence entre les versions

::........ La raison d’être principale de cette structure "améliorée", pour les formations qui souhaiteront l'adopter, n'estn’est pas de répondre spécifiquement au handicap éventuel des utilisateurs de la wikiversité. Certes, cette structure est plus accessible pour les personnes avec un handicap et c’est une des améliorations qu'elle propose, comme expliqué dans "Les enjeux" ci-dessus. Mais la raison d’être principale de cette structure, selon moi, est de permettre de créer des formations dont la mise en forme est plus utilisable et plus efficace pédagogiquement, en particulier pour la formation d'adultes en activité professionnelle qui ont été exposés à des MOOC ou à du e-learning (avec fil d'ariane, découpage visuel, navigation en 1 clic, mise en exergue des objectifs et pré-requis, etc.). D'ailleurs, si ce nouveau modèle de formation se révèle effectivement plus satisfaisant pour cette formation lors de son usage, lors des contributions et aussi pour la maintenance, on pourra imaginer que d'autres formations décident de l'adopter progressivement ailleurs dans la wikiversité. Peut-être que ça pourrait préfigurer de nouvelles habitudes pour améliorer l'ergonomie et l'utilisabilité d'autres formations dans la wikiversité ? A mon avis, c’est beaucoup trop tôt pour le dire. L'objectif de cette prise de décision est uniquement de permettre de créer un modèle de ce type et en aucun cas de décider de son adoption par d'autres formations que celle pour laquelle il a été créé. --[[Utilisateur:Jean.akaSig|Jean.akaSig]] ([[Discussion utilisateur:Jean.akaSig|discussion]]) 29 février 2016 à 20:58 (UTC)

::: ----> La mission de rendre accessible un site internet ou de créer un site internet accessible n'estn’est pas la mission principale des chefs de projet qui pour certains l'associent à un travail laborieux. En leur permettant d'accéder à une formation dont le parcours est visible dès la première page, qui peut être suivie facilement en plusieurs fois, dont la structure permet d'avancer pas à pas on leur permet de bien gérer leur temps et de changer leur regard sur l'accessibilisation, on leur permet de le voir comme une nouvelle compétence facile à acquérir et de fait de considérer l'accessibilité comme une action opérable. Et c’est le plus important étant donné le peu de site accessible.[[Utilisateur:Isabelle-ANDI|Isabelle-ANDI]] ([[Discussion utilisateur:Isabelle-ANDI|discussion]]) 1 mars 2016 à 08:12 (UTC)

::........ Cette proposition de nouveau modèle, pour cette formation, ne change rien d’important pour les contributeurs. Elle ne consiste qu’à modifier des fichiers "techniques" (fichier CSS et fichier Javascript) utilisés par cette formation (ou par les formations qui utiliseront le modèle qui fait appel à ces fichiers) et que les contributeurs n'ont pas besoin de modifier (sauf s'ils sont développeurs Javascript ou CSS, mais c’est une autre histoire). La manière de contribuer au contenu ne change pas. La particularité de la nouvelle mise en forme est liée à ces fichiers techniques. Elle n'estn’est pas liée aux contenus qui peuvent être modifiés comme d'habitude par n’importe qui. Ce n'est donc pas en contradiction avec l'esprit d'un wiki. Au contraire, cette proposition respecte le principe de séparation du fond et de la forme ("separation of concerns") qui est un principe de base de l'architecture de tous les wikis. --[[Utilisateur:Jean.akaSig|Jean.akaSig]] ([[Discussion utilisateur:Jean.akaSig|discussion]]) 29 février 2016 à 20:58 (UTC)

Le principale avantage de l'éditeur visuel à mes yeux, c’est que sont utilisation n'estn’est pas obligatoire. Chaque utilisateur peut en effet l'activer ou le désactiver globalement sur la projet, ou encore l’utiliser ou ne pas l’utiliser en fonction des pages et des modifications qu’il a a faire. De ce fait, refuser son installation devient difficilement justifiable du fait que son utilisation est facultative.

Étant donné que le débat technique au niveau de cette prise de décision m'échappe, je me pose donc simplement la question de savoir si la mise en œuvre de ce que propose cette prise de décision sera facultative ou pas à un niveau individuel (au même titre que l'éditeur visuel) ? Si cette liberté est assurée alors je voterai en faveur de cette prise de décision sans aller plus loin dans le débat. Si cette liberté n'estn’est pas permise, alors j'aimerais poursuivre le débat. Une belle fin de journée à tous, [[User:Lionel Scheepmans|Lionel Scheepmans]] ^{<big>✉ </big> [[User talk:Lionel Scheepmans|Contact]]} _{Désolé pour ma [[w:dysorthographie|dysorthographie]]} 29 février 2016 à 21:19 (UTC)

: Non, je crois qu’il y a malentendu, là. Le modèle dont la création est proposée dans cette prise de décision est un modèle qui s'appliquerait de manière NON FACULTATIVE à TOUS les utilisateurs de la formation qui adoptera ce modèle. Ce qui est facultatif, c’est le fait, pour une formation donnée, d'adopter ou non ce modèle. Ce n'estn’est pas comme l'éditeur visuel ou les gadgets. C'est plutôt un choix que font les créateurs ou contributeurs d'une formation : pour cette nouvelle formation que je créé ou que je modifie, vais-je adopter tel modèle "habituel" (par exemple le modèle Cours) ou bien vais-je adopter ce nouveau modèle MOOC qui est plus ergonomique et plus accessible. Une fois que le choix est fait par les contributeurs, ce modèle s'applique à tous les utilisateurs de cette formation. Et, pour revenir sur ce choix (adopter un autre modèle), il faut modifier le contenu de la page. Isabelle-ANDI dis-nous si je me trompe ! Le risque à peser est donc double : est-ce acceptable d’avoir certaines formations avec un modèle différent des autres même s'il est plus utilisable, ergonomique et accessible ? est-ce que ça demande plus de travail de maintenance à l'avenir ? L'inconvénient de cette décision est donc un manque d'uniformité visuelle entre les formations (celles qui utilisent le modèle MOOC seront plus sexy, pour faire simple) et le fait que le jour où quelqu’un repérera un bug dans le fichier javascript ou CSS de ce modèle, il faudra un peu de compétence technique pour pouvoir le corriger. A mon avis, les avantages (permettre aux utilisateurs de mieux apprendre sans compliquer la vie des contributeurs) dépassent les inconvénients (avoir certaines formations mieux présentées que d'autres et dépendre de compétences simples en javascript ou CSS en cas de bug à corriger). D'où mon vote "POUR". Mais ça se discute... --[[Utilisateur:Jean.akaSig|Jean.akaSig]] ([[Discussion utilisateur:Jean.akaSig|discussion]]) 1 mars 2016 à 21:53 (UTC)

::::::Je dirais même plus mon chère Dupont Dupont : Vector est l'apparencel’apparence graphique (skin) des pages MediaWiki appliquée par défaut. Il y a d’autre apparence disponible dans le menu [[Spécial:Préférences#mw-prefsection-rendering|préférence]] des compte utilisateur. L'une d'entre elle est monobook souvent utiliser pas les administrateur du site en raison de certaines fonctionnalité. [[mw:Skin:Vector/fr|Plus d'info sur Vector]] sur le site dédié à MediaWiki mais je n'y ai pas trouvé de charte graphique. Belle fin de journée à tous, [[User:Lionel Scheepmans|Lionel Scheepmans]] ^{<big>✉ </big> [[User talk:Lionel Scheepmans|Contact]]} _{Désolé pour ma [[w:dysorthographie|dysorthographie]]} 14 mars 2016 à 12:16 (UTC)

: En fait ce n'est qu'une démo permettant de montrer l'aspect graphique et le menu de navigation. Cette démo n'estn’est pas hébergée sur la wikiversité. Une fois le modèle validé, nous pourrons en effet l'appliquer à la formation et le mettre dans une faculté. [[Utilisateur:Isabelle-ANDI|Isabelle-ANDI]] ([[Discussion utilisateur:Isabelle-ANDI|discussion]]) 1 mars 2016 à 07:47 (UTC)

:: C'est parce que ce n'estn’est pas un gadget que l'utilisateur active ou non dans ses préférences. Ce n'estn’est pas au choix de l'utilisateur. C'est au choix du contributeur qui créé ou modifie la formation. A mon avis, le fichier est d'ailleurs mal nommé car un gadget, sur MediaWiki, c’est quelque chose de facultatif, que chaque utilisateur décide ou non d'activer dans ses préférences.. On aurait dû plutôt appeler ça quelque chose comme modele-MOOC.js et modele-MOOC.css. L'objet de la proposition est de référencer ces 2 fichiers depuis, respectivement, Common.js et Common.css et de créer un modèle MediaWiki qui incluera les balises HTML et CSS connues de ces 2 fichiers modele-MOOC.js et modele-MOOC.css. Ainsi, sur les pages habituelles de la wikiversité, Common.js va se charger dans le navigateur, comme d'habitude, puis charger et exécuter le code de modele-MOOC.js. Mais comme ces pages habituelles de la wikiversité utilisent les modèles habituels (Cours, etc.), elles n'incluent pas les balises HTML propres au modèle MOOC. Donc rien de spécial ne se passera pour l'utilisateur sur ces pages (ni pour le contributeur d'ailleurs). Par contre, dans la formation accessibilité, qui utilisera le modèle MOOC, (ou dans les autres formations qui décideront d’utiliser le modèle MOOC), le code HTML contiendra des balises HTML propres à ce modèle MOOC. Donc, lorsque modele-MOOC.js va se charger dans le navigateur de l'utilisateur (de tous les utilisateurs de passage sur cette page), il va reconnaître ces balises et faire son travail de mise en forme de la page selon le modèle MOOC. Idem pour modele-MOOC.css. Et l'utilisateur verra, en résultat, ce que vous pouvez voir sur la maquette en démonstration sur le serveur de Mobyou. Ce principe est celui qui a été appliqué sur la wikiversité anglophone pour le MOOC Web Science, à l'exception qu’ils ont fait ça de manière plus compliquée, en créant un addon MediaWiki qui a donc dû être installer sur les serveurs, ce qui a probablement requis l'intervention d'administrateurs système de la fondation (si j’ai bien compris). --[[Utilisateur:Jean.akaSig|Jean.akaSig]] ([[Discussion utilisateur:Jean.akaSig|discussion]]) 2 mars 2016 à 19:33 (UTC)