http://tc.eserver.org/publisher/One_Man_Writes A listing of works published by One Man Writes 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/One_Man_Writes http://tc.eserver.org/35829.html http://tc.eserver.org/35829.html Consistency is an important part of communication, even at the simplest level of having a common terminology, using the same words consistently throughout a document helps the reader learn. Take this idea up a level, from a single document to a number of documents and maintaining the same terminology across all documents can further help re-enforce the messaging and aid learning, and should give the reader a level of comfort that the entire set of information has been thought of, and delivered, as a cohesive set. http://tc.eserver.org/35586.html http://tc.eserver.org/35586.html One common complaint a lot of technical writers have is that they aren’t included early enough in lifecycle of a project. The downsides are that by the time work hits your desk you don’t have a full picture of who the customer is, why they want whatever it is you are building, and how they want it provided to them. All of which directly impacts the information being created. http://tc.eserver.org/35526.html http://tc.eserver.org/35526.html I have been remiss at writing new content for this blog, and whilst this topic isn’t one that I said I’d post about (those posts are coming, I promise), it’s something I was discussing yesterday and so is at the forefront of my mind. Like many people I still use pen and paper when taking notes, and regardless of the type of meeting I stick with three basic categories. http://tc.eserver.org/35419.html http://tc.eserver.org/35419.html 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? http://tc.eserver.org/35301.html http://tc.eserver.org/35301.html I have no idea what our users want. I do know they want information, and I know they want that information to be kept up to date as our product evolves and as far as those basic needs are concerned, I’m happy that we are meeting them. Beyond that I admit I’m not really that sure. http://tc.eserver.org/34651.html http://tc.eserver.org/34651.html Perhaps the time has come to wrap up the STC and let a new organisation grow from the ashes. Those who are interested, and who believe our profession needs such an organisation will rally round and rebuild something. If there is not enough interest then perhaps that is a further indication that the STC has had its time. http://tc.eserver.org/34105.html http://tc.eserver.org/34105.html The parallels between the theories of technical communications and those of web design are very similar, the key aim is to keep the audience in mind at all times. The way you structure and present the information is also important, as is a sense of usability of the content itself. http://tc.eserver.org/33693.html http://tc.eserver.org/33693.html One of the more popular posts on this blog is titled DITA is not the answer and, whilst things are certainly moving forward, it’s a little sad that it is still valid. A recent comment on that post suggested that it’s not just DITA that is lacking, it’s the working realities of single source that is flawed. http://tc.eserver.org/33695.html http://tc.eserver.org/33695.html 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. http://tc.eserver.org/33607.html http://tc.eserver.org/33607.html The main aims are to provide a consistent set of information to our customers, throughout their relationship with us. So from initial contact right the way through to rollout and future upgrades, we will have a coherent set of information that is updated accordingly and a clear idea of how it will all be communicated to the customer. http://tc.eserver.org/33330.html http://tc.eserver.org/33330.html There are some fundamentals tenets of our profession that are widely accepted. One being that you always need to know your audience before y can begin to understand their needs and so produce the information that they require. http://tc.eserver.org/32145.html http://tc.eserver.org/32145.html 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. http://tc.eserver.org/32089.html http://tc.eserver.org/32089.html As part of the product, testing documentation seems like an obvious thing to do, but what does it really mean? I’ve fielded the question in a few different places now and it’s always interesting to delve deeper and understand the rationale behind the request. http://tc.eserver.org/32046.html http://tc.eserver.org/32046.html As a technical writer, every decision you make is influenced by several discrete things, considerations for either the audience of the information, the process you’ll need to follow to collate and verify the information, and so on. Every decision requires such considerations but is it possible to model these? http://tc.eserver.org/31749.html http://tc.eserver.org/31749.html Single sourcing is good, I’m sure most of us can agree on that, but I’ve recently been wondering if perhaps DITA isn’t quite good enough? http://tc.eserver.org/31747.html http://tc.eserver.org/31747.html These are exciting times and we have a great opportunity to finally leverage technical communications into the spotlight. The value of information is finally being properly realised, and we are ideally placed to help any organisation make the most of what information they have and help them understand and create the information they really need. http://tc.eserver.org/31748.html http://tc.eserver.org/31748.html The gaps in your documentation aren’t there because you haven’t consider a particular level of user; the gaps in your documentation are there because you haven’t considered how one level of user becomes another. How DO you get from Beginner to Expert?