User:Salvatore Ingala/GSoC 2011 application

Up to date project notes are being kept on the page /Notes.

Identity

Name: Salvatore Ingala
Email: salvatore.ingala -at- gmail.com
Project title: AMICUS: Awesome Monolithic Infrastructure for Customization of User Scripts

Contact/working info

Timezone: UTC+2 (Italy)
Typical working hours: Mostly afternoon to evening from Tuesday to Friday until July, flexible any other day and after July.
IRC or IM networks/handle(s): ^Spider^

Project summary

MediaWiki allows registered users to personalize the aspect of its user interface by the insertion of personal user script (in JavaScript language, on a per-user basis) or by enabling “gadgets” managed by sysops (on a site-wide basis). Lots of gadgets and user scripts allow some kind of customization. For example, the widely used Navigation popups have lots of variables that can be configured to enable/disable specific features, chose between alternative behaviors, and so on. The common way of doing this kind of configurations is to add code to personal user scripts which sets the appropriate variables. While this always works, this is far from being user-friendly (unless all your "friends" know JavaScript, of course!).

A better solution would be to have a nice, standardized interface to do user customizations.
End users should have a central place where options for all enabled gadgets/userscripts can be changed in an easy way and with proper validation.
Moreover, the tool developers should not have the bother of writing code to build the configuration interface: they should just expose an object with meta-configuration (option name, data type, default value, description, (possibly) code for validation and so on) and be happy.

AMICUS is the Latin word for "friend". AMICUS wants to be friend with both tool developers and end users! (Advertising – don't bother...)

This would be even interesting for some core components (e.g.: toolbar customization).

About you

I'm a computer science student at University of Catania (Italy); I completed the “Laurea triennale” (roughly equivalent to a bachelor's degree) in 2009 end expect to finish master's degree in 2012.

I'm a sysop on Italian language Wikipedia from 2005.

I've been involved in writing and maintaining both site-wide javascript code (MediaWiki:{Monobook,Vector,Common}.js) and several other user scripts on it.wiki since 2006, and I've often sought for improvements in usability and maintainability of user scripts; recent enhancements in MediaWiki (default inclusion of jQuery, deployment of ResourceLoader) and, I hope, near-future ones (deployment of improved ResourceLoader 2.0!) made me enthusiastic on the new possibilities.

Deliverables

Required deliverables

• A way to allow user scripts to expose their configuration metadata (preferably via JavaScript calls).
• A way to allow user scripts to read their own configuration (via JavaScript calls).
• An easy-to-use GUI to permit end users to set configurations for all tools that expose a configuration object.

Some points need attention:

• Internationalization
• Efficiency: avoid doing useless AJAX calls and minimize useful ones (the idea is to use HTML5 client-side storage to implement a cache for read access; the cache could be an independent module, useful on its own for other applications)
• Graceful degradation: on older browsers, it must fail without breaking anything and just return default configuration values.
• The application interface for configuration metadata should be kept very easy for simple things (most options are very simple, like “true/false” or multiple choices), while giving to the tool writers sufficient control to do more complicated things or customize the configuration GUI.

If time permits

• Application to existing user scripts (Navigation Popups, HotCat. ...)
• Code for toolbar customization should be much easier now than writing it from scratch.
• Pushing for deployment on Wikimedia wikis.

Project schedule

• Community bonding period: study of MediaWiki's components related to the project, discuss best way to do things.
• 2-3 weeks: exact specification and architectural design
• 2-3 weeks: prototyping

Milestone 1: basic working version

• 4 weeks: improvements on code and functionality; more advanced features
• 2 weeks: testing and documentation

This could leave room for something in the "if time permits" section.

Participation

I will often hang on #mediawiki for discussion or clarification of any doubt; I could use other channels (e.g. mailing list) if needed.

I would work on a local installation of MediaWiki, with frequent commit to a branch in the SVN repository. At some point, setting up a live test wiki could become more practical.

Past open source experience

I don't have any past experience in open source projects, but I'm quite used to write client side code for user interface customizations, as I said above.

I implemented a small feature for MediaWiki in 2005 (it was about a very rudimental idea similar to “pending changes”, when nobody still talked about that; I needed the feature for a personal wiki). I finished an initial version, but I eventually stopped working on the project and it went lost on some unused branch of the repository (as far as I know, nobody reviewed it).

Any other info

Gadgets are a good way to enable users to manage scripts without any programming knowledge; nevertheless they provide little flexibility: a gadget is just enabled or disabled. While a viable way to improve user experience with most of the proposed features would be to extend the syntax of gadget definitions with meta-configuration info, I think that this could not reach the same level of generality of the proposed JavaScript-centric solution. The only thing that's impossible in pure JavaScript is persistence (apart from HTML5 storage, which is unsatisfying for our purposes), and that's where some server-side help is needed (maybe extending MediaWiki API with a read and a store call for accessing personal data where configuration resides; the API could be very simple, storing and retrieving plain text strings).

This brings some issues, too: for example, it may be hard (or impossible) to prevent a gadget from reading other gadgets configuration (not a security issue since javascript code is trusted, but true separation would be conceptually nicer).

An example of how the configuration object could look like is at this subpage.