(Breaking this out from 'Focus on sister projects' thread.)
I just want to give an official shout out, as Lead Software Architect for the Wikimedia Foundation, that Wikipedia's sister projects are important and that they need more love. Not only are they directly useful and interesting in various ways, but their explorations of additional subject areas, media, and organization styles is something that needs more attention as Wikimedia looks to its future beyond Wikipedia's first decade. The next decade can't just be ten years of doing the same things...
Historically it's been difficult to get enough attention for review & deployment of special-purpose extensions for those projects, so I'm highly interested in proposals that will help put more flexibility and power into the hands of their own motivated contributors: from easier self-configuration of sites to new plugin architectures that allow the use of new creative media tools without the explicit intervention of Wikimedia staff.
In particular, I think there's some low-hanging fruit in the Gadgets system. Right now it's honestly pretty awkward to create a Gadget in the first place, and sharing code modules between wikis requires a lot of cut-and-pasting (which leads to divergent code bases, which makes maintenance nigh-impossible in the face of MediaWiki framework changes).
Some things that would be very spiffy, and probably not that hard: * Provide a nice interface rather than forcing manual editing of MediaWiki: namespace message pages * Self-publishing: be able to do your user JS/CSS in modular Gadget-form, with easy sharing to other users. Don't require manual work to move something from 'my own custom JS' ro 'a user .js file that other people can use' to 'a Gadget that anyone can select in preferences'. * Cross-wiki gadget sharing: if we can avoid fragmenting common scripts, they'll be easier to maintain.
Harder, but very interesting in the medium to long-term: * Security model for safe code sharing: we could devise an explicitly limited interface between the wiki page JS and gadgets hosted in an offsite iframe. A foreign gadget could add certain UI elements (tabs, toolbar buttons) to be triggered, and could open as an embedded view to provide things like image editing, drag-n-drop category rearrangement, custom visualizations or interactive diagrams.
-- brion
On 04/03/2011 07:56 PM, Brion Vibber wrote:
In particular, I think there's some low-hanging fruit in the Gadgets system. Right now it's honestly pretty awkward to create a Gadget in the first place, and sharing code modules between wikis requires a lot of cut-and-pasting (which leads to divergent code bases, which makes maintenance nigh-impossible in the face of MediaWiki framework changes).
What about interwiki transclusion? That sounds like it could generally solve the more general problem "for a wiki to work, you'll first need to create a bunch of pages", although it might need some adaption (e.g.: on some specified pages, such as MediaWiki's gadget pages, non-existing pages automatically transclude from meta or some other shared repository) http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_tr...
-- Tobias
2011/4/3 Brion Vibber brion@pobox.com:
In particular, I think there's some low-hanging fruit in the Gadgets system. Right now it's honestly pretty awkward to create a Gadget in the first place, and sharing code modules between wikis requires a lot of cut-and-pasting (which leads to divergent code bases, which makes maintenance nigh-impossible in the face of MediaWiki framework changes).
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore
On Sun, Apr 3, 2011 at 12:14 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
2011/4/3 Brion Vibber brion@pobox.com:
In particular, I think there's some low-hanging fruit in the Gadgets
system.
Right now it's honestly pretty awkward to create a Gadget in the first place, and sharing code modules between wikis requires a lot of cut-and-pasting (which leads to divergent code bases, which makes maintenance nigh-impossible in the face of MediaWiki framework changes).
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
In principle, making an extension based on an existing Gadget should be pretty straightforward, especially with ResourceLoader taking care of more of the details of JS & CSS fetching.
Might be fun to whip up a how-to guide and post it on the tech blog...
-- brion
On 03.04.2011, 23:35 Brion wrote:
On Sun, Apr 3, 2011 at 12:14 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
In principle, making an extension based on an existing Gadget should be pretty straightforward, especially with ResourceLoader taking care of more of the details of JS & CSS fetching.
Might be fun to whip up a how-to guide and post it on the tech blog...
The downside is that to change something in an extension you need to be a developer and your changes will be pushed to wiki with a considerable delay (oh yes, and they may even not pass through code review XD ). Editing wiki pages is much easier.
Brion Vibber wrote:
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
In principle, making an extension based on an existing Gadget should be pretty straightforward, especially with ResourceLoader taking care of more of the details of JS & CSS fetching.
Might be fun to whip up a how-to guide and post it on the tech blog...
That seems like a bit of a regression, though. The Gadgets extension was implemented as a way for local admins to easily hook into Special:Preferences so that typical users could enable certain pieces of JavaScript without needing to edit any pages.
By creating separate extensions for individual JavaScript gadgets, you hit some interesting benefits/detriments:
Benefits: * extensions can easily be enabled globally * extensions have great localization support * extensions have sane review processes in place * extensions can implement functionality when JavaScript isn't available
Detriments: * extensions usually take one forever to get enabled (this is a huge point) * extensions generally have an expectation that they will have non-JS support in them (that's why you're presumably coding in PHP) * extensions can't be updated as easily (static JavaScript pages in SVN, etc.)
You're absolutely correct that the UI for adding Gadgets is bad. Ideally it would use a Special page and some... actual UI to add/remove/modify/duplicate individual gadgets, but then you run into the problem of the storage backend. All the data is stored in MediaWiki pages, so you end up with a front-end UI monster similar to Special:CentralNotice, which probably adds more problems than it solves.
In the case of gadgets, I mostly agree with Tobias: better global support is needed. Though instead of the interwiki transclusion/marking certain pages/etc. hackery, I think global preferences (and by extension, global gadgets) make much more sense. Centralize the "add a purge link" scripts at Meta-Wiki and let everyone use the same code. That seems like a more sane approach than creating Extension:AddAPurgeLink, even if it is easier now with the implementation of ResourceLoader. :-)
MZMcBride
Brion Vibber wrote:
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
In principle, making an extension based on an existing Gadget should be pretty straightforward, especially with ResourceLoader taking care of more of the details of JS & CSS fetching.
Might be fun to whip up a how-to guide and post it on the tech blog...
That (may or may not be intentionally) sounds like a way to work-around the elephant in the room, which is global preferences.
Gadgets are gadgets.
MZMcBride wrote:
In the case of gadgets, I mostly agree with Tobias: better global support is needed. Though instead of the interwiki transclusion/marking certain pages/etc. hackery, I think global preferences (and by extension, global gadgets) make much more sense. Centralize the "add a purge link" scripts at Meta-Wiki and let everyone use the same code. That seems like a more sane approach than creating Extension:AddAPurgeLink, even if it is easier now with the implementation of ResourceLoader. :-)
MZMcBride
+1
Although global preferences [1] is not fixed yet. Centralized gadgets is already possible. Both with and without resource loader (ie. before and after 1.17).
= Old way = This was only done or HotCats.js on some wikis: == Central wiki == * MediaWiki:Gadget-definitions * foo|foo.js|foo.css * MediaWiki:Gadget-foo This is Foo description. * MediaWiki:Gadget-foo.js alert('foo'); * MediaWiki:Gadget-foo.css body { background: orange; } == Other wiki == * MediaWiki:Gadget-definitions * foo|foo.js * MediaWiki:Gadget-foo This is Foo description. * MediaWiki:Gadget-foo.js importScriptURI( 'http://centralwiki.org/w/index.php?title=MediaWiki:Gadget-foo.js&action=...' ); importStylesheetURI( 'http://centralwiki.org/w/index.php?title=MediaWiki:Gadget-foo.css&action...' );
= New way = This way is promoted in the migration here [2] to start centralizing gadgets and avoid stuff from getting out of date. (navPopups, HotCat, UTCLiveClock, WikiMiniAtlas etc.) :
== Central wiki == * MediaWiki:Gadget-definitions * foo[ResourceLoader]|foo.js|foo.css * MediaWiki:Gadget-foo This is Foo description. * MediaWiki:Gadget-foo.js alert('foo'); * MediaWiki:Gadget-foo.css body { background: orange; }
== Other wiki == * MediaWiki:Gadget-definitions * foo|foo.js * MediaWiki:Gadget-foo This is Foo description. * MediaWiki:Gadget-foo.js mw.loader.load( 'http://centralwiki.org/w/load.php?modules=ext.gadget.foo' );
This new way not only centralizes stuff (like the old way did) but also does all resource loader stuff (1 request, minified, combined, cached)
This is already a huge improvement and can and is being done today. Once global preferences are up and RL 2.0 is in the air, it would be even easier. ie. extra section in Special:Preferences#Gadgets with "global gadgets" and MediaWiki:Gadgets-globaldefinition is used and meta.wikimedia/load.php
-- Krinkle
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=14950 [2] http://www.mediawiki.org/wiki/RL/MGU#Keep_gadgets_central
On 03/04/11 22:05, MZMcBride wrote:
Detriments:
- extensions usually take one forever to get enabled (this is a huge point)
- extensions can't be updated as easily (static JavaScript pages in SVN,
etc.)
Surely the fix for this is having someone dedicated to doing something like this, code review for this should be relatively quick, providing the reviewer is confident in JavaScript, and then the rest is a require_once or similar and any additional configuration variables suggested by the requester/author. For the other point, it just requires somebody getting round to doing it, which could be solved by having a volunteer or staff member to do it.
On 03/04/11 22:05, MZMcBride wrote:
In the case of gadgets, I mostly agree with Tobias: better global support is needed. Though instead of the interwiki transclusion/marking certain pages/etc. hackery, I think global preferences (and by extension, global gadgets) make much more sense. Centralize the "add a purge link" scripts at Meta-Wiki and let everyone use the same code. That seems like a more sane approach than creating Extension:AddAPurgeLink, even if it is easier now with the implementation of ResourceLoader. :-)
Global Preferences would be nice, for some parts atleast (email, RC settings, editing settings), other things, for example signatures would be a pain. I do agree that some of those gadgets should not be extensions, however for example, Twinkle, would be a very nice extension, as noted from various blips of activity from site owners over IRC.
-- Lewis Cawte
Lewis Cawte wrote: [...]
I do agree that some of those gadgets should not be extensions, however for example, Twinkle, would be a very nice extension, as noted from various blips of activity from site owners over IRC.
-- Lewis Cawte
Maybe, but when done as an extension imho it should be integrated in MediaWiki with it's own preference page, adding the actions as actual actions and interface messages etc. Not as an extension that loads a few javascript files.
Including for example non-JavaScript fallback (not as a goal but as a result of it being integrated).
-- Krinkle
On Sun, Apr 3, 2011 at 2:23 PM, Krinkle krinklemail@gmail.com wrote:
Lewis Cawte wrote: [...]
I do agree that some of those gadgets should not be extensions, however for example, Twinkle, would be a very nice extension, as noted from various blips of activity from site owners over IRC.
Maybe, but when done as an extension imho it should be integrated in MediaWiki with it's own preference page, adding the actions as actual actions and interface messages etc. Not as an extension that loads a few javascript files.
These shouldn't really be thought of as separate issues; there's no reason we can't extend the Gadget interface to allow gadgets to define their own preference panels cleanly, and I'm pretty sure that would be a win for users.
Including for example non-JavaScript fallback (not as a goal but as a result of it being integrated).
Non-JS of course is the main thing that's hard to do in JavaScript. ;)
-- brion
2011/4/4 MZMcBride z@mzmcbride.com:
Brion Vibber wrote:
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
In principle, making an extension based on an existing Gadget should be pretty straightforward, especially with ResourceLoader taking care of more of the details of JS & CSS fetching.
Might be fun to whip up a how-to guide and post it on the tech blog...
That seems like a bit of a regression, though. The Gadgets extension was implemented as a way for local admins to easily hook into Special:Preferences so that typical users could enable certain pieces of JavaScript without needing to edit any pages.
By creating separate extensions for individual JavaScript gadgets, you hit some interesting benefits/detriments:
Benefits:
- extensions can easily be enabled globally
- extensions have great localization support
- extensions have sane review processes in place
- extensions can implement functionality when JavaScript isn't available
Detriments:
- extensions usually take one forever to get enabled (this is a huge point)
The benefit of great localization support is also a huge point, and hugely positive. It's worth the resources to fix the hard, long and frustrating review processes that cause extensions to wait for years in the line to be enabled to get the benefit of localization. It's true that extensions take forever to get enabled, and this is, indeed, a huge point - and it must be fixed. I suppose that it requires resources; well, the Foundation must prioritize this much-needed evolutionary change higher than big revolutionary projects. It's not even a matter of "globalization", "language equality" etc. - it's something that's just plain useful for the Big English Wikipedia, too.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore
2011/4/3 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
I'm not a real MediaWiki developer, so it may be a silly question: How hard it is to convert a gadget into an extension? If it's not too hard, wouldn't it be better to redo useful gadgets as extensions? Unless i miss something very basic, this will make them easier to maintain, install, update and localize.
It's fairly easy. I guess a howto could be written for this.
Basically, you need to * put the CSS and JS in one or more files (split where it makes sense) * write an extension setup file that registers them * hook into some hook that makes sense for your use case, and call addModule()
Roan Kattouw (Catrope)
On Mon, Apr 4, 2011 at 3:56 AM, Brion Vibber brion@pobox.com wrote:
- Cross-wiki gadget sharing: if we can avoid fragmenting common scripts,
they'll be easier to maintain.
Not really, It's just up to the local sysops to decide if they want to do it that way or not.
For example, HotCat is commonly pulled down from commons[1][2] and it is even designed to allow local defaults to be setup[3][4]. And for example a pile (i won't post links to them all) that en.wikip pulls down from other locations such as mw wiki, de.wikip[5][6].
I think the main issue is in the past no one has really been around to help communities set these up like this and that has resulted in the fragmentation, Also It causes issues such as updates if the users aren't sysops to manage the scripts (eg: if they are the script author ) but some have worked around that by including user space pages into the mediawiki:* page. And it's not like we can't give non sysops access to edit these pages either, we do have the "editinterface" right we can give away (available in the "accountcreators" group on en.wikip as example) so that users can manage scripts without needing to be sysops.
[1]. http://www.mediawiki.org/wiki/MediaWiki:Gadget-HotCat.js [2].http://en.wikipedia.org/wiki/MediaWiki:Gadget-HotCat.js [3]. http://www.mediawiki.org/wiki/MediaWiki:Gadget-HotCat.js/local_defaults [4]. http://en.wikipedia.org/wiki/MediaWiki:Gadget-HotCat.js/local_defaults [5]. http://en.wikipedia.org/wiki/MediaWiki:Gadget-UTCLiveClock.js [6]. http://en.wikipedia.org/wiki/MediaWiki:Gadget-revisionjumper.js
On 04/03/2011 10:56 AM, Brion Vibber wrote:
Harder, but very interesting in the medium to long-term:
We would do good to survey and analyse other "gadget", "widget", "add-on" systems and communities that exist in web platforms. Not to say that wikipedias needs are the same, just that there are probably a lot of ideas to borrow from, and a good gadgets plan will have a few phases of implementation.
Some anecdotal notes:
* Gadget or widget have to get per user permission confirmation before it can take certain actions on your behalf. If we have an iframe postMessage api proxy bridge, we enable permissions of an open sand-boxed wiki gadget site we could potentially lower the criteria for entry and be a bit better than including random JS on your userpage .js page.
* There is very fluid search and browsing interfaces to find, 'install' and share gadgets / add-ons. This includes things like ratings, usage statics, 'share this', author information etc.
** Visibility. Many editors and viewers probably have no idea gadgets exist. With the exception of projects globally enabling a gadget, many feature are pretty much hidden from users. Its sort of a chikin and egg issue but in addition to highlighting content, the sites main pages, may also highlight good usage of in-site tools and features. Like commons featuring a densly annotated image to highlight the image annotator, or the community portal of wikipedia directly linking to an interactive js gadget that enables a particular patrol work flow or article assessment task. The "withJS" system is kind of a hack for direct link into a gadget feature which I have used a lot, but a more formal easy opt-in mechanism would be nice...
* Check out https://addons.mozilla.org/en-US/developers/ We have decent documentation for extensions and core mediawiki development, but the gadget effort is somewhat ad-hock, not very centralised and best practices are not very well documented ( although recent efforts are a step in the right direction :)
peace, michael
On 3 Apr 2011 at 10:56, Brion Vibber wrote:
(Breaking this out from 'Focus on sister projects' thread.)
I just want to give an official shout out, as Lead Software Architect for the Wikimedia Foundation, that Wikipedia's sister projects are important and that they need more love. Not only are they directly useful and interesting in various ways, but their explorations of additional subject areas, media, and organization styles is something that needs more attention as Wikimedia looks to its future beyond Wikipedia's first decade. The next decade can't just be ten years of doing the same things...
Historically it's been difficult to get enough attention for review & deployment of special-purpose extensions for those projects, so I'm highly interested in proposals that will help put more flexibility and power into the hands of their own motivated contributors: from easier self-configuration of sites to new plugin architectures that allow the use of new creative media tools without the explicit intervention of Wikimedia staff.
In particular, I think there's some low-hanging fruit in the Gadgets system. Right now it's honestly pretty awkward to create a Gadget in the first place, and sharing code modules between wikis requires a lot of cut-and-pasting (which leads to divergent code bases, which makes maintenance nigh-impossible in the face of MediaWiki framework changes).
Some things that would be very spiffy, and probably not that hard:
- Provide a nice interface rather than forcing manual editing of MediaWiki:
namespace message pages
- Self-publishing: be able to do your user JS/CSS in modular Gadget-form,
with easy sharing to other users. Don't require manual work to move something from 'my own custom JS' ro 'a user .js file that other people can use' to 'a Gadget that anyone can select in preferences'.
- Cross-wiki gadget sharing: if we can avoid fragmenting common scripts,
they'll be easier to maintain.
Harder, but very interesting in the medium to long-term:
- Security model for safe code sharing: we could devise an explicitly
limited interface between the wiki page JS and gadgets hosted in an offsite iframe. A foreign gadget could add certain UI elements (tabs, toolbar buttons) to be triggered, and could open as an embedded view to provide things like image editing, drag-n-drop category rearrangement, custom visualizations or interactive diagrams.
Some commentary.
For WS projects, ThomasV has been utilising this model for his proofread page schema. Most of his javascript is placed in http://wikisource.org/wiki/Mediawiki... and the local stuff would be local customisations for language, eg. field names
I would hope that as a model that this can be used, so that the guts of a script can be separated from the labelling.
With regard to calling gadgets from elsewhere, often the issue is 1) which server, there is so much variability, and many started at WP. 2) knowing what available on servers, and this is a documentation issue. Trying to find available scripts on TS is just as problematic.
Regards, Andrew
I think the source of the problems is the decentralizated process that wikimedia javascript have followed. Medium-size wikis will have 2-3 tech people. Small wikis will be lucky to have 1 js-savy sysop. Even wikis with no local expert may have just forked the Monobook.js from its mother project and never touch it again. There are also one-man javascript cathedrals that noone dares to touch now but have lots of users which will complaint if they stop working.
I'm sure there are lots of versions of collapsible tables out there (and some old pages are not viewable with the newer ones...).
There are diverging branches for each change. One user changes innerHTML to DOM while another added new features. Then a third one fixes an injection on its own copy, while the original version at enwiki is left unpatched.
Even their goals are different. There's no way to coordinate all these efforts. There's no central mailing list where it can be shouted "Hey! This javascript is now deprecated" or "This gadget is now much improved".
Also, the place to put the javascript code (a superset of the link-or-copy disyuntive) is made non-trivial by the distribution of sysop rights.
Some steps to take: * Finally create global gadgets. * Create a central wiki for javascript sharing [1] * Gather a list of tech users[2] and invite them to the new wiki and/or a mailing list. * ??? * Profit
[1] A protected Script: namespace at meta would also work, with a new permission. Note that we would need to give to all these people access to edit some global javascript.
[2] Make a list of users with more than 3 edits to Mediawiki:*.js on any project.
Very interesting! :-)
I'm a beginner in js stuff, but I realized how much js can be useful in a number of ways (presently I am a "very simple gadgets maker" t help users engaged into proofreading into wikisource). I'm a little worried about additional server load coming from AJAX, and I suggest different policies between local js scripts (that, fix me if I'm wrong, don't imply any server load) and AJAX scripts, which raise performance issues.
So, I can't wait for a js wiki.... but please, keep it simple! So simple that a beginner too could browse it,learn from it and publish anything without any embarrassment. Beginners often feel themselves really stupid.... and some good idea could be lost.
Alex brollo
On Mon, Apr 4, 2011 at 6:22 PM, Platonides Platonides@gmail.com wrote:
Some steps to take:
- Finally create global gadgets.
- Create a central wiki for javascript sharing [1]
It seems like this always comes up for a number of different things -- "global pages" for interwiki transclusion and interlanguage extension, just to name two recent ones -- maybe it's about time we actually make this? :-) I guess a list of things we'd put on this wiki would be a good first step.
- Gather a list of tech users[2] and invite them to the new wiki and/or
a mailing list.
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors ?
On Tue, Apr 5, 2011 at 10:27 AM, Casey Brown lists@caseybrown.org wrote:
- Gather a list of tech users[2] and invite them to the new wiki and/or
a mailing list.
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors ?
I don't see why we need to spilt it off to another list.... No reason not to do it here on wikitech-l.
On Mon, Apr 4, 2011 at 9:05 PM, K. Peachey p858snake@gmail.com wrote:
I don't see why we need to spilt it off to another list.... No reason not to do it here on wikitech-l.
Did you realize that that list already exists? There's also no reason not to use both of them, with the ambassadors list one being more of an "announce" list. People could send messages to both lists, and then most discussion would take place on wikitech-l.
wikitech-l@lists.wikimedia.org