Design/Explore

The design team collaborates in several projects with other Wikimedia Foundation teams. In addition to this, the design team also devotes time researching new project that could shape the future of the Foundation and its projects. The goal is to discuss new unexplored ideas, we are looking for:
 * Your feedback. Leave your feedback in the talk page. Take into account that explorations will be rough around the edges. So try to be specific in your comments and try to identify which aspect are you referring to (e.g., the idea, the interaction pattern chosen, the visual execution...).
 * Your help. Are you looking for a project to work for a hackathon or as a pet project? Feel free to take these ideas and implement them as a beta feature.

Mobile citations

 * Problem. Many users wonder whether Wikipedia content is reliable. Wikipedia has a collaborative reliability checking system where you can add or request references that support a given claim. However, this system is not evident for readers or new contributors.
 * Solution. By making the citation system simpler but more prominent, we can increase reliability (both real and perceived) and provide an additional micro-contribution to our users. The designs show the basic workflows:
 * Verify references. Check how many references are supporting a claim and navigate to them.
 * Request references. Indicate that some claim seems unreliable and requires a citation to support it.
 * Add references. Provide a reference to support a claim.
 * Considerations. Some additional aspects to take into account:
 * "Citation needed" is one of the core and very unique concepts of Wikipedia, we need to take care on how to present it. More thinking is needed on this.
 * In addition, "Citation needed" is a concept we can use on other social interactions. For example, in flow conversations, it could be possible to request a reference for other user's comment with "citation needed".
 * On mobile, tasks such as copying and pasting an URL are not trivial. Some aids have been considered, but more ideas are welcome.
 * The bottom panel where the UI is shown is just a possible execution (based on the current panel shown for references on mobile). If a contextual personal bar is used, it may make sense to integrate the actions there.

"Other uses" on mobile
Words have different meanings. When you land to the article about the Orange fruit, Wikipedia provides you with a quick way to other possible meanings (the orange colour, or "Les oranges" painting) just in case the fruit is not what you were looking for. On mobile, adding such notices pushes the content below.

This exploration tries to integrate the notification of alternatives into existing areas of the mobile UI so that no additional clutter is introduced.



Chrome-less exploration


Users are interested in content but chrome is too prominent in our current reading experience. In addition, users enjoy exploring the network of connected knowledge that a wiki page provides. This design exploration tries to :
 * Focus on content. The article is the most prominent element. At a second level of prominence (still visible initially), elements that directly related to the article's topic are presented (e.g., infoboxes, images, versions in other languages, info on sister projects...). Finally as a side note, some actions provide access to different kinds of "distant connections" (e.g., search other topics, access the list of favourite topics, or article tools). When a tool is selected, the associated panel appears to provide more information.
 * Provide a more rich exploration experience. Search is presented as "search and explore". Before any search is done, the user gets a visual overview of the different pieces of information linked with the article.

A prototype is available.

Editor-driven micro-contributions for readers


This exploration tries to provide individual editors with the capability to ask the community of readers for help with control for the signal-to-noise ratio. Editors can request different kinds of help (the list can be extended):
 * Ideas on what to improve the content of the current section.
 * Media to illustrate the current section.
 * Links to reliable sources about the section (that can become references)

A good signal-to-ratio balance is expected to be achieved by:
 * Limiting the total number of responses received by an editor to 10. Editors will receive more responses once the current ones are completed or discarded.
 * Receiving individualised responses. Each reply by a reader will be directed to a single editor even if several editors requested the same type of information for the same section. That avoids the same responses to be processed by many editors.
 * Focusing on a section. Questions are associated to a specific section and topic (media, ideas, links..) to avoid responses to become too general.
 * Limiting the number of questions each reader sees to a maximum of one. Even if several editors requested info on several sections, only one of them will be shown to the user each time.

For more details,.