Page MenuHomePhabricator

Update ParserMigration notice
Open, Needs TriagePublic

Description

This task is for design review and potential UX updates to the ParserMigration notice, which was added in T355567 and made Codex-compliant in T358296, T359000. Some slack discussion is at https://wikimedia.slack.com/archives/C024QCFAJ/p1706624320880659, https://wikimedia.slack.com/archives/C024Z8K9CAU/p1708637580424359, and https://wikimedia.slack.com/archives/C05D7UDJZ5E/p1713985199324989, summarized below.

The goal of the UX feature is to ensure that readers are aware that the Parsoid migration may cause issues with the display of certain articles on-wiki, and to ensure that they have access to links to provide more information or to report bugs if they find them. Since on some wikis parsoid is not used on every page (for example, it is being deployed only on talk pages which use discussion tools on some wikis), there should be some subtle indication on the page when parsoid is being used.

Our current design:

  • Puts a "Rendered with Parsoid" page indicator at the top of a page rendered with Parsoid, using the Codex InfoChip CSS (this is a slight violation of design guidance for the use of this component)
  • Add a notification popup the first time a user visits a page rendered with Parsoid, containing links to more information about the feature and a place to report bugs.
    • When the notification is dismissed, it stays dismissed for "some time" (currently 7 days, soon 30 days) but the idea was that it would periodically reappear in case the original notice was dismissed accidentally (aka "oops, now i'll never see that again").

Initial feedback was that the mechanism to dismiss the dialog wasn't very discoverable (T358296) which I think has now been addressed, although not in a generic way that benefits other users of mw.notification (T42307). More recent feedback has been that the notification "keeps reappearing", which might be because the cookie is site-specific, and so when you log in to a different domain (mobile vs desktop, en versus wikitech versus officewiki) you get the notice again. It might also be that the 7 day timeout is too short, or that there is some other bug in the cookie mechanism.

Some questions:

  • Could the wording be improved? Does an ordinary user know what the "Rendered With Parsoid" infochip means? Does the wording in the popup notification communicate what we are trying to convey?
  • Perhaps the "link for more information" could be folded into the page indicator infochip somehow; I don't think there's existing Codex guidance for this though.
  • Perhaps a site notice or other static message is more appropriate that a pop up notification?
  • Perhaps the popup notification itself could be less obtrusive?
  • Perhaps this should look different on mobile than desktop -- the popup takes up a much larger fraction of screen real estate on mobile.

image(11).png (160×300 px, 7 KB)

image.png (1×2 px, 381 KB)

To reproduce: follow the instructions at https://www.mediawiki.org/wiki/Help:Extension:ParserMigration to enable parsoid read views for a wiki (or globally).

Event Timeline

Have you considered using a banner either using siteNotice or at the footer? Since there is a rendered by Parsoid indicator I am curious at the goal of also having the notification...?

One thing that I might be wrong but it feels like this is that if the notice comes and goes without me clicking on the close button, it shows up again but if I hit the x button, it stays gone.

Have you considered using a banner either using siteNotice or at the footer? Since there is a rendered by Parsoid indicator I am curious at the goal of also having the notification...?

The notification provides a one-time link to more information, while the indicator/infochip is (intended to be) a small persistent non-intrusive non-interactive element. There are also sidebar links to swap between the legacy and new renderer. Design review suggested perhaps tying these together better.

One thing that I might be wrong but it feels like this is that if the notice comes and goes without me clicking on the close button, it shows up again but if I hit the x button, it stays gone.

That's an interesting observation. My original thought was "if you explicitly dismiss it it stays gone" but (given how obtrusive the pop-up is) I think it's reasonable to assume that you've seen it once we've displayed it once, and we could dismiss it once shown. It goes back to the "oops, what did that say?" issue, but that's why we show it again in <some time period>. Maybe the <time period> could be longer (or "forever") if you explicitly dismiss it, and shorter if the user didn't explicitly dismiss?

@cscott thank you so much for joining the design review today! We all really appreciated you sharing this project with us and hope the following summarized feedback from our conversation is helpful:

  • The current messaging "Rendered with Parsoid" is rather technical and might be hard for some users to connect with potential visual bugs. Some suggestions for improving the clarity of the messaging to less technical users:
    • Frame the messaging around reporting bugs and on click through or hover, inform them about Parsoid
    • To increase familiarity with Parsoid, consider utilizing a unique symbol or icon that can be associated with the project
  • To improve bug tracking, consider linking to a feedback form or phab task and consider auto-capturing the page where the bug occurred. Growth has done something similar in the past and might be able to help with this.
  • Codex does not currently have a Toast component and the Message component currently being used is not intended to appear in this way, as it is meant to appear within the page itself.
    • It'd be helpful if this use case could be added to the Phab Task related to the missing Toast component
    • @DTorsani-WMF suggests to include this dismissible Message at the most global level possible within the markup of the page
  • Consider having a 'do not show again' option in the message or in Developer Tools
  • The toggle could also be the place for having a call to action to report bugs

cc @mwilliams

Thanks @cmadeo - added some more content and recommendations, especifically about the chip + a quick mock:

@cscott thank you so much for joining the design review today! We all really appreciated you sharing this project with us and hope the following summarized feedback from our conversation is helpful:

  • The current messaging "Rendered with Parsoid" is rather technical and might be hard for some users to connect with potential visual bugs. Some suggestions for improving the clarity of the messaging to less technical users:
    • Frame the messaging around reporting bugs and on click through or hover, inform them about Parsoid
    • To increase familiarity with Parsoid, consider utilizing a unique symbol or icon that can be associated with the project
  • Do not use the "Rendered with Parsoid" infochip at all. Most people, except the most technical of users, would be unlikely to connect any visual glitches in the page as being related to it being rendered with parsoid as the reason. Since the infochip is non-interactive, they also have no ability to "find out more" about what this is. Instead, consider the following:
    • Change to a tooltip or popover that enables someone to find out more about this and take action to file a bug or give feedback if needed.
    • Move this new element to a much less prominent location in the page, ideally below/next to the Tools menu where the toggle to switch between legacy and parsoid is.
    • Change the copy to something more active such as "Report display bugs" or "Learn about Parsoid" that speaks to why this element is on the page.

image.png (1×1 px, 499 KB)

  • To improve bug tracking, consider linking to a feedback form or phab task and consider auto-capturing the page where the bug occurred. Growth has done something similar in the past and might be able to help with this.

Specifically When an editor submits a question to their mentor/help desk via the Help Panel, there is an option to include the article page title to the talk page topic that is posted:

image.png (554×740 px, 59 KB)

  • Codex does not currently have a Toast component and the Message component currently being used is not intended to appear in this way, as it is meant to appear within the page itself.
    • It'd be helpful if this use case could be added to the Phab Task related to the missing Toast component
    • @DTorsani-WMF suggests to include this dismissible Message at the most global level possible within the markup of the page
  • Consider having a 'do not show again' option in the message or in Developer Tools
  • The toggle could also be the place for having a call to action to report bugs
  • Changing the toggle copy to something like "Switch to legacy parser" may help make it clearer that is can be toggled back and forth

Change #1034112 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/extensions/ParserMigration@master] Use "switch to" language for toolbar link

https://gerrit.wikimedia.org/r/1034112

Change #1034112 merged by jenkins-bot:

[mediawiki/extensions/ParserMigration@master] Use "switch to" language for toolbar link

https://gerrit.wikimedia.org/r/1034112