I mentioned in my previous post that we run a webhelp build of our content (a.k.a. our Knowledge Centre) on our developer community website, and that it was hosted in an iframe. I thought it worthwhile fleshing out the detail of that as it includes a bit of custom code some others might find useful.

As our content is locked behind a login, we need to be sure that only people who are logged in can access it. This is achieved by a couple of simple checks.

1. When the Knowledge Centre is loaded, a script runs that checks it has been loaded within the correct iFrame within our website. If it’s not, the user is redirected to the login page.

The javascript for this is added to the webhelp.js file (around line 106):

//———– init function ————
Kbase.init = function() {

//OUR redirect
if(window.top.location==window.location) {
window.top.location = ‘URLTOYOURIFRAME’;
}

2. If the Knowledge Centre has been loaded in the correct iFrame (in other words the above javascript is happy), the website checks for a cookie (checking for login) and then either loads the Knowledge Centre, or, again, redirects the user to the login page. The javascript for this is standard cookie checking stuff (google will find you a zillion solutions).

And that’s it. Nothing particularly clever, but a useful way to (lightly) protect the content of our Knowledge Centre.

Finding the right solution for a problem isn’t always easy but sometimes, if you are very lucky, the solution will fall straight into your lap. Such was the case with our switch to Author-it even though we didn’t fully realise it at the time.

I’ve covered our reasons for switching from FrameMaker to Author-it elsewhere, and once we had converted our content we started to look at how we could get the most from the other output formats available. We already had ideas on how we could use the provided HTML based publishing formats to provide a better solution to the problem of finding information, and we were planning on generate HTML versions of the entire documentation set to be hosted, and searchable, on our community website.

It was right about then that Author-it announced their new ‘Webhelp’ format which would include a (very) quick search in a nice modern looking format. Given that one issue we were addressing was how hard it is to search across multiple PDFs (which presumes the poor reader knows which PDF they should start with) it looked like an excellent solution.

And it is.

We now host a specific build of all of our content within our developer community (which is password protected I’m afraid so you’ll just have to trust me), which allows the developers, partners and customers, to search across everything we have. However we have had to customise the output a little to meet our needs, and this is where the hacking starts.

Let me tell you a story. In it our hero (me) fights valiantly against two Javascript dragons called Webhelp and Google Analytics. It’s a bloody battle and at the end, when all the fighting is done, well … you’ll have to read on and find out.

Some background first.

We have a developer community website which hosts downloads of our software and all the documentation in PDF format. To make it easier for people to find information in the product documentation, we also host a Webhelp version of each and every document in one master Webhelp system so you can search across the entire thing. It works really well.

To track how the other areas of the website are used, we have a Google Analytics account and the necessary code has been added. For the Webhelp, the code is in both the index.htm and topic.htm files.

But, and this is where the story begins, it doesn’t work properly.

Google Analytics will happily track every visit to the WebHelp system, but it stops there. Any click made within the system is recorded as a click but there is no detail on WHAT topic was viewed. We had hoped to get stats on this to allow us to better focus on the areas of the product people were enquiring about but we are, essentially, blind.

It’s very annoying.

Why is this so? Well I think it’s to do with the way WebHelp is created. It uses a Javascript library called Ext JS which, amongst other things, means that every time you open a topic in the Webhelp, it’s loaded through a Javascript call so Google Analytics never ’sees’ a new HTML page (a new topic) being loaded so doesn’t know what you are viewing.

I think. I’m not 100% sure to be honest.

I’ve logged a somewhat vague Support call with Author-it, and have enlisted the help of our own webmaster. Next step will be to beg and plead with some of the developers for some of their brain power (most of them have a fair bit to spare).

It’s hugely annoying, being so close to what we want but not able to fix it myself, but sometimes you just have to admit defeat.

Of the battle, that is. I WILL win the war!

Better documentation lowers support calls, is a widely held assumption and one I’m hoping to prove in the coming months. With our new knowledge centre in place, and Google Analytics tracking how many people are visiting it, I’ll soon have stats for my side of the fence.

Early numbers (from the past two weeks) show that more people are looking at the Documentation area of our website than are looking at the Support area, but then the knowledge centre (part of the Documentation area) is new so that’s only to be expected and I’m really not expecting to get a true picture of how things are going until late January next year.

Fingers crossed.

With thanks to Rachel Potts for her post on what web analytics can do for technical communications.

Yesterday we launched a new version of our developer community website. It doesn’t have many ‘community’ features as yet but that’s all to come. One thing it does now have is an HTML version of all of our product documentation, in an easily searchable format.

It’s no coincidence that it looks very much like the Author-it Knowledge Center as it too was built using Author-it (alas I can’t show you our website as it requires a login).

This new format of the product documentation is largely to move us away from PDF only documentation. At present we still have a set of PDFs but they aren’t particularly usable.

We ran a few quiet trials of the knowledge centre format and everyone who saw it liked it, particularly the fact you can search across every piece of information offered.

So I was definitely pleased when, after sending out a company-wide announcement about the new version of the website, highlighting some of the new features, one of the first pieces of feedback I received was about the knowledge centre and how good it was. For the, as the kids say, win!

The knowledge centre will be updated on a regular basis, so my next challenge is to figure out a way to embed RSS notifications for new/updated topics. But so far so good, and with Google Analytics in place in the knowledge centre, we can continue to make improvements to both the information itself and in making sure it is accessible.

It’ll be interesting to see how the knowledge centre is used, particularly if we manage to track it against the number of incoming support calls as the main reason we are adopting this format of information is because, many times, the answers are there, they just weren’t that easy to find.

A teeny tiny gotcha that I thought I’d mention here. I can’t find explicit mention of it in the Author-it Knowledge Center and it’s tripped me up a bit.

Quite simply, and I realise these will sound obvious, make sure everyone who is using Author-it is using the same version of Microsoft Word.

My particular scenario has my laptop running Word 2007, making changes to the template, but when publishing from a machine running Word 2003, the footers weren’t being displayed despite the AutoText entry being available in the output Word document.

Naturally I’m discovering this delightful quirk on the final day of the project as we do a final publish and check on our deliverables. And people wonder why I’m almost bald…

For version 5.3, Author-it released new web help templates and having played with them a bit I have to say I like them. However I was struggling to see how to enable some of the options that you can see in the example Author-it provide, so off into the HTML and CSS files I headed to see if I could see anything useful in there.

And there is, several of the options are commented out in the HTML code and with a little bit of poking and prodding I got some of them to work. Pretty straightforward, if you know HTML and CSS that is.

But what if you don’t?

Well the good news is that the ever productive Hamish Blunck has created an Author-it Web Help Configuration Wizard which, in a few simple steps, will produce you a custom Web Help template. It really is very simple and works like a charm, it also uncovered a few options I hadn’t spotted in the code.

Thanks to Hamish for providing this to the Author-it community (he also hosts a search engine that polls the old Yahoo Group). Great stuff this, go and give it a shot.