Tag: <span>SVN</span>

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.

Tech Work

Prompted by an excellent article – Subversion for writers – I thought it might be useful to offer a Windows view. Like most software groups, our development team use a version control system to manage multiple versions of the product; we have customers using many previous versions and all are maintained in the same system so we can patch fixes back through multiple versions.

Our team of writers use the same system, although as we are using FrameMaker we lose some of the nicer features but the core reasons for using a version control system remain – files are locked by whoever is working on them, and we have a full version history of changes made, including when, who and why.

Single sourcing is good, I’m sure most of us can agree on that, but I’ve recently been wondering if perhaps DITA isn’t quite good enough?

The thing is, I’ve been looking at DITA as a solution for our single sources needs for a while now. I’ve attended conferences, read whitepapers, listened to vendors and everything else that goes with it and I’ve got a pretty good handle on things. If applied correctly the benefits you can gain are very large, although the same can be said of any other single source project, yet what seems to be consistently missing during all of these wonderfully theoretical discussions is the cost and impact of getting such a solution “applied correctly”.

A key part of planning to move to single source, of which DITA is only a part, is understanding the business needs and technological requirements of all of the content producers in your organisation. Traditionally that means Technical Communications, Training, Pre-Sales and Marketing, with perhaps other flavours to be considered depending on how your company is structured.

However, if those parts of your organisation aren’t yet ready to move, then the business case changes. At present this is the situation I’m in, so I find myself looking for a short-term (2-3 year) solution that won’t lock us in to a proprietary format and that can give us benefits as soon as possible.

Re-use is our main reason for moving to single source. We don’t (yet) localise, and there is only one other team that has any interest in re-using our content (and even then, they are likely to use it as an source of verification, not a source of content). With that in mind, and with the proviso that I’ve used it previously, we are looking at AuthorIT.

Yes it does mean we forego a lot of the power of DITA but as it will allow us to tag topics accordingly (in keeping with the DITA model) and it does have an XML DITA output option, then it shouldn’t lock us in. I’m willing to put up with a little pain further down the road to get the benefits now.

I’m still not entirely sure what else we are missing. We publish PDFs, HTML and Javahelp, all of which AuthorIT handles, and as yet we don’t have a need to dynamically publish information based on metadata. If that changes in the near future then we’ll handle it appropriately but it isn’t on anyone’s radar.

I am concerned about the versioning capabilities of AuthorIT as we maintain the last 3 versions of all our publications, but I know there are ways to achieve this in AuthorIT. I doubt it will work as well as our current system (FrameMaker files in an SVN repository) but, as is always the case, I do expect we may need to make some compromises to get ourselves moving towards single sourcing our publications. This is our main pain point and so becomes the focus for any possible solution.

DITA remains the long-term goal but, and I’ve said this before, until there is an all in one solution that is easy to rollout it remains marginalised as a viable option. Most of us need to produce some form of business case to justify such purchases and, at present, DITA is still too costly an option. I’m always happy to learn new things, and whilst I would love to be able to invest time and resource into creating and maintaining a DITA based solution, I just can’t justify it.

All of my research suggests that, rather than being a simple installation and conversion process, creating a DITA solution requires a lot of technical know-how and a not insubstantial amount of time and resource. We can handle the first, the latter is (I believe) not yet at a level which makes it cost-effective.

Ultimately, for the moment, DITA costs too much.

Do you agree? Can you prove me wrong? I’d love to hear your thoughts on this, particularly if you have implemented DITA already. I’m keen to hear just how more productive a DITA solution can be if you aren’t involved in localisation. Have you recouped your costs yet?

Perhaps DITA is only really applicable for those with large budgets and the chance to invest heavily upfront. Alas I’m not in such a position. For the moment.

Tech Work