This page is outdated, but if it were updated, it might still be useful. Please help by correcting, augmenting and revising the text into an up-to-date form.
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.
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.
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.
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.
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".
VisualEditor is slow, particularly for large articles.
VisualEditor doesn't work with many browsers, which confused a lot of users.
VisualEditor was created with an intent to become the primary editor, and a strategy to deprecate wiki syntax as the primary input method. A strategy was undertaken to allocate vast resources to the project, even at the expense of other activities. 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.
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.
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.
"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.