I know Robin already has some nice ways to trigger this feature.

The difficulty seems to come from the technical side. Options:

1. Get an API to remove a comment, just as we have one for posting. This is the most solid, and easily allows incorporation by iOS.
2. Allow a one button "delete", but behind the scenes do some local pattern matching on the wikitext and try to automatically remove it by submitting an edit to the talk page. This is brittle and prone to bugs. It also would be something iOS would have to do implement separately. Since an API was created for adding a comment, it also feels weird to use an API for adding, but then doing a really hacky thing for deleting.
3. Show the full wikitext, ask user to delete their comment. If user knows wikitext this is clean. But also could lead to users not familiar with wikitext deleting more or less than desired. However, if we need a way to delete comments now, this could be an interim solution until we can get API support.

Long press to delete

• Not a perfect way to do, since the text is selectable.

Add delete link to each comment

• Slightly messy (see screenshot below)
  

Swipe to delete

• A proper way to delete a single comment.

Undo API

• It can be used only if the comment does not have conflicting intermediate edits.

Replace the "to be deleted" comment with empty

• The possible way to do, but also comes with further questions:
  1. The https://en.wikipedia.org/api/rest_v1/page/talk/User_talk:Cooltey outputs the html format text.
  2. Need another API call of action=query to get the specific section of the comment, but the text format is wikitext.
  3. Because of 1. and 2., either the wikitext text or html text should be converted, which may require another API call to parse the text.

Thanks for laying out the interaction design options @cooltey — agree with this as it’s used in other places in the app 👇

Swipe to delete

• A proper way to delete a single comment.

In addition to the swipe, we could introduce a dialog, that educates users about the “destructive” nature of the action (edit/removal) and it’ll serve as a confirmational step.

Decision:

• Show a snackbar (5 seconds) for the user to delete the comment after submitting it.

Hey @schoenbaechler , in a future round of user testing we want to evaluate if 5 seconds is long enough for undo

Hi @JTannerWMF and @schoenbaechler

Here is the demo of showing a snackbar after submitting the response.
https://www.youtube.com/watch?v=hn1cNdb3wB0

Have two further questions:

1. Should we send a log to the eventlogging server when undoing it?
2. The current text on the snackbar is "Response submitted", any suggestion of a better wording?

Looks good so far @cooltey. Though the snackbar should be positioned above the floating action button, see Material guidelines:

Should we send a log to the eventlogging server when undoing it?

I guess this would make sense, what do you think @Dbrant @SNowick_WMF @JTannerWMF ?

The current text on the snackbar is "Response submitted", any suggestion of a better wording?

If we allow the undo action for replies only, this copy makes sense. But what if users submit a new topic on a talk page — will the undo action also be available? If yes, copy should say Topic submitted. I’m asking because from a UX perspective, it should be available, but I’m not sure if it’s technically feasible.

In T284532#7174425, @schoenbaechler wrote:

Looks good so far @cooltey. Though the snackbar should be positioned above the floating action button, see Material guidelines:

Got it, will update the layout.

The current text on the snackbar is "Response submitted", any suggestion of a better wording?

If we allow the undo action for replies only, this copy makes sense. But what if users submit a new topic on a talk page — will the undo action also be available? If yes, copy should say Topic submitted. I’m asking because from a UX perspective, it should be available, but I’m not sure if it’s technically feasible.

The current undo snackbar will be shown only on replies. It is feasible to show it when creating a new topic, will do. but I'll leave the decision to @JTannerWMF make.

thanks @cooltey — looks good to me — except for:

01) When “undoing” a talk page topic or reply, the floating action button disappears in the loading state. Is that intentional? It feels a bit odd, as it draws the user‘s attention to the thing that is disappearing. Check out the video experience it:

https://www.dropbox.com/s/4blm3gii3dmhfiz/20210713_101055.mp4?dl=0

I suggest to keep the FAB visible at all times (even if it’s not tappable in loading state) — maybe a slight overlay when loading could help?

In T284532#7207849, @schoenbaechler wrote:

thanks @cooltey — looks good to me — except for:

01) When “undoing” a talk page topic or reply, the floating action button disappears in the loading state. Is that intentional? It feels a bit odd, as it draws the user‘s attention to the thing that is disappearing. Check out the video experience it:

https://www.dropbox.com/s/4blm3gii3dmhfiz/20210713_101055.mp4?dl=0

I suggest to keep the FAB visible at all times (even if it’s not tappable in loading state) — maybe a slight overlay when loading could help?

Hi @schoenbaechler

Yes, it is intentional. The undo process is a POST action, and it will be interrupted if the user clicks the "new topic" or "reply" FAB while it is submitting.

In other words, the "loading state" is actually a "posting" state, and it is recommended to hide the FAB buttons during the state.

I suggest to keep the FAB visible at all times (even if it’s not tappable in loading state) — maybe a slight overlay when loading could help?

How about we make the FAB button disabled when it is in a loading state, and the color will be changed (in gray in general) as well.

How about we make the FAB button disabled when it is in a loading state, and the color will be changed (in gray in general) as well.

Disabled state sounds good, thanks Cooltey! I’d say let’s use the same “disabled” state design (50% opacity) as in places for other buttons, e.g. this one:

https://zpl.io/aX6RnrP

just tested, looks good now for both new topic & replies. thx @cooltey

Looks good on 2.7.50365-alpha-2021-07-21

This is great you all, wow what an improvement!

Just a few questions:

• If someone undo's, is it possible to take them back to the message they were crafting so what they wrote isn't lost?
• I see that we had a question about should people be able to undo new topics or just replies. It looks like the question was removed/struck out. If it is technically possible to undo a new post I lean towards us doing it but am open to hear why not

The current text on the snackbar is "Response submitted", any suggestion of a better wording?

Reply posted? Talk page post posted?

From a community perspective, I like the solution of offering the deletion option immediately after posting, by the way. Removing talk page posts (that aren't harassment, spam etc) is generally frowned upon, and the common way to do so is to use strikethrough – unless it's immediately after posting it, when there's sort of a grace period before it is considered confusing to remove what others might have acted on.

I filed some tasks related to the open questions here, so this task is now fine to be closed