As a software engineer I am no stranger to contextual tools. Tools which provide me with relevant information based on the work I am doing. Many of the popular development environments feature tools which provide the engineer with relevant documentation, most recent change history, code usage information, and much more.
When I started out in my career, I didn't place much value on these things. Instead of leveraging these tools, I purposely chose the most minimal development environment I could find. I didn't want the system to help me with code suggestions or refactoring, I wanted to do it all myself. I thought that the best way to learn how it all works was to do it all "by hand", and not build reliance on any one development environment or set of tools. If I wanted to inspect the history for a file, I would use the terminal and my version control system. If I wanted to import a third-party library I had to look up the import path, after finding the correct documentation. If I wanted to debug some code I used rudimentary tools to give me the information I needed. Consider any part of writing software, I took the long way around every time.
This strategy worked, to a point. I became familiar with the external libraries I was using, with where to find the relevant documentation, and with jumping between multiple applications to help me find what I needed. What I hadn't anticipated at the beginning of my journey was the cost associated with this approach. There was little to no monetary cost, but rather the cost of constantly context switching and maintaining the layers of knowledge required to accomplish my task.
My end to end process often involved multiple applications, multiple tabs open in my browser, a communication app such as email or an IRC client, and my text editor. Even though I was a competent engineer, familiar with the code and content I was working on, I still found myself jumping between applications and changing context frequently.
It simply is not possible to hold all the relevant information in your head all of the time.
Knowledge work requires maintaining layer after layer of context to support the worker. To effectively understand the task at hand you must understand the history, the surrounding context, existing relationships, existing patterns and solutions, internal and external requirements, the list goes on.
Over the years I have come to appreciate the value in what I think of as contextual knowledge tools. Tools which present you, the user, with relevant information in your primary context. I believe this is applicable whether you are a programmer, an author, researcher, business analyst, or even just responding to a large email thread. The less you have to switch out of your primary context to find a piece of relevant information, the more you can focus on the job at hand. Tools which deliver contextual knowledge help you to be more efficient, more focused, and produce higher quality work faster.
As an engineer, my primary context is my text editor - the interface I use to write and edit code. In this context, I find myself wanting to see documentation on the code I am working with, where else this code is used, who last changed this code and what reasoning did they record for their changes, and much more. The application should, and does, provide ways to access this information with the click of a button or a few keystrokes.
When I am writing or reviewing policy documents I find myself in a word processor, wanting to see related content to ensure the changes I am making or reviewing are accurate and consistent with the wider policy landscape. Perhaps I need to review a section of a standard such as ISO 27001 or ISO 15288, or I need to review a policy which is referenced by the one I am looking at. Ultimately this is the same problem I face as an engineer. One primary context: my policy document. Multiple relevant external knowledge sources: the ISO standards, existing internal policies, etc., and the need to move back-and-forth across them all multiple times to build the layers of context which I need in order to complete my work.
Contextual delivery of knowledge, regardless of the primary context, is a key capability in any area of knowledge work.
I find myself being confronted by this problem quite frequently, whether in my own work or in the lives of the clients I work with. The more time goes on the more I am convinced that the best products for knowledge workers, and especially those who work with complex interconnected knowledge systems, are those which implement features which deliver contextual information in the users' primary context.
The implementation of contextual knowledge tools is something I am keen to see more of in the products I use personally, and in the products that we build in Propylon.