Mobile design/Micro contributions

This document describes ideas for potential small contributions for mobile site users.

Rationale

Editing Wikipedia is a difficult activity, even more so on mobile. There are a variety of small maintenance tasks that benefit the encyclopedia and are fun and easy to do, but that are not surfaced or presented well enough for new users to discover and use. Isolating some of these tasks and wrapping them in a user-friendly UI could be a way for new or casual users who are looking to do small, self-contained chunks of work to add significant value to the encyclopedia without having to input text or learn wiki markup.

Micro contributions may be a hook to entice users to create an account, or a benefit that they get post-signup. More research is required to determine if they are more suitable as part of a page-centric workflow (e.g., they appear naturally as part of a casual reader's exploration of content), a queue-centric one (e.g., there is an explicit call to action presented to users to go to a separate work queue or download an app designed specifically for limited micro contribution activity), or a hybrid of the two (e.g., the user tries and successfully completes one micro contribution, after which he/she receives a call to action to visit a separate queue/download an app for more tasks).

User research

Maintenance tasks are very popular among experienced editors on the desktop site—many of whom use community-built tools like the Dab solver or HotCat to effectively build their own work queues of micro contribution.

• In the month of October 2012, there were 16,256 revisions using the Dab solver tool on English Wikipedia, with 627 unique editors using the tool. To compare this to another popular semi-automated tool among experienced editors: there were 14,446 Huggle warnings issued in September 2012, with a total of 114 unique editors using the tool. The high editor-to-revision ratio suggests that a small number of experienced users are hooked on this tool and return to it often to perform batch disambiguation actions.
• The Wikidata Game

Design requirements

• Create micro contribution features that don't require text input
• Use elements of incentive-centered design to encourage good contribution
• Leverage existing work queues on Wikipedia where possible

Currently in development

WikiGrok

See also: Extension:MobileFrontend/WikiGrok

Surfacing calls to action to add Wikidata statements to items based on their Wikipedia article.

Version 1

• 
  WikiGrok v1, first screen
• 
  WikiGrok v1, thank you screen
• 
  WikiGrok v1, 2nd question

• Based on the Wikidata occupation game.
• On Wikipedia articles that have a matching "instance of human" item in Wikidata, users who scroll to the bottom of the lead see a call to action to confirm the occupation of the person.
• Currently in development on the mobile alpha site.

Version 1.5

• 
  WikiGrok v1.5 first screen intro question
• 
  1st question
• 
  Confirmation screen
• 
  2nd question
• 
  More info/about Wikidata screen

• An iteration on the above based on initial user feedback:
  • first question is a warm-up to gauge interest (asks if the user wants to help Wikipedia)
  • includes secondary screen that explains what Wikidata is/why this activity is useful.

Other ideas

Categorizing

• add/remove/manage categories on articles (see HotCat)

Page-centered flow

1. User comes to an article via Google search
2. User sees section with categories that the article is a part of
3. User sees link to add/remove categories

Queue-centered flow

1. User comes to an article via Google search (mobile frontend) or accesses Wikipedia directly (mobile application)
2. User gets a call to action to visit a separate work queue (Category:Uncategorized pages)
3. User sees list of articles that need categories and can add them

Disambiguation

• fix links to disambiguation pages by selecting the appropriate article from a list of suggested ones (see screenshots of the Dab solver tool on desktop below)

Page-centered flow

1. User comes to an article via Google search
2. User sees a link that is styled differently from other internal links
3. User taps and gets a popup asking him/her where this link should go. E.g. "... and the main character experiences a flashback." ← Should this link go to: Flashback (narrative) or Flashback (psychology)?
4. User can dismiss the notice or choose to accept the task

Queue-centered flow

1. User comes to an article via Google search (mobile frontend) or accesses Wikipedia directly (mobile application)
2. User sees call to action to visit a separate work queue (Category:Articles with links needing disambiguation)
3. User sees list of articles with links that need disambiguating and can do as many as he/she wants

Current workflow on desktop

• 
  1. User receives talk page message from a bot.
• 
  2. User goes to Dablinks tool on Toolserver, where they can see the undisambiguated link(s) highlighted in red.
• 
  3. User can click the link(s) and open up a drop-down menu with different options

Wikifying

• tap words to add/remove an internal link

Page-centered flow

1. User comes to an article via Google search
2. User sees a suggested internal link under a word that should probably be wikified
3. User taps the word, which creates a link
4. User can untap a word to remove a link

Queue-centered flow

1. User comes to an article via Google search (mobile frontend) or accesses Wikipedia directly (mobile application)
2. User sees call to action to visit a separate work queue (drawn from Category:Articles that need to be wikified)
3. User can select an article and add/remove internal links where appropriate

Quality rating

Revision-level

• (from the watchlist) +1 good edits
• (from the watchlist) downvote/flag bad edits

Article-level feedback

• +1 an article
• Thank the Author/Editors

Image curation

As part of the Photo uploads project, there are potential avenues for adding curation micro-contributions like:

• add categories to your image/ add categories to all images
• add geo-coordinates to your image/ add geo-coordinates to all images

Tagging people in photos based on wikidata information

Recent changes patrol

• revert or give revision level feedback on new changes

New Pages Feed

• review & tag new articles for cleanup
• add categories to newly created articles

Quality crowdsourcing

Quality control

• Images
  • up/down vote if a specific image belongs in an article
  • up/down vote image on quality
  • up/down vote images on appropriateness/relevance for a category
  • rank images within an article to choose lead image

Article Workflows

• vote on whether an article should be deleted
• highlight sections of article as needing references (mobile)
• highlight section of article to quick add reference from ISBN or URL (mobile)

Location-based edits

• Attaching GPS coordinates to an article or image
  • This could be ideal from mobile
• Aggregate photos from Commons that were taken near a geo-located article and display as as a gallery
• Prompt users to upload image when geographically near an article missing an image
• Prompt user to associate an image with their current location if the article does not have a location when mobile.
• Match articles to Open Street Maps, Facebook, Foursquare locations
  

Category ontology

• given two categories choose weather they have a parent child relationship or not
• given a multi-word category decide if each separate word matches existent categories
  • “United States Finance” → “United States” & “Finance”
• Merging categories thats should be merged “United States” → “United States of America”
• Sorting categories on an article by importance
• Choosing primary category for an article

Style and Grammar fixes

• LanguageTool WikiCheck finds potential style and grammar problems
• A page-centered workflow is also possible, but I'd suggest to use a queue-centered workflow, where the potential errors from the 'recent changes' check are shown. The false alarm rate is better for those recent changes than for existing pages, that are often quite good already.
• Things to note:
  • A standard spell check is possible, but it's not activated currently - the tool currently only cares about errors that a standard spell checker doesn't detect.
  • The number of false alarms heavily depends on the type of error. All rules in LanguageTool can separately be enabled or disabled, so this can be optimized in either direction.
  • Not all errors found offer a suggestion yet, i.e. some need some typing. One might want to hide those.