Immediately upon release and use, customers and potential customers wanted more than just an image upload and some text. They naturally wanted to display their work instructions on JEM. Yeah, those hideous, Industry 3.0, laminated work instructions. So aside of just allowing customers to import digital files into JEM, eFlex management was convinced JEM needed some work instruction building capabilities built into JEM. Dev found a decent open source library and I designed an interface around it (as shown to the right). However, with feedback from customers, Sales was able to convince management how well received this function was and how worth it would be to built a custom work instruction editor (WIE).
With the go ahead, I really gave considerable thought to how such an image editor would be used. Having used Adobe Photoshop and Illustrator, Sketch as well as numerous other apps for a lot of years, I certainly had a feel for image editing tools and behaviors—BUT I'm not this user. Devs were syaing this is the way it should be. Sales was calling for functionality like that on Microsoft PowerPoint, because, "That's what manufacturers generally use to make work instructions."
First, manufacturing communications have always been behind the times, slow to change, first focusing on production than on marketing and advertising—doing the latter only when required. Typically. Secondly, this is a whole new, way of doing things. Very much disruptive to the Industry 3.0 status quo. Doing work instruction like on PowerPoint with connectivity is akin to taking a trade show pamphlet and using it as a TV broadcast commercial. So I quickly dismissed and fought against being PowerPoint-like. Again, who is it that would be using this? Who builds the work instructions? Not the person on the line. And how do we build this intuitively without much documentation?
Once the first mockups were laid out, a lot more requirements were being added—different viewing options, what does the library look like? What about templates? "We definitely have to have an approval process." Aside of developing an app-in-app structure (left-panel Tool Set / Workspace / right-panel Properties | Library tabs) I also designed an approval process, the library, a list view, a Get Started screen, and more. With weekly Product Review input an MVP version was very quickly implemented with further features added each release. Below are some of the highlight features.
Launches when the NEW footer button is clicked. Jumpstart buttons are displayed: NEW - 4:3 ratio, NEW - 16:9 ratio, and NEW - Custom. Also in a future iteration, jumpstart buttons for user-created templates will also display. In addition, a section for RECENT FILES displays the previously edited files. One can also dismiss the modal to scroll through folders and files in the Library accessed on the right-side panel. Icons at the top of the right-side panel allow quick toggling between small or large thumbnail previews (as shown below), and a toggle between the thumbnail views and a list view (also shown below). Additional icon buttons display an approval screen if the user has Approval authorization. In WIE, a user can have any of three authorizations: Editor, Approver, and/or Deployer, thus allowing them various views accordingly.
The heart and soul of WIE! Originally laid out with more functionality than would be initially developed, not only were the tools carefully selected, but their configuration as well—such as utilizing common placement of features from one tool set to the next. Even though this functionality would likely be used most often from an office, I wanted buttons and inputs large enough and spaced enough for quick editing on the plant floor.Below are some of the mockups showing the initial development of tool sets.
Basically, how the process plays out from scratch, first, a new work instruction is created—or an existing work instruction is duplicated as a template to create a like work instruction. Images are imported. Text, lines, shapes, and icons applied. All editing applied. Items grouped. Items locked. And to make an item dynamic, simply give it a DYNAMIC OBJECT NAME in its configuration settings and that is a dynamic object able to be manipulated by task events actions. Of course a work instruction need not be dynamic and just be a static image, but the dynamism does add whole new levels of functionality.
A simple explanation is, create a text box that reads, "Big Mistake!" and check the "Start Hidden" checkbox. Then, when configured to a task that dynamic object (the reject textbox) will not show unless an Event triggers it. In configuring the task, the user can create an event within the work instruction itself that if a reject happens, that message will then show. Or any message. Or any graphic. Or an entirely different work instruction.
Using the above configuring example, let's now take it a step further and examine dynamic work instructions more fully. The above mockup shows a dynamic work instruction as it's created in the Work Instruction Editor. Once created it's accessible to be imported into a task. And being a DWI each dark gray ring around each bolt is an individual dynamic object, as is the "Big Mistake!" text box—all with "Start Hidden" checked (not shown). All these dynamic objects do not show when the task starts, but show when/if triggered by an action event (e.g. Start, Pass, Reject). On top of these work instruction events, the same action might also simultaneously trigger task events (show a different work instruction) and/or station events (turn on a physical warning light, sound a warning beep).
The event configuration above when duplicated nine more times illustrates a torque task that when started all the dynamic objects are hidden. Upon Start (of the task) a yellow ring shows around all the bolts, except the first bolt is blue—the current bolt to fasten. Set upper and lower torque limits determine if a bolt gets rejected. If the torque is within limits, the blue ring turns green (Pass) and the next intended bolt ring turns blue. If a torque is out of limits or the wrong bolt is tightened the ring will turn red, the "Big Mistake!" message shows and any other reject event triggers.
Below is how this plays out on JEM.
This shows the possibilities that work instructions and particularly dynamic work instructions possesses. However, before any of this hits the plant floor they have to be approved. And this too can be done right within the application.
When a WIE Editor has completed a work instruction and it must go through approval, the Editor requests an approval, thus initiates the approval process for the work instruction—by clicking the REQUEST APPROVAL panel footer button. All assigned Approvers are notified. Each Approver can then individually go to the app to review the work instructions and approve or disapprove them. Once all Approvers approve a work instruction a Deployer can then deploy the approved work instruction with the click of a button. This will override any assigned work instructions at the next cycle or make it ready for use elsewhere.
All-in-all, the Work Instruction Editor was a HUGE addition to the application. It not only gave the capability to create work instructions—something that can be done in a multitude programs, but made them inter-connected with the eFlex application itself. As said in JEM, a lot of companies now created digital work instructions. But few have a robust editor, and no other work instructions have the dynamic objects. That in and of itself is a gamechanger.