Jump to content

Reading/Quarterly planning/Q4

From mediawiki.org

Most goals posted

[edit]

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


Brainstorming Guidelines

[edit]

Android

[edit]
  • 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!
    • Integrate with trending articles API, when it's ready?
  • 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]
  • 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

iOS

[edit]

Infrastructure, APIs, and Services

[edit]
  • 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]
  • 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

[edit]

Web

[edit]

Goals Draft

[edit]

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

Android

[edit]
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

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

Web

[edit]
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.