VisualEditor/Complaints

Complaints about VisualEditor and its deployment. There's no guarantee that any of these complaints are legitimate, but most are fairly common. In some ways, this document serves as a post-mortem.

Opt-in v. opt-out

Probably the single largest complaint currently.

User preference

Second-largest complaint. There was a deliberate choice to hide a user preference that allows completely disabling VisualEditor (after having provided the user preference during the "alpha" period). This really pissed off users.

Users had to fight tooth-and-nail to get a user preference re-added that allows completely disabling VisualEditor. The VisualEditor team implemented a compromise by explicitly labeling the user preference as temporary.

This create a lot of bad will very early on and set up a battle mentality with a lot of users.

Default editor

Making VisualEditor the primary/default editor angered editors at several wikis where this was attempted. The project manager gave assurances that VisualEditor would not be made the default editor without asking the community first. In an unannounced move, VisualEditor was made the default editor for new users. The default was structured to be invisible the existing community, which was viewed by some as an attempt to set VisualEditor as default by stealth. In the case of English Wikipedia the WMF did not reply to multiple objections for almost two weeks. It was necessary for several users escalate the issue to the Executive Director. The manager then gave assurances he would change the default. However after two weeks of inaction, the manager stated he would not do so. This resulted in outrage and accusations of "lying". The English community responded by drafting a sitewide javascript hack that would override the default. The wikitext editor was then made the primary editor. Complaints from other wikis were similarly disregarded or rejected for months.

Poor communication

The VisualEditor team played very little offense, meaning they're largely now playing defense. Being more proactive and responsive would have been better. Not necessarily from the technical side, but from a community management or expectations management side. The German Wikipedia, the Dutch Wikipedia, and the English Wikipedia are now all revolting in one way or another. This indicates that something went terribly wrong.

Timeline

A seemingly fixed, arbitrary timeline for deployment. Rather than taking small incremental steps forward, we've hit "big steps forward, and big(ger) steps back."

July 1 deadline come hell or high water. Backlash from this rapid deployment will be severe.

Labeling

Calling the software "beta" prematurely. Many people feel the software is not anywhere near feature complete and should continue to be called alpha.

A tangential complaint has been raised that using the term "beta" is largely opaque to users. It should instead be called "buggy" or "experimental."

The beta notice was not prominent enough in the user interface. No easy ability to add a notice to the VisualEditor editing interface.

User interface inconsistency

Differences between deployment of VisualEditor to MediaWiki namespaces change the context of "edit".

Performance

VisualEditor is slow, particularly for large articles.

Compatibility

VisualEditor doesn't work with many browsers, which confused a lot of users.

Visual Strategy

VisualEditor was created with an intent to become the primary editor, and a strategy to deprecate wiki syntax as the primary input method.[1] A strategy was undertaken to allocate vast resources to the project, even at the expense of other activities.[2] However this vision was never made clear to the community. The community was never on board with this grand strategy. When Visual Editor was introduced it was largely viewed as merely a "second editor" offered to those who might prefer it.

The value of a Visual environment were severely overestimated. A May 2015 research study VisualEditor's effect on newly registered editors found that VisualEditor brought none of the anticipated benefits. The strengths of Wikitext editing were also severely underestimated. As of 2018 editors still overwhelmingly chose Wikitext editing as the best tool for the job. The community firmly considers Wikitext to be the primary editor, and considers VisualEditor to be a minor secondary editor.

The strategic disconnect between the Wikimedia Foundation and the community has been a major and continuing source of discontent and hostility. The Foundation's efforts to push VisualEditor as the primary editor are widely viewed as mysterious, clueless, aggressive, and harmful. At times these efforts are even viewed as malicious. The Visual Strategy has often faced tradeoffs between Wikitext editing and Visual editing. When tradeoffs are made at at the expense of Wikitext editing, they are often viewed as active sabotage of the primary editing environment. The strategic decision to allocate heavy resources to the project at the expense of other work has left the community frustrated and angry at the lack of attention to core tools and other important work.

Some examples of this pattern include: Pushing out VisualEditor before it was ready, the strong resistance to rolling VisualEditor back to opt-in when it was causing excessive damage and disruption, hijacking of the "edit" link for VisualEditor, efforts to force new users into VisualEditor by default, pervasive promotional messages viewed as pro-Visual propaganda, abandoning important work on DIFFs to build VisualDiffs instead, hijacking the 2017WikitextEditor project to try and force editors into a "new wikitext mode" of VisualEditor which was slower than the Wikitext editor and had defective previews, ignoring intense warnings from the community and building Flow entirely around VisualEditor which resulted in severely defective Wikitext support, and a general lack of resources for non-Visual work.

Bugs

1

Users not trained well in how to effectively report issues. Lots of "I hit edit and nothing happened." reports. These generally indicate a JavaScript error, but nobody is explaining how to find/report those kinds of errors (e.g., checking your Web browser's JavaScript error console).

2

A general feeling that bugs aren't being acted upon quickly enough. Multiple complaints about users coming to report an issue only to find it had already been reported and still wasn't fixed. "I've hit this same issue and see it's already been reported, why hasn't it been fixed yet?" There's no way to aggregate bugs, so seemingly small issues affect larger numbers of users. And larger number of users become disenchanted/disillusioned, even if the bug is relatively simple to resolve.

3

Many bugs in VisualEditor are very obvious. "Why weren't these bugs fixed prior to the beta release?" Deploying the software very prominently and including glaring issues has been viewed as a sign of disrespect toward the editing community. And in some ways toward the volunteer community. Related to the following point.

4

"You're wasting our time." Arbitrary insertion of <nowiki> tags requires cleanup by other users. Watchlists become noisier with reverts of good-faith edits. Editors aren't aware that they're damaging articles. Volunteers feel as though their precious free time is being wasted cleaning up after a product they didn't ask for.