We are interested in the general topic of “design.” In the desktop Reactor Lab, we started out with each new lab looking differently than the previous one. We also observed that students are interested in moving through an assignment quickly, and that this would be aided by designing a consistent layout that could be applied to most labs: input on the left, process in the center, output on the right. Once you learn how to navigate your first lab, you can use that knowledge to navigate the others.
We were lucky to go skiing recently and stay in an old lodge. During the night, we got too hot. I remembered a thermostat on the wall. With the lights off and the room dark, I adjusted the slider on the side of the thermostat to a lower position in order to lower the temperature in the room. Below is a photo of the thermostat taken the next morning. What do you think happened?
We ended up cooking on top of the bed with the blankets off, even though the outside temperature was well below freezing! I had assumed that a lower temperature setting would mean sliding the control lower. Wrong! The more I tried to cool the room, the hotter it got.
What was the maker of the thermostat thinking? Maybe that Hell is down and hot, and clouds are up and cool? 😛
Design is not just nice to have. It is critical. Every time I hear about a disaster being blamed on “operator error,” I have a strong suspicion that the poor operators were trying to do their job – assuming they weren’t looking at their phones – but were more likely confused trying to operate a poorly designed system.
We recommend reading Don Norman’s recent post about the Hawaii false missile alarm, see especially the link to a photo of the operator’s software menu, and Norman’s book “The Design of Everyday Things.”
We uploaded an open-source version of SimzLab to our github project at https://github.com/RichardHerz.
SimzLab was an extension of the concept of ReactorLab to enable different types of labs, or “courses,” to be distributed from a single platform. Originally, one of the courses in SimzLab was ReactorLab. We later took ReactorLab out of SimzLab and stopped development on SimzLab due to lack of development resources.
The current SimzLab includes PureWaterLab, a project about water purification, a process Control Lab, and a Heat Exchanger simulation.
The Download section of this web site has a standalone version of SimzLab for Windows OS. For other platforms, you can download and use the open-source version with the free LiveCode Community Edition development tool.
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.
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.
We recently released the desktop Reactor Lab software as an open-source project on GitHub. View our open-source projects at https://github.com/RichardHerz. Contact us if you are interested in using this version or learning more about the structure and the code. The Lab is constructed with the open-source, Community Edition of LiveCode, which can be obtained at https://livecode.org.
We posted a new web lab with a simulation of dynamic diffusion and reaction in a porous, solid catalyst layer.
This our first web lab with multiple plots: two strip charts showing time history, and two profile charts showing time-varying concentration profiles in the catalyst layer. The way we handle data for these plots is different than we do in Lab 1, which has one strip chart plot. Our code structure continues to be under development.
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.
I was interested to learn about the work of Margaret Hamilton, who was awarded the Presidential Medal of Freedom yesterday. As a young woman, she led a team that designed the flight control software for the Apollo moon landers. This period was during the early days of computer programming when software design practices were just starting to be invented. Hamilton developed a theory and methodology for “design before the fact” of fault-free and fault-tolerant, real-time software control systems. The class of systems considered are asynchronous, discrete-event systems. This includes chemical batch process scheduling and control. Our web apps simulate continuous processes. Design Before the Fact contrasts with the development strategy we use, as outlined in my last post, but we will learn from Hamilton’s work.
Also at the ceremony at the White House yesterday, Grace Hopper was posthumously awarded the Presidential Medal of Freedom. She was an early pioneer in computing, invented the first software compiler, and popularized the idea of machine-independent programming languages.
Also see the blog post about other women engineers who were key figures in the moon landings.
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.