A directory of resources inthe field of technical communication.

Documentation

351-374 of 1,526 found. Page 15 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.

 

351.
#21025

Documenting Entertainment Software: The Mixed Challenge of Simplicity and Sophistication   (PDF)

The challenges of documenting entertainment software are in many ways the challenges of all technical communicators. We strive to make the interface intuitive and the documentation interesting and easy-to-read. Although the nature of the world of entertainment may suggest that our task is simple, the breadth of our audience and the depth of our goals makes it more sophisticated than it looks. We must be as imaginative as our users, recognize the emerging dimensions of multimedia, and create with the constraints of low retail costs, small teams, and fast-paced deadlines.

Guthrie, Lynn Frances. STC Proceedings (1995). Articles>Documentation>Software

352.
#28173

Documenting in N Dimensions

It is commonplace to find information through the Web, but the use of the Web for technical communication is still uncommon. What the competition entries made me realize is that in this networked world, the places where we find information are no longer one or two dimensional. Communication is no longer simply about words on a page (or on a screen). Technical information is now accessed through a multidimensional cyberspace.

Albing, Bill. Carolina Communique (2004). Articles>Documentation>Online

353.
#25379

Documenting in N-Dimensional Space

As technical communicators, we are being challenged with how to structure information in a multiple dimensional space made possible with Web technology.

Albing, Bill. KeyContent.org (2005). Articles>Documentation>Information Design

354.
#20310

Documenting ISO 9000   (PDF)

The ISO 9000 series of Quality Standards redefines how business will be conducted into the next century. The series is designed to measure the effectiveness of the Quality System in place, thereby ensuring both customer and company needs are always satisfied. The foundation of a robust Quality System is its documentation: problems in this area represent the largest single cause of registration failures. Quality System documentation also forms the basis upon which the 3rd party registrar builds the audit plan for your company.

Robinson, Ralph E. STC Proceedings (1998). Careers>Documentation>Policies and Procedures>ISO 9000

355.
#15118

Documenting ISO 9001 Compliance   (PDF)

Describes how technical writers can make their documentation comply with ISO 9001, the latest quality management system from the International Organization for Standardization. The article includes a list of suggested readings.

Parr, Kelly A. Intercom (2002). Articles>Documentation>Standards>ISO 9001

356.
#28734

Documenting Networks

Documenting networks is playing less with words, and more with diagrams. It also requires an engineering mind, an ability to think out-of-box, and creative mind. Technical writers can rise to a new scale and expand their skill sets if they are able to document networks.

EDITsphere (2007). Articles>Documentation>Intranets>Graphic Design

357.
#37265

Documenting Open Source Software

I love reading different community perceptions of both FLOSS Manuals, where we write open docs for open software. I’m also lurking on mailing lists and forums where open source projects are figuring out documentation needs for their users. Forgive me if I ramble a bit, but I’ve been thinking about these concepts lately while discussing them with other writers.

Gentle, Anne. Just Write Click (2010). Articles>Documentation>Technical Writing>Open Source

358.
#24215

Documenting Procedures After the Sole Subject Expert Has Left the Organization   (PDF)

A corporation's or nonprofit's life without written procedures is fraught with dangers and pitfalls that can strike without warning and potentially wreak havoc on the organization's ability to function efficiently—or even to function at all—especially when the lone source of how-to information leaves the organization. The task of creating those procedures from scratch from what often amounts to skeleton information and secondhand sources can be tedious and frustrating but well worth the effort if it helps prevent the organization from being caught off guard in the future. When it comes to workplace procedures, it pays to be prepared.

Kessler, Audrey Cielinski. STC Proceedings (1999). Articles>Documentation>Policies and Procedures

359.
#21657

Documenting Schemas   (PDF)

The issue of documenting schemas—or any machine readable language—goes beyond simple additions of comments. Thereal challengeistocreateschemasthat arereadablebothdirectlybylookingat their sourcecodeandbydocumentation extraction tools.

van der Vlist, Eric. O'Reilly and Associates (2001). Articles>Information Design>XML>Documentation

360.
#21504

Documenting the Flow of Rule-Based Programming in Expert Systems   (PDF)

With the spread of new technology, technical communicators face interesting new challenges for solving documentation problems. One area of software development that technical communicators are increasingly becoming involved in is that of rule-based expert systems. Because of their complexity, both the systems and their documentation can be difficult to maintain. Technical communicators can solve some of these maintenance problems by flow-charting only the chaining structure of the rule-base design.

Glover, Kyle S. STC Proceedings (1994). Articles>Documentation>Programming>Workflow

361.
#30781

Documenting While on Patrol   (PDF)   (members only)

While the jobs of Mary Clouse and the rest of the Security and Documentation Unit of the New York State Senate Technology Services department aren't as glamorous as those of the senators themselves, they ensure that the Senate can use its automated systems to conduct its daily business smoothly, efficiently, and securely.

Clouse, Mary. Intercom (2008). Articles>Documentation>Workflow

362.
#27501

Documents Needed for ISO 9000

There are four tiers of documentation recommended for satisfying ISO 9000 requirements. These documents are: the Quality Policy Manual, Procedures, Work Instructions, and Records.

Kurtus, Ron. School for Champions (2005). Articles>Documentation>Workplace>ISO 9000

363.
#31035

Documents That No Project Cannot Be Without

Short deadlines force project teams to quickly design, test, and release the product with little or no design documentation. If these documents are written, they generally are not well-written and are not comprehensive. The fact of the matter is that most project teams do not have enough staff to design the product, let alone write and manage documentation. This situation creates an ideal opportunity for technical writers to assist the project team in more ways than writing a user guide.

Dick, David J. Carolina Communique (2008). Articles>Documentation>Project Management>Collaboration

364.
#27574

Does a Good User Interface Obviate the Need for Documentation?

This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design.

Sprezzatura Systems (2002). Articles>Documentation>User Interface>Software

365.
#37316

Does Online Help Need an Overall Structure?

The way I learned to write documentation was that you started work on a new project by spending a decent amount of time getting to know your subject matter. I don't mean getting to know the software, I mean getting an understanding of the environment in which the software will be used and the reason for its existence - that is: what's the real value of the software to its users and what do they want to achieve by using it?

Christie, Alistair. ITauthor (2010). Articles>Documentation>Information Design>Technical Writing

366.
#36880

Don’t Leave Any Room for Doubt

I’m working on a little style guide for direct and concise technical writing. One pointer is to avoid the use of should or shouldn’t when what you really mean is do or don’t. Saying something like “shouldn’t” makes it sound optional. In other words, shouldn’t leaves a little room for doubt. Don’t, well, doesn’t.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Diction>Technical Writing

367.
#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

368.
#31988

A Dozen Techniques to Improve Your Software Online Help

There are several main reasons why putting your software manual on-line is necessary. It makes your web-site attractive for search engine crawlers and therefore brings you targeted traffic from Google, Yahoo!, MSN, and other search engines. A good online manual presents your product as serious and credible. Moreover, if a user faces difficulty using your software and asks for technical support, you may easily resolve the issue by referring that user to a certain page of your online help. Simply give the page's URL. With just one click the user will see screenshots and explanations which will help them to resolve the issue.

Crane, Dennis. Dr. Explain (2005). Articles>Documentation>Online>Help

369.
#32145

Driving Development

By partly adopting the process suggested by Daniel Brolund we, the technical writing team, can be involved right up front and the documentation can be one of the methods used to validate the software as it is being built.

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

370.
#30268

A Dual Path Approach to Developing Documentation   (PDF)

The document development process is traditionally viewed as a series of steps along a single linear path. Instead, it is useful to view document development as consisting of activities along dual paths: one product-centered and one document-centered. Isolating a product-centered path reveals how much of your time is spent on activities other than writing--for example, learning about the product. It also highlights the ways in which the documentation is dependent on or shaped by the product.

Igel, Victoria E. STC Proceedings (1994). Articles>Documentation>Methods

371.
#24865

Dumbing Down vs. Simplicity

Never assume that describing something in basic, simple, fundamental terms will annoy your audience. Dumbing down is a form of distortion and possibly deception. Simplifying and clarifying are forms of altruistic communication. Find out more about the differences between "dumbing down" and simplifying and clarifying...and how to decide how simple an explanation should be.

Streight, Steven. Blogger.com (2004). Articles>Documentation>Writing>Business Communication

372.
#35419

Dumping the Manual

I honestly can't remember the last time I picked up a user manual, an honest-to-god paper book of technical documentation. Actually that's a lie, it was just last week when i was tidying up. I picked up several user manuals and moved them to a lower shelf on my bookcase. So why do we still maintain a traditional view of how information should be provided?

McLean, Gordon. One Man Writes (2009). Articles>Documentation>Online

373.
#14591

The Duty of Candor in Future Software Documentation

The STC Code for Communicators requires us 'to communicate technical information truthfully...'. Such truthfulness has two related but distinct aspects, honesty and candor. I have never been asked to falsify technical claims in documentation (honesty), but I have occasionally been asked to withhold true claims about software that, if known to users, would surely affect how they interpret or apply that software (candor). The century ahead will increasingly demand user documentation that is candid as well as honest.

Girill, T.R. STC Proceedings (1999). Articles>Documentation

374.
#38412

E-Book Formats

Most technical writers understand online help formats and have worked with at least one over the years. Help file format have evolved from man pages (manual pages in UNIX in the early 1970’s) and HLP files through CHM files and the plethora of HTML-based formats that we have now. E-Book formats are similar in many respects to the common online help formats, but with one crucial difference; they’re designed to work on the small screens of today’s e-readers and tablets.

Soltys, Keith. Techwhirl.com (2011). Articles>Documentation>Standards>eBooks

375.
#30484

Early Involvement: Writing at Product Design Time   (PDF)

Lead writing is a process that moves the information development cycle into the product development cycle. Writers and programmers work together from the beginning to produce both code design and supporting information. This process ensures that information developers can actively participate in design, and programmers can contribute to supporting documentation. Both groups gain an appreciation for each other's perspective, expertise, and skills, producing a more customer-oriented product.

Coppola, Carolyn M. STC Proceedings (1993). Articles>Documentation>Writing>Technical Writing

 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon