#32774
Should Technical Authors Embrace User-Generated Content?
It may seem counter-intuitive, but we believe technical authors shouldn't fear the trend towards user generated content.
#32776
Placing Value on User Assistance
User assistance writers are often the Rodney Dangerfields of the UX world, bemoaning the fact that we don’t get any respect. I think the real problem is that user assistance folks are not particularly good at communicating the ways in which we add value to an enterprise. This column explores two models that show how user assistance adds value and how we can communicate that value to those who pay our salaries—something I would like to encourage other user assistance writers to do.
Hughes, Michael A. UXmatters (2008). Articles>Documentation>Technical Writing>Help
#32816
Learn about theoretical and practical examples of merging DITA (Darwin Information Typing Architecture), a structured authoring methodology, and wiki’s freeform authoring and editing capabilities.
Gentle, Anne and Lisa Dyer. Intercom (2008). Articles>Documentation>Technical Writing>Wikis
#32817
The "Quick Web" for Technical Documentation 
So how did the wiki become a seemingly permanent fixture in the landscape of today’s Web? Which wikis have succeeded as technical documentation, and how can we replicate their success?
Gentle, Anne. Intercom (2007). Articles>Documentation>Technical Writing>Wikis
#32822
Are you getting hung up with the XML and all of the other Content Management goodies and forgetting about the CONTENT?
Great Technical Writing (2008). Articles>Writing>Technical Writing>Content Management
#32823
Don't Let Your Product's Features Become Expensive Flaws
Your product's unexplained features can turn into costly flaws. This article describes three real-world products with just such "features." It presents ways you can prevent these feature-to-flaw conversions by improving the User Documentation for your products.
Great Technical Writing (2008). Articles>Documentation>Usability>Technical Writing
#32824
Before you release a product, have some people use it. From these "test users" get solutions to problems, tips and knowledge that would help your real-life Users. Put that information in your User Documentation, and on your product support website.
Great Technical Writing (2008). Articles>Documentation>Technical Writing>User Centered Design
#32895
What is Web 2.0 and How Will Technical Writers be Impacted?
Understanding the potential implications of a paradigm shift in how we view writing for the web. For content to reach the types of syndication and distribution imagined by web 2.0 enthusists, content needs to break free of the containers that both bind it and display it. One of the most significant ways that this transition to Web 2.0 can be seen is in the move toward XML, and semantic markup. With this move toward the granulation of content however technical writers need to rethink how to present content.
Diehl, Amy. Content Matters (2006). Articles>Web Design>Writing>Technical Writing
#33157
How a Teacher Reminded Me Why I’m a Writer
I enjoy creating content. I like to take words and arrange them to convey ideas, paint pictures, spur thought, and give guidance. I like thinking about what arrangement of the words will bring the best impact. I write not necessarily because the world turns on ideas or because information is a buyable product, but because words have a lasting effect on people.
Gryphon Mountain (2008). Articles>Writing>Education>Technical Writing
#33291
There's the Tribe, Where's the Technical Author?
Connecting people and giving them a place in the world IS (what makes you a living). I immediately thought, this affects technical authors. They connect people to information, rather than people. They help people find their place. They play a role in building and maintaining an organisation's tribe. They show there's more to the supplier-customer relationship than the moment of the sale.
Cherryleaf (2008). Articles>Writing>Technical Writing>Rhetoric
#33303
'Read Rage' Over Instruction Books
"Read rage" is sweeping the UK - as consumers become fed up with the often incomprehensible language used in many of the instruction manuals produced by manufacturers.
Channel 4 (2008). Articles>Documentation>Technical Writing>United Kingdom
#33319
Writing Technology Case Studies
One area in which a good, knowlegeable, and flexible technical writer can really make a difference is writing case studies. This blog post looks at what a case study is, and the elements that make up a good case study.
DMN Communications (2008). Articles>Writing>Technical Writing>Case Studies
#33322
Lessons in Introductions from O'Reilly
Book published by O'Reilly Media have a good flow to the information and they're well structured. One of the best features of many of those books is the introductory material. It can be a good guide, and help readers zero in on what they want to learn.
DMN Communications (2008). Articles>Writing>Information Design>Technical Writing
#33329
According to Plain English Campaign (www.plainenglish.co.uk), plain English is "… something that the intended audience can read, understand and act upon the first time they read it. Plain English takes into account design and layout as well as language." Many organisations have found that plain English brings commercial advantages.
Unwalla, Mike. TechScribe (2008). Articles>Writing>Technical Writing>Minimalism
#33330
There are some fundamentals tenets of our profession that are widely accepted. One being that you always need to know your audience before y can begin to understand their needs and so produce the information that they require.
McLean, Gordon. One Man Writes (2008). Articles>Writing>Technical Writing
#33331
A glossary is an alphabetically arranged list of terms, with a definition or an explanation of each term. A term can be a single word or many words. Typically, in a printed document, the glossary is at the end of the document. Usually, in online help, each term in a topic, or the first instance of a term, has a popup that explains the term.
Unwalla, Mike. TechScribe (2007). Articles>Documentation>Technical Writing>Glossary
#33332
Copywriting and Technical Writing Compared
Technical writers (technical authors) produce technical literature such as standard operating procedures (SOP), user guides, reference manuals and white papers. Copywriters produce advertising copy and publicity copy (also known as marketing communications or marcomms). Typically, that means product brochures, poster advertisements, advertorials, leaflets, and mailshots.
Unwalla, Mike. TechScribe (2007). Articles>Writing>Technical Writing>Marketing
#33334
Writing for an International Audience
Ideally, software and its documentation is localised (translated) into the languages of the target markets. However, in many cases, it is not cost-effective do this. Even if the target markets are the English-speaking countries, differences exist between the way English is used in the US, the UK, and Australia for example, and it is easy to cause confusion. This article examines some issues.
TechScribe (2007). Articles>Documentation>Technical Writing>Localization
#33337
FAQs don’t have that great a reputation, but recently, I’ve been working on FAQs for a client. Their computer help desk was annoyed about answering the same things again and again. Why not divert potential callers to a FAQ instead?
Jarrett, Caroline. Usability News (2007). Articles>Documentation>Technical Writing>FAQ
#33370
Normally I like to write positive stuff and I really love Uxmatters.. it’s a great site. BUT, the recent article PDF Manuals: The Wrong Paradigm for an Online Experience from my perspective is pretty much everything that’s wrong with Help today.
Lang, Keith. UI and Us (2008). Articles>Documentation>Writing>Technical Writing
#33372
I am ill equipped to write for an emerging segment of the marketplace. But that doesn't mean I'm used up like a worn-out number two pencil stub (my favorite simile these days). But it does mean that I need to reevaluate where and how I add value.
Hughes, Michael A. User Assistance (2008). Articles>Documentation>Technical Writing>Multimedia
#33378
The LabVIEW Documentation team consists of some of the most detail-oriented people you will ever meet. We debate using "attend" vs. "participate in". We agonize over "both" vs. "either". We spend half an hour brainstorming the placement of a level 2 heading and worry over its effects on the help file table of contents.
Blogspot (2008). Articles>Writing>Technical Writing
#33379
To a non-practitioner, the art of technical writing is a nebulous pursuit to be avoided at all costs. The territory is ripe with jargon and Rube Goldberg devices that are not to be trusted. Besides, who in their right mind would want to be a "Technical Writer" (whatever that is)? But to the artisan, technology and language are the subject and medium in which we create our masterworks.
HelpScribe (2008). Articles>Writing>Technical Writing
#33392
It's not a question of knowing. It’s more a question of feeling, when you read it, that the material was written at a company where professionalism governs everything. If you see writing that looks professional, then you believe that the coding — which you can’t see — is also professional.
Levinson, Mark L. Elephant (2008). Articles>Writing>Technical Writing
#33422
An average internet-banking user of this bank would be an Indian whose primary language, either at school or at home, was not and is not English. Such a person would not even notice the errors I’ve marked. Such a person would find the text totally comprehensible, unambiguous, and useful - though a tad incomplete because it answers only about four questions and doesn’t even address the how-to of the options provided by the internet-banking facility.
Info Developer (2008). Articles>Usability>Technical Writing>India
