Reading/Web/Advanced mobile contributions

Currently, a number of editing and contribution workflows are unavailable on the mobile website. These pages were initially hidden as they were not optimized for mobile devices and increased the complexity of the site significantly. However, their absence also prevented contributors from being able to edit and moderate. After a number of requests from our communities as well as an increased focus on contribution workflows for the upcoming year, the Readers Web team has decided to work towards exposing the currently unavailable pages and flows and to provide better editing functionality on the mobile web overall. Our plan is to build this as an opt-in feature which editors can enable. We hope this will decrease the necessity of switching between the desktop and mobile sites while on a mobile device and provide a better mobile editing experience overall.

Expanding the contribution workflows on an existing skin will provide a quick way to increase the amount of productive mobile contributions. It will also allow the full breadth of tools in a short timespan, giving us more time to do thorough research and design for the most crucial workflows.

We have captured this goal in output 3.1 from the 2018-2019 Annual Plan: Contribution tools on mobile web via an existing mediawiki skin.

Background
We began the research process by consulting with individual members of the community on the main obstacle to mobile editing in their opinion. Combined with two group consultations led at the Barcelona hackathon, the following main issues were identified:


 * Pages necessary to perform contribution (editing and moderation) workflows are currently unavailable on the mobile website
 * There is a lot of unexplored potential for microcontribution workflows on mobile

The focus of this project will be on the first issue - providing access to currently hidden pages from the mobile website.

Recommendation
Expose currently unavailable pages on the mobile website using the Minerva skin as an opt-in setting option.

Audience

 * Active editors, in particular medium and high-volume editors (100+ edits)
 * Editors focused on maintenance workflows - easier to make smaller contributions from mobile
 * Nice to have: all mobile editors

KPI’s

 * Increase mobile web edit volume by wiki segment over time by 10%
 * Increase the number of curation and moderation actions taken on the mobile website by wiki segment over time by 10%
 * At least 60% feature retention amongst medium and high-volume editors (100+ edits)

Other metrics

 * Decreased number of users of desktop version link
 * Number of users opting into/out of the feature

Overview of new functionality
An advanced editing option will be presented in the mobile settings menu (not a part of beta settings). Selecting this option will do the following:


 * 1) Add navigational elements within the user menu that direct to pages currently missing from the mobile website.
 * 2) Switch all mobilefrontend mobile special pages to redirect to the base mediawiki special pages.  (For example, if a link currently navigates to https://en.m.wikipedia.org/wiki/Special:History/King_Island_emu, switch to https://en.wikipedia.org/w/index.php?title=King_Island_emu&action=history )

Roadmap

 * 1) Perform user consultation based on proposed approach
 * 2) Determine navigational elements and hierarchy
 * 3) Determine metrics and build out instrumentation
 * 4) Build new navigation
 * 5) Switch links/Redirect mobile pages to mediawiki pages
 * 6) Provide settings option and communicate widely
 * 7) Potentially provide banner/some sort of CTA for advanced editors
 * 8) Based on feedback, prioritize fixes necessary to special pages
 * 9) Perform fixes in prioritized order

Length
The total length of this project would be approximately 1.5 Quarters

Technical estimates
The below estimate is for exposing the pages only. The special page fixes will require extra work depending on the scale/number of pages:


 * Navigation, link switching, adding new setting: 1 Quarter, approximately 2 engineers

Working with the communities
We would like to work with communities to help prioritize the special pages and flows for the mobile website as well as to help get feedback on the state of the project throughout development. We plan to do the following:


 * IRC Office hours
 * Constant communication throughout the development process with updates and time for the communities to provide feedback
 * Announce and discuss deployment schedules on all wikis
 * Provide banner/call to action for advanced editors upon deployment

Next Steps
Based on feedback received, we may continue with the following:


 * Expanding the set of fixes to special pages
 * Expanding the possible workflows available (making certain gadgets work on mobile, for example)
 * Continuing with similar changes in the vector skin (making vector responsive)

Product
Achieving the overall objective can be done through the following on mobile:


 * Displaying hidden special pages in an existing mediawiki skin
 * Identifying issues with current special pages and performing fixes to make pages usable

In terms of functionality, both the Vector and Minerva skins can achieve the objective. Investing in the Minerva skin for mobile, however, will make future transitions between entry-level editing and advanced editing easier and ensure a more consistent user experience throughout the process. In addition, exposing veteran editors to Minerva is likely to make them more conscious of the way their edits are displayed on the mobile website, which could eventually lead to providing better content for readers and editors alike.

Technical Rationale
From a technical perspective, doing these changes in the Minerva skin is preferable compared to Vector because of the downsides of doing so in Vector:


 * Less complexity - if we select Vector, we will need to hide the responsive vector changes under a feature flag, thus allowing for three separate versions of the mobile website - Vector, Responsive Vector, and Minerva.  We would also have to work on making sure we hide gadgets for Responsive Vector or worse, audit all gadgets before shipping so that we do not break any existing gadgets or workflows in Vector
 * Onboarding cost and development time will be higher - doing the project in Vector will take approx. twice the amount of time
 * Higher maintenance cost - the team will be expected to bear the full burden of maintaining volunteer changes to Vector

Community risk and adoption rationale
From the community perspective:


 * No strong preference was shown towards performing the changes in either skin.
 * Doing the changes in the Vector skin introduces risk - it was highlighted during our sessions and individual consultations that many members of the community will prefer to use the desktop version of vector on their phones despite the changes due to familiarity. We would like to allow editors to be able to continue doing this in the future
 * Community members stressed the importance of informing users on Minerva about the new advanced functionality to promote adoption.

Next Steps

 * IRC Office hours for additional input from communities on July 20th
 * Meeting with stakeholders to review the proposal

Documentation

 * Technical analysis
 * Community consultation summaries and product rationale

Themes from hackathon conversations, Barcelona 2018
During the Barcelona hackathon in 2018, we held two sessions focused on discussing this project with members of the editing and technical community. These are our notes from these sessions:


 * Interest in exposing more pages in mobile was high and people agreed that any work in this direction would be valuable.  The main issues that were identified were use and availability of gadgets as well as specific workflow variation - tools used and shifting across wikis, different workflows based on projects, workflows split among multiple pages, etc.  Interest was raised towards microcontributions and new microcontribution functionality (noting this here as it came up multiple times, although it is outside the scope of this project).

Full notes from the sessions can be found on this etherpad.

How people currently edit on mobile


 * 1) Switch back between vector and minerva, although some editors prefered minerva
 * 2) Use mobile for language and translation due to better multi-language input
 * 3) Use mobile for better syntax highlighting

What we’re missing currently


 * 1) Users do not like the fact that certain pages are blocked on mobile - “a lot of what timeless did well was simply bringing back hidden pages and features”
 * 2) There is an interest in exposing all pages, even if they are flawed
 * 3) Gadgets - one user switches to desktop only for the ability to use their gadgets
 * 4) Recent changes
 * 5) History
 * 6) Familiarity - If there were a mobile version of Vector, for instance, it would make it easier to find something familiar
 * 7) Mobile-specific workflows
 * 8) Easy way to read discussions - talk pages, help desk, administrative noticeboard, help desk
 * 9) New ways for microcontributions

Split audience here. While all could agree on missing functionality, the room seemed to be split along the lines of making this functionality mobile-specific versus making it available now and allowing editors to find workaround where necessary within their current workflows

Ideas on exposing all pages


 * 1) It probably won’t scale to expose all pages - begin with a prioritized list
 * 2) Collapsing rather than hiding can give a lot of the gains of hiding without the detriments

Minerva vs Vector


 * 1) No strong opinions either way - some people leaning towards vector with the technical motivation of only having one skin.  Others disagreeing to say the more skins the better
 * 2) Either will be useful and an improvement from the norm

Other notes


 * 1) A lot of simple tasks are built into tools such as twinkle and huggle.  Focusing on performing these tasks directly from mobile might not get us the results we are expecting.  However, not all editors use these tools.
 * 2) Whether responsiveness is desirable came up a few times - good to remember that regardless of what we do, it will make some people unhappy
 * 3) Often special pages might not even be that useful - while some people use recent changes, there’s a wide variety of workflows that this does not account for
 * 4) 80/20 rule applies to microcontributions - it would be helpful to have a way to tag articles/portions that fall into the side that requires more care, attention etc from mobile.  These can later be reviewed on desktop
 * 5) Vandalism example: “If you look at vandal fighting the bots take 70% of the work.  30% left - automation to say likely hard/likely not hard.  Likely not hard - show to mobile user like "do you think this might be vandalism" with buttons "yes" and "no"

Identified pages that need some work:


 * Talk pages
 * Village pump
 * Administrative noticeboard
 * Help page
 * Recent changes
 * Pending changes
 * Flagged revisions
 * Special:RecentChangesLinked
 * Special:NewPagesFeed

Questions

What percentage of editors use outside tools for microcontribution-type flows?

What are the main revision workflows per wiki?