Page MenuHomePhabricator

Newcomer tasks: switch to visual editor (desktop)
Open, Needs TriagePublic

Description

Separate work is required for the desktop and mobile versions of this task. This is the desktop version, and this is its mobile counterpart: T254823: Newcomer tasks: switch to visual editor (mobile)

We want users to experience newcomer tasks in the visual editor, as opposed to the wikitext editors. This is because we believe the visual editor will be a better experience for newcomers, and that they will be more likely to succeed in their first edits. Likewise, our guidance content (T245786) is written geared toward the visual editor (though it is possible to write separate guidance content geared toward the wikitext editor).

Our original plan for doing this was as follows (from T244431):

On single-tab editor wikis, we want users who click edit from the newcomer tasks workflow to have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings. But we should only send the user into visual editor the first time they open a suggested edit. If they visit a suggested edit task, and subsequently change over to the wikitext editor, on their next suggested edit, their preferred editor should open.

In considering this further, we've talked about whether this would be disorienting for users who have done either of these things:

  • Users who had previously switched over to wikitext editors in previous edits.
  • Users who explicitly set their preference to always default to wikitext.

Therefore, here is what we want to do so that the user has a simple, and not confusing, experience: every time a user clicks to edit in the suggested edits workflow on desktop for wikis that have the single edit tab, it should be the visual editor that opens, not the wikitext editor. The only exceptions are:

  • if the user has an editor preference set to "Always give me the source editor", we should follow that preference.**
  • if the user has an editor preference set to "Show me both editor tabs", we should treat their experience like we would on a wiki that has two tabs. This means putting our pulsing blue dot on the "Edit" button, and not altering the editor that appears when they click edit.
  • if the user has the editor preference checkbox set to "Temporarily disable the visual editor while it is in beta", we should only give them the wikitext editor when they click Edit.

We recognize that though this clarifies one behavior for the user (VE always opens with the suggested edits workflow), it may be confusing or annoying in other ways. For instance, the user may click edit on a suggested edit, switch to wikitext on purpose, then click to read the article again for a minute, then switch back to editing and need to change editors back to wikitext again. As we look into how to do this technically, we should identify opportunities to decrease this kind of annoyance for the user.

Event Timeline

kostajh claimed this task.Jun 22 2020, 7:32 PM
kostajh moved this task from Incoming to In Progress on the Growth-Team (Current Sprint) board.
MMiller_WMF updated the task description. (Show Details)Jun 25 2020, 12:29 AM
MMiller_WMF removed a subscriber: JTannerWMF.

@kostajh @Catrope -- I just updated the task description to include the full complement of preferences that are related to the Visual Editor that we would want to respect. Is it easy to include them at this point? Or split them to a separate task?

This looks like it will be kind of complicated to implement. On single edit tab wikis, VisualEditor resolves the question of "show wikitext or VE?" after "Edit" is clicked by looking at the user's preference for visualeditor-editor, which defaults to wikitext unless a wiki configuration has set it to visualeditor. I started looking at ways to override this, for example by:

  • having our homepage suggested edit card set a query parameter like &veeditoroverride=visualeditor when arriving at the page
  • patch VisualEditor to look for that override in VisualEditorHooks.php
  • update the suggested edit card code to add veeditoroverride to the Edit tab
  • remove the query parameter via client-side JS

It's mostly working, but complicated and I'm not sure if others would use this functionality too.

@MMiller_WMF I'm wondering if we could consider opting GrowthExperiments users into VE as their default on single edit tab wikis, by setting their visualeditor-editor preference to visualeditor. This would be far simpler and more robust. But it would also impact other editing, not just the suggested edits guidance flow related edits.

@kostajh -- I think your comment is about implementing this task as a whole, right? Not responding to my question from T255514#6255225? In that case...

  • All of the SET (single edit tab) wikis in which we work so far already have VE as the default, so that's good. According to @Esanders, there are 10 Wikipedias that do not use it as the default; four of them on the larger side (en, es, he, zh) and six on the smaller side (gan, iu, kk, shi, tg, uz). Some of these wikis have made a conscious choice to prefer VE, and some can't use VE for technical reasons related to their languages.
  • There are two use cases that I think we're trying to cover in this task:
    • The user is in a SET wiki that has wikitext as the default.
    • The user most recently was in the wikitext editor (perhaps on a talk page), and therefore would have the wikitext editor for their next edit.
  • Regarding the first use case, I think that's the less important one to handle. For wikis that do not have VE as their default, they may prefer for users to do suggested edits, and therefore receive suggested edit guidance, using wikitext. In that same vein, I do not think we can opt GrowthExperiments users into VE as their default.
  • I think that we are really trying to handle that second use case, in which the user is on a VE-by-default wiki, but has somehow ended up using wikitext. We want them to experience suggested edits with VE.

Does this help clarify or focus the scope of the work here? If, in your judgment, this has expanded beyond what we originally estimated doing for desktop, perhaps we should reconsider whether to prioritize it. We can talk about it on Monday.

I think that we are really trying to handle that second use case, in which the user is on a VE-by-default wiki, but has somehow ended up using wikitext. We want them to experience suggested edits with VE.

OK, given what is written above, then I think there is nothing further to do here. In the scenario of a SET wiki, where VE is the default, this scenario should work according to what you've written without us making any further changes.

Additionally:

if the user has an editor preference set to "Always give me the source editor", we should follow that preference.**
if the user has the editor preference checkbox set to "Temporarily disable the visual editor while it is in beta", we should only give them the wikitext editor when they click Edit.

Both of these are handled by VE and don't require us to do anything special.

if the user has the editor preference checkbox set to "Temporarily disable the visual editor while it is in beta", we should only give them the wikitext editor when they click Edit.

(tested on testwiki and cswiki betalabs).
Yes, in this case ("Temporarily disable the visual editor while it is in beta" is enabled) a user does see 'Edit' tab (not 'Edit source' ). However, SE guidance panel still prompts a user to switch to VE.

When clicking on "Switch to the visual editor" - "Try to load the editor in wrong mode (datatype:"visual", editor mode: "$2") " error is displayed:


Click on 'Try again' will give another error - "There is no revision with ID 0."

Clicking on "Cancel" recovers to the normal Reading state.

@Etonkovidova -- thanks for finding this. @kostajh -- what do you think we should do in this case? Should we not show the link for these users? Show them an informative message? I do think they should have the banner, so that they can try to understand why buttons referenced in the tips are not present in their interface. I think we should do something simple and easy to handle this error.

Etonkovidova added a comment.EditedJul 1 2020, 1:20 AM

Tested on betalabs and testwiki wmf.39.
"Remember my last editor" is the default option and SE guidance panel does not interfere with it.

Case 1: default "Remember my last editor"
(1) To clarify VE behavior
(a) - on betalabs I created a new user in

  • kowiki - single tab VE
  • cswiki - double tab
  • viwiki - double tab
  • arwiki - single tab 'Edit source'

Note: All notes below are for single-tabbed wikis. Two-tabbed wikis behavior is as expected - two tabs are always present.

(b) On wikis with the single tab, when I click to Edit, a dialog asks if I want to use another editor. I did not see the dialog asking me to set the preference - i.e. "Only show me source editor' or "Always show two tabs", or "Remember the last editor I used".

(c) On both single-tabbed wikis (and on testwiki wmf.39) in production, the editor where the last editing activity happened, would be presented as a single tab for the next edit.

(2) Suggested edit guidance panel prompts a user to switch to VE, and if an edit was saved, well, VE will be presented for the next round of editing activity.

Etonkovidova added a comment.EditedJul 1 2020, 1:44 AM

Case 2. Users who set the option " Always give the source editor" - the post-edit dialog disappears.

  • works as expected - SE guidance panel doesn't interfere with the setting, i.e. the switch to VE will not persist for non-SE articles.
  • there is an issue with the post-edit dialog - it flashes and disappears before a user has a chance to interact with it. In the below gif - no clicks or any actions are done on a user part after saving an edit.
  • a user on SE article
  • clicks Edit - the source editor is open sine it's set as a preference
  • a user looks at the SE guidance panel and sees the prompt to switch to VE, clicks on the link
  • types "Test" and saves this edit in VE

No user actions after that

  • the screen flashes the just edited article in Source editing mode with the postedit dialog - it happens also without SE panel
  • then switches to the Read mode with the postedit dialog
  • and then spontaneously dismisses the postedit dialog

Click on the animated gif below:

Tgr added a comment.Jul 1 2020, 8:33 PM

Case 2. Users who set the option " Always give the source editor" - the post-edit dialog disappears.

Yeah, we don't handle it well when VE fires the postEdit event and then immediately reloads the page.
It didn't occur to me when this issue came up int the past, but it's probably pretty easy to work around - just defer showing the panel if the URL looks like an edit URL.

@Etonkovidova -- thanks for finding this. @kostajh -- what do you think we should do in this case? Should we not show the link for these users? Show them an informative message? I do think they should have the banner, so that they can try to understand why buttons referenced in the tips are not present in their interface. I think we should do something simple and easy to handle this error.

Yeah I think we could look for that preference in particular, or check to see if the VE switching code is available, before rendering the switch link.

Etonkovidova moved this task from QA to Design Review on the Growth-Team (Current Sprint) board.EditedJul 2 2020, 2:54 AM

To summarize for @RHo :and @MMiller_WMF review:

  • there are four options for Editing mode in Special:Preferences and one stand-alone option (the issues for some options are summarized below in the table)
  • wikis might be two-tabs or single-tab wikis - which does not affect switching to VE specifically.
Editing options SE guidance panel link effect
Remember my last editor (seems to be a default option)does not interfere with the editing workflow but shows the pulsing dot on "Edit source"
Always give me the visual editor if possibleNo issues
Always give me the source editormy comment - the post-edit dialog disappears - might be easy to fix
Show me both editor tabsNo issues
Temporarily disable the visual editor while it is in beta (a standalone optionmy comment - VE produces errors

Notes: Additional edge cases
I just give brief description so to decide if they are worth digging into

  • a user has the option to move a page (depending on a wiki such option might be available to users with just Autoconfirmed status (e.g. enwiki). Special:MovePage/[Page Title] won't display the guidance dialog and when a user returns back to the page (not actually performing a move) by clicking any of the available tabs - Read, Edit, Edit source, View history - only Help panel will be present in Edit modes.

"Delete" and "Protect" options do display the guidance panel.

  • the article discussion namespace isn't VE enabled (for example, it's a case for cswiki), so if a user goes to a SE article discussion page and starts to make some edits/posts there and attempts to switch to VE via the guidance panel link - the same VE errors will be present as for the option "Temporarily disable the visual editor while it is in beta".
  • (not related to this phab task) Making an edit on an article discussion page will bring the post-edit dialog box.
RHo added a comment.Jul 2 2020, 11:01 AM

To summarize for @RHo :and @MMiller_WMF review:

  • there are four options for Editing mode in Special:Preferences and one stand-alone option (the issues for some options are summarized below in the table)
  • wikis might be two-tabs or single-tab wikis - which does not affect switching to VE specifically.
Editing options SE guidance panel link effect
Remember my last editor (seems to be a default option)does not interfere with the editing workflow but shows the pulsing dot on "Edit source"

@MMiller_WMF - This seems OK to me since we will have the message about switching.

Always give me the visual editor if possibleNo issues
Always give me the source editormy comment - the post-edit dialog disappears - might be easy to fix

@MMiller_WMF @Tgr - should this be filed as a separate bug?

Show me both editor tabsNo issues
Temporarily disable the visual editor while it is in beta (a standalone optionmy comment - VE produces errors>>

Again @MMiller_WMF do we want to file as new task the proposed fix to remove the "Switch to VE" link in this case (mentioned on T255514#6272994 by @kostajh)?

Notes: Additional edge cases
I just give brief description so to decide if they are worth digging into

  • a user has the option to move a page (depending on a wiki such option might be available to users with just Autoconfirmed status (e.g. enwiki). Special:MovePage/[Page Title] won't display the guidance dialog and when a user returns back to the page (not actually performing a move) by clicking any of the available tabs - Read, Edit, Edit source, View history - only Help panel will be present in Edit modes.

"Delete" and "Protect" options do display the guidance panel.

Agree this is an edge case. I think it's OK.

  • the article discussion namespace isn't VE enabled** (for example, it;s a case for cswiki), so if a user goes to an SE article discussion page and starts to make some edits/posts there and attempts to switch to VE via the guidance panel link - the same VE errors will be present as for the option "Temporarily disable the visual editor while it is in beta".

Would this be solved by the same fix as above by removing "switch to VE" link? Even if not, seems edgy enough to be leave alone.

  • (not related to this phab task) Making an edit on an article discussion page will bring the post-edit dialog box.

That is not expected but reasonably minor (considering newcomers are less likely to edit the talk page). Filed as T256955.

Tgr added a comment.Jul 2 2020, 1:36 PM
  • a user has the option to move a page (depending on a wiki such option might be available to users with just Autoconfirmed status (e.g. enwiki). Special:MovePage/[Page Title] won't display the guidance dialog and when a user returns back to the page (not actually performing a move) by clicking any of the available tabs - Read, Edit, Edit source, View history - only Help panel will be present in Edit modes.

"Delete" and "Protect" options do display the guidance panel.

The suggested edit session is defined as a sequence of page views to the same page. Page moving is implemented via a special page (unlike e.g. history or delete which are page actions) so technically it's a different page, and visiting it terminates the session. It would be very easy to fix, but I don't think it has any real-world consequence - news users don't even see the move option until they are autoconfirmed, and it's unlikely to be a meaningful action for suggested edits as long as we don't have new article creation as a suggested task.

Tgr added a comment.Jul 2 2020, 7:27 PM

Case 2. Users who set the option " Always give the source editor" - the post-edit dialog disappears.

Yeah, we don't handle it well when VE fires the postEdit event and then immediately reloads the page.
It didn't occur to me when this issue came up int the past, but it's probably pretty easy to work around - just defer showing the panel if the URL looks like an edit URL.

Ugly but works: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/609223

T253133#6172806 is my idea for a nice solution: provide an easy mechanism for firing postEdit, or a new hook, after page reload.

Moving to PM review since the questions on T255514#6274151 are for @MMiller_WMF anyway.

Change 610779 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] SwitchEditorPanel: Don't show if the current title is a talk page

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

Change 610780 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] SwitchEditor: Don't show link if VE is disabled or lib is unavailable

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

@Etonkovidova -- thanks for finding this. @kostajh -- what do you think we should do in this case? Should we not show the link for these users? Show them an informative message? I do think they should have the banner, so that they can try to understand why buttons referenced in the tips are not present in their interface. I think we should do something simple and easy to handle this error.

Handled here: https://gerrit.wikimedia.org/r/610780, basically, we don't show the "Switch link" text for this scenario.

@Etonkovidova -- can you please re-test the things that @kostajh and @Tgr fixed above? Specifically, these three things:

Change 610779 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] SwitchEditorPanel: Don't show if the current title is a talk page

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

Change 610780 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] SwitchEditor: Don't show link if VE is disabled or lib is unavailable

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

Apologies for the slow code review; the patches that @MMiller_WMF asked @Etonkovidova to QA in his most recent comment are now merged.

@Etonkovidova -- can you please re-test the things that @kostajh and @Tgr fixed above? Specifically, these three things:

  • Users who set the option " Always give the source editor" - the post-edit dialog disappears (from my comment)

Done - checked in production wmf.41 testwiki.

  • for users who enabled the option "Temporarily disable the visual editor while it is in beta"

Done. The patch is only in betalabs, not in production yet. As per @kostajh comment :

Handled here: https://gerrit.wikimedia.org/r/610780, basically, we don't show the "Switch link" text for this scenario.

  • Talk pages with not enabled VE

Done as in above - no link to switch to VE in the guidance panel -the fix is not in production yet, checked in betalabs.

I'll be checking the two fixes - for the option "Temporarily disable the visual editor while it is in beta" and for the Talk pages in testwiki after deployment.