2017 wikitext editor/fr



L’éditeur de wikicode 2017 est un mode de l'éditeur visuel qui permet aux utilisateurs d’utiliser les outils et la barre d’outils de l’éditeur visuel lors de la modification du code source wikitexte. On y accède depuis l’éditeur visuel en cliquant sur le bouton de la barre d'outils pour passer au wikicode.

Vous pouvez l’activer sur les wikis Wikimedia en tant que fonctionnalité bêta en allant dans vos 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 modération », le département Editing 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 en wikicode est disponible en tant que fonctionnalité bêta pour les utilisateurs sur l’interface de bureau. Le tâche principale sur Phabricator est 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. Le mode de fonctionnalité bêta permet aux utilisateurs de nous donner des retours et de prendre le temps, pour éviter une rupture brusque pour les contributeurs et le dysfonctionnement des gadgets.

Quels sont les raisons de ce projet ?
En 2010, la Wikimedia Foundation finit le projet Opérabilité (qui a aboutit à l’apparence actuelle Vector, à l’outil de téléversement et à l’outil de modification du contenu) et se pencha ensuite sur les questions soulevées par la communauté dans la Stratégie 2010-2015. Cela a inclue nombre d’améliorations pour les outils de modification, notamment l’éditeur visuel, en parallèles 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, sur la plupart des wikis Wikimedia, nous proposons trois principaux outils de modification du contenu. Ils sont incohérents pour les utilisateurs dans leur apparence et ambiance, dans la manière dont ils fonctionnent et agissent, et dans l’aide et assistance. Un d’eux est l’éditeur de wikicode pour bureau de la génération 2010 appelé WikiEditor, un autre 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 comment les utilisateurs, qu’ils soient nouveaux ou expérimentés, utilisent nos logiciels et comment ils préfèreraient l’utiliser. Notre étude a influé sur la construction de l’éditeur visuel en terme d’apparence qui correspond bien aux contributeurs, donnant clairement les indications aux nouveaux utilisateurs pour son utilisation tout en mettant de côté les expérimentés qui veulent seulement avoir quelque chose de terminé. Bien qu’imparfait, nous avons observé une forte préférence des nouveaux utilisateurs pour l’apparence de l’éditeur visuel, le déroulement du travail et par dessus tout l’expérience. 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 « "" ») 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 incohérents entre eux est mauvais. Cela est mauvais pour les débutants, parce que les idées qu’ils auraient appris sur un outil ne peuvent pas être appliquée dans d’autres contextes (par exemple en modifiant une page de discussion). C’est mauvais pour les utilisateurs existants qui doivent répondre à plusieurs questions avant de pouvoir estimer la difficulté de la situation pour le débutant et ensuite l’aider. C’est aussi mauvais pour les administrateurs, qui ont besoin de définir séparément les besoins de leur communautés pour chaque outil – ou de découvrir qu’ils ne peuvent pas y répondre avec certains outils. C’est mauvais pour les développeurs de scripts et de gadgets, qui doivent traiter de nombreuses situations différentes (ou les ignorer). C’est mauvais pour les développeurs, qui doivent prendre en compte trois systèmes différents lorsqu’ils veulent corriger ou ajouter une fonctionnalité. Enfin, c’est mauvais pour les donateurs de la Wikimedia Foundation, dont les dons sont dépensés pour soutenir ces multiples axes de travail parallèles.

Par conséquent, nous travaillons sur un nouvel outil de modification de wikicode. Cela donnera une expérience utilisateur unique, intégrée, cohérente entre modification visuelle et modification du wikicode, et ce à la fois sur bureau et sur mobile. Ce sera une plateforme intégrable dans d’autres outils, afin que l’expérience puisse être aussi proche que possible selon les situation et types de contenu modifiés. Nous donnerons aux utilisateurs la meilleure expérience possible, sans la moindre rupture.

Remarquez que la phase actuellement de déploiement est de fournir l’outil comme une fonctionnalité bêta et de recevoir des avis. Une fois seulement que nous avons atteint les seuils de qualité minimum (dont les tests par les nouveaux utilisateurs et le contentement de l’expérience utilisateur), probablement vers mi-2017, nous commencerons à l’installer par défaut à la place de l’outil de modification du wikicode actuel. Les utilisateurs qui ne l’aiment pas, bien sûr, pourront toujours ne pas l’utiliser tant qu’il est en fonctionnalité bêta et le désactiver en parallèle de l’éditeur visuel une fois qu’il sera sorti pour tout le monde. L’outil de modification du wikicode actuel ne bougera pas, au moins pour les quelques prochaines années. Bien que nous le fassions peut-être décliner, tous ceux qui l’apprécient peuvent le conserver.

First release (Beta Feature)
The initial goals for the project were to have parity with the existing wikitext editor, WikiEditor, using the same toolbar with the same buttons in the same positions as in the visual editor so users have consistent experience. This means providing at least all the controls in the wikitext editor, with very few exceptions for very rare buttons:

All these were completed as of August 2016, along with a lot of tools not in the existing wikitext editor (like strikethrough, underline, template inserting and so on), and features like pasted HTML being turned into wikitext automatically. In particular, we also provide the "citoid" auto-citation tool, which lets users quickly add references based on URLs or DOIs. This is similar to, but more advanced than, the gadgets that a few wikis like the English Wikipedia had written for themselves already, and they will now be available for all wikis.
 * Basic tools (bold, italics, signature, links and images);
 * Advanced tools (headings, bullet lists, numbered lists, big, small, superscript and subscript, galleries and tables);
 * Special character insertion; and
 * Find-and-replace.

We undertook extensive QA testing that the features work as expected, and a design review and structured user testing. Once we were happy that it is adequately working as intended, and is (at least) no worse for new users, we have sought feedback from experienced users of all levels via a Beta Feature.

Final beta release (before general release)
The point of the first release as a beta feature is to get some initial feedback on how well this new editor works for people. We expect the feedback to include a lot of suggestions for changes. There are a number of improvements that we're already considering. Some of these probably need to be addressed before the new wikitext editor would be released outside of a beta feature. Some of these are technically difficult and so have been postponed, whilst others would benefit from real-world feedback from existing users to shape the features as usefully as possible.

For the first category (big challenges), we believe that we will need to address section editing, in which clicking edit will show small parts of the page to edit, and a fully responsive design, so that the interface can scale up and down more cleanly for smaller devices, where users are zoomed-in, or other accessibility and platform reasons; these will let us provide the feature in mobile as a beta example as well, to ensure it works for all our editors, not just those on desktop.

For the second category (feedback needed), we will need to provide in-editor help to guide users through the editing process from the very first time they click edit and also later in their editing careers. Right now the wikitext editor has a "help" tab with some brief wikitext guidance; in the visual editor, we have a link to the user-guide, which we could replicate for this purpose. How this should work, and what it should highlight, is likely to be something on which many members of our communities have expert ideas. We will also need to clean up how gadgets extend the editor, as the new editor integration right now is complex and confusing. This would make converting some gadgets harder than it should be. Many wiki communities depend on particular gadgets to speed up their editing workflow, and it's important that we preserve the ability for wikis to flexibly experiment with improvements like this.

Naturally, any change of this scale is likely to be disruptive for some users' workflows, and will have a few issues with relative 'edge cases' not being addressed. We look forward to uncovering and addressing these over the weeks and months following the release of the beta feature.

Nice-to-haves
Alongside the above, there are other, new features we'd love to provide if possible, but which may prove too costly to develop or too slow for users, and so are not planned from the outset. One feature we'd be interested in providing is saving automatic local drafts as users edit, so that if their browser or computer crashes or loses power mid-edit they can resume rather than having to restart. This would rescue users from quite frustrating, if uncommon, occurrences, particularly people with poorly/old computers or network connections.

A big feature that often gets discussed is syntax highlighting of wikitext to help guide people's eyes to the right content for which they're looking. This feature was in fact built for the existing wikitext editor back in 2011, but we had to abandon it because the very high complexity of wikitext means that this was exceedingly slow for most users. Five years later, most users' machines are a fair bit faster than they were back then, which helps a little. Also, it might be worth exploring how performant we could make a feature doing this if we were to make some simplifications of the kinds of wikitext which we try to highlight.

More complex and error-prone than syntax highlighting, but possibly even more useful, would be a feature for folding wikitext structures into blocks so that users can easily ignore things they don't want to edit without having to read through them. For example, long infobox invocations or references could be folded up into blocks until you want to edit them. The technologies we built for the visual editor are particularly well-suited for providing this use case in a reliable fashion, so this may be something we could look at doing. Again, as with syntax highlighting we might need to compromise on the complexity of wikitext that we recognise in return for providing something performant enough to be useful to most of our users.

Another nice feature we could provide would be to prompt users when they save with two or three buttons to add one-click edit summaries based on their recent activities. This kind of feature is quite popular on some wikis as a gadget and it would be nice to provide it to all users on all wikis, without those wikis needing to have a gadget guru on hand to help set it up and maintain it.

Resources

 * An early rough design mockup from April is available here. To see the wikitext editor, click the brackets icon in the top-right corner.
 * An old rough demo video is also available as of mid-May 2016 at https://www.youtube.com/watch?v=jgd2ZHOZGBE.
 * Video demo of the 2017 wikitext editor from the December 2016 CREDIT showcase
 * The current version can be seen via Beta Features at https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-betafeatures; enable the "new wikitext editor" item, go to https://www.mediawiki.org/wiki/Project:Sandbox?veaction=editsource (for example) and see what it looks like when you switch back and forth.

Voir aussi

 * Nouvelles informations concernant les logiciels de modification, juin 2016 (en anglais)
 * Page de commentaires