Documentation always seems to come last at our company. First, it can't be written until the code is done. Then the programmer(s) involved are on to the next thing on their schedule while the documentation person needs to get a brain dump from then – after it has gone through testing and they have a build.
We also have a fundamental problem that we do not save up new features and then release all of them at once every 9 months. About 2 years ago we decided to release new features when they were completed – we had something we had added that one of our customers desperately needed and telling them to wait 5 months would not help anyone. With the program a constantly moving target, the documentation also became a moving target.
So we switched our whole approach – and it's working great. The documentation is now all in a wiki at ohana.windwardstudios.com. All Windward employees and a number of our customers can edit it at any time (anyone can add a comment at the bottom of any page). So now when a developer checks in the final code for a new feature, they are required to document it in the wiki. So we now document a feature before we ship it. And the person who implemented it writes it up when it is totally fresh. (BTW – I grew up in Hawaii and that's the Honolulu Airport wiki-wiki bus.)
This has made a tremendous difference. The level of detail and description of why you would use a new feature as well as how has jumped substantially. It's human nature, when a developer has checked in their code they are the proud parent of that feature and want to describe it in detail. And at that point they retain every detail of it and that all goes in. The old way they would be asked about it several weeks later when they are busy on a new feature and so their focus and memory is elsewhere.
The documentation person gets an email whenever a page changes. So she then goes in and cleans up the new documentation. A lot of developers do not write the clearest documentation, but it's enough that she can turn it in to something very clear and complete, occasionally asking the developer for some clarification.
Now the wiki is great, but what about when you click help in the program? Well it will first try to go to the appropriate wiki page for that help. So clicking help gets you the latest information if you are connected to the Internet. The biggest problem with this is you may read of a feature that your older version does not have. But that is just an indication that if you need that feature, grab the latest version.
And if you're not connected to the Internet? About every 9 months we bump the version number by 1, and then copy all the wiki content to html files. We ship those files with the program. So if the wiki cannot be connected to, it will pull up the local file instead. These files do slowly get out of date, up to 6 months so, because making a local copy is very labor intensive (basically 1 week's effort by an intern).
The code behind this generally works fast. The Windows call InternetGetConnectedState will return instantly if a system is connected to the Internet. If it is we request the HEAD for the desired page as that's the fastest way to determine if we can get the page. This will take a couple of seconds if it will fail, but failure is very unlikely.
We've had videos for some time for some basic training. But we are now in the process of adding videos to demonstrate how to perform any action that we get repeated questions on. These videos will require a connection to the Internet because users do not want us installing hundreds of megabytes of videos to their system. But the links to the videos are being incorporated throughout the wiki so a video to demonstrate a concept will always be a click away.
We are also adding Computer Based Training. We are creating interactive videos where it is showing the system, explaining what to do, highlighting the next step, and then the viewer has to perform that operation. So it guides you through performing each step of the action you wish to accomplish.
We also had one person come up with a very clever idea. The first time you run Office after installing AutoTag, it opens on a document we created. That document is both a tutorial and a report template. So it explains a concept, then has that concept as a set of tags there in the document. You can at that time tell AutoTag to run the template you are in and see the generated report. I like how it's both tutorial and template all in one – something we can only do because it's design in Office.
[DllImport("wininet.dll", CharSet = CharSet.None)]
private static extern bool InternetGetConnectedState(out uint lpdwFlags, uint dwReserved);
/// Determines if can access a webite. First checks connection state (that is fast). Requests the HEAD to verify.
/// <param name="uri">The uri to look for.
/// <param name="timeout">The timeout in milliseconds. Reccomend 10000
public static bool CanLikelyAccessWebSite(Uri uri, int timeout)
if (!InternetGetConnectedState(out unused, 0U))
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
request.Method = "HEAD";
request.Timeout = timeout;
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
return response != null;
No idea. But one thing I have learned, documentation can always be better.