#22466
Defining Information Architecture Deliverables
One of the hottest topics these days in Information Architecture circles is documentation. This is probably partly because the IA's role is so ill defined. Our jobs sit perched between engineering and graphic design: go too far in one direction, we're doing the coding, go to far in the other and we are doing the design. Neither role maximizes the architect's key skills; defining the organizational structure and behavior of the web site or application. An IA is most effective when they leave implementation and final graphic design out of the mix. The documents they create to express this have to be crafted with equal skill and diplomacy.
Wodtke, Christina. SitePoint (2001). Articles>Information Design>Documentation
#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
#21657
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
#26733
Enterprise Agility: SOX and Enterprise Information Integration 
The intent of Sarbanes-Oxley (SOX) can be characterized as risk reduction: reduce errors, inhibit fraud, and provide shareholders with transparent equal-access to material knowledge. But implementation is principally procedural controls and documentation, under threat of penalty. The vague parts of SOX are where the real leverage lies: principles of intent, and corporate transparency.
Dove, Rick. Paradigm Shift International (2005). Articles>Knowledge Management>Information Design>Documentation
#19057
Technical communicators have become increasingly interested in how to 'open up' the documentation process - to encourage workers to participate in developing documentation that closely fits their needs. This goal has led technical communicators to engage in usability testing, user-centered design approaches, and, more recently, open source documentation. Although these approaches have all had some success, there are other ways to encourage the participatory citizenship that is implied in these approaches. One way is through an open systems approach in which workers can consensually modify a given system and add their own contributions to the system.
Spinuzzi, Clay. ACM SIGDOC (2002). Articles>Documentation>Information Design>Open Source
#19781
Information Planning for Successful Online Documentation
Creating an information plan should be the first phase of any publication development life cycle, whether hard copy or online. The plan is a tool for reporting the results of your research about your audience, their tasks, the market, and the product. The plan presents the basic organization and content of the publications you intend to build, effectively directing the documentation team to produce a publication with very specific goals in mind.
Stevens, Dawn M. STC Proceedings (1996). Articles>Information Design>Management>Documentation
#28941
Documentation isn't the most fun part of design and IA, but does it have to be the most painful? Samantha Bailey looks at a tool that may help.
Bailey, Samantha. Boxes and Arrows. Articles>Documentation>Information Design
#29444
A Millennial Paradigm for Documentation: the Scroll!
Although some zealots have proposed eliminating printed information entirely in favor of online help systems, Adobe Acrobat files, and even e-books, discarding printed books may prove less effective than simply modernizing them. Scrolls are the logical successors to books.
Hart, Geoffrey J.S. Geoff-Hart.com (2001). Articles>Documentation>Information Design
#30285
Question and Answer Method of Generating Manuals
Several Texas Instruments writing groups are using a new manual publication method that emphasizes more customer interaction early in the manual development process. This emphasis brings project teams and customers together to accurately define their expectations for the documentation. Writers chunk information as they create the manuals, which allows reviewers to look at the small pieces one at a time and to focus only on those chunks containing information pertinent to their particular expertise. This method defines manual parameters early in the process, which simplifies usability testing.
Lang, Darice. STC Proceedings (1994). Articles>Documentation>Information Design
#28185
Structured Authoring and XML: Part One
Implementing structured authoring with XML allows organizations to create better content. The addition of hierarchy and metadata to content improves reuse and content management. These benefits, however, must be weighed against the time and money required to implement a structured authoring approach. The business case is compelling for larger writing organizations; they will be the first to adopt structured authoring. Over time, improvements in available tools will reduce the cost of implementing structured authoring and make it affordable for smaller organizations.
O'Keefe, Sarah S. Carolina Communique (2003). Articles>Documentation>Information Design>XML
#28177
Structured Authoring and XML: Part Three
Not every content-creation group will benefit from structured authoring and XML. Sometimes, the expense of implementation outweighs the benefits realized, especially in smaller groups with less total page count.
O'Keefe, Sarah S. Carolina Communique (2004). Articles>Documentation>Information Design>XML
#28186
Structured Authoring and XML: Part Two
In a structured authoring environment, authors create documents by assembling elements and text in an order permitted by the structure definition document. You might think of structured authoring as being similar to template-based authoring with a strict template. Authors do not assign formatting; the formatting is automatically assigned based on the structure of the document. Formatting may differ for different output media.
O'Keefe, Sarah S. Carolina Communique (2003). Articles>Documentation>Information Design>XML
#30622
Write Once, Use Many: Why and How We Make Product Information Modular
Faced with growing demand from customers for specific courses, addressing only their needs, in very short time-frames, we had to re-examine the way we worked. Patching together one-shot customized coursework was labor-intensive for a non-homogeneous and unsatisfactory result. Each new customer request required repetition of the same amount of effort. With reduced turnaround time and dwindling human resources, a solution had to be found.
McClelland, Patricia J. and Alison Bourdel. STC Proceedings (1993). Articles>Documentation>Information Design>User Centered Design
#21709
XML provides a robust, non-proprietary, and verifiable file format for the storage and transmission of text and data both on and off the Web. XML removes the complexity of SGML, making it easier to define your own document types, and to write programs to handle them.
Bokil, Manoj. STC India (2003). Articles>Documentation>Information Design>XML
#32096
Structured Writing, Structured Documentation: What and Why?
A brief comparison of two often-confused concepts.
West, Mike. MBWest.com (2007). Articles>Documentation>Information Design
#33338
Information Mapping is a proprietary method for the analysis, organisation, and presentation of information. It is based on the needs of the users and their purpose in using the documentation. Information Mapping has three parts: analysis, organisation, presentation.
Unwalla, Mike. TechScribe (2007). Articles>Documentation>Information Design>Standards
#34025
Wurman’s LATCH Model of Information Organization For Technical Documentation
Technical writing has its mechanical aspects that need to be mastered. A good technical writer must know how to use English effectively as well as various software products to produce acceptable technical documents. But I wish technical writing were all about that. The hardest part comes before one even sits down in front of a computer to type the first word. The hardest part in documenting anything is organizing the information in a way that makes sense from the user’s point of view. Otherwise a technical document suddenly looks irrelevant.
Akinci, Ugur. Technical Communication Center (2009). Articles>Information Design>Documentation>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
#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
#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
#35677
What Information Developers Can Learn from Software Developers 
The shift in information development from a narrative to a modular writing style reflects the established shift towards modularization of source code. What can information developers learn from software developers? What are the challenges and benefits of the modular approach?
Higgins, Paul. TC World (2009). Articles>Information Design>Content Management>Documentation
