At our GitHub pages, we added examples of the individual controls – checkboxes, radio buttons, plots, etc. – that we use in our Web Lab simulations. These examples are easier to read and understand than controls embedded in a complete simulation.

See these examples at our GitHub site

In addition, all of our Web Lab source code can be viewed in your web browser by viewing the page source.

The first two web labs listed at the Web Labs tab have the latest Javascript code structure. Our approach is to have a collection of Javascript code objects, each of which represent individual process units, or “unit operations” in chemical engineering terminology. Each process unit object contains definitions of variables that define the current unit state, and methods that update the unit state at each time step. One objective is to make the unit code objects as independent as possible so that they can be copied and used in other simulations.

In an earlier post, we mentioned the web apps being developed by Tony Butterfield. His web apps have a different structure than ours, and it is interesting to compare these two approaches. You can view the source code of the web apps by choosing View Source in your web browser.

Butterfield’s web apps have a parent code object that defines a child object for each variable in the simulation. This is in contrast to our collection of process unit objects. You might say his app structure is variable-centered, whereas ours is process-unit centered. His variable object definition appears to have been entered in a spreadsheet and then translated to Javascript, since it is minified.

Butterfield’s web apps have a single method that updates the state of the simulation at each time step, vs. our process unit objects, each of which contain a method to update themselves at each time step. For plotting, his web apps record variables values at each time step in each variable object, vs. our 3D numeric array that records the history of all variable values, with individual process objects storing only their current values.

Both approaches work, and it is valuable to have a choice for web app development.

The goal of our Web Labs is a toolbox that enables development of interactive web simulations or “labs,” and a set of labs built with this toolbox. Our development practice is as follows.

First, Get something up on the screen. Often this involves finding an example on the web and modifying it. Don’t spend a lot of time designing and thinking before something simple gets running. We believe that it is better to get something useful running than it is to have a beautiful plan and theory in development but nothing working to show for your time.

Second, repeat the following:

• Add functionality.
• As we observe repetition of code and see patterns developing, generalize the code. Have the objective of maximizing code in libraries and minimizing code needed to build new labs.
• As we observe patterns developing in the user interfaces, refine the design of a user interface guideline that is simple and consistent between labs in order to speed development of new labs and speed user comprehension when entering new labs.
• As we have time or run into problems 😛   read and learn about Javascript and CSS and design principles and try to incorporate better practices.

The most recent versions of the Javascript code are the first two labs listed at the Web Labs tab. The other experiments work but have code that was developed at an earlier stage of this software development process.