My fancy text interface was too complicated



  • Many years ago, I had a stint where I wrote and managed some factory automation software.

    One set of machines were almost ideal for this.  When one placed material on the machine, it would read a barcode off of the bottom of the material container, and send a trigger which included that barcode to the automation software.  The automation software could then look this container up in the database, find out what material it had in it and what processing that material needed.  As the machine processed the material, it would send out triggers notifying the automation of the state of processing, which allowed the software to do some of the end processing early (processing generated a lot of data, and uploading that to the database as it came in saved several minutes of data upload at the end.  A time savings that didn't matter at all, because processing generally took about 20 hours, so it was unlikely anyone was standing by the machine when it finished.)  It also generated data on the state of the machine itself, so the software could notify maintenance when the machine would need cleaning after a run, including approximately when that would be (at least, so long as that notice wasn't sent to maintenance less than 15 hours into processing.)  And, when the material was removed from the machine, it sent another trigger to tell the automation software that, too.

    It sent triggers to the software to say when someone aborted a run (big easy-push red mushroom button beside the material pod), when the machine was powered off, powered on, or even someone pressed the reset button.

    In addition to all of those triggers, there was a separate API to request the status of all of the above things.  I've no idea how well that actually worked, because the triggers worked very well, and I never needed to explore the alternative.

    The command interface was pretty simple: you sent the machine a process file name, and it returned a status code.  That could be 0 - success (processing started), which would also be accompanied by a trigger that said the same thing.  Or it could be an error, such as 1 - machine busy (already processing), 15 - no material, or about six other conditions.  There were no other commands; to select a process was to start it.  If anyone wanted to stop processing, there was a big easy-push red button beside the material pod.

    The machine had a safety door that one had to close after placing material, before one could start processing.  If one tried to start processing before the safety door was closed, regardless of whether that was via a manual start or via automation, the machine would lock up (with red lights flashing), and would not do anything else, until one restarted it - a process that took 15 minutes.  The safety door did not send triggers to the automation software.  There was no way to get a status check on the safety door.

    This wasn't a major hurtle.  All automation software required an automation terminal, which looked sort of like the gadgets some grocery stores have their stock people use to link barcodes to prices, process inventory, and stuff.  Except these were simpler; they had no barcode reader, and they were physically connected with a cat-5 cable to the same switch that connected the machine to the network.  They had about 50 keys (no modifiers), and a screen size something like 40x16.

    Once the operator put material that actually needed to run on the machine, my automation software would tell them to "close the safety door and press any key to start processing"  This message was enclosed in a simple ASCII-art box, and centered on the screen.  If they instead put material that needed a different machine, my software would tell them that, displaying the error 'wrong machine' in banner-ish text at the top, and indicating which machine it needed in normal text in the bottom third of the screen.

    Once processing started, my software would display a running status, including an estimated time to complete processing.  The running status was not in an ASCII-art box, and was quite terse.  It said, "running ", followed by the name of the process, with the time left on the line below, in minutes.  When processing finished, it gave a brief message telling them where the material needed to go next, until they picked the material up off of the machine.

    Now, even with this simple interface, I still got some support calls about the UI.  I remember a few:

    • The space key stopped working on the terminal.  I've ordered a new terminal, but can you make it go remotely until it arrives; it'll take a week.
    • The enter key stopped working on the terminal.  I've ordered a new terminal, but can you make it go remotely until it arrives; it'll take a week.
    • The 'A' key stopped working on the terminal.  I've ordered a new terminal, but can you make it go remotely until it arrives; it'll take a week.
    • The terminal's totally unresponsive, I can't make the machine start.  (These calls fell into three categories: secretly one of the prior three, there was an error message on the screen, telling them why the machine would not process the material, or, the power was out to the building.  The last only happened once, the others many times.  Sometimes, the error message indicated they'd tried to start the machine before shutting the safety door, so a 15 minute reboot was needed.)
    • I pressed a key on the terminal before I loaded the material, and it didn't do anything... (Note: the software didn't display *anything* before they loaded material on the machine.  We had tried having it display an instruction to load material on the machine, but that turned out to be a bad idea.  That's an entire post by itself.  But even without displaying any text, they'd still try a total cart-horse inversion some times.)
    • I accidentally left my note pad in the material bay when I started the machine.  The interface doesn't give me any way to stop processing.  (That's because the equipment interface didn't give me a way to abort processing.  Of course, the big red button right beside the material bay would stop the processing just fine - and could've been invoked immediately, rather than calling the computer room, having me paged at 2AM, and waiting for me to call back while the machine happily ate the notebook and utterly de-qualled itself, requiring something like 30 hours of cleaning and re-qualifying.  And, yeah, they tried to blame all that downtime, as well as the loss of the notes, on my lousy programming.)
    • I see there's material running on {machine}, could you tell me how much longer it'll take to process?  (If you're close enough to the machine to see it's actually processing, you're closer to the terminal that displays that info than to the nearest phone.  Also, this question always came from someone who made at least as much as I did, rather than someone making barely more than minimum wage.)

    I also occasionally got calls from the people who maintained the processing recipes about partial data on material that was still in the machine.  Note that the first line of the data said when processing started, so that should've clued them in.  Of course, I did also get a call from someone who *had* noticed that, and therefore was wondering why the processing had aborted, and why the software hadn't uploaded a completion status code explaining it.  (Answer: someone liked to pretend this stuff's write once memory.  As I recall, that person was the user who had asked that particular question.)

    Note that the operators did not have my pager number.  They could only call the computer room, and the computer room techs had a document that explained that the users could press any key on the terminal - any key at all - to start processing, once the material was properly installed in the material pod, the safety door was fully closed and locked, and there was nothing else in the material pod.  This was the same document that indicated who they should call if there were any problems the document didn't cover.  Of course, the first thing they did when they got one of these documents was to copy that last bit of info on their big spreadsheet of who to call, and only a few of the computer room techs ever looked at the document again.

    (For those curious, they did actually use the wrong material error deliberately sometimes, to see where something needed to go next.  When it was material that had just run on the machine, well, it would've been nice had they looked at the terminal before removing the material.  But oh well; it would've been nice had I coded a delay between material removal and clearing the terminal screen, so there's sharable blame.  When I saw they used that seven times in a row on different containers, each needing a different process, and having sat on average around 5 hours since they'd completed their last processing step, and having each come from a different process, I figured I really needed to get my coworkers to give more useful error messages, as it's pretty stupid to hold material while a machine with a 20 hour cycle time finishes up its stuff, to be able to tell where the material's supposed to go.  Especially when they could just enter the container ID or the material ID into one of the handy computer terminals throughout the manufacturing floor, and find out that way...  Eventually, they added some material barcode readers to some of the free terminals, so you could just set your material down by the terminal, and it would show you where to take it.  Putting one of those by this set of machines eliminated that particular abuse.)

    Just in case, somehow, I hadn't made it clear, each of the main system states - empty, ready to process, error, processing, finished processing - had a very distinctive look.  I'd been told this was important, because while the operators were literate, many were not very keen on the concept.



  • Usually I recommend to show a message like "Press Enter" instead of "Press any key" because some people are confused when they have too many options, however since the enter key stopped working on that machine it appears that the only way out of this situation is a jerrycan of fuel and a match.



  • Those first three types of support calls regarding the terminal being replaced show that the maintenance department wasn't on the ball. If they were, they should have had a spare sitting around and ready to roll out in case of failure. Especially if this was such a common occurrence that it occurred multiple times.

    And while the computer room has documentation how come there is no mention of documentation for the operators? I've dealt with operators most of my career and they are generally trainable. And in fact talking to the operators is the best way to get info on how a process is currently doing and how it can be improved - keeping them on board is very important.



  • @tgape said:

    Just in case, somehow, I hadn't made it clear, each of the main system states - empty, ready to process, error, processing, finished processing - had a very distinctive look.  I'd been told this was important, because while the operators were literate, many were not very keen on the concept.
    Didja ever want to have all the function buttons and indicators labeled with big pictures so you can write instructions like "when the duckie and the horsey light up at the same time, press the bunny"?



  • @da Doctah said:

    Didja ever want to have all the function buttons and indicators labeled with big pictures so you can write instructions like "when the duckie and the horsey light up at the same time, press the bunny"?
     

    comedy gold



  • @OzPeter said:

    Those first three types of support calls regarding the terminal being replaced show that the maintenance department wasn't on the ball. If they were, they should have had a spare sitting around and ready to roll out in case of failure. Especially if this was such a common occurrence that it occurred multiple times.

    Actually, the maintenance department had a crate or two of the fsckers at any given time.  What the operators didn't say was, "it'll be replaced in a week - when it's time for the machine to be taken down for cleaning anyway.  In the meantime, we'll just run it in manual mode if you can't help us, and screw the data the engineers want to improve processing."  The maintenance crew could only run demand maintenance on their schedule when either the machine was not processing material, the machine dequalled due to out of tolerance processing failures, the machine was idle and no operators were around, or the operators present indicated they wouldn't need the machine long enough for the maintenance to be done.  This same set of rules, btw, also worked for any automation testing as well, and the operators gave us about the same level of priority.  And, yeah, I got on better with the maintenance guys, so the machines happened to be down for maintenance at least half the time I did automation testing, despite generally running a couple of weeks between maintenance cycles.

    The terminal failure rate wasn't that high for most of the place; those particular machines were generally number two or three on the list of most frequent terminal failures, despite having a 20 hour cycle time, and an interface that only required a single button press per cycle.  I suspect there was a reason for it, but as a contractor, there was no way I was going to get involved with that.

    @OzPeter said:

    And while the computer room has documentation how come there is no mention of documentation for the operators? I've dealt with operators most of my career and they are generally trainable. And in fact talking to the operators is the best way to get info on how a process is currently doing and how it can be improved - keeping them on board is very important.

    We're talking about operators who couldn't be bothered to read short messages written on the screen.  Generally, all I would need to do would be to ask the operators to read to me the exact text the terminal had on it, and they'd get about half way and say, "oh.  Hey, the foo key worked!".  You expect them to read the page of documentation I taped to the machine?  They never even seemed to notice its existence, so I didn't feel like mentioning it.  I tested that once by including the sentence, "the first operator to call the computer room and tell them to email Tgape and say they've read the documentation will get twenty dollars," on one of those pages, and left it there for a whole month, and never got such an email.  After I replaced the documentation with the previous version, I made sure to double check with all of the computer room techs, to make sure they hadn't missed emailing me or something, and I asked all of the operators for that machine I encountered if there was anything I had promised them that I hadn't provided, but there were no claims for the $20.

    As for finding out how a process is currently being implemented, in the particular environment I was talking about here, the way to do that was from the operators...  Not by asking them, however.  By going to a machine beside the one you're interested in, and either "watch" it or talk to its operators, while keeping tabs of the operators for the machine you're really interested in via your peripheral vision.  Most of them had very distinct ideas of how to get the job done, and a very distinct idea that anyone whose title included the word 'engineer' was not to be trusted with any of those ideas.

    @da Doctah said:

    Didja ever want to have all the function buttons and indicators labeled with big pictures so you can write instructions like "when the duckie and the horsey light up at the same time, press the bunny"?

    No.  I did, however, want to replace the automation terminal for that particular machine with a nice, easy-push blue mushroom button.  (Not green, because at least one of the operators was the sort who'd claim to have gotten confused between the red abort button and the green go button due to color blindness, and the factory management types would accept that story and wouldn't question why he was trying to press the green go button while it was half way through processing a batch - or, rather, 98% through, to maximum machine usage, and still scrap the material in a way that 'automation' could be blamed.)



  • Have you ever written anything succinct?



  • @blakeyrat said:

    Have you ever written anything succinct?
     

    I know, right?


  • Discourse touched me in a no-no place

    @tgape said:

    and I asked all of the operators for that machine I encountered if there was anything I had promised them that I hadn't provided, but there were no claims for the $20.

     

     

    I hope you showed them that page immediately afterwards, and then asked them to read the documentation in the future.



  • @tgape said:

    You expect them to read the page of documentation I taped to the machine? They never even seemed to notice its existence, so I didn't feel like mentioning it.

    @tgape said:
    As for finding out how a process is currently being implemented, in the particular environment I was talking about here, the way to do that was from the operators... Not by asking them, however. By going to a machine beside the one you're interested in, and either "watch" it or talk to its operators, while keeping tabs of the operators for the machine you're really interested in via your peripheral vision.

    @tape said:
    .. and a very distinct idea that anyone whose title included the word 'engineer' was not to be trusted with any of those ideas.

    So no explicit training, no direct engagement of the operators and general mistrust from both sides of the aisle. Yet you wonder why you get stupid service calls? I've yet to see an operator who wouldn't do as much as possible to make my job easier, because he knew that in doing so it would make his job easier. They may not be the smartest people in the world, but once you can connect with them at their level then things can go really smoothly - and as an engineer its your job to find that connection.
    @tgape said:

    Actually, the maintenance department had a crate or two of the fsckers at any given time. What the operators didn't say was, "it'll be replaced in a week - when it's time for the machine to be taken down for cleaning anyway.
    And it sounds like you terminal was not just a "terminal" but was a critical part of the design - so that is sounding like a design failure in itself if it was so prone to failure.
    @tape said:
    I suspect there was a reason for it, but as a contractor, there was no way I was going to get involved with that..
    Man talk about a missed opportunity for additional work.


  • ♿ (Parody)

    @OzPeter said:

    I've yet to see an operator who wouldn't do as much as possible to make my job easier, because he knew that in doing so it would make his job easier. They may not be the smartest people in the world, but once you can connect with them at their level then things can go really smoothly - and as an engineer its your job to find that connection.

    Depends on whether or not they're in a union and the union's view on work rules. Making their job easier for them might be something their union would explicitly prohibit.



  • @blakeyrat said:

    Have you ever written anything succinct?

    Yes.



  • @tgape said:

    @blakeyrat said:
    Have you ever written anything succinct?

    Yes.

    Your multi-line signature betrays you.



  • @nonpartisan said:

    @tgape said:
    @blakeyrat said:
    Have you ever written anything succinct?

    Yes.

    Your multi-line signature betrays you.

    Quotes in the signatures are confusing, they make it look like the post is longer. I think I'll include some in my own signature just to annoy people.


Log in to reply