Mike spoke from experience. For the past two years he’s worked with a team of writers in a large enterprise software company that embraced Agile software development from the top management team down. (Without proper buy-in and support at the highest levels, it is hard to realize the benefits of this approach.)

Some Basic Principles
An Agile Manifesto lists four fundamental priorities. Favor . . .

There remains value in the functions on the right, but these should never dominate.

Real reality, not the virtual variety, is key. Unlike the all-to-familiar MS Project approach, where 100-page best-laid plans of mice and men soon go stale, Agile requires daily truth-telling sessions in meat space. Each participant stands and briefly addresses three questions: What have you done since yesterday (in an interval known as a “sprint”), what are you doing today , and are you being blocked from what you have to do? A series of sprints comprises a release for the multiple teams, called a scrum (yes, development can be bruising like rugby). In the sport, a scrum restarts the game after a minor infraction — a fair analogy. In development, a Scrum Master ensures that progress is made at each sprint truth-telling session. At the top of the process is the Product Owner — who is closest to the “first customer” and knows precisely what a potential buyer needs, wants, and is willing to pay for. All other features can come after the basic functionality of the product is rock solid. What a concept!

And the benefits?

Agile Documentation
Until someone writes the Agile Documentation page on Wikipedia, here are the principles Mike has arrived at from his experience as a writer involved in the Agile process:

But Wait, There’s More!

This should be enough to get you interested and motivated to learn more about Agile. And what better resource for that than the excellent slides you may have missed if you were not at our meeting. Many who attended will have some thoughtful insights to take back to the workplace.

So dig a bit and see what Agile could do for you!

Topic-based authoring is a technique for writing content as discrete, stand-alone pieces (“topics”) that can be combined and reused in different ways. The topic-based approach has been getting a lot of attention recently because it is an integral part of DITA (the Darwin Information Typing Architecture) and other XML-based solutions. However, topic-based authoring has actually been around for quite some time, and does not require DITA or XML. Using a topic-based approach can improve consistency and usability of information, and can make it easier to reuse topics in different contexts. It can also simplify maintenance, speed up the review process, and facilitate shared authoring.

For additional details and registration:
http://www.stcsacramento.org/Misc_docs/TopicBasedAuthoring.htm

Touchstone 2011-12
Call for Entries

This year’s Touchstone technical communication competition is almost upon us. The deadline for entries is Saturday, October 1, 2011. Entry forms and detailed entry instructions are at www.stc-touchstone.org/Submit.html.

If you have work you’re especially proud of, enter it so your fellow communicators can admire and recognize it.

If you have work that you’re not quite happy with, enter it to receive the advice and counsel of our experienced judges.

This competition is sponsored by the six Northern California chapters of the Society for Technical Communication (STC). We send the top winners to the STC 2012 Summit Awards competition. Winners of that competition will be announced at the STC Summit in Chicago, May 20-23, 2012.

The proceeds from Touchstone support the Kenneth Gordon Scholarship and other local STC activities.

Touchstone 2011-12
Call for Judges

This year’s Touchstone technical communication competition needs experienced technical communicators to serve as judges. Details and application forms are at www.stc-touchstone.org/Volunteer2Judge.html.

The judging for this year’s competition begins on Sunday, October 9, 2011. As usual, we finish before Thanksgiving.

If the balance between judges and entries is as in prior years, you will volunteer approximately forty hours of work over a six-week period, working with one or two judging partners to evaluate six to eight entries.

Judging entails both collaboration and individual effort. Your team generates consensus award recommendations, but each judge provides a separate written evaluation of the strengths and weaknesses of each entry.

Judging is good for your career. You work with other experienced technical communicators on a worthy project, and you have a chance to study some of the best work in your field. It’s also fun.

Judges receive free admission to the awards event in January, and one judge, in a random drawing, will win up to $250 toward a 2012 STC membership.

–

Richard Mateosian
Berkeley, California

The standard is “EPUB,” which Scott prefers to render as “ePub.” It is just another of many eBook formats, such as MOBI, DJVU, PDF, HTML, and TXT, that has evolved through time to meet user needs. ePub specifies the format and structure of the deliverable, much like a CHM, HLP, PDF, or HTML file does, and it requires both an application and a device to render the content for viewing. The underlying format is XHTML and CSS, with all components, such as content, images, and navigation, invoked from a single header file. Digital rights management (DRM) may also be included. The real wonder of it all is that content flows to fit the screen of the device on which it resides (to varying degrees of quality, as we will see later).

The ePub specification is maintained by the International Digital Publishing Forum (IDPF), and ePub 2.0 became an official standard in September 2007. (The original Open eBook standard of 1999 was actually developed for audio files and accessibility.) ePub 2.0.1 is the current stable build, and there is already a 3.0 draft. ePub comprises the following specifications:

Open Publication Structure (OPS): a standard for representing the content of electronic publications

Open Packaging Format (OPF): defines the structure and semantics as well as the mechanism by which OPS components are related

Open Container Format (OCF): (Seriously, Officer! the ePub was closed!) defines the mechanism by which all components of an electronic publication are packaged into a single deliverable (a ZIP archive)

So what are the many advantages, and why care?

The number of dedicated eBook readers is expected to exceed 11 million units by the end of this year, and the ePub format is supported by all readers and applications except the Kindle. A particular advantage of the format, in an age of vanishing trees, is that it is well suited to content that has limited life span — such as those 15-lb. programming manuals that are soooo last week. Rendered by a variety of conversion tools, ePub format works best for linear content, although reference material can use this approach as well.

It’s relatively cheap to provide instant gratification with this format. The user can search, add bookmarks, and annotations, and the content is very portable. But beware the downsides.

Tables more than a couple of columns wide can be disastrous on small screens. Links do not always work. Compliance with the standard varies highly, with no approach fully compliant. Indexes are not supported (although it is possible to create one as a page with links).

And as we noted earlier, renditions vary greatly (and can be truly extraordinary). Scott presented views of three different readers for the same content, and the differences were striking. As you will need tools (hand rendering is possible but not recommended), be sure to test drive a variety of applications to see which does the best job for your target devices. Scott presented an example of a specification document that he had converted, and it was very attractive and usable on both an iPhone and an iPad.

Enough for this overview. Now see the presentation summary that Scott provided and do your own exploration. Then head to the ePub for an ePint and let it all sink in.

You can’t just have a resume anymore; you need hard evidence to back up what is on it:

• Provide proof that you understand your audience, really know your tools, and can organize, write and deliver.
• Have you mastered the three types of software documentation content (procedural, conceptual, reference)?
• Have you mastered the three basic delivery types (linear prose, task-based help, instruction)?
• Have you developed concrete doc plans?
• Have you demonstrated a master of doc organization (TOC, concepts, procedures, reference, glossary, and even the index?)

Well, have you?

So what sells in the current market?

• Clean, friendly prose with the end user clearly in mind
• Illustrations, useful screen shots
• Code examples
• Complete instructions
• Use cases and implementation scenarios
• Troubleshooting

The audiences for each of the above are different, but the aspiring applicant who can demonstrate mastery of most of the above stands the best chance of success.

And when you are on the spot in front of your prospective employer, what wins?

• An effective presentation, with information that is accessible, relevant, and in a meaningful context: what were the conditions, constraints, and strengths and weaknesses (yes, those) in how you succeeded — or not?
• How did you approach similar challenges?
• What did you deliver and why?
• What did you learn?
• How did you succeed in the end?
• What was your role in development?
• What were all the circumstances you encountered and how did you deal with them?
• What would you do differently next time?

In short, be the best narrator you can, and leave nothing to chance.

So how does one deliver success stories these days? Many use the ubiquitous and affordable LinkedIn (which also hosts a “Creative Portfolio Display” section). Or develop a private website in which to hang your best work with a narrative. For the transfer of large files to your prospective employer, use box.net. Or use private directories (password protected, of course) and even (duh) email (for files that are not too large).

But, you say, all my examples are proprietary? Well, if you don’t deliver something, employers will assume you are bluffing if you just say, “Sorry, I have great stuff — just can’t show it.”

Too bad for you.

So how do you deal with the sticky issue of proprietary information? Here are Andrew’s suggestions, in increasing order of difficulty:

• Ask the prospective employer to sign a nondisclosure agreement (NDA). Companies ask others to do that all the time, so don’t be shy. It shows you are a mature negotiator as well as a respector of (eventually their) intellectual property rights.
• Neuter the content. Do search and replace on a variety of key words.
• Redact key sections, as Acrobat Pro allows (Acrobat Standard may do this too). However, even though you can black out words and lines, be sure to lock the file against further edits!
• Ask your ex (or currrent) boss for permission. Your judgment call here.
• Contact your current (or previous) legal department for permission. Your judgment call here.
• Ask for the names, addresses, and SSANs or the reviewing parties. Your judgment call here. (Success stories would be interesting to hear.)

In the absence of success in any of the above, or even if you have no current examples of the types of documents you would like to write, you can always take a public-domain document or public-domain information and rewrite and reorganize it, demonstrating your clear command of information management. Demonstrate your command of a technical subject area, as well as of your understanding of your audience.

Finally, avoid the classic “I am such a quick study, just teach me anything I need to know and I will learn it.” Well, that does not work in the current environment. No employer wants to hire a liability, and your inexperience should not end up their problem. Hiring managers are terrified to make a wrong hiring decision, and will instinctively minimize their risk any way they can.

So demonstrate the following with concrete examples: initiative, motivation, a master of subject matter sufficient for the task, an ability to overcome gaps in information and other challenges.  Most of all, make it crystal clear that you will be a good investment.

It is as simple as that.

For additional information, don’t hesitate to contact Andrew at andrewd@contentrules.com. Your success and his are intertwined.

Joe currently crafts user interfaces for iPhone apps and scripts YouTube videos to support other mobile apps, but he wisely counsels us to remember there is more to our trade than tools and technology. Having been recently in a hurricane in the Caribbean, he  showed examples of old-school journalistic style (on CNN’s website) that presented just the weather information he was curious about and in the correct order and proportion. Keep your key ideas up front, save the details for later, and do not overwrite so that you bury a good message in clutter — just simple, classic journalistic principles.

He cites Jakob Nielsen on good web design (see www.useit.com), and how readers do not approach web pages linearly. Here again, use the inverted pyramid approach from journalism school (you did take some journalism, right?), and lead with the conclusion if you want to be efficient and make your readers happy. Use bullets, meaningful subheads, one basic idea per paragraph, and toss unnecessary words. Some of us, like Dickens, may get paid by the word, but odds are that every unnecessary word is just a burden in your organization, from first draft through ongoing maintenance and costly localization.

Says Joe, “UA will become most effective when we spend twice as much time writing half as many words.”

Anyone wishing to polish up UA skills would do well to consider the Conference for Software User Assistance, to be held March 13 through 16, 2011, in Long Beach, Calif. The conference focuses on “developing the best possible user experience for all types of software applications through well-designed interfaces and helpful and accessible support information.”  In short, “Better UX through Better UA.” For details, see www.writersua.com/conference.

Every year Touchstone, the Northern California Technical Communication Competition, receives many fine entries. We send the best ones to the STC International Summit Awards competitions. We will announce this year’s winners and display their entries throughout the evening.

During the evening we will also recognize and honor competition judges and Berkeley chapter volunteers for their contributions to the chapter and the profession.

Our yearly raffle: Wow, do we have some great items for our raffle this year! Thanks to the generosity and support from these wonderful vendors in our professional community:

* Adobe is providing a copy of Technical Communication Suite 3
* Author-it is providing a full user license to Author-it
* ComponentOne is providing a license for Doc-To-Help Enterprise
* MadCap Software is providing a copy of Flare V6
For menu and registration details, please go to http://www.stc-berkeley.org/MonthlyMeeting/january2011_annual_party/meeting_details.shtml.

Isn’t this a wonderful thing? Yes, it can certainly be, depending on the nature and size of the enterprise and the amount and different types of content required–but it is not for everyone, and you had better choose your approach carefully from the start.

The great value that Scott provided in our online session was in detailing the various options. How much “manual” control to do you need (and have the technical resources to support)? How much built-in support do you need (and have the budget for)? What is the volume of your output and projection for future need, and how many “seats” do you need licenses for? These are just a few of the questions you must ask before heading down the DITA direction, because what looks like a simpler, more affordable approach at first could turn out to be an expensive, painful trap.

For a concise listing of the products, prices, and particulars of a variety of commercial DITA applications, you can’t do much better than review the brief summary of DITA issues that Scott has provided. Read it and be wise.

At our August 2010 meeting, Arlene Miller, author of The Best Little Grammar Book Ever!, came with a short list of grammar questions, and not surprisingly there was a spirited discussion about the answers. Despite what we have learned in school and over the years, there is always room for analyzing the best way to say something — and sometimes for deciding whether to say it at all.

In keeping with the spirit of the evening, Arlene will be monitoring our new Grammar forum. Try this resource when you bump into a language challenge you would like to resolve, or just want to add expertise to the conversation.