A directory of resources inthe field of technical communication.

Documentation

76-99 of 1,526 found. Page 4 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.

 

76.
#31148

Betriebsanleitungen für Anlagen   (Word)

Der Normenunterausschuss NATG-F des Deutschen Instituts für Normung e.V. ist derzeit damit befasst, Regeln zur Erstellung von Betriebsanleitungen für Anlagen zu erarbeiten.

Doculine (2002). (German) Articles>Documentation>Writing>Technical Writing

77.
#19988

Beyond End-User Documentation: Opportunities for Technical Communicators   (PDF)

A large number of people in the technical communication field create end user documentation; therefore, many people seem to believe that technical writing is synonymous with writing end user documentation. On the contrary, creating end user documentation is only one of many roles that a professional technical communicator can perform. In this paper, we will describe several roles for technical communicators.

Vaughn, Joan E. and Katie Walton. STC Proceedings (1999). Articles>Documentation>TC

78.
#29987

Beyond Software Manuals and On-line Help: Interactive Help

Software user guides have traditionally provided assistance when the user requested help. Context-sensitivity enabled help systems to predict the most appropriate topic to present. For Windows applications, the move from Microsoft WinHelp to the new Microsoft HTML Help format allows user instructions to be presented in the same window as the application. This offers technical authors some extraordinary opportunities to provide intelligent, predictive, interactive help without the user having to request it. In this paper, we will explore one of the first such interactive help systems (for the Archivist e-mail archiving software), and see where the technology is moving.

Self, Tony. HyperWrite (2003). Articles>Documentation>Interaction Design>Help

79.
#27603

Beyond Story Cards: Agile Requirements Collaboration

Discusses the life cycle of Story Cards, what they should be, how to use them and what to watch out for.

Shore, James. JamesShore.com (2006). Articles>Documentation>Agile>Card Sorting

80.
#21575

Bilingual Team Writing: How One Company Is Meeting the Demands of Simultaneous Software and Documentation Release in Multiple Languages   (PDF)

A company decides to release its software and documentation simultaneously in markets with different languages. For the documentation team, the traditional model of 'write and translate' does not work any longer. A bilingual writing team collaborates to produce a handbook in two languages at the same time.

Duffy, Gerald J. STC Proceedings (1994). Articles>Documentation>Localization>Collaboration

81.
#36764

Bindings for Printed Manuals

For practical purposes, a printed document needs to stay flat on a desk. This limits the binding that you can use. The basic options are explained here.

TechScribe (2007). Articles>Documentation>Finishing>Printing

82.
#33695

The Black Art of Estimation

Estimating the amount of time it takes to write documentation is tricky as it relies on many differing, subtle, factors and, for many people working outside of a highly regimented and heavily project managed team, it tends to boil down to a mixture of guesswork and experience. However, it’s not impossible to come up with a more reasoned estimate as long as you don’t mind doing a little planning.

McLean, Gordon. One Man Writes (2009). Careers>Documentation>Technical Writing>Estimating

83.
#38600

The Blame Game of RTFM

It may surprise you to find that the wikipedia entry for RTFM is a actually longer than the Wikipedia entry for technical communication. The RTFM response captures the disconnect between technical writers and end-users. Presumably, technical writers include the information in the help material that users ask about. Yet users often don’t take the time to consult the manual to find the answer. If only the users weren’t so lazy, the writer thinks, and mumbles RTFM in response to their question. On the flip side, the user thinks, if only the manual/application weren’t so crappy, then I wouldn’t need to ask others for the information I need.

Johnson, Tom H. I'd Rather Be Writing (2012). Articles>Documentation>Usability>Technical Writing

84.
#37624

The Blur Test for Assessing Page Design in Technical Documentation

The “blur test” is a technique for testing the design of a user interface (UI) or an image. The idea is to squint, or to blur the image in some other way, so that you see the areas of contrast and how they attract your attention. Perhaps we can use the blur test to analyse the design of a page in our technical documentation too.

Maddox, Sarah. ffeathers (2010). Articles>Documentation>Usability>Assessment

85.
#30778

Bring on Rich Media   (PDF)   (members only)

Technical communicators must adapt to the changing dynamics presented by the addition of rich media in the technical documentation space. Discover some suggestions for how to do so.

Ortega, Dan. Intercom (2008). Articles>Documentation>Multimedia>Flash

86.
#34507

Bringing Help to the Forefront: Strategies to Increase the Usability of Your Software User Assistance and Your Product   (PDF)   (members only)

Makes the case for embedded help as one of the most effective ways to integrate help within an interface. Although it can be difficult, Bleiel illustrates a way to “elegantly implement and map embedded help.”

Bleiel, Nicoletta A. Intercom (2009). Articles>Documentation>Help>Usability

87.
#13567

Brokedown Palace Part 2: Workflows for Fun and Profit

If you're going to toss out your user guides, you'd better have a good user interface and concise supporting materials. Workflows can help you both in the design of the user interface and in the creation of job aids for the people who use your product. A workflow is a compact and effective way to describe the flow of any procedure. How many times have you grumbled about the design of a piece of software or Web site that you've been trying to use? Chances are that no one ever sat down to model it using the workflow technique.

Knowles, Michael. Write Thinking (2002). Articles>Writing>Documentation

88.
#21505

Browse Sequence in Online Help   (PDF)

A browse sequence enables users to navigate through a series of help topics in the sequence established by the help author. Although often omitted from help systems, the browse sequence is useful and will become essential as print documentation diminishes. Effective design options for a browse sequence include multiple segments, rings, branching, and the use of a browse button to take the user to the first topic in the current segment of the browse sequence.

Farkas, David K. and Bruce R. Gibbs. STC Proceedings (1994). Articles>Documentation>Online>Help

89.
#37054

Browse vs. Search in Application Navigation

When I gave my own UIE Virtual Seminar last year on Navigation, I got a question from one of the attendees. He said that it was a requirement at his company that the user be able to get to any screen in the product (and there were 1,000+) with no more than 2 clicks. I enjoyed the challenge of thinking about how I'd do it. At the time, I was imagining a massive Site Map of the application, but now I think that perhaps another way to satisfy that requirement would be to implement the kind of searching that Apple has.

Rivers, Hagan. User interface Engineering (2010). Articles>Documentation>Online>Help

90.
#30230

Build-to-Order Documents with DITA

It is entirely possible to deliver custom, on-demand documentation that is precisely suited to a user's needs. It can be done today, using web-interface strategies and the right document format. This post shows how such a system could be implemented with the DITA format, and shows why it would be an ideal document-delivery system for programmers.

Armstrong, Eric. Sun Microsystems (2007). Articles>Documentation>XML>DITA

91.
#10316

Building a Better ReadMe   (peer-reviewed)   (members only)

Surveys and focus groups show that most software buyers use ReadMe files. Users primarily look to ReadMe files for information on software bugs. They identify the following ways that software manufacturers can improve their ReadMe files: 1) keep them short, 2) include a table of contents, 3) use hypertext, and 4) eliminate the need for ReadMe files. Along with these four improvements, this article discusses other ways to create quality ReadMe files that meet concrete user needs.

Johnson, Mark A. Technical Communication Online (1997). Design>Documentation

92.
#27925

Building a Case for Global E-learning

As globalization of business continues at a rapid pace, employees are increasingly being asked to absorb and learn from materials that are not written in their first language. These materials range from key corporate policies and procedures that all employees must follow to specific training on products, health, safety or compliance. Very often this is training content created in English at the American parent company and distributed to regional and global offices, where in many cases employees are expected to have a “working knowledgeâ€Ω of English as a second or third language. But there are serious problems with this approach that stem directly from poor reading comprehension and also from learners’ misperceptions of the level of language facility they have actually achieved.

McBrien, Kieran. tekom (2005). Articles>Documentation>Localization

93.
#14388

Building a SGML-based Documentation Environment   (PDF)

SGML (Standard Generalized Markup Language) became an ISO-approved standard and was adopted as a Japanese Industrial Standards. Recently, SGML has begun to be used more widely in Japan. We, the Corporate Design Center of Ricoh Company, Ltd., have completed development of the a single SGML module DTD (Document Type Definition), customization of a SGML editor, and the implementation of review system using the world wide web. In addition, we have developed an automatic DTP system based on SGML.

Mimura, Kaori. STC Proceedings (1998). Presentations>Documentation>SGML

94.
#20285

Building Documentation into the Interface   (PDF)

As documentation is more and more built directly into the interface, and as technical communicators move into interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information will be conveyed at any moment. We can build on basic principles of cognitive psychology to help us make these decisions. We start from a question: Why should users be aware of the difference between interface and documentation when all they want is to get something done?

Quesenbery, Whitney. STC Proceedings (1998). Articles>Documentation>User Interface>Help

95.
#26225

Building Documentation into the Interface

As documentation is more and more built directly into the interface, and as technical communicators move into interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information will be conveyed at any moment. We can build on basic principles of cognitive psychology to help us make these decisions. We start from a question: Why should users be aware of the difference between interface and documentation when all they want is to get something done?

Quesenbery, Whitney. STC Orange County (1998). Presentations>Documentation>Usability

96.
#22849

Building Documentation Into the Interface: A Cognitive Theory   (PDF)

As documentation is more and more built directly into the interface, and as technical communicators move into areas of interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information should be conveyed at any moment.

Quesenbery, Whitney. STC Proceedings (1997). Articles>Documentation>User Interface>Cognitive Psychology

98.
#20287

Building the Treasure House: Creating Knowledge Bases on the World-Wide Web   (PDF)

Web knowledge bases offer an excellent platform for delivering technical documentation and customer support information. They also represent an area of great opportunity for technical communicators to expand their skills, satisfy their customers, and create value for their employers or clients. This session explores the components of a web knowledge base and the tasks involved in planning and building one.

Massa, Jack A. STC Proceedings (1998). Articles>Documentation>Online>Web Design

99.
#24972

"By the Way, We Also Want Online Help"   (PDF)

This presentation describes a strategy to meet a last-minute enterprise demand for online help for a software application program. We established design standards for writing online help, developed a process for gaining consensus from the project team on the content of the online help, and wrote the online help. We accomplished this in less than four months-a task that originally seemed impossible.

Davis, Herbert S. and Meryl Natchez. STC Proceedings (1994). Articles>Documentation>Online>Help

100.
#29359

Calculating Documentation Cruft

It's easy to describe documentation cruft, and often easy to identify it once you see it, but it's hard to estimate how 'crufty' a document actually is. Furthermore, it's often hard to convince the creators of a document that 'their baby' isn't as beatiful as they believe it to be.

Ambler, Scott W. Dr. Dobb's (2007). Articles>Documentation>Assessment>Minimalism

 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon