Wikimedia monthly activities meetings/Quarterly reviews/Core features/July 2014

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Core features team, July 9, 2014, 10:15AM - 11:45AM.

Present: Erik Möller, Lila Tretikov, Howie Fung, Danny Horn, Erik Bernhardson, Tilman Bayer (taking minutes), S Page, Rachel diCerbo, Jon Robson, Benny Situ, May Tee-Galloway

Participating remotely: Keegan Peterzell, Nick Wilson, Matthias Mullie, Shahyar Gobadpour

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:

Part 1 (9:30-10:15 - pre-meeting, no minutes) -- Introduction to Flow
- Talk pages: the crucial use cases
- Talk page pain points: New users and experienced users
- Flow hands-on demo
- Technical challenges
- Flow team goals
Part 2 (10:15-11:45 - quarterly review) -- Recent work + Q1 goals
- Intro Flow team
- Front-end rewrite
- Q1: Mobile web UI work
- Q1: Subscriptions and notifications
- Q1: Teahouse plans
- Proposed metrics

Danny: Welcome
in pre-meeting, we walked Lila through Flow
(Introduction of Flow team members)

Shahyar:
(on rationale for frontend rewrite, and how it went:)
When I joined, we didn't have dedicated frontend engineer
goal: make it polished, shiny
then goal became: make an easier to work with frontend, removing roadblock
switched to template based mechanism (consistent for both frontend and backend)
automate generation of code for user actions (instead having to write new code for each action)
Danny: going live tomorrow, on enwiki so far only activated on a few pages
Screenshot of Mobile UI: currently (today) / new (tomorrow)
Jon:
fixed a lot of awkward code, moved into CSS
standardize UI, buttons
much more future-proof
ErikM: so the icons (e.g. pencil) come from the existing library, that e.g. mobile editing uses? yes
Danny: we call this a Flow board
Lila: This presents starting a new topic as the most important action to the user, do we want that?
or is this a questions and answers page foremost (i.e. finding information as first task), then search would be most important action
Howie: I understand this is more a technical exploration at this point...
Shahyar: will work on this throughout Q1... and haven't gone in depth on investigating use cases
Lila: find out what users actually want, what gives most engagement
also, this uses half of the page for interaction features
ErikM: this view ("Tomorrow") is shown only when...

ErikB:
Technical challenges
e.g. oversighting (highest level of suppression). Sat down with Dan Garry, a longtime oversighter himself as a community member
numerous such things,
other example: spam prevention - no central place for that code
Lila: are you refactoring that? it might be an opportunity
ErikB: had a meeting with Platform, but they have so much to maintain (basically all the old stuff in MediaWiki, apart from the new features that Product is working on)
ErikM: examples for these major backwards compatibility issues?
ErikB: UI - things that were developed like 10 years ago without much usability
ErikM: (explains) suppression is pretty pervasive, in all kinds of user input fields, e.g. edit summaries
but honestly, for very specialized tasks like suppressing edit summary, it's probably OK if the UX isn't very intuitive
ErikB: also logs, CheckUser, .... all have their own tables, accessing databse in their own special way
Lila: tools needs to be decoupled from database
ErikM: yes, but we could spend 3 years cleaning up and refactoring MW...
Lila: Ok, but we are right now creating more headaches in the long term ...
S: Platform is pushing us to use Contenthandler for Flow boards, but that didn't give us anything for free
ErikB: Contenthandler was created by Wikidata and Platform, for Wikidata's non-wikitext content

Danny:
Q1 goals
for new users:
still need to cover auto notifications, mobile UI
Lila: is the existing Notifications system used for that?
ErikB: already using Echo for some
Lila: is it parametrized, so we can change easily later on?
ErikB: not entirely, but we can work on that
Howie, ErikB, Lila, ErikM: (discussion on notification bundling and configurability in Echo)
Danny: we differentiate between new and experienced users. for both of them:
subscribe to individual topics
Erik: reply box is actually a bit confusing, looks like top level (leftmost)
if I get notification, will see general view, not the actual reponse highlighted
May: correct
Lila: basically, I want to respond to what I clicked on
So the highlight is the vertical blue bar on the left. Does anyone else do that (on the web)?
May: have seen it elsewhere. didn't want to add any more boxes
Howie: Facebook does a yellow highlight
May: this is just a first pass, can iterate
(Danny:)
Read and unread notifications
Right now, can only mark everything as read in Echo
We're looking at ways to divide different types of Notifications
Jared and Juliusz are working on a new version of the Compact Personal Bar, which includes a split of Notification types, which implements some of the ideas we've been looking at
ErikM: "Thanks" don't record publicly though; it's a 1:1 interaction
Lila: would be good to have more encouragement mechanisms

-- break --

Danny:
Watchlist items: make them more topic-based, easier to read
know that watchlist is very important for experienced users
Lila: are these grouped?
Danny: in the sense that it only shows the most recent
ErikM: this watchlist screenshot isn't very helpful to illustrate that; normally watchlist combines a lot of different pages into one view
Danny: for a Flow topic, you would only see the most recent message in watchlist
ErikM: (more explanation on how watchlist work in UI)
Lila: discoverability? I did not know I had a watchlist ;)
ErikM: so in the final version, I would see fewer items in this screenshot? yes
Danny: by September, plan to get to Teahouse Questions page
quantitative and qualitative research: talked with Dario and Abby
Lila: want to look at frequency of notifications
Danny: there are things we won't learn from Teahouse example
e.g. talked with Dario about reducing orphaned conversations
Lila: what about an association with an overarching topic, to widen attention to related communities?
Danny: we are actually working on breaking up (a bit) the model of topic as the only unit
show a topic on several pages?
Lila: need continuous UX testing, also in early stages
I failed everything in the pre-meeting demonstration ;)
ErikM: how about a lightweight prototyping framework, like Winter (or even have Flow as part of Winter, although that might be tricky)
Shahyar: yes, actually had Flow there[?], but Winter is changing fast
ErikM: work on a Labs instance
S: how about a Beta Feature?
Lila: but can't do opt-in to Flow on user level
ErikM: could theoretically do opt-in on user (talk) page level, but 1. system isn't there yet technically, 2. worry about fragmentation
Teahouse has advantage of being a separate space
later maybe entire projects like Wikidata
right now, only RL use case we have are some WikiProject pages
Lila: fragmentation within a project might be inevitable to some extent, but needs a time horizon

Danny: Lila, suggestions or priorities for the team?
Lila: I already gave some. As mentioned, very important to test all these patterns
but I think you are on the right path
Do you have a data person?
Danny: talking to Dario, he will help us get a "data buddy", similar to other product teams
Erik: when are we going to start with the Teahouse rollout?
Danny: by September, we should actually be deploying; start engaging about a month before
when we posted about it like a month ago, a lot of enthusiasm, but also concern about bugs
Lila: engagement at Wikimania? Flow will be most important topic
ErikM: several CL are going to be there