Page MenuHomePhabricator

Thank notification on mobile should support click to undo
Closed, ResolvedPublic5 Story Points

Description

Intention:
Look at diffs from my watchlist on my mobile phone. Big green "Thank" button is too easily accidentally pressed (large and near to phone's "back" button), and does not then ask for confirmation as the desktop version does. I have accidentally thanked editors, through fat finger accidents. It's ironic that I get asked for confirmation after clicking the small "thank" link on desktop, but not when touching a large touchscreen button here.

Reproducible: Didn't try

Please provide a forum on English Wikipedia where questions about mobile access can be discussed.


Version: unspecified
Severity: enhancement
See Also:
T49658: Thanks workflow needs further thought
T71804: Thanks tool: How much does the confirmation button cost us?

Acceptance criteria

  • When clicking thanks button an API request is queued and a notification is shown
  • When undo in the notification is clicked, the API request is cancelled
  • When the notification disappears the API request is sent
  • When the API request is fulfilled, the thank button label changes to "Thanked"

Developer notes

TLDR:
This is pretty straightforward https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Thanks/+/442749 does most of the legwork so take a look at it. Needs i18n and some CSS to handle the disabled state.

This will require a 2nd patch in Minerva (to style undo icon).

Extended notes

Talking to @Mooeypoo, apparently the issue with undoing Thanks is how to handle things in the log. Do we log that a user undid a thank or do we not log that at all.

As a result of this, we plan to introduce a client side delay on the api call allowing user to click again to undo:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Thanks/+/442749

We will leave 2* seconds between clicking and sending the thanks - allowing user time to click it again to cancel.


(note:delay intentionally long so its obvious there is a delay,but in practice I suspect 2seconds should be enough)

@alexhollender provided these mocks:

Note: The code is located in Thanks extension

Acceptance criteria

  • It will now be possible to have a single action inside a toast. Given mw.notify does not support this, this should be implemented within the Toast component -

Under the hood might work like so:

mw.notify($('<span>Hello <a class="link-created-by-toast-with-correct-classes">action</a></span>'))
  • When clicking thank, the button should change state and a a "Thanking TestTest... UNDO toast will show.

if the user hits undo the API request will be cancelled.

  • If the user does nothing, the API request is sent.
  • On completion of the API request, a toast will show saying "You have thanked TestTest."

If the user clicks undo, the thank button should return to its unclicked state.

  • subject to tweaking

QA steps

(heads up @Ryasmeen you may get some Thanks love as part of testing - let me know if that's a problem :-))

Details

Reference
bz61737

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
alexhollender added a comment.EditedJul 9 2018, 10:38 PM

@Jdlrobson how does this look?

Jdlrobson removed alexhollender as the assignee of this task.Jul 9 2018, 11:19 PM
Jdlrobson updated the task description. (Show Details)

Ready for estimation.

Jdlrobson updated the task description. (Show Details)Jul 9 2018, 11:24 PM
Jdlrobson updated the task description. (Show Details)Jul 9 2018, 11:57 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 10 2018, 5:53 PM
pmiazga updated the task description. (Show Details)Jul 17 2018, 4:17 PM

After briefly discussing this task with the readers web team, a concern was raised that it might be difficult to coordinate the "Thanks" button with the "toast" component because the button lives in it's own extension, and the "toast" notification lives in mobilefrontend. Coordinating these two elements would mean creating a dependency between them, which might lead to breakage if one is not update updated without the other.

In line 18 of ext.thanks.mobilediff.js It seems the Thanks button already depends on the "toast" component, defined as a global variable popup, right below the comment // FIXME: What is "popup" and where is it defined?. Personally, I'd like to avoid creating these dependencies.

On desktop, it looks like the entire thank/confirm workflow is contained inside a single component. Could we try something similar for the mobile treatment?

Note, it is not necessary to use the toast component. It's just a wrapper for mw.notify which has Minerva specific styling.

Jdlrobson updated the task description. (Show Details)Jul 24 2018, 1:44 PM
Jdlrobson moved this task from Needs Prioritization to Upcoming on the Readers-Web-Backlog board.

I have updated POC in developer notes to show that there should be no concerns about dependencies. The POC does most of this change. We won't be creating complex thank/confirm workflows. Putting back in upcoming for another estimation attempt.

pmiazga set the point value for this task to 5.Aug 1 2018, 4:24 PM
pmiazga added a subscriber: pmiazga.

We estimated this 5 points mostly because of the risk - looks like there is not that much of code to write but no-one in our team worked with Thanks extension.

Change 442749 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/Thanks@master] Add client side click to undo on thank

https://gerrit.wikimedia.org/r/442749

Jdlrobson added a comment.EditedNov 15 2018, 6:40 PM

I rebased my old patch. If important, I suggest this is voted in the community wishlist so that it is prioritised more and the patch reviewed.

PamD added a comment.Nov 15 2018, 11:32 PM

So, please clarify: does this mean that 4 years on from my first request we're now being told nothing will happen unless we put it through the Community Wishlist scheme?

No. It means that the addition of this request in the wishlist this year helps with prioritization. It’s a good thing. Let’s hope it receives many votes.

The wording "undo" seems off to me, since it implies that the action has already be done. However the wording is in the present tense ("Thanking {username}..."). I would suggest "cancel" instead of "undo"
Tapping on the black bar (not the cancel button) closes the bar, and then a moment later you see "You thanked {user}". Might we consider any taps on the black bar as an "undo/cancel" action?

@alexhollender I got some feedback on my patch. Thoughts on using "cancel" here instead and clicking anywhere in the bar cancelling?

@Jdlrobson, I agree that "Cancel" makes more sense. I think the cancel action should only be triggered by tapping on the button, otherwise I think we'll get accidental cancels (e.g. someone trying to swipe the toast message away will accidentally cancel their thank).

kostajh moved this task from Incoming to QA on the Growth-Team (Current Sprint) board.

Change 442749 merged by jenkins-bot:
[mediawiki/extensions/Thanks@master] Add client side click to cancel on thank

https://gerrit.wikimedia.org/r/442749

Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Ryasmeen.

@alexhollender the click to cancel functionality is now live on beta cluster and ready for this weeks train. Take a look! @PamD please give it a try and let me know if this solves your originally posted problem.

phuedx added a subscriber: phuedx.Feb 11 2019, 6:55 PM

@alexhollender the click to cancel functionality is now live on beta cluster and ready for this weeks train.

i.e. this will be deployed to all wikis on Thursday, 14th February.

Change 442748 abandoned by Jdlrobson:
Confirm thanks before sending to users

https://gerrit.wikimedia.org/r/442748

Etonkovidova added a subscriber: Etonkovidova.EditedFeb 12 2019, 1:36 AM

@Jdlrobson - please review the following.
Testing on betalabs:
(1) The state is of 'Thank' button does not persists - click on 'Thanks' , wait for the confirmation and finishing of the action (grey 'Thanked' button), go to the next edit, return - the 'Thank' button will be active again. Also, the desktop and mobile do not sync - actions on the desktop are not reflected on mobile.

(2) The second and third screenshots - the label is centered and the user name and 'Cancel' are overlapping

(3) 'cancel' is not capitalized? It looks inconsistent with 'Thank' and other button labeling.

(4) Inconsistency with Desktop. The 'Thank' action on Desktop does not have a waiting period, it needs to be confirmed, which is just another click. On mobile, waiting period might be too short for some users or it might be unexpected for users to see Thank action proceed without confirmation,

please review the following.

Will do! thanks for the feedback!

(2) The second and third screenshots - the label is centered and the user name and 'Cancel' are overlapping

Will fix tomorrow first thing cc @kostajh.

(3) 'cancel' is not capitalized? It looks inconsistent with 'Thank' and other button labeling.

You are right. (T63737#4409991)
ill follow up on this tomorrow.

Also, the desktop and mobile do not sync - actions on the desktop are not reflected on mobile.

Yup this was the case before too.

Inconsistency with Desktop. The 'Thank' action on Desktop does not have a waiting period

Yup. This is expected.

Looks great. I'm fine with the centered text and the action on a separate line. Here is what I'm seeing:

Passing this back over to @Etonkovidova. Not sure if it's meant to be on both Readers and Growth boards — feel free to remove one or the other.

Note, the thanks feature does appear to be working despite the refresh behaviour (they show up in the log: https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Log?type=&user=Jdlrobson&page=&wpdate=&tagfilter=&wpfilters%5B%5D=thanks )

I see one remaining problem with this - when clicking on the toast outside the cancel button it dismisses the toast making it impossible to close. The notification api doesn't seem to support disabling this behavior so will likely need to deal with that in a separate bug. At least there's some way to undo an accidental thanks now even if not perfect..!

This is now live on mediawiki.org:
https://m.mediawiki.org/wiki/Special:MobileDiff/2507497

@Jdlrobson what do you mean by

it dismisses the toast making it impossible to close

To close what? For me it dismisses the toast, and then the thank completes as expected.

@Jdlrobson what do you mean by

it dismisses the toast making it impossible to close

To close what? For me it dismisses the toast, and then the thank completes as expected.

That's what I mean. What if you want to "cancel" but you accidentally click outside it and the thanks completes. Is this something we should be worried about?

That's what I mean. What if you want to "cancel" but you accidentally click outside it and the thanks completes. Is this something we should be worried about?

An alternative (mentioned a few times in this task and in use on desktop) would be to ask for confirmation instead of cancellation. It could be implemented within the same UI (replace “cancel” with “confirm thanks”, and provide 10-20 seconds instead of 2). That way, missing the target would result in not thanking rather than an accidental thanks. And it would be clear that the thanks didn’t happen.

@Jdlrobson I can see it both ways — clicking the toast outside the button shouldn't do anything, however toasts are often dismissible with a swipe, so it doesn't seem that crazy that tapping it dismisses it.

@kostajh I'm not opposed to that, although I'm not sure if we use our toast messages for confirming actions — I'd have to check on that.

Checked in testwiki (wmf.17) - the positioning of Cancel button looks good and makes it easy to cancel the action. Although I support 'Confirm' instead of cancel as it was mentioned on the ticket (by @kostajh and me).

And it'd be great to make 'Thank'

  • persistent between navigating from one edit to another ('Older' and 'Newer') and between user sessions
  • persistent (in sync) between mobile and desktop

    @Jdlrobson and @alexhollender - QA work is done for this ticket; if there are no more follow-ups - you may mark it as 'Resolved'.
Restricted Application added a project: Growth-Team. · View Herald TranscriptFeb 14 2019, 4:36 PM
Jdlrobson closed this task as Resolved.Feb 14 2019, 4:56 PM

I don't want to get into the discussion of cancelling
Vs multi step processes (https://phabricator.wikimedia.org/T63737#664824)

Let's see if this solves the problem.

I still think the correct solution here would be to support an undo API and use that on both desktop and mobile but that can be the subject of another task if this solution doesn't solve the underlying problem.

Thanks for QAing @Etonkovidova

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptFeb 14 2019, 4:57 PM

@Jdlrobson @Etonkovidova Why not go with a confirmation button; as executed via this script?

It is primarily intended to allow an undo whilst within the Mobile-Frontend extension but also adds a confirmation dialogue to the thank button.

T71804: Thanks tool: How much does the confirmation button cost us? Has a lot of background on why a confirm step might not be suitable for mobile but we've not had time to do that research. Please read and feel free to ask questions there.

@Etonkovidova - It seems to be intermittent in cancelling for me. I'm on chrome os and using the touchscreen. When i think i've clicked cancel in beta the button goes grey and registers it. I was able to cancel once though so i'm not sure if the button needs to be bigger or show for longer.

@Etonkovidova - It seems to be intermittent in cancelling for me. I'm on chrome os and using the touchscreen. When i think i've clicked cancel in beta the button goes grey and registers it. I was able to cancel once though so i'm not sure if the button needs to be bigger or show for longer.

@Etonkovidova / @Jdlrobson - Any update on my feedback.