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

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Mobile Contributions team on February 19, 2014, 1pm-2:45pm.

Present: Tomasz Finc, Ryan Kaldari, Kenan Wang, Carolynne Schloeder, Monte Hurd, Howie Fung, Erik Möller, Tilman Bayer (taking minutes), Moiz Syed, Juliusz Gonera

Participating remotely: Arthur Richards, Adam Baso, Brion Vibber, Max Semenik, Yuri Astrakhan

Absent due to illness: Sue Gardner

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
1) Mobile Trends
2) Goals and Roadmap
3) Q2 product overview: Mobile-first development, Porting existing features, Cross-team partnerships

Tomasz: welcome
no new people this time

Mobile trends

(Tomasz:)
Pageviews trends:
dramatic increase in mobile percentage, recent slide in desktop
getting closer to similar share of mobile and desktop - with current trends, convergence (50/50) in like late 2015
Kenan: tried different models with Analytics team, giving similar results
(Tomasz:) Share of mobile registrations rising in several languages
mobile registrations steady, less seasonal than desktop
highest mobile usage percentage on kowiki and arwiki (almost a quarter of 1+ mainspace editors, far more than enwiki)
mobile share of edits >5% on kowiki; investment in (non-EN) language support paying off
Kenan interviewed editor, who found desktop interface too difficult, but then made contributions on mobile, finds that it fits better into a busy lifestyle
second user story: "One Direction-pocalypse" - lots of edit conflicts when the new album of a popular boy band came out, spike in mobile registrations
We all need to take advance of this trend towards mobile

Goals and Roadmap

Kenan: 1000 mobile active editors/month goal
we focused on:

onboarding
analytics support
app

had problems with server-side account creation
mobile first : 0-1 onboarding, humanizing WP, design improvements
work with other teams to make sure their products become mobile frieldy
Q1-Q2: brought a lot of stuff from alpha into beta
and some from beta into stable, but there's still a backlog
Erik: VE on tablets means it loads irrespectively of device?
Kenan, Tomasz, Juliusz: yes, based on screen size (either dimension > 700px)
(Kenan:)
overview of lifecycle: Reader.. CTA...100+ edits, features supporting each stage
last review (Oct 24): saw 1+ edits similar to desktop, some conversion to DT
A/B tests of edit CTA guider (blue box "Don't be scared of markup. Try improving ..."), ~4% increase in activation rate
Howie: interestingly, this is even though user has to tap more (tap to get to edit screen vs. being taken directly there)
(Kenan:)
this was actually similar to a test Growth team did on desktop, as part of GuidedTours
another test: show guider after user has created account from left nav menu, significantly better result, 12% vs, 6%
(Kenan:)
Now know that guiding new editors helps.
did survey: 73% say they make their mobile edits at home (!)
How can we train new users to make more edits, get "hooked" to go on to 100+/1000+ edits
Erik: what is next with onboarding?
Kenan: will look into anon editor acquisition, account creation, account reactivation. post account creation CTA will stay
Also think about anonymous editing, move tablets into mobile
Erik: what about displaying redlinks?
Kenan: it's in beta now
"Humanizing": Let readers know WP is edited by humans (show "last edited by" + user name)
not quite metrics driven (Growth tried something like this a while ago and didn't keep it), but we wanted to get it started
More structured way to express user identities, by showing recent activity etc.
Also still in beta - got a bit of community pushback,
will work on making this provide value for workflows
Tried showing user intents (text box where one describes one's editing intentions), but doesn't work well without a clear purpose
Moiz: we learned that free-form text fields don't work well without clear directions
Erik: Growth team is trying out showing edit suggestions in contributions page
Kenan: yes, talking about this
Moiz: With Steven, exploring the idea of a separate homepage, where one lands after logging in, including edit suggestions

(Kenan:)
Design:
Mobile web UI overlay redesign (e.g. standardize upper left/upper right corner for abandon/progress action)
Erik: is this making a difference for edit rates?
Kenan: not seeing big changes
Erik: did we user test this (e.g. the check mark symbol on previews)?
Kenan: not a lot
Erik: should do this
Howie: worry that blue /green colors are confusing on first use
Moiz: UI elements should not need explanation
Kenan: this is the first release of something on mobile that uses Agora, worth testing
Tomasz: will evolve in the field
Q: how does it look on RTL languages?
Julius: everything is flipped

(Kenan:)
Brion's demo of app design:
local search
language choice
browsing history
save pages
editing (anon editing possible on app)

Arthur on mobile web:
we entered a new era in Q2
after laying foundations, entered areas like onboarding where other teams already have expertise
overlap between work of the Mobile Web team and the Growth team, in particular GettingStarted - our version is called "KeepGoing"
waiting for the Growth team's planned GS API
scaffolded functionality on our end, using random new articles needing links (instead of GS API), reinventing the wheel a bit, but should be easy to use API once it becomes available
Around the end of Q2, worked to get VE working in mobile frontend alpha (collaborating with VE team, Rob Moen)
VE now basically works, but quite a lot of bugs
Hit some roadblocks, or rather a nest of dragons ;)
VE team might have been in better position to do this work, given their familiary with the product
Juliusz did some research work on image display on mobile (tap to enlarge), conversation with multimedia team (Fabrice), identifying collaboration areas

Learned:
Collaboration is challenging when visibility of Mobile is low, can't be an afterthought
really difficult to shoehorn big projects like VE and Flow into mobile afterwards. Even though VE team had done tests with mobile browsers, didn't work well with MobileFrontend
Erik: are there architectural considerations, e.g. MobileFrontend part of core? Skin?
Arthur: best by engineers on these projects
Juliusz: mobile (in general) was not part of considerations and design for those products
e.g. VE design assumed lots of screen space
Kaldari: have to strip out lots of styles (the whole thing is made for the Vector skin), would be better if they had been separate from the beginning
Tomasz: they had to ship on enwiki on desktop, mobile became afterthought when things got busy
Arthur: earlier, MobileFrontend was more difficult to test with, now easier
Erik: embedding engineers?
Yes, with flow. Likely Jon

Kenan on Q3 goals and roadmap:
app editing
Flow integration
VE: talking with James, attending their design meetings, Roan coming to some of ours
They will prioritize work necessary for mobile over new features, becoming more of a platform team
Erik: so no need for cross-embed currently?
Arthur: no, but will reevaluate in a month
Tomasz: think about it more long-term, how WMF should operate on this as an organization
Howie: (question about how prioritization will actually happen)
Howie: hiding of styles etc. - how was that discussed?
Kenan: not a good answer yet for change management (a new button in DT VE might not show up automatically on mobile)
Kaldari: some components of VE may not be suitable at all
Erik: how many FTEs on the mobile team do VE work?
Kenan, Juliusz: maybe 60-70% this quarter
(Kenan:)
Next fiscal year:
Q1: Growth: anon acquisition, article creation, task suggestions, reactivating accounts
Apps: RC, microcontributions
Q2:
media and geo for apps
user profiles?
mobile power users
Erik: mediaviewer?
Kenan: not yet, but look at it in Q2
Tomasz: depends on how other work goes (VE...)
Kenan: lot of partnering with other teams, make sure their stuff works on mobile
Tomasz: want to continue existing investments through Q4, work with QA
Arthur: impossible for us to pass all browser tests, because of the way they are set up
need some more mentorship, guidance on unit tests, both for PHP and JS
testing infrastructure is a million times better than one year ago, but...
Erik: current test model (betalabs) can't correlate test with code changes, could instead start separate virtual machine for each test, report back directly into Jenkins/Gerrit
Arthur: tests are run blindly against all environments, even those where the code is not live yet (e.g. only deployed on mediawiki.org, but tested for enwiki)
Erik: the VM model would solve that?
Arthur: yes, but it would be even better to run with exactly the version deployed on that wiki. Chris McMahon working on that
Erik: can I and RobLa support this?
Arthur: just help prioritize it

Asks

QA (see above)
Tomasz:
Doing mobile after the fact is more costly than we thought. Need Mobile from day 1
Missing mobile support should be a blocker for deployment
Erik: ...
(Tomasz:)
have had 3 models of how product teams treats mobile:

DT only (does not work)
test mobile when team has time (does not work well)
integrate mobile from the beginning

Moiz: UX team advocates for good design. At least require responsive design for tablets
Tomasz: teams must not see this as responsibility of mobile team, but instead as their own
Howie: how will upcoming work inform next FY planning?
Tomasz: currently 4 + 3 engineers for web+app core work, can't take capacity away from them for mobile support of other products, this needs more capacity
Erik: agrees
Tomasz:

make providing APIs a requirement (e.g. team had to create API for account creation, was lucky to have Brion who was familiar with this)

Erik: that was legacy stuff. current examples?
Tomasz: e.g. no idea about Flow
difficult to even know what's available
Yuri: will lead to more service oriented model
Tomasz: more modular
Howie: difficulty: relies on other teams
Maryana working on something like that for Flow
Tomasz: embedding an app engineer could be huge driver for API development
Yuri: teams should use APIs themselves
Tomasz: currently very ad hoc, difficult to know what to expect

Erik: This was exciting stuff. No further questions
Tomasz: thanks to everyone