https://bugzilla.wikimedia.org/show_bug.cgi?id=53069
--- Comment #3 from Kunal Mehta (Legoktm) <[email protected]> --- (In reply to comment #0) > This bug tracks obstacles to enabling anonymous editing via > [[mw:Extension:MobileFrontend]]. Thanks. I've added blockers for a few technical issues I found when testing. I'm not going to attempt to respond to everything, just stuff I'm concerned about. > It's not quite so simple as a permissions change. Longer explanation below, > but > the tl;dr is that there's a lot of design and development work that needs to > be > done before we can just flip the switch. > > First and most importantly: editing a wiki "anonymously" means leaving a > permanent, searchable trace of your IP address in connection with your edits; > this is actually a non-trivial and in many cases highly sensitive piece of > metadata. As a bare minimum requirement to ensure the safety and privacy of > our > users, we would need to build an educational system into the mobile editor > that > alerted users of their logged out status, made them understand the > implications > of this (e.g. if they're in a country where their edits could put them in > danger, make sure they're aware that they're basically geo-targeting > themselves > by editing without an account), and let them login/signup before saving their > edit. On desktop, we do this with a series of templates and mediawiki > messages, > but mobile has a very different, radically constrained UI, and solving this > problem in a way that doesn't hinder the ability to actually make an edit and > gets people to read and understand the disclaimer isn't easy or > straightforward. Basically there needs to be some mobile equivalent of the anoneditwarning ([[MediaWiki:Anoneditwarning]]). > In addition to this bare minimum requirement, there are a > host > of other social, UX-related, and technical challenges to opening up an > anonymous editing funnel on mobile: > > 1. Mobile devices are quite different from desktop in that it's much easier > to > fat-finger and accidentally do something you didn't intend to do. A highly > motivated IP editor on desktop who accidentally (or as a test) blanks a page > might discover the page history and the undo button – that's much harder to > do > on mobile, where the history view is currently so tiny and cluttered that > undo > is barely enough of a target to tap on, let alone see. Until we have a nice, > clean, mobile-friendly history view and revert actions (something the team is > going to be working on sometime this year), you'll get a lot of first-time > users messing up or messing around with no way to clean up the mess. Is this for users to revert themselves by finding the page history and hitting undo? I'd imagine that if I'm using huggle a revert would be near instantaneous, but if I had to use my fat-fingers on a mobile device, it would take at least a minute. Is there any evidence that logged in users have this issue? Users are already forced to view a preview and then hit save, so there already is an extra confirmation step that desktop doesn't have. > > 2. On desktop, it's not as huge a break from your workflow to leave what > you're > editing, log in, and keep editing; on mobile, where everything is so focused > and zoomed-in, that feels like a huge break. Unless we made it obvious *why* > an > account is beneficial, it's doubtful most anon editors would go through the > trouble of creating an account to fix a typo -- but that means they're > missing > out on important features like a watchlist and a notification system (see > point > 4). So we're rejecting an edit from a potential contributor because they don't know that they can experience more features? That sounds backwards. > > 3. The abuse filter is already a huge problem for mobile, since on many wikis > it's configured to show a CAPTCHA for certain conditions (non-autoconfirmed > users adding links, adding/removing large chunks of text, or, on projects > like > Portuguese Wikipedia, making edits of any kind), which in turn causes the > mobile editor to throw an error. Right now the error rate is hovering at an > alarming 48% across all projects; making editing available to anons would > guarantee that the error rate would skyrocket. Until we build a replacement > for > the abusefilter CAPTCHA (again, a tricky engineering problem on mobile), we'd > knowingly be showing anons a broken and unusable edit button most of the > time. I found bug 53369 for AbuseFilter, but couldn't find one for CAPTCHA. FWIW, the AbuseFilter can't be told to show a CAPTCHA, they're two totally separate extensions. > > 4. A lot of the features we're building on desktop to keep people in the loop > about what's happening to their edits (like email and Echo notifications) are > for logged in users only, and those become extra critical communication > mechanisms on mobile, where it's harder (and, again, a bigger break from your > workflow) to find and check your talk page. I'm not sure how we'd build a > notification system for mobile IP editors without unnecessarily spamming a > huge > swath of mobile readers with notifications about user warnings that don't > involve them. This is already a problem on desktop, but it becomes > exponentially more problematic with the wildly fluctuating IPs of most mobile > devices. I filed bug 56828 for discussing enabling Echo for anonymous users. I don't think that is a blocker for mobile editing though. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
