Block notices on mobile web provide insufficient information about the block
Open, NormalPublic5 Story Points

Description

Problem

I have tested and found this issue using Wikipedia on the mobile web (i.e. MobileFrontend) and the Wikipedia app for iOS. (Apologies if I've filed this under the wrong tags.) On the English Wikipedia, it is policy for administrators, upon blocking a user, to provide certain information about the block. See WP:EXPLAINBLOCK. Using the standard desktop site, whenever a user attempts to edit a page using a blocked account, they are presented with a host of information, including:

  1. The reason for the block
  2. The name of the administrator that place the block
  3. The expiration date for the block
  4. Links to pages that explain what blocks are used for and how to appeal them

It is essential that all four of the aforementioned pieces of information are supplied to a user when they are blocked. Especially for users editing from shared IP addresses, blocks can affect innocent users, and for users contributing in good faith, a block intended to be temporary (e.g. for edit warring) can turn the blocked user away from the project in bitterness if the block is not explained and if avenues for appeal are not provided.

I created a test account and blocked the account with the reason "Testing what a block looks like on mobile" and with an expiration date of 1 week. This was the notice I saw on my desktop when I tried to edit the sandbox:


This notice is supplied by the English Wikipedia's interface page MediaWiki:Blockedtext.

On a mobile device, however, we have a different story. I used Safari on my iPhone 6s, running iOS 10.2, to access Wikipedia using the MobileFrontend and attempted to edit the sandbox using my blocked test account. (This is the same block from when I tried it on my desktop computer.) When I clicked the pencil icon to edit the page, here is what I saw.

The notice does mention the administrator that placed the block (me in this case) as well as the reason for the block, but as you can see, the block reason fails to display a hyperlink properly, displaying the raw HTML code for a link instead. Furthermore, the notice says nothing about the expiration date for the block or how the block can be appealed.

Replication steps

Acceptance criteria

  • When a person is blocked from editing on the mobile web skip taps an edit pencil, display the block in a drawer (as per the mockup below)
  • The UI messages and icons should match the design
    • 'Got it' should be 'OK'
  • The blocking user and expiration date should accurately display
    • If the expiration is set to 'indefinite' the expiration info should not display
  • Tapping the down arrow or 'Got it' button should close the drawer
  • The block reason should display as plaintext, except for links.
    • Links should display as blue links and on tap open in the same tab.
    • Templates should render as plaintext, e.g. {{anonblock}}
    • If there is no reason, the reason info should not display
  • The 'Need help?' link should point to https://en.m.wikipedia.org/w/index.php?title=Help:I_have_been_blocked on English Wikipedia and should be customizable per wiki.
  • Test for long usernames, block reasons, and in long languages (e.g. German translations)

Mockup

Additional notes

There are a very large number of changes, so older changes are hidden. Show Older Changes

If AH team is going to be working on this, I wouldn't mind doing the design. I can put up potential solutions soon.

@Nirzar — we'd like to size this next Tuesday, February 27.

@Nirzar — This missed the cutoff for AHT Sprint 16. I really want to get it into Sprint 17 (begins March 14.) If you don't think this is feasible we can postpone to Q4.

@TBolliger apologies, I was OOO during this period. I will make sure this is posted before March 14

We use two patterns when it comes to displaying information about an action that cannot be done for various reason.

  1. simple string message = toast message

  1. more information and further action that can be taken = drawer

Showing blocked notice and helping the user will require for us to use the second approach.
Here's how it might look with the drawer

Yes, the drawer looks like a good treatment. Would 'Got it' just close the drawer?

Looking at the English Wikipedia block log, a lot of block reasons are just templates. I'll take a look at the information that's in these templates tomorrow and post here.

@TBolliger lemme know if anyone in the team needs an intro to the code. Ideally this would be able to use the Drawer JS class. We'll probably need to collaborate a little to improve the code to accommodate this use case (and the button) however.

Thank you @Jdlrobson ! We'll size this on Friday and may decide to perform a technical investigation first to familiarize ourselves with the mobile web code, during which we'd probably meet with you to knowledge share.

I looked at the first 5 block templates used on English Wikipedia and collated screenshots on thie publicly accessible Google doc. Although they're all wordy they all look 'acceptable' on mobile.

Here's what I propose: a simple way to solve this with the design in F14397273 :

  • If the block reason is plaintext, display as plaintext.
  • If the block reason contains a link, parse the link.
  • If the block reason is a template, it should display as a link. On tap it should display the parsed template.
  • The 'Got it' should close the drawer (I'd actually suggest less colloquial language, such as "OK")
  • The 'Need help?' link should point here.

What do you all think?

Minor question: Should links (or templates as links) in the block reason open in the same tab or another tab?

  • If the block reason is a template, it should display as a link. On tap it should display the parsed template.

I think this might be problematic because transcluding changes the apperance of many templates especially if additional parameters have been specified.

  • The 'Need help?' link should point here.

This needs to be configurable in MediaWiki namespace.

@TBolliger

  • Note that an editor can put absolutely anything in a block template via Special:AbuseFilter - there is no enforced structure to them. As @MGChecker alludes to all these messages are defined by editors in wikitext so can continue absolutely anything

e.g. https://en.m.wikipedia.org/wiki/MediaWiki:Abusefilter-warning-talkblanking

  • If you are planning to parse the message and try to force it into a certain shape, you'll probably need to think about what happens if the reason text is too long; there is not a clear link to action or the message cannot be parsed.

(apologies if you're aware of these problems)

@Jdlrobson This may be passing the buck, but perhaps we split this into two projects:

  1. make block warnings on mobile use the drawer (and render templates as plaintext)
  2. better handle templates as block reasons on mobile

Sound good?

TBolliger updated the task description. (Show Details)Mar 14 2018, 6:27 PM
TBolliger renamed this task from Block notices on mobile provide insufficient information about the block to Block notices on mobile web provide insufficient information about the block.
TBolliger updated the task description. (Show Details)Mar 14 2018, 6:48 PM
TBolliger updated the task description. (Show Details)
TBolliger set the point value for this task to 5.Mar 14 2018, 6:53 PM

Rendering as a drawer sounds like a step in the right direction. We usually screen scrape this sort of thing and help converge editors to a standard consistent way of marking up content. We are seeing similar problems in the page issues work https://phabricator.wikimedia.org/T187916 may provide guidance/ideas!

dbarratt claimed this task.

Change 426641 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/skins/MinervaNeue@master] [WIP] Use a Draer for Block Notices

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

For the line that says "Block will expire in", what happens when the value is infinite ? Should we use the message "Never"? is it safe to use the underline-never key or should I create a new one?

Block will expire in: Never sounds bit odd, can we have a separate treatment like this -

jrbs added a subscriber: jrbs.EditedWed, Apr 18, 7:10 PM

Block will expire in: Never sounds bit odd, can we have a separate treatment like this -

"Permanent" implies there are no appeals. English Wikipedia currently uses "indefinite" to soften that, other languages may use the same approach.

(Sorry if my comment is off-base for this task :)

(Sorry if my comment is off-base for this task :)

Never! :P

What about "This block has no expiration date" which avoids strong words like "permanent" and also leaves room for appeals.

What about "This block has no expiration date" which avoids strong words like "permanent" and also leaves room for appeals.

Or could we just remove that piece of information completely? So if it's infinite, the last bit will be who blocked you?

Johan added a subscriber: Johan.Wed, Apr 18, 9:31 PM

I think that could work.

Restricted Application added a project: Product-Analytics. · View Herald TranscriptWed, Apr 18, 11:53 PM
Krinkle added a subscriber: Krinkle.EditedThu, Apr 19, 12:01 AM

@dbarratt Btw, T192512 is a good find, but with regards to the current task, I'm not entirely sure whether removeHTMLtags() should be used. The block reason is a "comment" field, which unlike regular wikitext content, only supports internal wiki links. These are rendered with their own parser pass, and output HTML that should be usable directly in the proposed interface.

The same is already used on diffs, logs, page history, recent changes, etc.

oooo! ok, I didn't know about that. I saw that we were using OutputPage::parseInline() I didn't realize there was a better alternative, which looks like Linker::formatComment().

Thanks @Krinkle!

@Nirzar I don't see the hand icon in our library:
https://doc.wikimedia.org/oojs-ui/master/demos/?page=icons&theme=wikimediaui&direction=ltr&platform=desktop
do we use it somewhere else that I could look at?
or do we need to add something like that to the library?

yeah we don't have it in our library right now. here's an svg but i will make sure this gets into our iconset eventually. this creates a little bit of debt for all of us

stjn added a subscriber: stjn.EditedThu, Apr 19, 9:00 PM

If that would be interesting to you, we use a WikimediaUI-inspired block notice in Russian Wikipedia with a generic alert icon, so if stop-hand.svg would be approved and uploaded to Wikimedia Commons, that would probably be beneficial to Russian community.

TBolliger updated the task description. (Show Details)Fri, Apr 20, 1:49 AM
Krinkle added a comment.EditedFri, Apr 20, 2:19 AM

@dbarratt Glad that worked!

Btw, there is a bigger difference than just simplicity (between regular parsing and then stripping, vs using the comment parser). Which is that it wouldn't make {{anonblock}} appear as literal text, but would be expanded (per Trevor's requirement). This requirement exists as it would otherwise go against user expectation. Template:Anonblock itself is intended for use on the blockee's talk page (as boilerplate notification, where Anonblock is one of several such templates). As a short-cut, albeit mostly on en.wikipedia.org only, administrators often use the same wikitext syntax both on the talk page and in the edit summary or block reason, saying "Blocked with {{anonblock}}", where the template is not meant to be expanded but meant as literal text. Somewhat analogous to editing an infobox in a wiki article with edit summary "I changed {{Infobox television}} to {{Infobox actor}}".

@Krinkle Thank you so much for the explanation, I had no idea. :)

stjn added a comment.EditedFri, Apr 20, 11:52 AM

As a short-cut, albeit mostly on en.wikipedia.org only, administrators often use the same wikitext syntax both on the talk page and in the edit summary or block reason, saying "Blocked with {{anonblock}}", where the template is not meant to be expanded but meant as literal text.

Proxies, hosting IPs and the like are banned specifically with the templates so that it would be expanded as wiki text. See block log in English Wikipedia, for example.

Edit: this also is very urgent to mobile users, since mobile IPs are frequently banned exactly with the reasoning of being an open proxy.

What's the minimum screen width that we support?

@dbarratt 320px is the official threshold for mobile with JavaScript enabled but the mobile UI works from 300px onwards. Anything under that is likely to struggle unless it's a feature phone running say Opera Mini or has JS disabled (in which case they won't be able to get to this screen).

@Nirzar uhh... so how is all of this information supposed to fit on a 320px screen? I think the height 480px might also be an issue, unless we want to let the drawer stay open on scroll (it looks like the default is to close the drawer when the user scrolls)?

@Nirzar uhh... so how is all of this information supposed to fit on a 320px screen? I think the height 480px might also be an issue, unless we want to let the drawer stay open on scroll (it looks like the default is to close the drawer when the user scrolls)?

Nevermind, looks like my browser was forcing a larger font size, I reset it and it looks much better now. :)

Here's a status update (of what we have so far).

jrbs added a comment.Wed, Apr 25, 6:04 PM

Here's a status update (of what we have so far).

Design update? Since the red text doesn't really make sense, but I guess you're focused on the look of it right now.

Design update? Since the red text doesn't really make sense, but I guess you're focused on the look of it right now.

Yeah just wanted to show the current status of my work, this isn't done yet. :)

jrbs added a comment.Wed, Apr 25, 6:09 PM

Design update? Since the red text doesn't really make sense, but I guess you're focused on the look of it right now.

Yeah just wanted to show the current status of my work, this isn't done yet. :)

Gotcha! Looking pretty good I think!

Gotcha! Looking pretty good I think!

I really need to make my local Admin account Jim Gordon :P

@TBolliger

The 'Need help?' link should point to https://en.m.wikipedia.org/w/index.php?title=Help:I_have_been_blocked on English Wikipedia and should be customizable per wiki.

Where should the default be? Or should there be no link unless specified?

Good catch — is it possible to pull from https://www.wikidata.org/wiki/Q175291#sitelinks-wikipedia and allow individual wikis to customize?