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.

See also: A Look at Developing User Assistance for Mobile Apps

Posted: November 24, 2014 link to this item, Tweet this item, respond to this item

Simplifying Armageddon

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?!

Posted: October 19, 2014 link to this item, Tweet this item, respond to this item

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.

Posted: October 12, 2014 link to this item, Tweet this item, respond to this item

Tiny tutorials

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

Posted: September 13, 2014 link to this item, Tweet this item, respond to this item

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.

Posted: August 23, 2014 link to this item, Tweet this item, respond to this item

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.

See also: The Lowest-Common Denominator Problem, Unintended Consequences of Good Documentation, and The Forgotten, Yet Passionate, Middle

Posted: July 20, 2014 link to this item, Tweet this item, respond to this item

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.

Posted: June 15, 2014 link to this item, Tweet this item, respond to this item

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.

Posted: June 11, 2014 link to this item, Tweet this item, respond to this item

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.

Posted: May 30, 2014 link to this item, Tweet this item, respond to this item

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.

Posted: May 20, 2014 link to this item, Tweet this item, respond to this item

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

Posted: May 4, 2014 link to this item, Tweet this item, respond to this item

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

Posted: April 20, 2014 link to this item, Tweet this item, respond to this item