Business-model delivery in a flash

06 May 2011

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!

© Implied Logic Limited