I like new things, as my Belbin team role suggests, I am the person who likes to start projects and enthuse others about it before… eventually.. I get bored with it and… ohh shiny! .. something new comes along.

I’m aware of this trait and have developed some internal habits that help me overcome it’s downsides, in other words I’ve figured out when I’m getting bored and so I start to change how I work to make sure that I see the project through to completion.

However my enjoyment of new things is beneficial and I’m constantly looking for new ideas, new inspirations from which I can learn, and for ways in which those ideas can be cross-pollinated (ok ok, stolen) and used in new ways.

One example came about when I first picked up on, after many years of being told to read it by my peers, Malcolm Gladwell’s book The Tipping Point. It’s a fascinating book and several of the key points can be translated into the technical writing world. One in particular stood out, the premise that an idea could be made ’sticky’, and got me thinking about how I could adapt some of the methods into my approach to writing and structuring documentation. To my great pleasure that premise has been further developed by Dan & Chip Heath in their book Make it Stick and, although I’m only partway through it, I already have some ideas which may help make the documentation I create more useful to the readers.

There has been some discussion about our profession recently, whether it’s “just a job” or a vocation for some. I think I, like others, fit somewhere in the middle. Whilst I doubt technical writing/technical communications can be seen as a vocation, it’s certainly more than just a job to me, spilling over into my everyday life and thoughts. Typography, design, architecture, marketing and, basically any form of communication, has me questioning and prodding it to see if I can reuse any of it.

These days with personal publishing also a hobby for many, myself included, obviously, then anyone who is interested in communicating ideas and information is able to draw so much from such a wide pool of sources that, and I hold my hand up in admission here as well, I’m somewhat surprised that we have been a little slow to grab onto these new ways of communicating. Mind you, blogs, wikis and the like, are all still very new so I expect that to change over time.

But it won’t stop me constantly scanning the horizon for something new.

Have you taken inspiration from an odd source? Spotted a clever way to tackle information, or noted an idea or two after reading a, seemingly, unrelated book. How much of a magpie are you?

Prompted by two recent articles discussing the use of a Wiki, firstly this one by Joann Hackos, and this excellent followup by Ann Gentle, I realised that my current place of employment is an excellent example of how well a Wiki can work internally, and how we are considering building on that success by creating an externally available source.

I can take no credit in the fact that the development team I currently work within has, and actively uses, a Wiki. I joined the company in January this year, and was delighted to find such a resource not only available, but being actively populated.

As an internal resource, the technical advantages of using a Wiki to capture technical information are fairly obvious. The ease of use, and open nature of a Wiki suit the task very well and I think it’s fairly safe to say that a lot of developers enjoy the lack of structure and formality as well. However, it’s one thing to have a Wiki, quite another to make it a central resource that is used without much, or any, prompting.

The key is to make the Wiki THE central resource for team specific information. With that in mind, most of our meeting minutes are posted there, as are seating plans, high-level feature plans and so on. Detail is kept to a minimum, and as they are using the Wiki to track their own work, it’s a simple next step for them to start populating it with any useful nuggets of information.

As for using a Wiki externally, I think Joann has the right idea. If you have a complex product, that can be used in many different ways and scenarios then, quite simply, you aren’t going to be able to document them all. It’s also likely that your users are going to have their own ideas and thoughts and, in some cases, your users may take matters into their own hands and start populating some form of resource of their own.

Wikis, forums and so on, considered the hubs of the social web, have shifted the power of information from the traditional model. Information is now considered free, and regardless of your view on whether or not that is true, the social web and, more importantly, the people involved within it, will pursue whatever they need to meet their needs. So, if you aren’t meeting them, and there may be valid reasons as to why that is so, as I mentioned previously, then perhaps part of our role in the equation is to become the faciliator in that area.

Of course, building an online community, regardless of how it is maintained, is no easy task. The beauty of a Wiki is that it is largely self-administrating, and you can rest assured that your users will automatically be predisposed to making it as useful as possible.

Creating and providing a Wiki to external users has an element of risk, and the biggest challenge may be convincing all the areas within your organisation that need to buy-in to the idea.

Do you use Wikis, internally or externally? Do you have a company blog? An online forum? If so, I’d love to hear your thoughts and experiences.

Additional info: How to hold meetings on a Wiki

… 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.

Proof, if more proof were needed that keeping the user in mind when designing a product, document or website really does work.

Renewing a support contract with a client, I was asking them if the website had been beneficial and if there was anything about it that had worked well. The response wasn’t quite what I’d expected, so I can’t take full credit for this, but it’s worth bearing in mind. Amongst various comments, one stuck out:

“… and a lot of people have commented on the fact the photos aren’t ‘glossed up’, you get a real sense of the workmanship that way”

For example, if you look at this photo page you can see that the photos used were taken by the client on a small digital camera. When I received these photos I pulled them into PhotoShop and started filtering and tweaking them, but no matter what I did to them the end result was the same.

They didn’t feel “honest”.

It’s hard to elaborate on this without sounding rather twee but ultimately I liked the fact that the photos LOOKED real, they didn’t looked staged and lit like a professionals photograph. Unwittingly I was wearing my user cap and seeing things from that point of view.

I wish I could say it was a conscious decision but it wasn’t, but it does seem that after spending many years wearing many different professional caps as part of my job as a Technical Writer, I can now flit between them without even realising!

I guess there even may be a lesson here for anyone selling something online. The more “real” you can make your product appear on your website, the better. Which reminds me, I’ve got some stuff to sell on eBay, maybe a video would help?

Ahh the joy of site stats and referrers. With them I may not have spotted that some kind soul had added this humble blog to the Tech Writer Blog Directory.

Whoever it was, thanks! (yes, I’m guessing it was Tom). I’ve updated my details, stopping short of listing all of my websites..

To everyone else, if you are a technical writer, or just work in the field of technical communications, and if you have a blog that should be added head on over there and add it. It’s a Wiki page and is open to all to be edited.

I’m a big fan of directories (I run the Scottish Blogs directory, as finding other blogs in a ‘niche’ is always somewhat tricky. If nothing else the directory provides a starting point from where you can explore.

It’ll be interesting to watch this list grow as well, as I’m sure it will, and there may come a “tipping point” when the Wiki approach is no longer viable, but that’s some time off I think.

In other news, I have a few posts almost ready to be posted here, but I’m a tad busy at until later in the week. I really want to “up” the postings and see what I can do with this blog, and I guess the first thing will be to post regularly and build an audience.

My ‘other’ site holds brief details on my little side job stuff, which is mainly focussed on web design. I’ve just finished a website (with another on the way) and it’s nice to get that little glow of achievement. I deliberately choose small projects, and it’s fun to take what I learn there into my day job as a technical writer.

Taking the lessons I’ve learned over the past couple of years whilst “running” one man designs, which is in essence a small business, into my dau job has been interesting. Treating a small team of technical writers as a distinct business makes sense on many levels. One I hadn’t really considered in great depth was marketing the services of the team, selling what we do to the rest of the company.

I guess I’d considered it an educational function and, once educated, everyone would (somehow) know to get the technical writers involved with their project, or introduce the latest functionality to them. Of course this is never the case. Now, don’t get me wrong, I knew this but just hadn’t really considered it in great detail before… what with being busy, you know, writing stuff. ;-)

So how do you approach this kind of thing? Do you hold meetings, talk to the other team leads/managers directly? How do you “sell” what you do?