Following up from a discussion on unblock-en-l...
How much effort would it be to add an enhancement to treat blocked user redlink clicks like we currently treat anon user redlink clicks when anon article creation is disabled?
We're trying to minimize the number of people who are fundamentally just readers, who click on a redlink and see a block message (mostly AOL users, but it happens to others). If they click on the "edit" bar and get it, that's fine, but if the default redlink behavior didn't show the block message then that would be great.
Thanks.
On 10/11/06, George Herbert george.herbert@gmail.com wrote:
Following up from a discussion on unblock-en-l...
How much effort would it be to add an enhancement to treat blocked user redlink clicks like we currently treat anon user redlink clicks when anon article creation is disabled?
We're trying to minimize the number of people who are fundamentally just readers, who click on a redlink and see a block message (mostly AOL users, but it happens to others). If they click on the "edit" bar and get it, that's fine, but if the default redlink behavior didn't show the block message then that would be great.
Thanks.
I don't think it would be appropriate to just say "you can't create this article because you aren't logged in", when there are more reasons as well. That would imply to the user that if they *did* log in, they'd be allowed to create the article, which isn't the case. They need to be informed that they've been blocked, preferably as well as any other reasons they can't do stuff.
Tangential question: why is User::isBlocked a public method altogether? Why not just run everything through a generic permissions-checker method, and return an array of reasons (rather than "false" as with User::isAllowed) if that's the answer? That would ensure consistent handling of blocked vs. other reasons *everywhere*, which I should think would be desirable. It would also ensure that people got the full story as to why they couldn't do something, rather than a single reason of multiple.
On 10/11/06, Simetrical Simetrical+wikitech@gmail.com wrote:
On 10/11/06, George Herbert george.herbert@gmail.com wrote:
Following up from a discussion on unblock-en-l...
How much effort would it be to add an enhancement to treat blocked user redlink clicks like we currently treat anon user redlink clicks when anon article creation is disabled?
We're trying to minimize the number of people who are fundamentally just readers, who click on a redlink and see a block message (mostly AOL users, but it happens to others). If they click on the "edit" bar and get it, that's fine, but if the default redlink behavior didn't show the block message then that would be great.
Thanks.
I don't think it would be appropriate to just say "you can't create this article because you aren't logged in", when there are more reasons as well. That would imply to the user that if they *did* log in, they'd be allowed to create the article, which isn't the case. They need to be informed that they've been blocked, preferably as well as any other reasons they can't do stuff.
The problem here is that a lot of people "are blocked" who really aren't specifically... anyone at AOL who hasn't already created a WP account and consistently logging in, for example, is blocked from editing a significant fraction of the time, due to rolling AOL vandal IP blocks.
Telling them that they're blocked if they click "Edit" is fine; that's a clear positive action intending to edit something.
A lot of requests that come in to unblock-en-l are AOL people who had clicked on a redlink and thought they'd been blocked from reading.
It's not really denying info to a really blocked person; most of the time an "editor" goes to edit something, they don't start by clicking on a redlink to create a new article. A small fraction of the time, yes, but not most of the time.
I think that accepting that a small fraction of the time, some blocked users will hit a redlink and stumble a bit more before they find out that they're blocked, while making nearly all the AOL complaints simply go away, would be a strong net positive.
On 10/11/06, George Herbert george.herbert@gmail.com wrote:
The problem here is that a lot of people "are blocked" who really aren't specifically... anyone at AOL who hasn't already created a WP account and consistently logging in, for example, is blocked from editing a significant fraction of the time, due to rolling AOL vandal IP blocks.
Telling them that they're blocked if they click "Edit" is fine; that's a clear positive action intending to edit something.
A lot of requests that come in to unblock-en-l are AOL people who had clicked on a redlink and thought they'd been blocked from reading.
Any message for an AOL block should make it 100% crystal-clear that the block has nothing to do with them, will be very temporary, and will only stop them from editing, not reading. If it doesn't, change the block message.
Changing page rendering depending if user is blocked or not won't happen. It would break page caching (this appeared before but asking to change 'edit' into 'view source').
Platonides wrote:
Changing page rendering depending if user is blocked or not won't happen. It would break page caching (this appeared before but asking to change 'edit' into 'view source').
We could give *all* red links a different URL than other editing methods. Then we could check blocked status when the red link URL is requested, and display an edit form or error message as necessary.
-- Tim Starling
On 10/12/06, Tim Starling tstarling@wikimedia.org wrote:
We could give *all* red links a different URL than other editing methods. Then we could check blocked status when the red link URL is requested, and display an edit form or error message as necessary.
That sounds good actually. Red link meaning "edit this new page" has a cute wikiness about it, but can be fairly impractical. If we did this, we could also implement some kind of last-ditch attempt to locate the page with searching. Thus, avoiding the problem where a redlink caused by incorrect case (eg, [[foo city]] instead of [[Foo City]]) ends up as a duplicate article...
Steve
On 10/12/06, Tim Starling tstarling@wikimedia.org wrote:
We could give *all* red links a different URL than other editing methods.
You don't even need to change the URL. It should be enough to detect when the edit form is invoked with an non-existing page.
"Lars Aronsson" lars@aronsson.se wrote in message news:Pine.LNX.4.64.0610130109240.9022@localhost.localdomain...
On 10/12/06, Tim Starling
tstarling@wikimedia.org wrote:
We could give *all* red links a different URL than other editing
methods.
You don't even need to change the URL. It should be enough to detect when the edit form is invoked with an non-existing page.
...and then what? Bear in mind that the software can't currently tell the difference between clicking a red link, vistiting a non-existant page and clicking 'edit' and typing an "?action=edit" URL into the address bar. Making the distinction between the first type of 'edit' and the second two means that we could (optionally) have a different response for clicking a red link and clicking an edit link, which is what I think Tim was suggesting.
- Mark Clements (HappyDog)
Mark Clements wrote:
"Lars Aronsson" lars@aronsson.se wrote in
You don't even need to change the URL. It should be enough to detect when the edit form is invoked with an non-existing page.
...and then what? Bear in mind that the software can't currently tell the difference between clicking a red link, vistiting a non-existant page and clicking 'edit' and typing an "?action=edit" URL into the address bar.
Yes, there are many cases, let's limit ourselves to the four you mention:
1. User goes to an existing article and clicks "edit" 2. User goes to a non-existing article and clicks "edit" 3. User enters ?action=edit in the browser's location field 4. User clicks a red link
All four brings up the edit form. In cases 1-3 the user knows this should happen, and isn't surprised by it. The only case that can cause surprise is 4, if the user doesn't know that red links indicate non-existing articles.
The problem we're dealing with here and now is when a user on a blocked network (a school or a library or AOL) clicks a red link (case 4) not knowing that this should bring up an edit form, and thus becomes very surprised at the message that he is blocked. This is the kind of surprise we want to eliminate. It represents one very specialized case in a matrix of possible cases.
One way to deal with this problem is to have a unique part of the red link URL, e.g. &linkcolor=red or &linktype=newarticle, and if this CGI parameter is present and the user or network is blocked, the edit form message should provide an extra explanation of how red links and blocking works. This solves the problem, and this is fine. The cost is that red link URLs need to be changed.
The alternative way that I proposed is to have the edit form recognize the case that the article was non-existing. This of course invades on cases 2 and 3. So my solution might provide an extra explanation about how blocking works in cases 2 & 3, because it doesn't provide any way to distinguish cases 2, 3 from 4. But providing this explanation a little too often is no real loss. The real benefit of my scheme is that it doesn't require any change of URLs.
On 10/14/06, Lars Aronsson lars@aronsson.se wrote:
- User enters ?action=edit in the browser's location field
This is such a bizarre, unlikely event confined to a few rare users who already know how MediaWiki works that I suggest totally discarding it from any future use case analysis. Anyone who manipulates URLs by hand can deal with the consequences.
Steve
"Steve Bennett" stevage@gmail.com wrote in message news:f1c3529e0610150245o47ff8355n2c5b220351d588a7@mail.gmail.com...
On 10/14/06, Lars Aronsson lars@aronsson.se
wrote:
- User enters ?action=edit in the browser's location field
This is such a bizarre, unlikely event confined to a few rare users who already know how MediaWiki works that I suggest totally discarding it from any future use case analysis. Anyone who manipulates URLs by hand can deal with the consequences.
It is not bizarre, and it is not unlikely.
I agree that it may be confined to 'a smallish subset' of users, but if we're talking about changing behaviour it is a very Bad Idea to ignore one of the possible uses - that's how things get broken.
Also this 'smallish subset' of users are also the type of people who create links such as [http://en.wikipedia.org/w/index.php?title=This_Page&action=edit%C2%A7ion... Add a comment] which can be clicked by anyone. I'm not sure if this is the same as typing into the URL, or a new 5th option, but it is something to consider.
- Mark Clements (HappyDog)
On 10/15/06, Mark Clements gmane@kennel17.co.uk wrote:
Also this 'smallish subset' of users are also the type of people who create links such as [http://en.wikipedia.org/w/index.php?title=This_Page&action=edit%C2%A7ion... Add a comment] which can be clicked by anyone. I'm not sure if this is the same as typing into the URL, or a new 5th option, but it is something to consider.
The fact that people have to make these urls manually to get that behaviour is in indicator of a missing feature. It looks like it should be possible with {{NEWSECTION|This Page}} or something.
Steve
On 10/12/06, Platonides Platonides@gmail.com wrote:
Changing page rendering depending if user is blocked or not won't happen. It would break page caching (this appeared before but asking to change 'edit' into 'view source').
Can you be more precise about "breaking page caching"? Purely hypothetically, it would be possible to store two different caches for each page, one for blocked users and one for everyone else, right? Or is this one of those "the amount of work required far outweighs the benefit" situations?
Steve
"Steve Bennett" wrote:
On 10/12/06, Platonides wrote:
Changing page rendering depending if user is blocked or not won't happen. It would break page caching (this appeared before but asking to change 'edit' into 'view source').
Can you be more precise about "breaking page caching"? Purely hypothetically, it would be possible to store two different caches for each page, one for blocked users and one for everyone else, right? Or is this one of those "the amount of work required far outweighs the benefit" situations?
Steve
I'm not a cache expert, i can't give very accurate answers, but i'd say the devs will gladly implement this system for you... as far as you give them the hardware to double our caching ability :-)
Tim Starling: Good point. We could then choose to send them either to 'action edit' or 'action view for 404'. Though a new arrive message might be preferable, in order to avoid "You can create this page" links on noarticletext.
On 10/12/06, Platonides Platonides@gmail.com wrote:
I'm not a cache expert, i can't give very accurate answers, but i'd say the devs will gladly implement this system for you... as far as you give them the hardware to double our caching ability :-)
Heh, "small matter of hardware"? Actually now that I think about it, since presumably these blocked users still make up a very small proportion of total page views (say 1% or less), it could be feasible to offer an uncached version? But I'm really talking well and truly out of my arse here.
Steve
On 10/13/06, Steve Bennett stevage@gmail.com wrote:
Heh, "small matter of hardware"? Actually now that I think about it, since presumably these blocked users still make up a very small proportion of total page views (say 1% or less), it could be feasible to offer an uncached version? But I'm really talking well and truly out of my arse here.
Remember that merely deciding whether the user/ip is blocked and which version to offer is going to be require a DB hit of some sort. This could add up to be quite an overhead?
wikitech-l@lists.wikimedia.org