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.

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.

First things first, the Webhelp output is built using HTML templates (for the layout and structure), CSS (for the styling) and is powered using Javascript. If you are competent in HTML and CSS you can do a lot of tweaking of the templates, although a good place to start is this excellent configuration wizard so generously created by Hamish Blunck.

So what is so special about our Webhelp?

1. Cookie detection
As we publish our webhelp to our developer community website, we want to make sure that only people who are logged in to the website can access the content. So we’ve added some javascript to the webhelp.js file which does just that. The code itself came from our webmaster but it was easy to take it and drop it in. If you aren’t logged in, you get redirected to the login page.

2. Tweaking the look and feel
As I mentioned earlier, after looking at the HTML and CSS myself, I happened across this configuration wizard. It covers most of the basic things most people will be concerned about and after running through the wizard, all I did was change some of the underlying images (to include our logo instead of the “built by Author-it”) and added in a copyright message to the footer. Both of those changes are made in the index.htm template file (around lines 50 to 70). Thankfully the colour scheme of our community website is based around blue so I didn’t have to tweak the colours (Hamish offers some tips on that as well).

3. Google Analytics
Tracking what people are viewing what topics is our ultimate aim. Unfortunately the way the Webhelp system is designed makes that very hard. Without getting into too much detail, whilst there are HTML template files (index.htm which sets the 3-pane view, and topic.htm which styles the topics themselves) the topic content is pulled through some clever javascript before it is displayed. Google Analytics requires a ‘hook’ to be able to track which topic people are looking at and as the javascript method used doesn’t provide that, we are currently blind as to what people are looking at once they get into our webhelp system.

That said, I’ve logged a Support call with Author-it and they are looking at (they are very good that way!). I’m hoping to get a resolution to this as I’d imagine more people might start looking at this area in the future.

4. Automated Build
This isn’t strictly a hack of the Webhelp but I think it’s worth mentioning. Author-it offers a mechanism for publishing via batch file, and we now have a dedicated machine which has a Scheduled Task to run the command line that builds the webhelp. Each Sunday it runs the correct build, and FTPs the files to the webserver. This means we always have the latest documentation available, making it much easier for us to get the information published as soon as possible, removing the constrains of the product release schedules. Whilst working in Author-it, we keep draft information out of the books that will be published until they are complete so there is no danger of the wrong information being published.

And that’s about it.

The published webhelp includes, as the ‘homepage’, a topic that lists all the recent updates the documentation, including links through to the updated topic, but the most impressive thing for the people who use it is the speed of the search. A direct quote from one of our developers, when I showed him how it worked, was “ohhh now THAT’S cool!”, and our Support team are actively pushing customers towards it as well. As making it easy for the technical users to find information was one of the main reasons why we chose this format (and ultimately why we switched to Author-it) I consider that job done.

For now at least.

So, with webhelp published to an area of our community website (it runs in an iframe there, the website itself runs on Joomla), we have an excellent place to direct technical users of our product. The recent updates page also allows me to do a little soft ‘marketing’ in the form of a fortnightly “What’s New” email which I send out to the relevant audience, which helps raise awareness.

The last thing to mention about the webhelp format is that it looks good. That’s one of the instant barriers removed, and everyone who has seen it has said something similar. It looks good, it looks professional and whilst I’m more concerned about the content within it, getting people to like something is sometimes the hardest battle of all. If they like it, they’ll use it and, so far, they are using it in droves.

Update: A quick screenshot of our webhelp based Knowledge Centre.

I mentioned this on Twitter and was promptly asked where it was published. I’ve mentioned the newsletter in passing here but realise that I’ve covered it in any more detail.

First things first, you don’t have to be a member to receive the newsletter, anyone can sign up and anyone can view the archives.

Having checked back I actually started my contributions to the newsletter in April 2008, almost two years ago, which took me by surprise. Since then I’ve been monitoring a large number of related blogs, and offering my take on the best posts from that month. I actually started doing that here but the newsletter took the focus.

The newsletter is fun, and offers me a chance to look back at some posts I’ve read but perhaps not fully digested properly and it feels good to be spreading the word about the great content that is available. There are a lot of smart people out there, and it’s good to get a chance to direct some traffic their way.

When was the last time you looked at the things you don’t do?

The reason I ask is that this very question is occupying my mind at the moment as I try to pull together both a content audit of what we have and a plan to create the things we don’t have. Which isn’t as easy as it may sound.

There are three or four different departments involved in the audit, and from each I’ve asked the same two things:

1. A list of all the content you currently have
2. A list of all the content you would like to have

With both lists in place, and understanding that some items in the first list may also need some rework or ongoing maintenance, we should all have a good view of what everyone else is doing and be able to plan a smarter way to produce more of the items in list two.

Whilst this is nothing radical it should help us by making people step back to see the big picture and allow us to move forward in one direction. Once this phase of the content audit is complete, the next stage, planning how to fill some of the “would like to have” gaps, will begin and once we start producing this content, regular catchups will help keep everyone up-to-speed and make sure we all focussed towards the same goals.

The tricky bit will be populating the second list. Asking your audience or colleagues for input will lead to one thing, a very big long list of “hey, do you know what would be REALLY good…” style requests. I’m more than happy to field those and they are, for the most part, good to have noted down.

Where it starts to get tricky is in the prioritisation of these things, and for that you’ll need to get some of the interested parties together to help. I’ve already covered how I do that but to make that process a bit slicker (it’s very ad-hoc at the moment) I’ll be setting up a common “Information Planning” meeting. That way we can involve the pertinent stakeholders in the decision process, and it will help communicate the ongoing plans around the Information Strategy.

Towards the end of last year I started to see how several related, but disparate, strands of work would start to come together. The information produced by my team, the training collateral, the partner focussed material, is all focussed on the product and this coming week will see the first step towards the realisation of all that hard work coming together into a cohesive story.

The final push comes in the form of a content audit, which will allow me to see where the gaps are, and where rework is required, to complete all the ’stories’ that run from the main product messaging, down through our information strategy pyramid.

At present we have successfully moved to a single source/content re-use system which allows us to publish content to a knowledge centre hosted on our developer community website, that content is also used by the sales/pre-sales department who receive it in a different format.

The developer community website will be used by partners to both learn and keep up to date with product developments, and reduce the burden on our Support team (something that is already happening with call numbers going down since we introduced our new knowledge centre). The website also means we can look at producing our forms of content for information delivery, videos, screencams, example tutorials and such like.

This is an area where the training team and publications team will come together and which the content audit will help drive.

On a personal note it’s nice to be on the final straight of some ideas I’ve had brewing for a couple of years now. I’ve been lucky that I work with a team of guys who I trust completely to do a good job and who’ve never let me down regardless of the challenge.

It’s going to be an exciting few months, with much to learn and many hurdles to be overcome but once complete I think we will have an excellent, information focussed culture throughout the company.

Buy-in for the information strategy will be re-enforced by the content audit as I’ll need to talk to everyone who could/should be involved, but it is noticeable that there has been a shift in understanding throughout our company with the realisation that information will play a larger and larger role in driving us forward.