http://tc.eserver.org/publisher/DMN_Communications A listing of works published by DMN Communications in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/DMN_Communications http://tc.eserver.org/35843.html http://tc.eserver.org/35843.html Technical communicators tend to get caught up in tools and techniques and formats. But, as Scott Abel said, It’s not about tech writing. It’s about content. http://tc.eserver.org/35825.html http://tc.eserver.org/35825.html While style guidelines can be useful for maintaining consistency across a set (or several sets) of documentation, the editors that I worked with viewed the style guidelines as sacrosanct. Any deviation, no matter how small, was punishable by a nasty email and a sharply worded note to the offending writer’s manager. http://tc.eserver.org/35787.html http://tc.eserver.org/35787.html Structure is a key component to anything that you write. In this blog post, Scott Nesbitt discusses the importance of structure in the context of using the LaTeX typesetting language. http://tc.eserver.org/35788.html http://tc.eserver.org/35788.html Sometimes, you don’t need documentation made up of perfectly-chosen words and phrases. Instead, you need something that can be easily scanned, easily understood, and easily digested. Documentation that distills the main points quickly. http://tc.eserver.org/35528.html http://tc.eserver.org/35528.html In a case like this, you don’t need documentation made up of perfectly-chosen words and phrases. Instead, you need something that can be easily scanned, easily understood, and easily digested. Documentation that distills the main points quickly. Far more quickly than even the kind of minimalist documentation that I encourage can. http://tc.eserver.org/35510.html http://tc.eserver.org/35510.html Radio and documentation. It sounds like a strange, if not incompatible, mix. But as Scott Nesbitt explains, an ideal model for writing documentation is a good radio report. http://tc.eserver.org/35407.html http://tc.eserver.org/35407.html While I'm a firm believer in the primacy of content over appearance, aesthetics are definitely a part of drawing people into documentation and engaging them. There's nothing wrong with making online assistance or a printed manual attractive. It doesn't need to be a beautifully-designed work of art, but it should be something a little more than blocks of black text on a white page. http://tc.eserver.org/35378.html http://tc.eserver.org/35378.html Power user. It’s a term that I don’t like. But there definitely are people out there who are working with the software and hardware that we document who want more than just basic information. Getting them that information can be tricky. http://tc.eserver.org/35285.html http://tc.eserver.org/35285.html When the subjects of usability and user friendliness in relation to documentation are broached, writing isn’t often the first thing that comes to mind. But it should be. http://tc.eserver.org/35265.html http://tc.eserver.org/35265.html I recently switched from RoboHelp 7 to Flare 5. I’m not the person to ask about the merits of one over the other because I don’t have enough experience with Flare yet. Because I’m coming to version 5 with my knowledge being only that which my colleagues have told or shown me, I hope to make life easier for anyone moving from RH to Flare or at least trying Flare out. http://tc.eserver.org/35125.html http://tc.eserver.org/35125.html I’m advocating boiling the documentation down to the essentials. Remove any superfluous material. Tell the user how to do things with a piece of software or a gadget, not what that something can do. You might wind up with documentation that’s just a set of procedures connected together by linking material and cross references. Don’t bog them down with what’s not necessary for them to get things done in a fast and efficient way. http://tc.eserver.org/35124.html http://tc.eserver.org/35124.html In this post, technical writer Milan Davidovic that contributing to wikis can help novices build skills and a portfolio. And he offers a simple roadmap for doing that effectively. http://tc.eserver.org/35108.html http://tc.eserver.org/35108.html The notes for a presentation (titled Thinking Outside the Book: Wikis for Writing and Delivering Documentation, that discusses the whys, the tools, and the techniques of using wikis for documentation. http://tc.eserver.org/35091.html http://tc.eserver.org/35091.html How exciting is technical writing, really?” Every once in a while, discussions in blogs or at conferences turn to that question. How technical writing is not really a calling or maybe even boring. Technical writing is my creative passion. I don’t have a recipe, but I want to share my excitement. Maybe it resonates with you, and maybe you’ll see technical writing in a different way. http://tc.eserver.org/35083.html http://tc.eserver.org/35083.html Technical communication is changing rapidly. If you’re not ready for that change, it’s going to really catch you off guard. Anne Gentle's book Conversation and Community is an excellent guide to rolling with those changes, and for staying ahead of them. This article takes a close look at the book. http://tc.eserver.org/35015.html http://tc.eserver.org/35015.html There's a shift happening in the way in which documentation is produced. We’ve all seen the beginning of it: the growing volume of what’s called (among other things) user generated or crowdsourced documentation. That trend is growing. And while a number of people in our profession are still resistant to the idea, it’s only a matter of time before users are our main partners in creating documentation. http://tc.eserver.org/34976.html http://tc.eserver.org/34976.html Skills. For the technical communicator, skills should go beyond the tools and techniques of the trade. This blog post looks at four skills that will be of use to any technical communicator. http://tc.eserver.org/34913.html http://tc.eserver.org/34913.html How do you get fresh blog content even if you want a break, say a summer off of the routine of writing two posts a week? In this guest post, Anne Gentle discusses just that. The short answer? By tapping into your community or writing ahead. http://tc.eserver.org/34803.html http://tc.eserver.org/34803.html Usability and compatibility testing is a must. If you’re developing a Web application, test it with not only the major desktop browsers but with the popular mobile browsers as well. If your application isn’t friendly to mobile devices, say so up front when someone visits that application using a mobile browser. It will prevent a lot of frustration on the part of users. http://tc.eserver.org/34770.html http://tc.eserver.org/34770.html Unstoppability. What does that mean to you? To Tom Johnson, it's about leading a life with passion and engagement. In this guest blog post, Tom talks about unstoppability and how it applies to technical communication. http://tc.eserver.org/34707.html http://tc.eserver.org/34707.html Social networking and social media have been touted as giving us a never-before possible opportunity to connect with and influence and work with others. The board might be new, but the game is essentially the same. http://tc.eserver.org/34706.html http://tc.eserver.org/34706.html Documentation for consumer products gets a bad rap. Often, it's deserved. But you can't paint all documentation with the same brush. This post looks at the good and the bad in consumer documentation, and at the elements which can make that documentation good. http://tc.eserver.org/34704.html http://tc.eserver.org/34704.html There are obvious benefits to single sourcing, the ones that roll off the tongue the minute single source is mentioned: multi-format publishing, consistency of information, quicker updates of common content, lowering translation costs and so on. But beyond all those, what else is there? In this guest blog post, Gordon McLean discusses just that. http://tc.eserver.org/34650.html http://tc.eserver.org/34650.html Technical writers are Jills and Jacks of all trades. But what really makes a tech writer tick? In this guest post, Sarah Maddox explores that question and comes up with some interesting answers. http://tc.eserver.org/34631.html http://tc.eserver.org/34631.html Video has the potential for enhancing documentation. But is video the be all, end all? Is it really the next stage in the evolution of documentation? Will it supplant text and static images? This post looks at the pros and cons. http://tc.eserver.org/34586.html http://tc.eserver.org/34586.html Finding information in documentation is easy. Or is it? This blog post argues that there's no universal solution, and that each document and each delivery method offers challenges and requires a slightly different solution. http://tc.eserver.org/34543.html http://tc.eserver.org/34543.html The Twitter Book was created as being a different approach to publishing. But it’s also a different approach to writing. And that approach has definite applications in technical communication. http://tc.eserver.org/34544.html http://tc.eserver.org/34544.html When you think of the crowd, you probably think about a specific mass of people who use the software and hardware that we document every day. The interesting thing about the crowd is that it doesn’t necessarily mean people outside of the enterprise in which you’re working. There are people in your enterprise who can do a lot to help you with the documentation, too. Developer, product managers, QA analysts. They all have knowledge that you can and should tap. http://tc.eserver.org/34545.html http://tc.eserver.org/34545.html Do we need to have an external help system? Why not embed help right into the application? Why not take this a step or two further? Instead of having a separate help system, integrate more useful, more robust, and context-sensitive help into the user interface. http://tc.eserver.org/34546.html http://tc.eserver.org/34546.html While the perfect mobile user interface is beast that doesn't exist, there are good interfaces that work around any issues there are with the displays on mobile devices. http://tc.eserver.org/34547.html http://tc.eserver.org/34547.html It's easy enough to fall into the trap of identifying yourself with what you do for a living. This blog post looks at why you shouldn't do that. http://tc.eserver.org/34548.html http://tc.eserver.org/34548.html A musing on the need to balance documenation that looks good with documentation that has substance. http://tc.eserver.org/34549.html http://tc.eserver.org/34549.html A question that technical communicators frequently ask about wikis is "How do I get the documentation out of a wiki?" A simple answer: "Don’t worry about it." Because the wiki is the delivery method. http://tc.eserver.org/34519.html http://tc.eserver.org/34519.html There was a time when organizations did offer a value proposition. Once upon a time, there was some prestige attached to being part of a professional organization. Being a member marked you as a professional. The potential was there for membership in an organization to open a more than a few doors. And organizations offered training, courses, information, and even pointers to jobs that you couldn’t find anywhere else. The Web, though, hasn’t just leveled the playing field. The Web has flattened the playing field, paved it over, and moved the goal posts. http://tc.eserver.org/34520.html http://tc.eserver.org/34520.html Most questions have been asked before. This isn’t a profound statement; most of us would consider it obvious. Just ask anyone on your Product Support team. Chances are the majority of calls they receive are fielded with canned answers. Why? Because we all seem to ask the same questions. By providing answers to those questions, you can help the majority of your users get back on track quickly. http://tc.eserver.org/34513.html http://tc.eserver.org/34513.html You can definitely apply some of the concepts of microblogging to crafting error messages. Like a good tweet or a http://www.identi.ca or a jaiku, a good error message must: be concise; contain useful information, for both the person reading it and technical support; and be easy to read and understand. http://tc.eserver.org/34063.html http://tc.eserver.org/34063.html Online help. User assistance. That thing that pops up when you press F1. No matter what you call it, user assistance is an important element in the experience of a user. It can mean the difference between a frustrated user and a productive one. But is today's user assistance all it can be? Are we giving users purposeful information at the right time, in the most effective format, and ultimately in the way that they need it? Unfortunately, no. http://tc.eserver.org/34064.html http://tc.eserver.org/34064.html A short blog post that discusses why users are more interested in learning how to, and not what is. http://tc.eserver.org/34065.html http://tc.eserver.org/34065.html Does a truly intuitive user interface exist? The author of this blog post doesn't think so. To create one, designers and developers really need to put the wrecking ball to the UI as it is now. http://tc.eserver.org/34066.html http://tc.eserver.org/34066.html Is taking on a side project or three actually worth the time and money? It depends. http://tc.eserver.org/34069.html http://tc.eserver.org/34069.html Is it possible for a technical writer to switch niches and write something different? Here's an example of one person who's done just that. http://tc.eserver.org/34070.html http://tc.eserver.org/34070.html While the concepts of structured authoring are more than just slightly useful for technical writing, they can be beneficial for just about any writing task within an organization. But how do you bring XML-based structured authoring to the masses? Perhaps by taking a cue from a word processor called Yeah Write. http://tc.eserver.org/33875.html http://tc.eserver.org/33875.html If we don’t learn, we wither. New trends, new tools and technologies, new techniques. Even just new skills for the job. Continuous education is a key to longevity in the world of technical communication. As a freelancer, though, getting educated can be a bit of a problem. While many full-time employees have access to at least some job-specific training paid for by their employers, freelancers must shoulder the costs themselves. And training isn’t always cheap. So, how do freelancers stay current and stay sharp? Here are a few suggestions. http://tc.eserver.org/33876.html http://tc.eserver.org/33876.html I'm definitely not the greatest presenter around. While I like to think I’m improving in this area, there are still holes in my game. Still, I was somewhat flattered. And it kind of fed my then-depleted ego to be asked this question, and the others that surrounded it. What follows are the points that I tried to get across. http://tc.eserver.org/33810.html http://tc.eserver.org/33810.html So, you’re seriously considering making the jump into the world of freelance technical writing. It’s a big step, and one there’s a lot more to it than just giving up your day job and hanging out a shingle. This post details a number of things that are important to consider before making the jump. http://tc.eserver.org/33811.html http://tc.eserver.org/33811.html The second part of a series on making the move to freelance technical writing. This installment discusses how to gigs and get paid. http://tc.eserver.org/33812.html http://tc.eserver.org/33812.html So, you’ve hung out your virtual shingle and even have a couple of contract gigs under your belt. You’ve decided that the freelance life is for you. Now what? Obviously, expand your business to gain more and varied clients. The way to do that is by marketing. http://tc.eserver.org/33696.html http://tc.eserver.org/33696.html There’s a lot of tool fetishism in the documentation world. We all succumb to it in one way or another — I used to think it was FrameMaker or DocBook, or nothing. Ah, the folly of youth. But that attitude severely limits you as a professional. For a consultant or freelancer, it’s only a few steps away from suicide. http://tc.eserver.org/33673.html http://tc.eserver.org/33673.html Structured authoring isn't just for technical writers. Just about any department in an organization can benefit from it. This article looks at one way of bringing structured authoring to the masses: by adopting the authoring concepts used in an obscure word processor called Yeah Write. http://tc.eserver.org/33495.html http://tc.eserver.org/33495.html With few exceptions, intuitive user interfaces really don't exist. Familiar interfaces do, however. But does that mean developers need to be locked into the same old design patterns? There's no reason why they should. http://tc.eserver.org/33475.html http://tc.eserver.org/33475.html As some in our profession have come to realize, social media and use of the Web in general have changed (and are still changing) the way in which people access and use information. http://tc.eserver.org/33319.html http://tc.eserver.org/33319.html 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. http://tc.eserver.org/33320.html http://tc.eserver.org/33320.html Some thoughts on what it takes to effectively mentor another technical communicator. http://tc.eserver.org/33321.html http://tc.eserver.org/33321.html One writer's experiences and thoughts about moving content from Microsoft Word to a wiki. http://tc.eserver.org/33322.html http://tc.eserver.org/33322.html 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. http://tc.eserver.org/33328.html http://tc.eserver.org/33328.html I’ll discuss how Aaron and I get ready to give a presentation, how we actually deliver one, and what happens afterwards. http://tc.eserver.org/33341.html http://tc.eserver.org/33341.html A look at how two technical communicators plan and prepare presentations. http://tc.eserver.org/33313.html http://tc.eserver.org/33313.html A conversation between Scott Nesbitt of DMN Communications and Adam Hyde, who runs FLOSS Manuals. In a wide-ranging conversation, they talk about why Adam started the project, the way in which FLOSS Manuals gets things done, Book Sprints, Adam’s thoughts on the 80/20 rule, and more. http://tc.eserver.org/33169.html http://tc.eserver.org/33169.html Thinking of a career in technical communication? This article offers one point of view on what you need to know to be successful in the field. http://tc.eserver.org/32783.html http://tc.eserver.org/32783.html The detailed notes for the presentation on creating quality content with Open Source tools that was given at DocTrain East 2008 (Oct. 31, 2008). http://tc.eserver.org/32784.html http://tc.eserver.org/32784.html A chat with technical communicator and blogger Anne Gentle in which we discuss wikis, DITA, the XO Laptop, documenting Open Source software, and a lot more. http://tc.eserver.org/31882.html http://tc.eserver.org/31882.html Despite all the excitement in the technical communications community over Web 2.0 technologies like wikis and blogs, it looks like companies are still reluctant to tie the knot for a variety of reasons. http://tc.eserver.org/31885.html http://tc.eserver.org/31885.html An overview of how one technical communicator moved a Word document to a wiki, and some of the issues involved. http://tc.eserver.org/31883.html http://tc.eserver.org/31883.html User documentation is rarely, if ever, read like an ordinary book. Readers jump around, finding the information that they need to perform a particular task and pretty much ignore the rest. Until they need that information, of course. http://tc.eserver.org/31884.html http://tc.eserver.org/31884.html Whether you’re a full timer or a contractor, you’ll eventually part ways with an employer. When you step out the door for the last time, what will you leave in your wake? A mess, or a way for your co-workers or replacement to quickly pick up where you left off? http://tc.eserver.org/31799.html http://tc.eserver.org/31799.html A short article that offers some tips on writing articles for a knowledge base, whether internal or client facing. http://tc.eserver.org/31796.html http://tc.eserver.org/31796.html For some, going freelance seems like an all-or-nothing proposition: you either have to jump in with both feet or not try at all. This blog post argues another way: gradually transition to full-time freelancing. http://tc.eserver.org/31794.html http://tc.eserver.org/31794.html This blog post ponders whether or not technical communicators are sometimes too enamoured with the tools, and because of that lose sight of what's best for the reader. http://tc.eserver.org/31780.html http://tc.eserver.org/31780.html With all the talk about Web 2.0 and the attendant technologies, are readers actually being better served by documentation now than they were in the past? http://tc.eserver.org/31639.html http://tc.eserver.org/31639.html Some advice from one podcaster to others on how to do interviews. http://tc.eserver.org/31568.html http://tc.eserver.org/31568.html An interview done by Scott Nesbitt of DMN Communications. Nesbitt talks with Stewart Mader, author of the book WikiPatterns. In the interview, Nesbitt and Mader discuss adopting wikis, how best to use them in an organization, building communities around wikis, and why Mader is so passionate about wikis. http://tc.eserver.org/31569.html http://tc.eserver.org/31569.html A blog post about what one technical communicator learned about his craft from dealing with his autistic child. http://tc.eserver.org/31495.html http://tc.eserver.org/31495.html Podcasting is more than a platform for reviews or polemic. It's also a powerful tool within the enterprise for training, for marketing, and for documentation. Imagine being able to carry product information or supplementary material with you and not have to worry about stacks of paper? You can do that with a podcast. http://tc.eserver.org/31177.html http://tc.eserver.org/31177.html Helping users move from being perpetual novices to experts is a tough task. As this blog post argues, good documentation helps. But you also need to create a product that users can be passionate about. http://tc.eserver.org/31156.html http://tc.eserver.org/31156.html DocBook and DITA both have their places. They're both excellent for single sourcing. DocBook is better for what I call monolithic single sourcing, while DITA is better suited for discrete single sourcing. http://tc.eserver.org/31140.html http://tc.eserver.org/31140.html If you're considering a move to the contract side of the fence, you might want to think about the questions in this blog post before making a decision. http://tc.eserver.org/31111.html http://tc.eserver.org/31111.html Technical writing is one of those jobs in which you're constantly learning. New tools, new techniques, new methodologies. No one knows it all. That's especially true for the new technical communicator. If you've graduated from a writing and rhetoric course or a technical writing course, you have a pretty good grounding in craft. But you're really only at the base of the mountain. There's still a lot to learn, and if you keep your eyes and ears and mind open then you can quickly pick up what you need to know. http://tc.eserver.org/31106.html http://tc.eserver.org/31106.html Passion, though, is a funny thing. It's easy to become passionate about something. But the fire of that passion can also be easily dimmed or extinguished, often due to circumstances that are beyond your control. Throughout your career, you'll definitely find your passion waxing and waning. But holding on to that passion and nurturing it will make you a better technical communicator. http://tc.eserver.org/31105.html http://tc.eserver.org/31105.html So you've just started out as a technical communicator, or you've been on the job for a year or two. And you've decided that maybe, just maybe, technical communication is the career for you and you're in it for the long haul. Now what? Think about the future and how you want your career to develop. http://tc.eserver.org/31107.html http://tc.eserver.org/31107.html The dynamic nature of wikis can cause a few headaches when you need to baseline documentation that's on a wiki to correspond with the release of your product. This blog post looks at some ways in which you can try baselining wiki content. http://tc.eserver.org/31114.html http://tc.eserver.org/31114.html A lightweight markup language uses syntax that is similar to wiki syntax -- keyboard characters are used to define formatting. This blog post argues that if your documentation needs are simple, and you have a low or non-existent budget, then a lightweight markup language might be worth investigating. http://tc.eserver.org/31112.html http://tc.eserver.org/31112.html There's a lot of great free and Open Source (FOSS) software out there. But one area in which it's lacking is professional-level help authoring tools. In 2005, Linux.com published an article titled "FOSS help authoring tools falter". And not much seems to have changed in the intervening years. http://tc.eserver.org/31115.html http://tc.eserver.org/31115.html Writing documentation isn't merely the act of pounding out dry prose. There is some creativity involved which comes from how you present the information, both textually and visually. The writing, though, needs to be easy to read, complete, concise, and to the point. http://tc.eserver.org/31110.html http://tc.eserver.org/31110.html Thoughts on how a contract technical communicator can become part of a development team, and set the tone for the writers who follow. http://tc.eserver.org/31108.html http://tc.eserver.org/31108.html A blog post that presents a few thoughts on using technologies like DITA to author documentation. http://tc.eserver.org/31109.html http://tc.eserver.org/31109.html User-generated documentation is a big issue in technical communication circles. If properly done, tapping into the knowledge of users can improve the quality and breadth of your documentation. http://tc.eserver.org/31113.html http://tc.eserver.org/31113.html A blog post that discusses the XO laptop, and the risks that the designers and developers took when creating the user interface for the device - for the most part they succeeded in creating an intuitive interface and a usable computer. http://tc.eserver.org/28381.html http://tc.eserver.org/28381.html A weekly podcast for technical writers by a company called DMN Communications. http://tc.eserver.org/26309.html http://tc.eserver.org/26309.html A brief tutorial on creating cross-platform WebHelp (similar to that produced by RoboHelp) using DocBook. http://tc.eserver.org/26307.html http://tc.eserver.org/26307.html A set of slides that gives a brief introduction to DocBook and why it is useful for technical writers. Also available in PDF format. http://tc.eserver.org/26310.html http://tc.eserver.org/26310.html An introduction to XML (Extensible Markup Language) and how technical writers can use it to create and manage their documentation.