In my short time at the Foundation I've seen various problems which have risen due to communication problems between seasoned wikipedia editors, WMF teams and volunteer developers. Echo comes to mind as does the mobile photo upload feature my team designed.
It strikes me that the skin system would lend itself beautifully to bridging this communication gap between developers and editors.
class SkinVectorBeta extends SkinVector { public function initPage( OutputPage $out ) { parent::initPage( $out ); $out->addModules( array( 'echo', 'visualeditor' ) ); } }
Any interested editors could enable this skin through user preferences and be able to see exactly what new features are in the pipeline.
Is there any reason we don't currently do this in favour of various experiments and then a sudden push to production which tends a lot of the time to result in a heated Village Pump discussion?
On 05/28/2013 05:55 PM, Jon Robson wrote:
It strikes me that the skin system would lend itself beautifully to bridging this communication gap between developers and editors.
class SkinVectorBeta extends SkinVector { public function initPage( OutputPage $out ) { parent::initPage( $out ); $out->addModules( array( 'echo', 'visualeditor' ) ); } }
If we literally did this (there was a skin called vectorbeta, that you just chose in the menu), it would cause various problems:
1. The CSS classes wouldn't work (i.e. .skin-vector). 2. It would break conditional scripts (skinScripts/skinStyles) and user scripts (User:Example/vector.js). 3. We would have to do the subclass for every supported skin, for projects that are skin-neutral (which Echo is for example).
However, that's not to say a working beta system is impossible.
Is there any reason we don't currently do this in favour of various experiments and then a sudden push to production which tends a lot of the time to result in a heated Village Pump discussion?
I agree it's very important to communicate before it hits production, and an opt-in beta system could help with that. However, that's not the only reason for experiments. E3 uses A/B test experiments to determine which features actually serve their intended purpose before rolling them out to everyone. Furthermore, the users we're primarily working with (new users) are not likely to hit a beta switch in their preferences (it's impossible for some projects like the signup form).
Also, some people (even some experienced users), are not going to choose beta. They may talk about a feature before it's rolled out fully, but they'll only test the main production version.
Matt Flaschen
On Tue, May 28, 2013 at 7:05 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 05/28/2013 05:55 PM, Jon Robson wrote:
It strikes me that the skin system would lend itself beautifully to bridging this communication gap between developers and editors.
class SkinVectorBeta extends SkinVector { public function initPage( OutputPage $out ) { parent::initPage( $out ); $out->addModules( array( 'echo', 'visualeditor' ) ); } }
If we literally did this (there was a skin called vectorbeta, that you just chose in the menu), it would cause various problems:
- The CSS classes wouldn't work (i.e. .skin-vector).
Note true - skin-vector class could easily be added using addToBodyAttributes
- It would break conditional scripts (skinScripts/skinStyles) and user
scripts (User:Example/vector.js).
I'm pretty sure the skin could be modified to load these also but feel free to prove me wrong.
- We would have to do the subclass for every supported skin, for
projects that are skin-neutral (which Echo is for example).
I know most projects are skin neutral however we wouldn't not have to subclass every supported skin - since Vector is the most widely used skin I think this would be sufficient in succeeding in the goal of bringing attention to new features to interested party.
However, that's not to say a working beta system is impossible.
Is there any reason we don't currently do this in favour of various experiments and then a sudden push to production which tends a lot of the time to result in a heated Village Pump discussion?
I agree it's very important to communicate before it hits production, and an opt-in beta system could help with that. However, that's not the only reason for experiments. E3 uses A/B test experiments to determine which features actually serve their intended purpose before rolling them out to everyone. Furthermore, the users we're primarily working with (new users) are not likely to hit a beta switch in their preferences (it's impossible for some projects like the signup form).
I'm aware of these A/B tests and don't aim to change that but I think this system would address a different problem (see below). However there's no reason such a system couldn't be used for structured A-B tests where a focus group is collected and guided into enabling the skin.
Also, some people (even some experienced users), are not going to choose beta. They may talk about a feature before it's rolled out fully, but they'll only test the main production version.
This is true, but I think such a system would give them the option too if they are indeed worried about future development efforts. Currently they have no option until the feature is thrown over the fence which is just broken in my opinion.
On Thu, 30 May 2013 13:53:16 -0700, Jon Robson jdlrobson@gmail.com wrote:
On Tue, May 28, 2013 at 7:05 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
- The CSS classes wouldn't work (i.e. .skin-vector).
Note true - skin-vector class could easily be added using addToBodyAttributes
This would be a fairly hacky way to do things.
- It would break conditional scripts (skinScripts/skinStyles) and user
scripts (User:Example/vector.js).
I'm pretty sure the skin could be modified to load these also but feel free to prove me wrong.
This is controlled by ResourceLoaderUserModule not the skin, you would have to add a pretty awful hack to RL to make this work.
- We would have to do the subclass for every supported skin, for
projects that are skin-neutral (which Echo is for example).
I know most projects are skin neutral however we wouldn't not have to subclass every supported skin - since Vector is the most widely used skin I think this would be sufficient in succeeding in the goal of bringing attention to new features to interested party.
That's a pretty bad practice. Only subclassing one skin precludes users testing for compatibility bugs in other skins.
----
Quite frankly I find the idea of using a skin for beta stuff like this counterintuitive. The user is not expecting a "skin" -- something intended to change the visual layout and looks of the site) -- to be a preference to toggle on beta features.
I don't see any reason why these features must be implemented using a new skin rather than just adding a new preference to the preferences page for the same purpose.
((And to anyone complaining about more preferences being added. Adding an option with a completely irrelevant meaning to an existing preference is an unacceptable alternative to adding a new preference.))
On Thu, May 30, 2013 at 6:20 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
((And to anyone complaining about more preferences being added. Adding an option with a completely irrelevant meaning to an existing preference is an unacceptable alternative to adding a new preference.))
Can I complain about both? ;-)
But you're right, using skins for this smells funny, and a dedicated "Turn on experimental features" option makes a lot more sense to me.
-Chad
wikitech-l@lists.wikimedia.org