Wikimedia monthly activities meetings/Quarterly reviews/VisualEditor-Parsoid/November 2013

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's VisualEditor and Parsoid team on November 6, 2013, 12:30–15:30.

Present: Roan Kattouw, Trevor Parscal, Gabriel Wicke, Tilman Bayer (taking minutes), Rummana Yasmeen, James Forrester, Howie Fung, Tomasz Finc, Sue Gardner, Erik Moeller, Terry Chay (from 1pm)

Participating remotely: C. Scott Ananian, Marc Ordinas, Arlo Breault, Subramanya Sastry (Subbu), Ed Sanders

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:

• Parsoid
  • Our objectives
  • Progress Q1 2013/14
  • High-level goals for 2013/14
  • Tasks Q2
  • Questions and discussion

• VisualEditor:
  • Our objectives
  • Progress in 2013/14 Q1
  • Proposed work for Q2
  • Questions and general discussion

James: Welcome
this is Q1 review, Q2 forward look
welcome Rummana, joined as manual tester last week

Parsoid

Presentation slides: Parsoid

Gabriel on Parsoid:
basically same agenda as last time...
what we do: deal with wikitext, so you don't have to
wikitext <-> semantic HTML + RDFa
Q1 goals: (slide)
2 straightforward ones (but coming back to haunt us now)
some progress on image editing, but not done. hopefully wrapping up this quarter
public HTML API: problem - MediaWiki has everything wrapped in JSON, does not work well for this
stopgap measure: simple API being deployed
Erik: which VE features are blocked on that?
James: All of them – e.g. setting alt text, or alignment of an image
Storage API "Rashomon" (formerly "Storoid")
Using Cassandra as backend - looking good so far, fast
on track for Q2
language support:
hard. Q2 support for basic editing
work with community on bot-fixing constructs...
Erik: (explains) e.g. dynamic conversion between Chinese writing systems on zhwiki. There is specific markup to designate part of page being in a different writing system. Adds complexity
(Gabriel) complex rule system based on templates
these are research topics
need to weigh alternative approaches
(Erik: i.e. support the current system)
switch between HTML and wikitext within one edit
is a research topic, have ideas about how to do it elegantly
Wikia works on a similar feature, but they don't try to preserve information while switching, as we want to
Erik: example of what gets lost in Wikia approach?
Gabriel: e.g. authorship maps
James: so Wikia approach is slower, and causes dirty diffs?
Gabriel: also, diffing harder
Erik: how about Wikia's feature as interim solutions
James: risk of dirty diffs?
Subbu: I think Inez was talking about using selser [selective serializer] as well to not introduce dirty diffs, but we have to see how it works out Gabriel:- right, but dirty diffs from selsering a few times still accumulate, not acceptable
Erik: has Wikia's code been committed yet?
Roan: still in development, but seen it
Erik: so this might be a viable interim solution
Gabriel: what we can do immediately is to enable the switch VE -> wikitext editing, already being deployed
Erik: cf. John Vandenberg's hack
James: there was a complaint that this loses the VE edit tag - need to fix this
(Gabriel:)
enforce proper nesting of transclusions
template expansion should not cause rewrite of whole page
tradeoff: the more we restrict things, the finer-grained visual editing and dynamic transclusion updates can be
example: (breaking up <ul> list)
James: example on dewiki: name disambiguation page which trancludes list items from other pages [i.e. something like "{{:Alfred Martin}}" in https://de.wikipedia.org/wiki/Martin#Namenstr.C3.A4ger ]
(Gabriel:)
inserting a page-breaking tag (for example an unbalanced <div>) might not preview correctly in VE (i.e. page-breaking change might only show up after saving)
need to discuss with editor community about such a restriction in editor (prevents brokenness, improves performance)
Very few legitimate uses for this
Erik: this suggests a change to MediaWiki core?
(Gabriel:)
that's lower on the list of what we would like to do
Erik: so basically a tag marking such template
Gabriel: yes
Subbu: two distinct issues: 1. balanced tags producing single DOM tree (as Gabriel and James mentioned .. table start/end, etc.), 2. even when a block produces a balanced tree, it could affect page structure outside
both need to be addressed for efficiency and easy editability, and that is what we need to discuss between VE/Parsoid and see how we handle templates that might not conform.
(Gabriel:)
Marc did a lot of work on roundtrip testing infrastructure, now see results overnight instead of after several days
identified several performance issues
more work needed, some as OPW project
Erik: is this related to Ori's Ganglia stuff?
Roan, Gabriel: no, this is only about parsing performance
(Gabriel:)
next step: test full stack, integration tests - VE/P integration testing in beta labs
James: no roundtripping tests there yet
(Gabriel:)
more efficient template reuse / updates:
blocked on rev storage... Rashomon should help there, this quarter
Q1 progress: post-release work
eliminated a lot of tech debt
reached long tail now with rare edge cases (e.g. affecting only 10 pages on entire enwiki)
tone has changed a lot in bug reports
actually we found and fixed (Scott) some ancient bugs in old (PHP) parser, too
bonus features:
job queue fixes (after MZ's mass test null edits)
prioritize edits over background tasks
for mobile etc: serialize to XHTML5 (parses as HTML too), easier for postprocessing with XML libraries
Mathoid: currently, MediaWiki renders math formulae to PNG. Moritz Schubotz visited us, worked on improving math rendering - MathML + SVG
also helps accessibility (blind people can now read formulae)
part of the general move towards more semantic markup
Progress Q1: more users

• Flow
• Kiwix - very early adopter. already exported Wikivoyage, French Wikipedia. they push for API to become available
• PDF rendering - investigating. they threaten to use Parsoid output directly if no API ;)
  

Mobile: Wikipedia app likely going to use Parsoid output by January (replacing their mobile frontend which massages PHP parser output)
High level goals for 13/14:

• VE support
• leverage HTML in core
• HTML-based template editing?
  

Q2 tasks:
Features:

• image editing refinements
• basic language variants support
  

storage:

• simple API - deployed right now
• Rashomon storage - prototype testing this quarter. get interface up soon - if Cassandra doesn't work out, replace it with a different backend
  

Rich metadata and wikitext:

• unique IDs - e.g. enables tracing & metadata preservation while copy+pasting across pages, even across different wikis
  

DOM:
tranclusion parameters -> DOM: mostly in place now, but need to treat exceptions
Erik: (...) so this is a small subset of templates?
Gabriel: yes
Erik: so we do full typing of templates now?
James, Gabriel: type hinting, yes
(Gabriel:)
enforce proper nesting of transclusions
discuss with community: e.g extension tag
expose the information we have about improper nesting to wikitext editors, maybe enable bot cleanup
not so much a technical challenge (information is available), but discussing and deciding which things to fix
Ongoing work this q:

• Testing infrastructure
• compatibility: long tail
• performance
  

tasks on the horizon:
HTML-only support
deploying to non-WP projects: investigated this a bit. likely hard. labeled section transclusion is an issue
not sure we can prioritize this in this q. James: no, we can't
DOM-based templating
Parsoid for all pageviews: we will see, it's a stretch goal

Erik: timeline is ambitious
Gabriel: these were stretch goals

--break--

VisualEditor

Presentation slides: VisualEditor

James on VE:
the less sunny side of this review ;)
in q1, switched VE on as opt-out on e.g. enwiki - and switched it off again
Erik: this was the fun quarter ;)
Sue: a look back with mixed emotions ;)
James: long-term goal: VE becoming the best UX on WP, also reused outside MediaWiki
for that: work on better editing tools (usability), more editing tools (e.g. galleries), stability and performance
look back on proposed work for Q1:
ref citation template: not met, some work done: UX proposal done, in Q2
Erik: are we going to have a version up before Trevor goes on leave ?
Trevor: halfway done towards the point where someone else could take it up
Erik: who would take it up? Timo
Erik: could bring him here for collaboration on this
Erik: to be fair, we are solving a much bigger UX problem with that now - how to insert a complex template in general
Roan, James: yes
Trevor: also bringing over VE's existing simpler template editor
Erik: fundamental problem: multitude of project-specific templates ({{cite book}} etc.)
Trevor: also want to streamline it so it's not separate tasks to add ref and to add / edit citation template
draw user along, e.g. do not ask "what citation template"
Sue: optimize for inexperienced user?
Trevor: didn't want to build tool that can only work with specific cases
but for creation of new citations, narrowing choices is fine
Sue: recalls how it looked at VE launch
Trevor: we went down the flexibility rabbit hole
Sue: yes, this became a tool for advanced users, who actually don't need it that much
became harder than wikitext in some cases
James, Erik: showing https://www.mediawiki.org/wiki/VisualEditor/Design/Reference_Dialog developed by Kaity
Sue: is this the final list of ref parameters? no, just mockup
Trevor: we try to avoid software that knows anything about the wiki's content ;) community would decide about parameters
Sue: why doesn't it look like usual forms on the Internet? (outline on the left, instead of listing all forms immediately)
Trevor: too many fields otherwise
Sue: still, left column could be distracting
Erik: low hanging fruit: could lose whitespace,...
(more discussion about ref dialog tabbing ...)
Trevor: also, the designers worked backwards from what we gave them. not married to this dialog form
Howie: how do we validate this design with actual users?
Trevor: could track clicks, do additional testing
Howie: maybe TOC is useful the 2nd time around, but perhaps not for newbies
Sue: what most people try to do (when adding refs) is not a complicated task per se
what i have in my current setup as editor (for non-VE editing - cite button in edit toolbar) is more user-friendly. shows all fields at once
encourage designers to think from average use cases: adding refs
James: need to give the community space to be able to tell people how to fill out, e.g. last name, conform to MoS so they don't get shouted at
Sue: existing (non VE) form is pretty good, let's me fill out/skip fields in one view, do not need to select tabs in outline
Trevor: agree this looks more compact, perhaps there is room to improve the VE version in that respect. but people in this room did not design it, need to talk to designers directly
Erik: easy improvements: collapse outline, and get rid of whitespace.
need to decide about more obscure fields. maybe define a default set of the most important ones
James, Trevor (further discussion about design options)
Trevor: trying to have generic approach that community can customize
Sue: OK, but design should work from non-VE implementation, which is more user friendly. think from user's perpective
Roan: I think it could be made more compact
Erik, Trevor: need generic solution that works across WPs
Sue: but it's fine to also provide an enwiki-specific version that works well
Scott: there was a fundamental assumption that things have to work cross-wiki, but there may be exceptions
James: remember that the goal here is to add a cite button to all wikis, even e.g. dewiki which doesn't even have one currently
Sue: this is a basic function for article-writing, not a specialized task
Scott: not arguing that wiki-specific solution will necessarily be better, but we should not restrict our thinking
Erik: should rethink design, ideally not in a way that is hardcoded for enwiki
Trevor: repeats that we don't have the right people in the room for this discussion
Scott: avoiding wiki-specific hardcoding is an argument from the coder/implementers' perpective (i.e. mine ;), but that should not be the only perspective
Sue: reiterates that design team should think about what is best for end users (compromises can come later)
Trevor: argues for the flexibility that templates give to the community. we need to be careful with restricting that with our code
Sue: agrees, but some of the things we talked about do not touch that
Roan: concerned about speed of design process - these mockups are 5 weeks old
James, Trevor, Tomasz, Erik: (discussion about availability of designers, workload on them from other VE design tasks)
Erik: but overall it seems we are not blocked on design
Trevor: user interaction stats (Eventlogging) could yield valuable input for the design of ref templates
there are other usability issues, but trusting that Vibha can work these out, it's one of her strengths
(James:)
Q1 goal: media settings
Wikia didn't get to work on this as hoped earlier
in Q2; restarted work on this
HTML comments: not done due to other work
but I would like to change that, it's a bad experience for newbies if they get burned because a warning HTML comment was hidden from them
galleries, equations, code - not met, some work done:

• eq editor: deployed for testing now
• source code editor: completed, not yet deployed (bugs)
• gallery editor: Wikia's not ready yet
• in-line and block-level lang settings: (hewiki really wants this) - not met, some work done. GSOC for inline
  

Trevor: have a solid solution for block-level
Erik: current handling? no attributes on divs
Trevor: reluctantly, we decided this might be one of the first things in VE that don't allow direct manipulation (i.e. doesn't show in direct view - separate panel instead)
(James:) rich text copy&paste: done, but not deployed yet
Roan: discovering new issues every day with paste - keeps slipping
Gabriel: resolving longer term issues with IDs (see above). also an issue with Flow (C&P parts of discussions)
(James:)
Nowiki block editing: done (minor bugs on backlog)
redlinks shows as rad, stubs as purple - postponed
integration consistency - e.g naming of edit buttons
extensibilty, plugin architecture - mostly done
stability/performance done,but ongoing
244 non-enhancements bugs fixed in Q1
clientside perf improved too. no hard numbers, but could try to get them
Roan: yes, intend to work on getting them
proposed for Q2:
carry-over tasks from last q: ... (see above)
as planned:

• lang variants - need to deploy on zhwiki
• VE -> wikitext "bail" during edit
• drag & drop for TOC
• behavioral magic words: redirect, NOTOC, DISPLAYTITLE ...
• integrate VE into Flow (Trevor working on this)
• mobile: make VE available as part of their skin. weren't sure how big this was, but agreed it's important, should start now. right now, tablet uses desktop skin, can use VE (unless your wiki or yourself have opted out ;). for phones, need to redesign VE because of form factor
• deploy for all supported namespaces. (categories: done.) supported = all content or "content-like" namespaces: e.g. main, user, file, category (not; "signed" ones, i.e. those which that usually contain user signatures, e.g. project namespace)
• private wikis: mostly done, deploy in next few days. Roan: Office wiki not before next week
• re-consider "content-munging" (dealing with absolutely positioned content)
  

deferred:

• integration of VE and wikitext into one tab (preference: e.g. edit goes to VE first, or wikitext, seamlessly switch to other one)
  

Erik: imagine a world where VE works flawlessly and is universally accepted. in that world, would want to chose edit mode within editing, not a priori. complex design problem, Vibha is working on that integrated experience
(James:)

• in-page media upload
• non-template transclusion - deprioritized for ref dialog work
• hidden cats
• basic table structure editing - blocked on design (great challenge)
• rich nested template editing
• stable release for 3rd parties - low priority. Roan: but I'm going to do some work on that before the language summit, re i18n
  

(James:)

• deploy to non-WPs. e.g. Meta: hard to do, WV: need time to examine the wiki and discuss with community there
  

Considerations about re-enabling as opt-out on enwiki:
proposed criteria (just ideas so far):

• implement all critical features first
• fix all major bugs - including those causing corruption on a non-trivial amount of pages/edits
• achieve performance benchmarks: median/75% of client/server load/save times must be below XXXX, client-side load burden below XX MB memory/network
• user behavior metrics. e.g. Dario's user productivity metric, which measures whether newbies stick around
  

Erik: eswiki discussion: want proof that (it doesn't deter users). my understanding: we don't break the edit revert data down by editor source, because that comparison has confounding factors [users who chose VE or wikitext might already be predisposed for more productive editing]. More useful to see if total revert trend changes.
James: yes. Dario is analyst who worked on that
Erik: all these criteria will imply making statements about VE's impact on editors. need to be very solid on that
we need a lot of input from Analytics on these criteria
re median/75% criteria, what about worst cases? pages where the load is so high it prevents VE from working? currently there are pages that are impossible to edit on VE, even time out
Sue: what about wikitext editor, do pages ever time out there? are we measuring VE with a different benchmark, a higher standard than for current editor?
Erik: yes, we are. but there are page which broke on VE, but not in wikitext
Sue: these would be conditions we set for ourselves?
James: yes, we could go with this to the community
Sue: so some kind of contract?
document does nothing to capture the benefits of VE
maybe the user productivity metric, but…
not visible: improvement and joy provided by VE UX
my impression through this meeting, might be wrong: to date, it was engineering work. which is fine, but balance needs to shift to usability. (which makes me worried about Trevor's paternity leave, because he is working on such things ;)
Trevor: team was busy (and productive) with fixing bugs, did not get to work on things like this which it intended to work on
Roan: also, had inconsistent designer allocation - but better now
Trevor: it would be great to exceed that, also gets social capital (goodwill)
Sue: actual cost of pushback might have been mainly a reorientation of our resources towards experienced users, away from newbies
Erik: not sure that is true. we did say no to bad ideas (e.g. wikitext editing in VE). the other things the community demanded us to do were completely reasonable, also benefiting newbies (e.g. load times..)
Trevor: I think I can speak for the team when I say that we probably released too early
Sue: Agree. But the proposed criteria seem to omit upsides of VE
James: recall that projects like itwiki, frwiki use VE already. (which is BTW why the bug on Monday was so bad, affected 1600 page on frwiki alone)
enwiki can't turn VE off and then demand to be the main focus of development - it's likely our attention will focus on active users, even if we try to keep the wider focus
Sue: anything to learn from Vector deployment some years ago?
Trevor: happened with Vector too: small wikis that activated it early as a way to get dev attention, shape the development ;)
James: (demos Beta Features)
Trevor: with Vector, measured how many ppl opted in *and* stayed in, as a criterion for default deployment
Sue: ratio of opt-ins as criterion
Erik: but there will be people using wikitext for years to come - which is completely fine
Trevor: yes, with Vector too we were always fine with people still using Monobook - it was about the default setting
what we could not ignore is problems where VE actually made life worse for other people (corrupting pages)
Sue: need to compare downsides with benefits
Erik: there is no way around talking with the community
Trevor: we failed some willing initial users as well, because the features they wanted were not working yet
Sue: I don't think I'm disagreeing with Erik
Erik: just saying that we can't have a numerical criterion that will allow us to march through
Sue: difference between telling and asking
Erik: ask community what it considers as mission-critical blockers
it's not so much about contract, but about continously working with community
we did not have enough usage prior to July 1 launch
Sue: input from casual users?
Erik: VE has a limited feedback tool
surveys is what every startup does...
James: need to wrap up
detailed list of the remaining ~240 Wikipedias, their i18n needs - they need to be talked to too
some easy, some really hard cases (e.g. Kannada, Chinese)

Asks

Erik: What are the team's asks?
Trevor, Roan on new hire...
James: need more engineers, are hiring them
0.5 engineer for language
Erik: is that enough? perhaps not
(James:) David has been doing great work, need to take some load off him
Trevor, James, Roan: Wikia input was less than hoped in last review
Roan: I'll be taking over much of Trevor's stuff during his leave. concern that resources won't suffice to keep all of his projects moving (e.g. ref dialog)