Wikimedia Apps/Team/Philadelphia 2017 offsite/Offsite outcomes

On October 17th-19th the Wikimedia Foundation's apps teams, along with shared members of other teams (CL, QA, Admin, etc) met in Philadelphia. Please see the event page for more on the complete program, but here we'll outline the content shared among the team, the features and plans discussed, and other outputs of the event.

App Product Strategy

edit

Josh Minor, the PM for iOS, presented the 6 quarter 2017-2018 app strategy overview. This deck outlines the status of the Foundation's apps, the audiences the apps serve, and the value the teams and their products bring to the movement and Foundation.

https://docs.google.com/presentation/d/1Pm86vhDedmQQa_YjAwDV1i6pFpPg2pl5tQanfc9yYEg/edit#slide=id.p

Product Self Review

edit

At the initiation of the "redesigned" 5.x iOS app version, the team defined 8 aspirations for the app. Android adapted/adopted this same set of aspirations last year. We regularly revisit our review of our own product, with each team member scoring their app from 1-10. We also asked the other offsite participants to rate the app on the same scale.

Appy Sticky Responsive Private Polished Engineered Featured Accessible
iOS 7.75 6.75 7.2 7.6 7.75 8.24 8.2 7.6
Android 8 5.25 5.75 5.75 7.5 8 6.25 5
Other 8.75 6.5 8 7.66 8.66 7.33 8.33 7.33

Take-aways

edit
  • As you can see the teams are a bit self-critical, as reflected in their own self-scores compared to "Other" participants (and relative to general app store ratings).
  • In particular the Android team had a few areas where the team believes their product falls short of their own or users expectations particularly focused on navigation and user experience shine.
  • The lower scores on privacy for Android came from two sources: belief that even though privacy is important in the app, the design and user experience do not always convey that feeling. For example, "Because you read", although done in a privacy sensitive way, are often perceived as invasive. Second the Android app continues (unlike the iOS app) to require users to "opt out" of analytics.
  • Stickiness continues to be an area of weakness. Making a compellingly sticky reference app is a challenge and product theory remains far more weakly supported than other areas. That said, there is still strong team support for improving stickiness through iterations on the feed, recommendations and notifications, all of which were reflected in the planning priorities.
  • Both teams, but particularly Android, expressed a desire to have a separate evaluation of Accessibility, as in support for the visually impaired, and multilingual support. These are both currently subsumed under Accessible, but the teams would like to plan, build and evaluate those two audiences and feature sets separately. In future iterations we will add "Multilingual" or replace one of the other 8 to reflect the importance of this going forward.

App Design Vision

edit

Lead Designers Rita Ho and Carolyn Li-Madeo presented an overview of design on apps. This deck gives an overview of the methods, recent case studies and areas of focus for app design.

https://docs.google.com/presentation/d/1hPRQaH-mQdD3_2tm0q02Ipps5_3z7pg2sJMjVsZmvN8/edit

Editing Features Brainstorm

edit

The Android team has been the main team executing the "micro-contributions" strategy of the Readers team, with the Wikidata Description editing feature being the initial feature developed as part of that initiative. The Mobile Contribution community consultation envisioned additional contribution mechanisms based on the most supported proposals, and the 2017-2018 annual plan includes a program in this area. So, although the apps teams fall within the "Readers" audience focused part of the Foundation, the teams are the only staff working on native mobile editing features. Additionally, both teams strongly believe that we can, and should, do more to make contributing on the app a first class experience. Given all that background, the team did a brainstorming and grouping and ranking activity for potential mobile editing features.

Below are the ideas generated, grouped by area. Note that the goal was not to generate only new ideas, but rather a breadth of all mobile editing ideas.

After grouping and reviewing the ideas, the team did a quick straw poll to identify items which might be particularly well supported, or be particularly useful to existing editors (as opposed to the full universe of new and old contributors that novel contribution mechanisms might target). Features with some support are marked with a *. Items marked ** received significant consensus for investigation as future priorities.

Echo

edit
  • Native mobile push notifications*

Tours/Wikivoyage

edit
  • Walking tours
  • Curated "local" mode for tourists

Moderation Workflows

edit
  • Talk pages*
  • Messaging*
  • Recent changes patrolling (approvals, revert and/or message editor)*
  • Edit review queues (allow people to get task specific queues)**
  • New article review
  • Mark changes as patrolled
  • Tag articles with maintenance templates*
  • Mark text to "edit later" with associated task list (personal, not on wiki)*
  • Watchlist*
  • Block/unblock tool
  • Protect/unprotect

Images

edit
  • Improve lead images (select, place and crop)**
  • Add photos to commons
  • Scans for WikiSource
  • Add photos to locations*
  • 360 degree uploads for locations/simple place AR
  • Add pictures from existing media on Commons*

Categorization

edit
  • Mobile HotCat
  • Basic category/category editing support*
  • Connect the content in topics or queues
  • Why are you reading this? --> Recommendations

Media

edit
  • Scan objects or reliefs to create 3D models on commons (AR capable devices)
  • Chinese calligraphy for zh articles
  • Pronunciation recordings
  • Add audio to article (bird sounds!)
  • Oral histories
  • Record and add video
  • Live video streaming (for crowdsourcing updates of live events)

Location

edit
  • Distance support
  • Move or update article location
  • Mark current location as location of article*

Wikidata/ORES

edit
  • Structured infoboxes (native presentation)
  • Edit data properties, including adding required reference URL*
  • Feed and continuous scroll Description editing*
  • Wikilabels game
  • Wikigrok/wikidata games

Reader Opinion

edit
  • Readers thank editors*
  • Article quality voting
  • Change voting (improvement/regression voting on revisions)

References

edit
  • Highlight a sentence and add a reference by pasting URL
  • Share media to an articles talk page as a potential reference
  • Citation game
  • Scan ISBN/bar codes to add book citation*
  • Use OS sharing extensions to add content from other apps as a citation

Sub-Article Editing

edit
  • Inline Editing (hightlight, and open eiditng flow in place -- exists in a v1 on Android)**
  • Editing recommendations based on my reading history
  • Highlights/public annotations
  • Highlight "facts"
  • Highlight issues (citation needed, other guidance violations)

Explore Feed Design Review/Research

edit

Rita presented conclusions from her recent research on Explore feed usage on Android. The full deck is available here, though in the room we focused on the conclusions she draws:

https://docs.google.com/presentation/d/1PseUWB9GFe65SI_PXChuClQ3r1zt-EglFYpiJT7_5ok/edit?pli=1#slide=id.p

Addressing these conclusions in the near and medium terms was the focus of the next activity.

"My Morning on Wikipedia" Brainstorm

edit

The team was asked to envision the future one year from now. They go to look at the Wikipedia app first thing in the morning. What do they see on their home page? What would be in the feed? What content or interface greets them?

Below are the ideas generated, grouped by area:

User Education

edit
  • Tips about app features I haven't used yet
  • Tips about how Wikipedia works and how to edit

Search (in the feed or otherwise)

edit
  • Very prominent search
  • Trending search topics

Editing and Watching

edit
  • Watchlist updates since last visit
  • Notifications home
  • Reminders to edit specific articles (for example based on TV schedule)
  • Significant updates to saved articles
  • Stats about my reading (articles read, categories most read, recent searches)
  • Editor's feed: queue of tasks for editors and admins
  • Suggested articles to edit based on my history
  • Echo notifications received
  • Pages with the most issues (Top Broken)

Factoids in the feed

edit
  • Fun facts
  • Popular shared highlights
  • Did you know?
  • Recent notable deaths
  • Trivia questions and articles with answers

News

edit
  • Relevant articles to local events
  • Relevant articles to national events
  • Relevant articles to world events
  • Science news
  • Global news items
  • Realtime news related articles
  • In the news
  • Current events portal(s)
  • News... but fresher
  • News not our thing, should move down but be more current
  • A place for important events around the world this month
edit
  • Because you read... but better
  • Top Read and WHY
  • Trending by location
  • Smarter recommendation based on user input, not history
  • Reminders to read next articles in a learning track or queue
  • Articles based on reading history and interests

On this Day

edit
  • Births, deaths and holidays (already in API)
  • Notable birthdays
  • Holiday articles on holidays

Curated By Other People

edit
  • Follow other readers for their recommendations
  • Lists of articles from awareness campaigns
  • Articles posted on social media
  • Recommendations from groups: Women In Red, Wikiprojects, etc
  • Articles trending in TIL posts from Reddit
  • Articles about notable women

Customization

edit
  • Every feed type should be hideable
  • Dismissible individual cards
  • Re-order-able cards

Categories and Random

edit
  • Recommended articles in favorite categories
  • Categories related to my interests
  • Newly created articles in favorite categories
  • Recommended reading customized via a set up (with a flow like Pinterest)
  • Articles about TV shows based on schedule
  • Random in a specific category
  • Make a safe random (random can sometimes be "graphic")
  • Infinite scroll random

App Awareness Brainstorm

edit

As outlined in the app strategy, we believe that the quality and utility of the apps has improved significantly, and that our relatively small audience size is at least partly due to a lack of awareness of the apps. Although there have been attempts at raising app awareness in the past, there has not been any real sustained effort to let people know about the apps, and why they should use them. The teams would like to see that changed, but given the many priorities of the Communications team, and the Foundations very limited expertise in product marketing, the teams believe they will need to undertake many more awareness activities over the rest of the strategy. In this open brainstorming we listed all the ways the app teams themselves could work to raise awareness, without dependencies on other teams. Below is the list of suggested activities. These will need to be triaged, tasked and planned, but it gives us a nice long list of potential outreach options:

  • More blog posts (at least one a month)
  • Featuring in app stores and other stores in other languages
  • Facebook groups
  • Twitter
    • Retweet positive stuff found in chore wheel
  • Instagram
  • Maker sites
  • Make some videos
  • Styleguide
  • More demos (internally/externally)
  • Developer outreach (subreddits, etc)
  • Gifs
  • Post on reddit (host an AMA)
  • Tell-a-friend widget within app
  • Ask for reviews/ratings
  • Events (conferences)
  • Update mediawiki pages, FAQs
  • Microsite(s)
  • Marketing collateral for various events WMF attends (press kit)
  • Affiliates and interest groups and libraries
  • Mobile web - Put a notification(s)
    • Banners
    • Sidebar
    • Hamburger menu
  • Store
  • Non-wiki sites
  • Wiktionary advertisement
  • Feature specific marketing for specific markets
    • Offline for example in New Readers markets
  • Change category? Education as primary category?

Open Planning Prioritization

edit

Finally, based on the presentations and discussions of the previous two days the teams engaged in a round of collective prioritization and planning. Team members proposed potential epic for the next 1-4 quarters, and each team member was given a budget of votes. The budget could be applied to one or more prioties. After an intial round, epics with no votes were removed, and another round of votes was added.

Below are the proposed epics and their final vote tally by team (and Other for non-app team voters). Additionally goals for the app analytics project and app awareness were "automatic" winners due to their annual plan and executive commitments.

Items with a + in the Goal category represent likely goals for one or both teams for the next 1-3 quarters. Letters refer to target Android release versions, version numbers are given for iOS.

Epic Android iOS Other Goal Next Action
Feed customization 3 4 0 + Android, in design for E; iOS to begin design for 5.9.0
Navigation improvements 2 2 0 + Android work on flow in F, iOS to begin design research in Q3
Trending with reason 1 3 0 Product to begin research in Q3
Echo notifications 4 0 0 Resume definition work with Reading Infrastructure in Q3
Births, deaths and holidays 1 2 1 Android to add on this Day in E; iOS to iterate in 5.9 or 5.10
Improved feed recommendations 1 2 2 Mikhail is doing a simple test demo; Product to request for further data and research bandwidth
Darker mode for OLED 1 1 0 In designs' queue for slotting into a near term release
Fresher news 2 0 0 Potentially part of E or F on Android, pending Product definition
Healthier community awareness of apps 0 1 4 + Chris K to work with Product on potential outreach efforts
Dynamic randomizer (for Android like iOS) 2 0 0 To be tested in E for Android
Reader Notifications for Android 1 0 0 On hold until Feed work and Echo integration research complete
Fast article preview (for iOS like Android) 0 2 0 Development complete, release in 5.8
Low res/no image option 0 1 0 To be included in iOS 5.10 or 5.11
Article load speed improvement 0 1 0 Continue with Reading Infrastructure PCS and cacheing architecture planning