Gadget Studio

''This is a stub page, and will be worked out further and linked into the future and requests for comment pages... --brion 18:07, 12 April 2011 (UTC)''

Custom client-side JavaScript and CSS-based scripts, widgets and gadgets are the lifeblood of making a really awesome MediaWiki site. Power users create and share their own tools, which can get merged out to everyone or kept for individual opt-in.

Pretty much this is pure open source: people being given the chance to completely rework the user interface, and by tying into the server-side API, construct all kinds of awesome new tools.

Extension:Gadgets provides a way to present individual code chunks as options selectable in Special:Preferences, and has a very primitive management interface at Special:Gadgets which, unfortunately, is based on making local sysops edit MediaWiki: message pages without much direct assistance. There is documentation here so it's manageable, but we could do so much better.

== Baby steps ==

There's a few things that would make a huge difference, without significantly changing how it works, mostly covered in Extension:Gadgets/Roadmap notes already:


 * Give Special:Gadgets management page a basic GUI!
 * create a new gadget with a click
 * provide UI for selecting options (RL compatibility, dependencies, rights restrictions)
 * edit the localized names in inline fields instead of linking off to the standalone MediaWiki: message pages
 * enable screen shots or logos to be associated with gadgets, and pretty "add gadget", "remove gadget" type buttons.
 * Import/export
 * Consider a svn path to gadget mapping that makes it easy to do local testing and to import a copy from svn to the wiki page ( maybe beyond baby step )
 * It should be fairly trivial to produce a list of relevant pages and drop them into Special:Export automatically. Primary thing to consider is the definition line, which could be split out to its own little page or something.
 * This actually got in a while back it looks like -- but you still have to copy-paste the line manually. It does at least show it to you, but that should be automatable too.
 * Code editor
 * Editing JS and CSS in the wiki editor is awkward: the editor doesn't autoindent, the tab key jumps to another field, and there's no syntax highlighting until you save (if syntax highlight plugin is enabled).
 * Embedding something like SkyWriter's code editor could be beneficial, and should be mostly a drop-in.
 * Detection of syntax errors while you edit is SO HELPFUL ITS NOT FUNNY

Democratization

 * Integrate Gadgets with user scripts
 * make it easy to edit your own *personal* gadgets through the same interface
 * one-click publishing from the personal gadget space to the public gadget space
 * Integrate Gadgets with site scripts
 * lock in 'default gadgets' rather than having to work in a separate area for 'global site js'
 * Straightforward way to stash a library of JS scripts, CSS chunks, and images on-wiki? (so they don't have to be loaded from offsite hosting that might not scale or stick around)
 * Another task for a well thought out svn bridge, but also accessible via the web with forms and a set paths for "asset buckets" per gadget.
 * Default gadgets activated for new user accounts ("training wheels")

Safety and stability
This may be harder!


 * Define safe, stable JavaScript-level interfaces for gadgets to use
 * menu, toolbar, embedded file rendering hooks, data api access, etc
 * stability: defined interfaces should be independent of skin details etc, will continue to work in future
 * safety: subset of defined interfaces won't expose direct access to HTML & JS context, so can hook up to restricted execution environments...
 * Create safe execution contexts that can let code use the stable interfaces, but not anything else
 * Caja-like restricted execution through code rewriting?
 * off-site iframes with communication over window.postMessage?
 * this is kind of tricky.. but would be useful if we have an opt-in permissions system ie when you click "add gadget" it presents you with a little list of capabilities it needs, with the most permissive being the script runs directly on the wiki ( some things like XHR binary uploads of modified images or videos would be very tricky or slow to do over postMessage )

Live editing and debugging
Being able to at least refresh a script and poke at it while you're working could be quite handy. Really general debugging aids might be tough but fun.