Reading/Quarterly Planning/Q3

Top priority goals, fuller list

Update 11-December-2015: Top priority goals for quarterly reporting have been centrally posted for Q3 FY 2015-2016 (January - March, 2016). Refer to the Next Quarter column on the #reading-admin board for the more exhaustive list of goals planned to be worked in Q3.

Brainstorming Guidelines

Stay aligned with Q3 goals mentioned in with the Roadmap
Nothing (within the constraints of the Roadmap goals!) is too off the wall or crazy during brainstorming!
Earlier brainstormings are found here

Have Parsing needs?

Enter them in T119088 by December 4.

Web brainstorm

(for full list include Roadmap)

Speed/Architecture mobile web beta (including W0 compatibility)
Read More to stable
Gather/Collections support for Android
Language button / fixed footer menu mobile web, Simplified Vector desktop sidebar (w/ A/B test for Reading strategy)
QuickSurveys automation (no constant deployments)
QuickSurveys UI - possibly leveraging CentralNotice infrastructure
QuickSurveys event trigger mechanism (likely dependency: Fundraising Tech)
QuickSurveys Wikipedia Zero survey tagging
Revisit EL schemas
OpenGraph
Hovercards to stable
iOS universal links support
Image performance in MobileFrontend
Special:UserProfile transition
Researchers surveys

Web Engineering Goals (not all committed)

Committed	Objective	Key result	Dependency	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
Yes	Make Wikipedia more accessible to 2G connections with fast API-driven web experience in mobile web beta	Reduce data usage in mobile web beta by 20% Reduce first paint / time to interact to 5 seconds or less at the median and to 10 seconds or less at the 90th percentile on 2G connections, after accounting for lag	Critical path: Security, Architecture, Performance, Services, Parsing, Analytics Less time involved: TechOps, Fundraising Tech, Release Engineering, Partnerships	T113066	Applies Q2 R&D on a fast API-driven web experience, which will be discussed at the January 2015 Wikimedia Developer summit, to the mobile web beta channel, with progressive rollout to the mobile web stable channel following in Q4.	The website is unacceptably slow on slow connections. The Global South, where slow connections are more prevalent, is the core strategic focus of the Reading Web team. The necessary new architecture happens to be a great opportunity to employ server resources more judiciously and position us for faster innovation in the future, too.	Wikipedia Zero support intact, RESTbase/Node.js services exist or will be built in tandem, there will still likely be some api.php usage from the browser, SEO can be configured gracefully, data center availability configurable	*
Yes	Language switching improvement - to mobile beta (drafted for public committ) on all wikis	Increase language switching by 5% on mobile		T121919	Improve language switching within an article- probably by moving the button into a sticky footer (per T119658:	The current language-switching button is buried at the bottom of the article and still gets more clicks than the hamburger menu [1] see mobile report card (table name is 'page-ui-daily')
Internal commitment	Support Gather on Android	Android team has web support for new display of gather and backend support for work they are planning in Q3				Frontend: If a user shares a collection on Android, it will most likely be followed by someone on the web. Essential features of the collection being shared should not disappear when viewed on the web. Backend: The web team, with support from infrastructure team are best equipped to help with any API needs Android team has.
No	Drive engagement by providing read more to all users	Push read more (related articles extension) to stable on mobile and desktop		T122260	The feature should be up in beta by end of Q2 (per Q2 goals). Based on data and community feedback, hope to roll-out to all users to as many wikis as possible	This feature has significant engagement from readers on both iOS and Android, and we have reason to suspect it will be similarly valuable to web users.
No	AMP POC	Investigate viability of AMP markup
No	Quick Surveys	Support Research needs		T122263
No	Serve readers information faster with desktop	Hovercards is moved out of beta on as many wikis as possible (with opt-out)		T70860			To do this, we will need to demonstrate user value and address known material issues, as well as any material concerns raised on beta discussion page.	Hovercards should lead to a drop in pageviews, as users who are just looking for a definition will no longer have to load an entire page. We think this is a good thing, but will need to measure hovers to address any concerns that arise from drop in pageviews.
No	Work towards small experiments on desktop around language switching
	Not out of the question, but not yet prioritized, work to support other teams: low-res image support on slow connections for performance support universal links on iOS (T97785) quick survey improvements to support easier setup, research team, and W0 team

*We estimate at least 20% of engineering effort will go towards maintenance and bug-fixes, in addition to the significant infrastructure work being undertaken in the first goal mentioned above

Product and Design Efforts (Rough and subject to change)

Product (50% of an FTE):

delivering related articles (10%

delivering hovercards (desktop feature!) (30%)

section analysis for Q4 (5%)
figure out if we should actively work on bringing link preview to desktop (hovercards for mobile) (5%)

analyze language links on desktop (see above goal)

Design in Q3 (50% of an FTE)

Language bar 15%

desktop language experiments 5%

Hovercard improvements and engadgement around it 15%

Global South Research 5%

Look-ahead work on Q4 projects 10%

iOS brainstorm

(for full list include Roadmap)

Maps based nearby interface
IOS Notifications
Finish deployment of deep "Universal" links
iPad design and tablet specific user stories
CoreData migration (update app data layer for stability and speed)
Feed, feed, feed (potential dependency on apps content service if desiring to centralize logic)
Improve read more. A/B test variations of image size + text extract, amount of related articles, and location of read more within the page.
Adopt content services

iOS Goals (not all committed)

It should be noted that the iOS team is in the midst of finalizing and pushing to Beta a major revision of the app. All the items below are subject to being dropped if the user feedback from that roll-out requires significant iterations or investment prior to moving on to any new goals. I'm not sure this should be a stated goal, since its basically "finish the goal from last quarter if we haven't by Jan 1", but can add it if it is helpful for understanding the relative priorities of the team.

Committed	Objective	Key result	Dependency	ETA	Status	Epic Phab	Description	Rationale	Assumptions/Risks
No	Begin adoption of Android "Content Services"		Service layer architecture continues to be supported and staffed.	EOQ			The Android team has been pioneering a content services layer. iOS would like to adopt this. For the user this should result in quicker load times and less data transmission.	Currently the apps use endpoints which return HTML which then must be parsed on the client and re-presented in the app UI. The content service allows us to request specific content chunks relevant for the app, resulting in less network requests, data costs (for WMF and user) and a more "modern" development pattern which cleanly separates backend data provider from front end presentation.	This assumes that there are not major scalability issues with Content Services and the content services architecture continues to be a focus for the Reading team.
No	Update Data Layer	Improved load times, reduced crashes, increased feature dev velocity.	None	EOQ	To do	To do (there are existing tickets, but no "Epic" yet).	Convert our proprietary data layer to iOS standard approach, specifically the relational database provided by the OS (CoreData).	We currently use a basic file serialization pattern for storing user data. This is both brittle (eg. makes it easy to write bugs which cause crashes). It also means that all a user's history or saved pages must be read into memory before they can be queried or viewed, which can slow app responsiveness.	This was previously attempted and scrapped, so we need to ensure the scope and tech risks of this are understood/managed.
No	Research and pilot content notifications for readers	Increase retention	Depends on exact scope. For pilot: none	EOQ	To do	To do	Research, scope and implement a limited test (either in Beta or via a/b testing) to send a daily push notification to users who opt-in to receiving it. The push will be some kind of community curated content (ie. some element of the main page, such as "Today in the News" or FA) which will be pushed globally (ie. pushes will not b personalized) from the app client.	The overall goal for the iOS team continues to be to experiment with mobile-app specific ways to increase repeated use (retention) of the iOS app. One common mechanism in mobile apps to retain users is to push notiifications to them based on events or interest. In an ideal world we would build on our centralized notification systems, but since the purpose of these notifications is different (to push content to casual readers) than Echo and watchlist usage (which are about editing and collaboration workflows), we will pilot this in isolation, and	This is assuming this pilot can be implemented entirely within the Reading team. We will be bounding the scope to make that feasible, but if this requires support from other teams, that may be

Android brainstorm

(for full list include Roadmap)

Gather (likely dependency on Reading Web for API enhancements)
Wikipedia Zero exit interstitial (potential dependency on Reading Web, although is simple extension change potentially doable by Android engineer)
Better custom APK channel persistence (i.e., don't lose channel if custom APK preload gets upgraded before first launch)
Do more with notifications?
1. Picture of the day?
Tablet layout
Continue work on Wikipedia Lite
Improve discovery of saving a page and accessing list of saved pages
Surface more main page content
1. Any of which would also work nicely on Google Now if they actually open up the API
Improve share a fact and show which text has been shared

Outcome: #4 is likely part of Gather epic, everything else added to the holding tank of awesome ideas!)

Android Goals (not all committed)

Committed	Objective	Key result	Dependency	ETA	Status	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
Yes	As a user, I'd like my collection of Saved Pages in the app to persist with my Wikipedia account, so they can be synchronized on any of my devices.	Lay down the groundwork for the general implementation of "collections" in the Android app.	Gather API (possible guidance requirements from Mobile Web team)	2016-02-15	To do	T120107	This will allow the app to synchronize the user's collection of saved pages (linked with the user's Wikipedia account), and enable the user to access their list of saved pages across any device on which they use the app (when logged in).	This is the first step of the much larger goal of implementing general "collections" on the Android platform. We realized that using the Gather API for the purpose of synchronizing the user's saved pages is a good baby step towards the overall goal. This will enable a much-needed (and much-requested) feature, and simultaneously allow the team to gain a deep familiarity with the Gather API, and get a sense of its capabilities and deficiencies (if any), which will poise us to implement the larger feature set of collections with much greater efficiency and forethought.	We're assuming that the Gather API, as it exists today, has all the basic functionality we need to get this up and running.

Committed	Objective	Key result	Dependency	ETA	Status	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
Yes	As a user, I'd like to be able to create collections of articles that appeal to my interests.	A basic implementation of collections (visible and manageable only by the user), to set the stage for creating fully "social" collections.	Gather API (likely guidance requirements from Mobile Web team)	2016-04-01	To do	T120108	This will allow users to create and manage collections from articles that they browse in the app.	This will implement the fundamental functionality in the Android app to create and manage "collections" using the Gather API. The current notion of "saved pages" will merge with the more general notion of collections. Roughly speaking, as the user browses articles, he/she will have options to add the article to a new or existing collection. The user will also have a new navigation item of "Collections," where all of the user's collections would be listed and be managed. Since this will use the Gather API, all of the user's collections would be linked with their Wikipedia account, meaning that the collections will be accessible from any device where the user logs in.	We're assuming that the Gather API, as it exists today, has all the basic functionality we need to get this up and running.

Infrastructure

Deploy AuthManager (needed for 2FA and finishes Q2 goal)
2FA (OATHAuth) for Wikimedia wikis (need to work with Security and Tyler; probably also CLs and Design)
Assist Web team in assisting Android team with Gather integration
API error messages should be localized
Migrate APISandbox to core (currently blocked on oojs-ui)
OAuth enhancements

Infrastructure Goals (not all committed)

Committed	Objective	Key result	Dependency	ETA	Status	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
Yes/No	Objective here.	Key result	Dependencies	ETA	To do	Link

Strategy/Product

0.1% unauthenticated desktop to mobile A/B test for Reading strategy

Strategy Goals (not all committed)

Committed	Objective	Key result	Dependency	ETA	Status	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
Yes	Assess strategy	Data obtained and analyzed	TechOps	EOQ	To do	T117826	Redirect a small portion of unauthenticated desktop web users to the mobile website, then observe impact on engagement.	There is an embedded assumption that contemporary UX leads to deeper engagement. To some extent, this is a given, although this strategic test will help to identify the relative weighting of the corresponding strategic pillar around UX refinement.	The ramp up should go through a process like that described by Hafak.