Here I transcribe a conversation with Michael Mehaffy regarding modeling complex systems with quantitative patterns in federated wiki.
Michael points out the encyclopedia page on system dynamics, and especially the animation used to illustrate the article. wikipedia 
Dynamic stock and flow diagram of model New product adoption (model from article by John Sterman 2001). source
How hard would it be to create the model in the upper right in federated wiki by putting together the patterns in linked sequential (and/or hyperlinked) pages, e.g. "Potential adopters," "New adopters" etc...?
Seems like all the JSON calcs could be done with Method now - in principle. The only real challenge at this point would be the visualization. Am I right?
I reply.
There would be a few separate aspects to be designed in making that sort of animation.
Will the animation run itself or will someone interact with it?
Will an author or the user layout the graphical elements of the animation?
What will be the repertoire of devices? How will someone know what they mean? Who will draw them?
How is scaling handled? If a change causes the system to go out of anticipated range will the animation adjust? How?
How will the animation respond to system changes such as adding new subsystems?
How is it that the calculations make a closed loop that oscillates? Is oscillating good?
Later I suggest Method Control Loops
The various answers could make such a project easier or harder. When choosing the easier path, critics will always suggest that more is possible. However, when people try to go full out with the hard solutions they end up with packages that only they can work.
Which of the things above are important to do really well?
Michael responds.
My instinct tells me that an ideal approach would be to make simple display elements that a (skilled) user could assemble into the display.
I continue.
Here is what I imagine regarding calculation.
One assembles a model by making Method object on pages that include descriptions of their intended use. We're calling these quantitative patterns.
One could tweak a model by scrubbing any number. Inputs would stay where you left them. Outputs would snap back to computed values when released. (now you have to double click)
Updates compute forward from left to right. Changes take effect immediately. (now you have to coax the calculation forward by refreshing items or pages)
One adds visualizations of roughly the complexity of Radar plugin or simpler. Double click of visualizations allow some customization.
Visualizations need to be programmed in javascript using html5 canvas or svg graphics primitives. It is possible for an artist to make very stylish visualizations using the css capabilities of html5.
Data flows could be illustrated when hovering over numbers. Arrows would show were inputs come from and go to. They wouldn't stay. No need to route them around other information.
If we wanted to have feedback we could make a special plugin that sent data backwards. It would be essentially a number that "scrubs itself" based on what it sees to the right. You could have more than one. For example, the classic Predator/Prey problem might feed back both population counts for wolves and rabbits. The equations would change as various pages were added to, say, hunt wolves, or fence rabbits. wikipedia
It would also be simple to make timer-driven self-scrubbers that feed preprogrammed signals into our calculations. Some systems call this an LFO (low frequency oscillator). Imagine sweeping a number back and forth over a few seconds each cycle. This is easier than actually solving equations for the oscillation because it will tend to stay i range rather than growing without limit and wrecking all the pictures.