bookmark_borderNews Headlines

Gosh, things are bad aren’t they. Awful. Credit Crunch apparently. No no, recession now. Or is it still a ‘downturn’? Hey it can’t be bad, did you hear the profit announcment from BP?

Enough of that, what about Brand and Ross? What a fuss! Fine them and be done with it. Everyone knows what they are like, and whilst that’s no excuse (and they should be dealt with) is it really the only news of the day?

What about the preview of Windows 7? No?

OK, a cat update. Last night he brought us a dead mouse and this morning, as I opened the front door to leave the house, he appeared with a tiny dead bird. Now I’ve had words with him about this before so he knew fine well that I would be taking the bird from him and disposing of it immediately.

I’m sorry but he needs to learn. Anyway, I have promised him that, the day he brings home a bloody magpie (in every sense of the word), he is free to de-feather, disembowel and generally torture the noisy thing all he likes.

And finally, Pro Evolution Soccer is taking some getting used to but it’s slowly winning me over.

Ummmmm.

So.

How are you?

bookmark_borderRunKeeper



runkeeper, originally uploaded by Gordon.

First run with this and it’s BANG on the money, you can even see which side of the road I ran down. Brilliant.

It’s still early days, and doesn’t have the same depth of information that a website like Fetch does but it’s quick and works far better than the Nike+ website.

bookmark_borderHow do we move to single source?

I’ve waffled on about single source and our plans for long enough so, as we are finally starting the process itself, I thought I’d capture some information as we go along. However, it’s probably good to set the scene, so I’ll cover that stuff first. Over time you’ll be able to see all the posts related to this work here.

How? – how do we do it?

Once we’d agreed that single source would provide us with a good solution (it’s still not ideal, but nothing ever is..) the next question was “How?”.

Having followed the technologies in this area quite closely over the past few years my immediate thoughts went towards a DITA enabled solution. The basic topic types and methodologies fit well with an Agile environment so there would be fairly immediate benefits once we got the system up and running. We spent some time investigating our content and planning how best to leverage DITA to our advantage and once we were happy that it would meet our needs (with less over head than adopting DocBook) we looked at the technological challenges of adopting a DITA based system.

And that’s where we hit the biggest block. DITA is an excellent methodology but still lacks simple/cheap tooling support (it would take upwards of several thousand to fully implement a DITA solution, whereas a bespoke solution could cost considerably less). Other considerations (we have JavaHelp as our online help format) also came into play and, after some investigation of other XML based tools we decided to go with Author-it and base our working practices around the DITA methodology and topic types.

We did consider upgrading our legacy applications (FrameMaker and Webworks) and configuring them to give us a solution that would meet our needs but even the rough estimates for that work took us beyond the cost of our chosen solution.

One caveat to this is to note that I have used Author-it previously and, whilst it is not without its foibles (which application isn’t) it hits the sweet spot of functionality versus cost. None of the rest of the team have used it but that would be the same for any other new tool and was considered as an upside to keeping the FrameMaker + Webworks solution.

A second caveat is that I’m fully aware that, in due time the tool vendors will get on top of this problem (MadCap already seem to be ahead of the others in this area), but alas the timescales don’t suit us. Worst case scenario is that we ditch Author-it in a few years, export the content to DITA XML and import to a compatible tool that meets whatever needs we have at that time.

bookmark_borderAimee Mann

It was my first visit to the Old Fruitmarket venue in Glasgow last night, to listen to ‘that woman who had several songs on the soundtrack of Magnolia’, Aimee Mann.

I can’t quite remember how I discovered her, but it was only recently that I purchased her previous album Bachelor No.2 and, quite liking it, I soon found I was a bit late to this party. She won’t tick the boxes for everyone and if I’m honest I’m surprised I like her enough to go and see her live.

Still, she has a way with lyrics that I like and a knack similar to Guy Garvey for capturing gorgeous imagery even if she is overly preoccupied with the freaks and failures of life. She does have a great ear for a tune and last night she picked several songs from her new album which does feel a little more upbeat than previous offerings.

The Old Fruitmarket is a small venue so the night had a nicely intimate feel to it, although it probably helped that I was four rows from the front. Aimee has a nice laidback on-stage persona which lends itself to a low key gig that felt well paced and never rushed. I admit I was expecting things to be a little ‘rockier’ than they were but it was far from a disappointment.

Halfway through the main set, she asked for requests and considering how they stumbled through “Dear John” (it took a member of the audience to remind her of the opening line) it was certainly a genuine performance. Supported by a very slick band it was a surprise when they reached the end of their main set, time flies and all that.

Back out for four songs, all requests and then off to politely raucous applause (everyone stayed seated), it was an intimate if somewhat removed show. Highlights included the requested singing of one of my favourite songs, 4th of July, and a solo acoustic version Red Vines which was mesmerising and hauntingly gorgeous.

bookmark_borderOn not running

Not jogging today as I have a twinge in my back. It happened at some point at work on Friday, just a wee tweak of a muscle I’m sure but I really don’t want to risk it. I’ll try to go out tomorrow night I think.

The jogScotland programme helps when this happens, it’s a slow build from one level to another, so missing one run doesn’t set you back. This morning I had planned, after my run, to go and support some co-workers who are running a local 10K with the aim of supporting Cancer Research. I might still wander down…

But having looked at the weather, maybe not. It’s one thing to go for a run in the howling gales and lashing rain that we’ve experienced this past week, quite another to just stand about it in. A lot of people have expressed amazement that I enjoy running in the rain and the only way I can explain it is to say that it’s very much like being a kid again. Sploshing through puddles and not worrying about getting dirty, it’s fab!

The wind? Yeah not so much, and I’ve already got the running tights looked out for the first of the snow.

What? Ohhh shut up…

bookmark_borderWhy we are moving to single source

I’ve waffled on about single source and our plans for long enough so, as we are finally starting the process itself, I thought I’d capture some information as we go along. However, it’s probably good to set the scene, so I’ll cover that stuff first. Over time you’ll be able to see all the posts related to this work here.

Why? – why single source?

A quick summary of our current situation. We currently maintain (and add to) ~2000 pages of documentation. The same content is used for both the PDF manuals and the online help provided with the product (exactly the same, no restructuring). There are various levels of coverage (some good, some bad), we are embedded within an Agile development environment, limited publications resource. On top of that we have an aggressive release schedule and a two-tier product which includes a development kit and an application built by us using that development kit.

Whilst we have made good strides in improving how we work with the software developers – we have a technical writer embedded in each new feature team and the benefits are evident from both sides – we know we need to be focussing our efforts in the correct areas, and providing information in a structure and format that meets the needs of our audience. Luckily we have direct access to the largest section of the audience as they work for the company.

Better structured information is one of the requests, and to allow us to get the most of our current documentation we would need to reuse a lot of the content we have already, but it’s locked away in FrameMaker files, sometimes in the depths of a 100 page long chapter. What to do?

Ultimately we believe that the ability to reuse our content will make producing the content faster – the current documentation set is unwieldy and hard to search, a little digging reveals some duplication already exists – and make us much more flexible when it comes to providing useful sets of information for our audience/customer.

Eagle-eyed readers will have spotted that we already single source our documentation and online help from the same FrameMaker files, but as we don’t reconstruct the online help into something more intuitive and useful it is, essentially, an HTML rendition of the manual. Not ideal by any stretch of the imagination.