Last modified: 2014-02-14 04:01:53 UTC
We discovered from bug 52891 that anonymous IPs and registered users who are blocked get a mysterious error from Special:GettingStarted. Currently, when they click one of three tasks, they get no response and the page just reloads. This is because there is a check for whether the user can edit the page called for, and if they are blocked they fail this editability check until they hit the maximum requests. This case is pretty rare, because the majority of visitors to this page just successfully created an account. However, it should be relatively simple to detect when a user/IP is blocked, and either redirect them somewhere appropriate or produce a special error.
This applies to the modal too. Not tested, but I think they'll always get the 1-button version pointing to GettingStarted, and then not be able to do anything if they follow it.
This bug also applies to the modal version (gettingStartedReturn=true). I tried this with a test account (User:WMF Test Account 049f00). The following behavior occurs: 1. Since the user is presented with the edit button still, they get the version which prompts them to "Edit this page", and they get tour=firstedit. This is a bug related to how we detect page editability, which I will file separately I think. 2. If the user clicks the "Find pages that need easy fixes" then task retrieval fails and they get directed to Special:GettingStarted/task/copyedit?source=redirect-invite-click
For the modal, our best solution might simply be checking for blocked status, and presenting no CTAs. For the Special page, an error state is likely needed. Which of these we need to solve for will be sorted out as part of [[m:R:OB6]] research.
I agree on what has been commented so far. In order to provide the less surprise to the user: - For the dialog, it makes sense not to show it (since that only provides useless options to the user). - For the GettingStarted, it makes sense to avoid automatic redirections to the GettingStarted page (for the same reason above). However, if the user has a link to it, then we should keep the place and inform about the situation. We can show the warning message* and a disabled version of the page (e.g., with 40% opacity) as illustrated in http://i.imgur.com/3BiEHtV.png in order to convey the idea of "this is the page you were used to visit, but now it is disabled because you are blocked". * The warning message shown is just an example, we can consider using the standard blocking template, or a specific version that provides appropriate call to actions to deal with the blocking
(In reply to comment #4) > I agree on what has been commented so far. In order to provide the less > surprise to the user: > > - For the dialog, it makes sense not to show it (since that only provides > useless options to the user). > > - For the GettingStarted, it makes sense to avoid automatic redirections to > the > GettingStarted page (for the same reason above). However, if the user has a > link to it, then we should keep the place and inform about the situation. We > can show the warning message* and a disabled version of the page (e.g., with > 40% opacity) as illustrated in http://i.imgur.com/3BiEHtV.png in order to > convey the idea of "this is the page you were used to visit, but now it is > disabled because you are blocked". > > > > * The warning message shown is just an example, we can consider using the > standard blocking template, or a specific version that provides appropriate > call to actions to deal with the blocking I think your suggestion for Special page definitely works Pau. In the case of prevented actions, there isn't actually a standard MediaWiki message, for instance the edit screen specifically refers to editing, etc. For the "call to action" question: when a user is blocked they will get a talk page message with unblock request instructions, so if we include a link it should refer to that thread, if possible. We'll reassess which solution we need after the A/B test results are finished.
Okay, so with the new version of GettingStarted, the experience is much better. If a user is blocked in between the time they register and when they get redirected to their returnto page (very unlikely), they do not get a secondary CTA leading to a copyediting task. This should be very rare. If a user is blocked they can be served the primary CTA, or take either the 'firstedit' or 'firsteditve' tours, or they can take the task toolbar tours. These tours will still work up until the point a user clicks edit, when the Preview step fails to find and attach to the Preview element. Either way, these cases are going to be very very rare because a user only gets these dialogs right after registration. In order to get the broken tour they would have to be blocked in a matter of minutes or seconds, mostly likely. I don't think this is prevalent enough for us to spend a lot of time fixing.
