Ed's an EE, PE, and author in Poughkeepsie, NY. Contact him at [email protected] with "Dr Dobbs" in the subject to avoid spam filters.
Essentially all consumer electronics contain a computer of one sort or another, with the user interface pared down to a few buttons, a knob or two, perhaps an LCD panel, and little else. The term "intuitive" may have fallen out of favor, but every single gizmo is easy to use. At least that's what the ads say, anyway.
System designers face the problem of stuffing more and more complex functions inside gizmos bearing fewer and fewer external controls, intended for operation by unskilled users who never read the instructions. Although this works surprisingly well, the failure modes can be equally surprising because there's only one way for the thing to work correctly and many, many ways for it to fail. Figuring out what happened and unwedging it can be nearly impossible, particularly given the paucity of evidence presented by a pared-down user interface.
We engineering bears know that complex systems occasionally seize up and we're quite willing to defibrillate them as needed. Ordinary folks (that is, friends and relatives) regard a jammed computer or erratic appliance as a catastrophe. Even if the gizmo came with a decent manual, uncovering the actual problem from the symptoms, then figuring out how to fix it, can be a major undertaking.
Oh, they call you for help, too?
In recent weeks, I've had several experiences highlighting this problem. Let's take a look at just how hard it can be to "read the fine manual" for typical problems.
What Does This Mean?
Back around the turn of the millennium, I saw an ad for a thing called a "Mailstation." The pitch was that you could do e-mail "without a computer" and it was obviously intended for people who were intimidated by PCs. The user interface was a monochrome LCD over a squashed QWERTY keyboard, plus a phone jack in the side. Imagine any personal computer before the IBM PC and you'll have the right order of magnitude.
A Mailstation didn't make much sense to me at the time, what with a price up to $200.00, depending on rebates, plus the cost of a standard ISP account. Except that you didn't get web browsing, and it couldn't handle picture attachments, print messages, or do much of anything else. If all you wanted was text e-mail, it would suffice.
At about that time, my sibs and I set up a PC for my mother. I briefly considered a MailStation, but then she wouldn't be able to receive or print granddaughter pictures and, believe me, that was a deal killer right there. So she got a 433-MHz Windows 98 box (this was late 1999, okay?), I showed her how to use a few vital Outlook Express and MS Works functions and, after a few false starts, she was up and running.
Her Christmas card envelopes now sport neat labels and a friend recently asked her to type up transcripts of Civil-War-era letters found in the canonical attic trunk. She swaps e-mails with several folks every day. All in all, we count it as a success.
Early this year, that PC began suffering from random crashes, applications failures, and the occasional BSOD. Virus scans came up clean, so it was evidently another case of Windows bit-rot. As you might expect, she's not well-equipped to cope with that sort of thing and it took a considerable effort to convince her that the errors and crashes were not her fault.
Rather than reinstall Windows and hope for the best, I swapped in a slightly more recent 1-GHz box running SuSE Linux 9.1. The user interface is close enough and the screensaver displays all the pictures I've taken at family gatherings over the last several years. Plus, of course, the obligatory granddaughter pictures.
What level of documentation do you think is appropriate for her?
Windows itself has minimal documentation and help, although you can buy any number of kilopage tomes at the bookstore. Linux comes with megabytes of doc, tucked in various subdirectories in any of several immiscible formats. In all cases, the doc describes what a particular program does, not how you can accomplish a particular goal.
I put together 20-odd pages of step-by-step directions for the most common tasks, including screen captures of the key dialog boxes with highlights on the important buttons. We walked through the tasks, added a few notes and scribbles to the directions, and she was up and running. As far as she's concerned, while the eye candy may be slightly different, SuSE Linux works just like Windows, even though she's now using a full-throttle, multiuser OS.
All was well, until I got a phone call: "My e-mail doesn't work. The computer says something about an ess-em-pee-tee error."
That's the message you get when you forget to dial up the ISP before fetching new messages with K-mail. My little how-to book included a page showing that error message and explaining what to do about it, but, well, you know how documentation works.
Mom really, fundamentally, doesn't care about the computer part of e-mail and writing and suchlike. All she wants is something quite reasonable: The PC should Just Work, all the time. Failure, to borrow a phrase, is not an option.
Wouldn't it would be nice if error messages gave both the cause of the problem and how to fix it? That may not be possible in the general case, but the error message here is helpful only if you know far more about Internet operations than any civilian really should.
I walked her through the solution, pointed her at the appropriate page in the notebook, and that problem's behind us.
Your job, and you should choose to accept it, is to write error messages to identify and solve problems without assuming knowledge of all the doc. You can depend on your users to not read the doc, because they just want to get the job done, not get an education.
Why Doesn't It Network?
My home office has a network with a few Linux boxes and a token Windows XP laptop for gadgets, like my device programmer, that just don't play under Linux. Having read many of the fine manuals and figured out where the config files hide, I know perhaps slightly more than your average bear about this stuff.
Which means I get calls from friends and relations who just installed their second Windows box and maybe a router. Sometimes their new network Just Works, but when it doesn't, finding the root cause can be really tricky.
Oh, you get those calls, too?
My friend Eks called a few days ago to say that his new Dell laptop with integrated Wi-Fi didn't talk to his other two PCs or his wireless router and did I have any ideas? He'd already spent something like an hour on the phone with Dell and another 45 minutes with Belkin, twiddling this and changing that, all to no avail.
I repeated many of the basic tests: pinging, tracerouting, examining the various setups, and so forth and so on. Pings worked from some machines and not others, but all the routes seemed correct, all the connections showed good signal strength, and so forth.
To make a long story short, if you follow this trail:
Start Button
Control Panel
Network Properties
<select the wireless NIC>
General tab
Properties
General tab
There you'll find an entry for "Client for Microsoft Networks." If that item isn't checked, even though pings and routes and suchlike may work, your PC won't play with your Microsoft network. It should never be unchecked, but that was the situation with Eks's new laptop.
I can see why tech support didn't solve the problem: That checkbox can't possibly be on anybody's scripts. Maybe Eks unchecked it while flailing around, perhaps accidentally, perhaps on the advice of tech support? We'll never know.
Your job is to figure out how to explain to a bright, but inexperienced, user, how to make a dysfunctional network Just Work. Remember, it's supposed to work right out of the box, so you start at a disadvantage. I'm certain this is impossible at the current state of the art.
Where Are My Photos?
If you've ever used a 35-mm film camera, you've certainly had one of these two experiences: Either you managed to not engage the end of the film strip in the takeup spool or you didn't rewind the film before opening the camera's back. In either case, all those pictures you took simply vanished. Metaphysically speaking, the latter is more heartrending, but the effect is the same.
Digital cameras take this to an entirely new level. I use a Sony DSC-F717 digital camera to record my projects and to take pictures of the aforementioned granddaughter. It's a 5-megapixel camera that stores 2-MB JPG images on Sony's proprietary Memory Sticks.
One weekend, I took some pictures of early-morning hot-air balloon launches, then transferred the files to my desktop SuSE Linux box. Every time you plug a USB memory device into a Linux box, this line appears in /var/log/messages:
kernel: WARNING: USB Mass Storage data integrity not assured
This time, as previously, it worked perfectly. I put the Memory Stick back in the camera and erased those image files.
That afternoon, our daughter pedaled her recumbent to win a USCF-sanctioned criterium, which is noteworthy because USCF rules exclude recumbents. However, if you're under age 13 you can ride "any type of bike," which she did.
Anyhow, I returned with many granddaughter pictures, popped the Memory Stick in the card reader, and...it didn't work. Not only did it not work, I wound up with the morning's file directory written atop the afternoon's pictures. The first picture was okay, but the rest were trash.
This may have been a user error, it may have been a system problem, it may have been anything. One thing was certain: I had to get those pictures back!
As nearly as I could tell, both the FAT directory structure and JPG image files were intact; the directory just didn't match up with the files. If I could extract the image data from the Memory Stick without using the FAT directory, the images should be recoverable.
This being a Linux box, I had at my fingertips a whole bunch of vowel-deficient tools designed for dissecting files. With coaching from folks in the Mid-Hudson Valley LUG, I managed to get the job done. Here's a quick summary:
Copy the raw Memory Stick data into a file:
dd if=/dev/sda1 of=memstick.raw
Each JPG file had an EXIF header near the front, so the start of the images were easy to find:
grep -b Exif memstick.raw
The FAT file structure puts the start of each file at a 512-byte boundary. I dumped grep's output into a text file, imported it into an OpenOffice spreadsheet, converted the offsets into hex, forced the low-order hexits to zero, converted back to decimal, created a series of dd commands that copied 3-MB hunks of the raw file into separate files, turned those cells into a script, and applied it to memstick.raw.
Applying ImageMagick's convert program to those chunks turned them into respectable JPGs with no trailing junk. Having started with an empty directory on the camera, all but one of the files were contiguous in memory. If I were recovering data from a fragmented hard drive, things could get ugly.
I picked the best pictures, applied a dose of The GIMP, and e-mailed them to Mom. It worked: Life is good!
This is well beyond what you might expect from any rational user, but I'm quite certain that, regardless of which OS or gizmo is in charge, Memory Sticks and other digital media occasionally have, um, incidents. The question of whether a manual could describe how to salvage the data remains up for grabs.
Homework: Design a free-on-the-CD "Wizard" to fix the five most common problems with your gizmo's data or configuration. Write a manual explaining when and how to use the Wizard. Extra credit: Describe what happens to the Wizard on a Linux box under Wine.
The Job Undone
Systems embedded in consumer gear are approaching the complexity of desktop PC systems and, with embedded Windows and Linux, they may essentially be desktop PCs with stripped-down user interfaces.
Given the myriad ways that such complex systems can go wrong, is it possible to write instruction manuals that will not only be read, but also be useful when things go bad? The current evidence suggests that it's not possible even when things work.
Worse, if a customer calls up your tech support line, will she get a meaningful response? After spending an hour trying to get a new system networked with the customer's existing equipment, would your company accept a "does not work" return?
Making gizmos usable is certainly feasible, but recovering after things go badly wrong seems entirely different. I suspect that all the people who read manuals (me and, perhaps, you) have been working with this stuff for years, so that packing more reading material in every box will be self-defeating.
Anybody have any suggestions? Failing that, any good stories?
Wavelengths
Methodical readers Mark Innes and Keith Dow pointed out, quite politely, that I had my Stupid Cap pulled firmly over my eyes in the September column when I wrote that a signal's wavelength on a circuit board is inversely proportional to its propagation speed. In fact, as clearly shown by l=c/f, as the speed c decreases, so does the wavelength l. The numbers in the subsequent paragraphs were correct, though.
Keith also mentioned that board cost has several other drivers, most significantly the number of layers. As long as the conductor length is less than the critical length for the frequencies involved, standard board layout rules may require only four layers: power, ground, and two signal layers. The power and ground layers can contain a few signal conductors, but ideally they are uninterrupted copper sheets.
As the conductor length increases at a given frequency, layout rules mandate RF-friendly configurations by surrounding them with ground conductors and layers. Those additional constraints reduce the wiring density and increase the number of layers, dramatically increasing the board's cost.
System designers will do nearly anything to avoid that, which means that RF-friendly trace layouts occur only when absolutely necessary, which means that high-speed serial buses are a Good Thing. The equation looks something like this: fewer critical traces = fewer layers = lower cost = lower price = happier customers.
I think I have that one right.
Reentry Checklist
Earthlink acquired Mailstation and, although some new models have come out, it's obviously an orphan. More at http://www.mailstation.com/, which will redirect you to the Earthlink FAQ.
The GrokDoc project may be biting off more than anyone can possibly chew, but reading through the usability studies at http://www.grokdoc.net/ shows you just how horrible PCs are for novices.
Notebook computers used to be called laptops, but then the CPUs and disk drives got hot enough to smoke your shorts. If you're using a Dell Inspiron, you need the fan control utility from http://www.diefer.de/i8kfan/.
The United States Cycling Federation rules are at http://www.usacycling.org/rulebooks/ 2004_uscf_rulebook.pdf. More on why they exclude recumbents is at http://afchap.home.mindspring.com/BentHist.htm. All the bicycling speed records (and some wild and crazy bikes) are at http://www.ihpva.org/.
A list of Linux User Groups is at http://www.linux.org/groups/.
Far more detail than I needed to know about the Exif file format is at http://www.media.mit.edu/pia/Research/deepview/exif.html.
DDJ
