Page MenuHomePhabricator

Quick UI changes to mobile web "you are blocked" message to increase helpfulness
Closed, ResolvedPublic2 Story Points

Description

Original report

Source including more details: Ticket#2018112210009281
A user sent us a screenshot like this:

There are two big problems with this screen:

  • The target of the block is not listed, so to find the relevant block log entry we had to look through all blocks performed by that user searching for the summary provided.
  • It says "Your account" when in actual fact this was an IP range block.

Acceptance criteria

  • Change the message from "Your account has" to "You have" for all blocks
  • Add a "Details" link to the right (on LTR) that sends the user to Special:BlockList?wpTarget=foobar, which has block information

Event Timeline

Krenair created this task.Nov 23 2018, 1:17 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 23 2018, 1:17 PM

FYI @TBolliger since AHT worked on this feature

Restricted Application added a subscriber: MGChecker. · View Herald TranscriptNov 23 2018, 6:54 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.Nov 26 2018, 6:19 PM

Yeah, those are some improvements we should make. If it's an IP address/range block it should probably say "You have been blocked."

Listing the original block target was omitted simply for lack of real estate. We need to also solve for T189717 which is a real estate issue.

Krenair added a comment.EditedNov 26 2018, 6:24 PM

If it's an IP address/range block it should probably say "You have been blocked."

Actually it would be preferable to make it clear that a block for an IP address/range is not necessarily aimed at the user seeing the block error message, by saying "Your address" instead of "You".

TBolliger renamed this task from User blocked message on mobile web is unhelpful to Quick UI changes to mobile web "you are blocked" message to increase helpfulness.Jan 30 2019, 11:15 PM
TBolliger triaged this task as Normal priority.
TBolliger updated the task description. (Show Details)
TBolliger moved this task from Backlog to Cards ready to be estimated on the Anti-Harassment board.
TBolliger updated the task description. (Show Details)Feb 7 2019, 6:40 PM

Potential design for the link:

TBolliger set the point value for this task to 2.

Sydney — we'll want to ask volunteers to re-translate the string

Tchanders claimed this task.Feb 7 2019, 8:58 PM

@TBolliger Is the user's talk page the best page to link to? As far as I can see, it doesn't contain block information in mobile frontend, and it only contains block information on desktop if you go to the edit tab... Unless I'm missing something!

Change 489099 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/MobileFrontend@master] WIP Changes to block message drawer

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

Doh! I meant Special:MyContributions, which should display the information about the IP or user.

TBolliger updated the task description. (Show Details)Feb 7 2019, 11:40 PM

@TBolliger Ok, that makes sense! The block details are present in the desktop version, but they still don't seem to be there in mobile frontend:

DestopMobile frontend

What do you think we should do? We can still add the link, then file a task to show the block details in mobile frontend, or link to somewhere else, or not have a link? The WIP patch currently has the link and looks like this:

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Can we link to the block log like this?
https://test.m.wikipedia.org/wiki/Special:Log?type=block&page=Koavf

Also, I think the text should be "More info" rather than "Need help?" and I think it's fine to add the link to the right there seems to be plenty of space? or am I missing something?

or even better might be to link to the block list... it looks kinda gross right now, but it at least lists the currently active blocks:
https://test.m.wikipedia.org/wiki/Special:BlockList?wpTarget=185.220.101.31

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!

No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.

If there will be a problem, the translators will complain ;)

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!
No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.
If there will be a problem, the translators will complain ;)

Thanks @Amire80 - sorry I wasn't clear with my question! The button currently says "OK" but there is a suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

...An additional concern might be that someone who is using English but isn't that confident in English might not understand "Got it"?

suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

This was intentionally changed to "OK" after the mock up was created, I don't think there is any intention to change it back.

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!
No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.
If there will be a problem, the translators will complain ;)

Thanks @Amire80 - sorry I wasn't clear with my question! The button currently says "OK" but there is a suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

This is also pretty OK. Here's an example with quite a lot of translations:
https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3ACx-campaign-ok-got-it&namespace=8

Whether you actually use it here is up to you. I'm not sure that it's appropriate; "Got it" sounds lighter and goes well with tutorials or constructive actions, whereas blocking may be less pleasant and justify a more neutral language. But as far as general localization concerns go, it's not bad.

Let's leave the button as "OK" per previous discussions.

I agree with David's suggestion of https://test.m.wikipedia.org/wiki/Special:BlockList?wpTarget=foobar

TBolliger updated the task description. (Show Details)Feb 8 2019, 5:12 PM

Change 489312 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Make Special:Myblocklist redirect page

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

@TBolliger @dbarratt Thanks, have updated the URL to Special:BlockList. The patch passes in the block ID param rather than the target, since the user attempting to edit might not be the target - e.g. if it's an autoblock or an IP range block.

Change 489312 abandoned by Tchanders:
Make Special:Myblocklist redirect page

Reason:
Filtering by block ID instead of target in Icda4b85bc03a1b4ffde2b5

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

@TBolliger @dbarratt Thanks, have updated the URL to Special:BlockList. The patch passes in the block ID param rather than the target, since the user attempting to edit might not be the target - e.g. if it's an autoblock or an IP range block.

Perfect! Great work. 🚀

Change 490615 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Add block ID query paramater to Special:BlockList

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

Change 490615 abandoned by Tchanders:
Add block ID query paramater to Special:BlockList

Reason:
Using wpTarget=#ID in Icda4b85bc03a1b4f instead - thanks Dbarratt

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

Change 489099 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Make block message drawer more informative

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

dom_walden added a subscriber: dom_walden.

Beta-cluster is currently read-only and test.wikipedia.org has an older version of MobileFrontend, so had to test on my local version:
MediaWiki 1.33.0-alpha (2e9c34c) 19:31, 14 February 2019
MobileFrontend 2.1.0 (a9a81ec) 17:22, 14 February 2019

But does not have VisualEditor. I don't know if that makes a difference. The pop-up occurs on the page before you get to the editor, so I guess not...

Sufficiently long blocking reasons can mean the top of the pop-up gets cut off (if viewport is small, i.e. on a small mobile phone). Not sure how likely that is, or if it is a major problem.

I notice many blocks on en.wiki use Templates. These don't work in the pop-up (appear as "{{templatename}}"). Perhaps to be expected. Side-effects of supporting templates probably too great. This way I guess is safer.

Otherwise, blocks of usernames and IP addresses (including auto-blocked IPs) appear with the correct reasons, correct expiry (if applicable) and show the correct block when you click "Details".

I saw this on Chromium with responsive design view and also on a Samsung N2, and it responds fine to changing orientation.

If a user is already part-way through editing a page when an admin blocks them, they get an error: "Error, edit not saved." with no other details. I will raise separately.

But does not have VisualEditor. I don't know if that makes a difference. The pop-up occurs on the page before you get to the editor, so I guess not...

Yeah you should get to it before that point.

Sufficiently long blocking reasons can mean the top of the pop-up gets cut off (if viewport is small, i.e. on a small mobile phone). Not sure how likely that is, or if it is a major problem.

I'm not sure, probably a good question for @TBolliger

I notice many blocks on en.wiki use Templates. These don't work in the pop-up (appear as "{{templatename}}"). Perhaps to be expected. Side-effects of supporting templates probably too great. This way I guess is safer.

T191939: How to deal with blocked messages on client that require advanced parsing?

If a user is already part-way through editing a page when an admin blocks them, they get an error: "Error, edit not saved." with no other details. I will raise separately.

That's interesting.

Ugh, templates for block reasons. Such a pain, and a tax that someone someday will have to pay.

If you can provide a screenshot of the pop-up cutting off on small viewports, I'd appreciate it. We can probably truncate the block reasons as a certain number of characters/lines. It should also be straightforward for us to calculate a distribution of block reason character counts to help determine how severe of a problem this is.

Ugh, templates for block reasons. Such a pain, and a tax that someone someday will have to pay.
If you can provide a screenshot of the pop-up cutting off on small viewports, I'd appreciate it. We can probably truncate the block reasons as a certain number of characters/lines. It should also be straightforward for us to calculate a distribution of block reason character counts to help determine how severe of a problem this is.

This is what it looks like (according to Chromium and Firefox's responsive design view) on the iPhone 5. The bit that tells the user "You have been blocked from editing $wiki" is cut off. This is an extreme but real life example from en.wiki.

Happens on view ports of that size (320x568) when the block reason goes over about 410 characters. Querying the replica table enwiki_p.ipblocks_compat only 6 of 1174140 have block reasons longer than this.

If a user is already part-way through editing a page when an admin blocks them, they get an error: "Error, edit not saved." with no other details. I will raise separately.

That's interesting.

I think the MobileFrontend only handles a few error conditions helpfully, and otherwise just shows a generic error (ref: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/master/src/mobile.editor.overlay/EditorOverlay.js#613). We could ask that blocks be handled more gracefully.

I've created T216533: Mobile web "you are blocked" notice should truncate long block reasons to document the long block reason. Not worth addressing for now.

I think we can ignore the use case of "blocked while editing" for now — there are several teams working on improving mobile editing, so these features/technologies are constantly evolving.

dbarratt closed this task as Resolved.Feb 20 2019, 10:28 PM