The following is largely focussed on the software industry as that is where my experience lies.

I’ve been an on/off member of the TechWR mailing list for many years now. I dip in and out of threads depending on my current work and knowledge levels. The membership of the list is fairly wide-ranging, with people involved in all sorts of technical communication activites across many different industries. This gives any discussions around our profession and interesting slant as, by and large, the constituent parts of what it means to be a technical writer, and the daily activities involved, are somewhat tied to the industry in which they work. My experience is largely in the software world, but many of the other list members have wholly hardware-based experience, yet others work in highly regulated environments, and some flit from contract to contract, job to job.

A while ago a discussion about how our profession was changing kicked off and the range of responses was fascinating. This wasn’t a surprise of course, the list is full of passionate and intelligent people, but did have the effect of causing me to sit back and reflect a little more on what I do for a living and how, ultimately, it’s a fairly unique profession.

The discussion centred, mainly, around how the emphasis for a lot of technical writing jobs is swaying more and more towards a more integrated approach to the role and how it fits within a team than the historical basis of being heavily centred on writing. The presumption (largely being pushed by those of us in the software environments) is that the skillset a Technical Writer brings to a team extends beyond “just writing the docs”. As a customer advocate, we can (and should) influence UI design and the functionality of the product, and increasingly we are involved in the early design discussions, get hold of early builds and so on. To a small degree, today’s Technical Writer whilst retaining the core function of writing documentation, also dabbles in UI design, functional analysis, sanity testing software (note: this is not QA by any means!) and may even contribute to the software itself.

Some say that this detracts from the role for which we were hired. I disagree.

The role of product documentation is hugely important to any company and its creation will always be the core function of a technical writer. However, as companies push to reduce timescales and costs, whilst ask that productivity is increased, the idea of a closely-knit team with a shared vision becomes all the more necessary. Integrating a Technical Writer into that kind of environment means that speciality becomes less of an issue, and everyone starts doing a little bit of everything else. This extends beyond the Technical Writer, obviously, but uniquely we span the divide between technology and user (application and customer) and so can start to play a larger part in the development of the applications themselves, and also lessen the impact on our own area of expertise.

As I stated in that discussion:

I’ve always presumed that the role of technical writing isn’t really about ‘writing’ all that much (these days) and is why I’ve pushed to change job and team titles away from “writing” or “publications” to “communications”. It’s a small thing, but I think it breaks the “document monkeys” label a lot of people still have in their heads.

What this can mean is that a Technical Writer needs to have a sufficient knowledge to be able to intelligently converse with the application developers, and a good understanding of the business and user requirements that are currently being worked on. Acting as a “user proxy” in early design meetings has the double bonus of improving the application being developed (as most developers have a tendency to think in terms of functionality, rather than task) and hopefully easing the burden on the documentation as the general usability should be improved.

A bold statement perhaps, but ultimately the long-term aim is to have a better grounding in the usage of the application for which you are writing documentation. Understanding the why, and the who, as well as the how, is not a new thing of course, but contributing to the team in a “non-document” way is the real benefit.

A lot of companies still view product documentation, and the technical writers who produce it, as necessary evils to be tolerated and humoured. Most technical writers are able to constructively challenge and change that perception and I’m certainly not suggesting that anything I’ve suggested is the only way to do things. But I do believe that, in software documentation, there is a growing call for more technically technical writers, as opposed to technical writing writers. Becoming the accepted user-advocate in your development team is one path to achieving this, and I firmly believe that it will enhance both your own career and the perception of our profession.

Additional links: TechWR Mailing List.

Over the past year or so, as I’ve started to struggle to keep up-to-date with the multitude of websites that interest me, I’ve increasingly turned to RSS feeds to help me manage the load.

With that in mind, I’ve been compiling a list of Technical Communications feeds that I find interesting. Some are by Technical Writers, some are not, but I generally skim through the new items daily and I’ve yet to have a day when I didn’t read or find something interesting and useful.

If you have an RSS newsreader, then feel free to grab a copy of my subscriptions. If you right-click that link you should be able to download the file, and then just import it into your newsreader of choice (I prefer Google Reader).

And, of course, I’d love to know if I’m missing any. Hope you find this useful.

I’m not sure if this is lazy blogging, or a useful feature but here, again, are a few of the articles and blog posts that caught my eye over the past week.

• Audrey Carr on Design Briefs ~ “After a series of small projects involving undefined requirements, fuzzy objectives, and an aparent lack of truly insightful customer insights, I’ve spent a good chunk of this week thinking about the strategist’s favourite tool for communicating with creative and account teams: the brief.”
• Inline Linking is bad for usability - whilst it’s aimed at those people concerned with optimising their content for search engines, the examples are interesting from a writing point of view as well, swap out “usability” for “readability” perhaps.
• Linking DITA Topics using Relationship Tables - If you are investigating DITA have a skim through this, yet another way to increase the power of DITA
• A mile wide and 30 seconds deep ~ Mike Hughes on how to focus your help content, “…focus the Help on what it does well, that is, provide a wide variety of 30-second informational solutions to get most users back on track and in task”
• Help Authoring Tool matrix - has been running for a few years now and is a bang up-to-date, excellent resource.
• The Rockley Blog - Ann Rockley and Steve Manning, of the Rockley Group and that book (Managing Enterprise Content: A Unified Content Strategy), have a blog. I had dinner with Steve, and others, after the X-Pubs conference this year and this is definitely a blog to watch.

OK, that’ll do for now.

Hopefully, by this time next week, I’ll have finished the new design for this site and will start posting a little more regularly. There are a few things I would like to explore, and hopefully I can get some feedback from you, dearest reader. Make sure you subscribe to the RSS feed to catch the next post.

… and why you should use it.

Separating content from structure and style is a common theory, widely accepted to those of us either using or investigating single source solutions for our documentation. The same theory has been applied to web development and offers similar benefits.

CSS-based web design developed in parallel with the growing movement towards (and promotion of) the use of standards on the web. The web standards movement was a direct response to the increasing problems faced by web designers as they struggled to keep pace with the bespoke features introduced by the browser software of the day. Advocating support for the W3 maintained standards around, initially, HTML it soon found a band of supporters who were challenging themselves, and everyone else, to stop using tables as a mechanism for controlling page layout, and instead switch to using Cascading Style Sheets (CSS).

The origin of table-based layout was, essentially, a clever hack. Early versions of HTML, and the internet browsers that people used to view web pages didn’t have any way to control the layout of a page so tables were used. Nesting tables within tables to provide discrete areas for navigation, content and so on, became the norm and some very complex examples still exist. However, as the web gained popularity and large sites started to emerge, it became apparent that table-based layout were no longer workable. They were far too hard and too time consuming to maintain, and many web developers recognised this and started searching for a solution.

Separating the content from the layout elements was an obvious step and is easily achieved using CSS. Whilst it was primarily created to allow more flexible and powerful styling, it was soon evident that, as each page element can have positioning assigned, that it could also be used as the positioning mechanism.

The basic theory of CSS-based layout is pretty simple. If you draw out the sections of your web page you’ll probably end up with several different blocks. One for the banner, one for the navigation, another for secondary navigation, one for the content, and so on. Each of those blocks can be positioned separately, or in relation to one another and as each block is uniquely identified division, then all you need to do is apply layout rules to every division to position it where you want. OK, maybe it’s a little flippant to say “all you need to do” as there is a wealth of issues to be aware of when using CSS for layout but don’t panic, there are plenty of templates to get you started, I’ve linked to some at the end of this post.

Mind you, this doesn’t really sound much different from using tables though. Right?

Wrong. The real power of using CSS for layout comes when you need to change the position or other layout characteristics of one of those divisions. For example, let’s say you have a set of navigation links in a column down the left of the page. In a table-based layout you’d have a separate table cell holding those links (which may in turn be held in a nested table to help you align them). Simple enough.

Now, you need to switch that list of links to the right of the page. In table-based layout you’d need to cut-n-paste that table cell and move it on EVERY PAGE in your website or across your help system. Do you fancy doing that for every page in a 500 page help system, because I don’t.

Using CSS for layout, you’d make a change to the stylesheet (the .CSS file) and all the pages in your website would be updated. For a large website, or for anything more than 20 or so pages, the time savings soon become evident. I’d advocate that you take this approach for smaller static websites as whilst, table-based layout is still possible, the repetition of making any minor layout change still needs to be reflected across every page.

Ultimately, using CSS for layout isn’t really about web standards, nor is it just a trend. It’s a justified and valid use of technology to allow you to work smarter, to concentrate on the content you are delivering, and not spend a disproportionate amount of time editing multiple pages of a web-based help system or website. When your boss asks you what you did last week, what would YOU rather say?

Learning CSS-based layout is not without problems, there are still browser compatibility issues to overcome, although most are now well documented and easy to grasp but I truly believe that it is worthwhile learning the basics. Of course, the internet being what it is, there are a myriad of templates available to get you started, in fact some may even provide all you need.

Related reading:
Layoutomatic - offers three simple CSS-based layouts. A good way to learn the basics.
Free CSS layouts and templates - compiled by the wonderful Smashing Magazine.
Web Standards Project - keep up to date with the latest news in web standards.
CSS Zen Garden - one structured page of content, hundreds of different CSS layouts and styles. THE example of the power of CSS-based layout.
A List Apart - an excellent online magazine for web design, chock full of good stuff.

From my own blogging experience, posting regularly is a good thing. Mr. Neilsen (who, despite reports to the contrary, is sometimes correct) suggests that quality not quantity is the way to go and, for this blog at least, it is something I’m striving towards.

Nailing a posting schedule is part of this and, as the evidence within demonstrates, I’ve yet to crack that egg. In an effort to force myself I’m going to try flipping that argument around for the time being and just posting whenever something catches my eye. No idea if it’ll make any difference but hey, you never know.

So, with that in mind, here are some interesting sites and articles that have zipped across my radar in the past few weeks:

• Simplest of style guides ~ “Write well, quickly, in the active voice and the present tense.”
• This way to the web, print designers ~ “… come to grips with the fact that, on the Web, design is not a method for implementing narrative, as it is in print, but rather it’s a method for making behaviors possible.”
• Is technical writing for you? ~ “If your goal is to write a novel, this is not the job,”
• Technical Writing podcasts by Harry Miller, a technical editor in Microsoft’s Developer Division User Education
• Adobe entering the “Office” software market? It’s a possibility, but what would it mean for FrameMaker I wonder..
• Better Writing through design from the “must bookmark” website A List Apart.
• Understanding Engineeers ~ “here’s a quick lexicon of what computer programmers generally mean when they’re talking about how hard some problem is” (via)

I hope you find them as interesting as I did.

If you’ve visited in the past week or so you’ll have noticed that things look a little different here. Well don’t get used to it as it’ll change again soon.

I’m “rebranding” slightly, but it’s taking longer than expected (pesky day job). I have two or three new posts ready to go, but I’m going to wait until the site is ready before publishing them. I think I said that a couple of weeks ago mind you but bear with me.

I’ve hit an unexpected problem with this blog, one which I didn’t think I’d hit for quite a while, if at all.

I can’t seem to find a focus.

Now, considering that this blog has the breadth of topics that the umbrella of “Technical Communications” covers that really shouldn’t be possible. But that isn’t really where I’m falling down.

I’ve long since held the belief that you don’t, ever, blog about your workplace. Confidentiality issues aside, it just doesn’t seem very professional to have a second dialogue, in a remote location, that discusses either colleagues, working practises, or general morale issues so other than some very “good day/bad day” hints, I’ve tended to steer clear of it altogether.

Which, for a blog that is centred on my professional life, makes things a little awkward.

Of course I don’t need to look too far for plenty of topics that aren’t directly related to my current employer but as there are already many blogs out there that cover general ‘tech comms’ news, it was something I deliberately veered away from.

So I now find myself searching for a focus for this blog, and until I hit upon a formula that works for me, as the writer, I’m afraid that you, dear reader, will need to put up with my tried and tested “if in doubt, blog” methodolgy. Of which this post is a shining example.

I guess it’s akin to writers block. The best way to break it is to start writing, about anything. I remember reading about one writer that, when “the block” descended on his writing, took to writing out his shopping trips in longhand. Pretty soon he was back in the flow, and found it much easier to switch back to his day job.

I do the same, although I guess blogging is a little different. At least I find one aspect of it different, namely the title of each post. I know that I can go back and add a title once I’ve finished but it’s not my habit, just yet, and so I find that a vague idea for a blog post is stated in the title but what follows, what flows when I start to type, is rarely what I thought I was going to discuss.

Ultimately I’m not searching for focus at all, I’m trying to kickstart this blog by forcing my own hand. If I keep writing the content will come, and so, I hope will something of use to anyone who reads it. It may just be that summer lull that all bloggers go through, but despite my best efforts, I’m finding posting here harder than it should/needs be.

I’ll keep bashing away at the keyboard though and hopefully things will start to take shape here. Ohh and that reminds me, there are some design changes needing done, so if things look a little wonky (or completely different) over the next couple of days, then don’t panic. It’s me, not you.

Phew. Post finished. That wasn’t so hard, was it?