Gadget Studio

From MediaWiki.org
Jump to: navigation, search


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[edit]

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[edit]

  • 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[edit]

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[edit]

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.

See also[edit]