I’ve been chasing this train of thought for a while now and decided to start writing my thoughts down in the vague hope that they come together in a way that makes sense to others. It seems to make sense to me but, as yet, there are a few grey areas into which I may stumble. So, not so much a train of thought but a car crash of ideas, if you will.

Shoddy metaphors aside, the main crux of my thinking is based in my efforts to find a central point around which I can arrange my knowledge. Obviously my knowledge of some areas is greater than my knowledge of others, but part of this exercise is to start to identify the areas in which I’m lacking and so allow me to investigate them further, to feedback into my train.. no.. car… umm, driveshaft??

OK, let’s start over.

The role of a technical writer is fairly varied, and merrily traipses through several distinct fields. Most technical writers will know a little (or a lot) about many topics, how to structure information or how to create a usable index, they will be also have some knowledge or awareness of, for example, typography and readability issues, they will have some knowledge of working with graphics, and they will also gain knowledge of the various tools they use. Suffice to say that the skill set and ‘earned’ knowledge a technical writer posseses is almost endless.

And that’s all before you consider how much they know about the products that they are documenting

So from that starting point we can see that technical writers already dip their toes into various pools of expertise.

Now, let me just changes hats for a second… right. I am now a web designer.

Look at the knowledge I have attained as a technical writer, with a web designer hat on, there are a lot of parallels. Some are direct, some not so obvious but still discretely linked, after all, regardless of the medium the two disciplines share key facets of importance; content and audience. The delivery mechanism is secondary to those at all times.

Web designers also span several different fields, with some knowledge of HTML, CSS and other languages (usually text based), they too worry about layout and typography to ensure readability is maintained, they plan what type of content will be created, and understand the need to structure that information in such a way that it is explorable. The parallels are many.

So, somewhere in my head I’m wondering why the two disciplines don’t seem to be talking to one another. Is it lack of visibility? Is it just me that thinks it is this way? Are there secret meetings going on as I speak?

One of the reasons I ask is because there is a wealth of information out there that focusses on web design, even spilling over into the social/community aspects of information sharing, which the technical writing world could use and leverage. Have a look at some of the articles on A List Apart, for example. Those which aren’t specifically about code tend to talk in terms of analysis, planning and design. All things I do as part of my job as a technical writer. Boxes and Arrows takes you into Information Architecture territory, with user experience key and, for many of us who work in software development and who can influence both the UI and the Use Cases that help constitute a software application, there is a lot of useful information that we can adapt for our own use.

If you are in New York City in early October, check out the idea2007 conference, which will highlight and discuss designing complex information spaces of all kinds. A limited entry pre-conference event kicks things off on the 3rd of October, and the conference proper is on October 4th and 5th.

Throughout their days, people are engaging with complex information to manage their lives.

And designers now realize that information isn’t simply this stuff you find - the appropriate presentation of information helps people make sense of the world around them.

This conference addresses issues of design for an always-on, always-connected world. Where “cyberspace” is a meaningless term because the online and offline worlds cannot be made distinct. Where physical spaces are so complex that detailed wayfinding is necessary to navigate them. Where work processes have become so involved, and so digitized, that we need new processes to manage those processes.

This conference brings together people who are addressing these challenges head on. Speakers from a variety of backgrounds will discuss designing complex information spaces in the physical and virtual worlds.

Keep an eye on the conference blog for further snippets.

I’m a member of the IAI and a little disappointed that I won’t be there, I’ve also been helping out on the conference website (although it’s a bit cheeky to claim that as my contributions have been few and infrequent).

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?