As requested, here's the weekly Flagged Protection update.
We continue to work on UI display issues and on getting up a Labs version of the German Wikipedia. We're pretty close to release, and we believe only minor UI issues remain.
If you'd like to verify that for yourself, start here:
http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page
To see the in-progress and upcoming work, it's listed in our tracker, under Current and Backlog:
http://www.pivotaltracker.com/projects/46157
We expect to release to labs again next week, and each week thereafter until this goes live on the English Wikipedia.
William
On Thu, Apr 29, 2010 at 5:24 PM, William Pietri william@scissor.com wrote:
As requested, here's the weekly Flagged Protection update.
We continue to work on UI display issues and on getting up a Labs version of the German Wikipedia. We're pretty close to release, and we believe only minor UI issues remain.
If you'd like to verify that for yourself, start here:
Greetings.
Can you point me to where it was decided to admonish new editors with statements like "Changes will be published once an authorized user reviews them." (in all red) after they make an edit.
I don't see what purpose this message can serve except to discourage editing.
If instead the site simply completed the edit like normal and set a session cookie that causes that client to view the most current rather than the "published" version of that article, then the editing experience for a new editor would remain identical to the experience that they have now: They make an edit, they see their edit on the site, they can browse away and come back without it immediately disappearing, and they can return days later and find their edit still there or not depending on the other users of the site being willing to accept it.
On 04/29/2010 03:35 PM, Gregory Maxwell wrote:
Can you point me to where it was decided to admonish new editors with statements like "Changes will be published once an authorized user reviews them." (in all red) after they make an edit.
I don't see what purpose this message can serve except to discourage editing.
If instead the site simply completed the edit like normal and set a session cookie that causes that client to view the most current rather than the "published" version of that article, then the editing experience for a new editor would remain identical to the experience that they have now: They make an edit, they see their edit on the site, they can browse away and come back without it immediately disappearing, and they can return days later and find their edit still there or not depending on the other users of the site being willing to accept it.
Hi! Good question.
My understanding, possibly incorrect, is that we can't do that. Because most pages for non-logged-in users are served from caches, most requests don't make it to the point where we can easily show different versions of a page based on cookie.
So the notice shows up because we didn't want people to have the even worse user experience of seeing their change disappear for no apparent reason, when really it was just waiting to be approved.
I'll double-check this with the rest of the team to make sure I got that right, but that's my understanding. Naturally, if anybody has suggestions to improve the wording of the message, or anything else that improves the user experience, we'd love to hear them. The optimum place to put them is here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:FlaggedRevs_issues
William
On Fri, Apr 30, 2010 at 2:24 PM, William Pietri william@scissor.com wrote:
My understanding, possibly incorrect, is that we can't do that. Because most pages for non-logged-in users are served from caches, most requests don't make it to the point where we can easily show different versions of a page based on cookie.
In general, Squid does not served cached pages at all to users with cookies. If it sees a cookie in the request, it just forwards it to the application servers. Viewers with cookies might be logged in, and Squid can't tell if a cookie represents a valid login -- it has to give it to MediaWiki, which can check in memcached and so on.
Some details of the above might be incorrect, but the general point remains -- you can set a cookie for an unregistered user and it will work as you'd like, causing the user to skip the Squid cache on all pages until the cookie expires.
On Fri, Apr 30, 2010 at 3:03 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Fri, Apr 30, 2010 at 2:24 PM, William Pietri william@scissor.com wrote:
My understanding, possibly incorrect, is that we can't do that. Because most pages for non-logged-in users are served from caches, most requests don't make it to the point where we can easily show different versions of a page based on cookie.
In general, Squid does not served cached pages at all to users with cookies. If it sees a cookie in the request, it just forwards it to the application servers. Viewers with cookies might be logged in, and Squid can't tell if a cookie represents a valid login -- it has to give it to MediaWiki, which can check in memcached and so on.
Some details of the above might be incorrect, but the general point remains -- you can set a cookie for an unregistered user and it will work as you'd like, causing the user to skip the Squid cache on all pages until the cookie expires.
This already happens when users edit. Otherwise anons would never be able to get the new messages indicator.
On Fri, Apr 30, 2010 at 4:34 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
This already happens when users edit. Otherwise anons would never be able to get the new messages indicator.
I stand corrected.
On 04/30/2010 01:34 PM, Gregory Maxwell wrote:
but the general point
remains -- you can set a cookie for an unregistered user and it will work as you'd like, causing the user to skip the Squid cache on all pages until the cookie expires.
This already happens when users edit. Otherwise anons would never be able to get the new messages indicator.
That's good to know. I'll pass this on to the team and we'll see what we can come up with. One question for any interested stakeholder: is this feature worth delaying launch to add? We have a number of nice-to-haves on a list to work on right after launch, so development will continue.
Also, Howie Fung, the UI expert on the project comments:
We can always soften the message a bit by changing the language, color and/or providing a link with an explanation.
So if people have suggestions on how to improve any of that, on any other aspect of the current implementation, please put them here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:FlaggedRevs_issues
William
On Fri, Apr 30, 2010 at 10:51 PM, William Pietri william@scissor.com wrote:
On 04/30/2010 01:34 PM, Gregory Maxwell wrote:
but the general point
remains -- you can set a cookie for an unregistered user and it will work as you'd like, causing the user to skip the Squid cache on all pages until the cookie expires.
This already happens when users edit. Otherwise anons would never be able to get the new messages indicator.
That's good to know. I'll pass this on to the team and we'll see what we can come up with. One question for any interested stakeholder: is this feature worth delaying launch to add? We have a number of nice-to-haves on a list to work on right after launch, so development will continue.
Also, Howie Fung, the UI expert on the project comments:
We can always soften the message a bit by changing the language, color and/or providing a link with an explanation.
So if people have suggestions on how to improve any of that, on any other aspect of the current implementation, please put them here:
http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:FlaggedRevs_issues
You could dangle a carrot and say "if your edit gets approved, you get a prize!"
That would certainly raise a few eyebrows.
But seriously, the issue of encouraging people to edit is crucial. Those who want to edit for malicious reasons will nearly always be prepared to jump through hoops, and those most likely to be discouraged by extra hoops to jump through will include those we want to attract to become new and regular editors.
All in all, if what Greg describes can be done, that sounds best, even if it seems a bit misleading.
Carcharoth
On 04/30/2010 04:11 PM, Carcharoth wrote:
But seriously, the issue of encouraging people to edit is crucial. Those who want to edit for malicious reasons will nearly always be prepared to jump through hoops, and those most likely to be discouraged by extra hoops to jump through will include those we want to attract to become new and regular editors.
All in all, if what Greg describes can be done, that sounds best, even if it seems a bit misleading.
Okey doke. I have passed the request on to the team to see what they think of the idea and how much time it will take to implement. More news as it comes in.
Thanks to all for the discussion!
William
William Pietri wrote:
As requested, here's the weekly Flagged Protection update.
We continue to work on UI display issues and on getting up a Labs version of the German Wikipedia. We're pretty close to release, and we believe only minor UI issues remain.
Between this update and the last one, the only commits made to the FlaggedRevs extension were localisation updates imported from translatewiki.net. But your language here implies that something actually happened this week. Could you perhaps be more specific as to what sort of work was done?
-- Tim Starling
On 04/29/2010 06:32 PM, Tim Starling wrote:
William Pietri wrote:
As requested, here's the weekly Flagged Protection update.
We continue to work on UI display issues and on getting up a Labs version of the German Wikipedia. We're pretty close to release, and we believe only minor UI issues remain.
Between this update and the last one, the only commits made to the FlaggedRevs extension were localisation updates imported from translatewiki.net. But your language here implies that something actually happened this week. Could you perhaps be more specific as to what sort of work was done?
Sure. The resolution to the apparent paradox is that not all useful work immediately results in commits. In particular, the major UI issue being worked on can be seen on this page:
http://flaggedrevs.labs.wikimedia.org/wiki/Hurricane_Vince_%282005%29
In the upper right, you'll note a lock icon with (+) next to it. The UI mavens involved, Howie and Parul, feel that the current version isn't consistent with the direction the usability team has for the interface, so they're trying to come up with something that looks and works better. However, getting something that satisfies them and also looks and works properly in all browsers has been a challenge. I understand the Usability Initiative developers have offered technical assistance with that.
This is pretty typical pre-release fit-and-finish stuff. I know it can be frustrating for project stakeholders, as it appears like not much is happening, but given the scale at which Wikipedia works and the importance of this project being well received, I think we're better off taking a bit longer for a solid user experience, especially the bit that appears on article pages.
I know some additional work was done on cleaning up names, labels, and text in the interface; if you're curious about exactly what went on, I can ask. My understanding is that is almost done, though.
William