http://tc.eserver.org/authors/Nesbitt,_Scott A bibliography of works by Nesbitt, Scott 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/Nesbitt,_Scott http://tc.eserver.org/35781.html http://tc.eserver.org/35781.html Writing in a more conversational tone is a worthwhile goal. If you do it properly, you can draw readers in and make them more comfortable. The keys are to write as you'd speak, and to keep the flow and cadence smooth. http://tc.eserver.org/35782.html http://tc.eserver.org/35782.html A report of a presentation by Dru Lavigne at FSOSS 2009 that discussed how to create and sustain a writing career by writing about Open Source. http://tc.eserver.org/35783.html http://tc.eserver.org/35783.html A short article that discusses how to use the bulk export feature of Google Docs to back your work up to your computer. http://tc.eserver.org/35784.html http://tc.eserver.org/35784.html With mobile phones, email, instant messaging, and the like we're expected to be available at all times. It should be this way, and this article explains one path to taking control of your communication. http://tc.eserver.org/35785.html http://tc.eserver.org/35785.html Is it hard for you to find the time to write the things that you want to write? This article looks at some changes that you can make to your life in order to free up that time. http://tc.eserver.org/35786.html http://tc.eserver.org/35786.html Writing quickly is a skill that you should definitely cultivate. This blog post looks at four techniques that you can use when you need to write quickly. 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/35789.html http://tc.eserver.org/35789.html How often do you really, truly listen to what a client has to say? Probably not often enough. This post looks at why you should. 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/35468.html http://tc.eserver.org/35468.html Are we giving users the help they need, in the way they need it? Go minimal. 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/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/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/34977.html http://tc.eserver.org/34977.html For the freelance writer on the go, there are some items that are essential for what they're doing. This post looks at the gear that one writer uses when working away from the home office. http://tc.eserver.org/34978.html http://tc.eserver.org/34978.html Writing tightly means packing the most information into the least amount of space. It's not easy, but when you do it, the result is like magic. The key to being an effective writer is to keep what you’re writing short, to the point, and easy to read. Like the best writing on the Web. 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/34745.html http://tc.eserver.org/34745.html Far too many writers have been in a situation where something goes wrong with their computer and their work is wiped out. They have to scramble to recover or (usually) redo that work, all for want of a good backup strategy. 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/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/34572.html http://tc.eserver.org/34572.html Wikis aren’t just tools for techies. They're also also for writers. In this article, one writer describes how he uses a wiki for his work. http://tc.eserver.org/34573.html http://tc.eserver.org/34573.html Bullets definitely have their place in writing. But far too often, they're used to replace crisp, well-thought-out writing. http://tc.eserver.org/34574.html http://tc.eserver.org/34574.html Some advice on writing articles about technology (and other topics) for a mass audience. 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/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/34128.html http://tc.eserver.org/34128.html Some Web entrepreneurs have made strides by developing Web-based tools for creating slides. The four that this TechTip highlights have a number of things in common. 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/34067.html http://tc.eserver.org/34067.html To keep organized, you don't need a complex system. In fact, as this blog post suggests, managing time and tasks is best done using a simple system. http://tc.eserver.org/34068.html http://tc.eserver.org/34068.html Sixty minutes isn't a lot of time. But if you use those 60 minutes wisely, you can get a lot of writing done. 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/33755.html http://tc.eserver.org/33755.html Documentation is one area in which free/libre/open source software (FLOSS) is weakest. A project called FLOSS Manuals is trying to remedy this situation. The idea behind project is to create quality, free documentation for free software. 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/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/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/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/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/28306.html http://tc.eserver.org/28306.html A look at three hosted wiki services that are free or relatively cheap to use and provide easy tools to set up your wiki within minutes. http://tc.eserver.org/28230.html http://tc.eserver.org/28230.html Writing, compiling, and maintaining documentation is a necessary evil. While moving to DITA might not improve the quality of your documentation, it can streamline the process of creating and managing those documents. http://tc.eserver.org/27457.html http://tc.eserver.org/27457.html While Linux lacks standard Windows tools such as FrameMaker, RoboHelp, and WebWorks Publisher, it's still a viable environment for technical writers. Linux users can take advantage of a number of documentation tools, including both free or open source software (FOSS) and proprietary software. All of them give technical writers the ability to author and publish professional documentation. http://tc.eserver.org/26317.html http://tc.eserver.org/26317.html A detailed article on using the HTML Tidy utility to clear up problems in an HTML file. http://tc.eserver.org/26315.html http://tc.eserver.org/26315.html An article discussing how to use the Opera Web browser as a presentation tool. http://tc.eserver.org/26316.html http://tc.eserver.org/26316.html An overview of Linux tools for technical writers. http://tc.eserver.org/26318.html http://tc.eserver.org/26318.html A review of an XML-based documentation tool. 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/26311.html http://tc.eserver.org/26311.html An introduction to using Sun's JavaHelp system for creating online Help. http://tc.eserver.org/26308.html http://tc.eserver.org/26308.html DocBook is a powerful tool for creating and maintaining documentation. However, there are a number of factors you should consider before you move your documentation to DocBook. This article discusses reasons for and against making the switch to DocBook. http://tc.eserver.org/26312.html http://tc.eserver.org/26312.html A short report (circa 1997) on how one documentation deparment could use Cascading Style Sheets to format the HTML-based documentation it produces. 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. http://tc.eserver.org/26306.html http://tc.eserver.org/26306.html There are a number of tools available for transforming DocBook XML documents to various formats. All of these tools have strengths, as well as some noticeable weaknesses and drawbacks. This article looks at the benefits of using the XMLmind FO Converter, a graphical, highly configurable, and cross-platform application designed to transform DocBook XML files to any supported output format.