Topic on Talk:Article feedback

I just saw this pop up on a web page. It's horrible. "Trustworthy?" If it needs an explanation, that is bad. We already have a talk page for each and every article. I was really scratching my head wondering why anyone would want my opinion anyway. And the "I am highly knowledgeable about this topic" part? Do we really expect people to be honest about this? The most I would support might be a small "Rate this article" option. But really I don't see the value in that either. This system has the potential to be gamed/abused. Please, throw this away and move on. Put efforts into making the talk page more accessible or inviting. But not this. Perhaps in addition to the Discussion tab, at the bottom of each article could be a link like "Do you have any feedback about this article?" linking to the discussion page.

Hi Tim!

Its the 5th of July. If there are no radical changes the community will overrule the supporters of the AFT on the 7th of July. The supporters of the AFT think they do not need consensus and think they can ignore the community. We, the community, should make clear we make the decisions. Jimbo is able to overrule the community, the supporters of the AFT are not able to do so, even if they believe they are. They do not have the authority.

Wasbeer, there is no "Jimbo overruling the community", neither a "group of supporters of the AFT". There is a team of people working to implement functionality described in the strategic plan and based on the strategic priorities defined by the Wikimedia community. We are looking for constructive feedback to help us understand how to make this tool valuable for the community and how to assess its value (there are several good suggestions in this sense in the above threads). If you simply expect the community to "overrule the AFT supporters" I don't see how we could even start a conversation.

Hello DarTar!

Thanks for taking the time to respond to our questions!

A couple of not-so-important things first: I am not a native speaker, so please forgive me if I make mistakes. I did not say there was a "Jimbo overruling the community", I just said he is able to. There are supporters of the AFT (I did not say anything about a group afaik). Please use quotationmarks only for direct quotes. I know one of the teammembers, and I like him.

I do not think the community needs to overrule the AFT supporters at this moment in space and time because the feedback is no longer being ignored, but mentioning the possibility and using the same deadline was certainly an excellent idea because suddenly you and Howief responded to the feedback.

We have are having a conversation now, and maybe it is a good idea to start with topics that we are more likely to agree on.

What is your opinion about moving the AFT outside of div#content? From my point of view this is a very important step, and I think this goal is easier to achieve because we are less likely to disagree about it.

The tool will not be moved outside of div#content. It is simply not going to happen. It is essential that the tool is associated with the contents of the page itself and be visible to the reader.

Counter examples for your arguments:

• Something doesn't needs to be inside of div#content to be "associated with the contents of the page itself" (see e.g. the sidebar of anypage: there are various links which are related to the content of the page itself).
• The page footer (MediaWiki:Lastmodifiedat) is outside of that div and is still visible to the readers.

Only experienced and expert users naturally associate sidebar contents with the contents of the page itself (within div#content). Testing has shown us that anything outside of div#content is effectively ignored by the standard reader - even the tabs are not typically considered to be associated with the content of the page.

Last modified date is metadata that users honestly don't care about. That's a very poor example, actually - the way it is displayed (small grey font on light grey background) tells the user, simply, "do not pay attention to this at all."

OK, then, just replace the AFT with a link to the discussion page. That is where feedback belongs, visible to the community and interactive to the community. this tool is wrongheaded in so meany ways it makes me think there is a major disconnect in the people who created this tool as far as how Wikipedia works.

To be honest I still do not understand why moving the AFT outside of div#content is not an option. Do you have data to back up your claim that people are unable to understand that stuff outside of div#content may be related to the content of the article? Please explain this again.

The positioning of the tool is critical. Moving it to the toolbar or to the talk pages is simply not a viable option as this would dramatically drop the (already small) volume of ratings we get. If we want to study how to make this tool more valuable and unbias the results it produces we need to increase, not reduce, the number of ratings we collect. We know that positioning the tool at the bottom of an article is not optimal either (we saw that conversions decay very rapidly, following a Power Law, with the length of the article, suggesting that people just don't see it unless they scroll to the bottom of the page) but this is currently the best option we could find. Another option that has been considered is an expansible, fixed position tab on the right of the screen, but that would probably make it too prominent.

I don't know if the content of Article_feedback/Extended_review#Wireframes_3 is still to be considered or is already a discarded option (if so, why?), but you may want to try out the approach currently used on English Wiktionary. Look at the sidebar of a random word. There will be a "Feedback" section with some default options and also a link to wikt:Wiktionary:Feedback. (Unfortunatelly, the toolserver account used to collect the data seems to have expired and the tool doesn't seems to be fully functional at the moment)

There is also something similar on Spanish Wikipedia, right below the "Donate" link in the sidebar, wich allows readers to notify editors about specific problems on articles. To test it, open a random article and click on "Notificar un error". See also the talk about implementing it on English Wikipedia on topic "Report an error" feature of Village pump.

Please don't put it there, I want to use the scrollbar. Lots of people will open it by accident.

Timl2k4 the data we've collected so far indicate that when people submit feedback via the AFT survey they don't even realize there is a talk page or if they do, they are often intimidated by how hard it is to participate in a conversation (because of technical and social barriers). I think the idea of experimenting with a "edit the talk page" Call to Action is a good one, but I expect to see a very low number of conversions. The question we should ask is: do we want to have more people participate in the discussion on individual articles and find lightweight ways to persuade them to become editors or just keep the current high bar and lose these potentially good contributions? Both AFT and WikiLove suggest that there are different entry vectors we can experiment with to successfully engage new users with the contents and members of the community.

they don't even realize there is a talk page or if they do, they are often intimidated by how hard it is to participate in a conversation (because of technical and social barriers).

Bingo! This is the problem. Lose the high bar to he discussion page. The entry point to editing articles should start there. Having inexperienced editors editing articles without any prior discussion is no good. I've seen this time and time again, they have good intentions but end up with bad results. Look at this another way, is not the discussion tab the built-in starting point for Article Feedback? Let's make it better! The most common mistake is new users have no clue how to sign comments. This is trivial and should not be a problem. Make it automatic for IP users. Currently, if someone hits edit there is no reminder or pointer to the discussion page. So the Wikipeida discussion system is woefully inadequate, instead of fixing that this tool was created instead. Not good.

Automatic signatures for IPs seems doable by JavaScript, and could probably be requested on Local Village pump. Besides, the problem will be better solved by Extension:LiquidThreads, wich is enabled on this page.

I think the intention is to have more "inexperienced editors editing articles" (e.g. to fix typos, or correct obvious mistakes, and to become regular editors), since this is one of the priorities determined by the community of Wikimedia wikis.

From strategy:Wikimedia Movement Strategic Plan Summary/Increase Participation:

Increasing both the total number of editors, and their diversity, is a key priority for the Wikimedia movement. (...) We need to improve the editing interface in order to reduce barriers to participation. When people try editing for the first time, we need to support and coach them.

and from strategy:May 2011 Update:

Two months ago, the Wikimedia Foundation published the results of our new Editor Trends Study (you can read the results here), which showed that over the past several years it's been getting increasingly difficult for people to edit the Wikimedia projects.

(emphasis mine) So, I think it is unlikely that "prior discussion" will be ever made into a requirement to edit wiki pages. Instead, the chances are that we will have new easy ways to edit pages (e.g. Extension:InlineEditor, which you can test here) and will get more edits from inexperienced editors

True, the ultimate goal is to get more of our users editing article pages. But we also want to get the right types of users and we want to keep them for as long as we can.

It could be the case that discussions offer the best introduction to editing Wikipedia, and users that first edit a discussion page tend to stay longer (e.g., they have a better understanding of the rules, know how to avoid newbie mistakes, etc.). This would argue for making the invitation to discuss more prominent, simplifying the talk page interface, improving the feedback loop to the newbie once she's entered into a discussion, etc. Or it could be the case that completing a very simple edit like a spelling correction offers the best entry into Wikipedia (e.g., newbies are shy, they often feel like they're not qualified to edit, so accomplishment is a good way to build confidence). This would argue for making this type of editing as simple as possible (e.g., in-line editor). Or maybe the most effective way of drawing new editors in is to have them create an account (e.g., it gives them a sense of belonging and therefore more ownership over their contributions). And we need to measure this against the quality of these editors. The last thing the community needs is a bunch of disruptive editors coming in through one of these entry points.

The reality is probably a mix of these reasons, and many more. Also, an "entry vector" that works for one newbie may not work for another. At present, we don't have quantitative data that enables us to compare the effectiveness of these various "entry vectors". But it's something that we'd like to test. For example, we have indication that AFT is probably a good entry vector, given the 17% click-through rate for the edit call-to-action. But we don't yet know whether these individuals actually make good editors (e.g., how constructive are their edits? How long do they edit for?).

This post was posted by Howief (WMF), but signed as Howief.

I agree with Howief and Helder. And I think resources should be focused on developing more user friendly tools like LiquidThreads (and perhaps also the InlineEditor) and invite readers to the talk pages instead of the Article Feedback Tool.

I want to interact with other users who actually work and reason, not readers who just may want to express an opinion. I don't understand why the developers choose to prioritize the latter before the former. The underlying problems need to be fixed, not just the symptoms.

I think that's a good way of looking at things. We want features that help us get the "right" kind of editor in the funnel, not just any editor. That's why I'm a little skeptical about the results of experiments like the section edit icon -- this project increased the number of edits by a significant amount, but it may be because the section edit link is nice and shiny and therefore attracted people who really shouldn't have been editors in the first place. We haven't done the follow-up analysis for this project, but my guess is that the cohort of users that come in through the section edit link icon are probably of lower "quality" -- their edits are probably reverted at a higher rate and they probably don't stick around for quite as long. This is the type of analysis that we need to do with AFT. The click-through rates give us some good indication that users respond to an invitation to edit, but the real question is whether these editors will end up becoming constructive Wikipedians.

The invitation to discussion is something we really need to dig into. I agree that we should focus on developing more user friendly tools for discussion (like LQT). One of the underlying problems is that there are disconnects at many levels between readers and the idea of discussion on Wikipedia. Some don't even know discussions take place. Some think they take place but aren't sure where to find them. And those that can't find them are confounded by the interface since it doesn't look like any discussion page they've seen before. Brandon's done a lot of thinking around the next generation of LQT. But this is a much longer-term project -- to get this right will take a significant amount of time to design, develop, iterate, etc.

This post was posted by Howief (WMF), but signed as Howief.

I think that both the section edit icon and the InlineEditor will encourage readers to become editors. And they do it in a more direct and honest way than the manipulative method AFT employs. Both SEI and IE put the newbies exactly where I prefer them: In the thick of it. But we need better tools to guide them once that first step is taken:

• Positive feedback as soon as possible
• Instant help when needed

In my mind, reducing churn should happen before heavy recruiting starts. Making sure that first edit is a pleasant experience is paramount.

Yes, agreed on positive feedback and instant help. The positive feedback needs to be given to the new editor in a manner in which they understand. We can't assume new editors understand the purpose of their user talk page, nor can we assume they even know that such a page exists. I'm also not sure how likely it is that these new editors either notice or act on the yellow notice across their screen. Email notification might be a better way to make them aware of the feedback, but not everyone provides an email address upon registering.

Instant help would be awesome.

This post was posted by Howief (WMF), but signed as Howief.

• Positive feedback: Perhaps a tool that shows edit diffs by users who does not yet have an edit on their talk page. Experienced users monitoring that page should then be able to "one-click-welcome" users making useful edits from a selection of welcome templates; "Thank you for copyediting!", "Thank you for adding information!" and so on. I'm thinking along the lines of the (now defunct?) Interwiki-Link-Checker (http://toolserver.org/~flacus/IWLC/start.php) where bilingual wikipedians could compare two wikipages and answer yes or no (or maybe) to the question "create iw links between pages?"
• Instant help: Perhaps a chat on the tool-server where experienced users offer help in a one-on-one chat with newbies.

There is the Extension:WebChat which is currently used on Translatewiki.net (example).

"we will have new easy ways to edit pages (e.g. Extension:InlineEditor, which you can test here) and will get more edits from inexperienced editors"

Well that is slick! Glad to see that in the works. As far as the discussion page, a little entry form for article feedback perhaps? Also make the discussion option more prominent somehow.

See also Visual editor and progress on editor (on Wikitext mailing list)

As for the "a little entry form for article feedback perhaps", do you mean something like the free-text field mentioned on extended review page?

Yes, I think so. I have a feeling it would end up with all sort of spam, useless comments. There would need to be an easy way to filter them. Having a captchca would probably dissuade 90% of the population from leaving a comment, I mean the useful ones too, although if someone has a useful comment, they may be more motivated to work through the captchca.

After leaving their feedback they could be presented with what would I hope eventually be hopefully improved ways of article discussion and editing than what currently exists.

I'm going off a bit of a tangent here, but if someone has a fact to add to the article, walking them through the process of adding a proper citation (and helping them find one if they don't and making the edit process very user friendly would help turn readers into constructive editors. If they simply have a correction, hopefully this will become more user-friendly, I mean user-friendly like my grandmother could make a correction without messing up the page. The examples I've seen in this discussion (excluding the AFT) are encouraging.