User:Adam Cuerden/Sandbox/Media Viewer
 Article display preview: | This is a draft of a potential Signpost article, and should not be interpreted as a finished piece. Its content is subject to review by the editorial team and ultimately by JPxG, the editor in chief. Please do not link to this draft as it is unfinished and the URL will change upon publication. If you would like to contribute and are familiar with the requirements of a Signpost article, feel free to be bold in making improvements!
|
MediaViewer fiasco enters the Arbitration Committee
You get one shot at rolling out new features for the first time. If things go well, such as with the recent additions to galleries, noone will say very much, the new features will just start appearing everywhere. (Indeed, isn't it time to just make the new galleries the default?) Sometimes, a rollout will go very badly: Wikidata's original rollout to English Wikipedia actually failed, but with more funds and more development, it got another chance, and, while it's not as noticeable on English Wikipedia, mainly serving to massively simplify the former scheme of linking to articles on the same subject in other languages, which formerly required whole hosts of interwiki bots to maintain, and now happens pretty much automatically.
There will, however, always be some objection to new features. Take Echo, the notifications tool that alerts users to messages, mentions of their user name on other pages, and the like. There was an RFC on that, asking for it to be removed, the WMF ignored it, and... it all blew over, and I'm pretty sure everyone likes it now. That isn't to say that this is always a good idea, though: Echo worked as intended out of the box. It had an issue, in that it made the talk page message notifications less visible when it launched, but a small fix later, and it was a perfectly good substitute for that feature - while adding many more features.
However, sticking to ones guns is not so effective when you've removed or substantially modified core aspects of the Wikipedia experience while not offering any replacement for them. VisualEditor's launch suffered exceptionally badly from this. It was very buggy at launch, which didn't help; it lacked modules for handling ubiquitous features such references, which is rather a problem, had some bugs that occasionally mangled page content on save, and was extremely slow. Further, while one could edit pages in the normal, non-VisualEditor way, at launch, and for some time after, the ability to edit sections of an article was a VisualEditor only feature. VisualEditor did not, and still does not actually support editing a single section, instead loading the whole page, and then moving users to that section, meaning that it was actually removing functionality completely. It had a core of good code, but it was in no way ready to launch, and, worse, could not be turned off by any means, with WMF staff insisting that it was the future, and that they wouldn't allow users to hold back progress by allowing implementation of a user preference that would turn it off. It will now be extremely hard to get VisualEditor back onto English Wikipedia, because the developer's actions turned users so strongly against it.
A good general rule is that, when trying to get people used to a radical shift in features, one should make it very easy for them to opt out, and tell you why. If it's painless to opt out, users won't mind having the new, improved features offered to them again in a month or two, after the feedback is taken into account.
Which gets us to MediaViewer.
The Wikimedia Foundation staff are clever, passionate, and generally write excellent code. Unfortunately, they have a tendency to roll out this code without any significant widescale testing first, and are extremely reluctant to turn off their new code in response to feedback.
Wikipedia:Arbitration/Requests/Case/Media_Viewer_RfC
Discuss this story