Last modified: 2014-11-03 14:44:01 UTC
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.
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1722
Click again to undo? This seems to be a common design pattern across the mobile web... a confirmation step sounds nasty...
No, clicking again doesn't work: the "Thank" is sent instantly and the green button then turns to an unclickable "Thanked". Plenty of operations on my mobile have an "are you sure?" confirmation option: what's "nasty" about that? Alternatively, I'd appreciate an option to turn off the "Thank" facility when I'm on mobile: it's just too easy to hit that huge green button by mistake.
The Thanks extension has a few bugs in this bug tracker related to this issue (on desktop).
We've filed this as an enhancement request. We will look at a click to undo behavior.
But as it has instant effect, the message will already have gone to the inappropriate recipient before it can be undone, leading to potential confusion or embarrassment. A real confirmation stage, or option to opt out of Thanks on mobile, would be much more sensible.
If Bug 53879 results in one-click thanking on desktop, then Mobile might be able to use the same method. The main point is this: People definitely do mis-click the Thanks buttons on *all* platforms. We need to stop those accidental triggers regardless of cause. There is no visual design that will stop mis-clicks due to carpal tunnel issues, dropping your smartphone, or other accidents. We need a system that assumes that some percentage of clicks will be unwanted. (When Thanks was new on desktop, some people thought that it might be a quarter of all Thanks). There must be a method available to the user to make them notice what happened, and to either refuse to confirm it or to cancel it. My preference is for an active confirmation, because a 30-second timer does you no good if a cat walks across your device when you're in the next room.
Dropping a phone will not lead to accidental button presses. Please read https://en.m.wikipedia.org/wiki/Capacitive_sensing and I don't think we should be making a bad UX because of a rogue cat. Do we have any real data that shows this a problem on mobile? Seems like a load of fuss about a non-issue. Adding design to get their input.
Sure, the act of dropping *shouldn't* click anything... assuming that it lands on the floor and not your bare leg, or your foot... but you still have to pick it up, which means you might touch the screen. You might even try to catch that expensive piece of hardware before it hits the floor and breaks, which also means that you might touch the screen. As far as I'm concerned, if we're getting complaints about this, then we should do something about it. Every single one of these is a potential source of embarrassment for editors. The cause of the misclick can't be solved; the fact that a single mistaken touch causes an irreversible and potentially embarrassing (public) communication between users is solvable. As for data, you'll get it the day after you implement a confirmation step and can thereby see how many fewer thanks are used by experienced editors.
see #c5 it is not a top priority but we believe click to undo is the way forward.
Agreed, it's not the dropping but the catching ... or the tired editor's scrolling-finger drooping and landing on the bottom right corner, the most vulnerable corner of the screen (assuming right-handed editor), where this large green button sits, or a fumbling editor aiming for the phone's "back" button a few millimetres away and missing. My experience is on a Samsung Galaxy Fame, an unreliable local data service and flaky wifi: devs may be accustomed to rather larger, faster, machines. You want evidence: https://en.wikipedia.org/w/index.php?title=User_talk:Skookum1&diff=prev&oldid=620599401 is a recent diff. Please do one of several things: 1: Require a confirmation click (in a different part of the screen so an accidental doubleclick wouldn't do it) 2: Have a delayed action "Thank" with undo, so that pressing the button again within 30 secs or whatever will stop the Thank from going through (ie the accidentally "thanked" editor sees nothing) 3: Move the thank button to a less accident-prone part of the screen and/or reduce its size - if I need precision clicking to do everything else on mobile, why make an exception for this? 4: Provide a Preference of opting out of Thanking on mobile.
That is indeed a very large button, on a small screen! Given the previous discussions about confirmation-steps on desktop, I've filed bug 69636 ("Thanks: Implement an undo feature")
Having a secondary confirm on mobile is moving in the wrong direction, I think the number of accidental clicks is far outweighed by the number of thanks we'd lose (and are currently losing) by having a confirmation step.
How exactly do we know that we're losing any WANTED thanks at all? (We're supposed to be "losing" thanks that people didn't want to send.)
its conjecture, and 10+ years of experience that multi-step processes have greater falloff then single step actions.
I'm willing to believe that every click costs readers. Do you know how many thanks are not being completed on desktop? Does it differ by user experience level? Getting those numbes would let you make some estimates. I suspect that uncompleted thanks among people with thousands of edits are due almost entirely to not wanting to send thanks. (All of mine, for example: I know that the thanks button requires confirmation, and I intentionally look for the confirmation.)
WhatamIdoing, can you log a bug requesting information from analytics/instrumentation for thanks clicks that were abandoned on the subsequent confirmation page segmented by user edits please?
This really is a silly discussion. We agree there is a problem and that it needs to fix but I personally think arguing the merits of a click to undo vs confirmation step is a waste of WMF resources.
I filed the request for information at bug 69804. Jon, if the confirmation step on desktop is working (stopping unwanted thanks without losing many wanted ones), then it can be copied to mobile, we'll have a consistent interface across all platforms, and the significant engineering effort to make it undo-able can be skipped.
Thanks for filing this bug WhatamIdoing, my gut feeling is that the opposite will happen, that we'll be able to developer an undoable behavior that can work across all platforms consistently rather than a modal or two step process as a means of achieving consistency. But we'll see what happens. Thanks again.
I've now filed Bug 72903 - Need option to switch off "Thanks", in view of the slow progress on this or Bug 69636.
