Interactive Strategy Observations

There are a number of proposals for developing more interactivity in Wikipedia, by allowing detailed graphics and animations to be contributed. The basis for these proposals is straightforward: plain text and images are a difficult means to explain certain ideas: diagrams and animations potentially offer a better way to communicate some things. For a good demonstration of what has already been achieved by extending wiki markup, see Wikitex.

Some of these proposals appear to overlook a key principle, that Wikipedia should try to extend its reach and accessibility by being universally editable. Some recommend the use of video (in proprietary as well as free-software formats), while others recommend binary-formated media (such as java applets and/or proprietary flash applications).

Other proposals recommend the use of browser capabilities to handle open markup formats, such as SVG and Canvas which are incorporated in the upcoming HTML5 specification and have been present in many browsers already for several years. However:

At present the most widely used browser, Internet Explorer, does not have native support for SVG, but has VML in its place. There are however existing plugins and libraries for the present, and other workarounds being developed for the near future, but all of these options require that the developer take them into consideration and code specifically for the library or the workaround, rather than specifically and exclusively target SVG. Also, there are recent indications that Microsoft may be coming round to the idea of adding SVG to a future version of IE (which will still leave older versions of IE as being incompatible).
The current stable release of Firefox does not support SMIL animation of SVG, but, again, this is in the pipeline.
Low-cost, low-power devices don't necessarily have the resources or capabilities to display animations.

Overall, then, the proposals need to pass the Wikitex litmus test:

Are the proposals easier for ordinary people to contribute new pages and/or modifications to existing pages, compared to what Wikitex currently offers?
Are the proposals implementable without significant risk, or large resources (e.g. compile farms or reviewers' time), compared to Wikitex?
Do the proposals provide significant extra features which cannot be covered by Wikitex markup (now or in a future revision of Wikitex)?

Proposals based on Binary-Formats

Proposals which recommend that pages, in part or in whole, be based on binary-formats such as Silverlight, Flash, have the following implications for contributors and for wikipedia. Note that all steps must be completed and complied with. The steps in this process are not optional.

An end-user, whose first language may not be english, must learn one or more advanced programming languages.
An end-user must have access to the development environment.
An end-user must have the technical resources to run the development environment, including the cost of the bandwidth to download the development environment. Or, if the development environment is not proprietary, an end-user must have the technical knowledge and skills to download a compiler and build environment, download the source code of the development environment, download the dependencies of the development environment (as source or binary), and bootstrap their way up to a full working development environment, substituting personal time, resources, initiative and patience for convenience (due to lack of access to affordable bandwidth).
As an alternative, an end-user must have access to an online equivalent of the development environment (the simplest implementation of which is the provision of a pre-prepared development environment - running "somewhere" on "someone's" hardware at "someone else's" expense - through Remote Desktop or VNC, with all the nightmare implications and associated security risks). In this instance, the end-user must have real-time Internet access in order to have continuous access to the online development environment.
An end-user should, ideally, have real-time Internet access in order to access online help resources as well as being able to interact with other programmers on forums, mailing lists and "Chats".
Contributions, for security and many other reasons, cannot be uploaded in compiled format but in source code form only
The source code must be peer-reviewed before being deployed, to ensure that it meets agreed "Lowest Common Denominator" standards for deployment across the widest range of devices and is interoperable with free software implementations of the binary-format players (for example, swfdec and gnash only support limited and different subsets of ActionScript 2)
The source code must be peer-reviewed, before being deployed, for security risks.
Wikipedia potentially becomes liable for any security breaches of end-user's machines, as a direct consequence of knowingly deploying binary-formatted risky code.
Wikipedia's servers and peer-review specialists could become overloaded by the need to recompile all source code of all binary-formatted media, should a security vulnerability be discovered.
End-users must download the binary-formatted code.
End-users must have sufficient bandwidth to download the binary-formatted code.
End-users must, on downloading the binary-formatted code, go through the process of acquiring the necessary plugin to run the binary-formatted code in their browser.
End-users must have sufficient bandwidth (or money) to acquire the necessary plugin (including potentially compiling the plugin from source code, if a free software version is chosen, and is capable of interpreting the binary-formatted code - assuming that the "Lowest Common Denominator" standards have actually been correctly met).
End-users must have a device capable of running the necessary plugin.

By contrast, here is the series of steps which "wikitex" goes through:

An end-user clicks the "edit" button on a page
An end-user is presented with an unfamiliar markup tag (for example < music > < / music > )
An end-user looks up the documentation on the unfamiliar tag, which is only a few pages in length, reads them, and follows the instructions.
An intelligent end-user ignores the documentation, works out through context and experimentation (in the sandbox, if they are particularly intelligent) and copies the pre-existing example and makes corrections.
The end-user submits the edited page to the Wikipedia Servers
The Wikipedia Servers run some PHP and some programs (that have been vetted thoroughly for security issues and bugs before being allowed to run on Wikipedia Servers), the sole and exclusive purpose of which is to turn the specific "wikitex" markup tag into a Lowest-Common-Denominator acceptable format (usually a PNG image).
The PNG image is displayed on the end-user's browser, showing the end-user the (hopefully corrected) graphical representation of the "wikitex" extended markup, in the appropriate context of the rest of the Wiki Page.

So without going into detail, and notwithstanding the fact that some of the steps require proprietary tools that must be deployed on both the end-user machines and also on wikipedia servers, overall it should be blindingly obvious that the costs, barriers and risks are insanely high, for the simple, simple task of providing a means to edit information in one of the "rich" interactive binary formats.

Proposals based on extensions of Wiki Markup

Some proposals are recommending that Wiki Markup be extended, or the implementations of existing image / animation systems behind existing Wiki Markup (e.g. use of librsvg), be extended to provide better and/or faster features. These are good ideas as long as:

the extensions do not end up turning Wiki Markup into a full-blown NP-complete programming language
the display mechanisms still present the information in gracefully-degrading formats suitable for a wide range of devices.

One known source of complaints against wikipedia is that wiki markup, especially its advanced features, are "elitist" (the number of proposals talking about adding "WYSIWYG" capabilities to wikipedia is a testament to this fact). By ensuring that the extension to markup is kept to an absolute minimum level, with basic usage instructions of only one or two pages in length, the majority of intelligent end-users will pick up the principle enough to be able to make useful contributions to complex and comprehensive pages.

References