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