Page MenuHomePhabricator

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

Description

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

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 taps to edit in the suggested edits workflow on mobile, it should be the visual editor that opens, not the wikitext editor. The only exceptions are (not all of these may apply to mobile):

  • 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 tap edit on a suggested edit, switch to wikitext on purpose, then tap 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

@RHo -- could you please have a think about this task? And perhaps we'll be able to implement something in next week's train?

RHo added a comment.EditedJun 12 2020, 4:35 PM

@MMiller_WMF - I created a sub-task T255074 for the proposal to add a notice to nudge users back to using VE, assuming this task will be to proceed with the short term solution to switch to VE by default across browsers. Is that correct, or should that subtask be closed and made into this task?

I see this on enwiki and mediawiki.org but not on cswiki or frwiki:

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.

My vote would be that any time (not just the first time) that a user clicks on a suggested edit card, pretend that the user's previous edit was in VisualEditor, so that VE loads by default. Yes, for users who have explicitly set this preference (which doesn't seem to be surfaced on all wikis), it might be a bit disorienting but OTOH I don't think those users are the ones we are trying to reach with this feature, and it's not a big inconvenience for those users to toggle to VE, but it will be much more confusing for brand new users to see guidance for something that isn't in front of them.

Tgr added a comment.Jun 15 2020, 8:08 PM

AIUI a wiki not having that preference means either that VE is still in beta and not available to most newbies, or that both tabs are always shown (in which case we don't have a problem, at least on desktop).

MMiller_WMF renamed this task from Newcomer tasks: nudge to visual editor to Newcomer tasks: nudge to visual editor (mobile).Jun 16 2020, 12:42 AM
MMiller_WMF renamed this task from Newcomer tasks: nudge to visual editor (mobile) to Newcomer tasks: switch to visual editor (mobile).
MMiller_WMF removed RHo as the assignee of this task.
MMiller_WMF updated the task description. (Show Details)
MMiller_WMF updated the task description. (Show Details)
MMiller_WMF removed a subscriber: JTannerWMF.

@Catrope -- this is ready for you to think about. Please read through the task description because there are some relevant specifications in there.

Change 607036 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] WIP: Prefer VE on mobile

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

kostajh claimed this task.Jun 22 2020, 7:31 PM

I'll elaborate a little on the WIP patch and then combine this with T255074: Newcomer tasks: notice to switch to VE within guidance

For instance, the user may tap edit on a suggested edit, switch to wikitext on purpose, then tap 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.

I left this part for a follow-up because IMO we should clarify the business rules around it before writing code. The other parts of this task are covered in the patch (default to VE on mobile, unless the user has some other setting specified for their visualeditor-tabs preference).

Change 607357 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] Guidance: Don't force VE on mobile if last editor was wikitext

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

Change 607036 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Guidance: Prefer VisualEditor for mobile editor

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

Change 607357 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] Guidance: Don't force VE on mobile if last editor was wikitext

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

This patch is me implementing an offhand suggestion Kosta made, before I realized that he was just thinking out loud and we hadn't actually decided whether we want this.

Right now (in beta labs), we force the user into VE if they have the "Remember my last editor" preference set, regardless of what their previous editor was, or if there even was a previous editor at all. (Technical note: we do this by overwriting the record of what their last editor was to say "visual editor".) Kosta proposed two alternatives:

  1. (My patch:) Force VE, except if the user's previous editor was wikitext. This would cause VE to only be opened for users who used VE the most recent time they edited on mobile, or who have never edited on mobile before.
  2. (Later refinement of #1): Force VE, except if the user switched to the wikitext editor the most recent time they made a suggested edit on mobile. This would still cause VE to be opened for users who have previously used the wikitext editor on mobile, except if they did so specifically in the context of a suggested edit.

I think #2 would be the better approach of these two (my patch implements #1, but that's because I wrote it before Kosta suggested #2). But this is really a decision that @MMiller_WMF and @RHo should make.

@Catrope @kostajh -- thanks for thinking and asking about this. I do prefer #2 to #1, because it does a good job of respecting a choice the user made on their editors, without it being too easy to accidentally get stuck in the wikitext world (for instance, if they had recently edited a talk page). But I want to ask for some more specificity. What would happen in these scenarios:

  • User clicks edit for the first time on a suggested task. They are forced into VE. They then switch to wikitext and save an edit. Then they click edit on a different suggested task. Desired behavior: wikitext.
  • User clicks edit for the first time on a suggested task. They are forced into VE. They then switch to wikitext. Then they switch back to VE and save an edit. Then they click edit on a different suggested task. Desired behavior: VE.
  • User clicks edit for the first time on a suggested task. They are forced into VE. They then switch to wikitext. Then they go away and do something else. Then they go back to their homepage and choose a different suggested task and click edit. Desired behavior: VE.

After writing those out, I think the desired behavior would that it would maintain the wikitext preference if that was the editor the user was using when they saved the edit. Is that what the patch does? What do you think?

MMiller_WMF updated the task description. (Show Details)Jun 25 2020, 12:32 AM

@kostajh @Catrope -- could you speak to the questions I asked in my previous comment? Also I just edited the task description (as I did for the desktop task) to include the full complement of preferences related to Visual Editor that we want to respect. Is it possible to include those at this point, or to split them to another task?

I agree that the behavior you describe would be better: only record a change in the last-used editor if the user (attempts to) save an edit with that editor. However, the current behavior in VisualEditor and MobileFrontend seems to change the last-used editor when switching. We may be able to implement this behavior for suggested edits only, I'll look into that. But I think you should also talk to the Editing team about what the "last editor" behavior should be generally, because right now we're just piggybacking on that.

@Catrope -- so with respect to the three scenarios I listed, it sounds like you're saying the current implementation would affect the desired behavior only for the third scenario? That if the user switches to wikitext inside the context of a suggested edit (whether they save or not), they'll have wikitext the next time they start a suggested edit?

And I want to make sure we're talking about this all in the context of suggested edits. In other words, the following scenario would also be true: User clicks edit for the first time on a suggested task. They are forced into VE. They then go away and edit some other article, switching to wikitext and saving the edit with wikitext. Then they go back to their homepage and choose a different suggested task and click edit. Desired behavior: VE.

Is that right?

And what do you think about the full complement of editor preferences I added to the task description?

And what do you think about the full complement of editor preferences I added to the task description?

From what I can tell, MobileFrontend doesn't do anything with the Temporarily disable the visual editor while it is in beta preference, so I don't think we should do anything special in our code to account for it being set. (Like, I don't think we should try to hide the VE button for example.)

Overall, I would like to propose we keep the approach that is currently in beta labs, where tapping the Edit pencil defaults to VE unless the user has their preferences set to anything other than "Remember my last editor". Implementing this is four lines of code, and adding more scenarios to this (like: only do X if the user did Y in suggested edits mode, but not if they have preference Z set) would come at a cost of more code complexity that seems to have diminishing returns from the overall goal, which is to try to put VE in front of new users as a more friendly editing environment.

@Catrope -- so with respect to the three scenarios I listed, it sounds like you're saying the current implementation would affect the desired behavior only for the third scenario? That if the user switches to wikitext inside the context of a suggested edit (whether they save or not), they'll have wikitext the next time they start a suggested edit?

Yes, that's right. I should also correct what I said before: the "in the context of a suggested edit" change would also require us to do our own preferred editor tracking, so making that on save instead of on switch probably wouldn't be much more work. I'll try to implement either/both of these now.

We decided today to keep this simple: always switch to VE when the user opens a suggested edit, unless they have an explicit preference for wikitext. I believe this is now in code review with code that does that.

Change 607357 abandoned by Catrope:
Guidance: Don't force VE on mobile if last editor was wikitext

Reason:
We decided we don't want to do this, see task

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/ /607357

Kosta's patch, which is already merged, implements the simple behavior. I've abandoned my patch.

We decided today to keep this simple: always switch to VE when the user opens a suggested edit, unless they have an explicit preference for wikitext. I believe this is now in code review with code that does that.

Checked it in testwiki wmf.39. Behaves as expected.
(1) If a user has a default setting "Remember my last editor", then on mobile all Suggested edits articles will be open in VE; does not matter if users' previously saved edits were in wikitext editor (on normal or SE artciles).
the above behavior is different on desktop - "Remember my last editor" setting will not be overridden.

(2) A user has "Always give me the source editor" preference - the wikitext editor will be given in all contexts - normal articles and SE articles.

@kostajh -- if the user has "Show me both editor tabs" set, then it no longer forces VE open on mobile (according to my testing). Could you please look into that? It should be opening VE for all the preferences settings except "Always give me the source editor".

@kostajh -- if the user has "Show me both editor tabs" set, then it no longer forces VE open on mobile (according to my testing). Could you please look into that? It should be opening VE for all the preferences settings except "Always give me the source editor".

There is a note: "You are using the original editor. The following editing tips work best in the visual editor." The note will be displayed on mobile for all Editor options in Special:Preferences

Having no link to switch to VE on mobile is based on the following patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/ /606686 ( in T255074)

Mobile switching is not implemented. Users are opted into VE by default so they should understand how to switch back when the warning notice instructs them to. Providing a link to initiate mobile switching would
require some changes to MobileFrontend, and that's left for a follow up.

There should be a follow up?

There should be a follow up?

@Catrope and I talked about it a little; it doesn't seem worth the effort at this point for a few reason:

  • The user will be in VE, so if they are looking at Wikitext, it's because they already switched and therefore presumably know how to do it themselves
  • due to bugs with how iOS Safari handles overlays and specifically overlays on top of editable surfaces (e.g. the visual/source editor), our code for mobile detaches the editor entirely from the browser DOM. In order to switch the editor, we'd have to:
    • write code for MobileFrontend that triggers switching editors in response to a hook being fired, and get that merged
    • write code for GrowthExperiments that waits for the help panel to close and for the editor to be reattached, then trigger the switch, which will probably look a little weird to the user because the time between when they tapped "Switch editor" and when that actually happens could be fairly significant (like, suppose they tapped "Switch editor" then started looking through other guidance tips. Maybe the UX could be something like showing a toast with "The editor will switch to VE when you close the help panel")

Anyway, it's enough work that, given the first point about how the user would already know how to switch, doesn't seem worth it. But if we think it's important, let's do it :)

@kostajh -- if the user has "Show me both editor tabs" set, then it no longer forces VE open on mobile (according to my testing). Could you please look into that? It should be opening VE for all the preferences settings except "Always give me the source editor".

Hmm, I think at some point this task might have said to show VE when the user preference is "Remember my last editor", because that's what we implemented in the code, but yes I will rework for what you've written here.

Change 611302 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Guidance on mobile: Use VE unless user explicitly selected "prefer wikitext"

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

On mobile with "Show me both editor tabs" preference, it falls back to "Remember my last editor" option.

Change 611302 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Guidance on mobile: Use VE unless user explicitly selected "prefer wikitext"

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

Etonkovidova added a comment.EditedFri, Jul 17, 10:23 PM

For @MMiller_WMF review

On mobile - the logic with editor tabs is simpler than on desktop

  • Unlike the desktop- the two editor options - VE and the source editors - will be always present even if "Temporarily disable the visual editor while it is in beta" or "Always give me the source editor".
  • the SE editing context is independent from normal editing context, i.e. a user makes several edits on non-SE articles in source editor ->then clicks to edit a SE article -> VE will be displayed.

So, there are two venues of editing contexts which do not affect each other - SE articles (for two cases a user's choice will be preserved) and non-SE articles where the option "Remember my last editor" seems always true for mobile.

Editing options SE contextnon-SE context
Remember my last editor (default option)always VE - even if a user makes/saves edits in source editorlast editor remembered
Always give me the visual editor if possiblealways displays VElast editor remembered
Always give me the source editorlast editor rememberedlast editor remembered
Show me both editor tabsalways displays VElast editor remembered
Temporarily disable the visual editor while it is in beta (a standalone option)last editor rememberedlast editor remembered