Talk:Reading/Readers contributions via Android/Outcome

Ideas to go further:

• https://en.wikipedia.org/wiki/ESP_game to gamify image tagging
• special:deadendpages - ask readers to link these page
• Special:LonelyPages - ask readers to provide links to these pages
• Special:Withoutimages - this is something that isn't even currently possible on wikimedia as the page doesn't exist. It would also be very expensive on huge wikis, so might not work at all
• Add categories to pages

This investigation was quite interesting and reasonably carried out. But as usual these kinds of things tend to exclude non-English speakers, as evidenced by the fact that there isn't a single non-english suggestion in the list. They might even have interesting ideas that don't occur to larger wikis due to their heavy use of bots. Although it is understandable that this wasn't designed to be as extensive as the community wishlist.

Perhaps before future research in both well liked and "disliked" ideas, Extension:Quicksurveys could be create a translated survey. It might even be improved to take freeform ideas for such projects, allowing staff to later translate, remove all spammy stuff, and provide a page for discussions of such ideas.

Contributors to this informal discussion from bigger wikis might be blind to the needs of smaller wikis due to the heavy amount of vandalism and issues experienced on that scale. What may work terribly on a big wiki might in fact be perfect in a smaller wikipedia, and might later even be adapted to cater for larger wikis. A good example is Extension:ContentTranslation which larger wikis probably don't care for due to the potential for vandalism, and the amount of errors added by non-native speakers.

A smaller wiki may welcome such tools even with all their flaws due to the fact that they can gradually improve such articles.

I'm involved on others wikis than English Wikipedia and I kind of disagree with you. :) Work on disambiguation and add relevant images can be used on any Wikipedia, work on micro contributions on Wikidata if useful for all Wikipedias (and Wikidata), tag images is a Commons thing...

IF you have any suggestion for smaller wikis, they are still very welcome! :)

You misunderstood, the ideas are fine, but they represent a small number of english speakers (both native and non-native) from big wikis. Smaller wikis have bigger problems such as actually attracting contributors, while someone mentioned that they were worried about "hat collectors", for a smaller wiki hat collectors may even be welcome as they may be turned into full time editors who make useful contributors.

As for as an idea, I'd say Wikimedia needs to either consult gamification experts or outright hire one. There are so many tasks that are easy to gamify, yet are currently slow and cumbersome due to the normal editing mode. For example, the easiest tasks involve either identifying objects to make it easier for people adding it to articles, or actually identifying all images that actually relate directly to an article. For example, the current wikidata image idea relies mainly on finding one image to represent a wikidata item, it could conceivably be a fun task to identify as many images that fit any wikidata item. This is a very tedious task for experienced editors, but casual readers could maybe be prompted to do this while reading an article.

You've had luis von ahn a gamification expert in Wikimania, he created a game, which would be perfect for wikimedia (if it were adapted):

• https://en.wikipedia.org/wiki/ESP_game
• labeling-images.pdf

Even without the Commons structured data, this is entirely possible using wikidata. In fact, this data will likely always remain on wikidata. Commons will probably only contain metatada directly related to the image itself, and fetch the rest from wikidata.

For smaller images such tagging would provide them with more choices for actual images to use in an article.

You should also have a look at rs.wikia.com/wiki/Special:community . It is a similar concept to the wikihow page, except that it is completely automatic, and some of those wouldn't work well at all on big wikis.

For example, it is completely possible to have some reports on smaller wikis like:

• special:deadendpages - ask readers to link these page
• Special:LonelyPages - ask readers to provide links to these pages
• Special:Withoutimages - this is something that isn't even currently possible on wikimedia as the page doesn't exist. It would also be very expensive on huge wikis, so might not work at all

See, there are differences to the needs of big wikis vs small. Some big wikis might not even want any image on certain pages, while smaller wikis would probably welcome it.

The simplest would probably be to add a tool for mobile readers to add categories to page. This is quite trivial to do, and the main reason it isn't done is probably due to the fact that a) Big wikis would likely be strongly against it, b) there is an expectation of vandalism.

This would again be easy to solve by having a sort of counter from randomly selected readers before the edits go live, although it is conceivable that smaller wikis wouldn't have that problem anyway.

Thank you for your replies. I've summarized the discussion with your ideas. We will consider these ideas for the next steps.

Luis von Ahn talk at Wikimania London was really inspirational to me. It is indeed a good idea to have someone with a gamification background to provide ideas. I'll discuss about it with the team.

The idea of having a community board with things to do has been proposed as a project for the Collaboration team for the coming fiscal year (July 2017 - June 2018).

Concerning changes that may be subject to posible vandalism (even though I believe in good faith), we can imagine to have a double-checked entry. User A is asked to add a category to a page. Then, user B (another "player") is asked to confirm if it is correct. If so, the edit is done a A's edit. When A (or B) have donne enough quality edits, they don't have to go through that confirmation process anymore.

> User A is asked to add a category to a page. Then, user B (another "player") is asked to confirm if it is correct. If so, the edit is done a A's edit. When A (or B) have donne enough quality edits, they don't have to go through that confirmation process anymore.

Exactly the point. This is a mechanism that should be explored for mobile micro-edits in general (a la Extension:FlaggedRevisions) maybe as a "FlaggedMicroRevisions".

Ideas:

• Add images via wikidata or simple commons search
• Work on choosing the most qualitative images

This is probably the most feasible and easiest option and to implement for the simple case. It will likely have the most impact at the lowest cost.

Some concerns though:

• Infoboxes - It is nigh impossible to determine how to add an image to an infobox consistently using template parameters
• Cultural differences - some images are perfectly fine in one culture but may be offensive or inappropriate in another. This may lead to "editphoto wars".
• Rating - frankly commons has too many images, so using rating or pageviews to surface possible candidates makes sense.
• Duplicate work - the page image could primarily be stored in wikidata to reduce duplicate work in other wikis
• Wiki preferences - It might require adding more properties on wikidata to ensure that each wiki can choose its preferred image there. This may reduce arguments over which image is best for which wiki.

For infoboxes or templates that add images, the ideal option might be to add a new property to templatedata, maybe something like parameter type:

params": {</nowiki>

        "user": {

            "label": "This is the main image. It is shown in search results, and represents the page",

            "type": "main-page-image",

If no infobox exists in the article, it can just fallback to adding the default markup, e.g.: "<nowiki>[[file:page-image.png|thumb]]</nowiki>". Yet another alternative might be to use the image from wikidata whenever this parameter doesn't have any value. This might be highly controversial, and this wikidata functionality could be opt-in for wikis that want it.

The simplest MVP implementation is probably to avoid infoboxes altogether, and just add the "standard" file:image markup to the article only when there is no "infobox class".

Fixed templatedata markup:

params": {
        "pageimage": {
            "label": "This is the main image. It is shown in search results, and represents the page",
            "type": "main-page-image",
}

Thank you for your feedback!

I see two different things in it: add images to illustrate a wiki and take the quality of an image into consideration.

Choose an image to be the universal representation of a person or a topic can be controversial, as you mentioned it. There is already a way to take an image and put it on Wikidata as the default image. This image will be taken into consideration in search or on wikis that use Wikidata data on templates, mainly infoboxes. It is still possible to override the default image by using another one locally.

Some wikis doesn't have infoboxes that use Wikidata, but there is an idea to have a central repository for templates. Also, have a way to indicate default value of a Wikidata element into TemplateData is also a (slow) work in progress.

If there is no infobox, well, that's indeed easier and it can be considered. :)

Concerning quality image, I think it would be a very good idea. However, I would advise to wait for the first steps of Structured data on Commons to avoid adding a new system that would have to be re-integrated to wikibase later.

All of this is context. We will of course consider your ideas, but based on it.

> Some wikis doesn't have infoboxes that use Wikidata, but there is an idea to have a central repository for templates.

Yes, the problem is when the infobox doesn't use wikidata for its image. In those it is probably better to avoid adding an image. The central repository might not use wikidata either, and even if it does, convincing wikis to use it is a huge task.

Maybe the long term solution for this would come from Multi-Content Revisions. It could have a special slot for article image for articles that don't use any infoboxes along with either templatedata property or the regular wikidata parser function for all other cases.

Avoiding is probably the best in that case, unless if there is some help to deploy more Wikidata on infoboxes (which is indeed difficult, to convince people).

Concerning Multi-Content Revisions, that's a possible future: have all meta-informations out of the articles (infoboxes, portals, categories...). The question is now, should we create some features that may be obsolete in a few years because of a feature?

> The question is now, should we create some features that may be obsolete in a few years because of a feature?

100% yes.

If it were a complex feature then it would depend on the cost of developing it. This feature is technically easy to develop. In fact it can even be done without any special app, just by using javascript and the api. This would be trivial to change to work with whatever new api for MCR comes around eventually.

Waiting for MCR doesn't seem like a good idea, structured data is a very long term project.

Abstract:

• give more tools for users to edit mobile views for Main page or wikiprojets
• edit Wikidata descriptions en masse

One feature that Wikia has developed is the Mobile Main Page. It allows admins to change the default mobile view of the main page by changing the featured pages and content.

Advantages

• Design pages for the task - a mobile page for mobile users and a desktop page for desktop like tools
• No wikitext - The mobile main page can be completed edited without any knowledge of wikitext
• Mobile compatible
• Mobile editable - it can be completely edited using mobile devices without wikitext markup
• Pages automatically populated pages from categories
• Cropping tool

Disadvantages

• Some loss of control - apart from user selected pages the tool essentially shows other content based on how trendy they are
• No custom interface - mobile sites don't allow any css or js changes

The tool shows how some of the ideas here could be implemented without relying on too much markup or complicated interfaces. It even allows selecting a page image and description for each featured item.

Demo: http://khanacademy.wikia.com/wiki/Khan_Academy_Wiki?useskin=wikiamobile

Thank you for this suggestion. I'm however afraid it is not in the scope of the current outcome.

Plus, I'm not sure to understand the final goal of this Mobile Main page you are suggestions. Can you clarify? Every Home page for Wikipedia shows the article of the day, and various other resources that a quite common across the languages. I think the reasonable idea would be to unify more all Wikipedia Mobile Main pages. What do you think?

The suggestion is not to use the mobile main page as wikia as done it, but merely to evaluate what concepts could be reused from it.

Some ideas :

• Change description and page image - wikimedia has deployed article descriptions in the mobile apps, yet there is no way to change the page image at the same time.
• Change multiple page images - instead of one by one for related pages.
• Changing related page descriptions - if someone is reading an article about the Thomas edison they may be interested in Nikolas tesla, and improve both descriptions or images.

That wikia tool allows changing or adding both at the same time although it relates to only the main page, the idea would be extending the concept of editing multiple page properties (e.g. description, image, etc) at the same time.

> I think the reasonable idea would be to unify more all Wikipedia Mobile Main pages. What do you think?

That would be hard. The main page tends to be the most viewed page in a site, any changes to it would be very controversial.

> Change description and page image - wikimedia has deployed article descriptions in the mobile apps, yet there is no way to change the page image at the same time.

This is a work in progress : Wikidata centralize the main picture and the description of any Wikipedia article, and there is a beta feature in the Android app in some language to edit the descriptions (images are a more complicated issue, mostly due to copyright).

> Change multiple page images - instead of one by one for related pages.

You mean a way to edit the description for one image that will have impact on all pages where this image is used?

> Changing related page descriptions - if someone is reading an article about the Thomas edison they may be interested in Nikolas tesla, and improve both descriptions or images.

I don't get this one.

> That would be hard. The main page tends to be the most viewed page in a site, any changes to it would be very controversial.

I'm not sure. All pages have the same way to work: article of the day, events, image of the day... At the moment, the Main page on mobile is using these resources to display contents. Improve this, to give the best information, is not controversial. It can be controversial if a community wants to have titles in green and don't have a way to do so. :)

>  Changing related page descriptions - if someone is reading an article about the Thomas edison they may be interested in Nikolas tesla, and improve both descriptions or images.

>> don't get this one

In that tool you can edit multiple items (both images and text) at the same time. The current wikidata descriptions, apply to a single page. For example:

"Thomas edison" - Description: Famous Inventor of the light bulb ; Image : Thomas.png

"Nikolas tesla" - Description: Famous Inventor of the tesla and wireless telegraphy ; Tesla.png

Currrently changing those those two would require going to two separate pages, either on wikidata or wiki. So it essentially decides all the items that will be displayed without leaving one page.

> Change multiple page images - instead of one by one for related pages.

>> You mean a way to edit the description for one image that will have impact on all pages where this image is used?

That's more like a job for structured multimedia data, but that could indeed be one way to implement it, with appropriate local changes as needed.

>  At the moment, the Main page on mobile is using these resources to display contents. 

Probably only the bigger wikis use this, and it is also unstructured at the moment and using a mix of templates and wikitext to make it work.

To write a description, you need some context. If you just have a title and an image, it will be difficult, no? I think that's why image description or just descriptions are not included in the WIkidata Games.

> Probably only the bigger wikis use this, and it is also unstructured at the moment and using a mix of templates and wikitext to make it work.

Correct, but most wikis I have visited have been inspired by a bigger ones, and use templates that are quite similar. Anyway, have a way or another to edit the home page on a mobile will need some community questioning, which is not a priority as far as I know.

>To write a description, you need some context. If you just have a title and an image, it will be difficult, no? I think that's why image description or just descriptions are not included in the WIkidata Games.

It depends on the topic, most kindergarden kids can already name and describe hundreds of objects and animals without reading the whole article about it. Adults know more although offering a preview of the article like with hovercards will eliminate that problem. I think that the android app already offers a hovercard like tool anyway.

So it will still be a useful tool it can be used to help finish up the description of articles and confirm any images related to the topic.

The work they put into add description probably made it easier to add images simultaneously.