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