The Four Phases of Knowledge Production

Knowledge production consists of four basic phases – manage, create, process, and share. When designing knowledge production systems, it pays to keep these four phases in mind and to build platforms that have an eye on this high-level abstraction. These phases can be linear dependencies, overlap and/or be concurrent.

‘Thinking from above’ can help us to better understand where the needs of each phase might be placed within the system we are designing.

Manage – when producing a knowledge asset, there needs to be some management of the context. This mainly includes things like the setting up and processing of users, roles, permissions, and groups. However, ‘manage’ can also be an appropriate way to think about the ways users access content. A dashboard is a management interface, as are interfaces to create a Table of Contents (book) or keep track of a Collection (eg a set of related journals). The usefulness of thinking of management needs in this way is that it really highlights that a dashboard (consider Google Drive as a dashboard) and a Table of Contents interface for managing an online book production system are the same category of interface. They might have a different treatment according to the use case, but they facilitate much the same kinds of activities.

Create – content needs to be created, so we need content-creation interfaces. We are familiar with these: think about blogging and where you write your posts – that is a content creation interface; now think about a book production system where you write a chapter – that is also a content creation interface. These interfaces both belong in the same high level abstract container.

We need to think of content creation interfaces at a high level of abstraction when designing these kinds of systems for many reasons.

First, it is useful to think about how components may be re-used. What, for example, is the difference between an interface that is used to create a blog post, and one used to create a chapter? For a great deal of use cases, the answer is nothing. This re-use approach is taken by PressBooks, for example. PressBooks uses WordPress as a book production platform (note: I don’t agree this is a good idea, as WordPress is an entire suite best suited to blogs and not books, but I am pointing out the similarity of the content production needs at a very high level).

Second, it is interesting to ask ourselves what kind of content we are trying to produce and whether we have the right type of content production interface. Think, for example, of a book production system. All (except one) of the online book production tools I am familiar with have one kind of content creation interface – a WYSIWYG editor attached to a blank page. You use the editor to fill up the page until your chapter is done.

But what if you need to produce a glossary? Most book production systems use the same tool. That doesn’t seem like a good idea. Glossaries have very specific needs – users need to be able to sort, create new items, perhaps even translate terms into other languages and sort by those languages etc. A ‘waterfall’ cascading content creation interface (WYSIWYG and a blank page) doesn’t meet that need very well. What if you wish to produce 2 page spreads (in the case of paper books), or an index ? …then imagine that instead of books, we are are looking to produce annotated data sets.

We need to liberate ourselves from the one-size-fits-all approach to content production, and placing these needs in a high level abstract container allows us to think of the needs and not the UI.

Process – one thing I have come to learn through working in STM publishing, is that publishers add value to content by improving it. That is pretty much what every publisher does. In my mind, we should be re-framing publishers and calling them processors. After all, making content public these days is a doddle. And the difference between ‘self-publishing’ and ‘publishing’… is the processing bit. Self- publishers (generally speaking) do not have access to the same level of experienced and useful processing that can improve a work. As the day goes on we will have less and less value for the ‘publishing’, and in the case of STM, the long wait to making science public is already an impediment to progress.

The processing of content is an important part of knowledge production. If we want good knowledge, we need to be able to bring into play all those people and (sometimes) machines at the right moment to improve the work. That is essentially what workflow is all about. Processing is a high-level abstraction for workflow. It’s important to consider processing at a high-level abstraction because far too many systems build hard-coded workflow pipelines into their platforms, and that retards the opportunity to reconsider, optimise, and even radicalise workflows. I also consider other UI elements such as discussions to belong in the ‘process bucket’. Discussions are workflow and they are often the only type of mechanism that can account for the high level of specificity and issue resolution required on a per-knowledge asset (eg issues for each manuscript, chapter etc) level.

Share – formerly this was getting the book to the bookshop, but under current conditions this is something else entirely. Sharing works in the age of digital assets and network communications is all about file formats, APIs, and syndication. Avenues for sharing and the requirements of this process are prolfierating daily and the needs can be so complex that any system built to manage ‘sharing’ needs to be extremely flexible.

Thinking about sharing at a high-level of abstraction helps us with this enormously. For example, ingestion of .docx to an HTML-based knowledge production system is actually an act of sharing. It consists of file conversion and feeding the result into the production system for others to access. That ‘feeding’ of content into our production system, is a type of syndication. And the next ‘export’ of the finished product to some other system (eg a book sales system), requires a further process of file conversion (to the target book format) and feeding that format into the target system. Exactly the same high-level process as ‘ingestion’. They both belong to the ‘sharing’ bucket.

So, we can see that actually ‘import/ingestion’ and ‘export’ are actually the same thing. Consequently, we can save ourselves a lot of effort by building a framework in any knowledge production system that will ‘do both’ (ie recognise that there is no difference between import and export, and manage both rather than building redundant parallel processes).

The beauty of this ‘conceptual schema’ for knowledge production is that we can apply it to a wide variety of use cases to understand the knowledge production process at hand, and the variation and similarities between any of them. For example, Book Sprints traverse each of these 4 phases, as does a typical book from a publisher, as does a Wikipedia article, as does a grant application to a funder. Thinking of the process that way helps us see where the variance is – and helps us to better focus on designing for the needs of each. This suggests that a really good, efficient, single system can be designed to enable the production of a vast range of knowledge types, and accommodate apparently different processes which were formerly housed in standalone single use case platforms.

Colophon: written in Piha after walking on the beach, then cleaned somewhat by Raewyn. Written using Ghost blogging software (free software!).