Page MenuHomePhabricator

[L] Improve Edit Summary on iOS
Closed, ResolvedPublic

Assigned To
Authored By
Jan 2 2024, 8:25 PM
Referenced Files
F49864793: image.png
Thu, May 2, 9:07 PM
F49865367: image.png
Thu, May 2, 9:07 PM
F47261973: Group 30.png
Apr 18 2024, 1:54 AM
F47261958: Group 29.png
Apr 18 2024, 1:54 AM
F44174024: 3alert.png
Apr 2 2024, 2:28 PM
F44173862: 2separator.png
Apr 2 2024, 2:28 PM
F44173838: 1margin.png
Apr 2 2024, 2:28 PM
F42482505: Watchlist.png
Mar 9 2024, 1:01 AM



Through our user research we've learned how critical communication is with reverts. To improve communication when reverts to other people's edits are made, our team can improve the diff view. One way of making this improvement is encouraging users to leave a detailed, but respectful summary of the edit they've made (including reverts). This is aligned with Wiki policy.

User stories

Our current summary experience can be improved to achieve the following user stories:

  • When my edit has been reverted, I want a clear distinction between the edit summary and the diff itself, so that I can process information more efficiently.
  • When editing Wikipedia, I want the interface to give me clear direction for crafting helpful summaries in line with Wiki policies, so that patrollers and other users understand why I made the change that I did to an article.
  • When accessing the Watchlist, I want to review a diff and clearly understand why an edit was made, so that I have the proper context to agree or dispute the change.
The Task
  • If someone selects other, provide some guidance from the edit summary policy and the reverting guidance
  • Make it less likely that users publish without an edit summary
  • Create parity for watchlist view and revision history view, to clearly call out when the edit summary is blank

Figma link

1. Edit summary flow
1) Scrolls to section2) Taps edit3) Makes edit4) Previews edit5) Edit summary6) Type summary7) Finalize summary8) Success message
Scroll to section.png (667×375 px, 213 KB)
Tap to edit.png (667×375 px, 77 KB)
Makes edit.png (667×375 px, 64 KB)
Preview edit.png (667×375 px, 77 KB)
Edit summary.png (667×375 px, 36 KB)
Type summary.png (667×375 px, 38 KB)
Finalize summary.png (667×375 px, 35 KB)
Success message.png (667×375 px, 79 KB)

5) Edit summary

6) Suggestions:
 Will not be included at this time, explanation in comment below.
  • This feature exists already and might help users prepopulate the field if tasks are done repeatedly. We will keep it to respect existing user flows.
  • Suggestions should match the edit just completed (if they just added an image and caption, “Added Image and Caption” should appear, if they added Alt text, “Added Alt text” should appear, etc. (For T358923 and other future suggested edits)
  • After publishing a custom edit summary, the contents of it (e.g., “Formatting") are stored.
  • Once users start typing, the previously stored custom edit summary is presented as an autocomplete suggestion.
  • Tapping the suggestion fills the input field and takes users to 7)

7) Finalizes summary: PUBLISH button turns into blue600 once the input field is populated with text.

2. Optimize the Watchlist screen

Please add Empty edit summary copy/info from Revision history to the Watchlist for consistency:

Revision historyWatchlist
History.png (667×375 px, 39 KB)
Watchlist.png (667×375 px, 41 KB)

3) Requirement before release:

  • Signoff from Shay on what is recorded to properly instrument new additions


  1. Android Task
  2. Discussion with Isaac

Testing Notes

Please test in TestFlight Wikipedia app 7.5.0 (3509).

In addition to testing requirements in this task description, please also regression test captcha appearance on the edit summary view. There are some old testing steps for that here, but they didn't work for me. -TS

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
JTannerWMF raised the priority of this task from Low to Medium.Mar 5 2024, 8:48 PM

@JTannerWMF what is the "other" referring to here?

If someone selects other, provide some guidance from the edit summary policy and the reverting guidance

Couple of comments regarding the task. 


  1. Suggestions

This section that is described under ‘Annotations’ will not be included at this stage. 
Adding this component to the flow would be a fairly large engineering lift. To include this element more time would need to be dedicated to:

  •  Create a new solution to use for the pre-defined answers as we do not have a component that lets us do that in the app currently. 

  • Create a spike

  • Dedicated time would be needed to make this experience reusable and create a component out of it that could be reused in future designs (like in the @ mention in talk pages improvements).


  1. Optimize the Watchlist screen. Please add Empty edit summary copy/info from Revision history to the Watchlist for consistency

I wanted to note that iOS doesn’t have the ‘Empty edit summary’ copy in the ‘Revision History’ or in the ‘Watchlist’ cards currently. 
I have added designs for both in the section above. 

Hi @JTannerWMF

  1. Edit summary

Keyboard is active when users arrive on this screen to reduce steps.

On iOS the keyboard would cover the ‘Terms of Use’ text. I see that on Android the text is at the bottom of the ‘Preview’ page. Since the ‘Preview’ page is pretty busy I was curious if we could keep the text on the ‘Edit summary’ page (this would be consistent with mobile web) and not have the keyboard active right away?

Hey @OTichonova I can't see the mocks for Watchlist or Revision History, its restricted T354219#9616386. Sure lets make the keyboard inactive but if we still have an issue with folks clicking through we should revisit this.

@HNordeenWMF can you break off a task for the suggestions. Also, Other was intended for Watchlist for reason for reverting. This task has been generalized but at the least the learn more covers edit summary policy.

Hi @JTannerWMF, hopefully all mocks should be visible now.
Sounds good about the keyboard.

Subtask for suggested edit summaries started: T359854

Tsevener renamed this task from Improve Edit Summary on iOS to [L] Improve Edit Summary on iOS .Mar 25 2024, 6:50 PM
Tsevener claimed this task.

@OTichonova Experimental build #100 kicked off for design review.

A piece of additional work that may be useful: if the user decides to watch an article as they edit it, when they publish the change and return to the article view we should refresh the article view's overflow menu to reflect its watched status.

Hi @Tsevener, this is my first design review so let me know if things pointed here have been addressed previously and/or if I should tag someone else here.

I only see a few issues:

  1. Margin: I did notice that the margin on the experimental instance is considerably wider than the figma file. In the Figma design, margin is set to 16px but in the built it is set to 48px. I believe this should be fixed (unless it is a device size thing)
  2. Toggle separation: Another difference between the design and the test instance is the line dividing the toggles. The test instance adds a separation that is not on the Figma file. I believe this needs to be fixed by removing the line separator.
  3. Alert component: This one I am not so convinced it is an error. I noticed the test instance and the design file have different components to alert the edits have been published. The design file has a floating alert without a close icon while the experimental instance has a similar one, but it is "anchored at the bottom" with a close icon.

1margin.png (1×1 px, 322 KB)

2separator.png (1×1 px, 292 KB)

3alert.png (1×1 px, 292 KB)


Alert component: This one I am not so convinced it is an error. I noticed the test instance and the design file have different components to alert the edits have been published. The design file has a floating alert without a close icon while the experimental instance has a similar one, but it is "anchored at the bottom" with a close icon.

Yeah, that is a major difference for sure. Unfortunately the Figma uses a new design component that Engineering hasn't moved over to yet. The hope for us to one day build a new Toast component that matches this design (see T350398 for that work). Until then we're going to have that difference due to us using a legacy component.

Your other two items of feedback look doable - I'll update when it's ready for another look. Thanks!

Tsevener updated the task description. (Show Details)

@GLima-WMF New Experimental build #107 is available for design review. This contains margin and div fixes.

This comment was removed by OTichonova.

@OTichonova yeah, these should still be build #107. Sorry there was a bit of a mixup with these. The design review updates for this ticket are only accessible via the old editor flow in build #107 (i.e. not in image recs yet). Once these changes look good, they will be merged and will propagate into T358923. I can make another design review build for T358923 once this one is merged.

Ah okay sorry, I didn't read the ticket carefully. This looks good!
Couple things ->

  1. Could the color of the confirmation toast text be gray 700 in default rather than blue 600 so it doesn't look like a link?
  1. The cc text at the bottom of the page still has the old margin, could we update it to have the new margin?
Group 29.png (692×612 px, 19 KB)
Group 30.png (667×375 px, 46 KB)

Please test in TestFlight Wikipedia app 7.5.0 (3509).

@Tsevener the minor edit link is leading to :, which displays as a CTA to redirect
to this page:
Could we swap to the Mediawiki page?

@HNordeenWMF Will do - I'll leave this in QA since it's such a minor change. No use in holding up testing other parts of this ticket.

hi @SNowick_WMF. This requires your signoff before release to ensure the new additions are instrumented. Could you please take a look at these changes and let us know if any instrumentation changes are needed?


  • Change Publish button gray color if edit summary textfield is empty
  • Moves edit summary "Learn more" button down to match Figma
  • Shows watchlist toggle, turns ON if article is already on user's watchlist
  • Adjusts font sizes on edit summary view
  • Adds "Empty edit summary" copy to article history and watchlist cells if there is no edit summary
Old Screen:
image.png (2×1 px, 158 KB)
New screen
image.png (2×1 px, 174 KB)

@HNordeenWMF The only change that needs to be instrumented is the added Watchlist toggle, we can add a watchlist_added boolean to the action_data for the action = save_attempt where active_interface = article_edit_summary. I made a note in the Instrumentation Doc where this should be added. Not sure where this falls into priorities but would be a nice to have in place so we can get event counts.

thank you @SNowick_WMF !
@Tsevener would you be able to add these instrumentation changes tomorrow?

Validating we are seeing watchlist_added: values in action_data in ios_edit_interaction data.

HNordeenWMF claimed this task.
HNordeenWMF changed the task status from Unknown Status to Resolved.Tue, May 7, 10:20 PM