Last modified: 2014-07-21 10:46:44 UTC
(Very provisionally filing this for the BetaFeatures extension, but it's also possible that core or a new extension is the right way to do this.) Some of the things learned from un-beta-fying MediaViewer: * It is important to test widely with anonymous editors, they will have different issues (especially so if the interface is different for logged-in users). * If a feature which is not limited to logged-in users has an optout, the optout should work for anonymous users. * Opt-out statistics would be a very valuable source of feedback, but the current representation (where a missing user_properties row can either mean that the user never touched the setting or that they set to the same value which happened to be the default) makes it close to worthless. * Our current preference page is hard to use, and not a good place for an opt-out switch (or at least not good as the primary location). There should be a way for one-click optout from inside the application. * Designing a good opt-out workflow is hard, especially when the new functionality replaces something else. The user should be able to experiment with the old and new interface, seamlessly switching between opted-in and opted-out state, in the same interaction flow, before making up their mind. This should be supported by standardized UI elements (dialogs, config/optout icons etc). To support all this, BetaFeatures (or something else) should provide a toolkit for new products to easily build a good optout workflow, including: * a way for anonymous users to opt in to beta features; * an easy programmatic way to set enabled/disabled state, so that it works both for logged-in users (stored in user preferences) and anons (stored in localSettings, maybie cookies); * tri-state settings (default/enabled/disabled) instead of the current bi-state settings (default/enabled for beta features, default/disabled for graduated features) * standard widgets to provide a uniform optout interface across features (e.g. a stadard button icon, guiders/dialogs) It would also good to have support/guidance for how to measure optouts, especially for anonymous users.
I'm not sure that BetaFeatures is the best place for this. It is the deliberate intention for BetaFeatures to… * … ONLY be for opt-in features, and * … NEVER be used for reader testing. There's a bunch of documents describing this from a user/product perspective, but essentially this feels at heart like a MediaWiki core need.
IMO the obvious path for BetaFeatures is to become a feature switch framework, with options like "deploy to 1% of users", so those rules should be eventually relaxed. That said, a good enable/disable workflow is something mature products could use as well, so you are right about this making more sense in core. BetaFeatures should still support anon opt-in, though. One of the things we learned with the MediaViewer deployment is that the English Wikipedia has a significant amount of anonymous users who have pretty much the same power user expectations as active editors (they edit description pages, they care more about the metadata than the image etc), and treating them as readers just because they don't want to log in will end badly. There should be a way to invite these users to test beta features just like we invite normal editors.
> * an easy programmatic way to set enabled/disabled state, so that it works > both for logged-in users (stored in user preferences) and anons (stored in > localSettings, maybie cookies); For MediaViewer, this was implemented in https://gerrit.wikimedia.org/r/#/c/138766/ and https://gerrit.wikimedia.org/r/#/c/140259/.
