Reading/Quarterly planning/Q4

Most goals posted

Update 10-March-2016: Most goals have been centrally posted for Q4 FY 2015-2016 (January - March, 2016).

Brainstorming Guidelines

Align with the roadmap
This said, it's brainstorming - be creative!
Some previous brainstorms: Q1 & Q2 FY 2015-2016 brainstorms, Q3 FY 2015-2016

Android

The Feed. (replace the current "Today" screen (Main Page) with an infinitely-scrollable feed of relevant articles based on the user's activity). DBrant (WMF) (talk) 18:10, 4 February 2016 (UTC)[reply]
- Model off the iOS team's implementation (card views).
- Sort of dependent on the success of the feature in the iOS app, but very likely better than the current Main Page. Featured articles on the Main Page are disproportionately Cricket-related. That's enough with the cricket!
  - Gonna need a citation on that cricket claim. ;) MHolloway (WMF) (talk) 23:55, 10 February 2016 (UTC)[reply]
- Integrate with trending articles API, when it's ready?
  - And then trending and recommendations can tie in nicely with google now also KHammerstein (WMF) (talk) 00:00, 10 February 2016 (UTC)[reply]
Wiktionary. DBrant (WMF) (talk) 18:42, 4 February 2016 (UTC)[reply]
- Expand current Wiktionary integration to more languages (currently restricted to en). Will require more server-side work to massage non-en pages.
- Split off into its own app, and replace the current (outdated, Phonegap-based) Wiktionary app.

Comment splitting Wiktionary into its own app might be a step in the wrong direction. It seems to me that a single integrated app might be preferable. Is there a rationale for wanting to split off Wiktionary? --Pine^✉ 18:14, 7 February 2016 (UTC)[reply]

I think an argument can be made for both cases. But the reality is that we currently have a Wiktionary app published on Google Play that is severely out of date (but still has ~75k users). If it's simple enough to split off our new integrated Wiktionary dialog into its own app, and replace the current one, it might be worth pursuing. We should, of course, also weigh the option of sunsetting the current Wiktionary app entirely. DBrant (WMF) (talk) 15:00, 8 February 2016 (UTC)[reply]

Some integration with the Wikipedia app would definitely be nice, but I find Wiktionary very useful on it's own and would appreciate direct access to it via it's own app. (the old wiktionary app was nice to have, for what it was) Also would be awesome if it could support using the content offline (e.g. when someone is travelling). Probably integration of structured data in wiktionary would help towards making such an app more easily possible and able to do more. Aude (talk) 19:33, 8 February 2016 (UTC)[reply]

Yes to structured data in Wiktionary! MHolloway (WMF) (talk) 23:55, 10 February 2016 (UTC)[reply]

Moar Wikidata. DBrant (WMF) (talk) 18:42, 4 February 2016 (UTC)[reply]
- Native info windows populated from Wikidata.
  - This needs careful thought. We already have the infoboxes in Wikipedia and I wouldn't want to replace them with something automatically generated from Wikidata. With the infoboxes, users can control what fields are there, etc. There are plans or ideas for improving infoboxes and make them fully machine readable, etc. phab:T114251 Aude (talk) 19:33, 8 February 2016 (UTC)[reply]
- Inline with link previews, search results?
Move away from hamburger menu. DBrant (WMF) (talk) 18:50, 4 February 2016 (UTC)[reply]
- Surface more clearly the features we want users to see.
- Force ourselves to trim away features that are unnecessary.
  - This sounds really cool, but we could prototype first! KHammerstein (WMF) (talk) 23:59, 9 February 2016 (UTC)[reply]
New directions in microcontributions. DBrant (WMF) (talk) 18:42, 4 February 2016 (UTC)[reply]
- Engage with community of editors/admins to generate ideas for apps to handle low-hanging, repetitive administrative tasks.
- I like and this fits well with 'community of readers' strategy as JMinor (WMF) pointed out to me that such an offering could provide pre-emptive tools for moderating new casual contributions like (me talking now):
  - media uploads, wikidata descriptions, lead image selections, explanations for why something is trending (if Donald Trump is trending, we should have a short caption saying that he just dropped out of the race...otherwise a reader has to read through article to find it). Jkatz (WMF) (talk) 04:18, 11 February 2016 (UTC)[reply]
Make app aware of metered connections BSitzmann (WMF) (talk) 23:47, 8 February 2016 (UTC)[reply]
- When on a metered connection (e.g. on a cellular data plan):
  - Lazy load images (only load shortly before we scroll to it)
  - Turn off image widening
Focus on more sessions and longer sessions for existing users KHammerstein (WMF) (talk)
- Google now integration to encourage coming back to the app
  - Trending, recommendations, nearby, ...?
- Improve read more to encourage longer sessions
  - Test different amounts, locations, designs
Improve highlighting
- Make it easier to highlight article elements
- Save a article excerpts in groups (like saved pages) (KHammerstein (WMF)'s baddass idea Jkatz (WMF) (talk) 04:18, 11 February 2016 (UTC)[reply]

iOS

potential epics include:
- deep links
- nearby w/map
- sharing improvements
- find in page
- daily content local notifications
- reader customization (themes and dynamic text)
- in the news added to the feed
- Incognito mode
- Further UI improvements and design improvements (drawers, gallery)
- Machine curated feed phase 1 (r&d)
- Improved iPad support
- JMinor (WMF) (talk) 23:24, 10 February 2016 (UTC)[reply]
Article profiles Nirzardp (talk) 17:51, 11 February 2016 (UTC)[reply]

Infrastructure, APIs, and Services

Suggestion for quick survey: (I talked with Adam about this and he recommended I add it here.) In the Wikidata team we're working towards improving the perception of Wikidata on the Wikipedias for example through better data quality tools. One way we measure satisfaction of Wikipedians with Wikidata is how much data from Wikidata is used in a given Wikipedia. I'd like to get some additional data by asking a small group of Wikipedians one or two simple questions (like "Do you know Wikidata? What is your general feeling towards Wikidata?). Quick Survey seems like the perfect low-effort way for editors to do this. I'd like to track this over time and across projects. I would like to only ask Wikipedians who have at least 100 (?) edits. I am told this might need integration with central notice to only ask people who fit a certain criteria. --Lydia Pintscher (WMDE) (talk) 13:47, 10 February 2016 (UTC)[reply]
- Hi Lydia Pintscher (WMDE) - This seems like a great idea. Quick survey right now requires (from my understanding) about a day's work of dev support and it takes time to implement it from one project to the next. Right now - it does not handle open ended questions, but you can link out to an external survey (e.g. google forms, qualtrics). I guess my point is that the tool needs work and development! Would be great to have that.
- For Community Engagement, Quicksurveys is something that CE is also eyeing - well, I am eyeing :) We need a way to poll editors from time to time to ask them questions about awareness of products, WMF and other questions. Wondering if/how reading might be able to support it or how I may be able to get support or how we might be able to streamline the tool so it is easier for others to use. Thanks! --EGalvez (WMF) (talk) 08:28, 13 February 2016 (UTC)[reply]
  - I'd rather not link out to a survey to keep this very low-effort and low-friction for the editors we're asking. --Lydia Pintscher (WMDE) (talk) 09:59, 13 February 2016 (UTC)[reply]
  - Oh and I don't think I need open-ended questions. Choosing from a bunch of options is enough for my case. --Lydia Pintscher (WMDE) (talk) 10:00, 13 February 2016 (UTC)[reply]
new 3D media formats requested in Tech Wishlist - Blender (T3790, #11), KML (T28059, #34) --Tgr (WMF) (talk) 16:28, 11 February 2016 (UTC)[reply]
API support for cross-wiki page lists (e.g. for Android saved pages feature) --Tgr (WMF) (talk) 17:25, 11 February 2016 (UTC)[reply]

UI Standardization

Visual Diffing tool integration together with demos on base stylesheet
Automated Accessibility testing of base style demo implementation (and maybe libraries) --VEckl (WMF) (talk) 17:17, 11 February 2016 (UTC)[reply]
- [copying from below] Add a high-contrast mode to improve the UX for the visually impaired users. Bmansurov (WMF) (talk) 01:48, 11 February 2016 (UTC)[reply]
Ambient light sensor specific contrast adaptions

Web

Mobile web stable channel speed/architecture ABaso (WMF) (talk) 05:12, 29 January 2016 (UTC)[reply]
Private multiple watchlists --ABaso (WMF) (talk) 18:02, 3 February 2016 (UTC)[reply]
- Integrable as general collections (reading lists) in Apps. DBrant (WMF) (talk) 17:33, 4 February 2016 (UTC)[reply]
- Recent discussion on task T124752 (Expiring watch list entries) has included various ideas of expanding watchlist entries to include tags that could be used to expose multiple lists. There are also task T3492 (Multiple watchlists) and task T9467 (Public and private watchlists, shared watchlists) and I'm sure many other related requests for improving watchlists. This seems like an area where a suite of improvements could be designed and implemented possibly in collaboration with WMDE and other interested parties. --BDavis (WMF) (talk) 22:36, 6 February 2016 (UTC)[reply]
- This proposal does not seem to be related to the roadmap. Perhaps you want to propose a change in the roadmap? Nemo 16:44, 7 February 2016 (UTC)[reply]
  - Maybe :) --ABaso (WMF) (talk) 19:42, 10 February 2016 (UTC)[reply]
List/watchlist-related Tech Wishlist requests: reading list (T120756, #37), cross-wiki watchlists (#4), user watchlists (#10), download page collections as EPUB (T97672, #36) --Tgr (WMF) (talk) 16:28, 11 February 2016 (UTC)[reply]
- +1 on EPUB, can be considered as "global south" because it's for offline consumption. Nemo 18:49, 28 February 2016 (UTC)[reply]
The roadmap says "global south", so let's fix known, self-contained bugs that reduce the quality of the websites for all unregistered users with limited networking or resources: task T119344 task T119342 task T62250 task T54165 task T126825 task T121734 task T98125 task T126836 task T114791 Nemo 16:43, 7 February 2016 (UTC)[reply]
- As a stretch, let's do the same for casual users and light editors who would otherwise be forced to use the desktop site for simple activities: task T88270 task T101491 Nemo 16:43, 7 February 2016 (UTC)[reply]
- Nemo Do you have a list of such Global South-impacting bugs? If so that could be awesome! I do not think we have a good grasp, otherwise Jkatz (WMF) (talk) 04:00, 11 February 2016 (UTC)[reply]
  - The list is right into my message. Nemo 18:29, 28 February 2016 (UTC)[reply]
    - I see, Nemo. Can we schedule maybe an hour sometimes this week or next to walk through them? I would really appreciate it. Jkatz (WMF) (talk) 04:01, 29 February 2016 (UTC)[reply]
      - I didn't see this message, sorry. However I would not have been available in that period anyway. Nemo 21:54, 25 March 2016 (UTC)[reply]
- Unsurprisingly, participating here was a waste of time. On the bright side I didn't lose much, my suggestions were easy to find in the issue tracker... Nemo 21:54, 25 March 2016 (UTC)[reply]
  - Hi Nemo, I actually think that is a premature conclusion. Getting ideas on the table is the first step, but it is rarely the last. It generally takes several quarters for any ideas to get enough awareness, buy-in and planning to be prioritized. This is on our radar now and while some are actively being discussed, I think ideas mentioned in one quarter could very well fit in a future quarter. We probably should have set more explicit expectations in this regard. To further set expectations, most ideas that are proposed in this or any future brainstorming session never get worked on. I don't think that is necessarily a reflection of the process being bad, but of limited resources. In my opinion, even if ideas are never worked on, the suggestion alone adds value by exposing everyone who reads it to a new idea or viewpoint. That being said, whether or not you feel that value is worth your time or not is completely personal. It's not too late to talk about those tickets. I'll email you. Jkatz (WMF) (talk) 23:45, 25 March 2016 (UTC)[reply]
Can we get Wiktionary integration on mobile web? --Pine^✉ 18:15, 7 February 2016 (UTC)[reply]
Would be interested in splitting of Special:Nearby out of MobileFrontend and adding maps, like we did in the Android app :) Aude (talk) 19:34, 8 February 2016 (UTC)[reply]
Promote HoverCards out of beta to stable channel. --ABaso (WMF) (talk) 19:38, 10 February 2016 (UTC)[reply]
Add support for consistent structured data driven plus geo context aware feed main page --ABaso (WMF) (talk) 19:38, 10 February 2016 (UTC)[reply]
Expand QuickSurveys: user friendly UI and improved targeting, maybe via CentralNotice as described in task T125125 AGomez (WMF) (talk) 00:39, 11 February 2016 (UTC)[reply]
Table of contents overlay that's only a tap away and accessible from anywhere on the page (unlike the current implementation in which the user has to scroll to top to see the TOC) Bmansurov (WMF) (talk) 01:48, 11 February 2016 (UTC)[reply]
- This will help us get rid of collapsed sections, which will allow easily printing the page and searching on it.Bmansurov (WMF) (talk) 01:48, 11 February 2016 (UTC)[reply]
- This fits the notion of an 'article action menu' for readers Jkatz (WMF) (talk) 04:09, 11 February 2016 (UTC)[reply]
Collapsible infobox Bmansurov (WMF) (talk) 01:48, 11 February 2016 (UTC)[reply]
Infoboxes and navboxes as first class citizens separate from the editor (see https://phabricator.wikimedia.org/T112987) Jdlrobson (talk) 17:16, 11 February 2016 (UTC)[reply]
Support for gestures: pull down to refresh the page, left-to-right swipe to open the hamburger menu, etc. Bmansurov (WMF) (talk) 01:48, 11 February 2016 (UTC)[reply]
Add a high-contrast mode to improve the UX for the visually impaired users. Bmansurov (WMF) (talk) 01:48, 11 February 2016 (UTC)[reply]
Give editors the tools to make their templates mobile friendly (style tags in wikitext, update preview to show in different skins/resolutions) Jdlrobson (talk) 17:01, 11 February 2016 (UTC)[reply]
Cache logged in users pages on mobile web just as we do for anons Jdlrobson (talk) 17:01, 11 February 2016 (UTC)[reply]
- This would require some edge/device composition layer, correct? As such it would be a large, cross-team project, but if all the right skills could be assembled trying it out on mobile web first might be slightly less scary than doing it for all web at the same time. --BDavis (WMF) (talk) 17:13, 11 February 2016 (UTC)[reply]
Push notifications of trending topics (by edits) Jdlrobson (talk) 17:07, 11 February 2016 (UTC)[reply]
Mobile style warning
- Mobile preview for editors (similar to Brion Vibber's jscript hack)
- Or allow media-sensitive CSS and provide a notice if you use a template that doesn't provide Jkatz (WMF) (talk) 04:09, 11 February 2016 (UTC)[reply]
- Feedback around how your edit might increase page load time or payload size, e.g. if the editor has added a large image Phuedx (WMF) (talk) 17:40, 11 February 2016 (UTC)[reply]
expose talk pages to anonymous users on mobile web (T54165, Tech Wishlist ask #79) --Tgr (WMF) (talk) 16:28, 11 February 2016 (UTC)[reply]
- +1, it furthers the "global south" objective by empowering marginalised people. Nemo 18:49, 28 February 2016 (UTC)[reply]
cite / share / export tool (T120487, Tech Wishlist ask #80) --Tgr (WMF) (talk) 16:28, 11 February 2016 (UTC)[reply]
expose article quality information to readers (T120754, Tech Wishlist ask #63) --Tgr (WMF) (talk) 16:28, 11 February 2016 (UTC)[reply]
- JMinor (WMF) is this something you might consider for iOS? Seems to fit well into the 'better encyclopedia' realm (though not necessarily retention). I personally think the web has more core in-article issues (like sections/toc) that should precede this. Jkatz (WMF) (talk) 16:51, 11 February 2016 (UTC)[reply]
- True, MobileFrontend worsens the situation which this wishlist point complains about. As for MobileFrontend the situation can be as easy as a removal of some skin-specific hacks. Can further the "global south" goal if intended as a way to reduce information asymmetry in countries with lower access to information and education. Nemo 18:49, 28 February 2016 (UTC)[reply]

Goals Draft

Deprecated: See Wikimedia Engineering/2015-16 Q4 Goals#Reading for latest

Android

Committed	Objective	Key results	Dependency	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
	Drive retention via feed	• Similar design to iOS • Services for some of the current-side transformations • not blowing up hamburger menu, but bringing people back to it if they close app • share button
	help highlights?
	in-the-news/trending articles

iOS

Committed	Objective	Key results	Dependency	Epic Phab	Description	Rationale	Assumptions/Risks	Notes

Web

Committed	Objective	Key results	Dependency	Epic Phab	Description	Rationale	Assumptions/Risks	Notes
Not yet	Increase learning by lowering cost of exploration	Launch hovercards beta feature on desktop web across multiple wikis, gauge improved reader satisfaction via survey	Community Engagement Analytics Ops	https://phabricator.wikimedia.org/T70860	See here: Beta Features/Hovercards Enable it under your wiki's beta settings to try.	Launching on Android has shown an increase in engagement and web survey data shows overwhelmingly positive feedback. Working on desktop code is a good first step towards cleaner codebases.	This will require community approval on all wiki's it rolls out on	We are looking into whether or not the assumptions made This changes how we measure engagement on Wikipedia's, as pageviews will drop. We will need to start publishing the 'hover' metric (or total engagement) metric in addition to pageviews.
Yes	decrease load time and cost for low-resource environments	Lazy loading of images, and cutting default html size on wikipedias, stable	Jdlrobson can you review and fill in the blanks here?	https://phabricator.wikimedia.org/T113066	Page-load performance improvements, driven primarily by only shipping data that the user will see/use: https://en.wikipedia.org/wiki/Lazy_loading	The load time for articles on slower connections can be several minutes, vastly impacting accessibility. See here for more.	There will not be a major impact on how users experience and engage with content.