VisualEditor/Complaints

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

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[edit]

Probably the single largest complaint currently.

User preference[edit]

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.

Poor communication[edit]

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[edit]

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[edit]

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[edit]

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

Performance[edit]

VisualEditor is slow, particularly for large articles.

Compatibility[edit]

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

Bugs[edit]

1[edit]

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[edit]

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[edit]

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[edit]

"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.