Wikimedia monthly activities meetings/Quarterly reviews/Mobile contributions/May 2014

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Mobile Contributions team on May 29, 2014, 1pm–3:30pm PDT.

Present: Tomasz Finc, Lila Tretikov, Vibha Bamba, Kaity Hammerstein, Max Semenik, Howie Fung, Carolynne Schloeder, Monte Hurd, Toby Negrin, Erik Möller, Jon Robson, Tilman Bayer (taking minutes), Maryana Pinchuk, Dan Garry, Rob Lanphier, Oliver Keyes, Bernd Sitzmann, Dmitry Brant, Jared Zimmerman (from 1:45), Terry Chay (from around 2pm)
Participating remotely: Brion Vibber, Arthur Richards, Adam Baso, Yuri Astrakhan, Juliusz Gonera, Yuvaraj Pandian

Please keep in mind that these minutes are mostly a rough transcript of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material

Agenda and introduction

Presentation slides from the meeting

1. Mobile Trends
2. Goals and Roadmap
3. Q3 Product Overview
– Tablet Redirect
– Visual Editor
– Native Wikipedia App

Tomasz:
Welcome
Today's review: Both mobile web and app teams,
focusing on mobile contributions
Welcome new team members:
Dmitry & Bernd working on Android app
Product manager transition from Kenan to Maryana and Dan, working out well

Mobile trends

Maryana:
released contributions pretty recently (Q3)
were not sure what to expect, exceeded #contributors goal by far
this Q: upping the goal
focusing on tablet users in Q4, with VE
don't have native apps yet (only Phonegap-based app)
Lila: can we add actual numbers to the slides? ok
Lila: Do we have other mobile goals around e.g. readership or donations?
Maryana: no
Tomasz: we used to set readership goals (around 2 years ago), but organic growth was steady anyway
Lila: seasonal effects for unique user numbers?
Maryana: can't tell yet
majority of users who make 1+ mobile edit are new users
Howie: released mobile editing around a year ago
reason we chose the 1+ threshold (rather than the usual 5+ on desktop) was that we needed to gauge the interest in mobile editing first
(Maryana:)
registration -> edit conversion rate is lower on mobile than on desktop (difference becomes even larger when crossing higher edit count thresholds)
right now, new active editor numbers from mobile are just shy of theQ3 goal
stepping back, looking at history of mobile Internet (2006: WAP/SMS .... 2014: app traffic > PC traffic in the US)
recalls first mobile web version of WP...
Phonegap apps were easy to roll out, but slow, lack of features, more time spent dealing with old browser bugs
Why native apps (instead of Phonegap)?

• Fast – huge difference for users!
• scrolling, animations, gestures. User expectations from other iPhone/Android apps
  

Drawbacks: separate web/app development teams
mobile contributions elsewhere in the industry – example: Yelp
first did not offer users to submit reviews on mobile, only other features like checkins
then they did (surely motivated by the global mobile traffic developments)
for a long time, they probably assumed that serious writing wouldn't take place on mobile. We did too!
Lila: e.g. one used to have no copy+paste on apps
Maryana: also, form factor – now mobile also includes larger screen sizes
responsive design vs. apps
for news, 60% of table users prefer web over apps, as opposed to e.g. Facebook. So FB focuses on app
Lila: also, rapid changes – study from 2012 might be outdated. cf. e.g. Flipboard, mobile search
(Maryana:)
bundling vs. unbundling: e.g. Facebook doesn't move in a clear, single direction over time
Toby, Lila, Vibha: Facebook does lots of testing and adapts to the results
(Maryana:)
important: they try not to disrupt existing UX too much
Lila: need to think about where the user is, and how we can bring WP to them – not the other way around
(Maryana:)
Facebook vs. WP mobile milestones
Lila: how does our readership curve compare to the industry overall?
Oliver, Howie: overall quite similar
Dan: could get really specific with specific apps, e.g. an admin app ;)
Moiz: avoid the mistakes of Facebook ("Home")
Monte: could also have "responsive apps' (for both tablets and phones)

Q3 product overview

Arthur on mobile web :
focus areas:
1. get Extension:MobileFrontend to work nicely on tablets
now, you no longer get redirected to mobile version on tablets, instead have a desktop-like UX
2. get VisualEditor working with MobileFrontend, for tablets
goal of 1200 mobile editors on enwiki by Q3, was dependent on wrapping up 1. in that quarter, which is why we did not quite reach it
I would wager that it would have been reached or exceeded if we had completed that
Jon Robson:
demos mobile web version on phones
collapse section for readability on long articles
when enlarging browser window, still stuck with small images etc.
but tablet version (beta) now fixes that (e.g. icons and text shift, TOC moves into article)
sections shown by default instead of collapsed like on phones
on phone mobile, some messages use overlays covering up the whole screen
on tablets, these are placed alongside content
Tomasz: it has evolved nicely

Arthur:
on UX unifications and convergence:
responsive design interpolating betwee tablets/phones
would like to have this to cover all devices
mobile: many features easier to find
big advantage: had a blank slate to work on, could experiment for better UX, implement ideas from Design team
mobile paves the way: Typography refresh
several people across Engineering came together and resolved to roll this out to desktop too
but encountered a surprising amount of community backlash
had to revert some changes, but kept others in place
Some designers have worked on the "Winter" proof of concept: unified for desktop and mobile, as kind of a nirvana vision ;)
might not be implemented 1:1, but helps to see what improved UX could look like
Lila: so how does the Winter team collaborate with Mobile?
Jared: some people worked on this on the side(?), Howie and I discussed the project. Brandon primary designer with Kaity, Jon Robson on the Mobile side
Lila: say we put this on Beta, test it successfully – would this replace the Mobile site?
Jared: it would eventually be a replacement for the default skin (Vector)
right now, Winter doesn't look very different from mobile default
Jon: have a rough prototype, some slight differences
Erik: Winter is a useful sketching board
"if we did it all over again, what would that look like"
the eventual tablet experience will probably look different
Arthur: yes, drawing inspiration from Winter, incredibly valuable as that
Lila: we need same tech underlying all device experiences
Erik: big issue right now is to get the tablet redirect to mobile working
Tomasz: yes, this is a test case. If we can get this to work, desktop comes later
Arthur: Because WMF grew fast, only recently started efforts to unify work
maintaining separate libraries, all with own HTML templating
current RfC on unified HTML templating, moving slowly
but at least the Flow and Mobile Web teams will converge
Lila: performance issues due to these templating libraries?
Jon, Tomasz: oh yes
RobLa: regarding RfC: options being worked out now by Gabriel and Matt Walker
after that, consensus could be quick
Erik: it's a scope issue: How much to include?
Max: wheel reinvention ;)
Erik: consider wikitext templates too, need to move away from them
adds security concerns
Jon: regarding Flow and Mobile Web, these two teams actually use slightly different languages (Handlebars vs. ...)
Arthur: bigger takeaway: need not just design convergence, but also code convergence under the hood
Lila: shared ownership?
Erik: no, that's part of the problem currently
Platform team has ownership of backend
but no shared ownership of frontend
catching up, slowly arriving in 2011 ;)
Jared: have a Trello card for that kind of thing from the UI perspective, I'm kind of the PM from Design for that, but none from code side

Juliusz:
demos VE on tablet
can always go back to wikitext editor
section level editing: similar to desktop
only basic tools in mobile VE
e.g. creating links, adding references
separate save page
Erik: this is a big accomplishment
Tomasz: very technically complex
Lila: different from desktop? Yes
Jared: framework chosen for VE on desktop has big issues on mobile, needed rewrite
Juliusz: majority of code is the same, it's not a separate project
Erik: what were the testing criteria to determine that it's ready on tablets?
Kaity: still need to do some more user testing
started from wikitext editing toolbar, added functionality from that
save button is a usability concern, because it leads to a separate page
eventually want VE on desktop to feel the same way, unify UX
Erik: I assume a lot of desktop VE features are still not available, how were these prioritized?
Maryana: that was still Kenan's decision
Kaity: next: add headings
Arthur: thought about bare minimum to be valuable for users
Tomasz: eventually handoff conversation with VE team
Oliver: how do we assess what new users want to do?
Maryana: we do have an idea about this in general
e.g. change/add text
Arthur: hoped to have redirected tablets to mobile by now, not quite there yet. plan: June 17
did a lot of tabletification in MobileFrontend
no target date yet for getting mobile VE into stable
Lila: what is "stable"?
Maryana: stable is the default version (i.e. on wikis where VE is enabled, it will be shown by default)
Arthur: ...as opposed to Beta (opt-in in preferences), and Alpha
need to push VE into Beta, process bug reports from Beta users, then into stable
Erik: agree it can't go into stable yet. But can we aim to include VE into Beta with the June 17 date? It needs to get usage.
Arthur: yes, can explore that in planning meeting next week
mobile VE handoff to VE team:
in the long term, we should not have 2 VE's
mobile VE should benefit from VE team's domain expertise

Lessons learned from this project:
still, mobile first!
also: handoffs and dependencies are bad
history of collaboration with VE team:
had Rob Moen from VE embed with Mobile web team during Nov/Dec
then, Mobile team took over all mobile VE development, but hit wall, reapproached VE team
Roan Kattouw from VE team came over to our meetings, for sanity checks
Maryana and JamesF(?) from VE team started doing regular PM checkins
VE team works on an interrupt model ;) we could always ask them for advice, code review
but they had to do interrupt prioritization too. it became a bottleneck for us, couldn't take their availability for granted
and getting blocked on this kind of requests causes us expensive context switching (need to get back later, get reacquainted with situation)
mobile team does not have domain expertise with VE
And: the two teams have very different work models (VE: interrupt vs. Mobile: scrum)
other unscalable things:

• mobile absent from product goals, retrofitting is expensive
• mobile team can't own the mobilification of other products, lacks domain expertise
  

How to fix this?

• need to integrate mobile into products from day 1
• standardize helper libraries/tools
• minimize handoffs/dependencies (maybe team practices team?)
• share mobile engineers, e.g. Jon will be embedded with Flow team for one quarter, so Flow engineers will be able to do this on their own, and ideally share that knowledge with others later
  

Lila: this is very helpful information
Erik: being a multi-device org means more than just integration into product goals ...
Tomasz: agrees, it also needs resourcing

Native Wikipedia app

(Tomasz:)
Why build app?
From Commons app, saw that apps give us high quality contributions from power users
they ask us for new features to enable even more efficient contribution
Mobile web is great for large number of users
But apps much more specificity, R&D space, to significantly change UX
not just about making an edit – that's just a small part
also e.g. need to know about feedback (e.g. someone reverts me, someone nominates my uploaded image for deletion)
we do have notifications on mobile web, but user needs to open browser to see this
on app, user gets feedback more directly
What are the personas we need to develop for?
level of engagement is higher for users who installed it from app store (they specifically sought out the app)

--break--

Moiz:
demos iOS app (Android app is very congruent both with respect to both features and design)
thought about 2 navigation patterns:
1. search-based (navigating to a page/between pages) 2. within page
Monte: app works in airplane mode too, because of caching
Moiz: for the first time, can share content on social networks (Facebook, email, ...)
offers offline reading
fast
A lot of 3rd party WP apps exist for reading, but ours is the first with editing
Monte: shows panel of predefined edit summaries (e.g. "I fixed a typo")
no longer collapsing sections
but TOC can be displayed simultaneously
native approach allows us to integrate images better
integrated TOC allows to navigate long articles more quickly (e.g. 5-6 swipes instead of 50-60 swipes for a long article)
Lila: who is the designer for this? Vibha and Moiz
Monte: top left menu has basic functions, e.g. list of recently read articles
Lila: what about preloading articles?
Monte: needed code would be already in place
Dan: app loads first section first, then the rest of the article
Lila: down the line, could try to predict search results, preload
Monte: or refresh saved pages automatically
Lila: or push them
Monte: i.e. like mobile web, apps can try out things
Toby: need to figure out how to count these things correctly (as usage)
Monte: iOS6 enabled responsive design in apps
also made internationalization easier (less worry about text overflowing in other languages)
and, compared to mobile web, "closer to the metal" performance – can basically write in C (instead of e.g. JavaScript)
and, less roundtrips to the server, handle more inside the app
it's a fun sandbox for us ;)
Vibha: app also encourages readership
Howie: typically, users get to WP via Google search – shallow experience, arms-length relationship
apps could enable a closer relationship
Jared: also enable microcontributions, e.g. you are near a building that needs an image
Toby: what ratio of mobile app/web traffic are we aiming at? (right now 90% web)
Tomasz: really focusing on contributions
Monte: have tens of thousands of app downloads per day already, without much effort
Tomasz: Wikipedia Zero integration (post-meeting videos – Android,iOS – UX looking for opportunities for final polish within screen and software architecture constraints)
Carolynne: app preloads will be a big priority for us next FY

Goals and roadmap

Tomasz:
Goals and assumptions:

• engage repeat contributions
• launch with anonymous and logged-in editing
  

data collection on:

• editing workflow – where do people drop out?
• account creation
  

Release plan:

• June 4: Android beta app
• June 25: Android stable app
• Next FY: iOS beta and stable

Maryana:
this review is about Q3, but as Arthur mentioned, work carried over into Q4
right now, can read and login everywhere (desktop/mobile web/app...)
support for editing is more mixed
Currently, everything focuses on long-form reading and editing
e.g. on mobile, infobox might take up entire first screen, blocking out definition in the article's first sentence :(
Wikidata might be an opportunity for mobile microcontributions
Max: that feature already exists ;)
(Maryana:)
readership reflects global trends
currently mobile = 23% of our pageviews
Facebook: 79% of MAUs
Yelp: 46% of UVs
Historically thought of mobile as like 20%, but should prepare for a world where it will be 80% for us

Questions, Asks

Tomasz: thanks to everyone who worked on this and helped prepare this quarterly review
Questions?
Erik: where are we on microcontributions, which level of detail?
Maryana: starting planning
Tomasz: the word "microcontributions" should not become a red herring. Focus on what will give us contributors, and then implement it
Erik: Flow will offer lots of opportunities, but is nowhere near mobile-ready, needs to be resourced appropriately or it will fail
Let's not repeat the VE situation – implementing lots of cool features without mobile support
Tomasz: every team should set mobile goals. that might imply resourcing, training, support
Jon: Flow has a no-JavaScript mode, so works somewhat better than VE on mobile already
Erik: need to surface this in the next VE quarterly review
Lila: we should design and build for mobile first
because 1. it's a green field, 2. it will be the primary platform (80%)
Mobile team should become a resource to other teams, just like Platform is
Tomasz: having a template library per team is quite insane, need that unification. huge switching costs. Excited about Gabriel's and Matt's work
Erik: challenge: prioritization of microcontributions vs. enabling existing workflows on Mobile. let's not paint ourselves into a corner
comfortable with revisiting our goals during the FY, zooming in on particular features
Jon: browser testing asks:
CloudBees has issues
Betalabs (testing close to production) is flaky, often not sure if test failed because of bug in our feature or because of issues with testing platform. sometimes only find out a day later
RobLa: CloudBees migration is happening in the next few weeks
just hired Dan as automation engineer
should help with getting tests into better shape
Regarding Betalabs, might be different issues
Jon: things are already improving
Erik: what about manual testing?
Max: we used to have a manual tester, not any more
RobLa: Rummana?
Arthur: she worked a bit with the mobile web team
RobLa: also, we are quite far along with QA(?) hiring
Tomasz:
also, talked with Tim etc. about service oriented architecture
Lila: thanks everyone, this was enlightening