A directory of resources inthe field of technical communication.

Documentation

501-524 of 1,527 found. Page 21 of 62.

About this Site | Advanced Search | Localization | Site Maps
 

« PREVIOUS PAGE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25  NEXT PAGE »

Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.

 

501.
#32975

Gallery of Onscreen Help

A collection of screen captures from online documentation, to permit technical writers and documentation designers to review a variety of visual styles.

Gallery of Onscreen Help. Resources>Documentation>Help>Online

502.
#22904

Genre Ecologies: An Open-System Approach to Understanding and Constructing Documentation   (peer-reviewed)   (members only)

Arguing that current approaches to understanding and constructing computer documentation are based on the flawed assumption that documentation works as a closed system, the authors present an alternative way of thinking about the texts that make computer technologies usable for people. Using two historical case studies, the authors describe how a genre ecologies framework provides new insights into the complex ways that people use texts to make sense of computer technologies. The framework is designed to help researchers and documentors account for contingency, decentralization, and stability in the multiple texts the people use while working with computers. The authors conclude by proposing three heuristic tools to support the work of technical communicators engaged in developing documentation today: exploratory questions, genre ecology diagrams, and organic engineering.

Spinuzzi, Clay and Mark Zachry. Journal of Computer Documentation (2000). Articles>Documentation>Rhetoric

503.
#26197

Get Going With DocBook

A tutorial on writing documentation that will be used in a particular project.

Galassi, Mark. Galassi.org (1998). Articles>Documentation>Standards>DocBook

504.
#38051

Get It as Good As You Can Get It

Most technical writers want their documentation to be perfect. That's a laudable goal. But you'll never achieve it. So, why not make your work as good as you can, and not stress about it not being perfect

Nesbitt, Scott. DMN Communications (2011). Articles>Documentation>Technical Writing>Planning

505.
#35154

Getting Content Into and Out of Wikis

As wikis mature, we’re using them for more complex business cases such as technical documentation, business analysis and project management. It’s becoming more and more interesting, if not essential, for wikis to support the import and export of content to and from other formats. Most wikis allow you to convert their pages at least to PDF and HTML. But what of other formats, and what about tools for getting content into wikis as well as out of them?

Maddox, Sarah. ffeathers (2009). Articles>Content Management>Wikis>Documentation

506.
#32146

Getting FLOSSy: Acrobat Killer Or HAT Replacement?

Some writers truly hate Adobe Acrobat and any tool that can do the job better is worth a shot, particularly if it’s open source and easily navigated. Flossmanuals.net introduces FLOSS which does a lot of the single desktop Acrobat Pro’s job - collaboratively and open source.

Jeter, Charles. Charles Jeter (2008). Articles>Content Management>Documentation>Software

507.
#25444

Getting Started with SGML/XML

This chapter is intended to provide a quick introduction to structured markup (SGML and XML). If you're already familiar with SGML or XML, you only need to skim this chapter. To work with DocBook, you need to understand a few basic concepts of structured editing in general, and DocBook, in particular. That's covered here. You also need some concrete experience with the way a DocBook document is structured.

Walsh, Norman and Leonard Muellner. O'Reilly and Associates (1999). Articles>Documentation>Standards>XML

508.
#27740

Getting Started with the DocBook XML Dialect

Gets you started with DocBook, an SGML/XML dialect that describes the content of technical articles and other documents. David discusses the benefits of using DocBook, and then describes how to plan and modularize a large document conversion project.

Mertz, David. IBM (2000). Articles>Documentation>XML>DocBook

509.
#33726

Getting Tech Writers Involved in FLOSS

I commented that many tech writers aren't interested in doing more tech writing in their spare time, but might be interested if doing so can help them professionally. In particular, folks coming into the field, either out of school or as career changers, need writing samples for their portfolio to show to prospective employers.

Swisher, Janet. Techie Tech Writer Blog, A (2009). Articles>Documentation>Professionalism>Open Source

510.
#31748

Getting to Expert

The gaps in your documentation aren’t there because you haven’t consider a particular level of user; the gaps in your documentation are there because you haven’t considered how one level of user becomes another. How DO you get from Beginner to Expert?

McLean, Gordon. One Man Writes (2008). Articles>Documentation>User Centered Design>Technical Writing

511.
#36091

Getting Users to Read the Documentation

No one reads the documentation. Maybe that's because the manual as we know it is at the end of its usefulness. A key to making documentation more palatable and useful is to make it more like the information that users are finding on the Web. Focus on specific tasks, not features. Task-based documentation, but to the extreme.

Nesbitt, Scott. DMN Communications (2010). Articles>Documentation>TC

512.
#23389

Give Them Printed Documentation, Too!!!

The current trend among technical communicators is a twisted form of minimalism that says the documentation should contain procedural documentation but little or no reference documentation. I believe that this trend is a disservice to our customers and tends to increase technical support costs because customers subjected to this form of documentation have little or no access to the information they need. If it’s not there, they can't find it.

Starr, Mike. TC-FORUM (2002). Articles>Documentation>User Centered Design

513.
#33606

Giving the Instructions a Fair Shot

We as technical communicators ought to afford each other the courtesy of using each other’s materials when the need arises. As the writers, we know how valuable it can be, and if we don’t use it when the need arises, we’re contributing to the prevalent concept that “no one reads it anyway.” By doing so, we shoot our own profession in the foot.

Gryphon Mountain (2008). Articles>Documentation>Technical Writing

514.
#33331

Glossaries Aid Clarity

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

515.
#23963

GNOME Documentation Style Guide

The GNOME Documentation Style Guide provides guidelines for authors who want to contribute to the GNOME Documentation Project.

GNOME (2004). Reference>Style Guides>Documentation>Linux

516.
#34116

GNOME Handbook of Writing Software Documentation

The GNOME Documentation Project (GDP) aims to provide GNOME and GNOME applications with a complete, intuitive, and clear documentation system. At the center of the GDP is Yelp, which presents a unified interface to GNOME-specific documentation as well as other Linux documentation such as man pages and texinfo documents. The GNOME Help System provides a comprehensive view of documentation on a machine by dynamically assembling the documentation of GNOME applications and components which are installed.

Mason, David, Daniel Mueth, Alexander Kirillov, Eric Baudais, Eugene O'Connor and John Fleck. GNOME (2003). Books>Documentation>Software>Technical Writing

517.
#24694

Goal-Oriented Paper Versus Online Documentation Search Strategies   (PDF)

In this age of information, advanced technology gives us access to more than ever imagined. Are people easily moving toward gathering information online instead of from paper? This study investigated novice and expert user access of paper versus online documentation.

Anson, Patricia H. and Robert Anson. STC Proceedings (1996). Articles>Documentation>Online

518.
#37109

Going a Bit Too Minimal

Aaron and I advocate minimalism in documentation. Our definition of minimalism differs slightly from how some people may define the term, and we take some heat for it. But no matter how you define it, the aim of minimalist doucmentation is always the same. To give user the information they need in the most concise, readable, and accessible way.

Nesbitt, Scott. Communications from DMN (2010). Articles>Documentation>Technical Writing>Minimalism

519.
#33321

Going from Word to Wiki

One writer's experiences and thoughts about moving content from Microsoft Word to a wiki.

DMN Communications (2008). Articles>Documentation>Wikis>Case Studies

520.
#19485

Going Global Without Going Broke   (PDF)

Companies are increasingly operating world wide. As a result they often need to produce documentation in several languages to meet market demands. The quality of the source document plays an important part in controlling the cost and release date of the localised documents. This article discusses several issues that need to be considered when producing documents for the multilingual marketplace.

O'Neill, Jennifer. STC Proceedings (2001). Articles>Documentation>International

521.
#19831

Going Online: Selecting the Right Tool   (PDF)

There are numerous tools that you can use to create online documentation. However, each tool has its strengths and weaknesses, and each is more appropriate for some types of information than others. This workshop explores many issues of online documentation tools: Why go beyond Windows Help? Which is better: HTML or Adobe Acrobat? What tools support cross-platform presentation? When should you use Workgroup tools such as Lotus Notes or Folio? When does SGML make sense? How to utilize a!ocument databases? When to use Management tools? Real examples developed using these tools will be given throughout the session. Participants will leave with a clear understanding of the pros and cons of each.

Rockley, Ann. STC Proceedings (1997). Articles>Documentation>Software>Help

522.
#36090

Going Paperless

We've been hearing about the paperless office since (at least) the 1990s. Then, people predicted that within 10 years every office would be paperless. That prediction was way off. And going paperless with documentation can be a challenge.

Nesbitt, Scott. DMN Communications. Articles>Documentation>Planning>Online

523.
#19925

Going Paperless — No Longer a Revolutionary Idea   (PDF)

Moving user documentation from paper to online requires long–term planning and hard work. You must rethink how you design documents and determine the best way to present information online. You can take steps to downsize the existing documentation workload. You may even change the way you work with the software development staff. As a result, you will probably produce better documents, start working a lot smarter and save the company a lot of money.

Mulreany, Sharon R. and Risa Glick. STC Proceedings (1996). Articles>Documentation>Online

524.
#34340

“Good Enough” Really Isn’t

I’m enough of a perfectionist that I mentally wince every time I find myself thinking, “It’s good enough.” It sounds like a cop-out. It sounds like avoidance of responsibility and ownership. It sounds like I’m indifferent.

Gryphon Mountain (2009). Articles>Documentation>Quality>Technical Writing

525.
#37554

Good Help is Hard to Find

Help content gets no respect. For one thing, it is content, and our horse-before-cart industry is only now beginning to seriously tackle content strategy. For another, we assume that our site is so usable, nobody will ever need the help content anyway. Typically, no one is in charge of the help content and no strategy exists to keep it up to date. On most sites, help content is hard to find, poorly written, blames the user, and turns a mildly frustrating experience into a lousy one. It's time to rethink how we approach this part of our site. Done well, help content offers tremendous potential to earn customer loyalty. By learning to plan for and create useful help content, we can turn frustrated users into our company's biggest fans.

Mullican, Lyle. List Apart, A (2010). Articles>Documentation>Technical Writing

 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon