At our GitHub pages, we added examples of the individual controls – checkboxes, radio buttons, 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.
We have been working on our web page design project, lcCardLayoutToWeb, which is posted at GitHub. Here is a screenshot of a test page.
This new work should allow us to make interactive web apps more easily.
See our newest Web Lab, “Dynamic diffusion and reaction in a porous solid catalyst” at the Web Labs tab above. See the latest version of this web lab in our open-source projects at GitHub, https://github.com/RichardHerz/.
Space-time plots are a beautiful way to view dynamic reaction-diffusion systems. We added one to the Web Lab, “Dynamic diffusion and reaction in a porous solid catalyst.” Here is a static screen shot from the lab.
We prepared static plots of space-time data for our previous research work, e.g., at http://escholarship.org/uc/item/9bc7v3kv. We were inspired to make them dynamically by the fluid dynamics simulations of Oliver Hunt at https://nerget.com/fluidSim/ and Daniel Schroeder at http://physics.weber.edu/schroeder/fluids/. Those pages showed us that this was possible to do in a web page.
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 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 app experiments is a toolbox that enables development of interactive web simulations (“labs”). 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 as simple and general as possible in order to speed development of new labs and speed user comprehension when entering new labs.
Web app experiment 3 demonstrates feedback control of temperature during reaction in a continuous stirred tank reactor (CSTR). See the Resources tab, Web app experiments. Below is a static screenshot – click to enlarge.
At default conditions in manual control mode with constant inputs, the system oscillates. Do you know why the system oscillates? See the Resources tab, CRE Notes, 15 – CSTR thermal effects. Then put the system into Auto Control mode.
The architecture we are using is that of separate code objects, representing separate process units, which send messages to each other. This architecture allows us to change a simulation easily by adding or subtracting units from a system model.
These dynamic simulations solve a set of coupled, first-order, ordinary differential equations. This type of system is termed an “initial value problem.” The solution method is stepping in time (the independent variable here) using the Euler method. The Euler method has inherent numerical errors, as do other numerical methods, but the solutions can be corrected to approach the exact solution, as we have done in several labs in the desktop Reactor Lab.
Experiments by others show that the speed at which LiveCode web apps load can be made much faster through several techniques. In my first experiment, the files loaded to the Western US from the LiveCode server in France. Putting the large files, which are common to all LiveCode web apps, on CDN’s (Content Delivery Networks), which post copies on servers around the world, may speed loading dramatically. Other techniques may include loading only the parts of the modular LiveCode engine that are needed for a specific app.
See work by [-hh] at the LiveCode Forums and click the link “test it here” on that post.
HTML5 web apps have the advantage of cross-platform deployment – of a single set of files – on all platforms (operating systems) via web browsers. Web apps don’t have all the functionality of desktop apps and smart phone apps but they do have the main functionality we are looking for. LiveCode has cross-platform deployment on the desktop and as smart phone apps but you have to build and deploy a separate distribution for each platform. Web deployment is under development in LiveCode version 8 but our initial experiments show that loading the first app is slow: about 40 s currently in my browser in California fetching the page from the server in France, where load times increase with distance from the server. But this is a development version of LC 8 and speeds may improve in the future. In contrast, HTML5 web apps are small and load fast.
Layout of LiveCode screens (“cards”) is easy and fast. Just drag and drop both active (e.g., buttons and widgets) and graphical elements. You can easily change the appearance and locations of elements with script when the app is running – so far it seems more easily than in HTML5. For HTML5 apps, we are using the desktop tool MACAW. In that tool, you can also drag and drop elements onto a page, then generate HTML and CSS files but not nearly as easily as LiveCode.
Bottom line of initial impressions? LiveCode wins in ease of development and power. HTML5 wins in deployment – one set of files across all platforms – and speed of loading. We are leaning to devoting our efforts for future development to HTML5, although we are going to keep an eye on LiveCode to see if the speed of loading web apps improves significantly.
We are pretty happy with MACAW. It definitely speeds up the process of learning CSS and laying out a web page. One very nice thing is that it generates standalone HTML and CSS files – you do NOT have to link your site to a proprietary library.