bookmark_borderRecently Read

Another week, another quick set of links. I really should start using one of these new fangled “social bookmarking” sites for this, shouldn’t I. Problem is I already have a del.icio.us account for personal use, and I like being able to add some thoughts about the links but it limits that slightly.

In saying that, it does mean I give each link proper consideration, rather than just bookmarking them in passing. With that in mind, I thought I’d change the format of this post a little and offer a little more thought on each. Hopefully the links remain interesting and useful to others.

In a (short) post entitled Identical vs derivative reuse Ann Rockley suggests that

“one thing is certain, that companies can reuse more content then they think”

If you are currently investigating reuse opportunities within your company then you should find this interesting. Understanding the potential is a key part to forming your single sourcing business case, and if nothing else it offers some handy reminders of places to look.

Anne Zelenka wonders why companies are moving away from cubicles to open plan spaces to aid communication, and proffers some suggestions in her post titled Mold the virtual space, not the office space

“Lots of web workers are traditional employees and go to an office every day. But they can still take advantage of the web to reach out inside and outside their company.”

In my personal experience, open plan offices are a boon to the technical author in many ways. Physically locating a technical author with the development team that they are working with ensures that they catch all those snippets of information that typically disappear into the ether.

However, the downside is the constant distractions and background noise. As such I tend to spend a few days a month working at home, setting work aside for those days as I know I can tackle larger chunks of work with little to no distraction or interruption.

The first of two links to the ever thought provoking Ann Gentle. Her article The “Quick Web” for Technical Documentation, which discusses using wikis for technical documentation. is available as a downloadable PDF. The article was recently published in the STC magazine Intercom and others sage advice (as ever).

Keeping on the wiki theme, I came across a summary report from an MBA student that covers Managing Wikis in Business:

“indicates that wikis have provided platforms for collaborative and emergent behaviour, enabling people to work/communicate more efficiently and effectively, learn from past experience and share knowledge/ideas in organisational contexts that are not averse to collaboration”

I’ve not read the full report yet, but looks very interesting.

Are you involved with the UI design of your application? Joshua Porter makes the case that you should be as interfaces need editors:

Editing is mostly about clarity and making the interface concise. It’s a lot of copy-writing, and only a little rounding corners.

With a task view of how an application is used, there is an easy ‘in’ to this area for most technical writers.

Sticking with UI design, if you are interested in this area have a look at these articles from Apple Insider. Whilst they are focussed on new elements of the “soon to be released” Apple OS, they start back in the days of early GUI. Fascinating stuff, or maybe just a nice bit of nostalgia. The articles cover the new Dock, Spaces, and Finder.

Finally a doozy of a post from Ann Gentle. It’s the type of thing that makes my head spin and sort of, maybe, ties in with my own thoughts on structured authoring within an Agile development environment. Single sourcing documentation, following a structure such as DITA, matches the fast pace of Agile development, to improve collaboration and make the sharing of discrete chunks of information more open a Wiki makes sense. So, in my mind there is a match, or at the very least a correlation between structured authoring (DITA) and Wikis. However Ann, in discussion with Chris Almond and Don Day, comes to get:

“a sense that there are two camps in technical documentation. There’s the “quick web” folks who connect easily and author easily, and then there’s the “structured quality” camp that requires more thoughtful testing and time spent on task analysis and information architecture. Also, the types of information that these authors are trying to capture are opposed in some senses.”

It’s a fascinating post and has certainly got “ideas popping and synapses firing” in my brain. Are structured authoring and wiki opposing forces? is a question which is going to keep me occupied for a while.

That’s all for now. Next week I’m going to try and NOT feature a post (or two) from Ann Gentle but we do seem to share a lot of similar ideas. Don’t worry, I’ll “spread the love” as they say.

Right I’ve got a presentation on Using Wikis for Collaboration to finish. Pass the caffeine please.

bookmark_borderWikis, and the shifting of power

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