Wikimedia monthly activities meetings/Quarterly reviews/VisualEditor/March 2014

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's VisualEditor team on March 26, 2014, 1:00pm-2:30pm

Present: Howie Fung, Gabriel Wicke, David Chan, Rummana Yasmeen, James Forrester, Erik Möller, Sue Gardner, Phillippe Beaudette (partly), Moriel Schottlender, Tilman Bayer (taking minutes), Roan Kattouw, Jared Zimmerman, Trevor Parscal, Rob Moen, Ed Sanders, Terry Chay (also taking some minutes)

Participating remotely: C. Scott Ananian, Maggie Dennis, Subramanya Sastry

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

Our goals and objectives
Progress in 2013/14 Q2 & Q3
Proposed work for Q4
Questions and general discussion

James: welcome
this time, covering two quarters (Q2, Q3)
(Re-intros / visiting team members): Moriel Schottlender visiting from NYC (contractor, formerly OPW intern), Ed Sanders visiting from UK, David Chan visiting from UK (partly on Language Engineering), Rummana Yasmeen (doing day-to-day QA testing), Rob Moen visiting from Portland

(James:)

Goals and objectives

goal: be the best editor (default for Wikimedia wikis), --> objectives like enabling table editing, support for Chinese, etc., expand ecosystem (get 3rd party developers on board etc.)
work in the last 6 months - get closer to a complete replacement for wikitext editor, and also make things easier (e.g. adding refs)
example: last review, didnt have image alignment (left/right)

Citations Demo

(in testing: plan to production in 2 weeks)
Shows demo on http://en.wikipedia.beta.wmflabs.org
click on ref, edit "cite web" and other ref templates
not released yet
prominent link to add citations, configurable by local wikis
Sue: can we have a look at "cite book" too
autofill from ISBN?
(James:)
not yet, but in Q4 (based on ISBN, DOI, URL)
Lots of other optional parameters that the community has added, but can be hidden
Erik: community specifies via template metadata which parameters are required
James: could change VE so that saving ref is not possible if required fields missing
Erik: ideally we should allow community more direct/fine-grained control of what VE regards as required
Sue: When this rolls out, I'll be using VE full-on all the time;)

Progress on Works for Q2&Q3

References: citations template (in testing)
Basic media dialog
Advanced media dialog
rich text copy and paste - done
red links - done
HTML comments and hidden content (not done, started work)
- - important because they may contain advice and warnings for editing
- design work not done due to competing concerns
in-line & block level language settings (not done, started work)
- important for Hebrew and Arabic wikis due to mixed texts
- plan to release as a beta feature, work deprioritized for other stuff
galleries, equation editor, code block editing (GSOC last year) (partially done)
- equation editor is a beta feature (getting feedback), still as a LaTeX source code editor, but seeing results immediately
- source code editor bugfixing was de-prioritized
- basic gallery was released, but not that good
- hoped that Wikia would work at a general integrated media editor, but they decided not to

Sue: Wikia still working on VE in general?
James: Yes, they had a team of 3, now a team of 2

better browser support (not met, some work done)
- still investigating IE incompatibility
- changing browser market means our support% increases automatically ;), but still need to add support for older IEs

low-speed connections will remain problem (even on desktop)

extensibility and plug-in - done
ability to bail from VE into wikitext - done
- added one-way escape from VE to wikitext
Basic table structure editing (not done, de-prioritized in favor of other things like refs)
set/change first behaviour magic words (redirect, disabling TOC, title override) - done
- page title override isn't technically launched in production, as de-prioritized
Working with four other teams:
- Flow, to integrate VE - stalled
  - due to prioritization in Flow team - too difficult for them to do right away
- Mobile - fruitful relationship, tablet offering on alpha - started (on-going), next: links and citations
- Multimedia - in-page media upload - started. At present need to open new tab, like in wikitext. currently working on this
- Language - variants editing (e.g. zh-hans / zh-hant conversion, Kurdish, Urdu) - not started
  - apart from Chinese, not a high priority in Parsoid issues/blockers
  - blocked on some UX questions (zh- see above)
  - David: discussed language management in templates - one edit could disrupt thousands of page
  - CScott: there is an RfC about that under review next week
  - Gabriel: direct editing of translated version will probably not be possible
  - James: it's a hack implemented in 2003, not used elsewhere on the web
  - CScott: This is also a political choice in China, it's like british/american spelling issue but where people can't comprehend each other
  - Erik: Consensus is not introduce regressions, and then discuss what to do before doing anything more
drag and drop updating of ToC - not met, but mostly done
- as you change the heading, you can see it in TOC (thanks to Rob's work)
- haven't switched it on yet until people wanted. Eventually want to be able to change position of TOC by drag and drop
Deploys:
- deploy to all supported namespace on WMF wikis - done
- deploy to some private wikis - done
- initial deployment on non-Wikipedias - done based on community invitations: some communities requested us to switch VE on as default
  - FR-wikiversity…
- re-consider "content munging" (not met)
  - decided not to do yet because we don't know what to do yet
  - featured article icon, padlock icon for protected articles, etc. are put in by CSS hack via templates, breaks VE but we should be able to fix this
- make slugs less odd (outline model?) - Done
  - blank lines that aren't in the article as it's visible to readers, but are inserted by VE so editors can place cursor there
  - some might have outline mode to put cursor in there
  - ed making it so that they animate to highlight that they're not real lines
  - Erik: e.g. makes it clearer when editing page with infobox
  - Sue: yes, I remember being confused by those extra newlines, but not recently (i.e. the fix worked)

(James:)

- Stability/performance/scalability - Done & ongoing
  - We do this all the time, but important to highlight
  - Trevor: closed bugs?
  - JamesF: don't know, but usually I'm the #1 closer of bugs nearly every week (more than the next 4 people combined), probably around a thousand
  - Sue: quantify improvements to performance?
  - JamesF: for indvidual changes yes, but not overall
  - Roan: A lot of performance stuff is in pipeline, found that it was harder to do than it seemed, so put it aside (e.g. in July last year, typing got slower in some browsers due to one change)
  - Trevor: aside from catching regressions, it's difficult to track performance over time because a lot of performance issues are in features that didn't exist before.
  - Erik: We have the new latency graphs: https://gdash.wikimedia.org/dashboards/ve/ , this e.g. helped find a API overload issue (see the spike in the 1 year graph)
  - Erik: VE is now forcing us to truly maintain stability of API :).
  - Sue: Page loading time and stuff? That is relative to wiki syntax, is it? A lot of the initial complaints were perception issues - stuff that took long in wikitext, too
  - Trevor: we don't have the baseline, no.
  - Erik: it's worth looking into because in some cases VE is faster than wikitext (no page reload). Overall, ideally we should have monitoring in place to track performance in relation to deployments. A lot of this is developed in partnership with Ori as senior performance engineer who's working on deployment integration as well. This is more important than the direct VE-wikitext performance comparison, but agree VE/wikitext comparison is useful for storytelling.
  - Sue: Not sure how important that is vs. the storytelling of VE/wikitext thing
  - James: E.g. consider initial loading of VE code (about 300kB), which may not be necessary for a week afterwards
  - Erik: with Ori, thought about detecting computer/network performance, if machine/network is too slow, offer wikitext only (Gmail does something like this)
  - JamesF: loading pages and saving is about 4-5 secs(?) and goes up from there; now improved by preloading stuff when opening save dialog

Sue: from perspective of regular editor, VE feels much faster now. There used to be noticable lag when I saved in the past, but it's better now.
James: should still get hard data
Sue: people forget things weren't ideal with wikitext either

Expected Deliverables in Q4

big picture: improve what we've got, make VE the better alternative even for experienced users

Make citations even easier with autofilled ISBN, web links, etc
Provide an easy way for users to upload media to Commons and use them in edit
add image editing tools for less common/advanced power user tasks like giving an image a different link, or precisely aligning images. a number of power users really want them
improve and release the tool that makes it easier to edit templates' information for all wikis, so that VE users get helpful hints
- right now it's JSON code-like. only for super-power users, make it accessible for normal power users ;)
- Erik: Important thing to call out is data-driven citations piece -- could make citations vastly more accessible, is hard to do and crucial for the editing process. Getting this right would be huge. Everything else next quarter is gravy.
- Sue: agrees, in my case learning to add citations (finding ref tool) took me out of normal text writing mode
- Erik: in some other areas you will still need to use wiki-text, e.g. templates. There will be those corner cases, but the majority of cases it'd be nice to have rich editing surfaces
- (James:)
work on non-Wikipedia editing tools
- Haven't sat down and worked out the issues that people need on these projects (e.g. ProofRead page on Wikisource, Wikivoyage, a litle Commons)
improve support for users' browsers
- really meaning Internet Explorer
- Roan working on some DOM thing to make Chrome 2x faster (it was something that Firefox added a while ago but none of the other browsers started adopting until this year)
Stability/performance/scalability (on-going)
- improve the speed of the editor for users so that they spend more time making edits, and less time waiting for things
other big thing: basic table structure editing (was already in last review though ;)

deferred from Q4:

real-time collaboration
drag & drop for non-image content
editor switching mid-edit
arbitrary user CSS
non-template transclusions
rich nested templated editing
- Gabriel: actually, Parsoid is pretty close to solving this.
putting VE & WT into one edit tab
stable 3rd party release of VisualEditor
getting VisualEditor bundled into the 3rd party release of MediaWiki
- Sue: I got asked about this at LibrePlanet. I agree though it's not a core priority
- JamesF: it does have value though, e.g. MarkH wanted to get it working with IE, found a lot of bugs in the process

Summary: Made progress, not as far along as we'd like, but we did make core editing easier.

Questions

Erik: we are on the same page on priorities. let's talk about team relationships.
relationship with Mobile is the most important one (VE on tablets, smartphones). still very experimental, but understand it's priority for them
worked a lot on VE and UX relationship in last three months, still challenging at times - VE is a very complex project, has to deal with intricate features that designers may never have heard of yet
designers would like to build new editor from the ground up, which VE can't do
Kaity will be embedded designer with team, getting better understanding
Sue: apart from this "green field" illusion, there is also the opposite problem - pressure on designers to just accept existing complexity
Erik: Citation issues were a combination of both of those problems
Erik: The VE roadmap is a really good document which is updated every 2 weeks. It has a section on things that are blocked on design. Gives a lot of visibility into the work being done
James: demos simplified UX on beta.wmflabs
Trevor: we perhaps became a bit insular, unintentionally. embedding might work for solving this.
Sue: insularity seems totally natural to me, team has been working on something that is unbelievably complicated
deep work has been getting done, coming more to the surface now
one of the costs of having a team that knows each other well, collaborates intensely is that there will be outsiders
Erik: Gut feeling is we're crossing the threshold from "you can do stuff but it's painful" to "hey, that was easy!". Having those moments more and more often. It's not quite there yet and need to be careful, but want to create more of those moments. There's a good amount of polish that needs to be done, even for basic things like link dialog
Getting positive feedback from experienced users that we didn't get half a year ago
Trevor: waiting them out, and wearing them down ;)
James: Mentions user-testing video demo of add-a-citation [no url available]
user not expecting having to press save (this is not necessary on Google Docs), but understand that WP might be different
considering to save automatically to non-public user-specific draft, rename save button to "Publish"
Sue: great idea
Jared: Everyone on VE team reviewed the videos. Overall people had a successful time, a few points of confusion (e.g putting bad content in web citation breaks it) are already being acted on: showing two access points for ref editing
design todo items: required/recommended/optional template parameters
make sure access points make sense to users
know about frequent errors and accidents
e.g. do I place ref at cursor, or first highlight the sentence being referenced?
Erik: great that we do this kind user testing again with VE (it's been a while), should we be doing it routinely? What's your thinking around that?
James: we can do that, worry about bandwidth though
Trevor: right now for specific features. like to see us do it more because it can pick up a lot of other things, possibly more relevant than bug channel
Erik: might be more a monthly thing
Jared: you don't get a lot of feedback on things you aren't testing
Erik: We're hiring permanent UX researcher, so that should help put structure around that.
Jared: close to hiring (few weeks)
Erik: product managers used to own this, which means implementation/commitment varies, separate ownership will help
Erik: other asks? James: no
Sue: seems most blockers and impediments were about design and user testing, being fixed now. Others?
Trevor: other thing: CE (Contenteditable) engineer hire, David filled in for a lot of that
James: kind of a replacement for Wikia ;) Highly specialized role, difficult to find.
Sue: so what do we do about it?
Erik: don't have to solve it in this meeting. Should work on job spec
Trevor: for this role, tension between product vs. browser. We should have started building relationships with browser vendors and now 3 years later there have been multiple iterations of browser releases that could have reduced the difficulty of the CE role.
Sue: Last time, talked about high level agreement for VE rollout to current non-default projects
James: said we would get citations done, then open dialogue about requirements
in particular nlwiki, dewiki, eswiki
rolled out to 165 wikis by default now
Jared: consider # of Beta Features signups (around 30,000[?] now)
Erik: not the time to decide about approach yet
Sue: while engineers do their work, community liaisons should be involved in this planning already