Reading Usable Help
@UsableHelp on Twitter
Gordon R. Meyer
Standard reference for mobile doc development
Joe Welinske's Developing User Assistance for Mobile Apps has been revised and expanded. It was the first publication for practitioners to address how to deliver and develop content, and it remains the best. The new edition is available in several different formats, too.
Michael Dobbs, writing Nuclear Option for Smithsonian magazine, describes the iconic "Football" valise carried by the President of the United States. The full contents of the bag are mysterious, but we do know that the secret codes and instructions for launching a nuclear attack are among them.
These instructions might be the most important technical documents in the entire world. In addition to being the one manual that you hope is never used, it seems that for many years the instructions were overwhelming if not situationally unusable. Dobbs writes:
A recurring complaint of presidents and military aides alike has been that the Football, which currently weighs around 45 pounds, contains too much documentation. President Jimmy Carter, who had qualified as a nuclear submarine commander, was aware that he would have only a few minutes to decide how to respond to a nuclear strike against the United States. Carter ordered that the war plans be drastically simplified. A former military aide to President Bill Clinton, Col. Buzz Patterson, would later describe the resulting pared-down set of choices as akin to a “Denny’s breakfast menu.” “It’s like picking one out of Column A and two out of Column B,” he told the History Channel.
Kudos to the unknown tech writers and designers who improved the documentation. Can you imagine what it must be like to have this assignment?!
So long, Macworld
After 30 years of publication, the venerable Macworld magazine will no longer produce a printed magazine. I'm inclined just to say they're out of business, but I'll defer to the publisher's statement that they will still be publishing, albeit it only on the web. I'm sad to see them go, and I'll remain proud of having written a couple of articles for them in years past.
In his final editorial, Jason Snell describes how their readers are vanguards, and that the decline of interest in a printed magazine is simply the way the world is turning. Despite being put out of a job by the announcement, Snell even manages to encourage readers to embrace the "monthly digital editions" that are now being offered. The rest of us, though, would simply call it a paywall.
Given this news, I found some delicious irony in one of the articles featured in their final, printed issue. The opening sentence is "There's no stopping change," and writer Chris Barylick continues on to offer this bit of advice to consultants and support professionals assisting their clients:
YouTube is your friend--especially when it comes to instructional videos. If your clients are worried about learning to use a new application, piece of hardware, or operating system version, odds are good that you can point them toward an instructional YouTube video, bookmark the video for easy access, and perhaps save a link to the desktop as well. The instructor in a video is always accessible (and may be feeling more patient than you are in the heat of the moment). Take advantage of these resources.
You know what else is always accessible and patient? The documentation that came with the product. It's also more likely to be correct and well-written. You know, just like Macworld magazine was.
While in many ways Vine represents the worst in the erosion of attention spans and polish, it can also be an effective tool for visual demonstration. For a very interesting set of examples, look at these for Dispatch, a mail program for iPhone.
See also: Short Attention Span Microvideos
Why everything is OK
Andy Hertzfeld, one of the fathers of Macintosh, writes about how "OK" became the universal "go ahead and do this" interface language for modern computers. The reason might surprise you, or at least make you laugh. For a less amusing exercise, search your own work for "click OK" and ask yourself if your readers still need to be told to do that after more than 30 years.
Sadly, the "Huh?" button introduced more than a decade later in Apple Guide failed to catch on.
Not our job to make it easy
Mark Bernstein, writing Intuitive, argues that professional software doesn't always have to always make things intuitive because it makes things possible. It's a short, stimulating perspective by someone who does the real work. (Bernstein is the creator of Tinderbox, the software I've been using for over a dozen years to create this website.)
I generally agree with what Mark is stating, as not every tool should be reduced to the simplest, monkey-proof set of options. Easy and intuitive are fine goals and should almost always be measures of success, but that doesn't mean a product has to be intuitive for every type of user. It's OK for a tool to be written for people who know what they are doing and what they want to accomplish.
Documentation faces a similar challenge that is, perhaps, even more pronounced. It's very common for writers and reviewers to want the instructions written for "the grandmother who just bought her first computer," or the person who, apparently, has no motivation or reason to be using the software in the first place.
How to make a design problem worse with documentation
About a year ago I wrote about my experience using an Energizer flashlight that would automatically turn itself off after a few seconds of use. The short version of the story is that it is caused by a demonstration mode that that is poorly described in the documentation. (Yes, a flashlight with documentation, go figure.)
Well, despite the problems, I really liked the "Light Fusion Technology" that the flashlight used, so I decided to buy another model in the same product line. The new model also had the same, crazy demo feature. But instead of a user guide, this time they affixed a sticker to the unit, apparently hoping to explain the reset procedure.
Unfortunately, the sticker is just as bad, if not worse, than the user manual was. While it is more discoverable for certain, the wording continues to obtusely refer to the problem and solution. So now you have a big, ugly, multi-lingual warning that tells you nothing about why the flashlight will not stay turned on.
By the way, this time I returned the flashlight to Amazon. As noted by other reviewers, the battery door is not affixed very securely, and I was put off by the fact that Energizer--a battery company of course--sells the light without a complete set of batteries. "Batteries Not Included," indeed.
Managing prose as if it were code
Frank Miller, writing Is Managing Content the Same as Managing Code? for CIDM, offers several important points on the pitfalls of writers using version management systems that have been designed for programmers. Yes, it can be done (as many shops will attest), but it's not very efficient or effective. Those who contend that "words are just bits" don't really understand what productive writers need.
Tech writing with heart
James Somers, writing You’re Probably Using the Wrong Dictionary, observes that somewhere along the line our dictionaries were drained of life and nuance. It's a great article and anyone who loves words will enjoy it.
Far be it from me to commit the heresy of suggesting that technical writing should be engaging, but I can't help observing that most software documentation is in a very similar situation.
Walkthroughs are cruft to be scraped away
Sarah Perez, writing Rethinking the Mobile App “Walkthrough” for TechCrunch wonders if introductory UI walkthroughs are going too far. (And in the time since the article was written their usage has only increased.) Perez cogently raises some important questions to consider, including the impression of complexity that's created, the barrier they create for new users, and their overall lack of good (or any) instructional design. My favorite bit is the characterization that they are cruft that the user has to scrape out of the way. My view is that the biggest problem is that they appear at exactly the wrong time in the learning-cycle.
A thousand words in a jiffy
David Smith, author of the RSS tool Feed Wrangler, writes about his methods and workflow for creating animated GIF files to supplement documentation. Although the example given is not very compelling from an instructional viewpoint, the Mac-based writer will find his tips useful
Generate good faked data
Here is yet another method to create faux information for use in screenshots and examples. Faker is a Python-based program that can generate almost anything you'll need, in a variety of formats. Although designed mostly for testing, technical writers will probably find it useful, once the technical challenges have been overcome.
See also: When you need fake user data