#34029
How to Create a New Paragraph Style in a FrameMaker Document
Adobe FrameMaker is the information design platform of choice for most professional technical writers and technical communicators across the globe. Like all powerful software applications, FrameMaker also has a lot of features and configuration possibilities. One of those features is the ability to create new paragraph styles. Each paragraph style in FrameMaker is represented by a “Paragraph Tag.” So to create a new formatting style you actually create a “tag.” Here is how you can create a new paragraph style/tag for your FrameMaker (FM) document.
Akinci, Ugur. Technical Communication Center (2008). Articles>Document Design>Style Sheets>Adobe FrameMaker
#34093
User assistance can add value to a product or Web service’s business model by influencing how deeply users adopt new features or services. As more products employ pay-as-you-go models like that of SaaS (Software as a Service), the contribution user assistance makes becomes increasingly more important.
Hughes, Michael A. UXmatters (2009). Articles>Documentation>User Centered Design>Help
#34100
Fluid layouts are an undervalued commodity in web design. They put control of our designs firmly in the hands of our users and their browsing habits. They’ve also utterly failed to seize the imagination of web designers.
Marcotte, Ethan. List Apart, A (2009). Articles>Web Design>Document Design>User Centered Design
#34155
Enhancing Your Written Works by Producing Effective Charts
Producing effective charts is essential to any document that conveys technical, scientific, or financial data. Here are four suggestions to ensure that your charts are effective and enhance rather than detract from your document.
Davidson, Jeff. Carolina Communique (2009). Articles>Document Design>Visual Rhetoric>Charts and Graphs
#34195
The Newest Tool for Technical Communicators: Redux 
Discusses color properties and color systems. Re-examines and supports Jan V. White's advice to technical communicators to use color to increase document usability. Discusses what technical communicators should know about color to work effectively with professional printers.
Mackiewicz, Jo M. Technical Communication Online (2009). Articles>Document Design>Prepress>Color
#34252
Quick Reference Guides: Short and Sweet Documentation
In this article, my colleague and I provide strategies, tips, and approaches we’ve learned in creating quick reference guides for software documentation projects.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>User Centered Design>Technical Writing
#34265
Rather than spend hours coming up with a complex numbering scheme, this might be an excuse to implement something far more straightforward discovered by an extensive readability study at IBM, of which I was a part. My work involved sitting behind a one-way mirror with a stopwatch, watching people take tests that involved, among other things, "how fast can you find Figure 3-4?" We had cameras mounted over the participant's shoulders and could watch them thumb through the documents, and we also monitored eye movements. Then we followed up with a short interview where we got feedback.
Techknowledgecorp (2007). Articles>Document Design>Information Design>Technical Writing
#34294
Writing for Kindle is like writing for print, the Web, and mobile devices combined; optimal usability means optimizing content for each platform's special characteristics.
Nielsen, Jakob. Alertbox (2009). Articles>Document Design>Usability>Online
#34337
Open Source Alternatives To Tech Pubs Tools
Given how hard it is for students (and their programs) to afford the expensive tools in our profession, I thought it might help to pass along these alternatives to commercial products. I think anyone breaking into the field (or a new type of tool) would do very well to train up on these open source tools and create portfolio pieces with them.
STC Austin (2009). Articles>Document Design>Software>Open Source
#34378
User Paradox with Not Reading User Manuals
Users would save time by reading the manual, but instead they try to figure the application out themselves and then get lost/frustrated as they end up spending even more time getting up to speed with the application.
Johnson, Tom H. I'd Rather Be Writing (2007). Articles>Documentation>User Centered Design>Technical Writing
#34385
What Technical Communicators Can Learn from Comics 
Citing the rise of graphic novels, comics, and in particular, Google’s new web browser Chrome, which has a comic-book-style manual, Opsteegh argues that technical communicators can learn a thing or two about conveying information from graphic novelists.
Opsteegh, Michael. Intercom (2009). Articles>Information Design>Technical Writing>Documentation
#34401
The State of Structured Authoring in Technical Communication
In this podcast, Sarah O’Keefe of Scriptorium Publishing explains the results of their recent survey about the state of structured authoring in technical communication. In the survey, they found that 84% of respondents are either thinking of moving to structured authoring, are in the process of moving to structured authoring, have already adopted structured authoring, or are undecided. Only 16% of respondents said they were not moving to structured authoring. She also discusses other survey results, such as the adoption of DITA and mistakes people make in moving to structured authoring.
Johnson, Tom H. and Sarah S. O'Keefe. Tech Writer Voices (2009). Articles>Interviews>Document Design>Podcasts
#34444
Why do product manuals sound formal and stiff-upper-lipped? Why don’t users read manuals? These questions have haunted the precincts of Technical Writing for quite some time now. From what I have seen in Indian writers, I am forced to conclude that English Composition, as we were taught in school, is the culprit.
Kumar, Suman. Indus (2009). Articles>Documentation>User Centered Design>Rhetoric
#34464
Webpage Layout: Right Hand Side Blindness
In several recent websites we have user tested, the site designers have placed important task critical links and information on the right hand side (RHS) of three column page layouts. The user testing was conclusive, users ignore any information presented on the RHS. We think this is a similar effect to the well documented banner blindness. It is essential to ensure that import links or information is not positioned on the RHS as they will surely be ignored.
Frontend Infocentre (2009). Articles>Web Design>Document Design>Usability
#34485
Modular Docs Part 1: Why You Want Modular, Topic-Oriented Documentation
When documents are built from components, and the components can have contextual variations, it becomes possible to construct built-to-order documents "on the fly", in response to user demands, rather than having to pre-create static versions of all possible variations. Once such a system is in place, it becomes possible for users to further customize the results by modifying the list of selected topics, rearranging their order, or even by adding new topics.
Armstrong, Eric. Sun Microsystems (2008). Articles>Documentation>Information Design
#34489
Creating Topics: Where do you Draw the Line?
It's hard to look at a page of text and try to decide where to divide things to create individual topics. That "bottom up" approach is kind of pointless, in fact. There are better ways.
Armstrong, Eric. Sun Microsystems (2008). Articles>Documentation>Information Design>Technical Writing
#34548
A musing on the need to balance documenation that looks good with documentation that has substance.
Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>Document Design>Technical Writing
#34552
Users want to know how to do things, and not be told what a piece of software or hardware can do. And good those users can adapt, can work around any ignorance they have, and when needed fill in any gaps in their knowledge.
Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>Technical Writing>User Centered Design
#34587
How to Avoid Extinction as a Technical Communicator
Although there will always be a need for people to explain technical material non-technical people, Ellis Pratt said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way rather than merely creating it.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Multimedia>User Centered Design
#34606
Designing for a Non-English Audience
Through experience, I've discovered that foreign language typesetting can be very challenging--even when using the right software and platform, or having the help of a very experienced foreign typesetter. Through solving the problems encountered in the process, I also developed a new appreciation for simple, "internationalized" designs that are much easier to "localize" than others. Many problems can be avoided if the graphic designer keeps in mind that the document may be later translated into other languages. Sometimes, an attractive and very professional design in English can be a "nightmare" in other languages.
Bratu, Felicia. STC International TC SIG (2005). Articles>Document Design>Localization>Language
#34613
How To Create A FAQ Page Your Customers Will Love (And Might Even Use) 
What FAQ pages have become are elephant graveyards of non-information, the equivalent of the Miscellaneous file folder, the place where information-we-didn’t-know-where-to-put was dumped. The challenge of creating a FAQ page that customers will find useful has several aspects to it, but can be accomplished with a lot of planning and a little strategic work.
Bailie, Rahel Anne. Content Wrangler, The (2009). Articles>Documentation>User Centered Design>FAQ
#34637
Documentation Usability: A Few Things I’ve Learned from Watching Users
Even though your customers may not read manuals, your tech support team probably does, which means someone is reading the manuals and using them to help others. But if your users find it easier to call someone, wait on hold for an agent, and then ask the agent a question rather than find the answer in the help, maybe your help materials aren’t very usable. Maybe increasing the usability of your company’s documentation could alleviate the need users feel to seek answers from another source.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Usability>User Centered Design
#34638
Changing the Rules of the Game for the Benefit of the User
In this presentation, Joe Sokohl talks about gathering user research prior to designing and implementing your help deliverables.
Sokohl, Joe. I'd Rather Be Writing (2008). Articles>Documentation>Audience Analysis>User Centered Design
#34639
Starting Points with Quick Reference Guides: Gathering Before Designing
Dan Roam explains that drawing pictures can help you solve problems. He says the first rule is to “collect everything possible up front.” After collecting all your information, you then “lay it all out where you can look at it.” By laying out all the information, you can grasp the whole of it, make connections between various parts, see the important sections, and recognize patterns.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Documentation>Information Design>Planning
#34669
Review: Page Layout and Design Tips from Jean-luc Doumont’s Trees, Maps, and Theorems
Given the engineering audience, one can’t hope for too much style and flair in the prose, but it reads like a college textbook, outlining basic principles in a flat way. It is too focused on “clarity, accuracy, correctness, etc.” (p.79) to make for a fun or engaging read.
Johnson, Tom H. I'd Rather Be Writing (2009). Articles>Reviews>Document Design>Visual Rhetoric
