When we get a new car, we have to choose between different makes and models. The choice is to a large extent between complete packages, where each package has a whole variety of characteristics – fuel efficiency, size, performance, reliability .
We operate in quite a different way when we choose a kitchen. We (rarely) choose a kitchen as a complete package. Rather, we choose the individual components – the cabinets, the worktop, the cooker, the fridge and so on. We can do this because, fortunately, there is a basic infrastructure and set of conventions which allow things to work together – electricity, water and gas services, and standard dimensions.
System Dynamics software (and, indeed, most software) is like a car: we even use the term “software package”. We have to choose between one package and another, each of which has pros and cons – such as price, useability, feature-richness, and computational speed. Sure, initiatives for developing a standard model interchange language, such as XMILE, improve our ability to work with the same model on more than one platform, but that’s a bit like having several cars in the garage, and there are significant barriers, such as price, familiarisation, to the use of multiple packages.
If we think for a moment about the user interface for SD modelling, we realise that it is inherently modular: the screen consists of a number of panels. We have the model diagram, the equation listing, a run control panel, various display tools for showing simulation results, perhaps a control panel with sliders for changing parameters, along with various dialogue windows. It is hugely wasteful for every team who wants to develop SD modelling software to have to reproduce all these components. More fundamentally, even given infinite resources to develop the software, any one platform will be a compromise between feature-richness and useability: users find too many features confusing. But on the other hand, many users will want some esoteric feature that most others don’t – the “long tail”.
As far as I know (and i’m happy to be corrected), Simile is until now the only SD modelling platform which supports this modularity, and then only to a limited extent. [Disclosure: I’m a Director and shareholder in Simulistics Ltd.] When you install Simile, even the free evaluation version, all the tools for displaying model results (graphs, tables, maps etc) are text files in the Tcl/Tk scripting language. Any user is free to edit these files, to copy and alter them, or indeed (using Simile’s API) to make their own. They can then add them into their local Simile directory, or share them with anyone else. But: this applies only to the display of results (not the display of the model); not many people know Tcl/Tk; sharing files for desktop applications is a bit tedious; and you are still after all locked into one package, i.e. Simile.
Systo sets out to see just how far we can push the kitchen model. No aspect of the user interface is hard-wired in. Rather, the “kitchen” (a web page) is constructed using whatever HTML the web page developer wants to provide, and whatever Systo widgets they want to include in the page. Systo does provide a basic infrastructure (the water, gas and electricity services), but all the rest is chosen by the developers – they shop around on the web for suitable “appliances”, confident in the knowledge that they can just plug them into the web page.
Arguably, this approach is much closer to Tim Berners-Lee original conception of the web – as a peer-to-peer sharing of information. This contrasts totally with the current model: monolithic and centralised web apps on a single site, with the site owners dictating the whole of the user interface.
Of course, not everyone wants to design a kitchen from scratch. If you are going for a week’s self-catering, you expect to find a fully-equipped kitchen waiting for you. And so it is with modelling on the web: most users will have no interest in writing HTML, or Systo’s widget-based approach. They just want a nice, functional site which suits their needs, in terms of the models it provides or the tools available for working with models. That’s fine: they will just go to one of the many Systo-based web sites for doing their modelling, and they may not even be aware that the site is not a conventional web app.
So: let’s start cooking!
Systo 
All in all this looks like an intriguing idea, it should be quick and easy to make web based interactive models that explain a variety of concepts. The idea behind widgets also sounds quite like a web based version of the UNIX philosophy: write widgets that do one thing well and work well together. Have them communicate using a common data interchange format (JSON?). It seems to have worked pretty well for UNIX/Linux.
I can think of two practical problems with pulling widgets from different places on the internet though: availability and consistency. Both can be addressed fairly easily however. Availability – what if site X hosting a widget is down – through local caching plus checking that the widget in question hasn’t changed (through requesting a version numer or similar). Consistency – how do you guarantee that widget bahviour is the same tomorrow as it is today – could be fixed by versioning of widgets. However, this comes with its own set of problems. People may also want to have the latest cutting edge widgets, which should be a choice.
I’ll look forward to watching the progression of Systo!
Thanks, Mark, for these useful comments.
I accept that moving from a highly-centralised model to a highly-distributed one can introduce its own problems, and indeed can be seen as a recipe for chaos. But I think it’s worth while undertaking this experiment, mainly because of the huge opportunity for unleashing creativity, and that there is a reasonable chance that order might emerge from the chaos. Perhaps through social-media popularity rankings leading to the best widgets becoming the better known and thence the better maintained.
I think there might be some useful parallels with plugins for the jQuery Javascript library. Here again anyone can make their own, and publish them wherever they like. But potential users are greatly helped by the jQuery Plugin Registry (http://plugins.jquery.com/), which aggregates information about available plugins in a single place, provides links to the most recent versions, ranks the most popular, etc. It would be good to hear from someone who has made extensive use of the Registry as to how well this system works.