On 10/11/06, George Herbert <george.herbert(a)gmail.com> wrote: 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.

Platonides 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. -- Tim Starling

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(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Mark Clements wrote: 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. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

"Steve Bennett" <stevage(a)gmail.com> wrote in message news:f1c3529e0610150245o47ff8355n2c5b220351d588a7@mail.gmail.com... wrote: 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&sec… 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/12/06, Platonides <Platonides(a)gmail.com> wrote: 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

On 10/12/06, Platonides <Platonides(a)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. Steve