[go: up one dir, main page]

Jump to content

Éditeur de wikicode 2017

From mediawiki.org
This page is a translated version of the page 2017 wikitext editor and the translation is 100% complete.

L’éditeur de wikicode 2017 est un mode de l'extension Éditeur Visuel permettant aux utilisateurs d’utiliser les outils et la barre d’outils de l’éditeur visuel lors de la modification du texte wiki du code source (appelé wikicode). On y accède depuis l’éditeur visuel en cliquant sur le bouton de la barre d'outils pour passer au wikicode.

L'éditeur de code 2017 a été rendu disponible aux wikis hébergés par la WMF en 2023. Il n'est pas activé par défaut. Vous pouvez décider de l'utiliser sur les wikis Wikimedia en allant dans vos préférences et en cliquant sur la case à cocher Utiliser le mode wikicode dans l’éditeur visuel, au lieu d’un éditeur de wikicode distinct puis sur Enregistrer les préférences.

De quoi s’agit-il ?

Dans le cadre d’un des objectifs du Projet annuel 2016-2017, « Maintenir et améliorer progressivement les interfaces actuelles de création et de réparation », le Département d'Édition travaille sur un nouvel éditeur de wikicode.

Il est intégré dans l’éditeur visuel pour un meilleur passage de l’un à l’autre. Il a une apparence similaire et de nombreux outils présents dans l’éditeur visuel, dont le service Citoid. Le nouveau mode de modification du wikicode est disponible pour les utilisateurs d'ordinateurs de bureau. La tâche principale sur Phabricator est tâche T104479 (le logiciel y est parfois appelé « modern wikitext editor » ou encore « new wikitext editor » (« NWE »)).

Il s’agit d’un nouvel éditeur, pas d’une modification de l’éditeur de wikicode actuel. Comme l'éditeur et construit sur une couche de l'Editeur Visuel et non pas sur une zone textuelle standard, plusieurs gadgets d'édition ne fonctionnent pas avec cela (il faut utiliser une API très spécifique pour accéder au wikicode). Les gadgets qui ouvrent un formulaire pour modifier et qui nécessitent une zone de texte peuvent passer à l'éditeur de wikicode simple avec action=submit (plutôt que action=edit).

Quelles sont les raisons de ce projet ?

En 2010, la Wikimedia Foundation a terminé le projet Opérabilité (qui a abouti à l’habillage Vector actuel , à l’outil de téléversement et à 2010 wikitext editor ) et s'est penchée ensuite sur les questions soulevées par la communauté dans la Stratégie 2010-2015. Cela a inclus un certain nombre d’améliorations pour les outils de modification, notamment l’éditeur visuel, en parallèle des notifications et d’autres améliorations. Cependant, la stratégie n’est pas et n’a jamais été de remplacer le wikicode ; nous estimons les deux systèmes de modification comme importants à long terme pour aider la communauté à continuer à couvrir les projets Wikimedia de succès comme ils le sont actuellement.

Au mois de décembre 2016, nous proposons sur la plupart des wikis Wikimedia trois principaux outils de modification du contenu. Ils sont différents pour les utilisateurs dans leur apparence, leur fonctionnement, leurs performances, ainsi que leur support. L'un est l’éditeur de wikicode pour bureau de la génération 2010 appelé WikiEditor, le second est l’éditeur visuel (dans sa forme bureau ou mobile) et le dernier est l’outil de modification minimaliste de wikicode sur mobile.

Depuis 2010, nous avons beaucoup appris sur la manière dont les utilisateurs, qu’ils soient nouveaux ou expérimentés, utilisent nos logiciels et ce qu'ils voudraient voir changer dans l'éditeur. Notre étude a servi au développement de l’éditeur visuel autour d’architectures qui fonctionnent bien pour les éditeurs en donnant clairement les indications aux nouveaux utilisateurs pour son utilisation tout en mettant de côté les utilisateurs expérimentés qui préfèrent l'éditeur qu'ils connaissaient déjà, WikiEditor. Bien qu’il soit imparfait, nous avons observé une forte préférence des nouveaux utilisateurs pour l’éditeur visuel, son apparence, le déroulement du travail et l’expérience globale avec lui. Nous avons aussi beaucoup appris en terme de technique, et l’avons construit de manière à pouvoir être utilisé sur une page (comme lorsque vous cliquez sur « $labelhere ») ou à l’intérieur d’un outil (comme dans Flow), et sur bureau ou sur mobile, et d’une manière extensible par d’autres fonctionnalités.

Avoir trois systèmes d'édition incohérents est mauvais. C'est mauvais pour les éditeurs plus récents car tout ce qu'ils ont appris d'un éditeur ne peut pas être appliqué à d'autres contextes (comme l'édition d'une page de discussion). C’est mauvais pour les éditeurs expérimentés, qui doivent répondre à plusieurs questions avant de pouvoir déterminer quelle est la situation du débutant et comment l’aider. C’est mauvais pour les administrateurs qui doivent configurer séparément ce dont leur communauté a besoin pour chacun des éditeurs, ou bien découvrir qu’ils ne peuvent pas l’obtenir dans certains éditeurs. C'est mauvais pour les développeurs de scripts et de gadgets, qui doivent faire face à de nombreuses situations différentes (ou les ignorer). C’est mauvais pour les développeurs qui doivent prendre en compte trois fois plus de niveaux de complexité chaque fois qu’ils ont besoin de réparer quelque chose ou d’ajouter une fonctionnalité. Et c'est mauvais pour les donateurs de la Fondation Wikimedia, leurs dons étant utilisés pour soutenir ces multiples tâches parallèles.

Par conséquent, nous travaillons sur un nouvel éditeur de wikicode, l'éditeur de wikicode 2017. Cela fournira une expérience unique, intégrée et cohérente entre le bureau et le mobile, et les éditeurs de wikicode et visuel. Ce sera une plateforme qui pourra être intégrée dans d'autres éditeurs, afin que l'expérience puisse être au plus près entre les situations et les types de contenu. Nous offrirons aux utilisateurs une expérience aussi bonne que possible, tout en limitant la casse sur les fonctionnalités existantes.

Les utilisateurs qui ne l'aiment pas pourront bien sûr ne pas l'utiliser. L'éditeur de wikicode actuel ne va pas bouger, au moins pour les prochaines années. Bien que nous puissions éventuellement le mettre en veilleuse, ceux qui l'aiment peuvent le garder.

État du développement et objectifs

Première version (fonctionnalité bêta)

L’objectif initial pour le projet était d’avoir les mêmes fonctionnalités que l’outil existant de modification du wikicode, avec les mêmes boutons et aux mêmes endroits que l’éditeur visuel, de manière à avoir une expérience utilisateur cohérente. C’est-à-dire fournir au moins toutes les options de l’outil de modification de wikicode, avec quelques exceptions pour de rares boutons :

  • outils élémentaires (gras, italique, signature, liens et images) ;
  • outils avancés (titres, listes à puces, listes ordonnées, texte en gras, texte en petit, texte en exposant, texte en indice, galeries et tableaux) ;
  • insertion de caractères spéciaux ; et
  • trouver et remplacer.

Toutes ces options ont été achevées en aout 2016, accompagnées par de nombreux outils qui n’étaient pas dans l’outil de modification du wikicode existant (tels que barrer le texte, le soulignement, l’insertion de modèles, etc.) et par des fonctionnalités telles que la transformation automatique en wikicode du texte HTML collé. En particulier, nous fournissons également l'outil de citation automatique « citoid », qui permet aux utilisateurs d'ajouter rapidement des références basées sur des URL ou des DOI. Ceci est similaire, voire plus avancé, aux gadgets que quelques wikis comme Wikipedia anglais avaient déjà écrits pour eux-mêmes ; ils seront désormais disponibles pour tous les wikis.

Nous avons effectué des tests d'assurance qualité approfondis pour que les fonctionnalités fonctionnent comme prévu, ainsi qu'une revue de conception et des tests utilisateur structurés. Une fois que nous avons été satisfaits, qu’il fonctionne correctement comme prévu et qu’il ne soit pas pire (au moins) pour les nouveaux utilisateurs, nous avons sollicité les commentaires d’utilisateurs expérimentés de tous niveaux via une fonctionnalité bêta.

Version bêta finale (avant la sortie générale)

L’objectif de la première publication comme fonctionnalité bêta est de recevoir des premiers commentaires sur la qualité du fonctionnement du nouvel outil de modification. Nous espérons que les retours des utilisateurs incluront de nombreuses suggestions. Il y a un certain nombre d'améliorations que nous envisageons déjà. Certains de ces problèmes doivent probablement être résolus avant que le nouvel éditeur de wikicode ne soit publié en dehors d'une fonctionnalité bêta. Certains d’entre eux sont techniquement difficiles et ont donc été reportés, tandis que d’autres bénéficieraient des commentaires réels des utilisateurs existants pour façonner les fonctionnalités aussi utilement que possible.

Pour la première catégorie (défits importants), nous pensons que nous devrons traiter l'"édition de section", dans laquelle le clic sur éditer va montrer de petites parties de la page à éditer et une architecture totalement dynamique, pour que l'interface puisse s'agrandir ou se réduire plus proprement sur les appareils plus petits, que les utilisateurs ont agrandis, ou pour d'autres motifs d'accessibilié ou de plateforme ; ceci nous permettra de fournir la fonctionnalité pour les mobiles également en tant qu'exemple bêta, pour s'assurer qu'elle fonctionne sur tous nos éditeurs, et pas seulement que pour le bureau.

Pour la deuxième catégorie (commentaires nécessaires), nous devrons fournir une aide dans l'éditeur pour guider les utilisateurs tout au long du processus d'édition dès la première fois qu'ils cliquent sur modifier et plus tard dans leur carrière d'édition. À l’heure actuelle, l’éditeur de texte wiki a un onglet « aide » avec de brefs conseils sur le texte wiki ; dans l’éditeur visuel, nous avons un lien vers le guide de l’utilisateur, que nous pourrions reproduire à cet effet. Comment cela devrait fonctionner et ce qu’il devrait mettre en évidence, est susceptible d’être quelque chose sur lequel de nombreux membres de nos communautés ont des idées d’experts. Nous devrons également nettoyer la façon dont les gadgets étendent l'éditeur, car la nouvelle intégration de l'éditeur est actuellement complexe et déroutante. Cela rendrait la conversion de certains gadgets plus difficile qu’elle ne devrait l’être. De nombreuses communautés wiki dépendent de gadgets particuliers pour accélérer leur flux de travail d’édition, et il est important que nous préservions la capacité des wikis à expérimenter de manière flexible des améliorations comme celle-ci.

Naturellement, tout changement de cette échelle est susceptible de perturber les flux de travail de certains utilisateurs, et aura quelques problèmes avec des « cas extrêmes » relatifs qui ne seront pas traités. Nous sommes impatients de découvrir et de résoudre ces problèmes au cours des semaines et des mois suivant la sortie de la fonctionnalité bêta.

Bonnes pratiques

Parallèlement à cela, il y a d'autres nouvelles fonctionnalités que nous aimerions fournir si possible, mais qui peuvent s'avérer trop coûteuses à développer ou trop lentes pour les utilisateurs, et ne sont donc pas planifiées dès le départ. Une fonctionnalité que nous serions intéressés à fournir est la sauvegarde de brouillons locaux automatiques au fur et à mesure que les utilisateurs modifient, de sorte que si leur navigateur ou leur ordinateur tombe en panne ou perd de la puissance en cours de modification, ils puissent reprendre plutôt que de devoir recommencer. Cela sauverait les utilisateurs d’événements assez frustrants, voire rares, en particulier les personnes disposant de vieux ordinateurs ou de mauvaises connexions réseau.

Une caractéristique importante qui fait souvent l'objet de discussions est la coloration syntaxique du wikicode pour aider à guider les yeux des gens vers le bon contenu qu'ils recherchent. Cette fonctionnalité a en fait été conçue pour l’éditeur de wikicode existant en 2011, mais nous avons dû l’abandonner, car la très grande complexité du wikicode signifie que cela était extrêmement lent pour la plupart des utilisateurs. Cinq ans plus tard, la plupart des machines des utilisateurs sont un peu plus rapides qu'elles ne l'étaient à l'époque, ce qui aide un peu. De plus, cela pourrait valoir la peine d’explorer à quel point nous pourrions rendre une fonctionnalité performante en faisant cela, si nous devions faire quelques simplifications des types de wikicodes que nous essayons de mettre en évidence.

(Pendant ce temps, la coloration syntaxique est fournie par Remember the dot's syntax highlighter et WikEd , qui sont disponibles sur certains wikis sous forme de gadgets). La mise en évidence de la syntaxe a également été introduite à gerrit:343878 dans l'éditeur de wikicode 2017 en utilisant Extension:CodeMirror .

Plus complexe et sujet aux erreurs que la coloration syntaxique, mais peut-être même plus utile, serait une fonctionnalité pour replier les structures wikicode en blocs afin que les utilisateurs puissent facilement ignorer les choses qu'ils ne veulent pas éditer sans avoir à les lire. Par exemple, les longues invocations ou les références d'infobox peuvent être regroupées en blocs jusqu'à ce que vous souhaitiez les éditer. Les technologies que nous avons développées pour l'éditeur visuel sont particulièrement bien adaptées pour fournir ce cas d'utilisation de manière fiable, donc c'est peut-être quelque chose que nous pourrions envisager de faire. Encore une fois, comme pour la coloration syntaxique, nous pourrions avoir besoin de faire des compromis sur la complexité du wikicode que nous reconnaissons en échange de fournir quelque chose d’assez performant pour être utile à la plupart de nos utilisateurs.

Une autre fonctionnalité intéressante que nous pourrions fournir serait d'inviter les utilisateurs lorsqu'ils enregistrent avec deux ou trois boutons à ajouter des résumés d'édition en un clic en fonction de leurs activités récentes. Ce type de fonctionnalité est assez populaire sur certains wikis en tant que gadget et ce serait bien de le fournir à tous les utilisateurs sur tous les wikis, sans que ces wikis aient besoin d’un gourou du gadget à portée de main pour aider à le configurer et à le maintenir.

Ressources


Voir aussi