FAQ: How do you design industrial software to work like apps?
This post first appeared in Automation World. Greg Giles is Director of MES Error Proofing Systems, Jason Stefanski is Manager of Test Systems Software and Controls, and Doug Brown is Senior Software Engineer at RedViking. They each oversee teams of engineers who design software for manufacturing and test systems.
How has industrial software design changed over the past 5 years?
Greg: It used to be acceptable to have a grid view with some simple status updates. Today we’re creating actual views of the parts being assembled and highlighting where the parts are to be placed. And historically where touch screen devices wouldn’t have ever been considered, we’re looking ahead to multi-point touch with zoom and scroll. Doug: 5 years ago, an operator would’ve had to look at a manual to know the sequence to torque bolts onto a part. Now we’re building inherent work instructions right into the UI (user interface). Our application shows them the torqueing pattern, lets them know when they’re successful, and then shows them which bolt to torque next. Jason: We also use simple call outs and a clean interface to make the system more intuitive. It makes training a lot simpler because people can be easily trained across multiple machines, and it makes operations a lot more straightforward for the user.
Example of Operator Workstation (with Non-proprietary Part Image)
Doug: For the operator’s sake, it’s a lot better. If you have to do 12 click-through’s for the job you do every day, you’re going to hate it. A lot of our changes are driven by a better understanding of what the operator does frequently and infrequently.
Is this harder to maintain than the old “boxes and text” UI?
Greg: No, but it really pushes the need to have a good configuration interface. We’re experts on delivering the right systems but our customers are the experts on their processes. We provide them the ability to upload images and highlight areas of the images for an individual process. And they need to be able to have a technician do updates, not an engineer. Jason: That’s been a big change the past few years. I’ve seen it go from “Hey, I need an engineer to change the test configuration”, to where an operator can do it right on the screen. It involves more work in the initial development of the software, but it’s easier for our customers to use and manage long term. Doug: We like the secure browser-based approach because it gives us a dynamic platform. You’re not developing something for a specific HMI (human-machine interface); you’re developing for a browser that someone can use from a laptop, a phone or an HMI. It makes the entire system easier to maintain because you’re not maintaining multiple device-specific applications.
How much does your design vary based on the user?
Doug: Our goal is to write software so that nobody has questions, no matter who the user is. Again, there’s a lot more work on the design side, but it costs our customers less in the long run. Greg: Our users go to lunch and they go on Facebook and Instagram and Twitter and all of our stuff has to be just as intuitive as that. We don’t write code and compare it to other industrial software as much as we compare it to all the other applications that people interact with. Jason: We have users who are in their 20s and users who are in their 60s and we’ve gotten good feedback from both ends of the spectrum.
How do you evaluate our software’s usability before you release it?
Greg: We build in an approval phase where the UI look & feel are bought off on before development begins in earnest. That way everyone can understand what it’s going to look like and how it’s going to act before the back end is created. Doug: If you go through development before anyone has seen the UI, you don’t know what you’ll end up with.