Page MenuHomePhabricator

Design user experience for presenting people with multiple checks
Open, Needs TriagePublic

Description

T341308, T345472, and more immediately, T347531 will make it feasible for showing people multiple Edit Checks within a single edit.

This task represents the work of arriving at a user experience, and the corresponding design pattern(s)/paradigm(s), capable of scaling to accommodate Edit Check presenting people with multiple checks within a single editing session.

Where "multiple" in the scope of this ticket could mean:

  1. A single Edit Check type (e.g. editcheck-reference-activated) that is relevant to >1 places within the article someone is editing.
  2. ≥2 Edit Check types relevant to a single place within the article someone is editing.
  3. Multiple Edit Check types relevant to multipole places within the article someone is editing.

Story

As someone who is unaware of Wikipedia's content policies to the extent that the software can assume I'm likely to publish an edit that will "defy" them, I'd value being made aware of this information in an actionable way within a moment that I'm likely to be motivated/open to considering it so that I can publish change(s) A) I stand by and that B) are likely to remain on the wiki.

Requirements

Note: the user experience this ticket produces ought to be capable of scaling to a variety of Edit Checks and edit suggestions.

Learning objectives

This ticket is scoped with the goal of helping us to arrive at initial answers to the following questions:

  • 1. When and how is the feedback stored if/when people dismiss it?
  • 2. When and how are multiple peoples of feedback stored?

Open questions

  • 1. How might the eventual multi-check user experience need to be adapted to accommodate people who edit using narrow screen widths?
  • 2. Were we to move forward with a desktop approach that introduces a new "right rail," how might it be adapted so as not to conflict with other preexisting parts of the interface that live in that space? [i][ii]
  • 3. Were we to move forward with an approach that presents Edit Checks in a card-like format:
    • A. How might the design scale to accommodate a scenario where a large number (e.g. 10) of checks are activated?
    • B. How might the cards be related to one another within the right rail? E.g. Might the cards be displayed in a way that corresponds to where within the article the content they are meant to draw peoples' attention to appears? Might the cards be displayed in a way that clusters cards of similar types together? Something else?
  • 4. What – if any – logic will determine what checks are shown, and in what sequence, when multiple are activated within a single edit?
    • Note: this question will be address in T329596.
  • 5. What could be done to reduce the amount of space individual "cards" require? This question was spoken in response to the amount of space currently being afforded to the machine-looking icon. [iii]
  • 6. What – if any – affordance(s) will be included that enables people to quickly "jump" from check-to-check? Think about how navigation is handled by find and replace and analogous experiences. [iv]

i. Help Panel
ii. Page tools
iii.

Screenshot 2023-10-13 at 4.12.35 PM.png (1×1 px, 227 KB)

iv. Structured tasks: Add a link

Related Objects

Event Timeline

ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)

On Wednesday (11 October), the Editing Team met to discuss the initial multi-check user experience explorations (Figma). Below are the new questions these explorations brought to mind.

These open questions are also documented in the task description's newly-created ===Open questions section.

Open questions

  • 1. How might the eventual multi-check user experience need to be adapted to accommodate people who edit using narrow screen widths?
  • 2. Were we to move forward with a desktop approach that introduces a new "right rail," how might it be adapted so as not to conflict with other preexisting parts of the interface that live in that space? [i][ii]
  • 3. Were we to move forward with an approach that presents Edit Checks in a card-like format:
    • A. How might the design scale to accommodate a scenario where a large number (e.g. 10) of checks are activated?
    • B. How might the cards be related to one another within the right rail? E.g. Might the cards be displayed in a way that corresponds to where within the article the content they are meant to draw peoples' attention to appears? Might the cards be displayed in a way that clusters cards of similar types together? Something else?
  • 4. What – if any – logic will determine what checks are shown, and in what sequence, when multiple are activated within a single edit?
    • Note: this question will be address in T329596.
  • 5. What could be done to reduce the amount of space individual "cards" require? This question was spoken in response to the amount of space currently being afforded to the machine-looking icon. [iii]
  • 6. What – if any – affordance(s) will be included that enables people to quickly "jump" from check-to-check? Think about how navigation is handled by find and replace and analogous experiences. [iv]

cc @nayoub


i. Help Panel
ii. Page tools
iii.

Screenshot 2023-10-13 at 4.12.35 PM.png (1×1 px, 227 KB)

iv. Structured tasks: Add a link

I just happened upon a "muli-check-like" experience in Google Sheets (desktop web) that utilizes space adjacent to the editing/creative surface:

Screenshot 2023-11-05 at 9.21.08 AM.png (1×2 px, 209 KB)

ppelberg renamed this task from Generate design concepts for presenting people with multiple checks to Design user experience for presenting people with multiple checks.Nov 22 2023, 6:13 PM

Documenting outcomes from Wednesday's Editing Team meeting and the 1:1 conversation @nayoub and I had earlier today...

Convergence

The Editing Team thinks it would be a false choice to consider us as needing to decide between presenting people with Edit Checks on mobile while they're editing ("Option #1") or once they tap to advance towards publishing (Option #2). [i]

Screenshot 2024-05-17 at 1.48.14 PM.png (428×766 px, 70 KB)

Rather, we are aligned in thinking we need to be able to present checks to people while they are editing and/or once they tap to advance towards publishing.

Thinking: we assume people will be motivated and equipped to address some checks in the moment (e.g. T359107) and have evidence that supports us thinking (T342930) there are some checks (e.g. T325711) people will better receive once they tap to advance towards publishing .

Next steps

In line with the "Convergence" above, @nayoub is now exploring how we might unite these two distinct Edit Check moments within the mobile visual editor.

And as part of the above, Nico is exploring how – if at all – people ought to be able to defer acting on an Edit Check that is presented mid-edit to the pre-publish moment.


i. The Reference Check is currently shown once people tap to advance towards publishing