Topic on Talk:Reading/Readers contributions via Android

Comments on the mockups

5
197.218.88.240 (talkcontribs)

Some comments on the mockups:

  • Image via nearby - Looks good
  • Add/edit lead image to the article - Reasonable, although it might be a good idea to surface images from commons before uploading
  • Moderation queue for image submissions - Addressed in another post, but mockups seem reasonable. Make sure not to surface other user's moderation (e.g. +1 / -1), as this may cause bias and bad moderation, e.g. most experienced editors are negatively biased towards new contributions (despite claiming or believing that they aren't).
  • Lead image editing - Good concept. Looks uncontroversial, and easy to revert.
  • Article Feedback - This is complicated, +1 or -1 votes may be inaccurate because they may refer to a prior revision that changed wildly, may make people vote on the topic and not the article, and may cause issues.
    • Downvoting regardless - People against the theory of evolution may "downvote severely" despite the quality of the topic.
    • People also don't read instructions - This is better done indirectly, for example, if an article has lots of spelling /grammar mistakes, incorrect information or is unintelligible, then the user is basically noting that the rating is low.
    • It is considerably harder to identify a good article.
  • Wikilabels, wikigrok - This seems good.
  • Report an issue
    • The good : Nice implementation of taping the problem directly, and structured problems.
    • The bad : Again, freeform input is a problem, it is better to focus on common issues and add onto them later than allowing free form and dealing with the endless drama and headache with "i hate Puppies" or "No, the true God is ..." kind of comments. Structured comments don't need any moderation, and will not place an extra burden on editors.
197.218.83.152 (talkcontribs)

It might also be a good idea to review how Extension:UIFeedback works, and incorporating it for visible UI issues, maybe a blank page, a red error on the page, a mediawiki fatal error, etc.

Jkatz (WMF) (talkcontribs)

Thanks! point taken re: open fields and good point about voting on previous versions and the other concerns...not sure how we would handle that. We've thought about algorithmically providing article quality scores, but that seems like a massively controversial and potentially harmful approach. We'd have to move verrrry slowly on that one if it is deemed of value.

197.218.90.119 (talkcontribs)

> We've thought about algorithmically providing article quality scores, but that seems like a massively controversial and potentially harmful approach

Indeed, I'd suggest staying away from the word "quality", as it will always be contested. Instead focus on things that can be quantified scientifically. For example, for a good number of languages it is possible to detect with reasonable accuracy the number of spelling mistakes some text has, so you can have a metric of things such as:

  • Spelling accuracy
  • readability - https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests , an educated person may still have a lot of trouble understanding nuclear fission if it uses excessive jargon.
  • References - This is a bit trickier, but clearly, references from academic journals and scientific publications should rate higher than some links to youtube or facebook
  • illustration - a picture is worth a thousand words, and while some concepts are not easy to illustrate, it is incredibly hard to explain some without them.

Of course references are troublesome because people may just dump things that don't contain any cited materials, but good references make the content verifiable.

Such ratings may be very useful to help readers identify inaccurate content, and turn them into editors by making it easy to find and fix it.

Jim.henderson (talkcontribs)

Article Feedback is indeed complex. Questionnaire needs careful design so thousands of readers who are far more interested in a topic than in its presentation will provide information which dozens of editors can easily use.

Adding an image by phone also has complexities. I have done a few by current methods, which stink. A new system should provide ways to alert us logged-in users when we're near an article that lacks a picture, and automatically categorize and geotag the photo we snap in response. Not load it directly into the article, as field work tends to be too rough, but alert it to list watchers (and put it on our watchlist). Also when we deliberately look at an article about a nearby place, give an upload button doing those same things.

Reply to "Comments on the mockups"