[go: up one dir, main page]

Page MenuHomePhabricator

[SPIKE] What determines whether auto-save can return people to the middle of the edit check workflow?
Closed, ResolvedPublic

Description

In its current form, T325711 proposes a user experience for the initial reference Edit Check user experience that will would require people who are attempting to add a reference after being prompted to do so to [most likely] [i] navigate away from the mobile visual editor to retrieve said reference.

This task involves the work of identifying and documenting what – if any – technical constraints bind the software's ability to return people to the middle of the edit check workflow after having navigated away to fetch a reference from another browser tab/app.

Open question(s)

  • 1. What – if any – technical constraints bind the software's ability to return people to the middle of the edit check workflow after having navigated away to fetch a reference from another browser tab/app? We are interested in how the answer to this question could vary across devices with varying performance capabilities.

Done

  • Answers to all Open question(s) are documented

i. It's possible, although we assume unlikely, for someone who was needing to be prompted by edit check to accompany the new content they're attempting to add to already have said reference "copied" to their device's clipboard.

Event Timeline

ppelberg moved this task from Backlog to Triaged on the EditCheck board.
ppelberg moved this task from To Triage to Triaged on the VisualEditor board.
ppelberg added a project: Editing-team.
ppelberg moved this task from Untriaged to Needs Discussion / Investigation on the Editing-team board.
ppelberg added a subscriber: DLynch.

Meeting notes from today:

  • Straightforward, no big investigation needed. Just need to store “dialog”/whatever state somehow
  • Could get complex with big nested dialogs, depending on how they’re storing their data
ppelberg claimed this task.

Meeting notes from today:

  • Straightforward, no big investigation needed. Just need to store “dialog”/whatever state somehow
  • Could get complex with big nested dialogs, depending on how they’re storing their data

Sounds good; I've added a note about the above to T328944 so that we hold ourselves accountable to implementing this.