Twice Shy

Have you ever rolled out an upgrade only to have people complain that they preferred the old version?

The Situation

I am in the process of replacing our last CRT holdouts with spanking new wide screen LCDs. Amazingly, some users are fretting about this. The problem is that they proofread on screen and have had bad experiences with pixelated LCDs in the past. While I wouldn’t begrudge their fears, I do feel a certain amount of exasperation. Like the troglodytes in Plato’s allegory of the cave, they are overly content with their dim, blurry views of virtual reality. Moreover, I don’t want to force them out of the cave into the sunshine. I just want to upgrade the fire to a lantern and smooth out the cave wall, so to speak.

Step 1

The first step was to select a monitor model. It was surprisingly hard to find reviews that focused on the monitor’s presentation of text. These persnickity users need to be able to spot an italic comma hidden in normal text. But the LCD market is all about gaming or watching movies. Contrast ratio! Woohoo! Color! Yeehaw! I finally settled on the 22″ Samsung SyncMaster 2220wm. Fresh out of the box, it was like a wall of light. You could use it to treat depression in stuffed donkeys. I probably spent 1/2 hour fiddling with the controls to get it just right, i.e., toned waaayyy down. Brightness down to well below 50. Then, a day later, after (ahem) reading the manual, I discovered a shortcut to “Text” mode. It automatically dims the monitor and changes the color temperature. Nice.

Step 2

The second step was the mention the monitor to the user. You would think the process would be like a commercial for a flat screen TV, where the customer drools unself-consciously in anticipation. Alas, this is slightly more difficult than getting our baby to eat a string bean. I had to mention the new monitor to her in passing and indicate that it was optional. I set it up and tuned it on my computer and asked her for some “sample documents” so that we could verify it would work okay. I waited a couple of days and told her that my examination of the documents didn’t turn up any problems with the monitor and invited her to view it.

Step 3 (not profit, yet)

The third step was to actually put the user in front of the monitor. Slyly, I didn’t let her sit down right away. Instead, I sat there talking and clicking, resizing windows, and even ignored her the first few times she asked if she could drive. Finally I said “Oh sure,” and got up. Upon sitting down she immediately grimaced “Oh, this isn’t good.”

Step 4

My hands clenched and I contained a sigh. “You know,” I said with feigned cheer, “it didn’t look good to me at first, but after a few minutes my eyes adjusted.”

A few minutes later, “No, it still doesn’t look right.”

So I changed the topic of conversation, she sat back, and a few minutes later she glanced at the screen.

“Hey, it looks good now. What happened?”

Turns out it was the distance. She was happiest about 2 feet from the monitor. Which makes sense becuase it’s a freakin’ 22″ monitor!

Step 5

Next user. Rinse and repeat. Ugh.

Just make a button – problem solved

I sat in on a meeting this week in which a librarian was talking to a publishing industry working group and getting a bit too granular about archiving digital books. There was a lot of silence, and then someone asked “Isn’t this the sort of thing that gets solved and we just press a button?” He wasn’t joking.

He’s on a digital working group and his attitude is that techies make buttons and his job is to press them.

A good reply would have been “What color would you like the button to be?” (to paraphrase a post I read recently)

Notes on a Freezer, a Hard Drive, and Apple Migration Assistant

There is an old techie’s tale that if you literally freeze a dead hard drive, you can bring it back to life long enough to pull some data from it.

Recently I had the opportunity to test this, and lo, it works! I put a the deceased hd into a firewire enclosure, stuck it in a ziplock bag and into the freezer for a little over an hour. When I hooked it up to its original home with a firewire cable (new hd already installed with OS), nothing came up.

Undeterred, I popped open disk utility (Applications/Utilities/Disk Utility). Previously, while the dead hd was still in the laptop I had tried to mount it in target disk mode to another mac, and even used disk utility, but nothing would come up. This time, to my delight, disk utility found the chilled drive. I went to the First Aid tab and clicked the Repair button. It repaired the volume header.

Awesome, but after closing disk utility the drive still wasn’t there. Quickly I logged out and back in without touching the firewire cable. And there was the drive! At this point I knew the clock was ticking, but hubris took over. Rather than simply drag the contents to the new drive, why not use the migration assistant and get all of my settings back along with my data, without having to adjust anything?

Migration Assistant is in Applications/Utitlites/. Many people seem to think you can only use this during initial set up to pull over the settings from another computer. However, this little gem will pull over settings from any former os x system hard drive (maybe even os 9, not sure). You can put it in a firewire or USB enclosure; in a tower, install it on the system as a slave drive. Then just run the migration assistant and point it at the drive. I’m not sure, but I think it might even work from a folder on any volume accessible to the system.

So I ran Migration Assistant and pointed it at the external drive. It worked great for about 1/2 hour at which point the drive died again. But the assistant didn’t care. It put up a [Continue] button and waited patiently for me to toss the drive in the freezer for another hour. Sadly, I wasn’t even able to get it to show up in disk utility again. However, it had fully migrated my user account and data. It transfers applications after accounts, but didn’t get to them.

Probably I should have skipped the migration assistant and just dragged the whole thing to the new disk. The data would have come over faster, perhaps all of it, after which I could have used the migration assistant without a deadline and wouldn’t even need to reinstall most applications.

Clicknesia

Clicknesia. n. Inability to remember where one has clicked.

Mouspasm. n. Uncontrollable spasm of the mouse hand that sends the cursor careening over large swaths of screen, usually accompanied by desperate clicks hoping to trigger something.

Example: Randomly click about the control panels of your XP machine. Land on Accessibility Options, then the Display  tab. Click the High Contrast checkbox. Notice or do not notice. It matters not. Wonder why nothing is happening. Click the handy Settings button right next to the checkbox. Stare at wondrous list of colors and possibilities. Scroll down until you find Windows Classic or Standard or something that looks familiar to you. Click OK OK etc. Sigh because nothing happened and forget you ever touched that control panel. After all, if you never truly intended to do something, could you have done it?
The next day notice that web pages look funny and call your IT person. Profess ignorance of causes. See how long it takes your IT person to figure out why all the background properties of the CSS on web pages in any browser on your machine appear to be disabled.

From Zen to FUBAR

Hardly anyone will admit to self-sabotage, even if you confront them with blatant evidence. People believe they must suffer a bit in life, and to support that belief, a person can confabulate a whole series of complex reasons.

I think Mr. Rogers first indoctrinated me. Be patient now, save your allowance, put in a little work cleaning up your room, in other words, suffer, and later you will get some kind of payoff. He was trying to instill a work ethic in our millions of wee minds. What can I say. In our culture we learn from the T.V.

Later in life we discover other reasons to suffer, such as to avoid creating more suffering for yourself or someone else. We take an insult to avoid an argument. We let someone cut us off on the highway without honking. We get Zen.

When technology causes us to suffer we often treat it like that idiot motorist. Sometimes it only mucks things up enough to annoy us. Lots of people think they are being smart if they adapt to system muck-ups and soldier on. In reality, they’ve just built suffering into their lives for no good reason. Worse, these FUBAR systems become the norm and actually get supported.

For example, I commute by bicycle, and the device that holds the lock on my bike is broken. I tried to fix it one day, got about halfway through the repair, was interrupted, and never finished. I satisficed by finding a way to attach the lock to the rack when riding. I tried to fix it again the other day but it lasted about one ride. The clattering as I go over bumps is normal to me now and I wonder what’s up if I don’t hear it. I’ve been doing this for months. Why won’t I take 15 minutes to go buy a new part? Instead, I’ve instilled in myself a habit of fastening the lock to the rack, and I’ve gotten used to the wrong way.

Users do this with systems. One might argue that they are forced to do so. After all, they have work to get done. I recently heard a user complain not four feet away from me (to another user), “My computer hasn’t been backed up for a month.” Rather than simply turn to me and ask if I can do something about it (after all, I am the one running backups), they utilize the moment to complain about technology and share an eye-roll.

I have seen documentation written by users that mentions workarounds for bugs no one ever reported. Now why would you write five paragraphs to explain a workaround when you could report the bug in an email and get it fixed? Maybe that person was trying to look smart. Not sure. The best case is that they just don’t think it’s important and don’t want to bother me. They were actually writing documentation, which is in and of itself a miracle.

In life, people tend NOT to complain right away, but they’ll quickly vote with their feet. If your sandwich shop is the only one on the block and does an okay job on most sandwiches, you’ll probably survive. But woe unto you when competition shows up.

Users behave in a similar manner with system features that don’t work for them. They just stop using the ‘feature,’ or never use it, and they never tell you. You only discover the feature has failed long after its failure is a fait accompli. How can one prevent this from happening? If a feature is going to fail, is there really anything you can do to stop it? Not necessarily. But the sooner you find out it’s a failure and why, the sooner you can learn from your mistake.

So… Get feedback early and often. Encourage users to write internal documentation. Put all your documentation into a wiki that the users can edit and you can see. Track and read the edits. If you don’t have such wikis, and there’s no chance of getting them started, ask department heads to get their internal documentation to you.

All I’m saying is if you just suffer a bit upfront by putting in this extra work, things will be oh so wonderful down the line. Heard that one before?

The Noodge

usertype{noodge} =>

The noodge is misunderstood to be a complainer or someone who pesters. This is a superficial definition.

Noodges must delegate most of their tasks due to the nature of their work roles—they rarely hold positions where they actually produce anything material—but they are utterly incapable of communicating delegated tasks in a manner that coworkers can easily understand. Thus almost every request from a noodge requires clarifications and a series annoyed questions and follow-ups to several other people. These follow-ups trace circular paths through most nodes of office hierarchy, inducing shaking heads, sighs, fowarded emails with sarcastic comments, and occasional bouts of fury. Noodge requests seem rude and off-hand, but this is usually due to a deficiency of empathy and foresight in the noodge, not any rude intentions. Noodges are often haunted by the well-founded suspicion that, although they must delegate, everything they delegate comes out slightly wrong.

Therefore, castigate not the noodge. Do not attempt to educated the noodge, for the noodge does not want or need further education. Seek no clarification from the noodge, for you shall only receive further obfuscation. Let the noodge’s requests pass through you unedited, so that the return path goes back to the noodge, and not to you.

A noodge-trapping preprocessor:

use UMM::DopeSlap qw( WTF? );

use Common::Sense;

use Time::MyTime;

if ($requesterType{$currentRequester} eq "noodge") {

   @realRequest = &noodgit($currentRequest);

   for $possibleRequests (@realRequest) {

      exit $_ if &processRequest($_) unless WTF?;

   }

} else {

   exit $currentRequest if &processRequest($currentRequest) unless WTF?;

}

sub noodgit {

   my ($request, $requester) = @_;

   while ( WTF? || $tm->wasted < 5min ) {

      push @realRequest, kwg ( gro ($request * peg ( $requester ) ) );

   }

   return @realRequest;

}

This is highly simplified, but the basic idea is if you must process a noodge’s request, do not do so directly. Always use peg to remind yourself of the user’s general personality, gro to rise above semantics and general rules of grammar to get at the meat of the intention behind the seed of the request, and wrap kwg around the whole thing to sift out the herrings. And of course, never process a request if you’re still thinking “WTF?”

Estimation Iteration

In an episode of ST TNG, Scotty comes back as a guest star and ends up working with Geordi on, well, you know, transferring the warp drive hoo-ha to the shields, or some jibberish the writers pulled out of their butts. At one point Scotty is aghast to learn that Geordi always tells Picard exactly how long it will really take him to accomplish things. He insinuates that Geordi still has a lot to learn.

When I first saw the episode I thought the joke explained a lot about Scotty. The second time I saw this particular clip was while bartending for a crowd of engineers. They roared with laughter. I understood that perhaps there was a broader truth here.

Then one day I became a sysadmin and merrily told people how long it would take me to accomplish their various requests. Oops. After a few years I’ve gotten pretty good at giving what sounds like a reasonable estimate that in fact gives me tons of leeway.

On the flip side, users will gladly pretend they have a deadline and guiltlessly make you run in circles for no good reason. “If I could have that in ten minutes it would be fantastic,” runs the typical plea. You drop everything and produce whatever it is they need. They thank you. Two weeks later you find out they haven’t even used it yet. That’s when you know you’re on the receiving end of repairman culture.

Pretty soon, if you start thinking about it, you realize that all sorts of people have been giving you bogus estimates of just about everything in your life, not just how long it will take to get something done. Look at how “Heckuva job!” turned out. In fact, you realize you have been giving yourself bogus estimates. This haircut can work for a few more weeks. These running shoes match everything I own. I’m pretty good at making spaghetti. What’s that about?

---

This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License.

Actively Seek Inaction

proud and unbroken
actively seek inaction
get to the point please

The diagnostic mindset can be a detriment. You can come off seeming rude, obnoxious, worse than a CIA interrogator with no leash.

“Did you install any software recently? Did you or did you not?”
“Have you changed any settings on your computer? Are you sure?”
“When did this start happening? Be precise.”
“Okay, but you said XYZ, which means it didn’t start until two days ago.”

You justifiably want to find out WTF happened. But users seeking help always provide a song and dance as preface to the statement of the problem. The preface is different every time, but you’ve probably noticed patterns. Some individuals need to vent before, during, and after statement of a problem. Others feel the need to explain the importance of the issue, as if they need to convince you it’s worth your time. Still others feel the need to prove that they’ve considered the problem in an intelligent manner before bringing it to your attention.

Actually, all of these are legitimate greetings in the office realm, and they reflect the given user’s relationship with the issue and with you. So here are some suggestions for getting people to get to the point.

Don’t be in a hurry. Sit tight and hear them out. If they are spinning their wheels, take it as an opportunity to ponder their relationship to the computer. You will demonstrate that you care about what they have to say, and give their momentum a chance to slow down.

Do not respond to accusatory language unless you plan to apologize for something. Occasionally users come off sounding like they’re blaming you, because in some sort of logic akin to the doctrine of original sin, you are guilty of everything technology throws their way, even self-inflicted disasters. Rise above this tone and move past it. It’s not your problem.

Do not respond immediately to incorrect statements. Ultimately, if the user does not understand how email really works, does it matter? Are you such a great teacher that you can convey the necessary concepts in a few minutes? If you must correct a user’s statement, do so after fixing the problem. Your correction will have more authority at that point.

Answer only questions that need to be answered. Some users can produce more ‘why’ questions than a four year old. Some can be answered with a smile, a shrug, or a roll of the eyes, or nothing.

Do not answer stupid questions with intelligent answers. If the question is stupid, it’s ill-informed. If you are cornered and must answer, then inform the user so that they can frame a better question.

Refuse to multitask. If someone speaks to you, or you speak to them, face them with full attention. I find that if I continue to work on a computer while having a conversation with the user, they tend to slip into a stream of consciousness that is mostly irrelevant to the problem at hand.

Learn to politely interrupt. This requires experience, empathy, and timing. The general principle is to let them spin their wheels until a natural pause comes, then somehow acknowledge the general trajectory of their spiel as valid and indicate that you understand where they’re going. Then, in the same breath, provide a new direction for the conversation.

Do not make it a secret that you would prefer to do nothing. The Tao says to do only what needs be done. Laziness is a programmer’s virtue. Just don’t come right out and say you are a lazy Taoist. Perhaps you can teach the user to fix the problem. Perhaps it’s operator error? Perhaps it’s not plugged in?

Do not blame the user, even implicitly. This will start a whole new stream of self-justification. Instruct, if you must, but not much.

Get to the point. I’ve never met a user who wanted an extended explanation. Ever.

Shiny Competence

always make progress
never admitting defeat
shiny competence

This one has always irritated me because a) it’s fake and condescending to put up a facade that plays to people’s weaknesses in perception, and b) it works every freakin’ time.

Why should it work? Why am I not allowed to utter the following while helping someone with a technical issue?

• I don’t know.
• I have no idea.
• I’ll try.
• I’m not sure.
• Let me think about it.

If you say any of these things, the person who has asked for your help will doubt your competence. You can often visibly see them cringe. They think, “Damn, I should have asked someone who knows what they’re doing.” It doesn’t matter who they are, how smart they are, etc. The moment you pause to visibly think, they think the worst.

So what do you do? You provide filler and busy work. You give immediate answers and start seemingly prudent diagnostic actions. You immediately set to work. You admit no uncertainty.

The funny thing is, you can choose not to answer questions that have answers like “I don’t know” and fill in answers to implied questions. For example, “What do you think is wrong with my computer?”

Real Answer: “I have no idea, but I can find out if you let me try a few things.”
Competent Answer: “Let’s see, do mind if I drive?”

The real answer gets a Pavlovian negative response. The competent answer does not. There is no real difference between the two answers except in tone. Yet because in the second one you do not come out and use words like “don’t know” and “try”, you’re okay.
I know this sounds bizarre, but it’s ironclad. I think it also explains how the current administration has gotten so much political traction with their arrogance, but that’s another topic.

The Contradictor

usertype{contradictor} =>

The contradictor objects to everything their interlocutor says. These objections do not have to be logical or even explicit but maybe communicated by as little as restating what someone has said in a doubtful tone of voice. Their favorite phrases include, “Are you sure?” “But yesterday,” “But I always thought,” “But this has never happened,” “But my home computer never does this,” “But you know,” etc. The contradictor is the king or queen of “but”. The amazing thing about their buts is that they do not have to bear any logical connection to the topic of conversation. The contradictor is simply compelled to fill in an objection after every statement you make. Try not to take offense. Try to sense when you really do not have to answer the objections, because the person is just thinking out loud. The highest compliment a contradictor pays is, “Oh, I guess you’re right,” stated in such a way that you still might be wrong. Ponder the logical disconnect and how difficult it must be for this person to perform basic daily tasks. Finally, clear your mind after conversations with a habitual contradictor. Do not search for justifications behind the contradictions.