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 