Imagine a STEM model in a web page, and then think slick, Flash model presentation with a live connection to a STEM model running on a server, and you will have a fair idea of a current development thread to be unveiled in October 2011
A number of tools have emerged
in recent years which have made it easy to stick
all manner of sexy user-interface widgets – spinners, sliders; you name it
– onto the front of a business model and present it as a standalone application,
or in a web page. But what can you say about the mathematical integrity of what
lies inside, or its connection to external data sources?
By popular demand, we have been adding export interfaces to connect sophisticated
STEM model structures to accessible Excel inputs and outputs. Now we have turned
our attention to another kind of export interface, and a flash one at that!
Exporting a critical set of inputs
It is commonplace to make a distinction between the full range of business-model
inputs controlled by a model developer, and the more focused (sometimes very few)
inputs intended for the desired audience. In fact a very complex model on the inside
may grow from a specification for a model driven by only two or three key assumptions.
STEM version 7.3, to be released in October 2011, will have two new export commands
designed to automate the creation of coding of Adobe Flash interfaces, such as may
be embedded in a webpage. The Editor command allows you to export the required Flash
code to control certain inputs from the embedded Flash object. The simplest approach
exports any defined user data for the currently selected elements. Alternatively
you can specify the output more directly, as well as an allowable range for Flash
slider or spinner controls, using purpose-built sensitivity elements.
New ‘Export to Flash’ command in the Editor
A pure spreadsheet model might have such a ‘top-level levers’ front
sheet, as indeed might a linked interface for a run-time model created with Distributable
STEM (D‑STEM). But, in either case, the model has to be transferred to and
installed by the end-user, which may not be desirable if the model contains sensitive
data. In contrast, a Flash object embedded in a web page is likely to work on the
majority of computer platforms, and will be instantly accessible to a potentially
huge audience.
Generated and then embedded Flash object
Choosing what comes out
Current STEM users will be familiar with the two separate Excel export functions,
one for inputs and one for results, and the same rationale applies to Flash, even
though the inputs and outputs are ultimately bound into a single Flash user-interface
component.
The export of inputs (from the Model Editor) for Flash creates a core XML description
of the desired object, and a linked file which describes the inputs. The export
of outputs (for the Results program) is driven from selected graphs or results views
(just like the export to Excel) and also creates or updates the core XML description,
as well as a second linked file which describes the desired outputs. Unlike the
results export to Excel, which just delivers the numbers, the generated Flash object
contains embedded chart items, similar in appearance to the original charts in STEM.
The Flash object is compiled from three separate, generated XML files
In our current development prototype, we use the compiler from the Adobe Flex SDK
to manually generate the compiled Flash object (file with .SWF extension). In the
production system we envisage STEM being configured to execute the end-user’s
preferred Flash compiler directly so that a compiled Flash object really does ‘pop
out’ from STEM.
In practice, we expect anyone planning to use such a Flash interface in a commercial
environment to take the opportunity to manipulate and edit the generated XML code
to allow for a more compact and corporate ‘look and feel’ than we could
ever expect to create on autopilot.
How does it work, and where does it run?
Contrary to popular misconception, a Flash object does not ‘run on the server’;
rather the entire object is downloaded and then runs on the client browser. So how
does this differ from any other readily downloadable model with bells and whistles?
The critical distinction is that our Flash export is only an interface, analogous
to that ‘top sheet’ of a complex model. The model itself will sit on
a server – hosted by Implied Logic in the first instance – and the Flash
object will be generated with the required knowledge of how to communicate with
that server, with suitable security restrictions to avoid unintended visitors, robots
or malicious hackers from over-loading the server.
In fact our design very strictly limits the scope of what the server will respond
to or offer back from a given model, regardless of what an adapted copy of a local
Flash object might try to do.
How the Flash object interacts with the STEM model on the server
So we gain the immediacy and modern appearance of the Flash interface while getting
all the structural benefits of a STEM model on the back end. Furthermore, the model
may be connected to the usual wide range of external data sources, while any sensitive
data remains out of harm’s way on the server. Best of all, the model can be fixed
in situ independent of the Flash interface if any design flaws emerge in that model
after it has ‘gone live’. The days of waiting for an expensive user-interface update
every time a trivial model bug is reported are over!