Change Details

During the beta feature phase, we have had almost exclusively highly-experienced editors using the new workflow. It's possible that we will run into new issues when we enter "small default" and less-experienced users see our interface. I would like to collect some additional data to understand whether we're allowing data loss. We're also going to grab a bit more information about high-priority usability questions. When first presenting a conflict, [] How many of the chunks could be automatically resolved, and how many are a legitimate conflict? After a successful merge, [] How many chunks were selected but not edited, for which the corresponding conflicting chunk included diffs? [] How many chunks were edited but not selected? In case we can intercept abandonment, [] Were any textboxes edited before abandonment? [] How did abandonment happen? Cancel button, back button, reload, tab closed... [x] Store the "your" text and other edit fields needed to reconstruct the edit (section title, oldid, base revision). I'm not sure which abandonment flows can be intercepted. Maybe we can tap into the "leave page?" popup. Our data should be sent using `sendBeacon` to avoid slowing down navigation. This is the default for MediaWiki event APIs, but we need to also prevent data collection when the sendBeacon API isn't available.

During the beta feature phase, we have had almost exclusively highly-experienced editors using the new workflow. It's possible that we will run into new issues when we enter "small default" and less-experienced users see our interface. I would like to collect some additional data to understand whether we're allowing data loss. We're also going to grab a bit more information about high-priority usability questions. When first presenting a conflict, [] How many of the chunks could be automatically resolved, and how many are a legitimate conflict? * [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TwoColConflict/+/576902/ | Log complexity metrics when entering a conflict workflow ]] #patch-for-review After a successful merge, [] How many chunks were edited but not selected? * WIP: [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TwoColConflict/+/576291/ | Track usage potentially leading to data loss ]] [] How many chunks were selected but not edited, for which the corresponding conflicting chunk included diffs? * Although this is possible to do by replaying conflicts through postprocessing, we also have the "sed" edit list available and can log that directly. I'll consider this a bonus metric to record. In case we can intercept abandonment, [] Were any textboxes edited before abandonment? * Same statistics as above will be logged at abort. * I'm not sure which abandonment flows can be intercepted. Maybe we can tap into the "leave page?" hook as well as page unload. [] How did abandonment happen? Cancel button, back button, reload, tab closed... * Our data should be sent using `sendBeacon` to avoid slowing down navigation. This is the default for MediaWiki event APIs, but we need to also prevent data collection when the sendBeacon API isn't available. When hooking into page unload to record abort conditions, guard with a test for the sendBeacon API. [x] Store the "your" text and other edit fields needed to reconstruct the edit (section title, oldid, base revision). * I was unable to access the section title. Maybe EditPage doesn't carry the value forward as a parameter to conflict resolution?

During the beta feature phase, we have had almost exclusively highly-experienced editors using the new workflow. It's possible that we will run into new issues when we enter "small default" and less-experienced users see our interface. I would like to collect some additional data to understand whether we're allowing data loss. We're also going to grab a bit more information about high-priority usability questions. When first presenting a conflict, [] How many of the chunks could be automatically resolved, and how many are a legitimate conflict? * [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TwoColConflict/+/576902/ | Log complexity metrics when entering a conflict workflow ]] #patch-for-review After a successful merge, [] How many chunks were edited but not selected? * WIP: [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TwoColConflict/+/576291/ | Track usage potentially leading to data loss ]] [] How many chunks were selected but not edited, for which the corresponding conflicting chunk included diffs? [] How many chunks were edited but not selected? * Although this is possible to do by replaying conflicts through postprocessing, we also have the "sed" edit list available and can log that directly. I'll consider this a bonus metric to record. In case we can intercept abandonment, [] Were any textboxes edited before abandonment? * Same statistics as above will be logged at abort. * I'm not sure which abandonment flows can be intercepted. Maybe we can tap into the "leave page?" hook as well as page unload. [] How did abandonment happen? Cancel button, back button, reload, tab closed... * Our data should be sent using `sendBeacon` to avoid slowing down navigation. This is the default for MediaWiki event APIs, but we need to also prevent data collection when the sendBeacon API isn't available. When hooking into page unload to record abort conditions, guard with a test for the sendBeacon API. [x] Store the "your" text and other edit fields needed to reconstruct the edit (section title, oldid, base revision). I'm not sure which abandonment flows can be intercepted. Maybe we can tap into the "leave page?" popup. Our data should be sent using `sendBeacon` to avoid slowing down navigation* I was unable to access the section title. This is the default for MediaWiki event APIs, but we need to also prevent data collection when the sendBeacon API isn't available.Maybe EditPage doesn't carry the value forward as a parameter to conflict resolution?