Nostalgic Reminiscing

Back in the day, I built a knowledge base solution for a large oil and gas company, hosted in a SharePoint. The business maintained heavy-weight documentation in Word but were concerned that this approach, whilst satisfying compliance regulations and allowing auditors to tick off a check sheet, did not make it easy for consumers (their staff) to quickly find the key information needed to do their work safely. The concern was not that the information was lacking, but rather that it was simply inaccessible as no one takes pleasure in wading through 400+ pages of technical information in search of some key guidance information.

The first (and most obvious) recourse was to throw out the SharePoint search engine as the solution. But that didn’t really help. It might find us a good subset of candidate source documents, but users still needed to open each document in Word (I should mention this was on-prem and back in the day before we could open Word documents directly in the browser) and plough through its content.

I am up with a solution called Word to Wiki (W2W), initially an old school full trust farm solution (remember them) and later a Provider Hosted App built as a SharePoint Add-in (an approach which is now deprecated). The solution would allow authors to manage their source content in Word but at the click of a button, publish it as a SharePoint wiki web page. It was a big success in its day, but sadly it’s day has passed, for it was built for a SharePoint Classic world using a deprecated technology – R.I.P. W2W ☹

Do we still need wikis?

Strictly speaking W2W was not what I would consider to be a wiki solution because wikis have a decentralised content management model. They are aimed at empowering citizens to make (expert) contributions as they deem appropriate. This can lead to tapping a world of hidden knowledge which might prove invaluable, by turning tacit knowledge (implicit knowledge acquired through experience) into explicit, documented knowledge that might improve the productivity of journeymen.

However, great care must be taken. An experienced field engineer might suggest that tapping a stuck release valve with a monkey wrench gets the job done but a newbie might think a large bang with a sledge hammer would do just as well – potentially resulting in well, a large bang!

You get my point, wikis can be dangerous (literally). And yes, we can put moderation in place, but that comes with a management overhead.

I personally do think that there is still a place for wikis in the corporate enterprise but they should be used in specific scenarios only. They might still provide a rich seam of knowledge gold, but should not be used as uncontrolled surrogates for Procedures, SOPs, Work Instructions, Safe Handling Instructions or the like. These products need to be subject to good governance with tightly controlled approval an release cycles.

Web Publishing then?

I say W2W wasn’t really wiki solution because most customers used it as a content publishing tool rather than for content migration. As a web publishing tool, the source documents (the Single Source of Truth (SST)) was stored in Word documents and W2W simply provided a way to publish renditions of these documents, with the intent of making the information more readily accessible to consumers.

So, the question now becomes – do we still need web publishing tools? This one is more tricky to answer because now, in SharePoint Online and with the Modern UX we can open a Word document (or PDF) in the browser at a link-click and are no longer encumbered with overhead of first opening a heavyweight client app, primarily intended for content editing rather than information consumption.

The problem is the Word in the browser doesn’t quite cut it – it’s almost there but not quite. Let’s see what Word in the browser gives us and then we can see what is missing and then decide if we still need something else.

Word in the Browser

It’s not too bad. I can access the document and read it cleanly and I can use the document navigator to skip directly to headings.

And the Find tool works great, I love the search term highlighting and text snippet based navigation (super-cool).

The only problem is that these tools are only available in Edit mode and what I want is for them to be available to consumers (users with read-only access or using View mode).

When in document View mode, the unnecessary tabs and toolbars disappear – which is great, as it makes for a far cleaner UI.

But my cool navigation tools are gone!

What else is missing?

Even if Microsoft were to find a way to enable the in-document navigation features for view mode. This only give us half of the system, or rather half of the system that I envisage that would be required to build an effective knowledge base solution.

You see, when accesses from SharePoint, these documents sit in splendid isolation. They are an information island unto themselves. In some cases that is just fine but often the document is but one element of a larger information space. Yes, we can cross link documents by embedding appropriate hyperlinks to other relevant resources but that is like having a tunnel to another information island.

The problem with hyperlinking between documents (using a tunnel) as that you still can’t visualise the full context and you also have no guarantee that there will be a back link to where you started – you might be riding a one-way-tunnel, and have no way of knowing!

Structured Authoring – we need bridges not tunnels!

What we need here is an inter-document navigation mechanism. But we need more that just a flat set of links because the association between documents might be hierarchical in nature, and so to provide an appropriate context we need a navigation system that is capable of reflecting this structure.

For example, consider a knowledge base that provides users with access to controlled documents. A Policy document might set the overall context at a general level for a business functional area, but specific activities, business processes to be executed as part of that wider function, might be supported by a specific set of Procedures which may reference specific Work Instructions or provide access to Forms (form templates). So, we might end up with something like this:

The Internet is awash with these type of Knowledge Base (KB) solutions. Microsoft themselves use their own system in multiple scenarios, including the Microsoft Learn KB, as shown below:

Good as it is, I think the example Learn KB can be improved upon in the following ways:

The navigation panel on the left provides the way to switch between documents (articles if you prefer), without losing the overall context. It provides bridges, not tunnels and it supports a hierarchical navigational structure and so that any parent-child relations between documents are easy to visualise.

• The layout has 3 panels (left article nav, centre content-viewer area and right in-page navigation) but I would like to be to at times, toggle the visibility of the left or right panel an so give over more screen real estate to the content viewer.
• I’s also like to have the ability to resize the left and right panels – a couple of draggable vertical splitter would do nicely.
• It uses Markdown as the format for the main content viewer, and whilst the simplicity or Markdown is appealing, I would prefer the flexibility or full HTML.
• The in-article navigator provides a header-based navigation tool only, we lack the quick quick-find tools available to us with Word Online.

There are several other features and tools that I can think of which would readily improved the user experience, but I won’t go into those today.

K-Docs Publish

This type of solution is commonly referred to as Structured Authoring and I think it is a badly needed and sorely missed part of the SharePoint infrastructure.

To address this missing piece of the jigsaw, Kaboodle Software have developed a solution call K-Docs Publish. The current version (as of December 2025) is available from the Kaboodle Software web site now and publishes source Word Documents as SharePoint Modern Site Pages (or as PDFs), but it does not currently provide the inter-article browsing capability described above.

However, the Kaboodle team are hard at work developing the full-featured version which will launch in the Microsoft Marketplace in February 2026. If you would like to try out the beta of the new version, please reach out to me and I will make it happen.

As with all Kaboodle product, there is a fully functional Freemium option. You only need to acquire a paid-license if you need access to advanced features.