Consultation des souhaits de la communauté pour 2021/Prévisualisation du wikicode en temps réel
Bonjour à tous, et merci de venir vous informer sur la Prévisualisation en temps réel. Il s’agit du 4e souhait de la Consulation des souhaits de la communauté pour 2021. Cet article va décrire notre méthode pour construire une solution à ce souhait. Nous sommes preneur de tout retour de votre part pour améliorer au mieux le produit.
Cette page documente un projet sur lequel l'équipe Community Tech de la Wikimedia Foundation a travaillé ou a refusé dans le passé. Le travail technique sur ce projet est terminé.
Nous vous invitons à rejoindre la discussion sur la page de discussion. .
Realtime Preview for Wikitext Wish Team  | |
|---|---|
| Allow 2010 wikitext editors to preview the page while editing | |
| Groupe : | Community Tech |
| Membres de l’équipe : | Nicolas Ayoub, Harumi Monroy, MusikAnimal, Emanuele Leoni, Sam Wilson, Szymon Grabarczuk |
| Direction : | Natalia Rodriguez (product owner) |
| Mises à jour : | Updates |
Résumé des objectifs du souhait : permettre aux contributeurs utilisant le wikicode de voir le rendu de la page pendant qu’ils écrivent.
Background & Problem Space
Remarque : pour éviter toute confusion, nous avons renommé le titre du souhait et le nom du projet « prévisualisation en temps réel » (c’était « prévisualisation en direct » auparavant). En effet, une fonctionnalité différente s’appelait déjà Prévisualisation en direct.
Le wikicode est un langage à balises pour wiki. Il est utilisé par de nombreux utilisateurs pour la mise en forme sur les wikis. Le code est différent de ce que les lecteurs voient. Lorsque l’on travaille avec du wikicode, il peut être difficile de s’imaginer le rendu du résultat final. C’est pourquoi de nombreux utilisateurs utilisent la fonctionnalité de prévisualisation avant de publier leurs modifications. Cependant, cela nécessite une étape en plus du processus de rédaction du wikicode.
Pour faire simple, nous pouvons résumer la problématique du souhait original ainsi :
Comment les contributeurs s’assurent que les changements qu’ils réalisent produisent bien ce qu’ils souhaitent ?
Du point de vue produit, permettre aux contributeurs de voir le rendu du balisage en temps réel permettrait :
- d’améliorer l’expérience contributeur en réduisant le nombre d’étapes (clics) supplémentaires pour faire une modification ;
- de permettre aux contributeurs de repérer des coquilles et du wikicode erroné pour les corriger immédiatement et maintenir la qualité du wiki.
Solutions proposées
Exigences pour le design
Voici un ensemble d’exigences pour le design pouvant être demandées par les contributeurs pour avoir une manière de prévisualiser leur contenu.
En tant qu’utilisateur contribuant en wikicode avec un écran d’ordinateur, je peux :
- avoir une option pour prévisualiser le rendu du wikicode ;
- rendre la sortie de la prévisualisation défilable, afin que je puisse facilement voir des éléments du rendu sans que celui-ci occupe tout l’écran.
Portée et limites
Le bouton de prévisualisation en temps réel sera disponible :
- sur les outils de rédaction en wikicode (nous ne toucherons pas à l’éditeur visuel) ;
- pour la contribution depuis un ordinateur ;
- pour les écrans d’une largeur supérieure à 1 200 px en mode paysage (disposition horizontale), la taille normale permettant de positionner tous les éléments sur la page sans désordre (la largeur minimum pourra changer) ; en mode portrait (disposition verticale), ce sera activé par défaut.
Investigations chiffrées
Nous travaillons à répondre aux questions suivantes qui nous permettrons de mieux comprendre le problème :
- Combien de contributeurs prévisualisent leurs modifications ?
- La prévisualisation permet-elle d’avoir moins de révocation ?
- Combien de contributeurs utilisent des écrans de taille ordinateur pour contribuer sur les wikis ?
- Est-il pertinent d’utiliser la disposition verticale par défaut ?
Pourquoi et comment avons-nous accepté ce souhait ?
Ce souhait a été bien placé dans liste de priorités pour 2021. Il a été très populaires (grand nombre de votes), présentait d’importants bénéfices pour la communauté et semblait relativement peu complexe à mettre en place. Vous pouvez lire notre processus complet.
Release Timeline
| Item | Status | Actual Date | Target Date | Notes |
|---|---|---|---|---|
| Deploy to test wiki for user testing purposes | Complete | 2022-03-30 | 2022-03-30 | |
| Enable on Beta cluster – Beta English Wikipedia and Wikisource only, since Realtime Preview changes the UI slightly for everyone even when you don't have it turned on | Complete | 2022-03-30 | 2022-03-30 | |
| Merge MVP for QA to Review | Complete | 2022-04-26 | 2022-04-08 | |
| Confirm MVP Top Priority tasks merged and QAd | Complete | 2022-04-26 | 2022-04-08 | |
| Get a final greenlight from Design QA | Complete | 2022-05-19 | 2022-04-15 | |
| Train w work deployed to Polish Wiki | Complete | 2022-04-26 | 2022-04-27 | Designer to schedule user video calls to observe users and design accordingly |
| First pilot wiki as an opt-out beta feature: plwiki | Complete | 2022-04-26 | 2022-04-27 | |
| Announcement on project page & any tool-specific pages | Complete | 2022-08-17 | 2022-04-30 | |
| Pilot wikis as an opt-in beta feature: huwiki, fiwiki | Complete | 2022-05-26 | 2022-05-24 | |
| Pilot wikis with Vector-2022, as an opt-in beta feature: cawiki, viwiki, fawiki | Complete | 2022-06-14 | 2022-06-14 | After phab:T307725 is complete |
| Get greenlight from Performance Review | Complete | 2022-10-17 | 2022-05-24 | |
| Announcement in WMF internal #release-announcements Slack channel | Not Started | |||
| Bugs identified and cut | In Progress | Should happen as soon as we release to the first wiki | ||
| Bugs triaged | In Progress | Should happen as soon as we release to the first wiki | ||
| Announcement in Tech/News | Complete | To be done when releasing to all wikis: | ||
| Release to group 0 as opt-in Beta (T314150) | Complete | 2022-08-02 | 2022-08-02 | |
| Release to group 1 as opt-in Beta (T314182) | Complete | 2022-08-23 | 2022-08-17 | |
| All wikis as opt-in Beta | Complete | 2022-08-31 | 2022-08-31 | |
| Graduate Beta Feature to feature for all | Complete | 2023-01-12 | 2023-01-09 |
Dernières mises à jour
Aug 17, 2022: Available as an opt-in beta feature for most wikis
After gathering feedback from the pilot wikis (cawiki, viwiki, fawiki, plwiki, huwiki, and fiwiki – thank you all!) we have released this feature to group 0 and group 1 as an opt-in beta feature. We plan to release to group 2 this August 31st as an opt-in beta feature. We plan to let it sit behind the Beta feature tab for 6-8 weeks, listening to feedback and improving the feature if any bugs arise. After that time window, we plan on graduating it from a beta feature to a feature for all 2010 Wikitext Editor users. To enable this feature from inside your beta preferences, be sure that the Realtime feature is enabled, and that the New Wikitext mode is disabled.
We would love to hear about how you enjoy using this tool and any other feedback from all of you in the Talk page!
May 3, 2022: Launching to partner projects
We have launched a version of the Realtime preview feature to Polish Wikipedia. Its community has agreed to partner with us and give us feedback on how to improve it before we launch to the rest of the users. Please find our complete Release Plan.
This feature touches one of the most used editors (Wikitext 2010) across wiki projects. We've thus decided to roll it out as a Beta Feature before we release the feature to everyone. This will allow us to collect feedback and make improvements before we release to everyone.
We are partnering with users early on to understand behavior on the new tool and make improvements. Depending on the user’s connection, we are aiming to observe and evaluate patterns regarding the automatic and manual reloads of the preview pane, as follows:
- Automatic reload: Debounce time. When the preview pane is automatically reloading, is our debounce time sufficient to provide a fluid experience?
- Automatic reload: Discoverability of the manual reload button. When the preview pane is automatically reloading, is the manual reload button that appears while hovering over the preview pane easy to find?
and/or
- Manual reload: Discoverability/Display time of the manual reload status bar. When the preview pane is NOT reloading automatically, the user will see a status bar inviting them to manually reload. Is the discoverability of the bar sufficient? Is the status bar obstructive to the users’ workflows?
We will aim to observe both of these scenarios for users with stable high-speed internet connections. In both cases, we will be performing the test on two pages: one short article without images (for faster reload time) and another one with a large content and multimedia assets (for slower reload time).
Aside from our main investigation, we will also be observing the following during our screen-sharing sessions with users:
- Discoverability of the overall feature: although users will be notified of the existence of the realtime preview feature, and the potential relationship between the latter and the "Show preview" feature.
- User screen sizes- This data could be helpful to understand how useful the Realtime Preview is for folks with a smaller screen. Does this make their experience too crowded?
- Usage of syntax highlighting/Code Mirror
- Understanding that both panes do not have a synced scrolling behavior.
If you would like to give us any feedback on any of the open questions above, please reach out to us in the talk page as we are eager to hear about the usability of this new feature. Thanks for building with us!
2 novembre 2021 : trouvailles des tests utilisateur du design
Bonjour à tous,
Merci sincèrement pour votre soutien et vos retours massifs sur les designs proposés. Merci pour vos messages sur la page de discussion et pendant la dernière visioconférence « Discutez avec nous ». Nous avons beaucoup appris sur la manière dont les utilisateurs expérimentés contribuent.
Par ailleurs, nous avons mené des tests de facilité d’utilisation sur la plateforme usertesting.com, auxquels 5 contributeurs ont pris part. Vous trouverez ci-dessous certaines des trouvailles et intuitions dégagées :
- La moitié des utilisateurs ont trouvé le nouveau bouton « Prévisualiser » dans la barre d’outil. Une des raisons à cela peut avoir pour origine les modèle comportementaux développés à partir du bouton « Prévisualiser » existant en bas de la boite de l’éditeur. Nous allons concevoir un point clignotant peu dérangeant avec un guide surgissant. Nous espérons que cela permettra de remarquer plus facilement cette nouvelle fonctionnalité.
- All users found the existing "show preview" button.
- All users understood the difference between both buttons. One could be used while editing (offering a quick glimpse at the output). The other could be more helpful for proofreading before publishing the changes.
- One user reported that it might always be easy to understand the relationship between the Wikitext input and the preview output. To mitigate this, we are exploring ways to highlight the text in both panes and align the scrolling or editing behavior.
Acknowledgments:
- Not all of these editors are experienced users. Although this wish is intended to be helpful for every user – we assume that less experienced editors will tend to use the Visual Editor over the wikitext editor. This will make the new feature less relevant for them.
- We are also working on improving the scaling of both panes. We want to allow for optimal support to both small and ultra-wide displays alike.
Again, thanks so much for your feedback!
September 14, 2021: Next steps about the design
Thank you for your feedback
Hello all, we are back with an update on the proposed designs for this wish. Thanks for all of your comments on the talk page. We heard what you said and synthesized the feedback as follows:
- The button to preview the wikitext output should be more intuitive, the person clicking it should know what it does.
- The button to preview the text should be in the toolbar.
We then took a second try at creating the following set of designs. We are proposing a new button appears in the toolbar:
We are proposing than when user previews the content, the preview button label remains "blue" to indicate that the preview state is on, and activated:
The preview button would turn back to black if users toggle it off and the preview would disappear.
Horizontal vs Vertical
Please note that these proposed designs are illustrative. We only included a vertical version because we are currently investigating if the ability to have a wide screen will still be an option given the planned and upcoming work on Web desktop improvements which would limit the page to 960px in width, making it too cluttered to have a horizontal view.
Open Questions: We want to hear from you!
- Does the new button placement seem more intuitive to the workflows in the toolbar?
- Does the current proposed layout feel like there is enough space to view both the wikitext and the output?
Thanks so much for your continued feedback on the talk page!
August 27, 2021: Initial Design Feedback
Proposed Designs
Horizontal Desktop Layout
A new button will appear. This gives editors the option to preview the text on the side in real-time:
Note: The pink box above is just to draw attention to the button, it will not actually appear to users.
Editors will be able to click on the button highlighted above. If they do that, the following layout would allow them to preview the output in a scrollable fixed container:
Vertical Desktop Layout
The following new user interface element will appear when a user has a vertical desktop screen:
Note: The pink box above is just to draw attention to the button, it will not actually appear to users.
Editors will be able to click on the button highlighted above. If they do that, the following layout would allow them to preview the output in a scrollable fixed container:
The engineers have begun work on these changes. We are introducing the changes inside of MediaWiki core. We'd love to hear your thoughts on our proposed designs. We'd especially love feedback on:
- Making the copy and button placements intuitive
- The overall feel of the proposed designs
We're looking forward to hearing your thoughts on our proposed designs and any other considerations!
Open Questions: We want to hear from you!
The solutions above are proposed and in early stages. We'd love to hear your feedback on the talk page. Your insight can help us understand other approaches, risks, and solutions.
These are our questions to you:
- How do you think this will influence the way you edit?
- Does the icon on the expand button prepare the editors to understand what it does? Is it distrupting?
Relevant Links
- Live Preview (NOT what we are doing)
- Original Wish
- Wikitext