Page MenuHomePhabricator

Add a link: edit mode toggle (machine suggestions & visual)
Open, HighPublic

Description

While doing machine suggestions, the user is in a new "mode" of the visual editor (the other two being visual and source modes). The new mode is "machine suggestions" mode, as described in T269638: Add a link: Suggestions mode.

  • It only possible to get into this mode via the suggested edits feed or the post-edit dialog from doing a suggested edit. Users cannot toggle into this mode when they are just editing under normal circumstances, though in the farther future, they will be able to.
  • Users cannot combine link suggestions with other kinds of edits. They can do one or the other. If they leave "Suggestions" mode, their progress is gone. Same with if they toggle over to visual or source mode, make some changes, and then toggle back to machine suggestions mode: their progress is gone.
  • When the user is in machine suggestions mode, they can toggle out of the mode with the edit pencil mode dropdown in the upper right of the editor.
  • When the user selects that mode dropdown, they will see two modes. "Suggestions" will be the first one in the list, in blue, and with a robot icon. Below it will be the "Visual editing". Toggling to and from source is tracked separately via T285785: Add a link: support toggling between source and machine suggestion modes.
  • When the user selects the visual mode, they will get a modal that asks them to confirm they want to leave machine suggestions mode if they have unsaved changes regardless of whether useeditwarning preference is set. If they leave machine suggestions mode, their progress will be lost and unrecoverable.
    • Header: "Leave AI suggestions?"
    • Body: "Switching modes will allow you to make other kinds of edits. Finish reviewing to submit your progress so far."
    • First button option: "Switch without submitting"
    • Second button option: "Cancel"
  • If the user selects "x" on the toolbar, they will see the standard dialog shown when a change is made in editor mode on VE and source.
  • Once in visual or source mode, they can edit and publish like normal. Publishing through visual or source mode does not lead them to any special post-edit workflows. It's just normal.
  • Users can also switch back to machine suggestions mode with the toggle, which will put them back at the beginning of the link suggestion flow as if they had not started yet, i.e. where they were right after the onboarding. If they made some changes in visual or source mode and then want to switch back to machine suggestions mode, they should get the dialog that you get in the editor when you are going to close the window and lose your edits, the one that says: "Are you sure?"

For wikis that have multiple edit tabs, yes, the "Edit source" tab should do the same thing as the edit mode toggle (show the special dialog, etc.)

But for all other ways to exit the experience (e.g. clicking "Read", clicking a left nav item, clicking the Wikipedia logo, etc.) we should hand the user the standard "you are exiting the editor" experience.

In some cases, like clicking the left nav, that looks like this:

image.png (168×436 px, 22 KB)

And in other cases, like clicking "Read", that looks like this:

image.png (163×320 px, 13 KB)

Inheriting all of that is fine.

Mobile mockups as of 2021-01-12:
image.png (335×450 px, 14 KB)
image.png (453×261 px, 15 KB)
Desktop mockups as of 2021-01-12:
image.png (538×631 px, 58 KB)
Screenshot of dialog when user selects "x" on the editor toolbar
image.png (1×724 px, 109 KB)

NOTE: Refer to Figma for up-to-date detailed redline mocks and specs:
Mobile: https://www.figma.com/file/2SONd8P1tsexIB5coMOp8h/Growth-Structured-tasks?node-id=181%3A65
Desktop: https://www.figma.com/file/2SONd8P1tsexIB5coMOp8h/Growth-Structured-tasks?node-id=112%3A0

Instrumentation

See T278115: Instrumentation: Edit mode toggle for details.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
kostajh moved this task from Post-release backlog to Backlog on the Add-Link board.

The engineers discussed this in our meeting yesterday and propose this as a candidate task for after the initial release.

If we don't do this for initial release, the UX would basically be to only allow the user to experience AI suggestions mode when navigating to a link recommendation task from Special:Homepage. We'd have to think about how that might interact with T278485: Inspector does not open after reloading the page on desktop in case a user was trying to Ctrl + R to get to a regular editor, but on the other hand, if we're aiming to reduce scope to ship earlier, maybe that particular scenario doesn't matter that much. cc @RHo and @MMiller_WMF

The engineers discussed this in our meeting yesterday and propose this as a candidate task for after the initial release.

If we don't do this for initial release, the UX would basically be to only allow the user to experience AI suggestions mode when navigating to a link recommendation task from Special:Homepage. We'd have to think about how that might interact with T278485: Inspector does not open after reloading the page on desktop in case a user was trying to Ctrl + R to get to a regular editor, but on the other hand, if we're aiming to reduce scope to ship earlier, maybe that particular scenario doesn't matter that much. cc @RHo and @MMiller_WMF

Hi @kostajh - fair enough about moving this to later release, but in that case I wanted to confirm in that case that the edit pencil icon dropdown to switch editor modes should not be shown at all. Is that right?
Secondly, in the scenario you describe with the bug T278485, where reloading doesn't bring back the page - if the user then tries to bring it back by first backtracking (selecting browser back) to their homepage, will the suggested article still be shown? Asking because if they are able to return to the article from the homepage, then it would be annoying but not as frustrating as losing the ability to do the suggested edit on the article entirely.

The engineers discussed this in our meeting yesterday and propose this as a candidate task for after the initial release.

If we don't do this for initial release, the UX would basically be to only allow the user to experience AI suggestions mode when navigating to a link recommendation task from Special:Homepage. We'd have to think about how that might interact with T278485: Inspector does not open after reloading the page on desktop in case a user was trying to Ctrl + R to get to a regular editor, but on the other hand, if we're aiming to reduce scope to ship earlier, maybe that particular scenario doesn't matter that much. cc @RHo and @MMiller_WMF

Hi @kostajh - fair enough about moving this to later release, but in that case I wanted to confirm in that case that the edit pencil icon dropdown to switch editor modes should not be shown at all. Is that right?

Yes, I think if we cut this from initial release then there would be no edit mode dropdown in the top right. (Aside: I understand that this is an important task and am not proposing to delay it indefinitely, just that it might be something we could work on after the project goes live.)

Secondly, in the scenario you describe with the bug T278485, where reloading doesn't bring back the page - if the user then tries to bring it back by first backtracking (selecting browser back) to their homepage, will the suggested article still be shown? Asking because if they are able to return to the article from the homepage, then it would be annoying but not as frustrating as losing the ability to do the suggested edit on the article entirely.

I can't remember if we intentionally established some rules around this, but the status quo on desktop is that clicking a task card and then clicking back shows you the first item in the task card queue. But if you click the second item in the task card queue and then click back to return to Special:Homepage, you see the first task card in your queue and not the second. On mobile, navigating back in the browser from an article shows you the suggested edits feed with a shuffled task queue.

The engineers discussed this in our meeting yesterday and propose this as a candidate task for after the initial release.

If we don't do this for initial release, the UX would basically be to only allow the user to experience AI suggestions mode when navigating to a link recommendation task from Special:Homepage. We'd have to think about how that might interact with T278485: Inspector does not open after reloading the page on desktop in case a user was trying to Ctrl + R to get to a regular editor, but on the other hand, if we're aiming to reduce scope to ship earlier, maybe that particular scenario doesn't matter that much. cc @RHo and @MMiller_WMF

Hi @kostajh - fair enough about moving this to later release, but in that case I wanted to confirm in that case that the edit pencil icon dropdown to switch editor modes should not be shown at all. Is that right?

Yes, I think if we cut this from initial release then there would be no edit mode dropdown in the top right. (Aside: I understand that this is an important task and am not proposing to delay it indefinitely, just that it might be something we could work on after the project goes live.)

Agree, it sounds like a reasonable piece to carve off for initial release.

Secondly, in the scenario you describe with the bug T278485, where reloading doesn't bring back the page - if the user then tries to bring it back by first backtracking (selecting browser back) to their homepage, will the suggested article still be shown? Asking because if they are able to return to the article from the homepage, then it would be annoying but not as frustrating as losing the ability to do the suggested edit on the article entirely.

I can't remember if we intentionally established some rules around this, but the status quo on desktop is that clicking a task card and then clicking back shows you the first item in the task card queue. But if you click the second item in the task card queue and then click back to return to Special:Homepage, you see the first task card in your queue and not the second. On mobile, navigating back in the browser from an article shows you the suggested edits feed with a shuffled task queue.

Yes, I've just checked and you're right it looks like on Desktop *only* the first article in the queue is kept when navigating back on a task. And actually it's the same behaviour on Mobile as well (the first article is always maintained, second and subsequent always lost). Given that is the case... what is the complexity in changing the rules so that people's articles aren't lost on going back to their queue? Asking not only for this task, but think we should amend this unexpected "randomising" task queue behaviour independently. What do you think @MMiller_WMF ?

@kostajh -- thank you for thinking about which tasks can be cut from scope. I think it is okay to release to our four pilot wikis without this task, but that we would need to complete it before deploying to additional wikis. It's because an important component in structured tasks is that the user can find their way to more ambitious work if they want to, and the edit toggle is the most important pathway we'd planned to make available in this structured task. This would mean that we would make it our top priority after releasing to our pilots (in addition to any other urgent bug fixes). Does that sound okay?

@RHo -- about "losing your place in the feed when using back button", I think we can file a task about that, but I'm not sure if we should prioritize it. In what scenarios do we expect users to click "Back"? Is it because they see the article, decide they don't want to edit it after all, and want to keep going in their feed? I could imagine that happening, and I suppose it would lead to users opening suggestions in new tabs so they don't lose their place.

@kostajh -- thank you for thinking about which tasks can be cut from scope. I think it is okay to release to our four pilot wikis without this task, but that we would need to complete it before deploying to additional wikis. It's because an important component in structured tasks is that the user can find their way to more ambitious work if they want to, and the edit toggle is the most important pathway we'd planned to make available in this structured task. This would mean that we would make it our top priority after releasing to our pilots (in addition to any other urgent bug fixes). Does that sound okay?

That sounds fine. I think we could also place it towards the end of the queue of scheduled work, and decide closer to completion if we want to push to include it in initial release or not. If we don't do it in the initial release, we'll have to be a bit more careful in the QA process (for functionality and instrumentation) to ensure that when we roll it out, all the other pieces still work as intended. Like, maybe we could merge it just after the branch cut happens so that there is a week for QA in beta before it arrives in production with the train.

@RHo -- about "losing your place in the feed when using back button", I think we can file a task about that, but I'm not sure if we should prioritize it. In what scenarios do we expect users to click "Back"? Is it because they see the article, decide they don't want to edit it after all, and want to keep going in their feed? I could imagine that happening, and I suppose it would lead to users opening suggestions in new tabs so they don't lose their place.

@MMiller_WMF agree it is not that high priority. But there are two scenarios that come to mind. First is when someone mistakenly goes back, which even from just personal experience that can happen especially when browsing on mobile where there is an OS swipe left gesture to go back that can accidentally be triggered.
The second is if someone is deciding between a few articles they browse in the feed. Say they browse from the first article "Cream" to a second article "Diamond" and then 3rd is the "Pearl" article.
They open "Pearl" to check out what's involved and think they might go back to see what "Diamond" is about first before committing, but upon hitting back "Diamond" and "Pearl" are both no longer available to edit.

kostajh triaged this task as Medium priority.Apr 26 2021, 7:54 PM

@RHo @MMiller_WMF a couple of follow-up questions:

  1. What should happen if the user clicks the "Read" or "View history" tabs?
  2. What should happen if the user clicks on the Discussion tab?
  3. Should clicking on "Edit source" (if present) be treated the same as if the user had used the dropdown to switch to source editing mode?

@kostajh -- for wikis that have multiple edit tabs, yes, the "Edit source" tab should do the same thing as the edit mode toggle (show the special dialog, etc.)

But for all other ways to exit the experience (e.g. clicking "Read", clicking a left nav item, clicking the Wikipedia logo, etc.) we should hand the user the standard "you are exiting the editor" experience.

I see that in some cases, like clicking the left nav, that looks like this:

image.png (168×436 px, 22 KB)

And in other cases, like clicking "Read", that looks like this:

image.png (163×320 px, 13 KB)

Inheriting all of that is fine. If this sounds good, please say so and I'll add it to the task description. Or feel free to add it yourself.

I think we should go ahead with this task.

We decided (again) to move this back.

MMiller_WMF raised the priority of this task from Medium to High.Jun 7 2021, 5:11 PM

I was thinking about this task again in the context of 1) T284609: Add a link: [Mobile] Provide compact responsive view of link inspector on smaller devices and T281185: Add a link: [Desktop] Undismissable link inspector can obscure text, 2) our upcoming suggested image project T284778: Add Image: GrowthExperiments architecture sketch, 3) T269638: Add a link: Suggestions mode and 4) reflections about how VisualEditor is structured and opportunities for our code to interact with it, and I wanted to offer an alternative before we undertake this work.

tl;ldr rather than suppress everything in VisualEditor and attempt to define an entirely new editing mode, maybe we should just have link suggestion exist as a regular plugin alongside all the other ones – the only difference would be that we warn users (this task's scope) about exiting the plugin's user interface

Notes:

  1. The link suggestion interactions (the inspector, the accept/reject flow, etc) all happen through a plugin that we register with VisualEditor. VisualEditor has many plugins, things like the "Cite" and "Link" buttons are plugins
  2. When you have a plugin interface open in VE, you can't make other types of changes to the document. For example click the "Cite" button, if you try to click elsewhere, the Cite dialog closes; when the Cite dialog is open that is the only "mode" of editing available
  3. In both our mobile and desktop implementations, our plugin interface is always available and can't be dismissed (yet – that's what this task is for, of course)
  4. When we are showing link suggestions, we disable almost all other VisualEditor plugins (their context items and commands) from the interface and define a new type of editing mode ("machineSuggestions", alongside the "source" and "visual" modes). This is problematic for a few reasons:
    1. it's kind of hacky to iterate over all plugins and disable them, only to leave a couple in place. It led to all kinds of UX inconsistencies (like clicking/tapping on an image, or on an infobox) that we eventually ironed out, but it's not a great implementation IMO
    2. in some ways we are defining a new editing mode, but in other important ways, it's still "visual" editing mode in terms of how we interact with the VisualEditor API through our plugin. Based on what I see in this task, we will now likely need to provide a way to modify VisualEditor to allow for more editing modes that extension can define, and we'll also have to deal with extension/skin code that expects the hard-coded values of "source"/"visual". We can implement (another) hack to work around this, but to do it the non-hack way would probably be a pretty big effort.
    3. debatable, but IMHO by hiding all of the UX elements of the VisualEditor from the user, we're not introducing them to "normal" editing workflows, although again, I recognize that this is what the current task is about
    4. currently we just have one type of structured task, but how would the user switch between different types of structured tasks available for an article in this paradigm?

Anyway, given the above, plus the fact that image suggestions and other types of structured tasks are coming up, I wanted to suggest an alternative.

The idea is that instead of hiding all the VisualEditor plugins, we allow all of them to be shown. Alongside those plugins, we show an icon for our link suggestion plugin (the robot icon + a link, for example), and highlight it in the toolbar row:

image.png (924×1 px, 752 KB)

When the user clicks outside the inspector, they get the warnings shown in this task, and we would minimize the link inspector back into the link suggestions toolbar icon. Similarly, when the user wants to move the inspector to be able to read the text, we could minimize the inspector into the icon, and the user can click the icon again to bring up the link suggestion inspector.

When image suggestion or other structured tasks are added, those would also have their own icons and toolbar items. That would allow users to switch between different types of structured tasks available for the same article.

If we go this route, we could remove various hacks:

  • pretending that we have a new editing mode when it's really the visual editing mode that's under the hood
  • suppressing other plugins
  • removing the Edit source link

Sorry I didn't have these comments ready 6 months ago, but I don't think I could have reached these conclusions without my experience working on this project & with the VisualEditor code.

I was thinking about this task again in the context of 1) T284609: Add a link: [Mobile] Provide compact responsive view of link inspector on smaller devices and T281185: Add a link: [Desktop] Undismissable link inspector can obscure text, 2) our upcoming suggested image project T284778: Add Image: GrowthExperiments architecture sketch, 3) T269638: Add a link: Suggestions mode and 4) reflections about how VisualEditor is structured and opportunities for our code to interact with it, and I wanted to offer an alternative before we undertake this work.

tl;ldr rather than suppress everything in VisualEditor and attempt to define an entirely new editing mode, maybe we should just have link suggestion exist as a regular plugin alongside all the other ones – the only difference would be that we warn users (this task's scope) about exiting the plugin's user interface

Notes:

  1. The link suggestion interactions (the inspector, the accept/reject flow, etc) all happen through a plugin that we register with VisualEditor. VisualEditor has many plugins, things like the "Cite" and "Link" buttons are plugins
  2. When you have a plugin interface open in VE, you can't make other types of changes to the document. For example click the "Cite" button, if you try to click elsewhere, the Cite dialog closes; when the Cite dialog is open that is the only "mode" of editing available
  3. In both our mobile and desktop implementations, our plugin interface is always available and can't be dismissed (yet – that's what this task is for, of course)
  4. When we are showing link suggestions, we disable almost all other VisualEditor plugins (their context items and commands) from the interface and define a new type of editing mode ("machineSuggestions", alongside the "source" and "visual" modes). This is problematic for a few reasons:
    1. it's kind of hacky to iterate over all plugins and disable them, only to leave a couple in place. It led to all kinds of UX inconsistencies (like clicking/tapping on an image, or on an infobox) that we eventually ironed out, but it's not a great implementation IMO
    2. in some ways we are defining a new editing mode, but in other important ways, it's still "visual" editing mode in terms of how we interact with the VisualEditor API through our plugin. Based on what I see in this task, we will now likely need to provide a way to modify VisualEditor to allow for more editing modes that extension can define, and we'll also have to deal with extension/skin code that expects the hard-coded values of "source"/"visual". We can implement (another) hack to work around this, but to do it the non-hack way would probably be a pretty big effort.
    3. debatable, but IMHO by hiding all of the UX elements of the VisualEditor from the user, we're not introducing them to "normal" editing workflows, although again, I recognize that this is what the current task is about
    4. currently we just have one type of structured task, but how would the user switch between different types of structured tasks available for an article in this paradigm?

Anyway, given the above, plus the fact that image suggestions and other types of structured tasks are coming up, I wanted to suggest an alternative.

The idea is that instead of hiding all the VisualEditor plugins, we allow all of them to be shown. Alongside those plugins, we show an icon for our link suggestion plugin (the robot icon + a link, for example), and highlight it in the toolbar row:

image.png (924×1 px, 752 KB)

When the user clicks outside the inspector, they get the warnings shown in this task, and we would minimize the link inspector back into the link suggestions toolbar icon. Similarly, when the user wants to move the inspector to be able to read the text, we could minimize the inspector into the icon, and the user can click the icon again to bring up the link suggestion inspector.

When image suggestion or other structured tasks are added, those would also have their own icons and toolbar items. That would allow users to switch between different types of structured tasks available for the same article.

If we go this route, we could remove various hacks:

  • pretending that we have a new editing mode when it's really the visual editing mode that's under the hood
  • suppressing other plugins
  • removing the Edit source link

Hi @kostajh - it sounds like you are suggesting that we would make the structured task suggestions a part of the VE mode, is that right? We did in fact have this as the alternative direction (basically "Concept A" tested in T260534), but over the course of usability testing and discussions about wanting to ensure newcomers could focus on the specific task initially it was decided to go with this separate structured task mode initially.

image.png (1×2 px, 1 MB)

How much effort would there by create this alternative design (integrating within VE) for the Add links task now? @MMiller_WMF - I wonder if this would be worthwhile A/B testing to see if the within-VE version is better at encouraging retention and productivity (the hypothesis being this version better exposes the newcomer to other editing opportunities)?

Change 700719 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Add a link: Prototype edit mode toggle on desktop

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

Hi @MMiller_WMF @RHo — I was prototyping a fairly simple implementation of the edit mode dropdown and have a question about the confirmation dialog.

Should the custom "Leave suggestions?" dialog only be shown when the user has interacted with the link inspector (that is, when there is something to save)?

If that's the case, would it be ok if we stick with the existing warnings and not show our custom dialog? The issue I ran into is that when the user has already made changes, the browser would show an unsaved changes warning when leaving the page. As fas as I know, there's no way to suppress or customize this dialog consistently across different browsers, so we could end up with two dialogs being shown back to back like this:

addlink_editModeToggle_doubleDialogs.gif (1×1 px, 2 MB)

Another question: since the pencil icon is part of VisualEditor, do we need to add anything to allow users w/single edit tab go back to Machine Suggestions mode once they have switched to source editor (I guess there's no way to go back to regular VE mode either)?

addlink_editModeToggle_source.gif (1×2 px, 3 MB)

tl;ldr rather than suppress everything in VisualEditor and attempt to define an entirely new editing mode, maybe we should just have link suggestion exist as a regular plugin alongside all the other ones – the only difference would be that we warn users (this task's scope) about exiting the plugin's user interface

Would that mean all the editing functions are available and the article can be changed, or would we keep readonly mode?

Keeping readonly mode seems confusing - there would be no way to switch to "real", editable VE mode as we would have discarded the notion of a third mode, and and the user would be presented with a suite of tools that don't actually work.

Going all the way and integrating the Add Link tool into normal editing is a direction that's very much worth exploring IMO (the concept of "edit suggestions" can be extended to many things that are not specific to inexperienced users and combine well with normal editing, such as spelling/grammar fix suggestions, something that other document authoring environments tend to support as part of the editing workflow), but it has its own significant challanges:

  • We'd have to keep track of the suggested link anchors while the user makes unrelated edits to the page. Would we have to do something expensive, such as AddLinkArticleTarget.findRecommendationFragments(), after every document change? I think VE keeps sufficiently track of annotations and we wouldn't have to do anything, but I'm not sure.
  • Business rules are built into mwaddlink and as such applied to the initial state of the article. If that can be different from what actually gets saved, those rules might get violated. Most prominently: most wikis prefer linking a word at its first occurrence.
  • There would be more chance for the user to accidentally break things, at the point in their trajectory when they are most vulnerable to negative feedback.
  • We'd have to figure out what to do about the save dialog, which currently assumes only the links get changed.

(Worth noting though that much of these problems result from recommendations being relatively slow. If we could just recalculate them on the fly for the current document draft when the user clicks the relevant tool, we would not have to keep track of them, or worry about business rules. For link recommendations that's probably not currently feasible, but for other kinds of recommendations it might be.)

Hi @MMiller_WMF @RHo — I was prototyping a fairly simple implementation of the edit mode dropdown and have a question about the confirmation dialog.

Should the custom "Leave suggestions?" dialog only be shown when the user has interacted with the link inspector (that is, when there is something to save)?

If that's the case, would it be ok if we stick with the existing warnings and not show our custom dialog? The issue I ran into is that when the user has already made changes, the browser would show an unsaved changes warning when leaving the page. As fas as I know, there's no way to suppress or customize this dialog consistently across different browsers, so we could end up with two dialogs being shown back to back like this:

addlink_editModeToggle_doubleDialogs.gif (1×1 px, 2 MB)

hi @mewoph - do you mean we would use the standard browser warning dialog only and never use the custom dialog? Given the alternative of showing the double confirmation dialog, I would prefer this option (showing just the one browser warning dialog) - especially if the user is able to switch back to suggestions mode again in the same session.

image.png (474×614 px, 451 KB)

Another question: since the pencil icon is part of VisualEditor, do we need to add anything to allow users w/single edit tab go back to Machine Suggestions mode once they have switched to source editor (I guess there's no way to go back to regular VE mode either)?

addlink_editModeToggle_source.gif (1×2 px, 3 MB)

The expectation is that they should be able to switch back to Suggestions and VE mode from Source. It's just that in the source editor, the toggle button is located within the wikitext toolbar. I think it's an error that your screencadt doesn't show this editing toolbar (it should appear sticky at the top of the text area:

image.png (660×2 px, 178 KB)

tl;ldr rather than suppress everything in VisualEditor and attempt to define an entirely new editing mode, maybe we should just have link suggestion exist as a regular plugin alongside all the other ones – the only difference would be that we warn users (this task's scope) about exiting the plugin's user interface

Would that mean all the editing functions are available and the article can be changed, or would we keep readonly mode?

Keeping readonly mode seems confusing - there would be no way to switch to "real", editable VE mode as we would have discarded the notion of a third mode, and and the user would be presented with a suite of tools that don't actually work.

I think the idea is that if the user decides to interact with other tools with VE, we'd show them the warnings that they are exiting suggestions mode. But yeah, it would then be confusing to, say, fix a typo, and not be able to re-enter suggestions mode, unless we do what you propose below:

Going all the way and integrating the Add Link tool into normal editing is a direction that's very much worth exploring IMO (the concept of "edit suggestions" can be extended to many things that are not specific to inexperienced users and combine well with normal editing, such as spelling/grammar fix suggestions, something that other document authoring environments tend to support as part of the editing workflow), but it has its own significant challanges:

  • We'd have to keep track of the suggested link anchors while the user makes unrelated edits to the page. Would we have to do something expensive, such as AddLinkArticleTarget.findRecommendationFragments(), after every document change? I think VE keeps sufficiently track of annotations and we wouldn't have to do anything, but I'm not sure.
  • Business rules are built into mwaddlink and as such applied to the initial state of the article. If that can be different from what actually gets saved, those rules might get violated. Most prominently: most wikis prefer linking a word at its first occurrence.
  • There would be more chance for the user to accidentally break things, at the point in their trajectory when they are most vulnerable to negative feedback.
  • We'd have to figure out what to do about the save dialog, which currently assumes only the links get changed.

The toolbar in the source editor is from WikiEditor and is set up differently from the VE toolbar. It looks like VisualEditor and MobileFrontEnd are customizing the edit mode dropdown in ve.init.mw.DesktopArticleTarget.init.js and SourceEditorOverlay.js respectively.

@mewoph -- based on today's discussion, it seems like this should be assigned to you and In Progress. Is that correct? If so, please make those changes to the task. Thank you!

Hi @MMiller_WMF @RHo@Tgr @kostajh and I discussed the changes and we think that it would make sense to exclude source editor from the dropdown for the first pass (so the user can switch between regular VE and machine suggestions VE) since switching from source editor would require more effort. Would that be acceptable?

Hi @MMiller_WMF @RHo@Tgr @kostajh and I discussed the changes and we think that it would make sense to exclude source editor from the dropdown for the first pass (so the user can switch between regular VE and machine suggestions VE) since switching from source editor would require more effort. Would that be acceptable?

Given the audience for our features, I agree that makes sense. Do you want to separate the source editor toggle into a different task for later then?

mewoph renamed this task from Add a link: edit mode toggle to Add a link: edit mode toggle (machine suggestions & visual).Jun 29 2021, 5:48 PM
mewoph updated the task description. (Show Details)

@RHo & @MMiller_WMF — I wanted to confirm the copy for the edit mode dropdown's invisible label. Currently the existing copy for the dropdown w/visual and source modes is "Switch editor". Should we have a different copy in this case (along the lines of "Switch editing mode") since the user is choosing a different mode and not editor per se?

Screen Shot 2021-06-29 at 3.11.16 PM.png (290×478 px, 29 KB)

@mewoph -- thank you for this attention to detail. Are you saying that "Switch editor" is the copy that comes with VE and was already there before we started this work? If so, I think we should leave it the way it is now and not make an exception for our workflow. I'm imagining that a user who might have encountered that invisible label in the conventional editing experience might be looking for that same label in this one as they search for the same control.

Hi @MMiller_WMF, yes that's right. I'll leave it as is then.

Hi @MMiller_WMF @RHo — I wanted to update you on the dialog for this change. I previously thought it was not possible to bypass the default browser dialog in all cases but I was mistaken, so we should be able to show the custom dialog instead only when switching from edit mode toggle ( & the user has already reviewed suggestions). When the user reloads or navigates away existing dialogs will be used. That being said, I've only verified that my implementation works on desktop and mobile sites on desktop Chrome, Safari and Firefox, and on iOS. It would be good to test on some real Android devices (I don't have one currently). Another thing to note is that we would be showing the editing warning regardless of whether the user has this preference set — if that's not desirable, let me know and I'll look into not showing the dialog if the user opts out of this warning.

Screen Shot 2021-07-12 at 3.12.06 PM.png (82×842 px, 17 KB)

Desktop:

editModeToggle_desktop.gif (532×640 px, 2 MB)

Mobile:

editModeToggle_mobile.gif (640×296 px, 1 MB)

Hi @MMiller_WMF @RHo — I wanted to update you on the dialog for this change. I previously thought it was not possible to bypass the default browser dialog in all cases but I was mistaken, so we should be able to show the custom dialog instead only when switching from edit mode toggle ( & the user has already reviewed suggestions). When the user reloads or navigates away existing dialogs will be used. That being said, I've only verified that my implementation works on desktop and mobile sites on desktop Chrome, Safari and Firefox, and on iOS. It would be good to test on some real Android devices (I don't have one currently). Another thing to note is that we would be showing the editing warning regardless of whether the user has this preference set — if that's not desirable, let me know and I'll look into not showing the dialog if the user opts out of this warning.

Screen Shot 2021-07-12 at 3.12.06 PM.png (82×842 px, 17 KB)

Desktop:

editModeToggle_desktop.gif (532×640 px, 2 MB)

Mobile:

editModeToggle_mobile.gif (640×296 px, 1 MB)

That's good news @mewoph, thanks for the update. It looks like the user preference for warning on unsaved changes is checked in user preferences by default. Since the main audience we are targeting with this feature will be newcomers who won't have changed their user preferences, I tend to think this is OK to start with, though we should still file another task for later to not show the dialog if someone opts out.
And I'd be happy to test on my Android device once it's available for testing.

@mewoph @RHo -- I also think there's an argument for showing this dialog even when the user has that preference off: we're discarding changes in a situation where the editor would reasonably expect them not to be discarded. Since changes are usually preserved when the user toggles between VE and source editing, they would probably expect them to be preserved between suggestions and VE. But we don't do that, and I think therefore it is good to give them a warning.

@MMiller_WMF — that makes sense. I'll update the task description and remove the check.

Change 700719 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: Edit mode toggle (w/machine suggestions & regular VE modes)

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

(1)

  • Header: "Leave AI suggestions?"

Of course, all references to "AI" have been removed. It says "Leave suggestions?".

(2)

  • If the user selects "x" on the toolbar, they will see the standard dialog shown when a change is made in editor mode on VE and source.

Just to clarify this point: it refers to mobile only - VE tool bar on desktop doesn't have "x" button.

(3)

For wikis that have multiple edit tabs, yes, the "Edit source" tab should do the same thing as the edit mode toggle (show the special dialog, etc.)

  • Suggestions mode option will be always present with VE even if a user has one of the following Editing options enabled: "Remember my last editor" or "Always give me the source editor".
  • the shortcut - ctrl-option-e for the source editor - won't work from VE (after switching there from Suggestions mode) if a user has "Remember my last editor" option enabled. For normal editing there was no change in behavior of editing options.
  • the shortcut - ctrl-option-e for the source editor - will work from VE (after switching there from Suggestions mode) if a user has "Always give me the source editor". However, a user can reach Suggestion edit mode by switching back to VE and then to Suggestions.

I filed one issue for an edge case T288916: Add a link: saving an edit in Source edit mode brings post-edit dialog (similar to T288379).

MMiller_WMF moved this task from QA to Design Review on the Growth-Team (Current Sprint) board.

I think this task should get design review from @RHo, so I'm reopening and putting in that column. Thank you!

Hi @mewoph and @Etonkovidova - this LGTM but I did noticed that the mobile dialog is not fading in and out as expected from the centre, but 'dropping down' and flying out instead. This is also happening on the rejection dialogs now and is possibly a regression? Do you have a preference to keep on this task or filing a separate task?

Desktop:
image.png (398×602 px, 22 KB)
image.png (924×1 px, 124 KB)
Expected fade-in and out appearance of dialog
Mobile:
image.png (346×666 px, 69 KB)
image.png (862×756 px, 101 KB)
Unexpected dialog animation (drops down and flies up) vs expected fade-in & out

Hi @RHo — the dialog animation is unrelated to this change. Here's a video from a while ago before edit mode toggle was added. The animation from the top is consistent with VE's dialogs (we are using VE's dialogs for the rejection & the edit mode toggle dialogs). If you'd like the animation to deviate from VE's default, please file a new task.

addlink_reject.gif (1×622 px, 919 KB)

Hi @RHo — the dialog animation is unrelated to this change. Here's a video from a while ago before edit mode toggle was added. The animation from the top is consistent with VE's dialogs (we are using VE's dialogs for the rejection & the edit mode toggle dialogs). If you'd like the animation to deviate from VE's default, please file a new task.

addlink_reject.gif (1×622 px, 919 KB)

OK sounds like this was missed in the initial version, I filed this low prio task T288978