Jump to content

Umfrage zur Community-Wunschliste 2021/Echtzeitvorschau für den Wikitext-Editor

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Community Wishlist Survey 2021/Real Time Preview for Wikitext and the translation is 83% complete.
Outdated translations are marked like this.

This page documents a project the Wikimedia Foundation's Community Tech team has worked on or declined in the past. Technical work on this project is complete.

We invite you to join the discussion on the talk page.

Hallo zusammen und danke dafür, dass Ihr hierhergekommen seid, um mehr über die Echtzeitvorschau zu erfahren. Dieser Wunsch war #4 im Community Wishlist Survey 2021. Dieser Artikel soll unseren Ansatz, eine Lösung zu entwickeln, darstellen. Wir bitten Euch um Euer Feedback und Einsichten, damit wir die bestmögliche Verbesserung entwickeln können.

Zusammenfassung der Ziele des Wunsches: Benutzer, die den 2010er Wikitext-Editor verwenden, können die Seite während der Bearbeitung in Echtzeit ansehen.

Originaltext

Hintergrund & Problemschilderung

HINWEIS: Um Verwirrung zu vermeiden, haben wir den Wunsch von Live-Vorschau in Echtzeitvorschau umbenannt. Dies geschah, weil es bereits ein Feature mit dem Namen Live Preview (Live-Vorschau) gibt.

Wikitext ist eine Wiki-Auszeichnungssprache. Sie wird von vielen Autor*innen benutzt, um in den Wikis zu formatieren. Sie sieht anders aus als das, was die Leser*innen sehen. Bei der Arbeit mit Wikitext kann es schwer sein, sich vorzustellen, wie das Endergebnis aussehen wird. Deshalb benutzen viele AutorInnen die Vorschaufunktion vor der Veröffentlichung einer Änderung. Das bedeutet allerdings einen extra Schritt, getrennt vom Schreiben des Wikitextes.

Im Großen und Ganzen können wir das Problem der Originalwunsches wie folgt zusammenfassen:

Wie stellen AutorInnen sicher, dass die Änderungen, die sie vornehmen, das gewünschte Ergebnis haben?

Aus Produktentwicklungssicht kann die Ermöglichung der Echtzeitansicht der Auszeichnungen Folgendes bedeuten:

  • Verbesserung der Erfahrungen als Autor durch Reduktion der Schritte (Klicks) während des Schreibprozesses.
  • Es erlaubt den Autor*innen, Tippfehler und fehlerhafte Syntax sofort zu erkennen und somit die Qualität der Wikis zu verbessern.

Vorgeschlagene Lösungen

Anforderungen an das Design

Im Folgenden wird eine Reihe von Design-Anforderungen aufgeführt, die es Autor*innen ermöglichen, eine Vorschau ihrer Inhalte anzuzeigen.

Als Nutzer, der mit einem Bildschirm in Desktop-Größe Wikitexte bearbeitet, kann ich:

  • Eine Option wählen, um eine Vorschau des ausgegebenen Wikitextes anzuzeigen
  • Durch die Vorschau scrollen, sodass ich ganz leicht die Vorschau für Elemente anzeigen kann, ohne dass der ganze Bildschirm davon eingenommen wird

Wichtige Einschränkungen

Die Echtzeit-Vorschau-Schaltfläche wird verfügbar sein für/auf:

  • Bearbeitungswerkzeuge, die auf Wikitext beruhen. Wir werden nicht den Visuellen Editor verändern.
  • Bearbeitung am Desktop-PC
  • Bildschirm mit mehr als 1200 px im Querformat (horizontales Layout). Das ist die Standardbreite, um alle Seitenelemente unterzubringen, ohne ein Durcheinander zu verursachen. Die minimale Breite kann schwanken. Im Hochformat (horizontales Layout) wird dies standardmäßig verfügbar sein.

Datenermittlungen

Wir arbeiten mit Hochdruck daran, die folgenden Fragen zu beantworten, die dabei helfen werden, unser Verständnis des Problems zu vertiefen:

  • Wie viele Autor*innen benutzen die Vorschau für ihre Änderungen?
    • Führt die Vorschau von Änderungen zu weniger Zurücksetzungen?
  • Wie viele Autor*innen benutzen Bildschirme in Desktop-Größe, um Bearbeitungen auf den Wikis vorzunehmen?
  • Ist es sinnvoll, das Hochformat zum Standard zu machen?

Warum und wie haben wir diesen Wunsch angenommen?

Dieser Wunsch schnitt bei unserem Priorisierungsablauf 2021 sehr gut ab. Er war sehr beliebt in Bezug auf die Anzahl der Stimmen, einflussreich in Bezug auf den Nutzen für die Gemeinschaft und hatte schätzungsweise eine relativ niedrige Komplexität. Bitte informiert euch hier zum gesamten Ablauf.

Release Timeline

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


Status-Updates

17. August 2022: Verfügbar als Opt-in-Beta-Funktion für die meisten Wikis

Nachdem wir das Feedback der Pilot-Wikis (cawiki, viwiki, fawiki, plwiki, huwiki und fiwiki - vielen Dank an alle!) gesammelt haben, haben wir diese Funktion für Gruppe 0 und Gruppe 1 als Opt-in-Beta-Funktion freigegeben. Wir planen, diese Funktion am 31. August für die Gruppe 2 als Opt-in-Beta-Funktion freizugeben. Wir planen, die Funktion 6-8 Wochen lang hinter der Registerkarte "Beta" zu belassen, um Feedback zu erhalten und die Funktion zu verbessern, falls Fehler auftreten. Nach diesem Zeitfenster planen wir, die Funktion von einer Betafunktion zu einer Funktion für alle Benutzer des Wikitext-Editors 2010 zu machen. Um diese Funktion in deinen Beta-Einstellungen zu aktivieren, stelle sicher, dass die Echtzeitfunktion aktiviert ist und dass der Modus Neuer Wikitext deaktiviert ist.

Bildschirmfoto der MediaWiki Beta-Einstellungen

Wir würden uns freuen, von dir zu hören, wie du dieses Tool nutzt, und würden uns über jedes andere Feedback von dir auf der Diskussionsseite freuen!

3. Mai 2022: Start für Partnerprojekte

Wir haben eine Version der Echtzeit-Vorschau für die polnische Wikipedia gestartet. Die polnische Wikipedia-Gemeinschaft hat sich bereit erklärt, mit uns zusammenzuarbeiten und uns Feedback zu geben, wie wir die Funktion verbessern können, bevor wir sie für den Rest der Benutzer einführen. Hier findest du unseren kompletten Release-Plan.

Diese Funktion betrifft einen der meistgenutzten Editoren (Wikitext 2010) in allen Wikiprojekten. Wir haben uns daher entschlossen, diese Funktion als Beta-Funktion einzuführen, bevor wir sie für alle freigeben. Dies ermöglicht es uns, Feedback zu sammeln und Verbesserungen vorzunehmen, bevor wir die Funktion für alle freigeben.

Wir arbeiten frühzeitig mit den Nutzern zusammen, um das Verhalten mit dem neuen Tool zu verstehen und Verbesserungen vorzunehmen. Abhängig von der Verbindung des Nutzers wollen wir Muster in Bezug auf das automatische und manuelle Neuladen des Vorschaufensters beobachten und auswerten, wie folgt:

  • Automatisches Nachladen: Verzögerungszeit. Wenn das Vorschaufenster automatisch neu geladen wird, reicht dann die Verzögerungszeit aus, um eine flüssige Darstellung zu gewährleisten?
  • Automatisches Nachladen: Erkennbarkeit der manuellen Nachladetaste. Wenn das Vorschaufenster automatisch neu geladen wird, ist die Schaltfläche zum manuellen Neuladen, die erscheint, wenn man den Mauszeiger über das Vorschaufenster bewegt, leicht zu finden?

und/oder

  • Manuelles Nachladen: Erkennbarkeit/Anzeigezeit der Statusleiste für das manuelle Nachladen. 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!

November 2, 2021: Findings from user testing of designs

Hallo zusammen,

Many thanks for your support and great feedback on the proposed designs. Thank you for comments on the talk page, as well as the latest "Talk to Us" video call. We have learned more about how experienced users edit.

Also, we have conducted usability testing on the usertesting.com platform. 5 editors took part. Below you will find some of the findings and insights:

  • Half of the users found the new "Preview" button in the toolbar. One of the reasons for this could be behavioral patterns developed over the existing "Show preview" button in the footer of the editor box. We are designing a low-friction pulsating dot with a guide popup. We hope this will make it easier to notice the new feature.
  • 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!

14. September 2021: Weitere Schritte zum Design

Danke für euer Feedback

Hallo an alle, wir sind wieder da mit einem Update zu den vorgeschlagenen Designs für diesen Wunsch. Danke an alle, die auf der Diskussionsseite kommentiert haben. Wir haben es uns zu Herzen genommen und das Feedback wie folgt umgesetzt:

  • Die Schaltfläche für die Vorschau der Wikitext-Ausgabe sollte intuitiver sein. Die Person, die sie anklickt, sollte ihre Funktion kennen.
  • Die Schaltfläche zur Vorschau des Textes sollte sich in der Werkzeugleiste befinden.

Wir haben dann einen zweiten Versuch unternommen, das folgende Set an Designs zu erstellen. Wir schlagen eine neue Schaltfläche vor, die in der Werkzeugleiste erscheint:

Wir schlagen vor, dass die Vorschau-Schaltfläche "blau" bleibt, wenn der Nutzer eine Vorschau der Inhalte anzeigen lässt, um zu signalisieren, dass die Vorschau gerade aktiviert ist:

Die Vorschau-Schaltfläche würde wieder schwarz werden, wenn Nutzer sie auf Aus stellen und die Vorschau würde verschwinden.

Horizontal vs Vertikal

Bitte beachtet, dass diese Designvorschläge nur der Veranschaulichung dienen. Wir haben nur eine vertikale Version berücksichtigt, weil wir momentan prüfen, ob die Möglichkeit, einen Widescreen zu haben, weiterhin eine Option bleibt, im Hinblick auf die geplanten Web Desktop Verbesserungen, die die Seite auf 960px in der Breite beschränken würden und eine horizontale Ansicht zu unübersichtlich machen würden.

Offene Fragen: Wir wollen von euch hören!

  • Wirkt die Platzierung der neuen Schaltfläche intuitiver zu den Workflows in der Werkzeugleiste?
  • Scheint es bei dem vorgeschlagenen Layout genug Platz zu geben, um sowohl den Wikitext als auch die Ausgabe anzuzeigen?

Ein großes Dankeschön für euer ständiges Feedback auf der Diskussionsseite!

27. August 2021: Erstes Feedback zum Design

Designvorschläge

Horizontales Desktop-Layout

Eine neue Schaltfläche wird erscheinen. Das gibt Autor*innen die Möglichkeit, eine Vorschau des Texts an der Seite in Echtzeit anzuzeigen:

Hinweis: Der pinke Rahmen oben soll lediglich auf die Schaltfläche aufmerksam machen und wird für die Nutzer nicht sichtbar sein.

Autor*innen werden die oben markierte Schaltfläche anklicken können. Wird das gemacht, würde das folgende Layout eine Option zum Anzeigen einer Vorschau der Ausgabe in einer scrollbaren festen Umgebung geben:

Vertikales Desktop-Layout

Das folgende neue Benutzeroberflächen-Element für Nutzer wird erscheinen, wenn ein Nutzer einen vertikalen Desktop-Bildschirm verwendet:

Hinweis: Der pinke Rahmen oben soll lediglich auf die Schaltfläche aufmerksam machen und wird für die Nutzer nicht sichtbar sein.

Autor*innen werden die oben markierte Schaltfläche anklicken können. Wird das gemacht, würde das folgende Layout eine Option zum Anzeigen einer Vorschau der Ausgabe in einer scrollbaren festen Umgebung geben:

Die Ingenieure haben bereits mit der Arbeit an diesen Änderungen begonnen. Wir führen die Änderungen innerhalb des MediaWiki-Kerns durch. Wir würden uns sehr freuen, wenn ihr eure Meinung zu unseren Designvorschlägen mit uns teilen könntet. Wir freuen uns besonder über Feedback zu:

  • Kopie und Schaltflächen-Platzierungen intuitiver gestalten
  • Der Gesamteindruck zu den vorgeschlagenen Designs

Wir erwarten mit Spannung eure Gedanken zu unseren Designvorschlägen und anderen Ideen!

Offene Fragen: Wir wollen von euch hören!

Die obigen Lösungen sind Vorschläge und stecken noch in einer frühen Phase. Wir freuen uns über euer Feedback auf der Diskussionsseite. Eure Meinung kann uns dabei helfen, andere Ansätze, Risiken und Lösungen besser zu verstehen.

Hier sind unsere Fragen an euch:

  • Wie wird die Änderung wohl euer Bearbeitungsverhalten beeinflussen?
  • Macht das Symbol auf der Erweitern-Schaltfläche die Funktion nachvollziehbar? Stört es eher?