Just in case you’ve missed these, TechSmith are giving away free versions of their software. Admittedly they are older versions but you can upgrade them for less than the full price of the newer versions.

Obviously they are hoping people will try them and like them enough to pay for the latest version:

• Get SnagIt 7.25
• Get Camtasia Studio 3

TechSmith have another product, which will capture images and video as well; Jing is available for both Windows and OSX, but it seems to be primarily aimed at sharing the content online.

What I’d really like is Skitch for the PC.

Tomorrow we get to spend the afternoon in the pub after gorging ourselves on turkey and stuffing. Yes, it’s the Development Christmas Lunch. This year it’s handily placed right at the end of a release cycle (although that does mean some poor souls may be dragged back into the office), so we can celebrate the release AND the birth of a baby a long, long time ago (or whatever you believe).

That also means that next week I’ll have a little more free time to think about the future, and get some plans in place. I’ve already got a fair list, some of which will feature here.

However, for the time being, here are a few things that caught my eye the past week (or so).

Writing Tips for Non-Writers Who Don’t Want to Work at Writing
As THE core skill of my job, some of this is a little hard to take but sometimes we can be a little too obsessed with grammar, don’t you think?

Grammar matters, but not as much as anal grammar Nazis think it does … Frankly, I think if most non-writers can manage to get agreement between their verb and their subject, I’m willing to spot them the whole “who/whom” conundrum.

Wiki Patterns: The Book
I love it when this happens, a blog I’ve read for ages (devoured some would say) gets published in book format. Needless to say my copy is already ordered.

Human behavior is pattern-based, and wikis are designed to support the
patterns of activity that occur when groups work together. Therefore, there’s no right or wrong way to use a wiki, so it’s impossible to write a recipe for successful wiki use that will work in all cases.

Instead, documenting the behaviors seen on different wikis and classifying those that help the wiki effort as patterns, and those that hinder the wiki as anti-patterns, is a more useful
way to offer guidance to other wiki users.

Use Structured FrameMaker and WebWorks ePublisher?
Sticking with Wikis, here is an excellent article from the WebWorks Wiki: Implementing Help-Specific Features with a FrameMaker EDD.
I probably learned more about using Structured FrameMaker with WebWorks reading that article than I have in the past year of actually using both products in anger (although that’s mainly because the set up here works so I’ve not had to tinker).

This project contains a complete workflow for producing printed and on-line documentation with ePublisher Pro. At the heart of the system is a structured FrameMaker template with an underlying EDD. The minimalist EDD contains a scant nine content elements and yet automatically assigns more than 120 paragraph styles that implement help specific-behaviors in the corresponding ePublisher Pro template.

Building Enterprise 2.0 on Culture 1.0
Sounds a bit odd I know but if you are interested in how to build an collaborative environment in your organisation then you must have a look.

To encourage an organisational shift along the enterprise collaboration maturity model, Enterprise 2.0 leaders should focus on capturing the flow of information. Over time, the flow builds not only a stock of searchable knowledge but also a reputation as the source of fresh ideas and trusted up-to-date content.

And finally, a little house-keeping. I had promised to update the OPML file of TechComms RSS feeds but I’ve not had a free minute. It’s top of the list now though, so expect to see an update early next week.

I’m currently pondering a proposal, suggesting to our Dev team that we write the user documentation first, and then use that as the basis of what the product should deliver.

This wouldn’t work for everyone but given that an XP environment encourages little (well, less) documentation than a more traditional ISO style project, then having a draft of the user documentation would be beneficial in many ways:

1. Early design thoughts are often lost as they are translated into the stories used to develop the functionality. Fleshing these out into more fully formed documentation would better capture that information, and focus it on the user.
2. Earlier consideration of the “what ifs” will likely come of this, pushing thoughts and discussions out into areas that the documentation needs to cover but which might not be considered as they might not be part of the software.
3. Focussing on the final product, rather than just the next piece of functionality, should make the big picture easier to see, allowing the developers to better understand WHY they are working on a particular piece of functionality.
4. Testing/QA can use the documentation to validate the software that is being produced. If it doesn’t match the documentation, it’s wrong.
5. Anyone coming late to the team can get up to speed much quicker.

I’m still thinking this through, and by pushing on with the documentation, sometimes even striding ahead of development, the technical author can help with the finer details of the implementation, running through some of the scenarios (or edge cases, or “unhappy path trails” depending on your lexicon) before they have been approached by development, blazing a trail for them to follow. After all, we spend a lot of our time considering things the readers of our documentation are likely to ask, if the answers need to come through the software then what better way to develop the solution?

All of this would, of course, be in close consultation with the development team but I think it might be an interesting experiment to try.

Anyone got any thoughts? Pros? Cons??

Update: I posted about this on the TechWR mailing list, and Andrew Warren pointed me at his previous response on this topic. Interesting.