Page MenuHomePhabricator

Add event for logging when people are prevented from switching from source to visual
Closed, ResolvedPublic

Description

This task is about implementing an event that should log instances when people are prevented from switching from the Reply tool's source mode to the visual mode.

Background

T256150 implements a new dialog that will prevent people from switching from the Reply tool's source mode to its visual mode if the comment they've drafted contains a template or a table.

This task will help us understand how often people are encountering this dialog/interrupt and subsequently inform how we prioritize implementing the new multi-line comment syntax that will be decided up on in T246960.

Timing

We would like for this event to be named, implemented and tested by 4-August-2020.

Requirements

  • An event is fired and logged that will enable to us to know:
    • A) When people encounter the dialog T256150 implements
    • B) What content – a template or a table – causes people to encounter the dialog T256150 implements

Open questions

  • 1. What should this event be called?
  • 2. What schema should this event be stored in?
EventEvent nameSchema
Person tries to switch to the Reply Tool's visual mode after writing a template in its source modedialog-prevent-template-showVisualEditorFeatureUse
Person tries to switch to the Reply Tool's visual mode after writing a table in its source modedialog-prevent-table-showVisualEditorFeatureUse

Done

  • "Open questions" are answered
  • Pre-deployment QA is completed

This is now done per T257501#6361341

  • "Requirements" are implemented

This is now done per T257501#6350423

  • New events are added to the VisualEditor/Feature use data dictionary

This will instead happen in T252930 per T252930#6347000

Event Timeline

ppelberg created this task.Jul 8 2020, 6:48 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 8 2020, 6:48 PM
Tacsipacsi renamed this task from Add event for logging when people are preventing from switching from source to visual to Add event for logging when people are prevented from switching from source to visual.Jul 8 2020, 9:46 PM
JTannerWMF added a subscriber: JTannerWMF.

Hey @Mayakp.wiki sometime next week, we need you to drive getting the answers to these questions in collaboration with @DLynch

LGoto reassigned this task from Mayakp.wiki to MNeisler.Jul 14 2020, 5:12 PM
LGoto triaged this task as Medium priority.
LGoto moved this task from Triage to Needs Investigation on the Product-Analytics board.

Hey @Mayakp.wiki sometime next week, we need you to drive getting the answers to these questions in collaboration with @DLynch

Next steps

  • Moving this to Blocked/Needs more work as @MNeisler and @DLynch need to come to a decision about what the event should be called

Timing
Ideally, we can decide on the event name, implement the event and test the event within the next 2-3 weeks.

The above is now reflected in the task description.

ppelberg updated the task description. (Show Details)Jul 15 2020, 7:19 PM

1. What should this event be called?
I'm currently thinking the following might work based on the event naming conventions in the VEFU schema. See the VEFU data dictionary.
Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Follow-up Question:
Do we want separate events to track if the dialog was caused by a table or a template in the source comment? (cc @ppelberg)

2. What schema should this event be stored in?

This event should be stored in the VisualEditorFeatureUse schema.

@DLynch - Any thoughts on the above? Happy to discuss other recommendations.

Follow-up Question:
Do we want separate events to track if the dialog was caused by a table or a template in the source comment? (cc @ppelberg)

Good call, @MNeisler; I'm glad you thought of this.

Yes, we would like to instrument separate events to know what content (table or template) caused the dialog to be shown (read: the person to be prevented from switching between source and visual).

Two notes:

  1. During today's standup, @DLynch and @Esanders confirmed the above should be possible considering code paths exist for the explicit scenarios we would like to instrument/detect.
  2. I've updated the task description's "Requirements" section to reflect the need to instrument what caused the dialog to be presented
ppelberg updated the task description. (Show Details)Jul 21 2020, 6:55 PM

Now T256150 has the relevant patch merged, we can do whatever logging we'd like.

Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Presumably we'd want variants on the action based on the type, so we'd wind up with dialog-prevent-{type}-show or similar.

Now T256150 has the relevant patch merged, we can do whatever logging we'd like.

Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Presumably we'd want variants on the action based on the type, so we'd wind up with dialog-prevent-{type}-show or similar.

Yes, agreed. dialog-prevent-template-show and dialog-prevent-table-show would work for me.

Now T256150 has the relevant patch merged, we can do whatever logging we'd like.

Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Presumably we'd want variants on the action based on the type, so we'd wind up with dialog-prevent-{type}-show or similar.

Yes, agreed. dialog-prevent-template-show and dialog-prevent-table-show would work for me.

Next steps
@MNeisler + @DLynch, based on the above, I am assuming y'all have agreed on answers to the task description's "Open questions." [i] As such, I am moving this to "Ready for development" so the events below [i] can be implemented by Editing Engineering.

⚠️If y'all have NOT agreed on answers to the "Open questions" in the task description, please comment as much.


Open questions

  • 1. What should this event be called?
  • 2. What schema should this event be stored in?
EventEvent nameSchema
Person tries to switch to the Reply Tool's visual mode after writing a template in its source modedialog-prevent-template-showVisualEditorFeatureUse
Person tries to switch to the Reply Tool's visual mode after writing a table in its source modedialog-prevent-table-showVisualEditorFeatureUse
ppelberg updated the task description. (Show Details)Jul 27 2020, 11:24 PM

Change 616874 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/DiscussionTools@master] Log when editor switching is prevented

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

ppelberg updated the task description. (Show Details)Jul 29 2020, 10:20 PM

Task description update

  • ADDED pre-deployment QA to "Done"

Note to Editing Engineering: please move this task to the Editing QA "High Priority" column once code review is complete.

Change 616874 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Log when editor switching is prevented

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

matmarex edited projects, added Editing QA; removed Patch-For-Review.
matmarex moved this task from Inbox to High Priority on the Editing QA board.
Ryasmeen added a subscriber: Ryasmeen.

Checked the two events on Beta. They seem to be firing as expected.

Screenshots for the dialog and the event for scenario 1, where a person tries to switch to the Reply Tool's visual mode after writing a template in its source mode:

Screenshots for the dialog and the event for scenario 2, where a person tries to switch to the Reply Tool's visual mode after writing a table in its source mode:

@DLynch/@ppelberg: I have a question though about a scenario which I tried :

When I write both a template and a table in Reply Tool's source mode and then switch to visual mode. I only get the event and dialog for one event, the one for the table, shouldn't I get these for both?

ppelberg added a comment.EditedAug 4 2020, 11:53 PM

Checked the two events on Beta. They seem to be firing as expected.

Thank you for the update, Rummana.

When I write both a template and a table in Reply Tool's source mode and then switch to visual mode. I only get the event and dialog for one event, the one for the table, shouldn't I get these for both?

Good spot which I think has two consequences:

  • 1. We need to add a third dialog for the case in which people write table and template syntax in the Reply Tool's source mode and attempt to switch to its visual mode
  • 2. We need to add a third event that fires in cases where people write table and template syntax in the Reply Tool's source mode and attempt to switch to its visual mode

Considering the new case you identified was NOT scoped as part of this task and the cases that were scoped as part of this task have been verified, I've created a task for "1." and "2." above: T259673.

Resulting actions
As for the remaining items in the task's description's "Done" section:

  • "Open questions" are answered
  • Pre-deployment QA is completed

This is now done per T257501#6361341

  • "Requirements" are implemented

This is now done per T257501#6350423

  • New events are added to the VisualEditor/Feature use data dictionary

This will instead happen in T252930 per T252930#6347000

I am resolving this task; the task description's "Done" section has been updated to reflect the above.

ppelberg closed this task as Resolved.Aug 4 2020, 11:59 PM
ppelberg updated the task description. (Show Details)
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptAug 4 2020, 11:59 PM