Wikimedia Foundation Annual Plan/Quarterly check-ins/Audiences2 Notes October 2017

Present (in the office): Toby, Eileen, James F., Heather, Grace, Josh

participating remotely: Maggie, Lydia, Corey, Joady, Erica, Olga, Michael H., Tilman, Adam Baso, Anthony Borba, Baha, Bernd, Carolyn Li-Madeo, Cooltey, Deb, Eileen, Mikhail, Natalia, Nirzar, Ramsey, Rita, Joady, Sharvani, Katherine (for part of the meeting), Anne, …

Slide 1

• Toby: Good quarter, want to thank self as slide advancer, Michael H as notetaker, Grace for slides/timekeeping/Josh: MCing

Slide 2

• JM: Going to skip the Readers strategy overview slides since they've been the same for ~2yrs. Also we're looking toward the next phase of our strategy in light of the broader movement strategy.

• Olga: Want to review page previews feature. Falls under increating retention.

• Relased to all Wikipedias inc. en and de, performing an a/b test on de.

• Due to delays on PDF rendering project we're holding off on further work, will regroup in jan

Slide 3

• Still some bugs affecting EventLogging which affected the A/B test; now fixed.
• However, we were able to get some preliminary results. we want to repeat the a/b test and get more in-depth results.

• Initial resulsts show that v. few users are disablling the feature; they like page previews.

• ~13-20% of page views have at least one card viewed.

• Per-session data coming in future A/B test.

• Also performed a fundraising test; we found there was no negative effect of the feature on fundrasing

Slide 4

• Lots of people really excited. (examples of feedback on Twitter)

Slide 5

• Our goal for this quarter was to replace our PDF rendering workflows. Wanted to replace OCG with Electron. We had lots of trouble from the beginning and weren't able to replace it this Q, although we sunset OCG.

Slide 6

• OCG was released in 2015, but had issues from the beginning. Later, the German community became very interested in PDF rendering, including table rendering (which OCG didn't support). During this time they built out the Electron renderer, and it worked side by side with OCG.

• Eventually the Readers team took over responsibility for transitioning from OCG. Readers web began working on this transition toward the end of the previous quarter. Hoping that Electron would be the solution.

• Mid-to-end of last quarter, Readers Web learned from Services that Electron was insufficiently stable to handle the traffic it was getting. Since then we've put our other work on hold to find a new solution for PDF rendering.

Slide 7

• ( Olga: Where are we now?

• We did manage to sunset OCG, and Electron is currently running as the alternative. This works for single articles but does not work for multi-article collections (eg Books). We're using Electron for single pages, and looking at replacing it with headless Chromium which is hopefully more stable.

Slide 8

• OCG: what went wrong?

• Sunsetting features has been difficult generally across the foundation. This project involved many different teams, which meant that convos were split up among many different channels. Difficult to find the single source of truth.

• Ownership was also unclear. Did Readers web team own just the UI aspect, or the whole service?

• We didn't do any research on usage, just assumed that we would support existing functionality at all costs. (e.g., book creator, which has fairly low usage.)

• Also didn't do a lot of research and testing on Electron after it was chosen by WMDE. Just accepted it. Should do more.

Slide 9

• Lessons learned

• Doing up-front research on both product and tech questions is important
• Clear ownership is important
• Identifying all stakeholders is important (there were teams we didn't realize were relying on us)

• There is a Sunsetting Working Group that's working on these issues and how to avoid them in the future. There will be a proposal from them up soon.

• Toby: Thanks for Readers Web and other stakeholders for this work. In the tune-up it also came up that we need a better focus on sunsetting.

Slide 10

• Olga: We've also been working on reinventing the mobile website (codenamed "marvin")
• Next quarter we'll focus on both dev work and communication for this. We'll do an RfC with TechCom and a roadmap for stakeholders.

Slide 11

• Corey: 10 years ago we had a single client: desktop web. These days we much support many different clients/contexts. Native apps, mobile and desktop, older vs. newer browsers. And certain experiences have both server- and client-side components. We also have to deal with intermittent network acces.

• The Page Content Service (and our broader investments in Reading Infra) are meant to address this.

Slide 12

• This is a simplified diagram, forgive glossing over details to establish a baseline.
• This diagram is just to establsih a baseline. How it's worked for years: Mediawiki at the core, then skins, extensions, templates etc. for modifying content. At the end would be the desktop browser.

Slide 13

• Where we're at now, it's obviously much more complex (on top of everything that the old slide has)

• An important thing to note is that this all happened organically, with teams buildling for specific use cases. We want to unravel this complexity.

Slide 14

• Here you can see our goals for what the infrastructure should look like. Bottom 3 boxes: we're unifying our Reading infrastructure building on MW, Parsoid, RESTBase. Above that is an adaptivity layer that allows adapting for specific clients.

Slide 15

• Process in designing this service.
• This demonstrates how we've grown as a dept over the last 2 years
• 1) leverage the work of the services and parsing teams on modern infrastructure
• 2) requirements gathering for all existing and planned experiences: get input from users and designers up front
• 3) sharing code as much as possible. (Particularly, since JS runs both client and server side, it helps us share code.)

• Toby: I want to call out that we're working with technology and tech ops; there are spirited discussions going on about the future of our platform and I think it's healthy.

Slide 16

• We're focuusing on three services here:
  • 1) reading lists service (for syncing across clients) was our goal last Q, waiting on security review, now back on track
  • 2) Page Content Service: effort at code consolidation
  • 3) Push notification service
    • we intended to do an RfC this Q., but we're pushing it back for further requirements gathering (and because we pitched in on OCG sunsetting).

Slide 17

• Josh: Android team goal this quarter was supporting the New Readers initiative, offline content for those with intermittent access.

• The goal here was to take a prototype that Dmitry (Android tech lead) had built for loading Zim files (an offline compilation format) in the official Android app. Based in part on a Community Wishlist item from Doc James.

• We learned a lot more about the offline content ecosystem and how to serve users at scale. There's going to be some more work to get it to prod scale. This Q we're going to release a "sideloading" version of the feature and do some user testing.

Slide 18

• The process of getting a pack of content from a server to the client is not just the push of a button. (Table shows the process of how clients pick content on the left, with the process needed moving right until we reach the client.)
• The feature shipped in Q2 will essentially skip straight to the "Reading" (far right column) point. More research is needed on the pipeline.
• We want to respect existing stakeholders while delivering strong user value.

Slide 19

• Thanks to Rita in particular for leading the research in partnership with Anne and Huero.
• They did on the ground research in India and also with "classic" Readers (experienced WP users). The results were pretty consistent: people thought it looked useful but wanted smaller content packs. Note that the Foundation doesn't necessarily want to be involved in content curation.

Slide 20

• on iOS, we focused on improving the encyclopedia experience. Wanted to ship synced reading lists but didn't due to backend delays. We want to release before the holiday season because apps tend to get a bump in installs/users then. (People get new devices.)

Slide 21

• Last-but-one quarter incomplete goal; carried over to last quarter.
• Both apps user top-read for the previous day as part of the explore feed, to show people what others are reading. Jon Robson build an alternative service based on trending edits. We did some research in the US and India and found that actually trending reads were more relevant than trending edits to users.

Slide 22

• Also released dark mode, here are some screenshots of it.
• One of the things I think is neat about WP is some of the neat editorial decisions; the featured article editors have broadened their coverage which has been nice. It looks great in this presentation.

• ?: What is dark mode? A: Dark bg, light text.

Slide 23

• Feedback was very positive, Apple was very enthusiastic. We've been recognized in the press for the quality of the app recently. Best apps for 2017 in PC Mag and Digital Trends. Also an Arabic best of apps blog.

Slide 25

• Deb: Discovery has been in a bit of flux since the tune-up. We've been wrapping up a bunch of tech debt and prepping for the new goals around structured data and apps.

Slide 26

• Search frontend: Jan has been working on this, and Mikhail and Chelsy have been analyzing results on the backend.
• The portion of the goals shown here are completed, Jan will begin working on the Portal now.

Slide 27

• Shows the different things we tested. Sister projects bar on the right hand side (already in production), left hand side results are expanded with thumbnail images and different language versions.
• We did the explore similar A/B test on enwiki twice in 2 different ways. We wanted to show that articles are written in langs other than English. We didn't get much clickthrough, though. This is wrapped up after ~6 mos of work.

Slide 28

• Portal stuff (www.wikipedia.org site) improvements
• Since Aug '15 we've worked to make the portal better. Detect browser langs, etc. Clean up CSS libraries, make things look smoother. We also want to automate some of the displayed stats (article counts, for example). But first, we needed to clear some tech debt.

Slide 29

• LHS is the desktop view, browser language of Catalan is detected by the site and so shown most prominently, and portal title(?)/subtitle and search default to Catalan.
• RHS is the mobile view.

• Toby: Do we know what % of searches the type-ahead satisfies?
• Deb: Not off the top of my head, but will report at Metrics mtg later this month.

Slide 30

• Last thing we've been working on is Maps.
• Paul and Guillaume have been able to make some technical improvements.
• Also got help from Max Semenik.
• Updated the backend to node 6.11 (which the rest of the Foundation is already using).
• Guillaume migrating map servers to wmf-cloud.

• This coming Q we'll deploy the new map style, migrate map servers to the cloud, and talk to the community about these updates.

• I (Deb) also went to State of the Map in Boulder and discussed the future of maps on Wikipedia.

Slide 31

• Shows a map about the Trans-Canadian Highway, which is the kind of thing we'd like to do more with maps.
• A few communities have recently enabled mapframe on their own. enwiki is having a convo about whether to ask for it to be turned on.
• Also been having interesting talks with orgs like MapBox and MapZen.

• Toby: The convo with enwiki has been cordial.

Slide 32

• Ramsey, our new Product Manager (Readers Multimedia), this is his first Quarterly Check-In.

Slide 33

• Three new hires in the team, up from just two engineers to having a desiger, a senior engineer and a product manager – We are now a cross-functional team ready to take on a bunch of new tasks and really get into the nitty-gritty on projects including Structured Data on Commons.

Slide 34

• Major task for the MM team for last quarter was 3D file support for Commons. Long-desired feature in both 2015 and 2016.
• This is a great feature already having a positive impact on user excitement
• Technical standpoint things are mostly done, but with a new file format come new legal issues. 3D files can be 3D printed, so we have to deal with issues like: what if someone uploads a weapon? A patented object? We're working to update the upload wizard to handle these kinds of issues and to ensure that the foundation is covered on the legal front.

Slide 35

• Shows the 3D interface in action. Available on testwiki and betawiki now. We only support the STL file format now (the most basic 3D file format). This gets us going as a start.

Slide 36

• In memory of Bassel Khartabil, the first 3D file we'll upload to Commons will be chosen by the #NewPalmyra project.
• He made great efforts toward documenting and digitally preserving many Syrian monuments.
• He was executed in 2015. We will commemorate his work in the first 3D file uploaded.

Slide 37

• The other thing we're working on is Structured Data on Commons.

Slide 38

• SDC offsite in Montréal after Wikimania.
• We had about two dozen people get together to discuss this very important project and how to make it work. We reached a base level of understanding about what the project needs to do and what needs to be built over the next couple of years.

Slide 39

• First objective is to take on unfinished business from a component started by the Wikidata team, the MediaInfo extension.
• The MediaInfo extension for Wikibase. Somewhat analagous to Wikidata, but specific to media files in Wikibase as we need for Wikimedia Commons.
• It's helpful for the foundation to have more internal developers with Wikibase experience, so that we don't need the Wikidata team to handle all structured data tasks for us all the time.
• We look to be on pace for competion by EOQ so that we can begin feature implementation by Jan of next year.

Slide 40

• My task along with Amanda and some other folk from other teams was to create user stories for Structured Data on Commons. We're doing research to better understand users and what their expectations are.
• We've created 21 core user stories that we believe cover the basic foundation of what structured data means to the people who will be using the feature.

Slide 41

• Shows a map of the product of the user stories process. Different types of users, their relative numbers, and how they overlap.

Slide 42

• Shows an example of a specific user story, in this case a GLAM user. Currently there isn't a way for GLAMs to download structured data for their own databases. We want to ensure that users like GLAMs can easily obtain and user structured data sets that we have.

• Thanks to J. Morgan and J. Curiel as well as strategists like A. Stinson for helping us understand issues like this one.

Slide 43

• Audiences Ops*

Slide 44

• Our role is to improve and ensure effective communication esp. b/w Audiences and Tech, surface any issues and unblock progress. Also drive special programs like TemplateStyles as needed.

Slide 45

• Grace: The thing I spent most time on last Q is defining the role for Natalia's backfill since she moved to an iOS eng role. Had convos with 14 people about what the role should be.
• Proposed an improvement to current SoS format; I also want to pull in feedback from people who don't currently attend
• Shut down CREDIT
• Partnering in designing New Editors workshops, building on research from Abby and Neil earlier this year in Czech Rep. and ?

• This Q:
  • hired 2 PMs
  • Facilitated the New Editors workshops planned last Q

Slide 46

• Lydia

Slide 47

• We started with some usability work. Did usability research so our design team could understand why and how people are editing Wikidata.

• Found some issues:
  • Need to make it easier to see when input is invalid

Slide 48

• Here you can see one of the features we've been working on: a gadget for constraints checks. Help community find issues. We want to make this kind of error more visible and easily fixable.

Slide 49

• Working on documentation, helping the community improve things, mainly at the hackathon and Wikimania people worked on improving onboarding documentation. We're also working on addressing community fears and objections toward Wikidata.

Slide 50

• Data partnerships involves the team helping outside institutions interact with the Wikidata community, find the right people in the community to help them do their thing.
• For two such partnerships we've published blog posts highlighting what people are doing with Wikidata. For example, Humboldt U. is tagging class slides with Wikidata items.

Slide 51

• A lot of work goes into keeping the community involved, happy, and connected. We organized WikidataCon to achieve this goal.

Slide 52

• We've also been working to support other teams on the Structured Data on Commons project. Published a demo system for a feature called federation, which will allow tagging files on Commons with properties on Wikidata so that Commons users need not recreate them.

• Next Q we'll continue supporting multi-content revisions work.

Slide 53

• We've also been building lexicographical support in order to support Wiktionary. We got great feedback on this at Wikimania. However, there was little representation from Wiktionary at Wikimania. We'll work further on that. We plan to release early next year.

Slide 54

• (Screenshot from the demo system for lexicographical support)

Slide 55

• ArticlePlaceholder: this will give people basic info about a topic that no article covers on their Wikipedia.
• Will be discoverable by search engines.
• So far, communities seem very happy with it.

Slide 56

• One of the primary reasons we have Wikidata is so that it can be used on other Wikimedia projects. Last quarter there were some issues that other communities, particularly enwiki, were unhappy about, so we're addressing those and will continue doing so next quarter.

Slide 57

• Automatically creating list articles based on Wikidata queries
• On English Wikipedia this sort of list article tends to be hand-crafted, but on smaller wikis they rarely exist, and Wikidata can help support creating articles like these.
• Pushed back because of fire-fighting.

Slide 58

• Other noteworthy stuff not already mentioned...
• Better documentation about using Wikidata in Wikimedia projects
• New supporting tools
• Wikidata flashmob
• Personal assistant (e.g., Alexa, Siri) support
• Better ORES accuracy
• Good data growth (now better than 7 statements per item on average)

Slide 59

• Example of kind of stuff people query from Wikidata.

Slide 60

• Another example of a typical Wikidata query

Slide 61

• Another example

Slide 63

• Good reading list if you have time.

Slide 64

• Thank you!

• Toby: Thanks to Lydia and WMDE for great collaborations this quarter! Good luck with WikidataCon next week.