Wikimedia monthly activities meetings/Quarterly reviews/Product/January 2015
The following are notes from an update meeting (using the quarterly review format) with the Wikimedia Foundation's Product Development team, January 29, 2015, 13:00 - 14:30 PST.
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
Present (in the office): Lila Tretikov, Howie Fung, Erik Moeller, Jared Zimmerman, Toby Negrin, Rachel diCerbo, Damon Sicore, Tilman Bayer (taking minutes); participating remotely: Wes Moran
Welcome, overview
edit
[slide 2]
Erik: This is actually not a quarterly review meeting
It's an update, and discussion with you
UX and CE Product teams are not currently doing quarterly reviews (will start next quarter)
because they are embedded in other teams
Most folks in this meeting serve other teams' goals that have been discussed in their respective quarterly reviews
[slide 3]
these have been my priorities as exec
[slide 4]
decided with Lila and Damon that Damon will take on responsibilty for site-wide tech changes
[slide 5]
include community(ies) in Q4 prioritization: this is an absolute first [haven't done this before]
UX Standardization
edit
[slide 7]
history of MediaWiki: no UX standards whatsoever
Lila: spell out why are we doing this (it's not process for process' sake)
Jared: one aspect is brand, consistent across platform
rely solely on logo [to maintain awareness on which site the user is on]
on desktop, have that [only] sort of accidentally - when you scroll down, you still know you are on Wikipedia [because of font, layout etc.]
Erik: also, so that users can use same mental model across devices
[slide 8]
e.g. developers don't need to worry "do I need a bitmap or vector graphic"
[slide 9]
Jared: in MediaWiki UI scheme, color has meaning
can change colors dynamically
Erik: this is pretty standard for web apps, but the way we do it is somewhat novel
Jared: make it work well for i18n, gone further than others
Erik: gigantic codebase that needs refactoring
[slide 10]
Erik: don't have velocity data though
Jared: hopefully most users will see new style at end of quarter, except maybe some rare cases (say Checkuser forms)
Erik: [demos live style guide]
switch between PHP and JS
more design aspects are being filled out by Jared's team
Jared: talked with Release Engineering, will have visual regression testing
Product Process Improvement
edit
[slide 11]
Erik: avoid obvious trigger points
Lila: the issue here is that our prioritization is insular
need to understand different audiences
communication methods are broken
in milestones from inception to outreach, where does community outreach happen?
Erik: products that have the most touchpoints with experienced editors tend to get most community liaison support
PMs are not without community interaction, but CLs do it much more frequently, have domain expertise
Lila: engagement means talking?
Rachel: there is a broadcasting element too
still figuring out metrics
Erik: example: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback - gets a lot of traffic
a lot of what CLs do is triage that, escalate to Phabricator, etc.
Jared: they monitor a lot of places
Lila: no clear workflows? do we have a numbers?
Rachel: we have workflows, would need to estimate their number
Damon: can CLs influence which bugs are fixed?
do we have good examples of how they changed products?
Jared, Rachel: yes
Erik: "bug triage" would downplay it a bit, this work goes much further
everyday conversations between PMs and CLs
Damon: I think that CLs are a great idea, but PMs should be in direct contact with users too
Rachel: we see ourselves as heavy lifters for communication
Damon: I think PMs should triage
Lila: should have some level of triage / low-hanging fruit picking by CLs
Jared: volume of feedback is much larger here than in other places
have heard CLs say "I heard about this problem 5 times / 100 times"
works really well
Damon: I like that we have CLs, but would want to have PMs as focused intelligence on entire process, surrounded by CLs etc.
[slide 12]
Erik: good team level triage process currently
but not ...
two (community) audiences: those users who are comfortable with Phabricator [earlier: Bugzilla], and those editors who are not, but nonetheless have their opinions
Lila: sees a parallel with [the general concept of] support teams. can call CLs community managers, but they are still there for supporting users
they do answer questions, e.g. "this feature is still there, but..."
that is something that support teams do
Howie: they have a role in shaping the product
Lila: a good support team does that too
Erik: gadgets surveys:
interesting difference between English and Spanish WP
Lila: is it because English WP is older, or a cultural thing?
Rachel: rather a cultural thing
also, Spanish Wikipedians wanted to do their own translation (unhappy with the one we brought them)
or, they rarely use watchlist notices there (compared to enwiki)
Erik: communicated low expectations when starting this - only gadgets, only 2 languages
[slide 13]
3 principles on dev summit
Lila: OK, but these seem more architectural principles than user-facing principles
no way to succeed with designing same UX for all users - e.g. both expert editor and general reader
might want to keep entirely different interface for longer-term power users, set aside budget for that
but also give new users what they want
and get from point A to point B in shortest amount of time
Jared: with Abbey, worked on personas/segments, for designer to design around (https://www.mediawiki.org/wiki/Wikimedia_Product_Development/Person%C3%A6 )
see how every change affects these differently
Lila: important to bracket correctly, not too granular
Erik: I think the persona draft is useful, and want user representatives (e.g. who stands up for readers?)
caution though that we also need to account for differences between communities
some, like Catalan WP, are eager to test new features
and these are people who have been around for many years
Lila: OK, but buckets (personas) could cut across communities
Jared: so that would mean experience is not only parameter for defining personas
Erik: it's not merely change aversion or acceptance
it's also e.g. how much that community as whole cares about newcomers
Lila: need not go after all WPs at all [for generating personas], can look at just a few from both extremes
Toby: need to decouple things (also: marketing), or will end up with like an 8 dimensional matrix ;)
Lila: it's still OK to start with English
Damon: can do language by language; I don't think English should be first
Erik: I take this as action item to think about there personas at higher level
(discussion about https://www.mediawiki.org/wiki/Wikimedia_Product_Development/Product_Development_Process/Draft ) :
Howie: mapped out so it doesn't misrepresent any team's process
Lila: define exit criteria, and roles
Erik: interesting to look at Grantmaking department's learning patterns library
as a PM, such a pattern could give me good guidance while still retaining flexibility
Lila: that's the next step after defining process, the howtos
Erik: exactly
Rachel: https://www.mediawiki.org/wiki/Community_Engagement_(Product)/Collaboration_Process/Draft
mapped out which tools CLs are using for community engagement
e.g. IRC, VE newsletter
tools will need to match against personas
what problems does it solve?
is this for English Wiktionary? for RTL languages?
is the product intended to change workflow? (this causes most concern with experienced editors, who are afraid their workflows will break)
"nobody told me" problem
Lila: need a way to notify users
Rachel, Toby, Tilman, Erik: don't have email for every user, CentralNotice is main tool for that
Rachel: don't have Beta notifications
concerns about banner overuse
Erik: Beta Features was last feature we developed for this kind of thing
Jared: Beta Features being only accessible to logged-in users is huge problem for getting wider feedback
not fundamental reason for that
Erik: I think existing mechanisms like CN can be sufficient if used better
get the most opinionated users to subcribe to newsletters, etc.
products which handle that most successfully are putting a lot of effort into newsletters, blog posts
unlikely to ever have email for all users
Lila: but could require on mobile
Erik: possible
Lila: problem that we can't reach all users in consistent way
should do what we can to incentivize people to give access, without forcing
Toby: have to earn every additional piece of [personal] info from user. also: nobody uses email any more ;)
Howie: ...
[slide 14]
Erik: for ideation phase, we have the tools we need
for resourcing, need to know timing of strategy consultation, which will draw half of Rachel's team
Lila: we should do this
Erik: can carve out time for this, but it will need to come from somewhere
Rachel: plan to map out community differences (e.g. which use watchlist notifications)
Jared: recently turned off compact personal bar Beta feature, got reactions from people who want to turn it back on
for Hovercards, requests to make it stable
Lila: why not prompt users who don't yet have a popular beta feature, watch how many turn it off
Rachel: yes
Erik: Content Translation
Lila: monitor disable rate
Erik; it will be low for CX because it does not change existing workflow
Lila: that's why disable rate targets will be different for different products
Wes: my high-level feedback:
speaking a common language will be beneficial
give audience visibility so that they *want* to reach out
anyone should understand pattern, what you want to achieve
Lila: VE is at tail end of that process