Update: 13 January
Today, @nayoub and I met to talk through the storyboard/experience diagram Nico put together for the initial mobile edit reference check experience. [i]

This conversation surfaced the following next steps and open questions.

Next Steps (now)

• 1. Sketch a workflow that prompts people to review/act on the feedback edit check is presenting them after they tap the toolbar's existing ▶️ button. This workflow would materialize as a new, distinct step within the publishing flow.
  • Note: as part of this exploration, it would be helpful to see how this flow would look/work if there were multiple reference checks for people to review.
• 2. Iterate on the edit summary / Save your changes view/moment so that it feels more like a part of the publishing flow and less like a speedbump within it

• 3. Sketch out one, or multiple, approaches for how we might cause people to feel a greater sense of accomplishment/satisfaction/gratification for reviewing the edit checks the interface is presenting them with
• 4. Iterate on the Citation recommended edit card so that there are clear options for people to take the following actions: i) dismiss the edit check, ii) act on the edit check, or iii) learn more about the edit check they are being presented with
• 5. Sketch out the learn more view that we're thinking people will be able to access via the Citation recommended edit card
• 6. Sketch out the flow for how someone might ask for help from within the learn more view "5." describes.
  • In this flow, we're thinking the "help" people would be asking for would be published to the article's talk page if/when the person follows through and publishes an edit to the article. This topic would also include a link to the diff they would have just published.
• 7. Sketch out a flow for how someone might offer context about the edit they're making from within the learn more view "5." describes.
  • In this flow, we're thinking the "context" people might offer will be added to the edit summary that gets published if/when the person decides to publish an edit. Note: this flow would be an alternative to the flow "6." describes.
• 8. Iterate on the "Citoid" edit card to include some kind of guidance that prompts people to reflect on whether the source they're considering adding is likely to be one other volunteers deem acceptable

Open Questions

• How might the interface make people aware of issues when those issues relate to content that is not currently visible to them because they've scrolled that part of the "document" out of view? E.g. might we introduce some kind of omnipresent indicator that shows the total number of checks that are available for people to review?

i. We will make the decision about the order in which we'll design and develop this initial edit check for desktop and mobile in T325787

Update: 25 January

Today, the Editing Team met to talk through the revised mockups @nayoub created for the initial mobile edit reference check experience. [i]

Nico and I then met to discuss what changes/directions we would explore in response to the questions/ideas that surfaced during the team-wide conversation.

Below is a list of said "changes/directions" we will be exploring next as well as the questions these explorations are intended to help us answer.

Next steps (prioritized)

• 1. Explore how the current design would accommodate the following additional edit checks and edit types:
  • Multiple checks, of the same type (references), at different locations within the article the person is editing
  • Multiple checks, of different types (references, copyright violation, and NPOV), at the same location within the article the person is editing
  • Multiple checks, of different types (references, copyright violation, and NPOV), at different locations within the article the person is editing
• 2. Fill in/sketch out the following aspects of the workflow which currently exist as placeholders:
  • The learn more view that we're thinking people will be able to access via the Citation recommended edit card
  • The flow for how someone might ask for help from within the learn more view described above
    • Note: In this flow, we're thinking the "help" people would be asking for would be published to the article's talk page if/when the person follows through and publishes an edit to the article. This topic would also include a link to the diff they would have just published.
  • A flow for how someone might offer context about the edit they're making from within the learn more view .
    • Note: In this flow, we're thinking the "context" people might offer will be added to the edit summary that gets published if/when the person decides to publish an edit.
• 3. Explore how the current the current design could be extended to accommodate proactive suggestions.
  • Note: this work will happen in T325011.

Open questions

• Do we think the current design is flexible enough to accommodate a range of edit types and edit checks?
• Is the proposed design technically feasible?

i. Figma: Editing/Edit Check/Mobile Flow, Team Feedback – Jan 23, 2023

NPOV is not a tractable problem for an automated check, especially if you are looking only at new additions and not at the overall effect. If you are looking for other ideas, consider these:

• flagging links that are on the spam list
• unwanted/excessive formatting (e.g., '''', which produces a pointless <i></i>).
• insufficient number of links to other pages (the ideal/practical number will vary by size of the wiki)
• warning abut URLs that may be particularly inappropriate, especially if we could copy XLinkBot's list
• longer pages with no ==Sections==
• individual sections that are too long
• empty sections
• accessibility problems, like using a ===Level 3=== section heading with no ==Level 2== section above it
• external links (e.g., [https://www.example.com Example, Inc.]) in the middle of a sentence or as a bare URL (so it displays as [1]).

In T325711#8566092, @Whatamidoing-WMF wrote:

NPOV is not a tractable problem for an automated check, especially if you are looking only at new additions and not at the overall effect. If you are looking for other ideas, consider these:

Update: 1 February

Today, the team met to discuss the latest round of mockups and the Open questions we named in T325711#8559347. The outcomes from today's discussion are documented in-line below

In T325711#8559347, @ppelberg wrote:

Update: 25 January

Open questions

• Do we think the current design is flexible enough to accommodate a range of edit types and edit checks?

Yes. During today's team-wide conversation we came to agree that the current approach is sufficiently flexible to accommodate a range of checks.[i] As such, we will be moving forward with building an initial version technical prototype. This work will happen in T328598.

i. Note: we'll be using T327330 to learn from Senior Contributors what additional checks they envision being useful/valuable. Thank you to @Sdkb who has already starting doing this on mediawiki.org.

• Is the proposed design technically feasible?

Yes, per the outcomes documented/soon-to-be documented in T325700's subt-tasks.