Reading/Quarterly Brainstorming

An archive of team brainstorming in Q1 and Q2

=Q1=

Readership Q1 Planning Brainstorm

NOTE: Brainstorming deadline for this etherpad was COB PT 06/09/15. Ideas below are being distilled (organized, de-duped) here: https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation

Some baseline data: https://www.mediawiki.org/wiki/Reading/2015-2016_Q1_Planning_Data

Goal: Readership team members start to asynchronously gather solutions to user problems within the areas identified below in preparation for brainstorming review and refinement session on June 4th and 5th. June 11th and 12th.

Questions

 * Where does offline Wikipedia and Wikipedia Zero fit in the below?

= Brainstorming Guidelines: =
 * Nothing is too off the wall or crazy during brainstorming!


 * Suspend judgement: this is not the time to analyze or critique others' ideas. There will be a separate opportunity to evaluate and analyze

Reminder: Effective Q1, Reading Infrastructure is available for approximately one API project per Reading Infrastructure team member per quarter to assist Reading Web & Apps engineers. They should otherwise always be consulted early and added to API and MediaWiki Core patches for code review for Q1 and beyond.

= Theme One: Make browsing faster [by improving page performance?] =

Android
 * Use "structured data" to (pre)view pages natively
 * "Link preview" feature already being prototyped in mobile apps (aka Hover cards for apps)
 * "Link preview" feature in MF (alpha, being promoted to beta)
 * Show external links in app like Twitter does
 * Bonus if we use the new Chrome theming unveiled.

iOS
 * cache API responses based on cache control from API
 * Use "structured data" to (pre)view pages natively
 * "Link preview" feature already being prototyped in mobile apps (aka Hover cards for apps)
 * "Link preview" feature in MF (alpha, being promoted to beta)

Web
 * ServiceWorker - https://phabricator.wikimedia.org/T101731
 * Hovercard type feature (avoid need to load pages at all)
 * Add "take offline" button to pages.
 * Visiting http://en.wikipedia.org/ on a mobile device redirects to http://en.wikipedia.org/wiki/Main_Page, which then redirects to http://en.m.wikipedia.org/wiki/Main_Page. Could we get rid of the intermediate redirect?
 * Fix issues displayed at https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fen.m.wikipedia.org%2Fwiki%2FBrad_Pitt
 * The new performance team (Ori, Gilles, Aaron and new hire to be announced) would likely be willing to help with this work but at least providing guidance
 * Build a non-MediaWiki mobile web app with offline/caching capabilities, specifically for users with slower connections
 * Only serve lead section for first page visits
 * Start using http://caniuse.com/#feat=indexeddb where available to store content for offline use

All Platforms
 * Custom-tailor generated HTML for mobile viewing
 * Responsive
 * Lazy
 * Replace mobileview API with RESTBase-fronted service
 * Extract mobileview from MF/remove it entirely
 * Use Parsoid as the main parser (also allows us to explore possibilities such as paragraph level annotations and a host of other features)
 * Opportunistically use existing image downsampling (works at least on JPGs right now)
 * Re-explore lazy loaded content/cache manifest usage

= Theme Two: Make it easier to find articles by improving SEO =

Android - App indexing

iOS N/A

Web

Question:  https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Share_pages_on_Facebook.2C_Twitter_etc.
 * A couple concrete tasks put forth by a board member:
 * https://phabricator.wikimedia.org/T93213 - Wes indicated Stas is looking at this
 * - Wes is curious if Reading can handle this
 * https://phabricator.wikimedia.org/T99587 [DONE]
 * Visiting mobile only pages on a desktop browser should redirect to the corresponding mobile page. For example, visiting http://en.wikipedia.org/wiki/Special:MobileMenu on a desktop browser should take the user to http://en.m.wikipedia.org/wiki/Special:MobileMenu rather than display an empty desktop page. 
 * continuity and easy finding: search results in google should link to specific part of article (via google snipped + anchors)
 * small text size on wikipedia.org hurts SEO [citation needed and we don't have small text..]
 * Expose search engine results for external sites. I can nearly always get from a search engine to Wikipedia, so I generally start there even when I know I want to get to Wikipedia. Wikipedia is currently a subset of the search engine results. When search fails on Wikipedia, it's a dead end.
 * Should links to external content be curated similar to the external links section in article or perhaps dmoz and surfaced?
 * do search engines use https://en.wikipedia.org/wiki/oEmbed or FB Open Graph (below) ?
 * Simplify Wikipedia's main page. The front page is currently a little daunting, especially for the single lingual. There are at least five different language advertisements. (The logo itself, the languages around the logo, the drop down language selector next to search, the freeform "Find Wikipedia in a language" field, and the article count by language list filling a full page in itself.) The front page seems to correctly guess which language I want so I feel some reluctance to tap again on my preferred language. Unfortunately, I'm given an ultimatum: either tap on my preferred language or perform a search. I believe it would be better to bubble up the content of the main page better or at least guide users to it:
 * For logged in users, go to the preferred language main page directly. https://en.wikipedia.org/wiki/Main_Page, in my case. There's actually not even a login header on the front page or other indicator that I'm signed in.
 * For all other users, emphasize the best guess preferred language link.
 * Add builtin support for a distraction free skin that removes a lot of the sidebar links and makes the page a comfortable reading width. This should be a toggle button at the top.


 * Structured article metadata - microformats, schema.org microdata
 * Lots of medical information can be made available via microdata; medical content is one of the strengths of enwiki (although this might be better suited for a wikiproject, in which case the question becomes, what can we do to empower it?)


 * Social SEO
 * OpenGraph support
 * make sure G+, Twitter, Pinterest etc. etc. previews work nicely
 * make sharing articles and images easier

All Platforms

= Theme Three: Deepen the browsing experience by surfacing interesting content =

Android
 * Tabbed browsing in Apps
 * More Safari-like browsing of multiple pages in history (e.g. using snapshots in a collection view)
 * Explore alternate pages ideas to replace "Today" page of W menu. Could be a gallery view/ cards view of recently featured articles
 * In W menu: Group Recent and Saved pages together into recent, add new item that promotes media instead. Could be while using Wikipedia Radio.

iOS
 * Tabbed browsing in Apps
 * More Safari-like browsing of multiple pages in history (e.g. using snapshots in a collection view)
 * Explore alternate pages ideas to replace "Today" page of W menu. Could be a gallery view/ cards view of recently featured articles
 * In W menu: Group Recent and Saved pages together into recent, add new item that promotes media instead.Could be while using Wikipedia Radio.

Web
 * Generate Gather lists from existing WP lists, and promote them on side menu
 * Re-use wikigrok in a way that supports suggesting further reads
 * Allow users to design/choose elements of their userpage ?
 * Enhance user to user interaction: Fix userpage issues on mobile, a better talk system, allow wikilove tokens.
 * Special:RandomList - Random 2.0 - Infinite scrollable random collection using Gather
 * Take Offline button
 * Saved pages for offline use
 * Download to pdf button for offline reading on Gather lists (Collections extension already has this function)
 * Add wikidata description and lead image to desktop site - parity with mobile
 * Add wikidata description and lead image to desktop search as you type - parity with mobile (is this Search & Discovery team's job?) (Reading probably would need to be the team implementing if doing for Q1)
 * Remove wikidata description from lead image overlay. Add as quick fact within the article while sourcing where it comes from
 * Alternative to the above, add only descriptions that contains data statements about (height, age, length..etc any quantity data type)
 * Hovercards to stable
 * Article annotations - annotate paragraphs with discussions (opt in experience, requires account, powered potentially by Flow)
 * Read more - More articles, add to mobile web, improve relevancy
 * New subsite- WikiFactoids cards - provide new interface on wikidata (not MobileFrontend) that surfaces interesting factoids that fit on a single page without scrolling designed for sharing (link to from mobile site)

All Platforms All link previews & Hovercards:
 * Swipe right to view the term in sister projects (Wikivoyage, Wikiquote, Wikidata), if any.
 * Infinite "Random" (with "good" - e.g., http://en.wikipedia.org/wiki/Wikipedia:Good_articles/all - or top N thousand less xxx articles, or both good and popular, articles) scrollable card list (like link preview / Share a Fact)
 * perhaps adding topic or interest filter to this
 * Note we have a pending patch for Gather that does this at Special:Gather/random
 * Sub page of Special:Gather/random/ returns pages Random in a provided category.
 * Reader centered recent changes feed customised to current location and most actively edited.
 * Reading queue (utilise Gather architecture)

Off-platform (other sites and apps, browser- and OS-level integration):
 * Package our link preview/Hovercards functionality as a standalone JS library to fetch and show Wikipedia summaries / Wikidata descriptions / Wiktionary translations / Commons images for a given string.
 * Develop WMF OS integration/browser add-ons that do this?
 * Make it easy to embed Wikimedia content (images, videos, quote a fact) - show example HTML, maybe become an oEmbed provider?
 * MediaViewer already shows embed HTML for an image
 * Make a 'Discover' page which provides random and nearby functionality Allow users to see titles, image of articles and extracts and click through to read full article.
 * and in future...
 * recently changed content/new content).
 * content i've edited
 * Hell yes! Phab task: https://phabricator.wikimedia.org/T93327 Prototype http://invis.io/F82S59VZU
 * continuity: when you click share-a-fact link you get taken to page that highlights or directs you to that text!
 * Highlighting of text (saved per user, shareable)
 * Random with categories
 * "Saved pages" / "watchlist" / "gather", whatever. I want to "bookmark" pages to read later, offline, and be able to reference that list on multiple platforms
 * Push notifications for watched articles
 * "Subscribe" to pages while viewing them, and notify the user when a new revision has been published
 * Surface quick facts, make them easy to share
 * Break up article into easily browsable chunks - images and quick facts together
 * let users browse/discover by interest categories
 * help users find content from other projects: quotes, source, etc.
 * Promote Commons content related to article
 * Sync with search & discovery plans and further promote map content on side menu or as suggested article

= Theme Four: Build trust and attachment via an excellent experience by fixing UX debt across our properties =

iOS
 * users can't find within article: make 'find-in-page' possible (duplicate)
 * Custom UX for tablets
 * Conventional "stack" navigation on iOS (including edge gesture support)
 * Simplify navigation on apps
 * Dark Mode. Please :)

Android
 * Custom UX for tablets
 * Simplify navigation on apps
 * explore new skins
 * Improve Offline experience
 * Open saved page from link when offline and linked page is saved
 * Sync saved pages (using Gather API)
 * Multiple lists (ie. Gather for apps)
 * The additional search box in the saved pages screen might be clearer if it replaces the "Search Wikipedia" field in the action bar. It seems particularly out of place when no pages have been saved because it just says "Search" with no additional context.

Web
 * Begin researching skin system revamp with primary goal of describing a "better" skin system that allows easier skin creation and responsive CSS
 * Better support for extensions adding widgets to skin in a manner that gives the skin control of presentation (eg Echo, watchlist enahancements, etc)
 * Better support for template based skin layouts
 * Easier to make and distribute a skin in general
 * Better support for layouts that aren't just Monobook/Vector with a small amount of CSS/JS added on
 * Skin-specific user options https://i.imgur.com/yUtQ2vf.png
 * (perfect world) Ability to replace MobileFE with a non-traditional devices skin
 * Will require collaboration with other teams and the community
 * At least one RfC would be needed
 * Provide tools for the community with which they can transition to semantic markup and better handle device diversity
 * Start work on https://phabricator.wikimedia.org/T483 (RfC: Allow styling in templates) which could unblock community transition from tables to semantic markup for many widely used templates
 * Global templates and modules
 * Decouple image presentation details from wiki markup - https://phabricator.wikimedia.org/T90914
 * Explore the possibility of wikitext markup for handling over control over sections of content to the skin (like https://phabricator.wikimedia.org/T25796 but bigger / more generic; Winter had some great design ideas that could be implemented with such a feature)
 * Provide CSS/LESS building blocks for responsive design e.g. https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system
 * Provide better ways of testing changes (e.g. extend the TemplateSandbox extension to user/site CSS/JS)
 * (crazy idea) Provide mobile previews
 * (not a crazy idea)
 * see https://phabricator.wikimedia.org/T85587 . In case the Editing team doesn't prioritize a production-quality solution soon, how about instead hacking together a mobile preview button as a gadget for power users who are specifically interested in helping to improve the mobile view of articles and templates (while editing on the desktop site)?
 * Revisit http://unicorn.wmflabs.org/winter/ for design ideas to be salvaged
 * Option for permanent TOC in sidebar like http://www.wikiwand.com/en/San_Francisco
 * Bring back clickable (and shareable) section anchor links https://phabricator.wikimedia.org/T18691
 * Expand/collapse toggle on mobile web to support Find in Page
 * surface TOC on mobile web (https://phabricator.wikimedia.org/T97581 )
 * Introduce architecture for different mobile skins, launch with a dark skin and a Vector/Minerva clone.
 * Explore new skins. On desktop, we need to have the option of a simple and cleaner interface that make it more comfortable to browse and read
 * Get a the collapsable infobox in mobile web as well

All Platforms
 * Update menu and icons for a more modern interface [caveat - needs Editing team buy in]
 * User testing major experiences, update problematic workflows
 * show the name of the section currently being read in some kind of header (the Wikiwand app appears to be doing this, see http://thenextweb.com/insider/2015/03/11/how-wikiwand-plans-to-make-money-while-building-a-better-wikipedia-experience/ ) or highlight current section in sidebar TOC (see desktop section above, the Wikiwand desktop version does that: http://www.wikiwand.com/en/San_Francisco, our apps' slide-in TOC does it too)
 * How do we see a seamless app/web browsing experience ?

= Theme Five: Improve developers' ability to develop features quickly and reliably to serve readers across desktop, mobile web and apps =

iOS
 * Achieve CI MVP
 * run tests for patches in code review
 * deploy builds in response to merge to master
 * start investing in automated tests
 * catch visual regressions
 * verify functionality across many languages in parallel

Android
 * Copy the iOS team's CI objectives :)

Web
 * start work on bring minerva experience to desktop to avoid having two separate code bases

All Platforms
 * Continue to improve the API
 * Facilitate writing automated tests (unit & integration) which can verify functionality against a set of fixtures or generated pages
 * write search APIs to get [popular|any] articles across various languages
 * ability to curate list of test articles
 * custom generators for writing MW property-based tests
 * Increase developer confidence
 * Get to Continuous Integration MVP for apps (run tests on patches, automate integration tests)
 * Publish code coverage reports for PHP, JavaScript (Objective-C, Swift, etc?) (https://phabricator.wikimedia.org/T100294 )
 * Run a suite of browser tests against each patch (MF - https://phabricator.wikimedia.org/T100293 )
 * Put all features behind feature flags
 * Let half-done features roll out disabled in prod, enabed in beta (for sign off)
 * Make feature flags more flexible (dev only, 1%)
 * Detach feature flag configuration from source code?
 * Improve error collection/reporting
 * Finish AuthManager to allow for a more consistent login experience between API (used by apps) and web, and to enable future security-sensitive features such as two-factor auth. (is this relevant to all platforms? - yes)

= Other =

Q: How do we engage differently with contributors vs. readers (there are perceptions that readers are just contributor who have not done so, yet) Q: Supporting Readership for readership's sake ?
 * Differentiating readers from active contributors through community dialogue


 * Start thinking about / experimenting with metrics which better reflect our actual impact. Reading about pokemons and early recognition of preventable disease does not have the same empowering effect on people's lives; our current metrics of click counts and session lengths cannot handle these kinds of differences. If we optimize the New York Times for clickthroughs, we end up with Buzzfeed; we do not want that for Wikipedia. We should figure out how to measure article value, not just article count.
 * This would probably involve the development of better feedback mechanisms, which is useful for a host of other things


 * What would be needed to have Wikipedia apps? (As in Facebook Apps https://www.facebook.com/help/493707223977442/, not mobile apps.)
 * Right now people can install custom JS via gadgets, but the developer experience is abysmal, there is no central management, the enable/disable interface is poor, and they have no backend component
 * Gadgets 2.0 is the mostly-written fix for that - https://github.com/wikimedia/mediawiki-extensions-Gadgets/tree/RL2
 * We have OAuth, which is a big part of the puzzle, but the user experience needs to be improved
 * Backends can be created easily(?) via Labs, but there is no easy way to store user data in a managed, privacy-sensitive way
 * (crazy idea) trust model for third-party tools? https://phabricator.wikimedia.org/T55046#1310718
 * Better support for user pages in apps and sharing user page content.
 * Share mobile app JavaScript enhancements (some discussion on this already).

=Q2= Readership Q2 Planning Brainstorm

Goal: Reading team members start to asynchronously gather solutions to user problems within the areas identified below in preparation for brainstorming review and refinement sessions. Ideas should be new ideas that are *in addition to* ideas from Q1 brainstorming (https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation ).

Resources:


 * Some baseline data from Q1: https://www.mediawiki.org/wiki/Reading/2015-2016_Q1_Planning_Data
 * Q1 Results Distilled: https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation
 * JK's rough stab at classifying Q1 results (if you use filter, make a copy first, as it will impact how everyone else sees it): *https://docs.google.com/spreadsheets/d/13iUPI64QnWVvPfDfoDTQG1F9wvHxxfKJ3KfphZK04fc/edit#gid=0

Themes
Aside from strategy, no themes this quarter!

Evaluation principles
Web: Ship something (i.e biased against an experiment or exploratory feature, outside of strategy work) Do one of 3 things:
 * 1) Maximize known impact (serve a user need)
 * 2) What problem are we solving for the user?
 * 3) What theory gets us from this idea to the user being happier?
 * 4) What is the user story?
 * 5) Put infrastructure in place to understand users better
 * 6) Put in infrastructure to improve engineering capacity
 * 7) Does it increase velocity?
 * 8) Does it reduce risk?
 * 9) Does it improve the user experience?
 * 10) Des it increase engineer happiness?
 * 11) Free up design and product for strategy and prototyping (avoid intensive front-end and community engagements)

Examples
Example for user value: “Enable saved-pages for web” The theory here is that:


 * there is a significant number of users whose experience is currently limited by connectivity - “I can’t reach wikipedia when I need it most”


 * these same users know or can be taught how to save pages


 * this is population is not better served by our app

All of these three must be likely for this to be a reasonable endeavor

Example for engineering capacity: implement automated visual testing (not all of these have to result in ‘yes’)


 * 1) does it increase velocity? yes, by reducing manual testing
 * 2) does it reduce risk? yes, by spotting bugs more proactively
 * 3) does it improve the user experience? indirectly, by reduction of bugs
 * 4) does it increase engineer happiness? it varies by developer on an individual level, but it is usually embraced in principle

Questions
= Brainstorming Guidelines: =
 * Nothing is too off the wall or crazy during brainstorming!


 * Suspend judgement: this is not the time to analyze or critique others' ideas. There will be a separate opportunity to evaluate and analyze

Reminder: Effective Q1, Reading Infrastructure is available for approximately one API project per Reading Infrastructure team member per quarter to assist Reading Web & Apps engineers. They should otherwise always be consulted early and added to API and MediaWiki Core patches for code review for Q1 and beyond.

Android
* Quiet crash reporting. * Sending crashes without user interaction will help us capture true crash metrics and bother the user a little less during an upsetting time. **Q: privacy concerns? implementation s,m,l.. ** BG: IIRC android was investigating HockeyApp, which iOS uses. on iOS at least, they provide a client SDK which can ask for user permission to send once, always, or never ** Also, integrating HockeyApp on iOS was small, but getting legal approval & customizing dragged on for a bit. hopefully android would benefit from our legwork in this regard * Improve network architecture * Gutting the old AsyncTask powered design and implementing a more modern pattern will help us be a lot less concerned about networking when building new features, (hopefully) manage our memory and thread resources better, and (hopefully) integrate better as a third party library if we're ever able to break out an API. We shouldn't have to pay tech debt when implementing a new feature that happens to require networking. * Card themed UI   * Many collection views, such as search results and saved pages, would look great using a Material card design. This is especially true for any upcoming aggregator work as well, where it's easy to picture a Google Now like interface that surfaces interesting content from numerous sources. There's strong library support for this functionality, we just need to reach out and use it. * BG: this briefly brought up back-end dependencies. Android is considering content service impl and iOS is hoping to "fix" textextracts to work w/ generators * The Wikipedia Android app is about reading and about search. That search box should look stellar. We can do this by following Material recommendations to make the search bar the toolbar. Best to check out that screenshot. * Brian and the iOS devs recently got some big accessibility contributions. We should strive to be a model for accessibility design best practices. * BG: We haven't gotten contribs yet, but hopefully soon...   * where are the gaps? that needs to come before we can prioritize, i think * idea raised of separate accessibility app * Recently Brian and Ori shared a blog about the perils of hamburgers. It really changed the way I felt about it, even on Android where the pattern is popular. I'd love to see what the app would like using tabs or some other no hamburger menu approach. Lets see how iOS does with its tab bar! *Q: perhaps worth waiting until iOS's vegan menu launches and see what we learn? * Aggregator MVP * Even those iOS devs have a content aggregator. Studies show that users love to read random data. Even the most minimal implementation attempt to surface interesting data to users would be a huge win. * Sounds like feeds to me   * Cross platform synchronized watch lists. * Saved pages are great but nothing compared to synchronized article management across platforms. * Search personalization (currently: recent searches, current results, and sometimes a suggestion; new: current implementation + previously viewed articles) * This might leverage some similar mechanics as content aggregation by favoring a mixture of search results from backend, on device sources such as history and saved pages. * Prototype a Dart / Sky MVP * Google has been iterating their sample Android app written in Dart and leveraging the Sky SDK. Since Dart compiles to JavaScript, we should keep current with this promising technology. * Build a focused feature library for internal and external consumption; maybe Wiktionary or link preview blurbs * This is an exercise to see if we can make a nice Java API that people actually want to use towards the end of shipping an SDK. * Print from app (T92266, T107684; is this more or less useful internationally?) * The app leverages a built in browser which supplies a print API. We should pick this low hanging fruit for people that still prefer or need paper. * Split Nearby into a separate app * This is really a brainstorm idea. I have mixed feelings about nearby and maps cloduing the focus of the main Wikipedia app. I do think Nearby will be excellent for surfacing interesting aggregator content. * Distraction free / Zen mode * Tap a button to remove everything but article content. Akin to Google Books or Kindle reading modes. *Q: evidence of user desire? night-mode did not get any traction, despite constant requests for it   * Wiki me (user page centric feature or stand alone app, allows users to add wiki content to their page like "places I've been"; User:Deskana is a good example) * There's so many neat user page features. We should help people be more involved in Wikipedia by getting them started on a topic they're most comfortable with: themselves. ** see Web's "identity profiles 2.0" below * Custom Chrome tabs (in beta right now but might be out by Q2) * We should keep users in app even for external links. * automatic app backup (make sure we don't backup too much to Google's servers -- sensitive data) * new runtime permissions **Q: user value?
 * SN: As a user, I want my bugs fixed but I don't want to be involved. As a developer, I want accurate crash numbers.
 * SN: As a user, I want a fast app that doesn't crash with out of memory errors. As a developer, I want an improved networking architecture that doesn't require maintenance or special hacks when implementing unrelated features.
 * SN: As a user, I want to use apps with modern Materal card themed UI. As a developer, some of this is low hanging fruit we can implement with minimal tweaking by design.KH
 * related to ^ JK: content service--> cards for external app/web consumption (nytimes, e-readers, blogs etc), explore longpress for definition opportunities for chrome/safari
 * SN: As a user, I want to use an app with clear purpose, for the Wikipedia Android app a dedicated search surface (see T108728 and screenshot)
 * SN: What happened to Google Now integration? (Google still hasn't opened this up beyond a few select partners)
 * SN: As a user, I want an accessible app regardless of who I am
 * SN: As a user, the hamburger menu confuses me. KH
 * SN: As a user, I love data to find me not the other way around
 * SN: As a user, I like my data to be kept safe and synchronized across all my devices.
 * SN: As a user, I want data tailored to me.
 * SN: As a developer, we should keep up with the latest app development technologies.
 * SN: As a developer, the most likely contributions come from developers using our code.
 * SN: As a user, I want to be able to print content from the app.
 * SN: As a user, I like purposeful apps.
 * SN: As a user, I like content not UI.
 * SN: As a user, I feel most comfortable and most enjoy self centered activities.
 * SN: As a user, I am confused by jumping in and out of apps.
 * BS: get ready for Android 6.0 (if not done already -- the next two are must haves IMO): []+
 * M: Again and again, rethink users in app feedback mechanisms (something like https://instabug.com/how-it-works). We already have tickets for this: https://phabricator.wikimedia.org/T97237, or  https://phabricator.wikimedia.org/T94043
 * Q: do we have a good system for reviewing feedback yet?   With a new system, the whole workflow should be more efficient.  Part of this already is the quiet crash reporting that SN mentioned above. If we are worried about our efficiency with handling feedback, the lack of enabling users to talk to us, is just as bad in the user's mind.  Both fall under being ignored.
 * DB: Wikipedia Lite app
 * DB: Rework main landing page (natively), with relevant content+
 * reason not to wait for iOS results?
 * DB: Geo labels/buttons where possible (pin icon in Lead Image, Link Preview, etc)+
 * DB: Infoboxes populated from Wikidata+
 * DB: Infoboxes populated from Wikidata+
 * DB: Designs for Tablets!+
 * Q: % of users impacted? <-- Everybody! Good tablet design means good landscape design. hah (Not a joke. Phone landscape mode has _many_ of the same challenges and same solutions as tablets. The path to good tablet design is paved by good landscape design.)
 * DB: Native drilling into / exposition of disambiguation pages


 * BG: Don't we already support for OpenGraph? http://ogp.me/
 * It's not in the tags from what I see.

iOS
Trending articles into feed - most popular overall, popular related to your interests, popular near your location, most edited, etc. Impacts all users when they first open the app++
 * KH: As a user I want to see articles that are popular with other readers and related to my interests so that I can keep up with current, relevant information.
 * Q: 1 question is status of such a 'feed' from analytics/discovery

* Conduct a beta experiment wherein we hack together a "more" button at the bottom of search results which continues the query * SN: I'm for this idea. That said, as a user I rarely find useful search results after the first ten or so results. * BS: Android has this but without a button. We probably should be able to get sme event logging data as to how many time the app had to update search results. * BS: Android has that for history and saved pages * Measure how many times the app downloads the revision of an article it already had * Try setting maxage on requests * Use anomie's newly added ability to add etags to an action module's response (i.e. etag mobileview responses) * Switch to RESTBase or mobile content service and get etags ** BS: I highly recommend storing etags when using the mobile content service. * Remove redundant fetch when we're redirected * Progressively download article content *Q: there might be data on how many iOS users are on a pay-as-you-go plan or how much this impacts their app choices. *Q: would be good to know our average amount of data usage per session to back up the supposition * BG: All of these would (ideally) be backed by a data-gathering phase, so +1. There are various data points we can gather in dev-run scenario tests and/or production logs. * SN: this is awesome! The Android platform has great per app data usage tracking. I don't know if we've used it much to ensure we're using as little as possible but it is something we're thinking about for the content service. * Multi-threading * Relational storage * Notifications (what does this mean?) * This will help simplify codebase and prevent known performance bottlenecks. Also prep codebase for more advanced features, reduce bugs, etc. * BG: As a user I want a quick and easy way to report bugs * With screenshots/video and record of previous user actions (all w/ their permission) (see lookback.io) * No need to get different HTML w/ new image src URLs * Easier to key requests in the cache * Bonus: ability to dynamically fetch low, then high-res pics (not being limited to the resolution initially provided by API/content) ** see Web's "image zoom (build a tile service) T77151, T105789" below * App doesn't respond to OS callbacks to use Wireless connection when available after app has been suspended ** beware cell data charges versus wifi JK: As a user, I want to mark a sentence or more that either needs citation or has some other issue (tell me more/bored/needs citation) and I get instant positive feedback for having helped identify issues for editors. It also helps tailor my feed... MH: SPDY - bearND tells me android is already configured to use SPDY - should be alble to use on iOS relatively easily.
 * BG: As a user, I want to paginate search results?
 * BG: As a user, I want to be able to search/filter (basically any list) my history, saved, recent searches, etc.
 * BG: As a user, I want the app to use less of my wireless data+
 * BG: As a developer, I want a robust data layer which supports:
 * M: Rethink users feedback mechanisms, for example: https://phabricator.wikimedia.org/T94043
 * BG: As a developer, I want to request data w/ different image resolutions w/o missing the cache
 * BG: As a user, I want my saved pages to be downloaded in the background
 * there's a ticket on iOS eng backlog for adopting SPDY: https://phabricator.wikimedia.org/T107756
 * also work looking into gzipping

MH: deploy wikidata description editing proof of concept from lyon hackathon in some limited fashion for testing https://www.youtube.com/watch?v=6VblyGhf_c8 (note: this does not necessary have to conflict in any way with autogenerated descriptions) Yes,"write a better description than this robot" :) Ideally you'd have an option to click on words in the AutoDesc and be able to edit the underlying Wikidata facts VB: As a user I want to share (to social networks?) this beautiful image of Frida Kahlo that is on my screen. ( Allow users to share images or entire galleries, limit to n. In order for this to make sense for a reader who sees the image our of context, replace commons descriptions with captions, combine with first sentence of article ).++  ** I recently watched a bit of a scuffle over attribution of images posted to social media. It could be interesting (but probably out of the scope of this) to use sharing to boost contributions to Commons for that reason.

Already in road map
https://docs.google.com/spreadsheets/d/1j5UuJF-PYqnHwjVInqVK6kLyttqbOz64p4zkPGQYQeA/edit#gid=0

* Using un-specced DOM selectors for things like: parsing images, sections, hatnotes, page issues/disambig, etc. * Let's switch to the documented, specc'd Parsoid DOM and use selectors we can rely on! +1
 * BG: (XPlatform/Stretch) As a user, I want to save/favorite/bookmark a page on my mobile device, and read it later on another device. (in road map)+
 * BG: As a user, I want to be notified when an article I've save/favorite/bookmark-ed is updated (in road map)+
 * BG: As a a user, I want to provide offset data for lead images or "as a developer i want to be able to get/set "main focal offset" for any image at any resolution so i can crop all images intelligently" (in road map)
 * see Web's "WikidataPageBanner extension" below? doesn't currently capture offset but if it's widely used it will have lead image
 * jdlrobson mentioned WikiVoyage's banner images. looks promising and that's kind of the idea. need to figure out how to easily manipulate it from apps and back it w/ (validated) structured data. it's currently done in wikitext :-/
 * BG: As a user, I want to upload images (in road map)
 * BG: As a user, I want to be able to search for text within the page (in road map)
 * BG: As a developer, I want a reliable way to extract data and content for native rendering (in road map)

Web
Related article cards shown at bottom of every article page. Has shown great engagement numbers on apps. Impacts any user who scrolls to bottom of a page on Wikipedia.
 * Read more - As a user I want to see related articles to the current article I've read so that I can continue learning about topics I'm interested in.
 * mobile web?
 * desktop web?
 * To talk about: Editor capabilities to suggest related or interesting articles? (maybe just search keyword boosting? [assuming this is driven by search])
 * Do we want to explore different recommendation engines or use only morelike? - apps also tried cirrus search, morelike performed 20% better


 * Address MobileFrontend's #technical-debt issues
 * Publish RFC for starting community conversations about how to improve MobileFrontend.
 * Split UserProfile, Nearby, Mobile watchlist, MobileView to separate extensions. Clean up MobileFrontend.
 * Continue merging beta features into stable. Remove the differences between stable and beta.
 * Make Minerva appear in available skins to increase awareness and contributions


 * Wikidata page banners to commons and possibly other smaller wikis.
 * Integrate WikidataPageBanner extension with MobileFrontend - Done https://en.m.wikivoyage.org/wiki/London
 * Remove "banner image" (read: lead image) module
 * Q: so a wiki's default pagebanner on articles would appear the same as the mobile experiences' article lead image?
 * Q: editable in VE? [needs work but can work]
 * Q: microcontribution "game"?
 * TODO: Make sure Design has had eyes on it!?
 * TODO: think about ways to measure user value
 * TODO: Could we enable just on user pages - get people used to them there?


 * Wikipedia lite web app for FirefoxOS and Windows phones
 * Approx 4K fresh sessions per day at last check on the existing FFOS app
 * TODO: % on windows OS / windows mobile versus potential (requires examination of entire Windows app ecosystem)+1 Windows Phone only? If so, it's dead.


 * Push notifications for article of the day on Wikipedia.
 * Trending articles would be a great type of push notification
 * Q: Is this something that we'd have to do inside of Wikipedia.org? nope could be a subdomain push.wikipedia.org or even pushwiki.org or even push.mydomain.mytld
 * Q: is email a better channel for this sort of thing? seems like a basic first step that is less invasive and/or an automated twitter feed?
 * existing IFTTT triggers can do both email and twitter +1 ( http://blog.hatnote.com/post/124069724187/wikipedia-and-ifttt-a-technical-guide#daily_triggers )
 * q: I guess the question is should we be doing these sort of things or do we build apis to support them. Although some exist already we can give greater visibility with our brand and impact more people's lives. (e.g. loads of people i know do not know IFTTT
 * A: Yes, pushipedia and IFTTT should share a trigger server (https://github.com/jdlrobson/pushipedia/blob/master/index.js#L122 and https://github.com/slaporte/ifttt/blob/master/ifttt/triggers.py ). Reading team can do the push notification in the browser.


 * If article appears in a Gather collection, show that collection in article footer
 * all collections or a random one?
 * Top collections?


 * Mobile web: Improve Table of Contents - show subsections, thumbnails of images in that section
 * Moreeeee images. Impact on performance? Impact on engagement?
 * Wouldn't it make more sense to have the list of thumbnails under the TOC? Easier to read text and see images at a glance.


 * M: [Experiment] On mobile, examine the idea of (X min read), like what Medium does. Might be something that furthers engages rabbit hole readers.  Could be a category.  (see the 4min read on top here: https://medium.com/code-for-africa/the-opportunity-for-african-newsrooms-mobile-but-not-online-2b674d9d399b). It helps us build a persona for those who come to WP without searching for something specific.
 * Read more feature (see above) could show this. Yup. Or the once proposed collections feed in random, once in place for mobile web.


 * Explore feature [Replace Nearby and Random with Gather based lists to engage new users by exposing content=> more page views => push to stable based on evaluation e.g. https://en.m.wikipedia.org/wiki/Special:Gather/explore/random / https://en.wikipedia.org/wiki/Special:Gather/explore/random +1
 * include link to random gather feature?


 * "Take this page offline" feature - explore offline reading capabilities.
 * Is this only worth on mobile, or both desktop and mobile? (Investigate this question with data/surveys?)
 * the big unknown for me is how we educate/promote this feature to make it usable to internet noobs--I can barely use gmail offline <<gmail has offline...? < Yep. It's not the best. hm.
 * could also do "Make this Gather collection available offline", or "Gather collection of my offline pages"


 * Give the editors of our projects an identity profiles 2.0 (can we use phabricator for profile pictures for example?)
 * link please for identity profiles 1.0? user pages :) (Like https://en.wikipedia.org/wiki/User:Jimbo_Wales )
 * is this https://www.mediawiki.org/wiki/Structured_profiles ? yeh that too.
 * is this more like template, e.g. https://en.wikipedia.org/wiki/User:Brion_VIBBER

M: Give guided tour to "How Wikipedia works" in general?
 * JK: give users a guided tour of wikipedia via Gather. improve gather to encourage more contributions and make collections more discoverable:
 * incorporate feedback from design research on creation flow-->to remove barriers to succesful creation
 * allow 'like' or 'follow' collections-->positive feedback to creators, ways to surface popular collections
 * allow rank ordering or item-level descriptions-->add more editorial personality to collections


 * JK: link preview, hovercards


 * Build a proper feature switch framework in core (some use cases: staged rollouts, A/B testing, BetaFeatures for anons)
 * something for our CTO or Chief Infrastructure Officer to do for us :)
 * all teams are reinventing this infrastructure. We should do it.
 * There's a thread in mobile-l about this -- I'll try and dig it out: https://lists.wikimedia.org/pipermail/mobile-l/2015-January/008498.html
 * This doesn't include Greg G's response but he's interested
 * Yeah this doesn't exactly seem like Reading (web?)... more Infrastructure (Reading?)? Could it be a collaboration? Somebody has to do it. We can be those ones.
 * It's a cross-division concern but Reading is hit worse by it, Editing gets by with BetaFeatures
 * Define "hit worse"
 * If we assume a large portion of "readers" are anons and we have no way to deliver multiple user experiences to anons, we are impacted more than say editing where most users are authenticated and we have the betafeature functionality to deliver divergant experiences to them (including % of new account auto enroll) [bd808]
 * I see your point. However, we have successfully delivered divergent experiences to anonymous users for the duration of an experiment before. It required more rigour when designing and deploying the experiment (speak to Aaron Halfaker about the Growth team experiments) [phuedx]


 * collect article engagement metrics (how much time do users spend on the page? how many users scroll down? how many users scroll down to the bottom?) +100 again, helps with building real personas.
 * via event logging? yes


 * extend quicksurveys to develop deeper knowledge of readers/refine strategy
 * Aren't external surveys meant for this kind of thing?
 * right now external surveys take a whole lot of work and several months, + recruitment cost +...this might be a way to get some quick answers to specific questions sooner
 * I think (but have no concrete data on this) users are more likely to answer a quick survey if they don't have to leave the page
 * My guess is a blend of types of surveys is best +1


 * image zoom (build a tile service) T77151, T105789
 * like yurik's https://github.com/wikimedia/maps-tilerator ?
 * MaxS said the maps tile service is not useful for images
 * Would need RfC and probably hardware unless it could fit on the existing imagescalers
 * A top to bottom revamp of the imagescaling system would be stellar (eg split up the image things in core to allow replacing local actions with service calls; build service)
 * How would this be exposed to the user? Some way to zoom and pan a huge image that talks to the server, instead of viewing the entire big image locally and using your browser's image features
 * by adding zoom controls to MediaViewer and/or the file page. I would expect that to be the easier part, standard libraries exist for it. (e.g. http://openseadragon.github.io/ )


 * Gather as desktop beta feature +100
 * A side effect of this would be reducing MobileFrontend tech debt
 * MobileFrontend already has custom watchlist code that could be removed.
 * Various bits of Gather depend on MobileFrontend e.g. overlays - would force us to resolve these issues / integrate more with oojs ui


 * Multiple watchlists
 * Desktop and mobile On mobile: https://en.m.wikipedia.org/wiki/Special:GatherEditFeed
 * On desktop (looks like Vector): https://en.wikipedia.org/wiki/Special:GatherEditFeed
 * sidenote: Thus the need to adapt it to Desktop
 * Clean up MobileFrontend watchlist debt
 * Using Gather infrastructure
 * Maybe replace watchlists with Gather collections?+1000
 * Maybe replaye Gather collections with wiki pages :)
 * Refactor desktop watchlist to be usable with other data sources
 * isn't this an editing feature?

For our readers, do we want to take some steps towards letting https://en.wikipedia.org/wiki/Wikipedia:SVG_help SVG render as clean SVG and not as PNG?? (Some improvements happened, https://phabricator.wikimedia.org/T63443, but we need more)
 * Let SVG render as SVG

This was awesome. you guys are awesome.

Other
- spage: productize and i18n Magnus Manske's AutoDesc (ought to be a tiger team with Discovery) - AutoDesc is a massive force multiplier for WMF mission that would dramatically improve hundreds of underserved Wikipedias. - use it as the stub handler and search result provider for all wikis, - consider using it for existing Mobile descriptions use cases when there's no wikidata description
 * Dmitry has taken the codebase https://github.com/dbrant/wikidata-autodesc, seems to be consensus for RESTBase to serve this