MediaWiki

Reading/Quarterly Brainstorming

< Reading

An archive of team brainstorming in Q1 and Q2

Q1

edit

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

edit
  • Where does offline Wikipedia and Wikipedia Zero fit in the below?


Brainstorming Guidelines:

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

edit

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


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

edit

Android - App indexing

iOS N/A

Web

Question: <i'm not sure SEO is a big problem for Wikipedia and I'm not convinced this would help get us more readers... I feel there are more gains to be had by exploring encouraging sharing of content (i'm not talking Like buttons) but it would be interesting to explore if we put a share button on the page (and say it only defaults to email) whether people click it or not> https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Share_pages_on_Facebook.2C_Twitter_etc.

  • 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?
  • 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

edit

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 <listen to an article> 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 <listen to an article> 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 <as a side browsing activity, and part of understanding how WP works>?
  • 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/<category name> 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.
  • 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

edit

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

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

edit

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
  • 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

edit
  • Differentiating readers from active contributors through community dialogue

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 ?


  • 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
    • 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

edit

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:


Themes

edit

Aside from strategy, no themes this quarter!

Evaluation principles

edit

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

edit

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

edit

Brainstorming Guidelines:

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

edit
  • 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.
   * 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
  • 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.
   * 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.
  • 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
   * 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
  • 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)
   * 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.
  • 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
   * 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
  • SN: As a user, the hamburger menu confuses me. KH
   * 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?
  • SN: As a user, I love data to find me not the other way around
   * 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
  • SN: As a user, I like my data to be kept safe and synchronized across all my devices.
   * Cross platform synchronized watch lists.
   * Saved pages are great but nothing compared to synchronized article management across platforms.
  • SN: As a user, I want data tailored to me.
   * 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.
  • SN: As a developer, we should keep up with the latest app development technologies.
   * 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.
  • SN: As a developer, the most likely contributions come from developers using our code.
   * 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.
  • SN: As a user, I want to be able to print content from the app.
   * 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.
  • SN: As a user, I like purposeful apps.
   * 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.
  • SN: As a user, I like content not UI.
   * 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
  • SN: As a user, I feel most comfortable and most enjoy self centered activities.
   * 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
  • SN: As a user, I am confused by jumping in and out of apps.
   * Custom Chrome tabs (in beta right now but might be out by Q2)
   * We should keep users in app even for external links.
  • BS: get ready for Android 6.0 (if not done already -- the next two are must haves IMO): [[1]]+
   * automatic app backup (make sure we don't backup too much to Google's servers -- sensitive data)
   * new runtime permissions
  • 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+
**Q: user value?
  • 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 <meta> tags from what I see.

iOS

edit
  • 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.
   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++
  • Q: 1 question is status of such a 'feed' from analytics/discovery
  • BG: As a user, I want to paginate search results?
 * 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.
  • BG: As a user, I want to be able to search/filter (basically any list) my history, saved, recent searches, etc.
 * BS: Android has that for history and saved pages
  • BG: As a user, I want the app to use less of my wireless data+
 * 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.
  • BG: As a developer, I want a robust data layer which supports:
 * 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)
  • BG: As a developer, I want to request data w/ different image resolutions w/o missing the cache
 * 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
  • BG: As a user, I want my saved pages to be downloaded in the background
 * 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.

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

edit

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

  • 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)
 * 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


Web

edit
  • 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.
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.
    • 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.
  • 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.
  • "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"
  • 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

M: Give guided tour to "How Wikipedia works" in general?

  • 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
  • Let SVG render as SVG

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)

This was awesome. you guys are awesome.

Other

edit

- 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
Retrieved from "https://www.mediawiki.org/w/index.php?title=Reading/Quarterly_Brainstorming&oldid=6413851"