I’m currently part of a cross company initiative (started at the grassroot level) that is aiming at improving our product based information, making the messaging more consistent and ensuring that our customers hear get the information they need, at the time they need it. This is from Marketing down through Sales and into the product documentation itself.

Everyone involved understands the benefits and can see the potential we have if we take this approach. Ultimately it should decrease the information silos across the company and make sure that duplicate content is kept to a minimum. It’s fair to say that, at present, our company is at Level One (with Level Two pretensions) on the Information Process Maturity Model:

“Information developers work independently, designing and developing their content in isolation from other developers in their organization.”

The common aim (and at this point I’ll point out that I’ve not mentioned the IPMM to anyone else yet, but have had it in my head as I helped start the initiative) is to get to Level Three which seems like a good place on which we can build further in the future. Level Three states:

“Information developers are encouraged to form teams to plan, design, and develop content regarding the same product or process. Opportunities for sharing content among deliverables increases because developers are more aware of the content being created by their colleagues. Developers frequently form self-organized teams to jointly produce a result.”

The good news is that, purely because some of us are already talking about the product information, there are other people starting to consider doing the same for other areas of information.

However there is something that will block us and that is the age old problem of document management, and yes the title of this post hints at what we are considering using to help us solve that problem.

The nature of the information we will be producing is very document-centric as a lot of it is written with mind to handing it to a (potential) customer. Currently there is likely to be a small group of people who will be authoring the content, and we had considered using our SVN repository to provide versioning and access control. We’d then publish the documents to a central location on the network.

Still not ideal but, given the current economic climate, it was a free solution for a grassroots level project and we all agreed it would be better to prove our approach was correct first before going cap in hand to ask for funds for a document management system (there are other reasons we shied away from that solution of course, administration and maintenance being one of them).

Then, by chance the other day, one of my colleagues mentioned that he’d just gotten in new MSDN discs and license and he spotted something called SharePoint and “hey, isn’t that something to do with documents? Can you guys use it at all?”.

After rolling my eyes a little (I thought I’d broken that ‘you are the document guys’ mode of thought already!), I realised that yes I could use it, and that it might well be ideal for our cross company initiative.

And so it is I come to find myself reading up on SharePoint installations, configurations and usage. My first port of call will be Tom Johnson but if anyone else has any good pointers please leave a comment.

I’m not entirely sure if it will meet our needs but, if nothing else, it’ll be good blog fodder. Consider yourself warned.

Finally (this is an idea I had many moons ago) a one stop website which aims to list all technical communications (specific) tools.

In their own words:

One of the most common questions heard on many forums is “What tool do you use for [purpose]?” Answers vary, of course, because everyone has their own favorites and some folks will even answer that the right tool is “the one that best meets your needs”.

Sometimes, many people will answer that you need to look at the different tools, download trial versions, and test. But where is the list of tools to choose from?

It’s here at TechComm Toolbox, your online resource for all applications, services, and consultants related to technical communication.

I’d imagine there are still some applications to be added but why not go and have a look at the Toolbox. I’m sure it’ll come in handy in the future.

Note: I am not being paid to promote this website. The Tech Comm Toolbox was created by JTF Associates.

Back from a week in Spain (weather was lovely, as was the cerveza and tapas!) I’ve taken some time to look into some suggestions for screen recording.

Part of the developer community website we have was always aimed at providing online video tutorials showing the latest features. However we’ve had acres of issues getting these produced. The recording usually goes ok but editing them and getting them into a format that is acceptable for the website seemed to be causing us problem after problem.

Having checked out all three suggestions, Wink, Demobuilder and Camtasia Studio I have to admit (and you’ve probably already guessed from the title of this post) that Camtasia Studio blew me away. It’s a very slick piece of software, brilliantly designed to lead you further into the complexities it CAN offer without dazzling you with options the frist time you fire it up.

One of the best features, the one that took me by surprise, is called SmartFocus. As you click around the screen it zooms in appropriately and only, rarely, missed a beat in the few demo recordings I took. It’s very impressive, and once you get into editing the recordings, splitting them up, adding transitions, captions, callouts… well I’m sold. As will my company very soon (the purchased order has been raised).

Thanks to all for their suggestions.

If you are looking for a very simple and quick way of recording a screen demonstration (I’ve run up to about 30 minutes without issue) then go download the Camtasia Studio demo copy. You can try it for 30 days and if you are in the market for software like this then definitely give it a look.

Hell, if you have 30 minutes free, download it, install it, record something and watch the playback. You’ll probably start to wonder what you COULD use it for in the future…

Note: I’m not being paid for this, just the opinion of a very impressed first time user.

Tom Johnson has had a look at the survey recently published by the HATT matrix website on help authoring and, by pulling in the results of some other surveys in the same area, has extrapolated some good conclusions from them.

He rightly points out that surveys need to be taken with a pinch of salt (he goes into the detail of why this is so), and that whilst the numbers involved would seem to be high enough it’s likely that the questions themselves need further consideration in future.

That said, there are two things I took from his post.

1. Know the problem before picking the tool
You may not be in the position to switch authoring tools, but if you are and you have investigated the market then please make sure that you are buying a tool that addresses the problems you have.

The presumption here is that if you have a legacy tool (like we currently do, FrameMaker 7.1) and it still works and meets your requirements then there is no good reason to upgrade. I’ve been victim of buying into the ‘keeping up’ frenzy that software manufacturers like to generate but once a product is reasonably mature it is likely it has most of the features you need already.

I’d offer Microsoft Word as an example here, I could probably still use Word 2.0 for the few documents I maintain in that format as the newer versions add functionality I don’t need (and which has ended up intruding on my workflow at times!).

The X-Pubs conference a couple of years ago had a common, if not publicised theme. Almost all of the presentations included the advice to figure out what problems you had, before deciding IF single sourcing (using XML as the base format) will help and that’s even before you consider the tools themselves.

2. DITA is still a theory
Whilst it is true that the number of people leveraging DITA for their content is rising, the numbers remain low.

Partly that will be due to the fact that few organisations/teams/people are in a position to quickly switch just because a new technology has come along, but and I’ve said this before (in fact I’ve said that I’ve said this before!) rollout of DITA remains harder than rolling out a bespoke authoring tool.

When costing an implementation of a new tool there are various factors and it’s very easy to see that you can get MadCap Flare up and running quickly, where as a DITA based solution takes investment in developing the environment. This is beginning to change but, as yet, the phrase ‘DITA support’ really only means that you can output to a DITA formatted XML file. The tools aren’t constructed around the DITA concepts, so you immediately lose a lot of the benefits that DITA can bring.

Until there is a tool that fully leverages DITA, building it into the workflow of using the tool, and helping the concepts become part of your daily working practice then it will continue to be a marginal player.

Which, in a way, is how it should be. DITA is not a tool, it is a technology and methodology. It is there to support the toolset and the writer. It’s just a shame that tool vendors continue to believe that THEIR format is best, refusing to budge from that position and shoe-horning ‘DITA-esque’ features into their software.

Anyway, the rest of the survey write up is interesting and worth a read but, as Tom says:

“I do love these surveys, though; if for no other reason than they give us something to talk about”

As we are in the midst of rethinking our publishing processes, I’ve been looking at the current crop of tools, and (for our needs) three of them stand out over their competitors. Adobe, AuthorIT and MadCap seem to be heading for a battle royale, with the latter two the David to Adobe’s Goliath. But who will win?

Before yesterday I wouldn’t really have put MadCap in that battle but it’s been a busy time for MadCap, who (yesterday):

..unveiled its roadmap for the first complete, native XML software family designed to solve all of a company’s documentation and authoring demands. The MadCap family will include five new products: MadCap Blaze, MadCap Press, MadCap Team Server, MadCap X-Edit, and MadCap X-Edit Express, as well as enhanced versions of MadCap Analyzer, MadCap Flare, MadCap Lingo and MadCap Mimic. The tightly integrated MadCap family will provide companies with an end-to-end solution for developing and delivering content in print, online and on the Web—and in their language of choice.

[full details]

OK, so MadCap have a lot of ideas, but what does this mean for the technical communications industry? Putting aside discussion on bespoke solutions, in what state is the current crop of “out of the box” products? And, ultimately, why is this news from MadCap so intriguing?

Looking at the current tools the obvious and dominating product is FrameMaker. Recently updated by Adobe and with a new lease of life alongside Robohelp in their Technical Communication Suite, the future looks bright for the product and as the market leader it’s a safe decision to adopt their products and, like Microsoft in the OS business, it’s safe to assume they aren’t going anywhere anytime soon. With a little work and additional tools, the Technical Communication Suite offers a smart multi-publishing system built around well-known and well-proven tools.

Then there is AuthorIT, which has been on my radar for sometime now, and the latest version certainly offers more functionality and builds on their core strengths. Their entire suite covers a lot of the areas that MadCap are targetting and it’s already being used by technical communications departments. The latest version is, in essence, a 1.0 so has a few rough edges and issues but the AuthorIT camp are making the right noises and I expect it to become a solid and viable solution for many people wanting to move into multi-format publishing from a single source.

At this point I should really mention the other tools that make up the rest of the market but as I’ve not really been heavily involved with anything else (Arbortext, ForeHelp, HDK are about it) it would be wrong of me to summarise both their market share and their futures (if anyone else has an opinion here I’d love to hear it in the comments). I would guess that, and I include AuthorIT and MadCap in this, the rest of the market outside of Adobe is fairly evenly split across a variety of products.

The new MadCap offerings bulk out their current product set into a complete end to end publishing system and, from what I can see with the limited details on offer, ticks all the boxes. On the other hand, both Adobe and AuthorIT will say the same thing so perhaps we need to see a little more detail before we get too carried away?

Yet, despite the fact that the feature set MadCap announced has a bigger overlap with AuthorIT, the feel is that MadCap are aiming squarely at Adobe. Of course, it’s understandable that they are aiming at the biggest target as chipping away at the other players probably isn’t a sustainable business plan, so the question is whether or not they can beat Adobe at their own game.

Given that Adobe were missing in action for a few years, the speed at which they have ‘caught up’ has impressed me but having seen demos of both their Technical Communication Suite, and of MadCaps offering (before these new products were announced) my gut feel is that Adobe have only caught up and aren’t moving forwards as fast as MadCap. In fact I think it’s safe to say that MadCap, and AuthorIT, are changing the game and I’m not sure if Adobe are properly positioned to respond.

As Ellis, over on the Cherryleaf Blog suggests:

I still have concerns that Adobe still really doesn’t understand the practicalities of technical communication, that features appear as solutions looking for problems to solve. However, Adobe is the market leader and, as we’ve seen in IT many times before, it’s often the company with the best marketing (rather than the best software) that wins.

The latest swathe of products gives MadCap a full, end to end, system that should be able to handle anything a ‘typical’ technical communications team can throw at it. In saying that, without a little more detail it may all be smoke and mirrors (something they’ve been accused of in the past) but the simple fact is that MadCap have already demonstrated they ‘get’ the current marketplace, and they’ve certainly made a big enough splash to warrant the attention.

I wonder, if we fast forward a couple of years, if the marketplace will still have one big player. I suspect not as the noises coming out of both the MadCap and AuthorIT camps speak of big things, so perhaps Adobe need to look over their shoulder and up their game? Regardless, the main winner of this competition is you and I, the technical writers who deal with these products on a daily basis. As far as I’m concerned, the biggest part of the MadCap press release is the fact it exists at all. Challenge the status quo and things start to happen, quickly, and the technical communications community can only benefit.

I’ve mentioned DITA a few times on this blog, and my DITA is not the answer post is still attracting attention. As I’ve said, I think the DITA standard is an excellent one for software documentation and the DITA movement is slowly catching up to the hype. I’ve never given up on DITA and had always planned to use it as the basis for the next stage of our content development, and as it happens the switch to a full DITA/CMS based solution may be closer than I had anticipated.

We have been considering how best to publish up to date information in keeping with patches and minor releases, and if we can tidy up and publish useful information from our internal Wikis and support system. The nature of the product we work with means there are a lot of different usage patterns, not all of which we would document as they fall outwith typical (common) usage.

So, how to publish formal product documentation, in-line with three versions of the product, in PDF for ‘printed’ manuals, JavaHelp to be added to our product, and HTML to be published to a live website alongside other technical content (ideally maintained in the same system as the product documentation). Storing the content as XML chunks also allows us to further re-use the content programmatically (which can be tied into our product in a smarter, dynamic, fashion).

The obvious answer is single source using DITA to structure the content, storing the content as XML to give us the greatest potential avenues for re-use. Nothing particularly startling there I know, but it’s a switch from the direction we had been considering. So I’ve been catching up on what’s new in DITA-land and have to admit I’m a little disappointed.

We already have FrameMaker and Webworks in-house, although both are a couple of versions old, and thinking we might keep using those applications I’ve been hunting about to see if I can find a solution that offers a coherent, end-to-end, story. There are several CMS solutions which require an editor, editing solutions which require a CMS, and a few products that straddle both CMS and editing but then require publishing engines.

I understand that it would take a collaboration between vendors to be able to offer a simple, seamless solution

In addition to that there does seem to be a tendency for any DITA focused solution to remain the remit of the overly technical. Don’t get me wrong, I’m quite happy delving into XML code, hacking elements, or running command line scripts to get things done. But surely I shouldn’t have to resort such things? Now, I’m sure there are many vendors who will tell me that I don’t need to worry, but I’ve seen several demos and all of them miss a part of the FULL story.

Come on then vendors, stick your necks out. If you are a CMS provider, then recommend an editor. If you sell editing software then talk nice to a CMS vendor and start promoting each other (yeah Adobe, I’m looking at you!).

And yes, I’ll happily admit that maybe I’m just not looking closely enough. If only there was some sort of technical community website that I could join, perhaps with a group or two on DITA? That’d be great.

Ohhh wait. There is! (not the most subtle plug in the world, was it? I think the new Content Wrangler communities could be a big hit, do check them out).

Have a got the wrong end of the stick, are there really gaps in the market in this area at present or is it just my imagination? I guess I’ll be running a fair few evaluations over the coming few weeks and, of course, I’ll post my thoughts and findings here.

Recently I’ve been toying with some software tools to try and focus my writing a little better, stumbling across an application called Q10. A full-screen text editor which is, according to the website, “a simple but powerful text editor designed and built with writers in mind.”

Whenever I start a new piece of work I tend to write up notes in text files first, before moving them into FrameMaker for formatting and publishing. This was largely borne from limitations in Structured FrameMaker, and sits well with our usage of an internal Wiki for content collaboration. Q10 helps with this approach by doing one thing very well.

Like most well-designed products, the features are usable out of the box, but there is enough scope for tweaking things to get a system that suits you. The full-screen aspect of Q10 is the most important, blacking out the rest of the screen and leaving you with a blank slate on which to focus your thoughts. There is no menubar, with options only available through keyboard shortcuts, including one to turn off the typewriter noises which I’ve left on as they are somewhat soothing… oddly.

You can set the file encoding, a target number of words (handy if you are writing an article), change the font and colour settings, and it supports quick text allowing you to replace given character combinations with whatever you specify (I use this for product names, although you have to search and replace on the underlying text file if the name changes).

At first I was only really using Q10 for writing blog posts and articles, but I’ve started to extend it into my set of ‘work’ tools and it’s proving very useful. Sure it gets some odd looks as people glance at your screen but I certainly seem to be more capable of focusing on my writing these days.

I’ve tried a few other full-screen text editors (for Mac and Windows) but as the bulk of my writing time is spent on Windows machines, Q10 is proving very useful. Best of all it’s free!