[BC] Thought For The Day: Understanding the operator

[Jeffrey Kopp]

Bob at B-D makes an excellent point. Operators view the system in a radically different way than techs because, well, they operate it--live and eat if not sleep with it. They have rhythms and methods of work that aren't obvious to someone who just comes in to fix things--or takes it away to do so. There is also a logic to their view which is fairly consistent, but just isn't going to be the same as that of one who knows the innards; i.e., "how it really works" vs. "is supposed to work." My experience with ETs while a radioman laid the groundwork for my approach post-service; until just a few years prior to my service, RMs had maintained their own equipment, and the division of labor took some years of adjustment. (Various battles with telco Special Services helped.)

Reaching back in my non-broadcast experience, WordPerfect had a 
beautiful consistency in design and operation philosophy--a "mindset," if you will--that made using it proficiently possible without having read much of the (thick, richly detailed, and almost perfectly accurate) manual. When I finally persuaded the IT guys I had half a clue and wasn't just a typist-cum-hacker, they allowed me to completely rework our extensive and intricate macro library (fairly well designed by consultants to work with a third-party document-management system and also generate or pre-format various complex legal documents, but rapidly obsoleted incrementally by software and procedural changes), write a few scripts (these were mainframe guys who didn't know and mistrusted DOS, never realizing just how much a good batch file system could do, even over the network), and even design an app. These were quite popular because they looked and acted "just like WordPerfect" (at which the IT guys were self-admittedly duffers) and could therefore be operated intuitive!
 ly.

The only apps I developed (two) were begun with a knowledge of what was needed, but I designed the main screen display/keyboard actions first, then the menus, and lastly, the back end that did the work, which was neatly fitted to the already designed and tested interface. (Modern program-design wizards work like this, but not so well.) This way, the user saw a system that operated logically to their expectations and conformed with their experience. This is informed fool-proofing, as opposed to merely locking the system down.

When I had a half-functioning prototype of a system (just the UI front-end) and persuaded an operator to deign to test it for me, within about 15 minutes several crucial oversights would be brought to my attention, which I couldn't see because I had already gotten too involved in the details, and the feedback at that early stage saved me a lot of reworking later on.

Allowing for operator convenience is more than just that, but 
recognizing and accommodating the exigencies and pressures they work under. When I showed IT how software updates could be delivered over the network by bootup client pull (previously, they'd been trying to keep four floors of PCs updated by running around with floppies), it was first implemented so the update was downloaded repetitively on every boot over a week's span. This took a few minutes and in many cases operators couldn't wait to begin work; it was especially annoying when the update had already been delivered. So my batch file update system created a null text file on the client with the update number in the filename so it only snagged updates not already obtained, and updates were kept available for a month after we discovered vacation-taking would cause missing an update made available for only two weeks or less. Finally, a "skip update" option (which timed out to the default of downloading if no response) was added, allowing a rushed operator to defer updating f!
 or up 
to a week.

It was Windows Update before Windows, and all in DOS batch.

Our consultants had put WP's customization menus behind a password 
prompt, because fiddling in there could disrupt our 
document-management system or cause training problems 
(inconsistencies between stations). (There's a parallel here to 
nonfunctioning thermostats and "PD joy knobs" on processors.) This was OK until we got color displays, when naturally everyone wanted to set their own colors. (By this time, some operators were obtaining WP at home and becoming aware there was more to it than we let them see.) So the "help desk" was compromising the password by giving it out selectively and arbitrarily to vain screamers who demanded self-customized colors. My solution was to bring up the color-setting screen immediately upon hitting the custom-menu key. Who cares, pretty colors didn't compromise the system's integrity; that's all most wanted, and they loved having it come right up single-key. The previous prompt to enter a password didn't even appear in this mod; we knew what it was, and typing it in blind at the color-setting screen would give us access to the other menus--the philosophy being, don't advertise something you don't want the existence of known, nor throw an insulting reminder at users that a p!
 ortion
 is off-limits to them.

This part was all done in WP macro language, which by ver 5 could handle multidimensional arrays (there was a trick to this) and determine precisely what screen/menu was displayed (though one had to know Boolean to use this), so we could trap out inappropriate keystrokes or macro operations with precision, eliminating much user FUD about blowing something up (losing a document!) by pressing the wrong key.

Oh, while I'm rambling, I might mention that before winning the trust that enabled me to do this stuff, I was dispatched to clean laser printers with a brush, a hundred or so of them, which took me two or three months. But this make-work drudgery in remote-floor Siberia paid off in that I got to spend half an hour behind the desks of secretaries, eventually every one in the office, discreetly observing their work, and discovering many surprising misunderstandings, misuses and abuses of the system, as well as malfunctions or odd stations that had gone unnoticed by or unreported to the IT staff. Discovering and copying user-created "cheat sheets" was also valuable in designing training and future mods of the system.

The IT staff had a policy of "we don't change toner carts," but the secretaries absolutely hated to do this; they'd get a box, start to open it, and then let it sit while their printers ran down to gray streaks. I tried (and failed) to sell the notion that (1) it's good PR for a tech to come do that 15-second dirty job (though it was often a five-minute or longer round trip), and (2) it's a valuable chance to inspect the station and take a measure of the operator (I mean proficiency and attitude, not their legs--that was a side benefit).

I made it my habit to briskly stroll all floors once each day, so I was visible and operators could flag me down to discreetly ask about something they'd been reluctant or hadn't gotten around to calling in, plus I could follow-up on a ticket by inquiring if the solution had worked as expected, needed further explanation, etc. It was also a cursory check for hazards (user-moved equipment, taut cords or cords across floors, unauthorized attachments, missing font cartridges, etc.) and other impending disasters, and kept me familiar and oriented with equipment locations and the staff. Oh, and I changed toner carts while making the rounds.