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.

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.

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?

Example 1

A friend was having mystery trouble with a php script the other day after performing an upgrade to another application that interacted with it. He had already done quite a bit of troubleshooting before asking me if I had any ideas. Although I did have a few suggestions he hadn’t tried, none of them revealed the culprit. We were starting to get frustrated. I took a deep breath.

“It’s probably something stupid,” I said. “Go back through all the most basic things you can think of, even if you think they couldn’t have changed.”

Sure enough, it was directory permissions. The new php script wasn’t set to 755.

Example 2

User asks me to make sure her new office is ready in terms of internet connectivity. I’m very careful, have made sure the jack is active, that her current machine will pick up an address when on that subnet, etc. A week or so goes by. She hasn’t moved in yet because they haven’t transferred the phone. She calls me and tells me her email stopped working a few hours ago.

Well, you know the drill, “email” means all network connectivity. The user just hasn’t realized it. I try some basic network stuff, and the machine can’t even ping the gateway. But the ethernet cable is plugged in. There are two jacks, and it’s in the right-hand jack, which I consider for a moment as odd, because I use the left-hand jack on my subnet (we have more jacks than switch ports). But this isn’t my subnet, and this user wouldn’t have touched the cable, right? I ask her. “Oh no, I didn’t touch the cables,” she says.

So from there I assume something has gone wrong with the network settings on the computer. Fifteen minutes later I’m pretty sure the jack is dead. You probably figured out where this was going already.

“Did they transfer your phone today?” I ask.

“Oh yes, thank god. I was wondering when they would get around to it. I’m moving into the new office tomorrow.”

I get down on my knees and put the cable in the left-hand jack. I pull up a browser, which works fine.

“You’re good to go now.” I say.

She stares at me and then the lights come on. “Oh dammit. Did the phone guy do something? Is my phone an internet phone?”

“No, you don’t have an IP phone. He mistakenly unplugged the ethernet cable and then put it back in the wrong jack,” I tell her, but in a friendly way. To users, what we do, or what “phone guys” do is voodoo. That our actions might somehow overlap in the world of jacks and cables never occurs to them.

Anyway, here’s hoping that the next time you’re in a “plug the damn thing in” scenario, you realize it sooner rather than later.